# Position\_estimator\_inav and mc\_pos\_control failure on Snapdragon

**URL:** <https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365>\
**Category:** PX4 Autopilot\
**Created:** [April 26, 2016, 11:20am UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365 "2016-04-26T11:20:09Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![langxm1223](https://discuss.px4.io/user_avatar/discuss.px4.io/langxm1223/32/3948_2.png) [@langxm1223](https://discuss.px4.io/u/langxm1223)\
**Post date:** [April 26, 2016, 11:20am UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/1 "2016-04-26T11:20:09Z")

</div>

Hello All,  
I am using snapdragon and want to use offboard mode to implement takeoff behavior.  
What I have is baro, IMU, optical flow modules.  
I checked the log and found several problems.  
First, with only baro available to correct z on the ground, the z\_est[0] and z\_est[1] were drifted about ±0.5 or so. After changed the baro weight to 3.5, z\_est[0] is a little bit better, but z\_est[1] is still bad. Further tests show that the acc[2] is not stable, sometimes with value more than 1. Is this expected? or any other reason for this issue? or any comments on the correction function,inertial\_filter\_correct?  
Second, with bad velocity estimation, position controller cannot be performed well. Is it good to use only one position PID loop instead of two loops?  
Any comments are really appreciated.  
Thank you in advance.

Xiaoming

---

<div class="post-metadata">

**Author:** ![LorenzMeier](https://discuss.px4.io/user_avatar/discuss.px4.io/lorenzmeier/32/17_2.png) [@LorenzMeier](https://discuss.px4.io/u/LorenzMeier)\
**Post date:** [April 27, 2016, 2:33pm UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/2 "2016-04-27T14:33:21Z")

</div>

@tumbili Can you comment here?

---

<div class="post-metadata">

**Author:** ![langxm1223](https://discuss.px4.io/user_avatar/discuss.px4.io/langxm1223/32/3948_2.png) [@langxm1223](https://discuss.px4.io/u/langxm1223)\
**Post date:** [April 28, 2016, 8:07am UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/3 "2016-04-28T08:07:43Z")

</div>

Thanks Lorenz.  
For better diagonise, I attached the accz output below.  
This is the raw data from IMU after arming with propellers. I am not sure whether it is good to use before software filtering.  
I wonder if the sin-shape vibration has any specific source.

 ![](https://discuss.px4.io/uploads/default/original/1X/322b3575f804f0e2257c2232cbaf1668dd73f6be.png)

---

<div class="post-metadata">

**Author:** ![tumbili](https://discuss.px4.io/user_avatar/discuss.px4.io/tumbili/32/3779_2.png) [@tumbili](https://discuss.px4.io/u/tumbili)\
**Post date:** [April 29, 2016, 5:35am UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/4 "2016-04-29T05:35:46Z")

</div>

Hi,  
thanks for reporting this issue! Actually we are experiencing estimation issues on our side as well and at the moment it looks like it is related to the IMU data. We are in the process of reviewing the drivers and discussing potential filtering of the data. Will let you know what the results are.

Roman

---

<div class="post-metadata">

**Author:** ![langxm1223](https://discuss.px4.io/user_avatar/discuss.px4.io/langxm1223/32/3948_2.png) [@langxm1223](https://discuss.px4.io/u/langxm1223)\
**Post date:** [April 29, 2016, 7:48am UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/5 "2016-04-29T07:48:59Z")

</div>

Thank you tumbili.  
I have used window filter to process the IMU data to ± 1 error.  
Another issue is barometer, which seems have only ±1m accuracy with noise.  
Further problem may be caused by the inertial\_filter\_correct function in position\_estimator\_inav.  
I appreciate if you could share any results to improve this.  
Thanks a lot.

---

<div class="post-metadata">

**Author:** ![JulianOes](https://discuss.px4.io/user_avatar/discuss.px4.io/julianoes/32/30_2.png) [@JulianOes](https://discuss.px4.io/u/JulianOes)\
**Post date:** [May 9, 2016, 6:45pm UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/6 "2016-05-09T18:45:21Z")

</div>

I see two separate problems here:

**IMU noise:**

When looking at the IMU data in the log or at the mavlink output in QGC, you’re only looking at 1 out of 32 for the gyro, or 1 out of 16 accel samples. The reason is that the MPU9250 FIFO buffer is read at 8kHz but the data is only published at 250 Hz.

Recent flight tests with ekf2 have been quite successful, however, it’s not finalized what the filter/integration solution should be.

I would advise you to use ekf2 for the time being and check back on the issue that I just created: [https://github.com/PX4/DriverFramework/issues/75](https://github.com/PX4/DriverFramework/issues/75).

**Baro noise:**

The baro needs to be covered with foam (permeable by air) to filter the effects of wind, orientation, copter movement, etc.  
Also, it should not be directly exposed to sunlight.

---

<div class="post-metadata">

**Author:** ![langxm1223](https://discuss.px4.io/user_avatar/discuss.px4.io/langxm1223/32/3948_2.png) [@langxm1223](https://discuss.px4.io/u/langxm1223)\
**Post date:** [May 10, 2016, 12:28am UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/7 "2016-05-10T00:28:12Z")

</div>

Thank you Julian.  
I added some output in the mpu9x50\_main to see every output from mini-dm. The noise is from the resonance of the motors spinning. I tried several methods, from hardware to software. And my problem is that what accuracy of the accelerometer is good to use? like ±5m/s^2?  
I found the barometer’s problem as well. The spining of the propollers did have effect on the data.  
If inav estimator is used, the parameters should be selected very carefully.  
I will keep following this issue.  
Thank you very much.

---

<div class="post-metadata">

**Author:** ![JulianOes](https://discuss.px4.io/user_avatar/discuss.px4.io/julianoes/32/30_2.png) [@JulianOes](https://discuss.px4.io/u/JulianOes)\
**Post date:** [May 10, 2016, 7:25am UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/8 "2016-05-10T07:25:39Z")

</div>

@langxm1223,

I don’t know exactly what data you can expect when using the mpu9x50. I am only working with the open source variant which is the df\_mpu9250\_wrapper and the mpu9250 driver of the [DriverFramework](https://github.com/PX4/DriverFramework).  
Also, everything I’ve said above relates to it and not the mpu9x50.

In general, it is a good advise to use some vibration isolation/dampening of the sensor (Snapdragon board in this case) against the motors/frame.  
The two effects to avoid are usually:

- The full sensor range (+/- 16 G) is exceeded, therefore the signal gets clipped.
- Aliasing occurs when prop/motor vibrations are sampled.

---

<div class="post-metadata">

**Author:** ![JulianOes](https://discuss.px4.io/user_avatar/discuss.px4.io/julianoes/32/30_2.png) [@JulianOes](https://discuss.px4.io/u/JulianOes)\
**Post date:** [May 11, 2016, 8:55pm UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/9 "2016-05-11T20:55:51Z")

</div>

Just FYI, if you want to try the inav\_position\_estimator again on Snapdragon, you could try this pull request:

> <https://github.com/PX4/Firmware/pull/4509>

Instead of using/publishing 1 out of 32 samples, the df\_mpu9250\_wrapper now takes the mean over 32 samples and publishes the result.

---

<div class="post-metadata">

**Author:** ![langxm1223](https://discuss.px4.io/user_avatar/discuss.px4.io/langxm1223/32/3948_2.png) [@langxm1223](https://discuss.px4.io/u/langxm1223)\
**Post date:** [May 12, 2016, 1:42am UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/10 "2016-05-12T01:42:51Z")

</div>

Thank you Julian.  
I also used a filter to process the acc raw data. And the result is attached.

 ![](https://discuss.px4.io/uploads/default/original/1X/92cbad2dae348925a21200fcb963f0641d48c76d.jpg)  
The red one is filtered data, with blue one raw.  
My problem was whether this red one is good to use in the position estimator module? Since both the ekf2 and inav use the acc to predict the state. Large deviation make lead to bad prediction and I am not sure if the correction step could pull the estimation back to the good value.  
Oh, and any filter would have a delay effect, does it matter?  
I will try the new pull and test.  
Thank you very much.

---

<div class="post-metadata">

**Author:** ![langxm1223](https://discuss.px4.io/user_avatar/discuss.px4.io/langxm1223/32/3948_2.png) [@langxm1223](https://discuss.px4.io/u/langxm1223)\
**Post date:** [May 19, 2016, 2:52am UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/11 "2016-05-19T02:52:39Z")

</div>

Hello @JulianOes  
I did some more tests on Snapdragon flight recently. And the IMU problem seems better after I changed to higher freq and take average of 16 samples.  
The remained problem is the estimation itself.  
In the Atlflight version of PX4 firmware, there is no ekf2 module compiled. Moreover, in the ekf\_att\_pos\_estimator module, there seems no optical flow topic subscription, which is what I am using to estimate xy position, so I have to stick on the inav modules.  
I believe my optical flow info is correct, but the estimation of xy is not good enough. I wonder if it is good that optical flow can correct xy position, instead of only correcting velocity currently.  
The code from ATLflight version is quite different from the master branch of PX4, do you think that is critical for estimation or control?  
Thank you very much.

---

<div class="post-metadata">

**Author:** ![JulianOes](https://discuss.px4.io/user_avatar/discuss.px4.io/julianoes/32/30_2.png) [@JulianOes](https://discuss.px4.io/u/JulianOes)\
**Post date:** [May 19, 2016, 12:20pm UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/12 "2016-05-19T12:20:55Z")

</div>

Why are you using the state of ATLflight?

[dev.px4.io](http://dev.px4.io) suggests to use the PX4 repo and that’s where all the development happens and we (as PX4) try to support as well as possible.

That’s also where you get ekf2 and all other fixes that we’ve been working on.

---

<div class="post-metadata">

**Author:** ![langxm1223](https://discuss.px4.io/user_avatar/discuss.px4.io/langxm1223/32/3948_2.png) [@langxm1223](https://discuss.px4.io/u/langxm1223)\
**Post date:** [May 20, 2016, 1:00pm UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/13 "2016-05-20T13:00:05Z")

</div>

I bought the board from Intrinsyc and followed the provided instructions.  
In the PX4 user guide from Intrinsyc, ATLflight version is written to be installed.  
I did not know that PX4 master firmware also supports this board, since there is not any instructions besides some installation steps.  
I tried to build PX4 on Snapdragon recently, but there are still some errors while running mainapp.  
I will do more tests, but kind of confused which version should be used.  
Thank you for your reminds so much.

---

<div class="post-metadata">

**Author:** ![Sam](https://discuss.px4.io/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@Sam](https://discuss.px4.io/u/Sam)\
**Post date:** [May 21, 2016, 7:11pm UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/14 "2016-05-21T19:11:15Z")

</div>

@langxm1223 Hi I’m also working on snapdragon flight, we have built a quadrotor X frame, and can drive motors now. May I ask two questions, firstly, how do you connect battery to snapdragon flight board, and how much battery voltage you use. Secondly, have you tested use RC to control snapdragon?

---

<div class="post-metadata">

**Author:** ![langxm1223](https://discuss.px4.io/user_avatar/discuss.px4.io/langxm1223/32/3948_2.png) [@langxm1223](https://discuss.px4.io/u/langxm1223)\
**Post date:** [May 22, 2016, 12:54am UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/15 "2016-05-22T00:54:16Z")

</div>

Hi Sam,  
I am also new to such board, so I think it is better that you try yourself no matter what I would say 🙂  
First, the battery can be connected to the board via a battery distributor PCB, which can distribute the battery to esc, snapdragon board and other devices. The voltage depends on the size of your quad, e.g. 2S is for small quad.  
Second, I can use RC to control the board to fly.  
Both of these could be found in the guide files provided by Intrysc. However, I am not sure which PX4 you used, and still confused these different versions.  
Hope this helps.  
Thanks.

---

<div class="post-metadata">

**Author:** ![Sam](https://discuss.px4.io/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@Sam](https://discuss.px4.io/u/Sam)\
**Post date:** [May 22, 2016, 2:03am UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/16 "2016-05-22T02:03:47Z")

</div>

In case of damaging the board, we want make sure if the power module delivered by Intrinsyc can support 3S battery. The RC really has confused me. As you know, snapdragon send out PWM data via J13’s UART, we also want to send RC information to snapdragon via J15’s UART, but don’t clear about the MAVLINK frame format the RC information should be. If your snapdragon can fly, could you share your RC solution?

---

<div class="post-metadata">

**Author:** ![langxm1223](https://discuss.px4.io/user_avatar/discuss.px4.io/langxm1223/32/3948_2.png) [@langxm1223](https://discuss.px4.io/u/langxm1223)\
**Post date:** [May 22, 2016, 3:02am UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/17 "2016-05-22T03:02:39Z")

</div>

I have not tried 3S battery, so I cannot say it can support.  
If you complied the PX4-Firmware version, it will send PWM via MAVLINK.  
However, in Intrynsic’s px4 user guide, the ATLflight version is used. In that one, the RC signal is sent out through some driver in DSP side. So I am afraid the you can try this version.  
Thanks.

---

<div class="post-metadata">

**Author:** ![Sam](https://discuss.px4.io/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@Sam](https://discuss.px4.io/u/Sam)\
**Post date:** [May 22, 2016, 4:51am UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/18 "2016-05-22T04:51:11Z")

</div>

Thanks for your reply. I just reviewed the ATLflight code, rc\_receiver\_main.cpp is much straightforward than the PX4 version, if you can fly snapdragon flight stably, I’ll try it.

---

<div class="post-metadata">

**Author:** ![bharathr](https://discuss.px4.io/letter_avatar_proxy/v4/letter/b/9fc348/32.png) [@bharathr](https://discuss.px4.io/u/bharathr)\
**Post date:** [June 30, 2016, 11:47pm UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/19 "2016-06-30T23:47:31Z")

</div>

In the latest version of the PX4 User Guide from Intrinsyc (available from [http://support.intrinsyc.com/projects/snapdragon-flight](http://support.intrinsyc.com/projects/snapdragon-flight)), we have updated instructions and a new release that incorporates EKF2. It uses proprietary drivers for RC Receiver and ESC but uses the open source MPU driver in the Driver Framework. The build procedure is slightly different from [http://dev.px4.io](http://dev.px4.io), but we will replace our proprietary drivers with the upstream drivers shortly.

---

<div class="post-metadata">

**Author:** ![langxm1223](https://discuss.px4.io/user_avatar/discuss.px4.io/langxm1223/32/3948_2.png) [@langxm1223](https://discuss.px4.io/u/langxm1223)\
**Post date:** [July 3, 2016, 3:19pm UTC](https://discuss.px4.io/t/position-estimator-inav-and-mc-pos-control-failure-on-snapdragon/365/20 "2016-07-03T15:19:43Z")

</div>

This would be very helpful.  
I will test it and thank you so much~
