Mavlink issue on yaw at 180 degree
  • Hi,
    I make a new post because I can´t change the wrong title of my old post: https://forum.basecamelectronics.com/index.php?p=/discussion/2542/2-61b8-yaw-recenter-problem#Item_5

    Coming from storm32, changed to SBGC32 via Mavlink.
    There is an issue with the mavlink connection when going through 180 degrees of the yaw axis.
    When the Copter went over the magnetic 180 degrees (S) it makes a full 360 turn to the opposite direction.
    I am using the latest 2.62b3, but the issue is since the first Mavlink release.
    Without mavlink all is fine.
    Hopefully Alex could fix this.
    Cheers Gregor
    https://www.dropbox.com/sh/9dv7acbkeab41ma/AAA2aZfAm7sFm_y_tzebpKAna?dl=0
  • ...with 2.62.b4 the issue still remains.
    I am the only one using Mavlink on SBGC32?
  • Hello, Gregor
    Finally, I found a time to fix some bugs related to MavLink support. Beside mentioned problem, do you know other problems with MavLink? Or may be you have suggestions what to improve or implement?
  • Hello Alex, because of this bug was essential I can not say too much ...The only thing I recognised, was that the connection between Arducopter and SBGC32 has sometimes a different behaviour regarding packet loss. Sometimes I got a good connection without lost packages, sometimes I have a huge amount of lost packages. Maybe the initialization of the connection could be optimized.Do we get the new beta before weekend? If so I would make further tests at the weekend.
    Thanks Gregor
  • I will try to reproduce this problem tomorrow, so there is a chance to fix it before the weekend.
    The helpful information will be the answers:

    1. Gimbal is locked to one direction or follows copter?
    2. Which mode for gimbal control is set in the ArduPilot, i,e, is it automated mission, geo-targeting, or RC control?
  • Ok, I found the reason of a problem. It is fixed now and published as 2.62b6.
  • Sorry Alex, tested it but the error is still there in the b6.
    1. The gimbal follows on yaw.
    2. The mode is set to RC control.
  • Hello,

    I fixed only a problem "When the Copter went over the magnetic 180 degrees (S) it makes a full 360 turn to the opposite direction."

    If you have other problems, please describe them separately.

    "The gimbal follows on yaw." but it's default behaviour, how ArduPliot controls it's gimbal. I do not see any setting in MissionPlanner that can change it. The second mode is "GPS position tracking", like "point camera here" option on the map. When ArduCopter enters this mode, I did not find a way to return back to RC control. It seems like it's a limitation of FC.
  • Alex, maybe you misunderstood my answers. They regard to your questions:
    "The helpful information will be the answers:

    1. Gimbal is locked to one direction or follows copter?
    answer: The gimbal follows the copter.
    2. Which mode for gimbal control is set in the ArduPilot, i,e, is it automated mission, geo-targeting, or RC control?"
    answer: The mode is set to RC control and I did not switch to another mode.
    I tested the problem with Yaw turn at magnetic south with 2.62b6, and the issue is still the same. When the copter moves over (S) the gimbal tries to turn to the opposite direction.

    Maybe it´s a little more clear now,
    Gregor
  • Hi Alex,
    with 2.62b7 the issue seemed to be fixed.
    Many Thanks,
    Gregor
  • Hi Alex, George.
    Can we please clarify this 'issue' I have installed Firmware 2.62b8.
    The gimbal always 'follows' the copter's yaw when, Arducopter's mount mode is set to RC Trigger.

    Not sure if this is the issue you have been talking about.

    We need the yaw NOT to follow the copter but remain on whatever heading has been set by the remote controller regardless of the yaw of the copter, yet still be directable by the remote controller (like it normally does when not using MAV).
    Is this possible? Is this an Ardupilot issue / setting?

    Also it would be nice if we could disable MAV via the RC, could be a profile one with Mav one without.

    Thanks

    Anthony