Posted by @cwrx777:
Due to the lift dimension, a MiR robot shall not perform rotation while inside a lift, and it shall only perform reverse when exiting the lift.
how can the above be achieved using python based fleet adapter?
if we have the in_lift API on the waypoint, we can skip the rotation while the robot is inside lift.
for entering, is it possible to use docking ? there’ll markers installed inside the lift.
for exiting by reversing, is it possible to set dock_name the waypoint outside the lift, and when the fleet adapter receives the dock command, it will send relative move command to the robot.
Edited by @cwrx777 at 2024-02-26T10:42:35Z
Posted by @mxgrey:
for entering, is it possible to use docking ? there’ll markers installed inside the lift.
Yes, in fact I recommend always using docking procedures for getting in and out of a lift.
for exiting by reversing, is it possible to set dock_name the waypoint outside the lift
Yes, and this is recommended, but there’s an annoying catch: You need to have a waypoint specifically dedicated to being the lift exit waypoint. The lift exit waypoint can only have one uni-directional lane connecting to it from the lift waypoint, but it can have any number of uni-directional lanes leaving it towards other waypoints. Give that lift exit waypoint the dock name that you want to use for exiting the lift.
Posted by @cwrx777:
reference discussion: #238, #454
When docking into the lift failed, the fleet adapter will send the robot to nearby waypoint and this waypoint will be set in the self.on_waypoint in the fleet adapter before the next step. As for the next step do I call docking_finish_callback and or replan ?
In my understanding of docking, the core does not have any expectation on where the docking finish waypoint is. It is the fleet adapter that needs to inform the core by setting the current waypoint and then call docking_finish_callback and the core will plan the next actions based on the current position. If the current position is inside the lift, the core will send the lift to destination floor, otherwise, rmf will release the lift session, plan and move the robot back to the lift calling position and subsequently request for the lift again.
Posted by @mxgrey:
In my understanding of docking, the core does not have any expectation on where the docking finish waypoint is.
I understand why you have this impression, but it is not true. The core does expect the robot to arrive at the finish point that’s indicated by the nav graph. If the robot ends somewhere else, you will need to trigger replan instead of triggering the finished callback.
I left a response for the specific questions you brought up about lift issues, but I’ll also share the general strategy we’re taking with lifts in our own deployment, which has been a challenging exercise in dealing with edge cases.
- Use the EasyFullControl API to minimize the complexity of the code that needs to be implemented in the platform-specific side of the adapter. This significantly reduces the likelihood of a bug existing in your client-side code.
- Assign the
lift_usage_[lift name] mutex group to every lift waypoint on every floor, and also assign it to the lift exit lanes on every floor. This gives an extra protection against robots fighting to get into the lift.
- Assign sequences of mutex groups leading up to the lift entry point as described in my other reply to create a queuing system.
- Identify when a command from the EasyFullControl API is sending the robot into the lift. If the robot is already adequately inside the lift, then immediately trigger the finished callback on the command instead of telling the robot to move anywhere.
- Identify when a command is having the robot enter/exit the lift (in your case you’ll see that it’s a docking command). When the robot is entering or exiting the lift, use the strategy described in this comment. This will prevent your docking procedure from getting disrupted by new plans.
- Identify when you’ve lost connection to the robot (e.g. querying the robot status is failing). During this time, stop submitting position updates and also follow a similar strategy to (5) by discarding any new commands from RMF. Once the wifi has reconnected, give RMF a fresh position update and then trigger a replan if any new command came in during the disconnection.
It’s tricky to implement all of this correctly, but we’ve found that this eliminates all of the disruptive lift-related edge cases that we’ve encountered so far. We’re working on migrating this logic out into the open source fleet adapter, but we don’t have a specific timeline for when we’ll finish that.
Edited by @mxgrey at 2024-04-29T02:33:56Z