fleet_adapter_mir

MiR100, 200 and 250 using the https://github.com/open-rmf/rmf_ros2/tree/main/rmf_fleet_adapter_python

Pre-Requisites

• ROS 2 (Foxy onwards)
• open-rmf (source build recommended)

Installation

If a source build of open-rmf is used, source the built workspace as an underlay, and build a new workspace with this repository.

# Create the MiR workspace and clone the repository
mkdir -p ~/mir_ws/src
cd ~/mir_ws/src
git clone https://github.com/osrf/fleet_adapter_mir

# Source the Open-RMF underlay workspace and build
source ~/rmf_ws/install/setup.bash
cd ~/mir_ws
colcon build

Description

These packages implement a MiR command handle that is managed by a fleet adapter in Python. (Along with some helpers.) It can be used to command and manage a fleet of MiR robots using RMF!

It uses the rmf_fleet_adapter_python bindings, which allows for communication with open-rmf libraries and ROS2 nodes.

In effect, it interfaces the MiR REST API with open-rmf, all without needing to directly use ROS 2 messages to communicate with open-rmf!

MiR vs. MiR Fleet

Since the MiR robots and MiR Fleet work with different sets of endpoints that serve different functions, both fleet_adapter_mir and fleet_adapter_mirfm packages are availble to demonstrate RMF integration between MiR100/200/250 and MiR Fleet respectively. In addition, the mir_fleet_client package provides additional API needed for the MiR Fleet + RMF integration.

For users who wish to take advantage of MiR Fleet’s centralized control system/interface or do not have access to individual MiR robots, the fleet_adapter_mirfm package enables RMF integration with MiR Fleet by obtaining individual MiR robot positions and mission GUIDs via the MiR Fleet API and dispatching commands directly to the robots themselves. The current MiR Fleet API does not provide all the necessary endpoints for RMF to perform its task allocation and traffic deconfliction to the full extent, hence the implementation contains direct communication between RMF and MiR robots as well.

As such, it is recommended to implement the fleet adapter directly with individual MiR robots using fleet_adapter_mir.

NOTE: fleet_adapter_mirfm is currently not being actively supported.

Additional Notes

Different Units for Angles

MiR and RMF use different units for angles.

• MiR uses degrees
• RMF uses radians.

You might also have to clamp your angles to be within +-180 or +-3.14.

Task IDs

Task IDs are kept as a monotonically increasing integer, with each robot having its own counter. They will be reflected as such in any RobotState messages that get published.

Fleet States

FleetState publishing is done manually and not under the purview of the individual robot command handle instances. Each robot handle will internally update its corresponding RobotState message, so it is fairly trivial to aggregate them all into a FleetState message externally.

The example script fleet_adapter_mir/fleet_adapter_mir.py does this.

Robot Transforms: Two Coordinate Systems

Since we are interfacing MiR and open-rmf, we need to deal with two coordinate systems and two forms of ‘maps’.

We have to deal with the rmf_traffic navgraph and the MiR map, with their own individual coordinate systems, waypoints/positions, and waypoint keys/position names.

Luckily, we can leverage the nudged Python library to compute coordinate transforms between the two sets of coordinates. You just have to make sure to provide equivalent reference points within the two maps so transforms can be computed.

The transform objects are stored in the EasyFullControl fleet adapter handle.

Very Involved: Location Tracking

Note: You do not need to know this if you just want to use this package to control robots. This is here to help any developers that want to look into the source code’s guts to understand why the code is written the way it is (and why there seem to be weird variables strewn about.)

This will be helpful if you intend on writing other fleet adapters for other robots that communicate with REST APIs.

In order for the appropriate RobotUpdateHandle.update_position() method calls to be used, we need some way to track the location of the robot on the rmf_core navigation graph.

File truncated at 100 lines see the full file