Impact of new "gimbal manager" mavlink commands on Storm32 and Alexmos gimbal controllers

[jstroup1986 (Joseph G Stroup Jr)]

@rmackay9 - I hope you don’t mind me tagging you on this post.

I haven’t looked into the new gimbal control functions for Gremsy gimbals - but today I noticed the new Mission Planner mission statement: DO_GIMBAL_MANAGER_PITCHYAW

In my previous missions I’ve used the DO_MOUNT_CONTROL to control my gimbal.

I looked up both these commands in MavLink.IO and I’ve got some concerns:

These references say that MavLink 205 (DO_MOUNT_CONTROL) is not deprecated.

As I recall, ArduPilot supports a number of deprecated MavLink commands. Can someone please confirm that DO_MOUNT_CONTROL is one of them - and will continue to be supported?

I also noticed that MavLink 287 (DO_GIMBAL_MANAGER_PITCHYAW) is a MavLink 2 command.

Storm32 gimbal controllers support both MavLink 1 & 2, but I think the vocabulary of MavLink 2 commands is limited to the specialized GoPro controller boards that were never really adopted by many users.

AlexMos only supports MavLink1. According to AlexMos docs, it’s proprietary serial protocol has extended functionality. ArduPilot has this option - but I found that AlexMos controllers work better with just MavLink.

I’ve recently been talking with a representative of ViewPro. She confirmed that their Z-6KA7 product has encoders and supports MavLink. I’d be really surprised if they developed their own controller with these features - so I’ve asked her to see if she confirm that they’re using an AlexMos controller. (AlexMos supports encoders. As I recall Storm32 encoder support is not well developed - if it exists at all)

I’m glad to see the effort the DEV’s have applied to have better support for Gremsy gimbals. The gimbal market has been dormant for many years - but it now seems to be springing back to life.

If any of the new MavLiink commands support proprietary Gremsy functionality, then these should be well identified in the MavLink docs - and maybe the command names.

If the new MavLink commands are generic - I hope new gimbal manufactures have enough information to take advantage of them.

Testing the DIY products such as Storm32 and AlexMos would also be really useful.

Thank you.

[rmackay9]

@jstroup1986,

Txs for the interest in the gimbal support.

One thing to remember is that the protocol used between the GCS and the autopilot can be completely different than the protocol used between the autopilot and the gimbal. So for example a servo gimbal using PWM should act the same as a Gremsy gimbal using MAVLink.

The do-gimbal-manager-pitchyaw command is really a command from the GCS to the autopilot and/or a command stored in the mission list (again for the autopilot). So there’s no need for gimbals to understand this message.

Re do-mount-control, there are strangely two versions of this command in the mavlink spec. There’s the ArduPilot specific MOUNT_CONTROL message which is deprecated) and then there’s the common MAV_CMD_DO_MOUNT_CONTROL which still works but which I would like to deprecate at some point. For now it must remain though because it is the only way to change the gimbal driver’s mode (e.g. RC_TARGETTING, MAVLINK_TARGETING).

If you have a chance, please give the new DO_GIMBAL_MANAGER_PITCHYAW command a try. I hope you’ll find that it’s better than DO_MOUNT_CONTROL because it adds the ability to specify whether the yaw is in body-frame or earth-frame (aka “follow” vs “lock”).

[jstroup1986 (Joseph G Stroup Jr)]

Thanks for your explanations.

When I tested Storm32 and AlexMos gimbles with PWM, Mavlink and proprietary serial interfaces, the gimbals did not react the same in all cases. This was especially true for commands like “point camera here.”

So your statement that a servo gimbal using PWM should act the same as a Gremsy using MavLink may require some refinement.

When these gimbal improvements were announced, I recall they were addressed specifically to Gremsy gimbals. But from your message here, I get the impression that the changes broadly effect any gimbal controller using MavLink. Please clarify this. Maybe the changes weren’t designed just for Gremsy gimbals - but that Gremsy gimbals would also benefit from the changes.

As there’s been an increase in gimbal development recently (after a lull of 5 or 6 years) it’s important to know exactly how the new developments effect which type of gimbals.

Is it possible to clarify that - either here or in the wiki? A comprehensive explanation of what we couldn’t do - but we an now do - would be really helpful. That, along with what is required of the gimbal to take advantage of the changes. For example - if MavLink-2 is required - and in what way.

