Logic in Storm32 MAVLink Driver Appears Flawed for 3 Axis Gimbals like the Gremsy Pixy U

I flight tested a 3 Axis Gremsy Pixy U gimbal on my Quadcopter recently and noticed that when I used a DO_MOUNT command that takes a pitch, yaw and roll angle to tilt the gimbal up or down, the copter would yaw to near 0 degrees from North. I had supplied the last know values from the gimbal for yaw (pan) and roll angle to keep them unchanged. The pan value from the gimbal was near 0.

Looking at the logic in the MAVLink parser for the DO_MOUNT command, it checks if the gimbal supports pan by calling the “has_pan” method. If it does not support panning, it commands the copter to yaw to the specified angle. It appears that it assumes that the angle is relative to North. It then passes the angles to the AP_MOUNT class, which in turns sends it to the backend (Storm32 MAVLink) that sends it onto the gimbal controller. It appears that the gimbal wants the pan angle in the local body coordinates (i.e. pan of 0 is straight ahead). When I did my bench testing, the gimbal responded correctly to the pan angles supplied to it.

The Storm32 has_pan() method is hard-coded to return false independent of whether the gimbal actually supports panning. I can fix it for the Gremsy by hard-coding it to return true or see if there is a way to query the Gremsy to see if it actually supports pan.

So, it looks like there are two issues:

1.) The Storm32 has_pan() method always returns false for pan, but yet sends the pan angle to the gimbal via MAVLink. It doesn’t query the gimbal to see if it supports panning.

2.) The pan angle is relative to North if the gimbal does not support panning, but the gimbal assumes that the angle is relative to the neutral gimbal position if it does support panning.

Let me know if this appears to actually be a bug and I’ll submit a bug report on github.

I’ve love to hear other people’s opinion on the correct behavior for this use case as well.

I found this related github issue as well:

yes, this is a bug

it was introduced 1 to 2 years ago or so, related to has_pan_control as you say. ArduPilot unfortunately hasn’t understood that the Solo gimbal isn’t a normal gimbal and introduced it that way. It is btw not really a STorM32 mount driver issue, but valid for “all” mounts. They in fact have introduced few more bugs in the last years, at least one of them they denied to exist. They don’t appear to do their job properly and think about and test what they are doing. It’s “funny” though that it is only now that user reports are coming in. Here another thread: Gimbal interprets cardinal directions as relative azimuth.

Good luck.

I saw this issue also in SITL mode and reported via github as issue here:

I confirm that copter 4.1.x storm32 mavlink is flowed for rc control mode. Instead of working corectly as expected in angle mode the gimbal work as in speed mode……

Does anybody experienced it? There is solution to get rid of that?