add a service to set the flight mode

[tfoote]

This will allow the user to arm and disarm the vehicle via a ROS service.

This is from the ROS-SIG-MAV discussions: https://groups.google.com/forum/#!topic/ros-sig-mav/f12m3mnqYl4

Open for comment. Not ready for merging.

There's a little bit left on this with the possible failure modes needing to be filled in, in the enum listing.

[vooon]

Mode as a single enum not good. Different AP's have different mode set, where only few modes may have similar meaning.
Because of that mavros use string representation.

[jonbinney]

@voon could you give a couple example of modes that differ between different AP's? Could we maybe provide an enum that specifies a high level state that makes sense for all AP's (INACTIVE/MANUAL/AUTO?) and a string for setting more detailed AP-specific states within that high level state?

[tfoote]

You're right we're conflating two things here. There are too many AP modes to cover. The thought for this was to provide a more abstract concept into which every autopilot mode could be binned.

I've got a reformulation of the messages using level of autonomy from the ALFUS from NIST.

[vooon]

@jonbinney http://wiki.ros.org/mavros/CustomModes

@tfoote that looks better, but why not add custom mode string?
Also note that arming in mavlink AP's is a separate from mode.

[tfoote]

@vooon The thought for these levels is not that they set the autopilot mode, but that they set the level of readyness. And the autopilot modes can be mapped to the different levels of autonomy required for that operational mode. And the autopilot should not go into a mode requiring a higher level of readyness than for which the system is enabled.

Setting the autopilot mode should go on through a different channel as it's implementation specific. Although the two predominate system architectures have discrete autopilots with discrete modes I do not see that as inherent to flying vehicles. And don't necessarily want to build that implementation specific design choice into the abstraction for interacting with flying vehicles.

[jonbinney]

So is the intent that LOA_REMOTE_CONTROL will put the vehiicle into a remote control state that is lower level than ROS (e.g. RF transfmitter/receiver sending PWM driectly to the FCU?) and LOA_TELEOPERATION will be a mode where ROS sends velocities that come from a human user (e.g. from an xbox joystick connected to the CPU running ROS?).

For the LOA_HUMAN_DIRECTED through LOA_AUTONOMOUS modes, is there a well defined difference in how the FCU ought to behave when in these modes? Will the FCU know whether commands coming over mavlink are from humans or from a navigation node? (for example, we could have a ROS command topic for each of these levels of autonomy, so that a navigation node would publish to /cmd_vel/autonomous and a joystick teleop node could publish to /cmd_vel/teleoperation - or am I reading too much into this?

[tfoote]

For background we started this with discussing how to arm the system. And when you're arming it's actually context dependent what subsystems are required depending on what mode of operation you will be in.

I think for clarification the level of autonomy in this arming is the expected onboard autonomy. It is not trying to classify or limit where external commands are coming from (human or ROS or other). What is is clarifying is that it has enough subsystems online to enable the flight category.

The goal of this is that the standard API is vehicle/autopilot agnostic. And then each time an autopilot wants to enter a mode. It is required to request the appropriate arming level before starting to operate.

As a starting point I'd suggest requirements to transition into a mode under one of these classifications.

• inactive => the vehicle must not be in the air
• prearm => the vehicle must not be in the air
• remote_control => capable of passing through direct commands for motors and control surfaces, has a control input source connected with validated signal
• teleoperation => capable of stabilizing itself and has a validated signal of control. enables things like stabilized joystick control
• human_directed => capable of navigating for short periods without human intervention, requires local odometry
• human_aided => capable of flying mostly without human inputs, requires localization
• autonomous => capable of executing a goal without human interaction including obstacle avoidance, path planning, and task planning

I think we should expand the spec a little bit for clarity on this. Maybe even to the level of a REP. We've been talking this afternoon about a subsystem status message which would provide visibility into the state of these subsystems for the user before asking to change the LOA. (So they have the option to check the preconditions themselves before hand if they want to. )

[jonbinney]

Ah, I understand now.That makes sense at a high level; I agree that a more detailed spec/REP going into how these behave would be useful.