Revision history [back]

I have watched the 2013 ROSCon presentation on how to ROSify robots. Does "ROSify" mean to develop software in the form of packages that can be used on a given robot, sensor or controller? Can this be done for any robot, sensor or controller? Or are there certain products that could never have ROS capabilities?

There are several different levels at which you can ROSify a robot. At the surface level you can always just provide a wrapper which will just expose the internals of the robot's implementation over ROS interfaces. At the other end of the spectrum you can change all of the robots communications to use ROS internally.

This can be done for any robot, sensor, or controller with enough effort. There are some systems that may be too resource limited for a full interface to be integrated onboard. For those devices usually there is a ROS driver that connects to the serial or USB port and interacts with the device using it's protocol and then expose the ROS interface.

The list of ROS-compatible robots from https://robots.ros.org/ seems to be non-exhaustive. What does a company have to do for their products to be ROS-enabled? Is there a difference between being ROS-enabled and having ROS packages available?

The index at http://robots.ros.org is definitely non-exhaustive. It relies on user and devloper submissions. If there is a robot that's using ROS I'd encourage anyone to encourage manufacturers to submit their robots. There's a contributing guide here: https://robots.ros.org/contributing/ If you have a ROS interface that's enough to be consider ROS enabled.

The https://robots.ros.org index is a good place for people to market research and educational robots with a public ROS API. It is not great at capturing the many robots that are now using ROS under the hood but don't publicly mention that they're using ROS or keep it secret that they're using ROS.