In Q4 2022 we attended ROSCON in Kyoto, Japan. We wanted to share our top three learnings with the community, as well as our recommendations for people facing certain situations in robotics.
Learning #1: The transition from ROS 1 to ROS 2 is still a challenge that many organizations are facing.
The majority of ROS-based companies still run on ROS 1, partially because of inertia and partially because the robust plug-in and hardware drivers ecosystem on ROS 1 hasn’t entirely been ported to ROS 2.
Rosbridge is a potential solution for porting ROS 1 packages to ROS 2 incrementally; however, there are three areas where you may run into issues:
- Compatibility: rosbridge may not support all the features and message types in ROS 1 or ROS 2. Which means you will have to make some manual changes.
- Performance: rosbridge may introduce some extra overhead, so in cases where performance is at a premium, it is likely not a viable option.
- Future Support: rosbridge is not a long term solution for migrating from ROS 1 to ROS 2. At some point you may need to fully or partially rebuild your application for ROS 2 in order to take advantage of new features and improvements in ROS 2.
Our recommendations if you’re an organization that is considering switching from ROS 1 to ROS 2
- Come up with an understanding of whether or not rosbridge is a viable temporary solution for you to provide a stopgap while you fully migrate to ROS 2.
- Look at the rosbridge protocol, and see if your message types can work with rosbridge
- Keep in mind that rosbridge can add a lot of latency, so if you’re close to the wire on compute resources, you may have to find another solution
- Estimate the time required to port your application to ROS 2 and estimate your engineering costs.
In the event rosbridge is a viable solution for you, you can essentially add the ROS 2 porting work to a long term roadmap and make the shift on a timeline that is comfortable for your org. Keep in mind that ROS 1 will be supported till 2025.
In the event that rosbridge doesn’t work for you, you’ll have to consider whether upgrading is the right choice based on
- Engineering bandwidth
- Do the packages and plugins you rely on work on ROS 2?
- Do you have ongoing operations that an upgrade may endanger?
In the case where upgrading is not a path forward, we recommend looking into other robotics frameworks that may be able to meet your needs. We mention some other options in the next learning.
For those starting from scratch:
- Unless there is a core ROS 1 package or plugin you desperately need, we recommend all companies starting today build with ROS 2.
The event(s) where we learned this:
Migrating from ROS 1 to ROS 2 - choosing the right bridge (video, slides)
The ROS 2 Developer Experience (video)
Learning #2: Neither ROS 1 nor ROS 2 meet the standards of safety-critical applications, but there are increasing alternatives
Generally, ROS isn’t suitable for safety critical applications because:
- Lack of real-time support: ROS is not an OS, nor does it typically run on a real time OS. It therefore doesn’t guarantee deterministic execution of code. This can make it difficult to use ROS in applications where timing is critical, such as in safety-critical systems.
- Limited Fault Tolerance: ROS does not provide built-in support for fault tolerance or error recovery.
- Lack of certification: ROS has not been certified for use in safety-critical applications, and may not meet requirements in the areas of reliability, and other factors. Efforts like SpaceROS and the work of Apex.ai, aim to chip away at this problem but as of today this problem stands.
If you are building safety critical systems in robotics our recommendations are:
- See if ROS can meet your needs with existing certified frameworks (slide 6)
- If not, consider options like Apex, ARK, AdaCore or Viam - There might also be the possibility of running ROS on top of an real-time OS (RTOS), but we’d consider this an advanced option wherein the guarantees your organization is looking for are simply not achievable with ROS.
- Consider the possibility that you may have to roll your own stack (like many self driving companies have had to). We recommend this option as a dire last resort.
The event(s) where we learned this:
ROS for Mission Critical Applications (video)
Tools and Processes for improving the certifiability of ROS 2 (video, slides)
Learning #3:The software tools ecosystem supporting ROS stacks is early, but growing.
Traditionally, robotics has been hard because at some level you’ve had to do it all yourself. Now, slowly, we’re seeing the rise of tools that allow robotics companies to do two important things:
- Focus on Robotics
- Build robots faster and better
We saw a really great demo of Behaviortree.cpp 4.0, which allows chaining of robot behaviors, from the Picknick team, a great talk on a growing ecosystem of native Rust components working with ROS, and a great talk on a distributed robotics simulator with Unreal engine.
We’re seeing the advancement of current tools like Behaviortree.cpp, the integration of technologies like Rust and Unreal, and the advancement of ROS tooling. While ROS hasn’t quite shed its academic roots, we’re seeing big advancements on the software tools side for ROS to advance practical applications of robotics.
Our recommendations for robotics companies of any stage:
- Take stock of what problems your team is facing on a regular basis
- Pain points
- Where do people in your org spend time?
- Are they spending an appreciable amount of time on tooling and infrastructure as opposed to improving robot functionality? - Try to look at what tools exist to help you
- Conferences are a great source of this - Sometimes it pays to ask the community
- ROS discourse
- ROS Reddit forums - Do a build/buy analysis before taking up any big challenges
The event(s) where we learned this:
Native Rust Components for ROS 2 (video, slides)
BehaviorTree.CPP 4.0 What is New and Roadmap (video, slides)
Distributed Robotics Simulator with Unreal Engine (video, slides)
