Bad BMP085 altitude readings on HK_RED_MULTIWII_PRO board and ardupilot-mpng-mpng-3.0.1-r3

[andrzej-ch]

Hello,

Today I've uploaded ardupilot-mpng-mpng-3.0.1-r3 to my quad for some testing - I was using MegaPirateNG_2.8 R3 until now with quite good alt_hold performance.

What I have noticed is very inaccurate altitude reading in the flight data panel. Altitude changes are about ~20meters. I checked baro condition directly from the terminal and it looks fine (~2meters). I decided to make some test flight to see if altitude is only wrongly presented in "HUD" or it is really affecting flight - unfortunately it is. My quad made some very big jumps as soon as I triggered loiter.

I made further check at home and it looks like there is some problem during altitude calculation based on the pressure. During short test I noticed about 0,2hPa pressure differences and about 20m difference in altitude at the same time. In my geographical location 1hPa change should cause about 10m altitude change.

I have uploaded logs from Mission Planner to DropBox - https://www.dropbox.com/sh/00iqyhrzpndggc8/wPIoU96J9i You can replay them to see last indoor test.

Br, Andrzej

[andrzej-ch]

Is someone from you using this flight controller as well? Do you have the same behaviour?

[SirAlex]

Please, try latest R3 code. I'm made some fixes regarding old boards like HK

[andrzej-ch]

It looks problem is still there - additionally new tests gave new suspicions.

I've noticed that copter orientation affects altitude readings. normal orientation -> altitude tends to increase in short term after rotation upside-down orientation -> altitude tends to decrease

I checked the same looking at baro tests in terminal and altitude looks to be not affected by quad orientation.

terminal -> test -> baro Alt: -0.02m, Raw: 98960.000000 Temperature: 31.7 Alt: -0.75m, Raw: 98968.000000 Temperature: 31.8 ... Alt: -0.75m, Raw: 98968.000000 Temperature: 31.8 Alt: -0.66m, Raw: 98967.000000 Temperature: 31.8 Alt: -0.21m, Raw: 98962.000000 Temperature: 31.8 ... Alt: -0.39m, Raw: 98964.000000 Temperature: 31.8 Alt: -0.11m, Raw: 98961.000000 Temperature: 31.8 Alt: -0.84m, Raw: 98969.000000 Temperature: 31.8 ... Alt: 0.24m, Raw: 98957.000000 Temperature: 31.8 Alt: 0.15m, Raw: 98958.000000 Temperature: 31.8 Alt: 0.15m, Raw: 98958.000000 Temperature: 31.8

Mission planner logs are available under the same DropBox location - files froom 2013-11-19 20-53 https://www.dropbox.com/sh/00iqyhrzpndggc8/wPIoU96J9i

[SirAlex]

Are you tried latest code? I'm updated R3 yesterday.

You see different result, since Altitude you are seen in HUD calculated by INS (Inertial navigation). But in CLI you see raw data from Barometer. Previous R3 code has bug in Gyro and Accel readings, so you see bad results in Altitude calculations.

[andrzej-ch]

I downloaded ZIP for branch mpng-3.0.1-r3 -> https://github.com/MegaPirateNG/ardupilot-mpng/archive/mpng-3.0.1-r3.zip (zip created 2013-11-18 12:18)

[Espenf]

Is mpng-3.0.1-r3 working with ITG3205 Triple Axis Gyro ? Is this IT3200 same as ITG3205?, anyway below says: Only MPU6050 supported for R2 Is support for ITG3205 included in -r3 ?

Release Notes for MegaPirateNG 3.0.1 R2 (ArduPilot 3.0.1) IMPORTANT NOTICE!!! IT3200 gyro doesn't supported in this version!!! Only MPU6050 supported!

(MultiWii PRO_HK_RED uses ITG3205 Triple Axis Gyro)

I have flashed my MultiWii PRO_HK_RED with 2.9.1 R6 and it seems to work, but i wonder if its wise to try mpng-3.0.1-r3 ??

[skoubri]

Hi to all... today just tested my RED board with 3.0.1-R3 and have to report the same issue!... Alt shows what ever it likes... from minus 3 meters to plus 10.. and of course if i engage alt hold it goes like a rocket up or down... Just a notice.. i upgraded from 2.8NG without clearing eeprom... maybe some data corrupted(i am trying right now).. but the copter flied perfect with same settings!

[Espenf]

I have not had any problem with altitude on my MultiWii and MPNG PRO_HK_RED. I remember I had to adjust compass Yaw 135 deg to find North, but that's all. I hope you cover the barometer from sun and wind. I don't understand how you managed to update without clearing eeprom.

[skoubri]

