search

open-rmf / rmf_ros2

Internal ROS infrastructure for RMF
Apache License 2.0
71 stars 59 forks source link

[Bug]: rmf_schedule_node spams REQUEST_END_SESSION LiftRequest.msg when running with Lift Adapter #382

Closed cardboardcode closed 2 months ago

cardboardcode commented 2 months ago

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

OS and version

Ubuntu 22.04

Open-RMF installation type

Binaries

Other Open-RMF installation methods

NA

Open-RMF version or commit hash

Open-RMF on Humble Hawksbill - Sync (2023-12-29)

ROS distribution

Humble

ROS installation type

Binaries

Other ROS installation methods

NA

Package or library, if applicable

NA

Description of the bug

Issue Description :bug: Similar to #315, this issue presents itself as a continuous stream of LiftRequest.msg with request_type = 0 for REQUEST_END_SESSION when it is able to find a lift adapter via /lift_states ROS 2 topic.

Steps to reproduce the bug

The Lift Adapter in question is using a variant of chart_sg/lift_kone_adapter:

https://github.com/KABAM-Robotics/lift_kone_adapter/tree/feature/update_dockerfile

To reproduce the issue, please follow the instructions below:

  1. Build and run the Lift Adapter with the appropriate API credentials:

:warning: Due to the restrictions on what I can share, note that I am unable to share the API credentials. You will need to use your own for KONE API. This would come in the form of a env.yaml file needed by Lift Adapter.

cd $HOME
git clone https://github.com/KABAM-Roboticslift_kone_adapter.git --branch feature/update_dockerfile --single-branch --depth 1 && cd lift_kone_adapter
docker build -t lift_kone_adapter .
docker run -it --rm \
    --name lift_adapter_kone_c \
    --network host \
    -v /dev/shm:/dev/shm \
    -v ./config/env.yaml:/opt/rmf/install/kone_ros_api/share/kone_ros_api/config/env.yaml \
    lift_adapter_kone:latest /bin/bash -c \
    "source install/setup.bash && ros2 run kone_ros_api koneNode_v2"
  1. Run rmf_schedule_node.
  2. Send a manual request within Lift Adapter docker container.
docker exec -it <DOCKER_CONTAINER_NAME> bash

Example Manual Lift Request:

ros2 topic pub /lift_requests rmf_lift_msgs/LiftRequest "{request_time: {sec: $EPOCHSECONDS}, lift_name: "A", session_id: "testing", request_type: 1, destination_floor: "L1", door_state: 2}" --once

Since the instructions given here may be insufficient in allowing others in replicating the core issue due to the possible lack of necessary KONE API credentials, please refer to the video attached below to see the issue reproduced.

Expected behavior

Once rmf_schedule_node detects the presence of Lift Adapter, it would not send REQUEST_END_SESSION LiftRequest.msg continuously.

Even if it does, any subsequent manual request made by a user via the RMF Dashboard should still work.

Actual behavior

rmf_schedule_node detects the presence of Lift Adapter and issues REQUEST_END_SESSION LiftRequest.msg continuously.

Additional information or screenshots

Video showing Lift Adapter receiving REQUEST_END_SESSION LiftRequest.msg spam once rmf_schedule_node is launched.

https://github.com/user-attachments/assets/057f6242-19f6-49ad-896b-8a6c09e0b7de

Video showing Lift Adapter ignoring Manual Lift Request made due to spam.

https://github.com/user-attachments/assets/5005f564-5ab3-4626-8f5d-92a424f69fcc

xiyuoh commented 2 months ago

@cardboardcode Thank you for the recording, this explains a lot about what you are experiencing! I'll copy and paste my explanation about how RMF lift requests work from another issue ticket:

To explain a little about how these lift requests work, the various fleet adapters will publish their lift requests via /adapter_lift_requests to the lift supervisor. The lift supervisor will then process these requests one robot at a time, i.e. only entertain requests from one session id (which usually represents the robot in the fleet_name/robot_name convention) on a first-come-first-serve basis. These filtered requests for the single robot will then be published to the lift adapter on the /lift_requests topic.

For your case, the lift supervisor is continuously publishing END_SESSION requests until a lift request comes along with a session ID (i.e. robot). From there on, it will only publish any requests submitted with that session ID. The problem here is that your manual lift request is being published to the /lift_requests topic, when it should be published to the /adapter_lift_requests topic instead. The lift supervisor is receiving requests on the latter, so using when we publish directly to /lift_requests it will bypass the lift supervisor and hence the manual lift request will simply be ignored or overridden by subsequent requests.

It is important for us to trigger the lift supervisor to conduct these filtering so that a lift won't be under control by two or more robots at the same time 😁 can you try running this again but publish to /adapter_lift_requests instead and let me know how it goes?

cardboardcode commented 2 months ago

Thank you for the detailed explaination. It has cleared up some confusions. :blush: :+1:

Will try running again shortly but with the manual request published on /adapter_lift_requests.

cardboardcode commented 2 months ago

:green_circle: Video showing Lift Adapter stops receiving REQUEST_END_SESSION LiftRequest.msg spam for Lift A after the following:

The Manual Request made was as such:

ros2 topic pub /adapter_lift_requests rmf_lift_msgs/LiftRequest "{request_time: {sec: $EPOCHSECONDS}, lift_name: "A", session_id: "testing", request_type: 1, destination_floor: "L1", door_state: 2}" --once

https://github.com/user-attachments/assets/06982814-fa9d-4b9c-995e-993fadd3bc65

Can further confirm that if an additional Manual Request is made for Lift B, the spam of REQUEST_END_SESSION LiftRequest.msg will stop completely.

ros2 topic pub /adapter_lift_requests rmf_lift_msgs/LiftRequest "{request_time: {sec: $EPOCHSECONDS}, lift_name: "B", session_id: "testing", request_type: 1, destination_floor: "L1", door_state: 2}" --once

Thanks @xiyuoh for the help and explaination. Will close this issue shortly.

cardboardcode commented 2 months ago

Solution :star:

The RMF Core is supposed to be spamming the LiftRequest.msg REQUEST_END_SESSION to the Lift Adapter.

The reason why Manual Lift Requests are ignored is because they were previously published on the /lift_requests instead of /adapter_lift_requests ROS 2 topic. This bypasses the Lift Supervisor which then leads to the outcome of the Manual Lift Request being ignored.

Therefore, please publish on /adapter_lift_requests next time, keeping in mind this expected behaviour of RMF Core.