EN RU CN
Accounting for Drift? GPS/EKF and/or Flight Controller Integration
  • Hi all,
    Everyone knows MEMS sensors ultimately drift over time, it's simply a matter of how much and how we deal with it.

    We are looking at ways to integrate dedicated GPS and using EKF onboard a gimbal controller, or integrating with a Pixhawk or other APM-powered flight controller that is already doing GPS-assisted EKF to help account for drift.

    I see very little discussion about this, but I know other proprietary controllers are using onboard GPS in some fashion. Because they are proprietary, I don't know if anyone knows exactly what they are doing and to what degree they help with drift.

    We are doing aerial survey research with scientific instruments so drift is a serious problem we need to account for. Do you have thoughts how this can be accomplished with a Basecam controller? Does the new Pro controller offer any unique solution or special flight controller integration as can be seen on DJI and Gremsy controllers?

    Thanks!
  • With GPS and other additional sensors you can get the flight path, and when that is known the accelerations can be calculated and their effect to gimbal eliminated.

  • Right, I understand the mechanics of the algorithm, generally at least. But can this be achieved with a Basecam/Basecam Pro controller, and if so, how? I can see benefits of using dedicated GPS for the gimbal controller (self contained) as well as integration with the flight controller. Is anyone doing this or is it only the "big guys", Freefly, DJI, etc. behind closed doors with teams of programmers?
  • BaseCam has FC interface, if FC would provide accurate data, maybe the result would be good.

    BaseCam does support compass, but currently not GPS.

    BaseCam also offers the Serial API to control the gimbal, so external devise could use also it.
  • Ah - OK - so if we had a separate device reading attitude/compass data from the BaseCam serial API, and doing EKF with GPS data, it could theoretically solve the drift.

    I am surprised no one else has expressed a desire for such things, it would be interesting to pursue as an open source initiative.
  • BaseCam has FC interface, if FC would provide accurate data, maybe the result would be good.

    A good way to interface with the FC would be to listen to the FC's serial and decode position data over mavlink. Right now I can not see how the PWM interface BC-FC would allow for attitude and direction compensation. The compass support works so far but the accuracy is questionable. There is drift even after one full turn.
  • Hello,

    Its absolutely normal that simple MEMS sensor used in gimbal controllers, drifts. Beside the known problems with affection of accelerations in 6-axis IMU, that was mentioned above, the lack of basic calibrations is a problem, too. This project was started from hobby, and we could not use 500$ high grade sensors or make complicated calibrations on cheap sensors.

    Generally, IMU drift is not a problem for most of gimbal application. In hend-held, "Follow me" mode does not suffer from YAW drift. In flight, operator can correct YAW drift.

    But now its time to improve IMU performance, and we (Basecam) working in that direction:

    1. Support of Mavlink to communicate with autopilots to get GPS, compass data - in progress
    2. Improve IMU hardware and algorithms and make factory calibration in full temperature range - in progress
    3. Accept data from external high-grade IMU - could be done via Serial API (CMD_AHRS_HELPER command).

    Regards, Aleksey
  • Aleksey, that sounds great. When will Mavlink and high-grade IMU support be ready?

    Also, when will the "SimpleBGC 32-bit Extended" be available? Is preorder an option?

    Thanks!
  • Mavlnk waits a good wheather and free time from me to test and debug it in air.

    High grade IMUs - we will test several models that available on the market now, and consider adding direct support by I2C bus. But I meant that you can add a support by yourself, if you have good IMU in your system, using Serial API.

    "Extended" is now in the production phase, check our store and Flyduino store after 1-2 months.
  • Great - thanks again. We will experiment with using the serial API and CMD_AHRS_HELPER for now and I will try one of the extended boards as soon as it is available.
  • @alexmos:

    The SimpleBGC manual states "...methods which are automatically applied by the controller to correct absolute drift and mutual azimuth drift of both sensors" include the following:

    "• Using precise orientation data from an external AHRS system. Using Serial API, you can provide the
    precise orientation of the camera tray or a frame measured by an external system with high-grade IMU using command "CMD_AHRS_HELPER". In this case, an appropriate sensor will be corrected using this data, and the second sensor will be corrected by one of the above methods.
    • Using AHRS data from flight controller - you can connect UAV autopilot (for example, Ardupilot or Naza) to the SimpleBGC32 controller by MavLink protocol, to synchronize their attitudes."


    MavLink is mentioned and this sounds excellent, but I am not aware of this being documented anywhere else. Is the idea to connect an Ardupilot telemetry port to the SimpleBGC serial port, or something else?

    Thank you!
  • Hello,

    Mavlink was mentioned because it support was implemented and planned to be released in 2.56b9. But some problems with its testing caused to not include it in offcicial release, so it will be available in next release of firmware and in neares beta verions of firmware.
  • Cool, very much looking forward to it. We're happy to help you test as well (in an area of the US with occasionally radical weather conditions!), if that would be useful.