Hi! thanks for sharing your experience!. Hmm. if i remember my Yaw adjustment was 90deg to find N but i am not sure as i didn't test Missions (GPS) yet. Comparing to my Crius V2 and multiwii... EVERYTIME i flash the board the adjustments remain untouched!... same happened with MPNG... after flashing the board with 3.0.1 PIDs and all others.. (even flight modes and other adjustments.. ) were there!.. But this was the problem finally.. before a couple of hours i cleared eeprom, reflashed and BARO worked fine.. Only problem but need more testing is that seems to have some "brownouts".. one time it wanted to fall like a brick!... I don't know why sonar dont work on 3.0.1.. reverted to 2.8 and tested and work ROCK SOLID alt hold! (under 2m +/-5cm~!!!) and over 2m very smooth and good altitude hold. Also one question if we use the stock GPS unit.. whenever i try MTK protocol (binary) it doesn't work... isn't it supported? Only NMEA managed to work.. (have flashed the unit and with MultiWii works fine at binary16 mode...) thanks in advance! (tomorrow i'll do final tests for missions, loiter, etc) P.S. Of course the baro is covered with dark grey foam :)

[Espenf]

My experience was that going from 2.9 version (north on compass was ok) but to latest 3.0.1 I had to use the adjustment in MP to correct north. I believe they removed Sonar from this version on purpose since adaptation was not finished. Other new stuff like auto-tuning I hope will come. Same experience as you I had with the stock GPS, i also had to use NMEA. Best luck for test flight I wish you, and hope for a small update of your results. I was a bit worried about the reported error with motors that stops in previous R2 release, but I think this is fixed now. I discovered that my multistar esc's cut power to the motors one after each other when the voltage dropped. This was with stock setting of the multistar. After reprogramming them with the program card I managed to avoid this happen. I prefer to kill my lipo instead of the quad. I also have a beeper now, but was sorry to hear they have not yet implemented telemetry FRSKY in this version. Also I hear that vibration dampening material should be used when mounting the board. I have not done this yet, but its on the to do list. Before testflight, when I tested my setup I used terminal and run the setup COPASS MOT also. Happy flight!

[skoubri]

Thanks for the info.. so i am continuing using NMEA... I have no issues with ESCs as they are flashed with SimonK firmare.. really much difference!! I also have 3DR telemetry and added voltage & current monitor which works perfect but also a beeper and optical idication through my custom lighting system (GLed). You don't need to worry about dampening if you balance your motors/props its better for the controller to read EVERY movement of the frame.. i have really stable flight!... My only concern now is about BARO as it is very dangerous in missions to calculate wrong height or stop reading height right.. I am coming tomorrow with update of course... otherwise... 2.8 worked super-fine.. (except not smooth loiter). Finally for the sonar i read that its a matter TIMERS that are no available any more in new version :(

[skoubri]

Hi again.. here is the UPDATE: total tests performed today on the field: Clean eeprom, 3.0.1-R3, RED board HK, Yaw dir 90deg, full calibrated and PID tuning, flies almost perfect.. this time BMP085 seemed to work.. at least at the beginning :( starting ALT HOLD worked pretty FINE!!... BUT trying to move around started some "spikes" which were dumped in logs.. strange changes in altitude (and pressure) were recorded.. disabled it continued to fly and when re-enabled it FALLED DOWN like a brick!!!! Checking the graphs it was all recorded but i cannot understand what happened expect that the height took some negative values... So... reverted back to 2.8 R3, with clean eeprom, loaded old settings and flied... soooo... 18,5 minutes (one battery).. ROCK SOLID ALT HOLD, within or out of the sonar range... under 2m about 5cm deviation, over 2m about 0,5-1m deviation... Loiter stable too... so my only conclusion is that something is happening on 3.0.1-R3 and the BMP085!!!!... other than that seemed ok... but of course couldn't check loiter, missions or RTL... I am ending up with 2.8R3 for this board... confirmed to work PERFECT!

[Espenf]

Tnx for your update, I cannot give any info from here now but will focus on the BMP085 next test-run. Don't know when yet either..its wintersports here now! Anyway, tnx for your info and maybe I also have to revert to previous rev..time will show. :)

[jbrazio]

@SirAlex it seems that the altitude hold issue with the HK red board (BMP085) is still there. I've tested the latest stable mpng-3.0.1-r4 and the mpng-3.1-beta. As soon as I engage althold or loiter the quadcopter goes full throttle up without changing xyz attitude, I have to revert back to stable mode before loosing it from sight. I've performed day/night testing, both with the same results.

[nunofmds]

I have the same issues...when I activate the ALT_HOLD or Loiter copter goes up or down ... if i have the throotle position below 60% it goes down else goes up. I tried with the copter on my hands and if I have the coopter on the same position the motors stop! Can you make this test @jbrazio ? Just remove the props and simulate...see what happens...

[jbrazio]

I've checked the code of the working version of mpng 2.8 vs the current beta version and the driver for the 085 is the same with some changes regarding the new scheduling/hardware abstraction layer. So I've almost ruled out any code related bug, of course the expert is @SirAlex so I hope he can really rule that out. Nevertheless what changed in APM since 2.8 is that loiter/althold is now part of the Inertial Navigation System, this means accZ is now being correlated with baro reading, if the acc experiences a lot of vibration on the Z axes, the alt hold will not even work.

[nunofmds]

On 3.0 ALT_HOLD works for me...