ROS2 Support

[SuedaSen]

Hello, as far as I saw there is no ROS2 support but will it be come? I installed the Vizanti dashboard as ROS2, if this project can be compatible with ROS2, it would be very nice.

[MoffKalast]

Hey, yeah it's definitely on my todo list since it's nigh impossible to make a mesh networked fleet on ROS 1. Vizanti's about 90% there in being ported to ROS 2 (see https://github.com/MoffKalast/vizanti/issues/9), the line_planner is next on the list, then the rest of the dependency packages and then this repo. ETA sometime in the next few months for the whole stack most likely.

[oskarsVismanis]

Hey, I am working on an autonomous boat project at the moment and I found this package very interesting so I am trying to convert some of the stuff to ROS2. At the moment just converting the code to make it functional. I would be happy to contribute if you have any concrete plan. At the moment I am just trying to get the diff_drive_simple and line_planner to work, but still trying to get a grasp on how it's all connected!

[MoffKalast]

Hey @oskarsVismanis, I would love to collaborate if you're up for it. For the rough idea on how it runs I would refer to the readme node schema, and the individual readmes of the packages themselves:

• Line Planner
• Diff Drive Simple
• Navsat Simple

The scripts are generally short so taking a peek at what each one does might clear up some things further.

It is a bit convoluted, so here are some points that might make a few of the odd connections clearer:

• there are no hardware lacks encoders or ways to measure linear odometry, so motor throttle commands are converted into a calibrated velocity estimate to offset the slow update rate of GNSS; kinda hacky but works surprisingly well in practice 😄
• the GNSS heading + IMU gyros give the absolute world rotation
• Vizanti gets TF data from navsat_simple and publishes PoseStamped goals in the received frames (map or world, typically)
• the line_planner then takes TF data and sends out Twist commands to drive the boat
• diff_drive_simple receives those, which contain a forward speed and angular rotation speed, which it then turns into actual diff drive motor rotation speeds for the left and right motor as a JointState (as if it were mixing a joystick axis)
• tuna_motor then turns this into actual PWM signals
• the URDF state publisher uses the joint states to show rotations in Rviz for debugging

---

I'm currently working on a larger platform that will be using the same stack, initially just by forking this repo on Noetic, but for the ROS 2 implementation the plan is roughly as follows:

• separating all actual navigation related nodes into a generic USV navstack repo, leaving only the hardware and URDF stuff for each specific boat in the robot package (i.e. moving out tuna_nav or merging it with navsat_simple)
• just the hardware related nodes in each robot repo
• launching everything fully namespaced, including TF frames, so that it can all work together under the same domain ID and be controlled and recorded together
• setting it all up with batman-adv for mesh networking
• integrating a Luxonis camera with eWaSR for collision detection, then feeding that into Nav2 somehow as a reprojected costmap or obstacle detections

My focus right now is mostly getting the electronics done and tested with Noetic so I can confirm the hardware works, while working on the Vizanti ROS 2 port. Then comes the generalization.

There are few non-ROS2 related things on my to-do list that need attention. I was hoping to get around to patching them before going for a port, but I suppose they could be implemented later if you feel like taking a crack at the port before I get around to it:

line_planner

It currently outputs "rough" data, as in the acceleration and deceleration is instant and it's assumed that the motor node imposes some limitations according to physical reality. On the other hand, doing simple proportional deceleration before a goal is reached without having a PID to match the speed depending on actual movement could make goals unreachable in case of currents or wind, so that's something that needs some serious thought to be implemented robustly and to not introduce some cases that could result in loss of vessel.

The usual final pass of matching the target rotation when goals are reached isn't implemented yet, which is fine for most cases, but in some one would really need it to orient in a specific way. So that would need to be added at some point, along with a a boolean param for driving in reverse. There is also a weird thing where goals sent in odom are ignored (either a bug or a safety thing, I can't recall).

navsat_simple

Currently only sets the map--> odom translational offset and publishes its heading rotation, which is integrated by a separate node that uses that and the imu gyro to get an absolute world rotation that's set in odom. A cleaner setup would be for the imu node to set only the gyro data to the odom rotation and navsat_simple to set the global rotation on top of that, but it's slightly tricky to implement in a consistent way.

---

I'm sure there's a lot that's still unclear, so feel free to ask anything. Overall I think diff_drive_simple is probably the cleanest candidate for a ROS 2 port right now, since it won't need any changes.

[oskarsVismanis]

I have already made a diff_drive_simple ROS2 port, just haven't found a good way to test it yet. For now, I'm just disregarding the dynamic_reconfigure parameters as I'm not really sure how those work in ROS2.

I've also converted theodom_publisher.py from the tuna package, area_to_path.py from line_planner, and I am a bit stuck with the line_planner_node.py. I will try to figure out the line_planner_node.py conversion and study what you've written to understand how it's all connected.

Also, as I understand, the move_base is now included in Nav2 as nav2_bt_navigator ROS to ROS 2 Navigation, so I'm not sure what happens with move_basic or if it's even that important.

[MoffKalast]

Hmm yeah, good point I doubt there's a good way to properly test it out without an actual robot (unless the turtlebot gazebo setup supports setting raw wheel speeds? I'll have to check), but we could add some unit tests that work in noetic, port them over and see if they still work I suppose? It'd be good practice to have some anyway.

For now, I'm just disregarding the dynamic_reconfigure parameters as I'm not really sure how those work in ROS2.

Well the good news is that it's been apparently rolled into the main parameter server, so all nodes are already reconfigurable. I'm not sure what the callback for on-the-fly changes is or if there even is one.

Also, as I understand, the move_base is now included in Nav2 as nav2_bt_navigator ROS to ROS 2 Navigation, so I'm not sure what happens with move_basic or if it's even that important.

Originally move_basic was designed to replace move_base for reliability reasons, which then got replaced by the line_planner here, so no it's no longer used. As it currently stands, conceptually the line_planer stands in for both the nav2_simple_navigator and nav2_dwb_controller, as it handles both Path and PoseStamped messages, but for now assumes the direct path is clear and that the hand made global plan is correct.

As for how collision avoidance plays into this I'm not entirely sure yet. Standard A* avoidance doesn't really take into account stuff like COLREGS or that you really need to get out of the way of that fast approaching speedboat that's out of range of all local costmaps.