[WIP] Improve gimbal support #10667

Due to how Ardupilot manages cancel ROI, we can not use the standard ROI indicator. Hopefully it will be solved in AP in short

Before commanding a gimbal we need to acquire control of it. If someone else is in control, we should ask the user if they really want to take over control or not. For instance the gimbal could be controlled by a companion computer or the autopilot itself as part of a mission and a user might not want to interfere. If no-one else is in control, then we silently acquire control. This control acquisition only works if the gimbal_manager_status message is sent out. We might have to request it at a certain rate. Signed-off-by: Julian Oes <[email protected]>

I don't think we're supposed to filter messages coming from the gimbal device as they could be sent directly from a gimbal rather than the autopilot. Signed-off-by: Julian Oes <[email protected]>

Signed-off-by: Julian Oes <[email protected]>

This still needs implementation in some way for PX4. Signed-off-by: Julian Oes <[email protected]>

This is just a first skeleton. So far, all it does, is request the gimbal information message. Signed-off-by: Julian Oes <[email protected]>

We don't want to use the term GimbalManager because that gets confusing because the MAVLink protocol also uses the GimbalManager term. Signed-off-by: Julian Oes <[email protected]>

We now request and handle - GIMBAL_MANAGER_INFORMATION - GIMBAL_MANAGER_STATUS - GIMBAL_DEVICE_ATTITUDE_STATUS in the GimbalController class. Signed-off-by: Julian Oes <[email protected]>

I needed the updated gimbal flags. Signed-off-by: Julian Oes <[email protected]>

This is an intermediate work in progress state trying to move the gimbal functionality over to the separate class. What's currently missing is the selection mechanism to chose between multiple gimbals and an API to then command a specific gimbal. Signed-off-by: Julian Oes <[email protected]>

Signed-off-by: Julian Oes <[email protected]>

The attitude one was missing. Signed-off-by: Julian Oes <[email protected]>

Signed-off-by: Julian Oes <[email protected]>

Somehow this caused trouble loading the connection bar. I don't quite appreciate or like the implementation of this helper and decided to just ignore it and send the command directly. Signed-off-by: Julian Oes <[email protected]>

Early return missing return, duh. Signed-off-by: Julian Oes <[email protected]>

I believe we can add that back in properly soon. Signed-off-by: Julian Oes <[email protected]>

Work in progress. It doesn't do anything yet. Signed-off-by: Julian Oes <[email protected]>

…l_manager_status at 0.2 Hz: In case the autopilot doesn't have a default rate for this message

For Ardupilot this wasn't enough sometimes if QGC connects right when vehicle is connected. For some reason the request isn't processed, probably because of some issue with the request messages implementation in Ardupilot, so it should be fixed at the Ardupilot level, but incresing it from 4 to 6 isn't a big deal as it will only happen in the initial handshake, and it allows us to continue working

… long notes: Implementation was based on the assumption that all the gimbal managers would have a different compId, which is not always the case. As per mavlink documentation: https://mavlink.io/en/services/gimbal_v2.html Discovery should be based on GCS sending a MAV_CMD_REQUEST_MESSAGE for GIMBAL_MANAGER_INFORMATION and we should instantiate gimbals when we receive response to this message. This commit introduces several modifications toi allow this. This was needed because otherwise the existent implementation would not allow multi gimbal systems with gimbals belonging to the same compid to work correctly

This includes: - Respecting the flags which determine the yaw frame of reference. - Using the Euler angle conversion ZXY which has a singularity at high roll but not at pitch down which is used much more often. Signed-off-by: Julian Oes <[email protected]>

This is needed for UI to detect changes in that vehicle's property. It is returning now gimbal 1 from gimbalController, and maybe the architecture on that regard will change, hence marking this as provisional

…tor for debug

This is needed in order to do nicer the frontend, so we can access Q_PROPERTY's from each gimbal to display on the UI. It potentially opens the possibility of calling Q_INVOKABLES on the gimbal itself as well. GimbalController was declared as a friend class of Gimbal, it is the only class that will actually modify values and it makes the code more compact overall

For some reason the Eigen based conversion was odd in yaw. It would only represent 0-180, and when passed that, it would go to 0-180 again instead of representing the negative (left) part of it

…hicle. Needs rework: it needs to account for adquirecontrol, etc and also some functions are using APM custom commands

…ap when hidden: In video view there is no point on having this enabled. Also when we hide this panel, we automatically remove the take coords from map feature, it was confusing otherwise

…elease gimbal control

There is a new signal showAcquireGimbalControlPopup that qml takes to show a popup asking the user if desiring to take control. In gimbal controller, we have a new method _tryGetGimbalControl() which we invoke prior to attempting any kind of gimbal control. This function emits the signal to show the popup if needed, returning false so the actual action isn't sent, and it returns true if the actual action could be sent ( if we are in control or if nobody is, although in the later it will also adquire control )

Moving towards multigimbal support

So we no longer use by default gimbal 0

it will show acquire or release depending on if we are or not in control

…re gimbal control

This qml class is meant to be used to aesthetically match the looks of ToolStripHoverButton, but without depending on the whole concept of ToolStripAction, which is handy to work on toolbars with simpler action Complexity

Whenever we have a gimbal active, a button will appear in the gimbal toolbar to select between the available gimbals. This will set the new gimbal as active gimbal, and all the commands will control it instead

…vehicle

…onger in vehicle

… in vehicle

so they are aligned with the name of the function

…anagerPitchYaw

…k as argument

Signed-off-by: Julian Oes <[email protected]>

We don't need this separate yaw lock call as the flags are already sent as part of sendGimbalManagerPitchYaw which uses follow mode. This caused problems because it leads to the situation where two consequtive GIMBAL_MANAGER_DO_PITCH_YAW commands are sent, first for the flags, second for the pitch and yaw values. The second one is dropped with a warning because the "same command" is still pending. Signed-off-by: Julian Oes <[email protected]>

This is my attempt at getting gimbal relative and absolute control working, using a joystick and by point and click. It cleans up a couple of methods that I believe were not actually used. Signed-off-by: Julian Oes <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] Improve gimbal support #10667

[WIP] Improve gimbal support #10667

Commits on Jan 15, 2024