Recommended way to represent robot initialization failures in RMF Web

Open-RMF Open-RMF General
1

Hi,

I’m working on an EasyFullControl fleet adapter and would like to clarify the intended usage of the uninitialized robot status.

The robot_state.json schema includes:

"status": [
  "uninitialized",
  "offline",
  "shutdown",
  "idle",
  "charging",
  "working",
  "error"
]

My understanding is that uninitialized could be used when a robot fails startup/initialization and is not yet ready for operation.

However, in the current adapter implementation, robot initialization occurs before fleet_handle.add_robot(...) is called. For example, if obtaining the initial pose times out:

if init_robot_pose.result() is None:
    raise RuntimeError(...)

The robot is never added to the fleet, and therefore no update_handle exists to call:

update_handle.more().override_status("uninitialized")

This causes the adapter startup to fail for that robot before it can appear in RMF Web.

My goal is:

  • Robot A fails initialization

  • Robot B and Robot C continue to initialize normally

  • Robot A still appears in RMF Web with status uninitialized

  • Optionally retry initialization later

What is the recommended RMF pattern for this scenario?

Should fleet adapters:

  1. Register the robot using a fallback/start pose and then call override_status("uninitialized")?

  2. Create a placeholder/degraded robot context even when initialization fails?

  3. Use a different status such as offline or error instead?

I’m interested in understanding the intended semantics of uninitialized and the recommended implementation approach within EasyFullControl adapters.

Thanks!

2

This is a great question. The situation falls outside the scope of what the original fleet adapter API was meant to handle. The API makes an assumption that there will always be some kind of best guess of where a robot is located in space, otherwise we won’t even know where to depict it on the dashboard. For the next generation, we’ll make sure to include a robot state that can better express “We don’t know where the robot is right now”.

  1. Register the robot using a fallback/start pose and then call override_status("uninitialized")?

Yes, this would be my recommendation for the current API. I would also recommend immediately decommissioning the robot by passing a decommission value to set_commission followed by reassign_dispatched_tasks just in case a task was assigned to the robot for the brief time that it was in an invalid state. Decommissioning the robot will ensure that no tasks are assigned to it. You can change the robot back to commissioned after you’ve managed to get it initialized.

  1. Use a different status such as offline or error instead?

We don’t have very strict definitions of these statuses. We should probably come up with a more rigorous specification for the next generation. I think any of the three could make sense, depending on the exact details of your system. If the initialization error is something you expect the robot to recover from automatically in a short amount of time, I would recommend uninitialized as a way of expressing that the robot is still booting up. If it’s an error that needs human intervention, I would recommend error to get the attention of the operators. I think offline is better to use when the robot has been deliberately taken offline, so it’s probably not suitable for this case.