Incomplete packet_finder in kobuki_driver

[yhju]

Sometimes packet_finder in kobuki_driver retrieve over-sized byte stream, or misaligned byte stream.

[yhju]

It was problem of ecl_formatter, not packet_finder.

I temporally disabled it in 3d455c0

Done.

[stonier]

Young Hoon, when you find a bug, don't disable and close it as a solution. That is not bug hunting, that is bug avoiding.

This bug will now appear for someone else in another program, which means, people have to debug again.

Start providing hints. At the very least, start a new issue in ecl_core with information.

• What error was occuring?
• Was it formatter or was it just the use of formatter?
• Do you have a simple test program that can reproduce it?

[yhju]

Actually,

In my opinion, the bug is here.

follower member variable of ecl::PushAndPop is not always zero, but ecl::formatters::ByteArrayFormatter always reads buffer( or container) from zero.

[stonier]

Formatters fixed in stonier/ecl_core#1

[stonier]

The problem I suspect isn't solved - it just isn't being troubled by formatter anymore.

I think the problem is because PushAndPop has a rollover policy. i.e. if it is full, it automagically pops the first element. This will cause serial packets to be misaligned.

If you find a robot on which this happens alot, let's cout the buffer.size() value to see if it's full.

[stonier]

In particular - buffer variable in PacketFinder. It is set to a size equal to:

  buffer = BufferType(size_stx + size_length_field + size_max_payload + size_checksum_field + size_etx);

Currently size_max_payload = 256. This may not be big enough. Again, do logging to work out how full buffer is getting.

[stonier]

Conclusions - PushAndPop should provide some warning when it's overwriting old data.

Practically, it needs a large enough buffer size for the driver to work with so that tdoesn't happen often.

Leave the warning flag for later. We have notes about this now here that is sufficient.