Missing ArduPilot mavlink support to light up QGC features

[DonLakeFlyer]

Click to Orbit support

• MAV_CMD_DO_ORBIT, MAVLINK_MSG_ID_ORBIT_EXECUTION_STATUS
• This allows you to click to specify where you want to fly to and dynamically adjust the orbit radius.
  

New ROI commands

• MAV_CMD_DO_SET_ROI_LOCATION, MAV_CMD_DO_SET_ROI_WPNEXT_OFFSET, MAV_CMD_DO_SET_ROI_NONE replace the single MAV_CMD_NAV_ROI command.
• This is mostly a reorganization of a single one size fits all command into more specific individual commands.
• This lights up these features in QGC:
  • Click in map to set ROI from fly view as well as cancel
  • Simpler creation of missions which use ROI. You don't need to show the user some crazy complex pile of settings to support old MAV_CMD_NAV_ROI
    
    
  • Structure Scan complex pattern in Plan. This needs the new MAV_CMD_DO_SET_ROI_WPNEXT_OFFSET support to work.
    

Support for newer Camera and Gimbal commands

• MAV_CMD_SET_CAMERA_MODE, MAV_CMD_DO_MOUNT_CONTROL, MAV_CMD_IMAGE_START_CAPTURE, MAV_CMD_IMAGE_STOP_CAPTURE, MAV_CMD_VIDEO_START_CAPTURE, MAV_CMD_VIDEO_STOP_CAPTURE, MAV_CMD_DO_SET_CAM_TRIGG_DIST
• Mission Planning
  • These allow for a simpler ui for manipulating a camera/gimbal. In QGC this capability is available on every waypoint you add. Here is what it looks like with the camera section expanded:
    
• QGC Joystick support allows you to control the camera and gimbal which in turn uses all of these messages: Example:
  

Follow Me

• FOLLOW_TARGET
• This allows a gcs to implement follow me in a generic way

Ready to Fly

• MAV_SYS_STATUS_PREARM_CHECK
• Shown here: Ready To Fly support based on MAV_SYS_STATUS_PREARM_CHECK mavlink/qgroundcontrol#8968

ArduPilot dialect messages:

• MAVLINK_MSG_ID_CAMERA_FEEDBACK, MAVLINK_MSG_ID_WIND
• QGC currently supports these but it would be nice if ArduPilot also spit out the common dialect versions of these messages so QGC doesn't need to have any specific ArduPilot dialect stuff in it.

Surveys which capture images right up to the survey edge

• MAV_CMD_CONDITION_GATE
• If you just use a waypoint at the end of a transect you can't really trust it to the stop camera triggering at a reasonable place. This is due to the mission state machine moving to the next command once it hits acceptance.
• Because of this most surveys need to be planned with additional turnaround even for multi-rotor that go past the survey edge. And also you have to capture images in these turnarounds as well to get good coverage over the actual survey area edges you want.
• This in turns generates a lot of crap images outside your survey area you don't really want.
• The condition gate command holds the mission state machine such that it wont advance until the vehicle fly past an orthogonal line. This allow you to the stop camera triggering after that. Which in turn allows you to only trigger the camera inside the portion of the transect which is inside the survey area. And you can stop the camera at a more precise spot. This allows capturing images right up the transect edge in a repeatable way without having to capture in a turnaround. Generating way less crap data to process.

New Mavlink Camera microservice

• https://mavlink.io/en/services/camera.html
• This allows a gcs to not only know if the vehicle has cameras available but also what feature the camera(s) supports.
• Which in turn allows a gcs to procide a rich ui to the user: Unified photo/video control which works with mavlink cameras and and video stream mavlink/qgroundcontrol#9003

COMPONENT_INFORMATION microservice

