[Feature request]: Task status on both ROS topic and websocket

Briancbn commented 5 months ago

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

[X] I have done a search for similar issues and discussions.

Description

As of https://github.com/open-rmf/rmf_ros2/pull/168, task status is no longer published on a ROS topic and only available through websocket.

When I was create an external module to generate a flow from an SKU order like the following

1 SKU order received
1 SKU order break into robot tasks with order
robot 1 do delivery
after robot 1 completes delivery, call another ROS node's service (e.g. my own node for another workcell), ofc this part can be part of the ingestor or perform action
after service completed, robot 2 do delivery

The most simple way for me is to dispatch robot 1 to do its task, monitor the robot1 task to confirm completion. Afterwards, call the other ROS node.

Here comes my dilemma, since the task status is not available on a ROS topic, I cannot catch the completion of the robot 1's task. So the only option is websocket.

After I integrated with the websocket using rmf_websocket for convenience, I realized that if I create a websocket server, the websocket server of the RMF Web API server cannot receive information from the fleet adapter. I believe this is due to only one websocket server can bind to a specific port and IP.

In the end, depends on the project the following two ways can be done

Create a websocket server to listen to the fleet adapter while at the same time publishing the same info to the RMF Web API. This implementation is like a passthrough filter or a man in the middle attack to extract the task state information :)
Enable rmf_ros2 to publish to both the ROS topic and websocket at the same time.

The second optino is my choice for only a small change in the rmf_ros2.

I would suggest that there is something similar to server_uri argument to allow publishing of the task status on the ros topic. Something similar to how robot_localization allow publish tf or odom.

I was also looking at the old forum posts for performance issue on why task status is no longer posted on a topic but can't find any.

Implementation Considerations

I was publishing this information through some modification to the TaskManager, but I don't think this is the best way.

Alternatives

I found this old discussion https://github.com/open-rmf/rmf/discussions/203#discussioncomment-3566503 about using the set_update_listener() to subscribe to the task status. But I think this only applies to fleet adapter. And I also don't really want to make changes to every one of the fleet adapter source code to publish task state.

Although later on with the flexible task definition can enable multi-robot collaboration, I do think with task_status available in the ROS topic, allows way more freedom with using RMF to fulfill different use cases.

Additional information

If this feature is also something that the maintainer agrees to, I can make a Pull Request.

Yadunund commented 5 months ago

The issue with the /task_status approach was that there was no clear source of truth for the history or log of tasks. Any node that subscribes to this topic could build up it's own. With the api-server, there is one clear source of truth. The API server can be queried via REST API to get all the information you need as described above so I'm wondering if you have tried that approach?

Here comes my dilemma, since the task status is not available on a ROS topic, I cannot catch the completion of the robot 1's task. So the only option is websocket.

The need to "catch" the topic is a huge reason we switched to websockets and a dedicated api_server. If the message is dropped, your task would be waiting indefinitely. And if your node joined the graph after this information was published (ie, a late joining subscription), you would likely not get the information unless QoS settings are transient_local durability.

Briancbn commented 5 months ago

Thanks @Yadunund for the quick reply.

The issue with the /task_status approach was that there was no clear source of truth for the history or log of tasks. Any node that subscribes to this topic could build up it's own.

I don't think I quite get the issue with this. As long as there is no false information, since currently the info needed is only the state transition. As long as the fleet adapter received the task doesn't crash and the communication doesn't break down. I think the task history can leave it to the api-server which act like an aggregator to collect and record.

The benefit for having a ROS topic is to provide more freedom for the designing use case specific node with the task dispatching system, while still leveraging the benefit of the rmf-web dashboard. Especially for use case related to tasks with custom actions. User can enable the topic for monitoring if they want to, as long as it doesn't cause issue with the existing api-server system.

With the api-server, there is one clear source of truth. The API server can be queried via REST API to get all the information you need as described above so I'm wondering if you have tried that approach?

iirc for REST API, I can only use to request for the information and can miss or skip state transition. I understand there is also a socket.IO server, will that enable a more reactive approach?

Secondly, the api-server REST API will require login and token with the authentication setup, which means creating a dummy user in the Keycloak server which is quite hackish and can introduce security vulnerability. While implementing below the api server layer can hide underneath along with the REST of the ROS topics.

And if your node joined the graph after this information was published (ie, a late joining subscription), you would likely not get the information unless QoS settings are transient_local durability.

Thanks for highlighting this. The monitoring node should join before the task is dispatched.

And yes that's the durability that I am currently using and wants to implement here. I notice this is also the QoS policy used for a majority of the subscriptions here. Is there any limitation that can cause trouble for subscribing to a topic published by multiple nodes?

open-rmf / rmf_ros2