search

RobotWebTools / roslibjs

The Standard ROS JavaScript Library
https://robotwebtools.github.io/roslibjs
Other
693 stars 382 forks source link

Reconnecting to actions needs to restore goals #270

Open Faibk opened 7 years ago

Faibk commented 7 years ago

In https://github.com/RobotWebTools/roslibjs/pull/267 I implemented reconnection for topics, which inherently works for action as well (since they build upon topics). But ActionClient also stores goals which might have succeeded/been aborted during the connection loss. In applications intended to keep running over an extended amount of time and through multiple reconnects this is a potential leak of state and memory.

Currently I resolve this outside of roslibjs by retrieving the status_list from the action's /status topic and creating/updating the goals accordingly. For that I suggested in #267 adding a way to explicitly set the goalID on instantiation, but reverted it to further discuss the issue here. With the addition of reconnect a concept to deal with orphaned goals might be relevant for the roslib core as well.

I'm not sure about how to tackle this, so I'm happy about feedback here. I would suggest integrating the restoring of goals into the ActionClient on connect and adding the possibility of creating a goal with specific goalID.

uahic commented 5 years ago

I have a similar use-case where I basically connect to a backend which implemented task-executions with action server (a concept that I personally dislike...). When refreshing the webpage/webapp it should of course catch up with running goals. By design an action server is probably not the best concept when used as part of a service-like API . Similar to your approach I've build (in Angular 7) a service that fetches infos from the status_list and feedback (which we enriched with meta-info just for this purpose).

Still, for my use-case and similar ones I think its a wrong approach and maybe building a wrapper class around the action server on backend-side that allows queries and ros-services for starting/stopping would be the easiest thing approach. The goal would be owned by some back-end node but allow to create new ones/kill old ones, get a list of running goals,.. etc. etc.

In general I was thinking about to start a library that offers an API suitable for service-like-architectures for roslibjs