search

open-rmf / rmf_obstacle

Packages that infer the presence of obstacles from sensor inputs.
Apache License 2.0
6 stars 10 forks source link

Adding an API to FleetUpdateHandle and RobotUpdateHandle. #26

Open suchetanrs opened 6 months ago

suchetanrs commented 6 months ago

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

Description

Hi @Yadunund ! I am planning to work on one of the tasks you detailed in the GSoC 2024 task list. This is regarding adding an API to the FleetUpdateHandle and the RobotUpdateHandle.

Right now the open_lanes and close_lanes are updated from the fleet_adapter.py file. The callback for the request topic also resides in this file. Could you please elaborate on what you desire the new API to have? To my understanding, we want FleetUpdateHandle to have something like a server callback or a subscription callback to handle the closing and opening of lanes internally?

Best, Suchetan

Yadunund commented 6 months ago

Hi @suchetanrs,

Thanks for enquiring more.

I realized I didn't frame the checklist item accurately. Right now the the open_lanes and close_lanes API in FleetUpdateHandle open/close lanes as long as a request is received. I was hoping to have some kind of "access control" where we honor requests only from approved requestors. I've updated the checklist to move this point under rmf_demos and specific to the rmf_demos_fleet_adapter. It's an open ended ticket so happy to hear any proposal on how to implement this.

suchetanrs commented 6 months ago

Thanks a lot for your comment @Yadunund :D To my understanding, at the end of this effort, there would be only one lane blocker node which would receive the obstacle information from the obstacle server and send lane closure requests. Please correct me if I am wrong. In case a user wants to explicitly close and open lanes not necessarily due to obstacles, I think the only communication with the user should be through the lane blocker node and he should not directly be allowed to send messages on the LaneClosureRequestTopic. So to provide an access control, I think a basic method would be to add a field of providing a node name in the message interface and check if the node name is in the valid vector of nodes in FleetUpdateHandle. If you feel this is not sufficient, we could try encoding the node name as a string using a json web token (https://jwt.io/) and decode it for approving access. However, to provide this check in the FleetUpdateHandle, I think I will need to change the function definition of open_lanes and close_lanes to pass the requesting node name / web token as an argument so I am not sure if its the correct approach :p