EN CN
Setup For A 2-axis Gimbal that can't look forward
  • mic1hov
    We are trying to track objects on the ground using a 2-axis gimbal in CAM-PITCH-ROLL hardware configuration
    The order of Euler AXIS is set to YAW-ROLL-PITCH. (its also connected to mavlink)
    The camera can rotate from 45 to 135 in pitch and -55 to 55 in roll. So it cant look straight forward the rotation is limited by the frame.

    1. Should the system know that the camera is looking down ? should the black arrow point down and white arrow for the encoders point forward ? The system seems to work when it thinks that the camera is pointing forward aka black arrow forward white arrow up but the camera is pointing down. In that configuration it tracks the direction its set in even if the gimbal is rotated in yaw. However when its configured in the right way the roll doesn't respond to anything the dial doesn't rotate when the gimbal is rolled.

    2. Should we use any settings from the Axis to stabilize for 1 or 2-axis systems section ?

  • alexmosalexmos
    Hello,

    1. Normally, system should know where the camera looks, so ROLL, PITCH and YAW angles defines the camera orientation and ROLL,PITCh=0 when camera is horisontan. But for your particular case - geo target tracking with 2 axis, the only solution is when the camera axis matches YAW axis (points down) when the stabilized platform is leveled. In this position ROLL and PITCH motor angles are 0 (white arrows point up). I don't see problems here if you take into account this 90-degrees offset in your software.

    For geotracking, we need ROLL and PITCH axis to be linked to the Earth and stable, YAW may vary. So YAW should go first in order.

    Most (maybe all) of other cases cause gimbal lock problem, which you most probably have described in the second part of the question. In the Euler order where ROLL is in the middle (YAW-ROLL-PITCH), when gimbal rolled 90-degree down it enters a "gimbal lock" case, so it should be avoided as a normal working position. You can only tilt gimbal, but it limits the range of control only by the single axis, which is not what you need.

    2. Maybe there is another working configuration using "axis to stabilize" and hardware motor assignment approach, but I think the positive result you already got, is the best possible. The main problem is the Euler gimbal lock, which is hard to solve, - we can only consider it as temporarily transition and safely pass, but not use as a working position.
  • mic1hov
    Hi, Thanks for the reply. This explains a lot

    counting in the 90 degree offset in our software is not a problem. The only concern I had was that the gimball wouldn't stabilize properly if it didn't know the right optical axis of the camera. Now I understand that this is the only possible setup in our case.

    As we are trying to compensate for the YAW rotation of the camera around the FOV axis in our software we need the gimball to always know its heading. For that reason we have connected it to mavlink of the FC.

    The setup in external IMU tab is "compensate for linear acceleration only" and "use as a heading
    reference" no other options are used

    1. Do I need any other settings ?
    2. Do I need to the Alignment correction for external imu ?
    3. In Hardware tab there is a setting "Heading correction factor" should we set it to 100 to make the gimball trust the mavlink data from the Pixhawk ?

    4. Also I have noticed that in the configuration YAW-ROLL-PITCH the gimbal became a little bit slower then before. Is there any way to make it faster ? the acceleration limit is set to 0.
  • alexmosalexmos
    1. No
    2. Not need
    3. 50-100 is a normal value. The correction source is always Pixhawk, this value just defines its weight compared to the angle measured by gyroscope integration
    4. If you mean the speed of target tracking - there is no special adjustment for a different order of Euler axes. Beside the acceleration limits, there are also speed settings in the "RC" tab, maybe they differ with the previous configuration.
    The speed depends on the control type, MAV_INPUT_MODE_SPEED or MAV_INPUT_MODE_ANGLE. In the last mode, the speed drops near target, to provide smooth control with the steppy signal.
Add a Comment