search

osrf / ros2_serial_example

61 stars 13 forks source link

Re-evaluate the serial framing protocol #18

Open clalancette opened 5 years ago

clalancette commented 5 years ago

The current serial protocol is exactly equivalent to the one in https://github.com/PX4/px4_ros_com/blob/master/templates/microRTPS_transport.cpp#L151 . However, it is worthwhile to explore whether that is the best way to frame a serial protocol. Some observations and thoughts on serial framing design:

  1. The payload should be a well-known format. We are using CDR.

  2. There should be a header with a well-known sequence, a length at the beginning, and a CRC. We are currently using CRC16. The current protocol looks like this (the vertical bars are separators and not actually part of the protocol):

    >>>|topic_ID|seq|len_high|len_low|CRC_high|CRC_low|payload_start...payload_end|

  3. Currently sends and receives to the serial port are "send it and forget it". It might be nice to have an ACK/NACK response.

  4. Currently, messages that are larger than the ring buffer in the serial->ROS2 direction are just quietly dropped. It might be nice to have the ability to query for the largest size message that we accept. Aternatively, see 3 above.

  5. We may want to think about using byte-stuffing for the serial protocol (see https://eli.thegreenplace.net/2009/08/12/framing-in-serial-communications/). In particular, think about the case where one of the first three > gets garbled in transmission, but there is >>> somewhere in the body of the message. In that case, we'll essentially be taking "random" data as the sequence, length, and CRC, and may make us do something unintended.

  6. Even better, maybe we should look at using COBS instead: https://www.embeddedrelated.com/showarticle/113.php

clalancette commented 5 years ago

This has partially been done by implementing COBS as an alternative in https://github.com/osrf/ros2_serial_example/pull/33 . However, we still want to investigate whether we can use DDS-XRCE as another framing protocol: https://www.omg.org/spec/DDS-XRCE/

tfoote commented 5 years ago

After some review the XRCE is much more powerful. It brings a much larger set of functionality to the embedded side. It's likely that microROS can provide that eventually. it provides a lot of things like acks for message reception, transport reliability functions. But you also have to have data readers, data writers etc all implemented on the microcontroller side. In the long term adding a ROS 2 abstraction on top of XRCE is likely something that will be possible but in the short term the simpler serial protocol will likely prove effective.