ROS Backwards Compatibility in Distributed System

asked 2012-06-27 06:32:18 -0600

thebyohazard
3542 ●52 ●68 ●83

I'm helping to develop an industrial robotics system that uses ROS. The system will be distributed amongst several embedded devices, perhaps some more powerful machines for the complicated algorithms, and a few consoles. The roscore will be running on one of the more powerful machines/consoles.

After we get our system working, we plan to continue improving it, adding more devices as necessary. On the new devices we'll probably want to use the new awesomeFeatureX from the new version of ROS that'll be out then. I don't want to have to update each node on each embedded machine in service because something might break with all those updates, and there's no reason to fix something that isn't broken. It would also be a pain to have two different ROS systems running side by side, and doing so would defeat one of the reasons for using ROS in the first place. On the other hand, the system will have been working and will be depended upon, so we can't break anything by just updating the master, either.

So my question is: what would happen to a working, distributed system if a new ROS version were installed on the machine running the master?

Or basically, what it boils down to is: In the foreseeable future, will communication between a master of the future and nodes of the past still be the same format? Or perhaps devices programmed with new code can communicate with an old master?

Thanks in advance.

edit retag flag offensive close merge delete

add a comment

4

answered 2012-06-27 14:16:52 -0600

tfoote

58457 ●128 ●550 ●526 http://www.ros.org/

The incompatibility is not just about a new version of the master. (So far most releases haven't changed the master). The primary reason for incompatibility of communication between versions of ROS is that the message definitions may have changed. Which is not something which can be trivially fixed. There are bag migration rules which could be applied in a python process and do translations, but maintaining support for arbitrary combinations of versions is a very large burden which we cannot support at the moment.

I would suggest that if you really need newFeatureX in an older platform that you backport newFeatureX to the older platform instead of trying to get both versions to be compatible. If you compile it against the older version of ROS that's great. The farther you diverge for the tested and integrated system the more effort it will require on your part.

Another solution which might be possible would be to create a translation node which can talk to both systems and republish communications from one to another. This might be possible in python with a lot of work, but I wouldn't recommend even trying.