Regarding the body-frame versus earth-frame yaw issue, I think this is more of an issue for fixed wing aircraft - as rotor aircraft have full mobility in yaw.

And there is a cable winding problem. Some gimbals use slip-rings that allow unrestricted yaw rotation - but these are not common. Interestingly - AlexMos supports an “unwind” command. It has the ability to keep track of the yaw rotations - and “unwind” them.

None of my Storm32 or AlexMos gimbals are mounted presently on flying copters. I’m hoping to evaluate a Viewpro Z-6KA7 in the near future. When I do I’ll be able to give the new ArduCopter features a full evaluation.

http://viewprotech.com/upfile/2018/11/20181126215323_695.pdf

Thanks for your leadership in this area - I’m glad to see it getting some attention again.

[rmackay9]

@jstroup1986,

A few points:

• In general all the gimbals should act the same regardless of which protocol they use. So for example, a user should be able to get any gimbal to point at a particular Location or lean angle, etc. Some gimbals have more controls or more range but in general they should all act the same.
• The Gremsy gimbals were the first we started working on. Next was the Siyi Z10/A8 and DJI RS2/RS3-Pro. Next is the ViewPro and then there are two more that have appeared recently.
• the “lock” vs “follow” feature (aka “earth-frame” vs “body-frame”) is important for multicopters as well. Sometimes a pilot will want to “lock” the gimbal’s yaw in a particular direction as they’re flying, other times they want the gimbal’s yaw to “follow” with the vehicle. Specifying this setting (in real-time) is possible now both when manually controlling the gimbal (aka RC_TARGETING) or when controlling as part of a mission or using GCS controls.

A big missing piece at the moment is improved GCS controls but one dev has stepped forward to work on this.

Thanks for considering testing. Any help with beta testing is very much appreciated!

[olliw42]

@jstroup1986

rmackay9 has given you already substantial answer (even though not every little detail is correct IMHO), nevertheless I’d like to give you some updated info on the STorM32 controller:

DO_MOUNT_CONTROL

STorM32 does support the MAV_CMD_DO_MOUNT_CONTROL and MAV_CMD_DO_MOUNT_CONFIGURE commands, and will continue to do so for a long while.

STorM32 does not support the DO_MOUNT_CONTROL and DO_MOUNT_CONFIGURE messages anymore, which never had been in the standard specification but were ArduPilot-specific, and ArduPilot has deprecated them (= there should be no need nor reason to ever miss them).

Storm32 gimbal controllers support both MavLink 1 & 2, but I think the vocabulary of MavLink 2 commands is limited to the specialized GoPro controller boards

STorM32 fully support MAVLink 2, but not really MAVLink 1, i.e., some things may work with MAVLink 1, but you really should use MAVLink 2 for STorM32. It supports quite a number of MAVLink2 messages, and not just a small vocabulary. For the complete list pl see MAVLink Communication - STorM32-BGC Wiki.

As I recall Storm32 encoder support is not well developed - if it exists at all

STorM32 supports encoder since 5 years (!), and it is well developed. It is then called T-STorM32, pl see here What is T-STorM32 about? - STorM32-BGC Wiki

If the new MavLink commands are generic - I hope new gimbal manufactures have enough information to take advantage of them.

the messages and commands of the new MAVLink gimbal protocol v2 are generic, and were carefully developped with this in mind. The STorM32 controller was the first controller adopting them, and in fact was deeply involved in the development of the gimbal protocol v2.

I get the impression that the changes broadly effect any gimbal controller using MavLink

yes, even though I’m not at the same ArduPilot expert level as rmackay9, I would agree to that. I would also say that the situation concerning support for STorM32 (and other gimbals using MAVLink) is currently mediocre. A major problem comes from the fact that STorM32 implements a MAVLink gimbal component which adheres to the official MAVLink standard while ArduPilot breaks the standard in few ways. Overall the changes made by ArduPilot are however a big step forward, weeding out some long standing bugs and issues, and moving in a forward direction. Even though they imply some changes for the user, you probably should welcome them.

As rmackay9 has pointed out, a big issue, which really diminishes user experience currently, is lack of proper support in some GCSes, like e.g. MissionPlanner.

