Can we have an extra field "priority" for every idl conversion with actions?

[saikishor]

Feature request

Can every action message have an internal field called priority with uint8 or uint16?

Feature description

This is very useful for the use cases, when there are many action clients around, trying to send goals, and having a unique behavior as in all new goals will abort the current goal or new goals are triggered only after an old goal is finished is something that doesn't work for day to day basis. For most applications, the priority behavior is the most common.

For instance, there might be the following use cases:

1. Ability to launch some idle motions to have the robot more alive and when an application needs to run a motion to greet the person needs to take more priority over the motions of the alive.
2. Navigating the robot might also work with priority, the robot with a low battery would be interesting to go to charge rather than continuing with its current navigation goal.
3. Emergency or safety actions need more priority than any other application

Implementation considerations

Adding a "priority" field within the actions would be very interesting and this way we will be able to solve most of the issues.

I would be happy to contribute to this part.

Best Regards, Sai Kishor Kothakota

[sloretz]

It sounds like your application could use a mechanism for the action client to tell the action server that a goal is more or less important than any existing goals it may have. Action servers already have freedom in what order they execute goals, and freedom to choose what goals to accept or abort, so I think the problem is definitely possible to solve. There are ways to solve it without adding the overhead of an extra priority field to all clients though.

One option would be to add a priority field to a custom action definition. Then the server can take that option into account. Note that this requires all clients on the system to behave, and not automatically send all of their goals as the highest priority.

Another option is to put another entity in the middle that would listen to the action clients, and pass though goals for the client it deemed the highest priority. This design is a lot like cmd_vel_mux. It would offer different action servers with different priorities, and have one client that sent goals to the real action server. The launch infrastructure would use remapping to map each client to the corresponding priority.

We discussed this a bit in the meeting today, and decided it sounds better served by an application specific solution, so I'll close the issue for now.