Hello again TSC,
In addition to our investigations into message delivery (see here), we’ve been looking into message definition options. We see these as distinct concerns and, as such, an opportunity to establish compatibility.
We view the breakdown roughly as follows:
Based on our experience, the most valuable features are:
- good language/platform support, actively developed
- possible to use same message format for the entire system
- on vehicle
- mobile apps
- ideally, on embedded devices
- good performance, both in terms of serialized size and serialization performance
- easy to add new message types
- expressive - supports complex data types (structures, variable length arrays, etc)
- ability to evolve a message definition while maintaining backwards compatibility
This list is most certainly not exhaustive, but represents the options we’ve selected for our short list.
This table provides a comparison of the options on our short list, please take a look.
Our current preference, echoed on the mavlink v2_playground repo, is to use cap’n proto. It represents the next generation of message definition/serialization systems, as it’s designed by the original author of protocol buffers. It has good platform support, is well documented, and performs well in the environments that we’re interested in.
We’d love to get feedback from everyone on what we haven’t considered, to understand whether cap'n proto is a viable option, and who is interested in collaborating with us on it.
Specifically, I imagine that we’d work to identify common message definitions (possibly porting/adapting existing mavlink messages), help fill any tooling gaps in terms of code generator workflows, and help establish interoperability among different platforms.
We’d like to make a decision as soon as possible at 3DR on which format to go with. Our strong preference is to go in a direction that has support in the Dronecode community, so we’d love to hear your feedback, questions & suggestions. Thanks!