These are navigator focus group’s notes from maintainer/core dev workshop during Zurich PX4 DevSummit. The action items should be built into roadmap and followed up in weekly dev-calls. The session was chaired by @JulianOes (notes by @potaito).
Main question: Where should the state machine live
What needs improvement
-
Reliable state machine
-
User needs to know what’s happening, when and why
-
We need waypoint control for various airframe configs (vtol, fixed-wing, multirotor)
-
Dependency between commander and navigator → We should not have everything everywhere
-
The whole global local coordinate topic
-
Reduce the complexity of commander
Initially commander was supposed to do only safety critical decisions and then tell the navigator to do the mission.
Where it falls apart
Flight tasks. A flight mode might know more than the commander does. Now what if a flight task fails? It informs the commander that if fails, but commander won’t necessarily know why. The other extreme would be to pipe all info to the commander and make the decisions there.
- There needs to be a callback provided by tasks and used by the commander, such that comm can check whether a task is currently feasible?
- It makes sense to have a central state machine where everything is controlled (commander). Flight tasks should be used through an API that also specifies what info the tasks need. These would be the properties of the orbit task for example.
There should be feedback from flight tasks that tell whether they would be able to execute such that we don’t try to use them and then run into a failure. This is also a usability thing. A User would not be able to select “Orbit” if orbit is not available right now. For whatever reason.The decision whether the orbit is possible or not should be done inside the orbit code, not commander.
@JulianOes Hybrid approach: Fail safe stuff in commander. In flight task we have more specific decision making.
Top-down: Commander knows everything, makes decision.
Ground-up: Flight tasks know everything and coordinate their own decision making.
Take the specific things out of commander and move them to the plugin side. Flight Tasks are plugins.
@dagar : Problem boils down to the fact that the state machine is hard-coded and distributed across modules. We can’t even draw/visualize the state machine currently. Flight task would be something that implements an interface. and commander uses that interface.
@MaEtUgR : Flight tasks will have runtime requirements such as “do we have local position?”. These things should be checked rather than simply tested and possibly rejected. And the check should be callable by the state machine.
@dagar : But these checks could be much more sophisticated than a flight task implements. Put differently: When is a local position valid or sufficient? Commander has its own notion of when this is the case. The flight tasks would have to use the same notion.
All: These checks should be in one place only.
@JulianOes : Where would a battery-sufficient check exist? → Failsafe → Failsafe state machine and therefore commander
All: RTL could actually also be a flight task. Or better example: The land procedure. Land does not need to be implemented in Navigator. Plus, this could allow easier implementation of different land procedures for FixedWing, VTOL and multirotor.
@Stifael : Maybe we should rename Flight Tasks. Tasks suggests that it’s in a work queue or something.
@JulianOes/@dagar : All flight tasks should have an interface that register with the commander state machine. The flight tasks are then fed with all the information that they need.
@Stifael : Another problem are tasks and commander running at different frequencies and therefore disagreeing for a split second because one module has different information than another. Daniel suggest we serialize the execution to solve the problem.
Action items
- Look at state machine implementations
- Move navigator modes to Flight tasks