Check out the tag 1.3.0, or the legacy branch.

Check if the zenoh messages are going through using the testing scripts in free_fleet_examples. For ROS 2 navigation stacks, make sure that the zenoh-bridge-ros2dds is launched with the same RMW_IMPLEMENTATION and ROS_DOMAIN_ID as the robot's navigation stack, otherwise no messages will be passed through the bridge.

This may be due to using outdated rmf_fleet_adapter_python released binaries, either perform a sudo apt update && sudo apt upgrade, or build RMF from source following the official guide.

Try ros2 deamon stop, ros2 daemon start, or explicitly kill the ros and gazebo processes, or restart your machine. It's been noticed that if the ROS 2 or gazebo process are not terminated properly (happens rarely), the network traffic between the simulation robots and the fleet adapter get affected.

Check out the integration tests docker compose, as well as the simulation and bringup docker files, for any missing dependencies.

This is because it is on a different ROS_DOMAIN_ID than the simulation, therefore it will not have access to the simulation clock topic, the examples running RMF, free_fleet_adapter and the tasks will not be using sim time.

Especially during multirobot sim example, spinning up a dedicated zenoh router and routing the zenoh-bridge-ros2dds manually to it, could help alleviate such issues.

Make sure the versions between the eclipse-zenoh in pip, zenoh-bridge-ros2dds and zenohd are all the same. If the debian binary releases of zenohd have breaking changes, and the repo has not yet migrate to the newer version, please open an issue ticket and we will look into migrating as soon as possible. In the meantime, using an older standalone release of zenohd would be a temporary workaround. Our integration tests will attempt to catch these breaking changes too.

This is most likely due to the rest-http-port which uses port 8000 by default, and might cause a conflict with other systems, for example rmf-web's API server. Run zenohd --rest-http-port 8001 to change it to 8001 or anything else.

This is by-design, as custom actions are often interacting with other systems or humans, and therefore the only safe way for an action to be properly terminated, would be an intervention, or waiting until the action times out, completes or fails, reporting the result back to RMF before RMF cancels the ongoing task.

This list is by no means exhaustive. Please also check past or existing issues on this repository, or any discussions on the main RMF discussion page.