Mount: issues with multi-gimbal support

[rmackay9]

PR https://github.com/ArduPilot/ardupilot/pull/21614 improved support for multiple gimbals but during discussion and testing several issues and enhancement became clear

• [ ] Ground stations (including MP) cannot set the mode of a single gimbal - instead all gimbals change mode. For example a Mission Planner user might want to use the "Set Mount" button to switch a gimbal to "RC Targeting" to allow the pilot to take manual control of the gimbal but this will affect all gimbals. The underlying problem is that the MAV_CMD_DO_MOUNT_CONTROL (see MAVLink Interface wiki here) does not include a "gimbal id" field. Possible fixes include:

  • Change handling of MAV_CMD_DO_MOUNT_CONTROL to only affect the primary gimbal
  • Create a new mavlink message called MAV_CMD_DO_GIMBAL_MANAGER_SET_MODE similar to MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW (see here)

• [ ] Similar to above, MAV_CMD_DO_SET_ROI_LOCATION and MAV_CMD_DO_SET_ROI_SYSID also affect all gimbals. The issue is that we are not consuming the "Gimbal device ID" fields of these messages. See note here in AP's ROI handler.

• [ ] Need an RCx_OPTION for "Mount2 Lock" because currently users can only switch between earth-frame and body-frame (aka lock and follow) using the RC (during RC targetting) for the first gimbal

• [ ] Users need to setup twice as many RC channels to control two gimbals when in RC_TARGETTING mode. Perhaps we should add a new RC option that allows users to specify which gimbal they wish to control. For example if this new RCx_OPTION is at the low position, the RCx_OPTION = Mount Yaw, will control the 1st gimbal. When in the middle or high position, the pilot controls the 2nd gimbal.

[WickedShell]

Could you use other component ID's on the aircraft to map out gimbal id's? To make it even better there are already 6 pre reservered MAV_COMP_ID_GIMBAL values.

[rmackay9]

Hi @WickedShell,

Txs for the feedback. I think the issue is really with the GCS<->autopilot communication. There's just no way for a GCS to specify which gimbal it wants to control in some cases. The "mode" is maintained in the autopilot so although we say, "gimbal mode" we should perhaps say "gimbal driver mode" or "AP_Mount's mode"

[olliw42]

Create a new mavlink message called MAV_CMD_DO_GIMBAL_MANAGER_SET_MODE

while irrelevant, just fyi, my 2 cents:

I am strongly opposed to such a message

as confirmed here https://github.com/ArduPilot/ardupilot/issues/20985 the current mavlink spec lacks a way for handling such a thing as the old mount mode. However: This has NOTHING to do with only the gimbal or only the gimbal manager, and hence should NOT be attached by name nor logically to it. I very much think that there is something like a logical architecture, and that the messages and their usage should refelct the architecture. I called it temptatively super mode, which is a stupid name, but infinitely better than gimbalmanager mode.

in the design of the gimbal manager concept such situations had been specifically considered and thought through, with the implication that it provides some primitives and concepts to handle them. It is sad enough that the gimbal manager concept is screwed by the currently suggested mount implementation in AP, but to wanting to screw it up on the protocol level by adding such messages is yet a more massive thing. I strongly hope it never would make it into the mavlink standard.

yes, gimbal v2 is not (yet) perfect, but I think you guys will eventually discover that your stance that gimbal v2 looks unnessecarily complicated and is not to be used will disolve, as you will just run into the very same issues which were discussed when gimbal v2 was designed, and will have to work them out at cost of your time. Frankly, it is really just the usual ArduPilot-dev attitude which prevents ArduPilot from making more progress with less efforts.

[rmackay9]

@olliw42,

While I always appreciate your input, I think comments like this don't actually help us get to a solution, "Frankly, it is really just the usual ArduPilot-dev attitude which prevents ArduPilot from making more progress with less efforts.". I'm a big boy and I'm not hurt but it's just not helpful.

Anyway, putting this aside, I'll respond on the other thread and maybe we can figure out how to resolve the issues I've outlined in this issue.

[olliw42]

I disagree. I have to say that you are about the most friendly person I have seen on the inet. yet I think ArduPilot would do much better in various areas if ArduPilot devs would not have this what looks like a common attitude. If no one ever says, you even could rightfully claim you couldn't know. From my side it is an absolute pain to over and over work against this incredible resilence and ignorance, which I find not very intelligent, and it is really just the altruistic and idealistic part in me which lets me doing it, not because it would be such a great pleasure. I agree however in that I went too far, and should not be doing this, I'll adjust.

[WickedShell]

Hi @WickedShell,

Txs for the feedback. I think the issue is really with the GCS<->autopilot communication. There's just no way for a GCS to specify which gimbal it wants to control in some cases. The "mode" is maintained in the autopilot so although we say, "gimbal mode" we should perhaps say "gimbal driver mode" or "AP_Mount's mode"

My point here is that by targeting a different component id you can differentiate what gimbal you want the command to be for. That's how MAVLink is intended to be used, target different component ID's. Arguably a smart gimbal should be listening to some of these messages itself, and if we have a situation where ArduPilot is proxying for some other gimbal front end it seems very logical for us to respond as those components as well.

[rmackay9]

@WickedShell,

OK, but I'm not sure I agree that the autopilot should be filtering through the messages the GCS is sending directly to some gimbals, intercepting them and then doing something else with them or replying in place of the gimbal. I think in some network setups (where the autopilot isn't in the middle) that's not even going to be possible.

Anyway, I hear what you're saying at least ...