Hi everyone,
This might make some people cringe, but let’s face it – you have a lot of ROS1 code and you aren’t switching to ROS2 yet because you have to rewrite a LOT of nodes.
So I wrote a legacy interface that behaves like rospy but speaks ROS2 behind the curtain. This is very different from a ROS1/ROS2 bridge in that you don’t need to run a ROS1 master at all.
The idea is to be able to take any ROS1 node, replace import rospy
with import rospy2 as rospy
and BAM it should work on ROS2.
This is far from complete but here’s an initial effort with a test node.
Feedback and contributions welcome!
Before continuing with this, I’m also trying to gauge interest as to:
(0) How many people would actually use something like this, if it was more fully-fledged?
(1) What ROS1 features do you absolutely need that this doesn’t yet support?
(2) Is there strong interest in a C++ version of this? Minding of course that it might be much harder to build a C++ equivalent considering that I’ve hugely abused Python’s lack of strong typing to make this work.
I’m not sure why you edited the title to include cringe; there’s nothing really wrong with doing this and it seems quite useful, if only for the fact it essentially provides an executable migration guide.
In the form of a document, this would show snippets of code (like a cookbook). That would already be great, as it would answer many questions of the form “in ROS 1 we did X, how do I do X in ROS 2?”
This just takes it one step further. If done well, that’s a valuable resource to make available
(it might not always show the best possible or most efficient way to approach such a migration, but it could still provide a good first stepping stone in migrating code)
I’ll take a stab at it when I get a chance. I’m wondering if anyone knows what the deprecation schedule for ConstPtr is? e.g. from /opt/ros/galactic/include/std_msgs/msg /detail/string__struct.hpp:
Having access to these ConstPtr might be perhaps critical to making a C++ equivalent work.
Writing something that occuies the ros:: namespace and provides ros::NodeHandle, ros::Publisher, etc. is easy, since it doesn’t conflict with ROS2’s rclcpp:: namespace, and ros:: can contain a bunch of proxy objects of sorts that behave like roscpp and speak rclcpp:: behind the curtain.
But the message callbacks in existing code are all going to be void some_callback(const std_msgs::String::ConstPtr& msg) { ... }