Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding an API to FleetUpdateHandle and RobotUpdateHandle. #26

Open
1 task done
suchetanrs opened this issue Mar 24, 2024 · 2 comments
Open
1 task done

Adding an API to FleetUpdateHandle and RobotUpdateHandle. #26

suchetanrs opened this issue Mar 24, 2024 · 2 comments

Comments

@suchetanrs
Copy link

suchetanrs commented Mar 24, 2024

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
Copy link
Member

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants