Description of task
Title
Add reusable mission control (start/pause/resume/restart/stop via ROS2 services) for all Yasmin FSM missions
Problem
We have multiple missions implemented as Yasmin state machines (e.g., docking), and we want common mission control functionality that can be reused across all missions/FSMs:
- Start
- Pause
- Resume
- Restart
- (optionally) Stop
- (optionally) Status
These controls should be triggered via ROS2 service calls and integrate cleanly without duplicating logic in each mission.
Goals / Requirements
-
Provide a generic, reusable mission control layer that works across different missions/FSMs.
-
Expose ROS2 services:
mission/start
mission/pause
mission/resume
mission/restart
mission/stop (optional but recommended)
mission/status (optional)
-
Ensure pause/resume is cooperative (states can safely block/continue).
-
Ensure restart and stop can cancel ongoing actions cleanly (or transition via CANCEL/ABORT outcomes).
-
Integrate with existing Yasmin FSM patterns using the blackboard and ActionState wrappers.
Proposed Design
1) Add a reusable MissionControl component (library)
A thread-safe controller that tracks mission state and supports cooperative pausing:
This component is intended to be mission-agnostic and shared by all missions.
2) Add a reusable MissionRunner base node (services + FSM execution thread)
A base class that owns and runs:
- a Yasmin
StateMachine
- a Yasmin
Blackboard
- a worker thread that executes the SM
Mission-specific code plugs in via 3 overridable hooks:
create_blackboard()
build_sm(blackboard)
reset_blackboard(blackboard) (for restart)
The runner provides the ROS2 services and forwards requests to MissionControl.
3) Mission integration pattern
4) Expected pause semantics
- Pause should stop FSM progression (no transitions)
- Resume continues from the paused point.
- Restart resets blackboard + rebuilds SM (or returns to initial state) and starts again.
- Stop terminates mission execution cleanly and cancels actions if possible.
Notes
- How should pause interact with action servers?
- purely pause FSM progression (no new goals), vs
- also cancel/hold current goal
- Do current action servers support “hold” semantics, or only cancel/re-issue?
Suggested Workflow
No response
Specifications
-
A single implementation of mission control is shared across all missions.
-
New missions can adopt mission control by:
- inheriting from
MissionRunner
- implementing the three hooks
- adding
mission_control to blackboard
- calling
checkpoint() in relevant states (feedback handlers and loops)
-
Services successfully control mission execution:
pause blocks progress and optionally cancels/holds controller outputs
resume continues
restart resets state and starts over
stop cancels and exits
-
No mission-specific duplication of start/pause/resume/restart service code.
Contacts
No response
Code Quality
Description of task
Title
Add reusable mission control (start/pause/resume/restart/stop via ROS2 services) for all Yasmin FSM missions
Problem
We have multiple missions implemented as Yasmin state machines (e.g., docking), and we want common mission control functionality that can be reused across all missions/FSMs:
These controls should be triggered via ROS2 service calls and integrate cleanly without duplicating logic in each mission.
Goals / Requirements
Provide a generic, reusable mission control layer that works across different missions/FSMs.
Expose ROS2 services:
mission/startmission/pausemission/resumemission/restartmission/stop(optional but recommended)mission/status(optional)Ensure pause/resume is cooperative (states can safely block/continue).
Ensure restart and stop can cancel ongoing actions cleanly (or transition via CANCEL/ABORT outcomes).
Integrate with existing Yasmin FSM patterns using the blackboard and ActionState wrappers.
Proposed Design
1) Add a reusable
MissionControlcomponent (library)A thread-safe controller that tracks mission state and supports cooperative pausing:
request(Start|Pause|Resume|Restart|Stop)checkpoint():falseif stop/restart was requestedtake_restart_requested()to consume restart requestsThis component is intended to be mission-agnostic and shared by all missions.
2) Add a reusable
MissionRunnerbase node (services + FSM execution thread)A base class that owns and runs:
StateMachineBlackboardMission-specific code plugs in via 3 overridable hooks:
create_blackboard()build_sm(blackboard)reset_blackboard(blackboard)(for restart)The runner provides the ROS2 services and forwards requests to
MissionControl.3) Mission integration pattern
Store
MissionControlin the blackboard:"mission_control"→std::shared_ptr<MissionControl>In states with feedback loops / long-running work, call:
blackboard->get<std::shared_ptr<MissionControl>>("mission_control")->checkpoint();For restart/stop:
checkpoint()returning false to trigger a CANCEL/ABORT transition, and/or"mission_cancel") for states to return CANCEL.4) Expected pause semantics
Notes
Suggested Workflow
No response
Specifications
A single implementation of mission control is shared across all missions.
New missions can adopt mission control by:
MissionRunnermission_controlto blackboardcheckpoint()in relevant states (feedback handlers and loops)Services successfully control mission execution:
pauseblocks progress and optionally cancels/holds controller outputsresumecontinuesrestartresets state and starts overstopcancels and exitsNo mission-specific duplication of start/pause/resume/restart service code.
Contacts
No response
Code Quality