[Re-write] Free fleet adapter using easy-full-control fleet adapter and zenoh bridges

[aaronchongth]

New feature implementation

A large motivation of this re-write, is to fully utilize the well tested tools already available in the ROS ecosystem and Zenoh, and also take advantage of python bindings as much as possible, to allow for easier iterations, testing and contributions.

The use of Zenoh bridges will hopefully also minimize disruption to any existing robot navigation stack, and can be spun up with just a standalone binary with the appropriate configuration file.

The legacy implementation can still be found at the legacy branch.

• re-implemented free_fleet using easy_full_control, based off the fleet_adapter_template, will allow setting up of perform actions, Support perform_action feature of the fleet adapter #116, [Feature request]: Add /robot_state topic published from free_fleet_server #141
• fleet adapter to use zenoh as the main way of communicating with robots
• change approach to use zenoh-bridge-ros2dds as a drop-in method of bridging required ROS 2 topics and actions between robot and fleet adapter
• supports the nav2 stack with the simple /navigation_to_pose action, ROS 2 navigation stack client #84
• using pycdr2 to serialize and deserialize messages, with required message definitions fleshed out, Question on message generation #129
• examples using existing simulations from nav2_bringup
• updated README, https://github.com/open-rmf/free_fleet/blob/easy-full-control/README.md
• supports Jazzy (other distros not tested yet), What are the plans on moving to humble (Ubuntu 22.04)? #138
• linting, Add style linting #100
• support for ROS 1 navigation stack (tested in simulation only, part of integration tests)

Architecture

This architecture and the use of Zenoh bridges will ideally improve the integration experience, with just setting up the zenoh-bridge-ros2dds and its configuration, instead of building and running a separate node.

This PR does not support the ROS 1 navigation stack, the diagram is just for illustrating the proposed architecture once it is implemented down the road.

Single robot example using official nav2_bringup's tb3_simulation

Two robots example using official nav2_bringup's unique_multi_tb3_simulation

Although the two robot simulation example is just for testing purposes as it uses a different architecture as intended

Single nav1 robot sim using official turtlebot3_gazebo and turtlebot3_navigation

Next TODOs (over subsequent PRs)

• attempt to optimize tf messages (not all are needed)
• map switching support
• docking support
• support for Rolling
• docker images
• releases
• testing and support for other RMW implementations

There are plenty of TODOs left, but this is the bare minimum testable and usable state

[xiyuoh]

After discussing more about the abstract class with Aaron, free fleet seems like a good place to house it since the goal is for a single fleet to integrate with multiple types of robot adapters. It would be extremely useful for future maintainers and community members to contribute their own robot adapters with other nav stacks.

However, since the current iteration of the class is meant for testability and is subjected to change after experimenting with nav1, I suggested it might be more appropriate to flesh out the class methods, and only introduce it after we ensure that there will be no breaking changes (especially with nav1).

Apart from that this PR looks good to me, have tested it out in sim + witnessed the hardware working well with the fleet adapter. Thanks for this massive refactor!

[mxgrey]

-20k net lines of code while also improving capabilities is such a rare treat