AP_DDS: Provide vehicle type and mode

[tizianofiorenzani]

DDS Interface to obtain vehicle's type and mode.

The DDS interface should provide information about the vehicle type and current mode.

Solution

• Create a new topic /ap/flight_mode of custom type FlightMode.
• FlightMode should contain:
  • vehicle_type: enum of the vehicle, plane, copter,....
  • flight_mode: enum of the current flight mode
  • armed: true if armed.
  • header
    • frame_id: string identifying the vehicle like SYSID_THISMAV.

Platform
[ x ] All
[ ] AntennaTracker
[ ] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

[Ryanf55]

Had you considered the reporting designed in REP-147?
https://ros.org/reps/rep-0147.html#flight-modes

[tizianofiorenzani]

Thanks for the link. I find the proposed FlightMode message a a little too reductive, as it limits interaction with only Guided/Offline and does not provide any actual detail of the underlying mode. For example the DDS interface provides input for joystick, which could be used to control a airplane in FBWB (copter guided is way more advanced).

We could use the VehicleStatus type for what I called the vehicle_type, use the proposed FlightMode as a simplified mode, but I'd also find it useful to provide the actual flight mode, the same as we provide to a Mavlink interface.

[timtuxworth]

frame_id seems confusing - in AP this might mean the frame_type/frame_class (e.g. if a VTOL is a X/H/Y frame and 4/6/8 motors etc) - whereas SYSID_THISMAV is not that.
Also SYSID_THISMAV is a number, not a string.

[Ryanf55]

frame_id seems confusing - in AP this might mean the frame_type/frame_class (e.g. if a VTOL is a X/H/Y frame and 4/6/8 motors etc) - whereas SYSID_THISMAV is not that. Also SYSID_THISMAV is a number, not a string.

frame_id is supposed to correspond to a coordinate frame, not a vehicle number. Each vehicle has it's own base_link of the "body" frame in AP terminology, and then attached sensors such as GPS, camera, rangefinder also have their own frames relative to that. I wouldn't worry about populating the frame ID with a value to differentiate which vehicle. Differentiating vehicles for swarming type operations is a separate issue here: #23567

I agree knowing the mode the vehicle is in is very useful because it can failsafe, or the GCS can change out of GUIDED while you are running some autonomous operation. To me it would be best if we published this with reliable transport on state change

• when the flight mode changed
• When failsafe is engaged/disengaged

Having Ardupilot manage the state will make it easiest for companion computer algorithms to abort, rather than all of them having to continuously check if the vehicle is in the correct mode.

[Ryanf55]

Also, can we call it /mode instead of /flight_mode because not all ArduPilot vehicles (Sub,Rover) fly?
Perhaps /mode_status or /current_mode?

[tizianofiorenzani]

Follow up:

• topic /ap/mode_status or /ap/status?
• published when status changes with reliable transport.
• fields:
  • frame_class
  • armed
  • failsafe (true when in failsafe mode)
  • mode (flight mode)
  • is_flying

[Ryanf55]

looking better - What's the meaning of is_flying on non-flight vehicles?

[tizianofiorenzani]

that is a good point, what can be a more generic term? Also, I know is_flying is well estimated for copters, but I am not so sure about planes.