It looks like you and I are having similar problems with the Pixy LR gimbal.
After a lot of fiddling I am finally able to get the gimbal to do somthing when I use the onscreen controls with MavCam but all the camera does is wiggle a bit and won’t move.
I’m honestly not sure what I might be doing wrong but it’s definitely frustrating.
I suspect the wiggling is happening because both ArduPilot and the application running on the herelink are trying to directly control the gimbal.
I’m not familiar with the application being used but if it only works by directly talking to the gimbal then AP can’t ever also be in control of the gimbal.
I think the options are:
hide the gimbal from the application by setting SERIALx_OPTIONS = 1024 (where “x” is the serial port connected between the autopilot and gimbal). I suspect the app will just stop working but if you’re lucky maybe it will try talking to the autopilot instead of directly to the gimbal and if the commands it sends are supported then the autopilot will control the gimbal properly. It’s unlikley this will work though
disable AP from being able to control the gimbal by setting MNT1_TYPE = 0, CAM1_TYPE = 0. Of course AP’s various gimbal related features won’t work.
I have tried option 1 and unfortunately with how the wiring is setup this won’t work as currently the Pixy LR is connected to Serial 2 via the gremsy COM2 port and the Airpixel Entire is connected to the FC thru COM4 of the gimbal (and thus in order for the entire to communicate to the FC I need to have port forwarding active in order for the Entire to communicate with the FC.
Unfortunately, if I select Option 2, all commands fail both in the onscreen display from the Mavcam App, and I can’t even control it via typical Herelink setup Gremsy (which seems strange to be honest since that’s merely SBUS commands and I can see in the Gimbal App that the gimbal is recieving the signal from my RC controller when I pass thru the command.
Thanks for the suggestions.
I will continue to troubleshoot the problem and will figure it out sooner or later.
After some fiddling I was finally able to figure it out.
Apparently there is a setting for the Entire that needed to be changed.
Specifically the setting “Control by the Link” needed to be unchecked. Once I did this the gimbal can be controlled via MavCam and the payload control in AP.
It will be very useful to add possibility to change smoothness of move to tilt, roll and pan of Gremsy gimbals. For now it is hard to get good control over gimbal on different controllers with Mavlink connection. In SBUS mode you can control the smoothness in Gremsy in each axis with Qtune app with Mavlink you don’t have such possibility.
So it will be great if we will have:
MNTx_RC_RATE for tilt, roll and yaw
The problem with Pitch 90 degrees down can be partly resolved if in QtuneDesktop 120 degrees will be set. But still it is hard to set pitch in 90 degrees.
There is also problem with horizon drift. Generally when you flying forward and changing only yaw… the roll of gimbal is ok but If you fly to the left and to the right the horizon will be wrong sooner or later and horizon is oblique. Such problem should be repaired by function “Reduce Drift by Drone” which is available in QtuneDesktop but this function doesn’t work. When “Reduce Drift by Drone” function is enabled with every change of position of the copter roll or pitch gimbal backs to latest position. You can’t change the tilt or pan of the gimbal because it reseted by movements of the copter.
