Siyi gimbal control using MAVLink commands

This is a discussion moved from here where @Ihor_Y says,

there is 1 more bug in MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW function implementation.
Flags (0=Yaw is body-frame/follow, 16=Yaw is earth-frame/lock) - this FLAG is not correctly handled. Actually it is treated as Yaw angle.


Thanks again for the report. I had a look through the code and I don’t immediately see any errors but of course that doesn’t mean that there aren’t any.

I guess you are testing sending mavlink messages to AP using a custom application or maybe MAVProxy? I would like to rule out a ground station issue so I wonder if you could test using MAVProxy and ideally use the example commands that can be copy-pasted directly into MAVProxy’s terminal window.

I’ve tried to use pymavlink directly with UART
My code sample is:
drone = mavutil.mavlink_connection(serialName, baud=9600)
drone.mav.request_data_stream_send(drone.target_system, drone.target_component, mavlink1.MAV_DATA_STREAM_POSITION, 10, 1)
drone.mav.request_data_stream_send(drone.target_system, drone.target_component, mavlink1.MAV_DATA_STREAM_RC_CHANNELS, 50, 1)
drone.mav.command_long_send(drone.target_system, drone.target_component, mavlink1.MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW, 0, -90, 0, float(“NaN”), float(“NaN”), 16, 0, 0)

So that FLAG=16 - controls yaw, not lock gimbal as described in doc.
It is supposed to be bug.


So to be clear, setting the flags to 0 or 16 will affect how the yaw angle (param2) will be interpreted. If flags is 0 then the yaw angle will be interpreted as a body-frame angle (e.g. 0=point forward), if flags is 16 then yaw angle will be interpreted as an earth-frame angle (e.g. 0 = North).

Maybe this is where the confusion is coming in?

If not, could you please describe what yaw issue you are seeing? Perhaps provide an onboard log…

mavlink1.MAV_CMD_DO_GIMBAL_MANAGER_PITCHYAW, 0, -90, 0, float(“NaN”), float(“NaN”), 16, 0, 0)

This command turns Yaw angle on 16 degree, but expected output - Yaw angle should be 0.