“Follow Yaw” in Rate control mode
  • I am trying to control the 3 axis gimbal through serial API and experience some odd behavior when I enabled “Follow Yaw” mode (using SimpleBGC GUI) in rate modes. The test is doing with the version 2.63b0. What I want to do is when the joystick is in rest I want the camera to look forward and align with the UAV heading. At the moment UAV yaw following does not work as expected. NOTE: When the camera is in rate mode the “SBGC_CMD_CONTROL” is send at 30Hz.

    I would like to get clarify followings to nail down the issue which I currently experiencing:
    1. Is it possible to correctly work “Follow Yaw” mode when the UAV is in rate mode and gimbal received “SBGC_CMD_CONTROL” packet at rate of 30Hz with ZEROS in its rate fields. I wonder that both the rate control mode and the “follow Yaw” modes are allowed to work at the same time? Because, when UAV send “SBGC_CMD_CONTROL” packet at rate of 30Hz with ZEROS in its rate fields the gimbal trying to control its axis based on the commanded values while gimbal itself trying to follow the UAV heading since we are enabled “Follow Yaw” mode (assuming there are both the main and frame IMUs are sitting on the gimbal). Doesn’t these mode fight each other?

    2. Does “Follow Yaw” mode is working when AHRS helper commands are send to basecam gimbal? Or Wonder that “Follow Yaw” function may be disabled when AHRS mode is ON? Note: The camera gimbal is in rate mode and the camera gimbal receive the “SBGC_CMD_CONTROL” paketat rate of 30Hz with ZEROS in its rate fields.

  • Hello!

    1) The "Follow" mode and serial control mode in MODE_SPEED, MODE_ANGLE and MODE_SPEED_ANGLE are concurrent. So, you can not enable both modes and mix them. Once you start sending CMD_CONTROL, follow mode is turned off. If you need such mix, the solution is MODE_RC - this is emulation of RC stick movement that is mixed internally with the follow mode.

    2) Yes, they work independently. AHRS HELPER affect IMU angle measurement.

    In my opinion, gimbal installed on a drone, should not be controlled in the "follow" mode for the YAW, though it seems as a most simple way. Operator should control gimbal directly, and drone should receive the same rate command. Of course after some time it will be accumulated a difference in angles of drone and gimbal, that you should correct in a form of a closed loop (i,e, read difference and add a portion of control proportional to it, into the command for a drone). Such way you can get precise gimbal control w/out lags and affection of imperfectness of the drone behavior.

    BTH, 30Hz looks too small for CMD_CONTROL. Optimal is 125 but half of it is good too. If 30 Hz is only possible, consider CMD_CONTROL_CONFIG allows to setup LPF to smooth step-wise behavior.

    Regards, Aleksey.
  • Hello Alexmos,
    Thank for the comments. This make me clear the behavior. Will do the code change and update how it goes.
  • Hi Alex,

    If I got it correctly when we send the CMD_CONTROL packet to the camera gimbal it disabled (i.e. OFF) "Follow Yaw" mode and does not auto enabled "Follow Yaw" once we stop sending CMD_CONTROL packet. So, once we send a CMD_CONTROL packet if we want to enable "Follow Yaw" mode again then we should do it by using the "SET_ADJ_VARS_VAL"?. In the "SET_ADJ_VARS_VAL" packet the "PARAM1_ID" should be set to 30 and the "PARAM1_VALUE"should be set to 1?.