ROS2 Driver Development

[Joshua Whitley]

Outside of my day job, I've gotten started creating ROS2 versions of some of my company's drivers. I would like to start to do the same for the drivers in this group. However, I want to discuss with you all how we should go about this. Should we:

1. Create a new repo for each driver with a different name (e.g. prefixed with ros2_) but keep the package names the same?
2. Create a new organization (e.g. ros2-drivers)?
3. Create a branch on each of the existing repos for each release of ROS2?

Thoughts? Have you seen this being done already?

Thanks,

Josh Whitley

AutonomouStuff

[Chad Rockey]

I've been trying to wait and see what other repos end up doing, has there been a consensus on what is the least painful way to migrate?

My understanding is that ROS2 isn't immediately replacing ROS1, so there will need to be an overlapping period of support.

I've always tried to advocate ROS drivers being in a format where there's a wrapper around a ROS agnostic core library (even if it uses the ROS generated headers).  Does the ament system support catkin packages as dependencies?  Is it possible to use one CMakeLists and build a different wrapper depending on the build system in use?

My motivation is to avoid having duplicated labor and keep the "core driver libraries" consistent and up-to-date - many people use them as starting points without ROS as well.

My quick uneducated opinion:

1) Might work, but I feel Github organizations have too many repos as it is, so they are hard to find.

2) This is the least desirable for me as it duplicates teams and maintainers.

3) If it's not possible to co-exist in the same branch, then this is preferable if it's what other packages are doing.

-----

On a related note, does anyone know if the message format is changing significantly?  Are the message specification formats going to be different?

If the messages need redone, it may be the best opportunity to remove some of the growing pains the sensor_msgs have experienced.

I know that LaserScan has redundancy (it has angle_min, angle_increment, number of beams, and angle_max).

Many people have told me they regret that Image and CameraInfo are separated and require complicated pipelines to bring together.

IMU also had issues as it lacks Magnetic Field, and is the only message capable of publishing acceleration data or angular velocity data.

If we've missed the boat or the message format doesn't change significantly, it's not a huge loss, I'm just curious.

- Chad

--
You received this message because you are subscribed to the Google Groups "ROS Drivers Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-drivers+unsubscribe@googlegroups.com.
To post to this group, send email to ros-sig-drivers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/38829c20-1865-43f9-a10d-4d4431302f50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Joshua Whitley]

The format is not changing significantly. There are much stricter formatting guidelines (naming, capitalization, etc.) and namespacing is more strictly enforced but they are still .msg and .srv files with the same basic structure.

That doesn't mean that this isn't a decent opportunity to make some needed changes. We're essentially starting from scratch because (to answer your other question), ament does not allow catkin as a sub-project. They are separate build structures (though ROS2 does support catkin and ament - ament is the recommended build system).

I completely agree with the structural recommendation (middleware-agnostic core and a ROS-specific wrapper) but many of the drivers aren't currently written that way. Do you think we want to take this opportunity to do so? IMO, ROS2 kinds of lends itself to this more readily since the node should be an inherited class from rclcpp::Node or rclpy::Node which can be easily logically separated from your processing code in another class.

To reply to your replies regarding the 3 options:

1. I agree.
2. Since the source code for the projects cannot live "side-by-side" or be developed along even similar paths (ROS2 requires at least C++11 and many of the drivers here still contain C code), I would actually favor this, even though the user management is a little more cumbersome.
3. The code is going to diverge significantly from the existing code for almost all of the repos here. Unless we intend to do significant overhauls on the next release of the ROS1 versions of the drivers to make them more similar in structure to the ROS2 versions, I would say this doesn't make a lot of sense. Forking from the existing ones to new repos makes a lot of sense, though.

Regarding other repos, I have not seen hardly any conversions yet. I think we're mostly treading on new ground.

Thanks,

Josh

To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-drive...@googlegroups.com.
To post to this group, send email to ros-sig...@googlegroups.com.

[Joshua Whitley]

Clarification: The message format is not changing significantly.

[Michael Carroll]

The general strategy is to try and do side-by-side when possible.  That's what we are doing with message_filters and image_transport at the moment.  It would be nice to be able to port patches back and forth when possible.

C++11 shouldn't be too much of a stretch for most of the drivers, it makes code cleaner in a lot of places, and allows you to remove the boost dependency.

If message improvements are desired, earlier is always better, but I'm not sure where we stand on that.

To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-drivers/9c485178-5d95-477e-9a01-66cc24d76dcf%40googlegroups.com.