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.

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.

Regards!

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?

Regards!

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!

Regards!

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.

Aleksey.

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

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.