Draft: Galactic-Devel (Help wanted)

[relffok]

Hi there, I have started porting this package to ROS2 galactic a while ago. It was a lot of effort so far and there is still heaps to do. I wanted to get further in the development before opening a PR but because of the lack of time I am guessing it would be easiest to all work together (hopefully) on this one to move along. And finally be able to use ROS2 for all the MiR platforms.

It is still pretty rudimentary, but the simulation and driver work together with our MiR100 platform and it is great to be able to use ROS2 package once the driver connection is up and running.

Overview:

• mir description: ported
• mir_driver: supports the laser_scans, cmd_vel, odom and tf so far. Since I didn't need the other topics, I have commented them out. (ROS1 to ROS2 msg require some dict filter, but that shouldn't be a big effort to implement for most topics) This was the biggest chunk to be solved, I ended up porting rospy_msg_converter to ROS2 (rclpy_msg_converter) as well. Will link the PR here shortly.
• mir_gazebo: simulation is up and running
• mir_navigation: mapping + navigation ported using slam_toolbox and nav2 (which is great) but there is still a lot of parameter tuning to be done (mostly waiting on 1.0.8 release right now)

Some issues to point out:

• Separate laserscans: The laserscans are the most important part in mapping, localization and mapping and we have two separate scans (front and back). In comparison to ROS1 the slam and nav nodes require the scan to be merged and not only be passed alternately to the same topic. So I needed to merge those (using another package I ported) from laserscan to pointcloud then merge the clouds and then convert it back to a single laserscan. At that time I could not find a better solution, if somebody else can point out anything, I'd be happy to review that.
• Known Bug: Gazebo simulated Laserscans drift away from time to time (before merging in a pointcloud). This seems to be an issue in the urdf configuration, but I haven't had the time to track it down. https://github.com/relffok/mir_robot/issues/1
• Missing namespace support: While porting I missed to drag the namespace everywhere (I also felt like there is an ongoing discussion about namespaces in lots of ros2 pkg), but this will also be added some time soon https://github.com/relffok/mir_robot/issues/2

To sum up, it is useable for a few tasks, but there is still lots of things to do and bugs to remove. Help wanted and appreciated!

[mintar]

Thanks a lot for all this work! I'll review it as soon as possible (I'm pretty swamped with work right now). Just a quick comment on one of your points:

Separate laserscans: The laserscans are the most important part in mapping, localization and mapping and we have two separate scans (front and back). In comparison to ROS1 the slam and nav nodes require the scan to be merged and not only be passed alternately to the same topic. So I needed to merge those (using another package I ported) from laserscan to pointcloud then merge the clouds and then convert it back to a single laserscan. At that time I could not find a better solution, if somebody else can point out anything, I'd be happy to review that.

This is really unfortunate. The problem with merging the laserscans like that is that you lose the information which frame a particular point was recorded from. At least in mapping and navigation there's some ray tracing going on between the sensor frame and the point (to determine free space), so that'll probably be a problem. Perhaps for pure localization it's going to work.

I remember having to do the same hack because gmapping in ROS1 also doesn't support multiple laser scanners, but it didn't produce good results, so I switched to hector_mapping instead (which supports multiple laser scanners).

[relffok]

Thanks a lot for all this work! I'll review it as soon as possible (I'm pretty swamped with work right now).

Thank you. I'm looking forward to get this one fully ported!

This is really unfortunate. The problem with merging the laserscans like that is that you lose the information which frame a particular point was recorded from. At least in mapping and navigation there's some ray tracing going on between the sensor frame and the point (to determine free space), so that'll probably be a problem. Perhaps for pure localization it's going to work.

I used it on MiR for mapping and navigation and also SLAM with a what I called virtual_laser_link (which I placed in the middle of the robot platform) and I didn't run into any issues. But maybe I am overlooking something here and you'll find something explicit to show me once you tested it.

[mintar]

@ros-pull-request-builder retest this please

[mintar]

That doesn't seem to have worked. Closing and reopening to trigger retesting.