EN CN
self excitation on api moves?
  • whizpop
    Hi,
    I have a custom gimbal that is actually being used as an api controlled time lapse rig, it appears to be tuned well during calibration however, one thing I notice when making movements through api "set angle" commands it can cause the gimbal to enter a state of self excitation.

    if I immediately connect to calibrate the device it is generally difficult to reproduce and generally stabilizes. I can settle the frame by touching it, but there seems to be very minor mechanical vibration or cogging that can excite the gimbal.

    my PID values are all pretty low(15-40) however on the axis that get excited I have fairly high D values (~70-90)

    also, it seems like it could be related to specific angles related to motor coging?

    I am using iPower GBM5208H-180T motors

    Any suggestions on how to troubleshoot this?
    thanks in advance,
    David
  • Garug
    Limiting acceleration could help. also starting and stoping the movement slowly via API should help.

    Gimbals vibrate often at some specific angles, but this has typically more to do with gimbal construction than motors. You could tune the gimbal in position it starts vibrating (resulting even lower PID) or see how the gimbal construction could be improved. Often the easiest places to start are firm camera installation and IMU placement.
  • whizpop
    since it is a timelapse rig, my set angle changes are usually very small degree changes. I did reduce the speed to 20 and it seemed to help. The camera and IMU placement are firmly mounted.

    in this type of scenario would you you still recommend acceleration/deceleration pattern to be used even for a small change in angle?
    I suppose its possible that a small change in angle (without acc/dec) combined with any gimbal or dolly mechanical resonance, could set off excitation.

    I tried to re-tune the gimbal, but I am unable to reproduce it manually at any angle, it seems to be more sensitive when sending angle commands via uart api.
    would increasing LPF values on the RC tab help? are there any values related to the RC tab that I could try?

    another thought is voltage/current can the gimbal be more sensitive as the battery depleats?
    does the battery compensate feature help if this is the cause?

    thanks again,
    David
  • Garug
    Try limiting the acceleration.

    See MODE_SPEED_ANGLE, would be good to use that or ramp up the speed.

    It has been long time though I have used the Serial API.
  • whizpop
    I will try that mode, it looks like the parameters are the same.
    how does the MODE_SPEED_ANGLE differ from MODE_ANGLE?
    my impression is that MODE_SPEED_ANGLE will only go as fast as it can maintain the angle?

    thanks,
    David
  • whizpop
    after looking at the docs/diagram, it appears that the main difference is that it is very explicitly follows the angle and speed, and maintains it after it is set.
    which seems like it would make it *more* jerky, does that sound right?
  • Garug
    As I understand it is just vice versa. On MODE_SPEED_ANGLE the wanted and actual angle are same, on MODE_ANGLE they are not i.e it overshoots =jerky .
  • whizpop
    ahh, that makes sense I will let you know how the testing goes.
  • whizpop
    it turns out using that MODE_SPEED_ANGLE behaves Very different.
    when setting an angle, the gimbal continues to move in the direction that was sent last at a continuous rate.

    the documentation does not indicate any difference in the input values for speed, angle are they relative or literal angles with that mode?

    any ideas?
  • Garug
  • whizpop
    the behavioral difference that I see when using MODE_SPEED_ANGLE (which is not described in the API documentation or code) is that the cmd_control needs to be sent at a fixed frame rate in order to take full control of the gimbal position.

    whereas using MODE_ANGLE you can send a single command with angle and speed and the internal logic will be used to send all necessary frames to position the gimbal to the desired angle.
  • Garug
    Yes, but then you can not control the acceleration, and it might try to move too fast to the desired position.

    Though, now I think there is also acceleration control, should look again to the Serial API, lately I have been using SBUS.

    But your problem is I think that it tries to accelerate faster than possible and that causes problems. Ramp up the speed, or limit acceleration.
  • whizpop
    before implementing a strategy to employ MODE_SPEED_ANGLE frame-strategy, I wanted to rule out a suspicion about motor current draw.

    I currently use 2 x 12v4500mAh li-ion (CCTV) batteries in parallel creating 12v9000mAh (not sure what the discharge rate is...)

    for a test I increased the yaw power from 200 to 230 and it seems to have reduced the excitation at extreme angles and generally improved stabilization.

    I am a bit concerned as the motor was already getting warm @ 200
    but I will need to do further testing

    are these power values or battery current uncommon?
  • Garug
    Do not worry about the current. Almost any RC battery can provide enough current for gimbal and the ones you mention certainly can.

    Typical gimbal will use around 1 A, maybe up to 2 A and they will use constantly the same current. Encoder gimbals are a bit different.
  • whizpop
    right, but as I mentioned this is a time-lapse rig, which also powers a stepper motor for linear motion , arduino and small touch screen.

    -arduino+screen: 5v@.5A
    -stepper: 12v@.8A
    -gimbal: 12v@1-2A

    I was thinking if the discharge rate of the battery(s) are not good enough (as they are not RC batteries)
    that the decrease in available current may cause stability issue for the gimbal?

    the reason I am thinking this is because the instability appears to be inconsistent, as different angles at different times.

    when it is stable it is strong and firmly in place, when it is unstable it seems to be at a pivital point that it cannot *hold*

    maybe I will shoot a video to share to see if that helps identify any oversights.
  • whizpop
    I think I found a flaw (unsure if its in my logic or BGC)
    my timelapse logic allows you to move the gimbal to a start-point, then to and end-point.
    I retrieve angles from the controller at both points.
    when performing the timelapse I interpolate (tween) angle values from start to end angles over a period of time. as such the interpolated values are likely to be fractions of angles at a resolution that the controller may or may not be able to reach/hold.

    I am adjusting my logic to capture degrees as ((int16_t)((float)(Angle) / (1.0f / 0.02197265625f))), then calculate the gimbal angle to send using ((int16_t)((float)(Degree) * (1.0f / 0.02197265625f)))
    which forces the interpolated values into a specific degree that the gimbal is expecting/able to reach/hold.

    quick test indicate that the movement is less granular, but more reliable...

    off to test more...
  • whizpop
    it seems like this was the cause of the issue,
    I will be performing several more tests to confirm.

    thanks for your feedback and ideas Garug
Add a Comment