I have a brand new (fresh out of the box) 3DRobotics IRIS and everything works well except the drone doesn’t hold altitude reliably in alt_hold, loiter or auto modes. For example if the drone is set to loiter indefinitely at 20m then the actual altitude will fluctuate between say 4m to 25m.
The attached graph and log file shows the IRIS set to loiter indefinitely at 10m, however the actual altitude varied between 10.6m and 3.1m. The graph also shows that the derived relative altitude does not track barometer altitude well. The graph also shows there are no vibration problems.
After a long debugging effort (including replacing the Pixhawk) it turns out the problem was completely resolved by downgrading the AC 3.1.2 (e2ed3dd1) firmware to AC 3.1.1 (681dafcf). Looking at the git change log between the two releases it looks like one of the new features in 3.1.2 is "Pixhawk baro bug fix to SPI communication which could cause large altitude estimate jumps at high temperatures" github.com/diydrones/ardupilot/ … eNotes.txt
Is it possible that this change actually introduced a bug?
Although my immediate problem is resolved by downgrading to AC 3.1.1 it would be great to get the alt_hold problem fixed in next release!
I’m having the same problem in alt_hold on my IRIS. I don’t use alt_hold that much right now so I’ll wait to see what other input we get. Good catch BTW. I’ve been looking for tuning changes but it looks like I will discontinue that approach.
The issue here definitely is not the baro, so that patch has nothing to do with the problem. That leaves vibrations. The magnitude of the vibrations is certainly not a problem, but the frequency content may be just right to cause some aliasing.
I’m afraid I don’t really have an answer other than to look at improving vibrations. I strongly believe your improvement with firmware version is a case of correlation, not causation.
The improvements in the next version should help. They include a 21-state extended kalman filter that makes use of both IMUs for vibration resistance.
However if the frequency content of the vibrations is causing aliasing wouldn’t that show up in “Alt” - the output of the algorithm that combines the barometer and accelerometer sensor data?
Just after line 44k there is a sharp drop in throttle output (ThrOut) even though the relative altitude (Alt) is still below the desired altitude (DAlt). That would suggest that at least part of the problem is occurring somewhere in the control loops i.e. after Alt has been calculated. I guess accelerometer data is used both to calculate Alt and then later in the control loops to provide stabilization.
BTW the alt_hold problem with AC 3.1.2 was very consistent and repeatable over say 20 flights; while I’ve not seen it once yet with AC 3.1.1 over say 10 flights. Flights were all in relatively calm conditions.
I finally got my IRIS out today and made it out of stability mode. Unfortunately I struggled with the same thing. I had it even in Loiter mode, and following Waypoints.
I have yet to look into the logs, but reading the live data, it appears that the altitude reading is very inaccurate, which is causing the errors, rather than the IRIS not being able to hold altitude.
If alt isn’t tracking baro alt, the problem is with the INAV. A sharp drop in ThrOut is probably from the copter sharply changing from tilted to level.
The flight corresponding to the attached log was produced in very calm and controlled conditions; I was standing close to the drone watching carefully and there were no signs of any twitching or tilting. The drone just drifted up and down, pretty much tracking BarAlt as far as I could tell.
There were no changes to the drone between 3.1.2 and 3.1.1. Actually I performed the downgrade from 3.1.2 to 3.1.1 ‘in the field’ and on the same day and without changing any parameters. After downgrading to 3.1.1 the IRIS was rock solid in terms of altitude and has shown no signs of any altitude hold problems since then (over 12+ flights).
The alt_hold problems with 3.1.2 were observed with two Pixhawk modules (the original that shipped with IRIS, and a replacement that 3DR kindly provided to help debug this problem). Changing the Pixhawk didn’t seem to make any difference to the observed altitude problem under 3.1.2.
Something I noticed with the attached log file is that some captured values are very high e.g.
7775: IMU, 2735031109, -1.849559e+21, -0.000326, -2379695., 0.000000, -0.000000, 0.000000
15428: CTUN, 537234332, 1323, 10496, 4096, 0.000000, -0.000000, -2.05e+07, 110.40, 0.05, 1504, 1504
25344: IMU, 468221, -0.000000, 0.000000, 7.302271e+37, -0.000000, -0.005424, -3.972609e+23
45185: IMU2, 2735311748, 0.000000, 5.118975e+20, 652.9689, 5.483534e+23, -1.082187e+32, 0.000000
GPS Glitch detection disabled when connected via USB
RC_FEEL_RP param added for adjusting responsiveness to pilot roll/pitch input in Stabilize, Drift, AltHold
Pixhawk baro bug fix to SPI communication which could cause large altitude estimate jumps at high temperatures
It’s a long shot, however could the glitches in the log file be the result of an SPI bug affecting IMU data in 3.1.2 that was somehow introduced by fixing the SPI bug that was affecting baro sensor data in 3.1.1?
Thank you for digging into this issue, really appreciate it!
The flight corresponding to the attached log was produced in very calm and controlled conditions; I was standing close to the drone watching carefully and there were no signs of any twitching or tilting. The drone just drifted up and down, pretty much tracking BarAlt as far as I could tell.
There were no changes to the drone between 3.1.2 and 3.1.1. Actually I performed the downgrade from 3.1.2 to 3.1.1 ‘in the field’ and on the same day and without changing any parameters. After downgrading to 3.1.1 the IRIS was rock solid in terms of altitude and has shown no signs of any altitude hold problems since then (over 12+ flights).
The alt_hold problems with 3.1.2 were observed with two Pixhawk modules (the original that shipped with IRIS, and a replacement that 3DR kindly provided to help debug this problem). Changing the Pixhawk didn’t seem to make any difference to the observed altitude problem under 3.1.2.
Something I noticed with the attached log file is that some captured values are very high e.g.
7775: IMU, 2735031109, -1.849559e+21, -0.000326, -2379695., 0.000000, -0.000000, 0.000000
15428: CTUN, 537234332, 1323, 10496, 4096, 0.000000, -0.000000, -2.05e+07, 110.40, 0.05, 1504, 1504
25344: IMU, 468221, -0.000000, 0.000000, 7.302271e+37, -0.000000, -0.005424, -3.972609e+23
45185: IMU2, 2735311748, 0.000000, 5.118975e+20, 652.9689, 5.483534e+23, -1.082187e+32, 0.000000
GPS Glitch detection disabled when connected via USB
RC_FEEL_RP param added for adjusting responsiveness to pilot roll/pitch input in Stabilize, Drift, AltHold
Pixhawk baro bug fix to SPI communication which could cause large altitude estimate jumps at high temperatures
It’s a long shot, however could the glitches in the log file be the result of an SPI bug affecting IMU data in 3.1.2 that was somehow introduced by fixing the SPI bug that was affecting baro sensor data in 3.1.1?
Thank you for digging into this issue, really appreciate it![/quote]
The log is corrupt. Please get the .BIN log from the PIXHAWK SD card.
Unfortunately the .log file initially posted is from the original Pixhawk unit which has now been returned to 3DRobotics, so I’m not able to get the corresponding .BIN file.
However here are .BIN files for the flights immediately before and after downgrading from AC 3.1.2 to AC 3.1.1. The flights were actually on subsequent days, and although I don’t remember making any changes to the drone - it is possible I installed a new prop between those flights. The graph with AC 3.1.1 does show lower vibrations.
Given that the original log file showed low vibration during alt_hold instability I had discounted that as a possible cause, so wasn’t actively looking for vibrations. However as you mention it could be that the frequency of the vibrations were such that aliasing was occuring with the initial log, even though the amplitude was low.
[attachment=1]AC 3.1.2 (2014-03-21 17-13-12).png[/attachment]
[attachment=3]AC 3.1.1 (2014-03-22 16-21-53).png[/attachment]
OK thanks for that. When I have time I might try some back to back A (3.1.1) / B (3.1.2) testing with the IRIS to confirm. However in the meantime thank you for taking a look; I’ve accepted the answer.
I’m not familiar with the detailed workings of the software. However in general for a signal to alias with a sampler over an extended duration there would need to be phase alignment between the sampling points and peaks or troughs of the signal. It’s a tough requirement, however it may well be the case given the precise motor control and various control loop that are running.
Will be great if a future release can avoid altitude instability even with a higher level of vibration!