Trajectory path

[zach-goh]

In order for a robot to conform to RMF's requirements for Read-only/Traffic light fleet, one of the crucial data to be obtained is the robot's planned trajectory (sequence of locations that the robot will be traveling through). I found this site (https://osrf.github.io/ros2multirobotbook/integration_read-only.html) that says the RobotState contains a path field. This is specified as an array of Location objects and its fields are listed on this site:
https://github.com/osrf/rmf_core/blob/master/rmf_fleet_msgs/msg/Location.msg

However there aren't any other details as to what the fields mean esp the time and index . Can someone help to provide more details so that I can write a fleet adapter to provide the sequence of locations in the data format that RMF requires?

[mxgrey]

The rmf_fleet_msgs API is a legacy API so it has some cruft in it and isn't generally recommended for use in developing a fleet adapter. However, we haven't put out a "modernized" API for the Read-Only style of integration yet, because the legacy one has been working well enough for all of our use-cases so far.

For the legacy Read-Only Fleet Integration you can ignore the t time field and the index field. The documentation you linked mentions this for t, but we need to update it to explain that index should be ignored as well:

Inside the rmf_fleet_msgs/Location message, the t field (which represents time) is generally ignored by the read-only fleet adapter. We assume that it is too cumbersome for your Fleet Driver to make timing predictions, so we have the read-only fleet adapter make the predictions for you based on the traits of the vehicle.

[mxgrey]

(This kind of ambiguity is a big part of why we're deprecating that API; we just haven't gotten around to making a replacement for the read-only yet, unfortunately. I've opened a ticket to track this issue: open-rmf/rmf_ros2#79.)

[zach-goh]

In the replacement API, are you expecting the requested robot path information (e.g. fields, data types) to change from the current API? If so, I would rather wait for the new API to be ready before I start developing my fleet adapter to support RMF.

[mxgrey]

I expect it will ask for the exact same information that the current legacy Read-Only fleet adapter takes in, just in a different format, i.e. a C++ or Python API (your choice) that is more explicit.

If we do decide to expand on the kind of information that the Read-Only fleet adapter takes in, we can do that in a separate API or as an optional extension. But the information taken by the legacy API has proven sufficient for most Read-Only cases, so I expect us to support that set of data indefinitely.

Working with the legacy Read-Only API should be a helpful exercise for getting familiar with RMF, and transitioning to the future Read-Only API should be very straightforward.

[zach-goh]

Thanks for the answer. To summarize, my fleet adapter only needs to supply these 4 fields to RMF. May I check what the units of x, y and yaw are? Are they in meters and degrees? Also any particular format that level_name needs to follow like string prefix or suffix - I guess this represents the floor number of the building e.g. level 1, basement...?

[mxgrey]

Technically it is up to the system integrator(s) and/or the facility manager to decide the exact meanings of these fields. It doesn't matter what convention is used, as long as every robot sharing a given space is using the same convention.

So far in all of our testing, we have used meters for the units of x and y, where the origin of that coordinate system is some well-known point on a floor plan, and the orientations of x and y are aligned with the x and y of the floor plan information that we are given. We set yaw to the orientation of the robot (in radians) relative to the x-axis. The level_name is the most arbitrary parameter of them all, but we generally go by whatever names are given to the floors by the lifts in the facility, e.g. "L1", "L2", "B1", "B2". We have already experienced cases where different vendors have different names for the various floors/areas, so do be ready to convert from custom vendor-specific floor names to some canonical set of "RMF floor names".

That being said, I believe there's growing interest in using latitude and longitude values for x and y instead of meters away from a reference point. Ultimately the choice will depend on the project requirements.