ROS2 port in progress - was: use of ros::time vs std::chrono

[BrettRD]

I'm working on a ros2 port, and I'm seeing a lot of files that only depend on ROS for its time class.

I really appreciate how Fuse is built as a standalone algorithm with clearly defined bindings for ROS, and I think this can go a little deeper.

I have a multi-agent application where no system has access to an accurate time, so I need to use the optimiser to establish relationships between clocks.

Is a switch from ros::time to std::chrono something that you would like back-ported?

[svwilliams]

I'd consider it. I'd just want to make sure I understand the ramifications for API compatibility. If you can point me at a branch with the time changes in it (either ROS1 or ROS2), I'll take a look.

[BrettRD]

I'm still figuring out the ramifications, I think the biggest deviation will be the way timestamps are packed for uuid generation. (I think boost::serialise has builtins for std::chrono)

I'll be posting here when it happens:
https://github.com/BrettRD/fuse/tree/galactic

I don't think my multiple-clocks thing will appear in the core api at all; in the extreme case I might make a plugin to override TimstampManager, but I doubt I'll need precise history windowing.

[SteveMacenski]

@BrettRD how far are you on a ROS 2 port? I'm starting to make plans for 2022 and wondering if I could assume this was going to be available in ROS 2 cira-March timeframe? We're looking for a robot_localization replacement in the Nav2 stack since Tom nor I have had a great deal of time to maintain it. It's better to use something newer and that the core maintaining company actually uses in production to keep up with it.

I think I could also dedicate some resources to helping with the ROS 2 migration.

@svwilliams a concern I have is around maintenance. Do you have a plan (or could create a plan) in order to keep ROS 1and ROS 2 in sync (e.g. requirements that PRs have both counterparts). It would be important to use in the Nav2 community that these don't get critically out of sync (for instance like grid_maps is, which has prevented us from replacing costmap_2d for the immediate future).

[BrettRD]

@SteveMacenski I have fuse_msgs and most of fuse_core building under galactic, barring parameter server stuff and whatever pub/sub operations I could isolate.
fuse_constraints, fuse_variables , fuse_graphs, fuse_loss need only trivial changes
fuse_models, fuse_optimizers, and fuse_publishers need regular node translation and parameter handling changes.

The major sticking point (as @svwilliams mentioned elsewhere) is the route used to shim a callback into the ROS spin thread.
It's used in three main places, and rclcpp doesn't provide anything like it (yet, planned since 2018).
There are a number of ways of dealing with it, but precious few of them seem sane, safe, or maintainable.

I'm doing this as a hobby at the moment, I'd love to be able to focus on it.

[svwilliams]

The AsyncXXX base classes were intended to make it easier for external developers to create sensors and motion models. The design did two things:

1. It hide the threading details so a new developer didn't need to know the minutia of what threads in the optimizer were calling which methods.
2. It makes a sensor or motion model behave similar to a standard node or nodelet.

However, these classes are not strictly necessary. One option is to remove them entirely and construct all of the motion models, sensor models, and publishers on top of the non-async base classes instead (fuse_core::MotionModel, fuse_core::SensorModel, and fuse_core::Publisher). It will just require more care and attention to precise which thread is doing what.

