G’day,
This can be a little confusing so I’ll try to explain a bit better.
PX4 and ArduPilot are different firmwares that both support Cube flight controllers and QGC, but not all commands are the same. You’re using ArduPilot, so you need to read the ArduPilot documentation and ask questions on their forum.
I’m still not sure we understand each other 
. Device I’m programming can use any version / format of MavLink packets to be able to communicate with the QGC. Cube itself does not modify the packets, so we can freely communicate Ardu/PX4 way. What I need to know, is what exact lib is used by QGC to parse the MavLink data. As my edit in previous post:
QGC Code repos seems to be linked to standard c_library_v2 library which is using mavlink_msg_camera_settings.h different to here posted by dogmaphobic upper.
So which code is exactly used by QGC to parse camera control packages?
You’re assumption about the cube not interfering is incorrect. It doesn’t forward messages it doesn’t know: so if you want to be flight stack agnostic you have to use messages included in both (this unfortunately likely requires source code inspection, not just comparing the mavlink repos)
Thanks for your time, unfortunately you are not esponding to my question. As written above CAMERA_SETTING packet has been delivered (screens above) in both cases (Ardu/PX4) (because CRC value has been modified to be understood by CUBE). QGC received both versions of CAMERA_SETTING well (seen in MavLink inspector as screen above).
Manual for camera control links to different packet #260 than provided by dogmaphobic structure. Qgcontrol code links to standard c_library_v2 which also contains different structure of #260 than here posted above.
So…can you please help me to find out which repo is used QGC to parse camera control packets?
The githash of the linked mavlink submodule gives you the version, (it’s mavlink/mavlink from a month ago), but I suspect what you’re running into is the combination of qgc camera handling and its autopilot plugins not currently supporting what you’re trying to do: @DonLakeFlyer is far better placed than I to comment on that. Might be better to shift this to a new thread btw.
OK, thanks. Of course I know the link gives me version of used MavLink icluded. As written before, version there contain different CAMERA_SETTINGS #260 structure than here provided by @dogmaphobic. That is making me confused…
Or QGC dynamically switch the MavLink libs between Ardu/PX4 depending on connected FC FW…?
If @DonLakeFlyer can look into, it will be much appreciated.
Qgc doesn’t switch mavlink libs based on connected flight stack, but does change what is presented and what features/functions are available
OK, so back to the roots of problem. If QGC does not dynamically change packets interpretation, there is something clearly wrong. QGC MavLink inspector also represents CAMERA_SETTINGS #260 packet different way to structure posted here above.
Only
boot_ms
mode_id
zoomLevel
focusLevel
No ISO / Aperture / Zoom values parsed.
Gus’ post from 3 years ago was a proposal. You need to work with what was actually implemented, or suggest improvements
This manual is also only proposal and is not valid?
(Because all I’m saing what is written there does not match reality. Just trying to discover how it is implemented now )
OK, so after reading of QGC camera control code its more clear.
It seems the process has changed from proposal here described (that’s a shame because it could be ArduCopter compatible) and manual does not include this newer information about exposure values exchange.
This routine seems to generate MAVLINK_MSG_ID_PARAM_EXT_REQUEST_LIST #321 as exposure parameters rquest. So, camera values are then reported by PARAM_EXT_VALUE packets, which are unfortunately not forwarded by Ardupilot because they are not included in the common.xml. That is the reason why I got no clue there is something missing in the whole protocol.
Hope this saves some time to others who eventually would like to follow the camera control manual and stuck at parameters exchange.
Exposure and such are handled through parameters. These are documented here:
Extended Parameters are documented as well:
Note that to support all this, the camera must provide a camera definition file as documented here:
That has been part of mavlink common spec for year+ now. Sounds like ardupilot common.xml is out of whack.
The management of the spec has been out of whack, which we’re trying to work through and resolve
By that I mean whatever common.xml is in the ardupilot build system. The one on the mavlink repo which QGC uses (which is actually the ArduPilot dialect) is working fine.
ArduPilot doesn’t has all required messages in their common.xml, especially not the param ext ones, and ArduPilot in addition doesn’t have a proper router, and that’s why ArduPilot based flight controllers can’t really work with the camera api.
I’m complaining about this since quite a long while, but ArduPilot has refused to do anything against it for that long while based on some “high principles”. So, @auturgy, pl don’t blame some dubious spec management conspiracies, but those who are responsible, and could change that within a single second 
@Everyoneelse You are somewhat waisting your time here discussing this, since it’s clearly all on ArduPilot’s plate. The only solution currently is to either switch to PX4 or compile one’s own ArduPilot version with the proper common.xml put in. Hope that helps clarifying this a bit.
1 Like