MavLink

[OlliW]

Hey folks,

this topic is not directly related to AQ, but maybe I may ask nevertheless
I'm implementing MavLink communication into the STorM32 gimbal controller, and face some issues with the AQ's stuff.

* I have done now the PARAM_REQUEST_LIST, PARAM_VALUE, PARAM_SET commands. With APM's Mission Planner things seem to work perfectly, however with AQ's QGroundControl the parameter reading get's stuck in the sense that the Onboard Parameter window displays "Requested param list ... waiting" and doesn't show the parameters. The Mavlink Message Inspector shows that the heartbeats are working, as well as that all parameters were read since the PARAM_VALUE entry shows the last parameter. It seems as if the QGC is waiting for or expecting some additional message to arrive to finally accept the parameters. What is needed to get AQ's QGC to read AND show the parameters?

* I tried to sniff the communication with the AQ M4, so I connected the M4 to a terminal expecting to see it's heartbeat ... however, the M4 just remained silent. What's the reason or how/when starts the M4 transmitting heartbeats? For what message from QGC is it waiting?

* a more general question, when QGC sends a message, and the receiver notices that but something goes wrong, e.g. that a timeout occurs because not sufficient bytes are coming in, or a crc error is detected, etc., what is the receiver supposed to do? Just nothing? Sending out an error message?
(I'm not asking about those commands where an ack is specified, such as e.g. COMMAND_LONG)

muchos gracias, Olli

[Max]

Hi Olli,

1) It might have something to do with which Component ID the AQ params handler is expecting (190, I think). I'm not sure but that's my guess. AQ QGC is somewhat specific to AQ in some ways, and especially in the "AutoQuad" main widget.

2) To which port did you connect and with what settings? The USB virtual COM port needs to be set to at least 1200 bps to start Mavlink (IIRC). The serial port on expander pads is set to use Mavlink at 115200 by default, I believe. There's no trigger to start Mavlnk data, it just starts sending at AQ startup. At any rate, you'll just see a bunch of junk via terminal anyway -- you can see the raw data via QGC if you want, in the Comm. Console (uncheck Compact, Hide MAVLink, and Auto Hold). It's not pretty.

3) In general it is up to the sender to verify that a message had the desired effect or got through at all. So usually some response is expected, in the form of a return message or ACK. There's no generic "please resend last msg" message, AFAIK.

Con mucho gusto,
-Max

[aBUGSworstnightmare]

Hi Olli,

you may want to have a look at the Mavlink part in the Mavlink2Spektrum project: viewtopic.php?f=33&t=3069

Well, this project uses an Arduino, but you should be able to figure out how to get the needed data from the Mavlink stream.

Run your UART at 115200 8N1.

Joerg

P.S. By the way: were to find info how to configure the STorm32 for 2-axis mode?

[OlliW]

[Max]

Olli,

1) It's Component ID, not MAV ID. The latter is "unique" for each connected AQ (as unique as 255 values can be ). The component ID is hard-coded at 190 ("MISSION_PLANNER" or something like that) for AQ (for some historical reasons I don't fully understand). The AQ params widget is looking for that component ID.

That whole part of the GUI is definitely AQ-specific (most of the buttons under the params list, for example), and in fact it could be somewhat dangerous to "allow" using it with other MAVs (though not a gimbal perhaps ). Mavlink is generic only to a certain point, when you start doing things like writing to eeproms, calibrations, restarts, etc, you really want to make sure you know what you're talking to. We actually had a "generic" params tree editor in there for some time as a widget, but it got removed because it was causing confusion and just slowing down param reloads, etc.

2) Yes, 42 is all you need to know!

3) You can set some timeout and retry options in QGC Mavlink settings -- the exact values will really depend on the link quality and speed. It makes sense if you think about it... the majority of mavlink messages are informative and don't require an ack -- the data is just being sent out repeatedly for anything that might be listening. OTOH if you're sending a command, or requesting specific one-time data (like params or waypoints), then the sender needs a retry system anyway in case of timeout w/out any response at all. The heartbeat (or PING) messages are used to maintain overall connection status.

-Max

[OlliW]

thx!

1) OK, so I set the comp ID to 190 -> still the same issue, I then in addition set sys ID to 243 -> same issue, I then set in addition autopilot to MAV_AUTOPILOT_AUTOQUAD -> still same issue, I then set in addition type to 0, then 1, then 2 -> still same issue (in the last case the values were sysid: 243, compid: 190, autopilot: 14, type: 0 o 1 or 2)
in each case the heartbeat is working, I can see it doing e.g. the mode
in each case the requested parameter list is read, I can see it in the Mavlink Inspector, because besides the heartbeat info also the PARAM VALUE info shows up, and it shows the correct entries for the last parameter
QGC only refuses to accept that the parameter list has been read, and to display it in the onboard parameter window. QGC seems to wait for something, or to require an additional condition to be satisifed.

???

EDIT:
a simple explanation could be that the QGC doesn't digest the param_count field in the PARAM_VALUE message, but has the number of expected parameters hardcoded, and expects the same number irrespective of the mav. ???

[Max]

Well, it was a guess, like I said. Could be all sorts of things really.

As for your edit, no, definitely not hard coded anything like that. The param tree will always show whatever params AQ has available in whatever fw. version is loaded, including any future versions.

-Max

[OlliW]

there must be however some cross dependence to something else, the native request_param_list and param_value mechanism as specified by the docu isn't working
I understand though that there might be no quick or obvious solution, as well as that there is no incentive for you to change anything here

thanks a lot however, the discussion has helped me considerably to understand this mavlink thing better!

cheers, Olli