• Hello all,
    I'm trying to point to a target from a fixed wing plane with a 2 axis gimbal (fixed yaw to the center of the orbit, roll and tilt stabilization and pointing). I control the gimbal angles with RC input, previusly making the calculation of them with the position and altitude of the target and position and altitude of the plane.
    Only main IMU activated.

    The problem is that, due to lateral accelerations (I presume), main imu drifts, and so the camera doesn't point to the target. I made some pointing tests in static and works fine, no drift.

    I decided then, to send over MAVLink AHRS,GPS and Controls data from external IMU. Basecam GUI says it's revceiving everything ok. Now, the questions:

    - How do I know if the gimbal is doing AHRS and GPS correction? (before I fly again)

    - Alex, can you tell me anything about your pointing tests (I saw your mavlink implementation video and seemed to work fine) and wether if you have any tricky information about that I should know?

    - Anyone having the same problem?

    I'll try to post my results pointing to targets when I success with it!
  • Hello,

    Currently we are working on a better support of corrections from external IMUs (including MavLink). Wait a bit when 2.66b4 beta firmware will be released (next week, roughly). Among other improvements, it will provide more information for a debugging of the external IMU, so you can ensure that acceleration correction is working and the AHRS information is provided from the flight controller. We will update the User Manual documentation and describe all new functions in details.

    BTW, it would be interesting to test this correction at a plane. As my first tests on UAV that you probably seen, were succsesffull, my recent tests from a car were not - Ardupilot did not detect linear accelerations properly. May be it is related to that fact it was not in the flight mode, I don't know. So please keep me informed about your progress testing new firmware.

    Hint: If your target is to stabilize the camera pointing to a geo target, it is important to choose proper order of Euler angles in the "RC" tab. ROLL-PITCH-YAW or PITCH-ROLL-YAW do not provide lock to a point in 2-axis gimbal - it will rotate by the YAW when frame is rotated. Use the YAW-ROLL-PITCH order, where ROLL and PITCH will be locked to the earth system regardless of the YAW rotations of the frame. With the external reference provided from the flight controller, this coordinate system will be in sync with the FC system that will simplify the calculations of target angles.
  • this is good news, been struggling with a storm and what appears to be some sort of rift and fork of arducopter for Storm. I dislike forks.

    Guess I need to replace that gimbal controller now
  • Hi Alex, thanks for your response.

    Before I go into testings, order of Euler angles was something I was going to test. I didn't know exatly how it worked. Do you use Euler angles for calculations instead of quaternions? Is gimbal lock because of that?
    About MavLink implementation, I'm finding some things. Maybe it helps for make it work perfectly. I found that when I choose frame IMU (mavlink IMU)position below yaw, or next to main imu, main imu's yaw is suposed to match frame IMU. It is at the begining, but if I move frame IMU in yaw, main IMU starts to make a correction, but not in position, but like in speed mode. For example, to make it understandable: start system, main and frame imu match in 10º. I move frame imu to 15º, and main imu starts moving non-stop in positive turning sense. I come back to 10º on frame and main stops. I move frame to 5º and same happens in the other way. if I go to further angle in frame, main imu do the same but faster turning speed. Maybe position as angular speed feedback?? don't know.

    I'll be soon making some flying tests in a plane. My frame IMU is very accurate, better than pixhawk's sensor fusion. I hope the tests go well, I'll keep you all informed here.

    Btw Alex, do you have anything you wanted to test "in plane"? You can write me and see if I can implement it on the tests.

  • "Do you use Euler angles for calculations instead of quaternions? Is gimbal lock because of that?"
    we use euler to split control of the gimbal to 3 axis. Gimbal lock may be mechanical (it depends on order of motors in 3-axis gimbal), but also the control in Euler angles have a forbidden areas. We may call it gimbal lock, too.

    In the current implmentation, the heading angle of the main IMU is referenced by the Mavlink-connected FC. If you rotate frame, angle is translated to the main IMU taking into account motor angles on the way, and it's heading is corrected. In your experiment you rotated frame IMU independently on the gimbal, that caused a correction. If you rotate it as it should - linked together, correction will be not required.

    In the upcoming 2.66b4 it will be more options for a correction from the MavLink FC.

    "My frame IMU is very accurate, better than pixhawk's sensor fusion" - can you give more information, what is the model of sensor? We a interesting in finding good sensors to improve the precision of stabilization.

    Regards, Aleksey
  • I meant gimbal lock in control algorithms.
    Waiting for new fw release! When will it be released approx?

    About my IMU, it's based on gyro&accelerometer (https://www.murata.com/products/sensor/gyro/scc2000), honeywell magnetometer and ublox GPS, with kalman filter.

    One more question: is it possible in encoder firmware version to directly command angles to the motors? I mean, use only encoders and external reference of the IMU position to stabilize, not using camera IMU at all. Is it possible, or maybe it will in any future release?

  • Direct control of motors is not possible and is not planned. It requires a servo-like controller on each motor to read encoder directly with the high rate, to implement feedback loop based on it. Out CAN_DRV module can do it, may be in future we will add this option for the CAN-enabled boards.
  • Hello all,
    I finally made my flying tests with mavlink and here the conclusions:
    - Tests were made making an orbit around a point in the map, at 140m height.
    - Still get pointing error. It goes between 9º and 16º, that means a distance error between 35m-75m on ground.
    - Maybe with next version I can better debug what's the correction the controller is making with mavlink input. Is next version allowing any tool to check mavlink input (i.e. correct sense of angles, etc)?
    - Alex, can you provide any information of the correction you are implementing on new firmware? gps velocities to correct lateral accelerations?
    - Is there a way to minimize this error? Should I test something more?

    Alex, about my last question, maybe I didn't explain myself very well. I meant if it is/will be possible, if I have only motors with encoders (no imu), to move them to any angle RELATIVE to the frame.

    That's all at the moment!

  • Another thing I forgot to mention:
    With encoder version, this stationary error is suposed to be corrected (having frame attitude from mavlink) ??
  • In new firmware it will be displayed the errors of attitude from the internal and external IMUs, that you can use for a debugging. Also in the monitoring there is IMU_G_ERR, IMU_HERR that has the same meaning. User Manual will be updated and you can find many useful information about IMU correction there.

    The acceleration correction is taken from the velocity estimated by Ardupilot's EKF2. It uses GPS in filter, but with many sophisticated rules applied. Sometimes GPS is not used by the filter, so it may be a potential problem for acceleration correction or attitude estimation.

    If your gimbal has encoders, in new firmware you can select new mode of correction, when the external attitude replaces the internal accelerometer sensor completely. May be it will work better then the accelerations correction, you can compare both modes.

    "I meant if it is/will be possible, if I have only motors with encoders (no imu), to move them to any angle RELATIVE to the frame." I understand it, the answer is no. Our controller does not support servo mode for a particular motor.

  • Testing new firmware tomorrow. Let's see how it works!
    Waiting for the new manual version to get deeper.

  • Ok, let me know about result. Test two modes: attitude reference and acceleration corrections. Heading correction should be enabled for both.
    The updated usr manual is already there: https://www.basecamelectronics.com/files/v3/SimpleBGC_32bit_manual_2_6x_eng.pdf
  • Hi Alex! I see you have made some improvements here with external flight controller feed to your boards. I also see you have successfully tested it in a car. I had to leave this work for a year now and I'm going to resume it and make it finally work! I have some questions:
    - Would you say it is working perfectly now?
    - What about the GPS-IMU v2 you are about to release? Can you give further information? Could it be used as standalone IMU for a flight controller? And, does it filter GPS positions in Kalman filter?
    - I'm going to use encoders as I'm going to use a Pan/Tilt gimbal. Is it recommended to use tilt encoder or just Yaw encoder and MavLink/your GPS-IMU should be fine? I will use what you consider to be the most precise configuration for it.

    Thank you very much and hope I will share the good results over here!

  • Hello.

    1) External IMU correction in our SBGC32 controller is working, it allows to solve most IMU-related problems, but all depends on the external IMU quality
    2) GPS_IMUv2 is going well, will be released in 2-3 months. Yes, it uses GNSS position and Kalman filter, it has environment isolation that significantly improves its stability, so we can get an accuracy of 0.1 degrees in dynamics. GPS_IMU has a Serial API so it may be used in any application different from gimbals, but it is not directly supported by the existing flight controllers.
    3) Better to use encoders for all axes.

    Regards, Aleksey.
  • any video available for external IMU