Altitde source calculation option #8127
Conversation
add cli setting to choose alt source modify alt calculation
|
job https://travis-ci.com/betaflight/betaflight/jobs/196424414 failed on target ALIENWHOOPF4 but locally I made it sucessfully |
src/main/flight/position.c
Outdated
| @@ -129,23 +144,39 @@ if (sensors(SENSOR_GPS) && STATE(GPS_FIX)) { | |||
| baroAlt -= baroAltOffset; | |||
| gpsAlt -= gpsAltOffset; | |||
|
|
|||
| if (haveGpsAlt && haveBaroAlt) { | |||
| estimatedAltitudeCm = gpsAlt * gpsTrust + baroAlt * (1 - gpsTrust); | |||
| if(positionConfig()->altSource == BARO_ONLY){ | |||
There was a problem hiding this comment.
The build fails because you are not checking haveBaroAlt here - this evaluates as constant false if USE_BARO isn't defined, causing the compiler to drop the entire block, and not tripping over missing barometerConfig on targets with no BARO support.
This should also be done for haveGpsAlt below, and the entire condition should probably be rewritten to check only once, and not once in the outer if, and then again in the inner if.
Also, the #undef USE_VARIO in src/main/target/common_post.h should only be conditional to USE_BARO to correct the dependency on barometerConfig that is tripping up above. But this can be fixed in another pull request.
simplify conditions
src/main/cli/settings.c
Outdated
| @@ -1435,6 +1441,9 @@ const clivalue_t valueTable[] = { | |||
| #ifdef USE_OSD | |||
| { "display_name", VAR_UINT8 | MASTER_VALUE | MODE_STRING, .config.string = { 1, MAX_NAME_LENGTH, STRING_FLAGS_NONE }, PG_PILOT_CONFIG, offsetof(pilotConfig_t, displayName) }, | |||
| #endif | |||
|
|
|||
| // | |||
|
I am glad to see this work-around for the erratic altitude readings when both a barometer and GPS are installed. But does it really make sense to use the GPS altitude at all when a barometer is present? The BMP280 barometer has a relative accuracy of about +/- 1 meter, while consumer-grade GPS altitudes can swing wildly by +/- 10 to 20 meters even under good conditions. When you have an accurate altitude source (i.e., a barometer), how does it help anything to mix it with a poor altitude source? |
|
@SJChannel: There's pros and cons to both barometer and GPS. While more accurate, a barometer's reading is also relative, and subject to drift due to temperature difference and wind, and once it's drifted it's never going to go back again, whereas the GPS' absolute reading may be less accurate, but it's not subject to drift over time. |
|
@mikeller: Thanks for replying. I understand your points, but let me show you some real-world data. Before I discovered this commit, I was investigating the strange altitude readings myself. As part of that, I added some code locally to log the raw BMP280 data in Blackbox for offline analysis. I then did some experiments, including the following. I took my quad (KAKUTEF7) from inside my house and set it on the ground outside. I powered it up and armed it immediately to start the Blackbox logging. I left it just sitting there on the ground (about 100 feet above sea level) with the motors idling for about 20 minutes. Here is the GPS altitude GAlt and the Betaflight derived altitude Alt, as recorded in my radio's telemetry logs:
You can see that Alt remains stable at very close to zero until the GPS obtains a lock. After that, the GAlt fluctuates wildly, and you can clearly see its corrupting influence on Alt. Even after 20 minutes, the GPS is still making things much worse than if only the barometer were used. Meanwhile, blackbox was logging the raw BMP280 output as well as the filtered barometer readings. From the raw BMP280 output I was able to log the temperature, as well. Here's the plot of that data:
The X-axis is elapsed time in seconds. The left-hand Y-axis is altitude (relative to ground level) in meters. The right-hand Y-axis is temperature in degrees C. As you can see, the temperature dropped by about 4 degrees C from taking the quad outdoors, and it possibly caused some drift in the barometer readings. However, it should be noted that the BMP280 compensation code includes compensation for temperature-related drift. The main point I want to make is that even with the temperature change and with possible atmospheric pressure changes over 20 minutes, the BMP280 output drifted by only about 2 meters. That is much, much better than the result obtained by mixing in the GPS altitude. As far as I know, the only way to get accurate altitude readings from GPS is by long-term averaging at a stationary location. That's not achievable in a flying machine. |
|
I forgot to mention that wind can indeed be a problem, but it can be solved by shielding the barometer, e.g., with a piece of foam. |
|
@SJChannel: Not sure if idling a quad on the ground is a good approximation of the pressure / vibration conditions you get in a real flight - it would probably be better to test the barometer in a real flight, and check the altitude reading on the ground before taking off, and then at the end of the flight after landing - in my experience a shielded BMP280 can easily yield 10m altitude drift in a 5 minute flight - as opposed to a GPS which may drift around the correct value, but will never actually permanently drift off. |
|
That is my findings with a 6 minute flight of my quad. Take off was 0 feet AGL and landing was +8,5 AGL. During the course of the flight, the altitude readings were consistent with other measurable items, like my house height, power line height, etc. Readings went up and down as they should. Not sure there is a problem here or not. I will report my findings if I see anything in the near future. |
|
@mikeller @Krohsis: I agree with @mikeller that idling on the ground isn't a sufficient test. I went out a few days ago with the intention of doing a bunch of more realistic flight tests. Unfortunately, I only got one flight that day because one of my camera mount screws vibrated out of the quad and I didn't have a spare. On that flight I had very little altitude drift (BMP280) from beginning to end, but it's true I've seen more drift in the past. I don't think I've ever seen 10 meters of drift, though. The problem with barometers is that a fairly small change in atmospheric pressure (i.e., weather) corresponds to a pretty large change in altitude. If our radios on the ground also had barometers, we could compensate for that. I suppose GPS could help under some circumstances, but we need a better way of determining how precise the GPS reading is at any given moment. Even in the final 5 minutes of my 20-minute ground test above, the GPS reading varied from 50 to 240 feet, a range of 58 meters. |
|
Hi, find this place by looking for some information related with Alt issues I am having. After reading this I thought that I could confirm to @SJChannel that there could be much more altitude drift than 10m. In my case it goes to -50m and more. I started to collect all the information in one place to be able to share it one day with someone who understands this stuff: dgtmdroneissues |
User Story: after adding gps to my quad i've noticed that there was some bad altitude reading. i would like to have option to choose source of altitude calculation. #5890 #7748
Add option to change alt calculation logic.
DEFAULT - unchanged
BARO_ONLY - use only baro to calculate alt
GPS_ONLY - use only gps to calulcate alt
add POSITION_ALT_SOURCE lookup table to enum
add cli setting to choose alt source
modify alt calculation
tested on KAKUTEF7