Another possibility (which I'm not sure I like) is to build the async base classes using a different event loop. For example, Boost ASIO allows you to easily create a thread pool of N threads, and post arbitrary function calls to be executed. Assuming ROS2 has some equivalent of ros::spin_once(), the ROS callback queue could be serviced from within the ASIO thread pool as well. This would achieve a very similar result -- all ROS callbacks and derived Fuse methods would execute within a single thread.

I'm completely open to other ideas. Those are just my first thoughts.

[BrettRD]

Just last night I found this:
https://answers.ros.org/question/322815/ros2-how-to-create-custom-waitable/
which should allow me to make something functionally equivalent to callback_wrapper.h and get on with the port.

I do like the async publisher concept, I've turned them off in the build so I could focus on the nuts and bolts, but I intend to get them going again when I get up to converting node handles etc
I think ditching the callback queue interaction would require a different (or additional) event loop almost everywhere.
rclpp does seem to be committed to allowing custom callbacks to be inserted into CallbackGroups like ros.h does, it's just not on the priority list.

rclcpp has some great features for multi-threading within a node, but leaning on those might force a divergence between code bases.
I'm all in favour of the compact node-like threading model you have already, and extending that with the ros components system requires that it supports a plain spin().

[ayrton04]

I started down this path independently (and also found that Waitables could solve the callback queue manipulation issue), but I don't want to duplicate effort. What's the status of your effort, @BrettRD?

[BrettRD]

@ayrton04 it's good to see someone else on the effort

I have it building up to and including fuse constraints and fuse variables, I'm most of the way through fuse graph.
I might draw a dependency diagram for the docs

I'm looking forward to reading your take on waitables, I think my callback wrapper is ok, but I've only seen one other example online

I'll have a look at your commits today and see what I can merge, a brief glance seems like we're focusing on different things

[BrettRD]

There are a few differences of approach, and you've found some APIs that I missed

I need to pick up your ros_console patch.

I made node-like classes such as the optimizers inherit Node directly, this makes ROS2 threading easier to configure, and might allow interaction with composable_nodes later on
I haven't done much to the node-like classes from fuse_core, they seemed like they could wait. I should be able to merge yours in pretty cleanly.

I approached ceres parameters from the optimiser side where it was difficult to pass the Node to the param helpers, so I'm passing the NodeParametersInterface and collecting the params on that
I had a go at the structure of some of the parameter files, the forward declarations and per-node name-spacing did require a few changes to how the parameters would be arranged.
I was planning on adding an on-param-change callback when I ported the parameter helpers, but I think I'll merge yours and back-log dynamic parameters for now

Your CallbackWrapper seems to be blocking by default, this is likely to slow down the sensor_models passing measurements to the optimiser, you might like to pick up mine.
I've added a CallbackAdapter class to implement Waitable and host a queue of CallbackWrappers more like the ROS1 callback_queue does. non-blocking example
CallbackAdapter can be initialised in a parent class constructor such as optimizer

I've also tried to reduce the total ROS dependencies across Fuse; A lot of Fuse seems like it could be built to run ROS1 and ROS2 sensor_models at the same time.

I made a lot of my changes while still trying to learn how Fuse hangs together, so a lot of it reads like scattered proof-of-concept rather than planned systematic changes.
I know what I'm doing now, and I'm expecting to have a lot more time to commit to this starting next month

[ayrton04]

@BrettRD would it make sense to:

• Make you a collaborator on fuse
• Rename my ros2 branch to something else
• Make your code the ros2 branch
• cherry-pick any changes of value from my branch to yours
• Delete my branch

And then we can all work together?

[BrettRD]

I think those things make sense,

I prefer the branch name to refer to a particular ROS2 version until we can get osrf matrix build tests running
I have at least one project where I maintain an upstream commit for a back-port to Dashing

I'll keep my fork open until I can clear out my issue tracker

[ayrton04]

OK, I've been working off of rolling. We can either finish the migration against that and then see how far back the API is supported and make branches accordingly, or we can target a specific release for our migration and work from that. If we go that route, though, I'd suggest something like Galactic.

@svwilliams, thoughts?

[svwilliams]

It sounds like targeting rolling is the suggested method:

Since new stable distributions will be created from snapshots of the Rolling distribution, package maintainers who want to make their packages available in future ROS 2 distributions can do so by releasing their packages into the Rolling distribution.

But I'm a little concerned that the constant churn of the rolling release would get in the way of doing the port. I'm inclined to target the port for galactic or humble (allegedly being released today), and then transition that code to the rolling release.

[ayrton04]

Seconded.