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: