Hey Folks
I would need your advices and recommendations.
I’m in the course of reworking the MAVLink support of the STorM32 gimbal controller, mainly because I want to integrate the camera microservice messages, which requires MAVLink 2 which the STorM32 didn’t yet do, but also because MAVLink has progressed significantly and I considered it time to catch up. The general idea is to make it as “MAVLink compatible” as possible.
MAVLink 2 and several new messages are already working fine, so that’s no the issue, but unfortunately there are quite a couple of points, related to the MAVLink version negotiation and some new MAVLink features, which are unclear to me, and which I couldn’t figure out despite having deeply dived through the docs.
I would greatly appreciate if you could help clarify them.
A. MAVLink Version negotiating.
This is the major part where I’m unsure how a gimbal controller should behave.
Please note that a gimbal controller may be used as both a “system” (e.g. when connected directly to a GCS, an Arduino, and so on) and a “component” (e.g. when connected to a PixHawk flight controller).
To make the story short, I won’t attempt to describe all my thoughts; pl assume that I carefully and repeatedly read the docs and was trying to make best sense of it, but that I do see (edge) cases where it’s unclear to me how a component and the STorM32 in particular should behave. So let me describe just what it currently does:
The messages can be differentiated as “outgoing”, such as e.g. a heartbeat or mountorientation, and “incomming with a potential response”, such as a command_long or param_request_list.
It also has a configuration parameter which can be set to Mavlink1 and Mavlink2.
It currently does this:
-
Outging messages are emitted using the version specfied by the parameter. If the outgoing message is MAVLink2 but the parameter is MAVLink1 when this message is dropped and not emitted.
-
When the parameter is set to Mavlink1, then incoming MAVLink2 messages are ignored, and a required response is send also in MAVLink1.
-
When the parameter is set to Mavlink2, then both incoming MAVLink1 and MAVLink2 messages are accepted, and a required response is send in the same version as the incoming message.
Is this what you would expect the STorM32 to do? What is OK what is not OK?
B. HeartBeat, autopilot field
So far the STorM32 used its own value in the heartbeat’s autopilot field, but reading through the docs it seems to me that the proper value would be autopilot = MAV_AUTOPILOT_INVALID.
Is this what you would expect the STorM32 to use?
C. HeartBeat, type field
So far the STorM32 used it’s own value in the heartbeat’s type field. However, there is now a MAV_TYPE_GIMBAL value in the enum (Messages (common) · MAVLink Developer Guide) and it appears obvious that this should be used.
However, the docu also says
type: Type of the system (quadrotor, helicopter, etc.). Components use the same type as their associated system.
This would IMHO represent a real issue.
- First, in case the STorM32 is not connected to a flight controller one would want it to show type = GIMBAL.
- Second, this requirement would imply that a component must wait for a heartbeat from the system to arrive, which implies that the component must know which heartbeat is the one from the system !!! I can’t see how that could be achieved without additional configuration parameters, which would be most inconvenient from a usability perspective.
- Third, I can’t see a generic way for the STorM32 to decide if its the first or the second situation, which would imply the need for further configuration parameters, which would be most inconvenient from a usability perspective.
- Fourth, this requirement actually doesn’t make any sense to me. Why should a component not be allowed to tell what sort of a kind it is. This loss of information can also create issues, e.g. it might be useful to figure out which ID/messages are related to the gimbal, which would not be possible.
My conclusion would be that the type should be GIMBAL in all cases.
What would you expect the STorM32 to do?
D. MAV_PROTOCOL_CAPABILITY
I find these values in the enum
- MAV_PROTOCOL_CAPABILITY_PARAM_FLOAT: Autopilot supports the new param float message type.
- MAV_PROTOCOL_CAPABILITY_PARAM_UNION: Autopilot supports the new param union message type.
Could you please explain what this means, what these are?
E. PROTOCOL_VERSION, MAV_CMD_REQUEST_PROTOCOL_VERSION, AUTOPILOT_VERSION, MAV_CMD_REQUEST_AUTOPILOT_CAPABILITIES, AUTOPILOT_VERSION_REQUEST
The docs appear to be quite inconsistent as regards this set of messages.
Here MAVLink Versions · MAVLink Developer Guide it appears very clear. However, PROTOCOL_VERSION is marked in big red letters as WIP and that it should not be used.
Later below, MAVLink Versions · MAVLink Developer Guide, there is then no talk of PROTOCOL_VERSION, but of AUTOPILOT_VERSION. However, there is no obviously related message in common.h which would allow oneto request AUTOPILOT_VERSION. Is one supposed to emit it periodically? What’s then the deal of it, since heartbeat does this already?
I note, ArduPilot in fact has added and uses a AUTOPILOT_VERSION_REQUEST in its dialect.
To make it totally confusing, there further is a MAV_CMD_REQUEST_AUTOPILOT_CAPABILITIES, but it’s totally unclear what should be send out as response. PROTOCOL_VERSION? AUTOPILOT_VERSION? ??
Currently I’ve followed the path of ArduPilot & MissionPlanner, which use ArduPilot’s AUTOPILOT_VERSION_REQUEST, and made the STorM32 to respond to it by sending a AUTOPILOT_VERSION. This works nice with MissionPlanner, but not at all with QGC.
What would you expect the STorM32 to do?
Lot’s of stuff, I know, sorry for that. Maybe you nevertheless could find time to provide some guidance.
Many thx,
Olli
