Split itinerary and participant updates

[gbiggs]

New feature implementation

Closes open-rmf/rmf#8.

Implemented feature

Reworks synchronisation between a database and mirrors so that participant information is sent separately from itinerary/route information. This enables scalable synchronisation that is robust to the timing of a mirror joining a query.

This PR is part of a set of three, all of which are needed for this feature.

• This PR, which implements the changes in the ROS 2 communication.
• Split itinerary and participant updates rmf_traffic#14, which implements the changes in the core.
• Split itinerary and participant updates rmf_internal_msgs#6, which implements the new messages required to support the feature.

This PR depends on the PRs that change mirror synchronisation to use a topic, and the PRs that enable updating participant footprints.

Implementation description

A set of new messages have been created for sending participant descriptions via a topic.

The schedule node publishes a topic, /rmf_traffic/participants, which broadcasts all participant information when certain events occur:

• When a new participant registers
• When a participant unregisters
• When a mirror joins a query
• When a manual "send info" request is made

When a mirror receives the set of participants, it refreshes its own list to match.

To account for timing differences in receiving the list of participants and receiving the list of routes, which could mean that routes are received for participants not yet known about, a semi-caching mechanism is added. If a route is received that does not yet have a known participant, it is stored with an empty participant description. When views and snapshots are taken of a timeline, any participants/routes with empty descriptions are ignored (i.e. not given to the view).

When a mirror receives a set of participants, if it finds that a participant already exists it updates the description of that participant to match the newly-received description. A double pointer is used to store descriptions, ensuring that all places referencing the participant's description will receive the updated description immediately. To avoid snapshots having their descriptions changed (snapshots are meant to be immutable), they make a fresh copy of all descriptions when the snapshot is made.

How to test

Launch the office demo world and start a couple of tasks. Rviz should show the visualisation of the scheduled routes. Kill the RMF rviz2 node that is publishing this visualisation; the visualisation will disappear from rviz. Start the RMF rviz2 node again manually, and the schedule visualisation should appear shortly.

Notes for the reviewer

There is a lot of participant updating happening in the rmf_traffic_schedule node. If comments are added to the Mirror::update_participants_info() function, then this sort of output will be seen several times per second:

[rmf_traffic_schedule-1] [Mirror::update_participants_info] **********************
[rmf_traffic_schedule-1] [Mirror::update_participants_info] Replacing participant description 0
[rmf_traffic_schedule-1] [Mirror::update_participants_info] Replacing participant description 1
[rmf_traffic_schedule-1] [Mirror::update_participants_info] ======================
[rmf_traffic_schedule-1] [Mirror::update_participants_info] **********************
[rmf_traffic_schedule-1] [Mirror::update_participants_info] Replacing participant description 0
[rmf_traffic_schedule-1] [Mirror::update_participants_info] Replacing participant description 1
[rmf_traffic_schedule-1] [Mirror::update_participants_info] ======================
[rmf_traffic_schedule-1] [Mirror::update_participants_info] **********************
[rmf_traffic_schedule-1] [Mirror::update_participants_info] Replacing participant description 0
[rmf_traffic_schedule-1] [Mirror::update_participants_info] Replacing participant description 1
[rmf_traffic_schedule-1] [Mirror::update_participants_info] ======================
[rmf_traffic_schedule-1] [Mirror::update_participants_info] **********************
[rmf_traffic_schedule-1] [Mirror::update_participants_info] Replacing participant description 0
[rmf_traffic_schedule-1] [Mirror::update_participants_info] Replacing participant description 1
[rmf_traffic_schedule-1] [Mirror::update_participants_info] ======================

I am not sure why this is happening and if it should be considered a problem or not.

[mxgrey]

This is looking really good. I just have a few relatively minor nitpicks/suggestions/observations.

[mxgrey]

We should probably change this argument to std::optional<uint64_t> minimum_version = std::nullopt, and change the RequestChanges message to have a bool full_update field. If update versions ever overflow (which would admittedly take a very long time with 64 bits), using 0 as the "oldest possible version" won't necessarily work.

[gbiggs]

Fixed in b2643b5.

[mxgrey]

Just one recommendation about the tuple.

[mxgrey]

The changes seem to be working 👍