Getting Updated Mavlink libraries in Ardupilot/Arduplane

I need to compile Arduplane with the latest Mavlink libraries. I am working on Runcam, GoPro (maybe GitUp) control with Mavlink and I need the camera protocol (https://mavlink.io/en/services/camera.html) and others-- many of which Ardupilot does not seem to have. In fact Ardupilot seems to be based on a fairly out-of-date Mavlink libraries (as opposed to PX4, which seems more current). Can I easily update my own Ardupilot fork with the latest libraries? It is not immediately obvious to me how right now. Generally, would it not be best to the latest libraries into Master anyway?

Any pointers would be great. Thanks.

(posed in Ardupilot/Gitter as well but no response).

The ArduPilot mavlink fork is regularly updated. “latest” is a debatable term: common.xml is (largely) developed upstream, and ardupilotmega.xml within ArduPilot, with a fortnightly sync meeting to keep things aligned. Not everything that goes into upstream is supported by ArduPilot, and not everything developed by ArduPilot is merged upstream. That’s the nature of things unfortunately.
If there is a need/use case for a currently unsupported message, raise an issue against the ArduPilot repo (firmware, not mavlink), so it can be looked at.
From memory the camera protocol, in order to add functionality not already available via digicam_control messages, requires mavftp, which is still WIP for ArduPilot.

Thanks James.

I am actually working to deploy Olli’s Storm32 NT Serial camera control. Right now I can do this on the bench only using Arducopter Nuttx binaries he has compiled. He has actually done some great work on this.

I will circle back and see if I can isolate what he needs and what is missing. It is only missing messages I think as that is all that I think he is adding.

In the longer term I hope we can develop the ability to use an ESP32 to convert Mavlink to serial/wifi camera control but right now I can do this with a Storm32 micro gimbal board and an ESP32 using Olli’s code.

Hey there, I am one of the ardupilot/mavlink fork maintainers. We only port non-“work-in-progress” messages from the upstream mavlink repo into out repo.

If those camera messages are “work-in-progress” (marked by the < WIP/ > tag) then we do not merge them. Our repo tries to use only stable messages when possible.

Hi @ amilcarlucas

Thanks for chiming in. I think some replies to my post were not public. @ olliw42 added some clarification. We just need some messages added for the purposes of routing from GCS/Storm32 GUI via AP to Storm32 controller. Essentially we just need the messages below added. Right now Olli has got this working by adding these to his older Nuttx builds but we need some messages added to master so we can get this into ChibiOS builds. For your interest here is where Olli is at with this. When we can get the extra messages into master, I can start a blog post here and hopefully we can get some more interest.

Here is the clarification Olli had in his reply:-----
ArduPilot does not have to support the newer messages. What only would be needed is that AP would route/forward them. So it’s totally sufficient to have them in your common.xml (as you know that by virtue of how Mavlink works it can’t route/forward messages those extra crc isn’t know to the router). No other code changes needed.

The camera protocol doesn’t need MavFTP at all. Also by virtue of what I just said that AP only needs to route the messages it’s irrelevant if AP supports MavFTP or not.

These are the missing messages needed to support Storm32 camera control:

PARAM_EXT_REQUEST_READ
PARAM_EXT_REQUEST_LIST
PARAM_EXT_VALUE
PARAM_EXT_SET
PARAM_EXT_ACK
These are missing and would be useful:
PROTOCOL_VERSION
TUNNEL

1 Like

Just to clarify something Olli mentioned to me-- these mavlink messages have nothing to do with the Storm32 gimbal – they are part of the Mavlink Camera Microservice. It just happens to be going though a Storm32 gimbal board.

So will you be able to add these Non-WIP messages? They will only be used for camera control so should have no bearing on anything else. Would you like me to move this onto Github?

Any progress on this? I have the same issue. I do not need the mavlink ftp service yet, from what I understood it should be possible to have the camera definition file online on http server and download it there. Then I only need to be able to set and get the parameters.
So I only need the mentioned messages
“PARAM_EXT_REQUEST_READ
PARAM_EXT_REQUEST_LIST
PARAM_EXT_VALUE
PARAM_EXT_SET
PARAM_EXT_ACK”
It would also be usefull to have the VIDEO_STREAM_INFORMATION" provided.

It’s probably worth having a discussion about what you’re actually trying to do. Pulling in from mavlink/mavlink will happen where it makes sense, but there’s no hierarchy / upstream “standard”. It could be that the behaviour you’re seeking is already possible via existing messages/parameters.

Well, my idea is to be able to use the QGC interface to control some the camera advanced settings. That would be eaysiest utilizing the camera protocol. Ideally I would send the HTTP adress of a definition file to the QGC in the CAMERA_INFORMATION message (yes, that would mean that for full functionality the device with the QGC would need to be connected to the internet when first coommunicating with the camera). That part works fine with Ardupilot, the QGC downloads the the definition file and offers the settings widget, but then the settings is to be sent and requested via the PARAM_EXT messages, which do not work with ardupilot. That means that I either need to change the QGC implementation to sent the messages from parameters protocol instead of extended paramater protocol (and reimplement the camera firmware accordingly), creating a hybrid which does not comply with the camera protocol, or I need the ardupilot to retransmit the PARAM_EXT messages. Or am I wrong?

OK. To get you going, I’d suggest trying serial passthrough to get things set up. If it’s a one-off configuration, this is probably good enough. https://ardupilot.org/copter/docs/common-serial-passthrough.html
It sounds like you’ve implemented a control mechanism under the belief that it’s a standard, when it isn’t. There’s some tidying up occurring in the mavlink org to reduce the likelihood of that happening into the future, basically because “common.xml” is misnamed. It’s never been a common set of messages. Implementers need to know what is actually “common”, what is an agreed “standard”, and what isn’t. Presently that isn’t possible, but it should be.
Moving on from that, for your particular camera is mavlink the best API? Often cameras with mavlink support have a native serial or canbus protocol that is richer and gives better control.

Well, my understanding of the common message set indeed was that it should be the “most universally” supported set of messages. Not only from the name “common”, but from the definition on the https://mavlink.io/en/messages/common.html. Am i to understand that that is not the case then? Is there a standart for semi-advanced setting of a camera (similar to camera protocol) that uses different set of messages?

Now the camera does have the possibility of being controled via SBUS, we have aimed to use MAVLink as another option.

The QGC offers the widget to set the camera when the camera definition file is present. Although your suggestet aproach (thank you) is definitely some step forward, it would mean that the camera settings is accesible only through 2-minute window. Now the camera protocol as is defined in the documentation and provided by QGC downloads actually set values on startup to have a “valid copy” of the sttings and then emits every change to the camera. While it would be possible (uncomfortable, but possible) to set the camera values this way, I see no way to download the actually values thi way. Tis would mean that the QGC would always display non-valid settings.

Maybe. But I basically gave up on this as amilcarlucas somewhat contradicted himself and then would not respond to me. It is simply not true that only non WIP messages are excluded from Ardupilot. I listed some that I needed and could get nowhere. There is obviously some way these are added to Ardupilot but I could get nowhere with it – I assume it would be easier as a vendor. I found compiling with manually edited submodules so tedious that I basically gave up on practically using OIlli’s Mavlink Camera control. It is quite tedious manually pasting in Mavlink messages that are overwritten constantly.

I was quite surprised at the lack of interest in just adding some stable messages from common mavlink messages. It seemed such a trivial thing to do.

I’ll have a look at param_ext again. They’re ugly: sending a big char array, whilst overcoming the limitation of only having a few floats, isn’t something we really want happening.
I’m also not convinced that the camera microservice will be around long once the component microservice gets worked out/matured.
Regarding WIP: true, not just those are left out. Things that basically duplicate what we already have, or are poorly designed, or create/expose problems etc tend not to get pulled in. Others there’s actually no good reason apart from nobody doing it.
Re other camera messages/protocols. There’s several. Do_digicam_configure obviously, but more broadly there’s a pr for visca, one coming for onvif, and a number already in the firmware (bmcc, runcam, GoPro etc).
Most of the high end stuff is integrated via a companion computer, not directly through the autopilot and mavlink.

That is fine. No need to do much of anything at this point – I moved on. I always thought there was likely a reason but it was just never expressed as such. I can understand why you may not want these messages going through the AP. It is just a pity that I could never really deploy what I had working on the bench – full GoPro control from QGC.

I was pondering if I should chim in or not, but now think I should, as it is one of the sad and unexplicable discussions where one really wonders if ArduPilot understands things.

ArduPilot would NOT have to do ANYTHING of all this.

The fundamental problem with ArduPilot is that the “router” which it implements is not a router at all but a whatever, which in fact does not even fulfill the most basic requirements required by the router specification, namely to also route unknown messages (which e.g. any other router on planet like mavlink-routerd and others do).

The only and really reason for why one has to add these other messages into ArduPilot’s xml is for exactly this reason, to make ArduPilot able to route them.

All this talk about WIP and “we do not like this message” and “ohhuhuhoho” hence turns out to be nothing else than a distraction. Given how long this sort of topic and responses are around and that it’s not like that it wasn’t mentioned before so they couldn’t know one only can speculate that this is by purpose.

Moreover, adding the missing messages to their xml would NOT do any harm at all, since adding the message in no way means that they would have to implement any support or change a single line of code. It would be zero effort and zero cost and zero brain. Yet they massively refuse to do it. One again concludes that all this talk about WIP and “we do not like this message” and “ohhuhuhoho” is just exactly this.

Sadly, ArduPilot’s attitude in this and such matters is certainly not to the benefit of the community.

This example here should be evidence enough. It only can be called sad that it made Marc_Dornan to not use something which he 2 years ago had been very interested in and which he probably could have had much use of.

Very sad. But actual fact.

Well there is some truth to this. Essentially there was a good solution for fully controlling GoPro Hero 7, 8, 9 from ardupilot. But I found keeping the Mavlink library manually updated sooo frustrating that I gave up. Every time you do a sub module update you lose the messages and have to retrieve them again.

I mean it literally is just adding a few stable messages so that Mavlink can be routed…

1 Like

Well, the DO_DIGICAM_CONFIGURE is hardly a protocol, does not allow custom parameters, the ground station has no way of knowing the possible values… the rest are only for existing cameras if I understand correctly.

While I agree that Extended parameter protocol as part of camera protocol is overkill and simple Parameter protocol would be sufficient, i find it very sad it is not included, basically agreeing with olliw42.

Thank you for the explonation at least.