Rospy2: A cringe-worthy ROS1-like interface for ROS2

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.

Thanks!

9 Likes

This can be a nightmare when reading someone else’s code, akin to getting fake transparent images in search :joy:

2 Likes

I would use this.

Desires (looks like most things already available):

  • params
  • pubsub
  • services
  • rospy-like threading (each Subscriber on its own thread)

Some interest in C++ version but mostly interested in Python because it seems like the lower-hanging fruit for this kind of portability lib.

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 :+1:

(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)

5 Likes

It could be great to have a C++ version of this!

1 Like

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:

  typedef DEPRECATED__std_msgs__msg__String
    std::shared_ptr<std_msgs::msg::String_<ContainerAllocator> const>
    ConstPtr;

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) { ... }