We're been hard at work at 3DR on system architecture and looking into new ways of building adaptable UAV systems.
Solo in particular leverages a number of distributed systems--vehicle, controller, and app--that continue to enable industry-leading flight autonomy--smart shots, and now the shot modes on etc. The complexity of UAV systems is only increasing, and handling messaging and data distribution between these systems in a reliable, high performance way is a complicated challenge.
After evaluating a number of options, we have selected eProsima Fast RTPS, a messaging middleware developed by eProsima, to power system-level messaging and data distribution on our future platforms. Fast RTPS is an open-source implementation of the RTPS standard. RTPS (Real Time Publish Subscribe) comprises the transport layer of the DDS standard developed and maintained by the Object Management Group.
We selected eProsima Fast RTPS over other available implementations for a number of reasons. Fast RTPS is feature complete, providing support for many of the advanced features available in RTPS that we’re excited about. Given our history of contributing to and supporting open source projects, Fast RTPS being open source was another compelling factor for us. Finally, Fast RTPS is also more approachable than other options we evaluated, increasing our confidence that we could make any necessary modifications and contribute fixes back upstream.
In connection with 3DR’s adoption of Fast RTPS, eProsima intends to join the Dronecode foundation to encourage further adoption of Fast RTPS. We’re also happy to announce that upcoming licensing modifications will enable Fast RTPS to be distributed on mobile platforms. Although Fast RTPS is currently licensed under the LGPLv3, eProsima plans to provide an alternative license for Fast RTPS, enabling use of Fast RTPS under MPLv2, a license developed by the Mozilla Foundation. MPLv2 retains many attributes of LGPLv3 while allowing users to embed Fast RTPS in mobile applications.
3DR is not alone in the decision to use RTPS for data distribution on complex robotics platforms. The Open Source Robotics Foundation, developers of the ROS and ROS2 operating system, have also decided to use RTPS to power future systems. To further facilitate adoption and use of Fast RTPS, eProsima offers options for commercial support and development for companies seeking to use Fast RTPS in their platforms.
Looking for more information? Fast RTPS is available on Github and you can download from eProsima web site the latest binaries. Discussions about Fast RTPS (and RTPS generally) have already started in the Dronecode forums.
More about eProsima...
eProsima, The Middleware Experts, is a company focused on High Performance networking middleware. eProsima provides insight to develop your distributed systems recommending the right middleware products and supporting you in all the stages of the development.
Comments
Hi Bill,
Not sure if there's a specific timeline for Tully's work. My sense is that he's submitted it out for feedback, but has perhaps not yet established a process for getting it signed off on, or even necessarily determined who should sign off on it, etc. Might be worth either chiming in on ros-sig-mav or bringing it up for discussion on discuss.dronecode.org.
In terms of RTPS integration to autopilots like APM and PX4, I think there's a continuum. On one end, the integration can happen externally, and an RTPS system can be connected to the onboard messaging system by a bridge that can translate bidirectionally between both. To integrate more deeply into APM, we could explore the possibility of abstracting the usage of mavlink as an interface to the outside world to allow for alternate implementations (I'm sure there are other approaches that would work as well). To integrate more deeply with PX4, we could potentially create an rtps module that sits at a sibling level to the existing mavlink module - both communicate with the system internally via uorb.
Please let me know if that doesn't get at what you had in mind - happy to provide any details I can.
@Liam Do you have a response to the above question as well? Thx
I'm not sure who this is targetted at, so please feel free to ignore this
My current use case would be to send position info from a plane to an antenna tracker. The spec was that the message should be transferred at minimum 5 times per second on a 1200 baud connection.( I have much more banwidth but this allows for audio FSK as a transmission method) I reckon that left me around 23 bytes for the entire encapsulated message. For my use case Reliable position information is critical but picometer(or beyond not sure what accuracy a float64 has?) accuracy and the rest not so much. Clearly the ROS NavSatFix message is not a contender for my use case :) So if anyone says "Why are you reinventing the wheel? " .. This is why :)
regards
Andy
Interoperability of the protocol layer is one aspect, but the real challenge for inter-op is based around the message definitions, and the sub protocols for missions and parameter settings. RTSP kind of covers the TCP part of the transaction and not the data being sent.
I did take a look at what Tully has been losing into, the key for an implementation is to have an initial spec laid down. Is there a timeline for that?
@James - yes, that is one motivator for updating the licensing terms of Fast-RTPS. eProsima can speak more directly to their goals, but they already had a static link exception to their LGPL licensing approach, and were interested in standardizing that and allowing for broader distribution.
@Bill - agreed, one discussion we've been following is one that Tully at OSRF has been spearheading to define a standard message set for aerial vehicles: https://groups.google.com/forum/#!topic/ros-sig-mav/f12m3mnqYl4
In terms of conformance, I'm not aware of a specific test suite that validates it, but it is tested for interoperability with several of the other available implementations. eProsima can likely provide more detail on that front.
OSRF have also been working on an implementation that can run on cortex-M4 class devices: https://github.com/ros2/freertps. Our primary use case for it is on network-enabled embedded Linux class devices, but smaller platforms can be supported as well.
how to implement on the embeded microcontroller such as stm32F4 series?
what is the difference between the fastRTPS and pixhawk uORB P/S mechanis?
what is the relationship and affection to MAVLINK protocol?
The challenge for using FastRTPS in whether this will make a good addition to DroneCode protocol suite is how the process goes for specifying the messages that are sent using the this new mechanism. The biggest challenges for MAVLink has been the interpretation of the intent of each message and its fields.
What's a time line for the a proposed set of message. Will this new RTPS library be supplied with a conformance test suite to help validate compliance?
Another question is how low bandwidth connections are handled with FastRTPS. This is directly dependent on message sizes. How much over head does the protocol add to transfers?
A final question, is how does 3DR choosing RTPS effect the OSS community created Autopilots? what's the overall strategy in adopting this into the ecosystem? What's the motivator to add FastRTSP to ArduPilot or PX4? How does adding to the products gain leverage into up and coming 3DR roadmap autopilots?
Thanks
definitely right selection and correct decision for the mobile network robot applilcation.
The eProsima guys are doing a great job pushing their FastRTPS implementation. Well done Brandon and 3DR team, this definitely will put the 3DR and the ROS community closer together!
Cheers