A last comment, which seems to produce confusion sometimes: The above comments are of course for latest firmware (some users use the 7 years old v0.96 firmware and are then surprised that it is - well - old).

Hopefully this helps a bit.

Have fun,
Olli

[jstroup1986 (Joseph G Stroup Jr)]

I’ll be happy to help as much as I can.

My experience is limited to Storm32 and Alexmos gimbal controllers. It’s been over a year since I worked on them, but as I recall my experience contradicts your statement about gimbals working the same regardless of protocol.

And there are weird complications. For example, Alexmos controllers support a compass module on the camera platform - which is required for some functions. (“point camera here” as I recall)

I was really happy to see @olliw42 contribute to this thread. I look forward to learning more from him.

[jstroup1986 (Joseph G Stroup Jr)]

Thank you so much for contributing to this thread. It’s a really great help!

I’d forgotten about the Storm32 T-Storm gimbal controllers. Thank you for reminding me.

I’m unable to find a source for T-Storm gimbal controllers. If you can help me source the necessary materials, I’d enjoy building one.

I’ve built an Alexmos gimbal using a kit from iFlight that has the controller and motors with encoders installed. From the wiring diagram on the T-Storm web page, it doesn’t appear that Storm32 controllers can address the encoders used on the iFlight motors. They use the AS5048A encoders.

The wiring diagram of the T-Storm encoders show that they daisy chain - that would be a great improvement in building a gimbal with AS5048A encoders - which each must have it’s own wiring back to the controller.

Thanks once again for contributing to this thread. There seems to be renewed interest in camera gimbals - and I’m enthusiastic to see new developments.

[olliw42]

@jstroup1986

I’m unable to find a source for T-Storm gimbal controllers

that’s really the Achilles’ heel … you essentially can’t buy any T-STorM32 stuff, and chip crisis (and Russia’s war) hasn’t made things better. For non-encodered conventional STorM32 the situation is somewhat better, but really only somewhat. E.g. Ghostand Designs offers at 2-axis gimbal for cameras in the GoPro size range. But overall the situation is just bad.

I didn’t wanted to drag anyone to STorM32, just to update some info.

[rmackay9]

@jstroup1986,

Just one last thing, “point camera here” doesn’t require the gimbal know its earth-frame heading. By default AP will do the conversion from earth-frame to body-frame and then send body-frame angle targets to the gimbal. This is how servo gimbals (using PWM) can point at a particular Location.

In the new enhanced drivers, if the gimbal does know its earth-frame yaw (like the Gremsy does) then we take advantage of that and AP sends the earth-frame targets.

[jstroup1986 (Joseph G Stroup Jr)]

@rmackay9

I’m going to have to dig a bit to find my references at the time, but I posted about this situation here:

How to succeed with "Point Camera Here"?

Working through configuration of an Alexmos gimbal, it appears that for ArduPilot to command the gimbal to “point camera here” (ROI) that the gimbal needs to have a magnetometer installed on the camera bracket. Without it, I’ve found that the only way “point camera here” works with Alexmos is if the copter and gimbal are initialized facing “north.” And then I suspect there would be significant drift. I don’t recall seeing this requirement when testing a Storm32 gimbal controller - I’m going t…

Searching just now, the Alexmos documentation on the magnetometer doesn’t address this particular issue - so I’m not exactly sure where I got this idea. Alexmos magnetometer docs: https://www.basecamelectronics.com/files/v3/SBGC32_Magnetometer_eng.pdf

What I do remember is that on my workbench, Point-Camera-Here didn’t work with Alexmos with MavLink. The gimbal was directed to an incorrect azimuth. This is what led me to the learning a magnetometer was required.

Calibrating a magnetometer mounted under a camera is also problematic - so after installing a magnetometer, I don’t remember testing it in flight.

It was peculiar because ROI does work fine - but it’s not yawing the gimbal, it’s yawing the whole copter.

I tested it here with 5 different ROI’s on a flight: https://youtu.be/DqwfeYNyV4Y

[rmackay9]

@jstroup1986,

We’ve resolved a bunch of issues with AP’s gimbal support in 4.3 so I think if you try again with 4.3 (or higher) it should all work and if it doesn’t I’m happy to look into it.