[Bug]: Robot doesn't create lift session with open door

[Vortex-TH]

Before proceeding, is there an existing issue or discussion for this?

• I have done a search for similar issues and discussions.

OS and version

Ubuntu 22.04

Open-RMF installation type

Binaries

Other Open-RMF installation methods

No response

Open-RMF version or commit hash

0.0.1-1jammy.20231206.081430

ROS distribution

Iron

ROS installation type

Binaries

Other ROS installation methods

No response

Package or library, if applicable

No response

Description of the bug

In our facility we have an agv lift that doesn't have a door on the first floor level, so in the Lift adapter API (using the lift adapter template), I set the door to always be open when the lift is currently at that floor, ready for the robot to move in or out.

This causes a problem, as the robot apparently expects a closed door and a lift session only is created when the door is initially closed. I could create a 'virtual door' that only 'opens' when there is a request, but 1. that doesn't represent the real state 2. requires the integration of some arbitrary triggers for door control depending on the robot

I'm not sure if this is already addressed in #310. Unfortunately I don't have the opportunity to test that, maybe someone can have a look at it.

Steps to reproduce the bug

1. Launch RMF
2. Launch Lift Adapter with Lift API that is configured to have a door open by default (when lift is on that floor level)
3. Sent the robot to a waypoint on another floor level

Expected behavior

The robot should request a Lift session and move into the lift

Actual behavior

No lift session is created (the robot waits in front of the lift and nothing happens), even though the door is open.

Additional information or screenshots

No response

[Vortex-TH]

Also, lift sessions don't get terminated when there is a door that stays open (or no door at all) after reaching a floor level.

[mxgrey]

Sorry for not noticing this issue report sooner.

I'm a bit perplexed by the problem that you're describing. I'm looking through the source code and I don't see anywhere that requires the lift doors to ever be closed.

the robot apparently expects a closed door and a lift session only is created when the door is initially closed

Lift sessions are managed by the lift supervisor which has no expectation of the door being open or closed; it just forwards whatever is asked for by the fleet adapters.

The fleet adapter only ever requests the door to be opened. The assumption is that the lift door will automatically close when it needs to, so there's no need for us to explicitly command a closed door.

The workflow for lift usage is only blocked on waiting for the door to be open. We don't have any condition that waits for the door to be closed.

Waiting for a lift session to end doesn't check the door state at all.

I think there must be some other problem blocking the workflow for you. Could you recreate the issue and then run

$ ros2 topic echo lift_states
$ ros2 topic echo lift_requests
$ ros2 topic echo adapter_lift_requests

and let me know what messages come out of each?

[Vortex-TH]

Thanks for the reply. I hope I can narrow down the issue next week if I have some free time. I'll have a look if I added something that may cause this.

I remember there was some confusion about what to return for the value of destination_floor when the lift is idle at the floor, but I'm not sure if that was causing issues. I'll check.

I'm also not sure if the other issue I reported (and is reproducible in the sim) has an effect or is intended behaviour. Maybe you can have a look at that too.

[Vortex-TH]

I noticed that there seems to be an empty session that blocks the lift request by the robot:

[lift_supervisor-12] [INFO] [1705944941.145228398] [rmf_lift_supervisor]: [] Published lift request to [L1] from lift supervisor
[fleet_adapter_neo-14] [INFO] [1705944941.145494490] [neo_fleet_adapter]: [neo/neo_2] is waiting to begin a session with lift [MyLift] but the lift is currently held by []
[lift_supervisor-12] [INFO] [1705944941.145883701] [rmf_lift_supervisor]: [neo/neo_2] Received adapter lift request to [L1] with request type [1]
[lift_supervisor-12] [INFO] [1705944942.145425284] [rmf_lift_supervisor]: [] Published lift request to [L1] from lift supervisor
[fleet_adapter_neo-14] [INFO] [1705944942.145653706] [neo_fleet_adapter]: [neo/neo_2] is waiting to begin a session with lift [MyLift] but the lift is currently held by []
[lift_supervisor-12] [INFO] [1705944942.145969155] [rmf_lift_supervisor]: [neo/neo_2] Received adapter lift request to [L1] with request type [1]
[lift_supervisor-12] [INFO] [1705944943.146061729] [rmf_lift_supervisor]: [] Published lift request to [L1] from lift supervisor
[fleet_adapter_neo-14] [INFO] [1705944943.146403358] [neo_fleet_adapter]: [neo/neo_2] is waiting to begin a session with lift [MyLift] but the lift is currently held by []
[lift_supervisor-12] [INFO] [1705944943.146671500] [rmf_lift_supervisor]: [neo/neo_2] Received adapter lift request to [L1] with request type [1]
[lift_supervisor-12] [INFO] [1705944944.145847326] [rmf_lift_supervisor]: [] Published lift request to [L1] from lift supervisor
[fleet_adapter_neo-14] [INFO] [1705944944.146274891] [neo_fleet_adapter]: [neo/neo_2] is waiting to begin a session with lift [MyLift] but the lift is currently held by []
[lift_supervisor-12] [INFO] [1705944944.146552614] [rmf_lift_supervisor]: [neo/neo_2] Received adapter lift request to [L1] with request type [1]
[lift_supervisor-12] [INFO] [1705944945.148897978] [rmf_lift_supervisor]: [] Published lift request to [L1] from lift supervisor
[fleet_adapter_neo-14] [INFO] [1705944945.149180348] [neo_fleet_adapter]: [neo/neo_2] is waiting to begin a session with lift [MyLift] but the lift is currently held by []
[lift_supervisor-12] [INFO] [1705944945.149544510] [rmf_lift_supervisor]: [neo/neo_2] Received adapter lift request to [L1] with request type [1]

/lift_requests and /adapter_lift_requests look like this (published at 1Hz):

---
lift_name: MyLift
request_time:
  sec: 1705944943
  nanosec: 146480901
session_id: neo/neo_2
request_type: 1
destination_floor: L1
door_state: 2
---

or this:

---
lift_name: MyLift
request_time:
  sec: 1705945109
  nanosec: 452245532
session_id: ''
request_type: 0
destination_floor: L1
door_state: 0
---

/lift_states:

---
lift_time:
  sec: 1705945570
  nanosec: 316430784
lift_name: MyLift
available_floors:
- L1
- L2
current_floor: L1
destination_floor: L1
door_state: 2
motion_state: 0
available_modes:
- 1
- 2
current_mode: 2
session_id: ''
---