Open koonpeng opened 3 years ago
@koonpeng could you elaborate further on the requirement?
The fleet adapters already respond to fire alarms via the /fire_alarm_trigger
topic albeit the behaviour can be improved.
It was previously discussed that the client should not have the power to freely control the alarm status. rmf should have some endpoint which the client use to request certain alarm state, which may or may not be successful depending on some factors.
I see. We could implement an alarm_supervisor
node which subscribes to /alarm_requests
and publishes an /alarm_state
. Clients can send requests to toggle the alarm status to this node. The node then publishes to /fire_aram_trigger
. With regards to authentication, one possible way could be to rely on SROS to pre-configure which nodes can publish over this topic.
I think we should stop using the "fire alarm" topic as the topic that fleet adapters listen to when deciding when to engage emergency mode. There are many possible reasons we may want to trigger the emergency behavior; fire alarms are just one of them.
I like the idea of an alarm_requests
topic and an alarm supervisor node. The only thing I would tweak about @Yadunund's suggestion is that we rename the relevant topic to something like emergency_state
or alarm_trigger
, or something else (as long as it doesn't explicitly mention "fire").
Feature request
Not sure if this is the right repo.
open-rmf/rmf-web#494 hacks around this by implementing in the api server. Obviously this is not good and such feature should be available in rmf core.
Also would be good if the design allows for arbitrary alarms depending on the deployment scenario.
Description
Implementation considerations
Alternatives
Additional information