I wanted to follow up on some of the previous comments with our experiences and plans for the transition.
HXR is a startup currently working on installlation / deployment automation tools for ROS2 based on some of our previous work building USB/ISO installers for ROS1.
ROS1 is OK (for some use cases)
Aside from academic projects and contributing to the occasional art project, members of the team have worked on two commercial projects with ROS1 with experiences worth highlighting.
We avoided the safety issues on one project by selling TurtleBots primarily to academics & researchers and for the other project, the end product was the data produced by the system not the system itself. We have generally avoided real-time issues by avoiding safety issues.
Instead of lifecycle management, we were able to improve reliability for a ROS1 based system by implementing watchdogs that could trigger a node reset if the diagnostics threw an error and a hardware reset if a node failed to produce data within n seconds of starting. In our experience much of the core ROS1 code has been very robust and I think there have been many valuable lessons learned getting it to where it is now, hopefully they won’t be forgotten.
We “implemented” QoS on ROS1 by using 2 quad-port gigabit Ethernet cards that had backplanes that could support all ports at full speed. This prevented an array of hardware synchronized GigE Vision cameras from crashing the network every 30th of a second. I imagine actual QoS is required for an office full of people trying to teleop into the same robot at the same time.
Historically, we tried to do what we could for security on the TurtleBot2 by having
roscore running as user ‘ros’, making this user part of group ‘video’, writing udev rules to provide access, etc. This approach has had some usability and functionality issues particularly with nodelets. The best option has been to avoid connecting ROS1 to the Internet at all. ROS2 looks to solve many of the security issues from ROS1 at the obvious cost of complexity. We hope to help with usability here.
Nodelets mostly work, except when they don’t. Be lucky, don’t try to chain too many filters with nodelets.
IIRC, services on ROS1 under some conditions could block the entire node. Don’t use services or be lucky.
ROS2 or bust
ROS2 Bouncy lacks support for two of the most important features; rosbags and diagnostics. The bagging infrastructure cuts development time spent chasing stupid software bugs. Diagnostics help cut development time chasing stupid hardware bugs. ROS2 development will be slower than it needs to be until these features land, hopefully in Crystal. We expect to see a significant increase in external contributions to ROS2 once this happens.
For many new robotics startups, ROS1 is not an option. It lacks critical features for most use cases and it is going to be hard to sell ROS1 to the management/board when ROS2 is in “beta”. Also, startups that just got funding will have about 18 months to deliver something with ROS2, because VCs will demand results. Having the bridge is nice, but it still requires some investment in ROS1 that I believe many without existing ROS1 codebases / experience would rather put into ROS2.
PhDs want to graduate in a few years and get jobs knowing the latest technology not something that was just obsoleted, and there are easy ROS2 papers out there waiting to be written. My gut says hobbyists will switch to ROS2 once some documentation/tutorials are written just to keep up with the latest technology.
I have heard people say that ROS1 has a learning cliff, however ROS2 currently has a learning asymptote, some of the code doesn’t even exist yet. If we can get past that I believe people will port legacy systems from ROS1 and we will avoid a fork.
While ROS2 is not currently production ready, I think much of the complexity with QoS and Lifecycle will get worked out, documented and simplified in the same way catkin improved quickly after it’s initial release. Is anyone still using
rosbuild at this point? I’m much more concerned about where ROS2 will be in a year rather than where it is now. ROS2 documentation will improve.
I think our biggest concern with ROS2 at this point is that some of the more common dependencies (pcl, diagnostics, etc) will get a direct port instead of the refactoring/redesign they really need. Then we will hypothetically end up with something like diagnostics2 in ROS2.1 and some of the initial development efforts will be wasted. However, it probably isn’t the worst thing if it gets more people using ROS2.
Despite the current state of ROS2, we have no plans to actively support ROS1 moving forward. Our team is currently working on our devops infrastructure for ROS2 and helping out where we can with development. We also plan to offer ROS2 porting/driver development as a consulting service soon.