[dronecode-tsc] messaging structure

Liam Staskawicz liam at 3drobotics.com
Fri Aug 14 21:27:15 UTC 2015


Greetings,

After launching Solo, we've been doing a bit of a system review at 3DR,
looking for opportunities to improve what we ended up with. One of the most
consistent issues that came up was the messaging infrastructure within the
system.

I'd like to share some of our pain points, and a few ideas we have for the
characteristics of a system that might help improve upon them. Comments and
discussion very welcome.

Sorry in advance for what turned into a long message!

*Rough System Layout*

   - Pixhawk 2, connected via uart to a Linux-class companion computer that
   provides WiFi connectivity and an application runtime
   - a variety of onboard devices (ESCs, GPS, IMUs, etc) connected to the
   Pixhawk
   - a handset/controller, with a matching Linux-class, WiFi enabled
   processor (which serves as the access point), connected to an STM32 that
   interfaces to the user via sticks, LCD, buttons, haptic feedback, etc
   - one or more mobile devices (iOS or Android typically)
   - a gimbal, connected both to the Pixhawk and a camera - video stream
   comes from the camera, and gimbal speaks an i2c cmd/ctrl protocol with it
   - external accessories, connected via USB and/or CAN

*Pain Points*

difficult to create new mavlink msgs (8-bit namespace)

   - leads to ad hoc creation of alternate msg formats in order to get
   things done (bad)
   - means there's not a single msg format used through all parts of the
   system (also bad)

(backwards) compatibility not well supported/specified

   - many independent components moving independently (and quickly!), but
   mavlink msg defs must be *exactly* the same for 2 peers
      - preferable to allow for msg defs to evolve (at least additively)
      without breaking compatibility
   - semantics of compatibility not clear without consulting generator
   implementation, ie “which changes to the msg def cause the wire
   representation to change?”

insufficient reliability/delivery semantics & performance on network
transports

   - UDP is usually OK for sending a stream of unreliable data (telem,
   video)
      - though, how to prioritize multiple streams as link quality
      decreases, e.g. RC vs. video?
   - there's not a good way to reliably send commands/events
      - mavlink-level ACKs are not quite right, since a mavlink receiver
      does not distinguish between an initial msg and retries of that
msg. can be
      ok for idempotent commands, but not for others like events.
      - tcp is often not what we want:
         - retry strategy can be higher latency than alternate solutions
         (ie, reliable UDP style protocols)
         - always pay for in-order delivery even if it is not required
         - difficult to interleave logical streams - head-of-line blocking
         can mean that other stream traffic is delayed
         - does not always play well with other traffic (UDP, etc) on the
         link

not able to easily discover devices/services on the system

   - requires more explicit coordination & tighter coupling
   - makes it more difficult to understand how new functionality properly
   fits in to the rest of the system

not possible/easy to specify in a fine grained way which traffic (on a
per-msg basis) should go to a given client at which rates

*Some (Possibly) Ideal Features*

dynamic discovery of devices on the system

   - implies arrival/departure/presence info
   - must support non-networked devices (possibly via proxy on the
   networked devices that they're connected to)
   - question: is device discovery enough, or do we actually want
   feature/service discovery as well?

network transport that provides lighter weight reliable message delivery

   - have looked a bit into a few protocols that build reliability/quality
   of service on UDP, some interesting options though haven't found a
   no-brainer solution

message format

   - ease creation of new message types
   - provide support for compatibility between devices with slightly
   different msg defs
   - rely on transport layer for framing & msg integrity
   - basics (duh): fast to encode/decode, compact wire format, don't
   reinvent the wheel

These are issues we hope to address in future revisions of our system, and
to the extent that these concerns are more universal, it would be great to
establish some strategies that address them.

Thanks for any feedback.

Best,
Liam
-- 
http://3drobotics.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dronecode.org/pipermail/dronecode-tsc/attachments/20150814/02bbdd66/attachment.html>


More information about the dronecode-tsc mailing list