• This allows you to get metadata about the vehicle in a known way.
• First support is for parameter metadata.
• It also includes generic spec for how to support language translations in json data. This in turn supports parameter metadata which can be translated. So if your gcs is running in German the parameter editor shows all the parameter metadata in German as well.
• Coming support for:
  • What commands does a vehicle support within missions
  • What are the known Mavlink FTP locations on the vehicle. This allows a gcs to provide a nicer FTP ui to move files to/from the vehicle. Thinks logs, scripts, etc.
  • Flight dynamics information about the vehicle which allows a gcs to do things more intelligently/safely. For example: Currently QGC has a global app settings for VTOL transition distance. It then uses this for creating plans when you add a takeoff item and a VTOL Landing Pattern. It creates them with a valid amount of distance for the transition to take place. A global app setting for this is crap, but it's the best I can do now. The vehicle really needs to tell the gcs what the value is. There are many many other cases for information like that which would be included.
  • On and on and on...
• Discussion is here: Using COMPONENT_INFORMATION to obtain vehicle metadata mavlink/mavlink#1346

BATTERY_STATUS.charge_state reporting

• At least from SITL testing it seems that the field is not supported
• QGC uses this information for spoken battery warnings to the user as well as high level battery indicator coloring
• Full details here: Full support for BATTERY_STATUS mavlink message mavlink/qgroundcontrol#9019

MAV_CMD_DO_CHANGE_SPEED not implemented according to mavlink spec

• QGC has UI for change flight speeds like this:
  
• This is disabled for ArduPilot because if you look at these two places:
  • https://mavlink.io/en/messages/common.html#MAV_CMD_DO_CHANGE_SPEED (look at the spec for param1)
  • https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/GCS_Mavlink.cpp#L751 (look at the code for param1)
  • You'll see that they don't match up. QGC implements to mavlink spec, but ArduPilot doesn't.

[DonLakeFlyer]

Added COMPONENT_INFORMATION

[khancyr]

hello,

Thanks for the list ! Some point are really interesting.

[DonLakeFlyer]

I pulled off the WIP. I think I have most everything listed now.

[Sextant]

Thanks for posting this DonLakeFlyer, I am very interested in the Click to Orbit support.

[olliw42]

@DonLakeFlyer
I shouldn't ask here since unrelated to AP but to QGC, yet it's triggered by this here.
As regards

Camera and Gimbal commands for simpler mission planning
MAV_CMD_SET_CAMERA_MODE, MAV_CMD_DO_MOUNT_CONTROL, MAV_CMD_IMAGE_START_CAPTURE, MAV_CMD_IMAGE_STOP_CAPTURE, MAV_CMD_VIDEO_START_CAPTURE, MAV_CMD_VIDEO_STOP_CAPTURE, MAV_CMD_DO_SET_CAM_TRIGG_DIST

are these send by QGC as broadcast or with target? (i.e. are they reached by flight controller, gimbal, and camera)(is relevant to know to prevent multiple recipients acting simultaneously)

[DonLakeFlyer]

This is for missions. A mission is targeted to the autopilot component of the vehicle as a whole. This is not COMMAND_LONG. What the vehicle does with them eventually as far as routing is up to the firmware.

The other usage is for the mavlink camera microservice but that is a different thing.

[olliw42]

This is for missions. A mission is targeted to the autopilot component of the vehicle as a whole. This is not COMMAND_LONG. What the vehicle does with them eventually as far as routing is up to the firmware.

ah. Thx. I'm kind of always thinking that a CMD should be supported both in mission and as message, but I see now that you were talking about the first while I was concerned about the second. Thx for clarifying.

[DonLakeFlyer]

Added section on QGC Joystick support using the new camera/gimbal commands for button assignment.

[DonLakeFlyer]

Also just to reiterate the importance of this stuff to ArduPilot customers these sort of reports against QGC on forums posts or folks entering Issues as QGC bugs reporting this or that doesn't work happens all the time. I spend a lot of time having to tell people sorry ArduPilot doesn't support that feature.

[DonLakeFlyer]

Added BATTERY_STATUS.charge_state

[DonLakeFlyer]

Added MAV_CMD_DO_CHANGE_SPEED problems:

• https://discuss.ardupilot.org/t/auto-mission-hover-speed/60849
• https://discuss.ardupilot.org/t/cant-change-default-speed-in-survey-or-wp-mission/60000