OpenPilot

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Ok, I tested the filter. It seems to work right. I added the commits to this review and a HIL test could be made...

Ok, I tested the filter. It seems to work right. I added the commits to this review and a HIL test could be made...

It shoul dbe ready, but I would like to test the filter code for proper behaviour before adding it to the review.

It shoul dbe ready, but I would like to test the filter code for proper behaviour before adding it to the review.

I'll try the filter code on my computer, it should behave the same on OP. Trying it out on the HILT would be also good.

I'll try the filter code on my computer, it should behave the same on OP. Trying it out on the HILT would be also good.

could you add the new commits/files to the review? I saw them in the dev branch. or are they not ready yet?

could you add the new commits/files to the review? I saw them in the dev branch. or are they not ready yet?

merged to rel-14.06

merged to rel-14.06

fix WhatsNew for release

Merge remote-tracking branch 'origin/amorale/OP-1358_add_separate_rotation_calibration_offset_revo_only' into rel-14.06

Merge branch 'corvuscorax/OP-1412_Gyrodrift_issue' into rel-14.06

to reflect that I changed the code again to only surpress bad magnetometer values during the initialization phase, during run time the magnetometer is always fed to the filter no matter how bad it ...

to reflect that I changed the code again to only surpress bad magnetometer values during the initialization phase, during run time the magnetometer is always fed to the filter no matter how bad it is (alarms will still be set though to notify the user)

I thought the suppression of these extreme readings would have avoided them, that was the original point to implement them. However I made a fundamental mistake. I thought the EKF would be able to ...

I thought the suppression of these extreme readings would have avoided them, that was the original point to implement them. However I made a fundamental mistake. I thought the EKF would be able to keep its state estimation solid for a prolonged time even without magnetometer input.

This is - as recent tests have unfortunately proven - not the case. As soon as magnetometers go away the yaw orientation becomes immediately unobservable. With this also the rotation around the vertical axis becomes unobservable, and as such the gyro-bias state estimation for the axis combination that corresponds to a rotation around that axis runs away to arbitrary values, yielding a plausible (aka fits the sensor input) but wrong state estimation where the copter is rotating maniacly.

So in order to keep yaw from rotating freely, magnetometer updates need to keep being fed to the filter to restrain this movement, even if the magnetometer values are completely bonkers (if they are they would yield the wrong orientation in yaw, but they still would yield an specific orientation as opposed to "anything goes")

of course erroneous magnetometer inputs also affect the state estimation regarding orientation in roll and pitch, but (thanks to the high magnetometer variance and the also-available accelerometers) to a much lesser degree. The error in resulting attitude is - although significant (several degrees in case of a badly distorted mag field) still safe to fly in most conditions - thanks to the corrections made after Greece.

This all is true but in the end it means you rely on the initial heading to be correct and from that point on more or less rely on the gyro. If for whatever reasons the estimated heading isn't corr...

This all is true but in the end it means you rely on the initial heading to be correct and from that point on more or less rely on the gyro. If for whatever reasons the estimated heading isn't correct any more, the magnetometer doesn't have enough weight to fix this. If an external magnetic field is strong enough to have such an extreme influence as you described then that's a configuration that probably shouldn't be flown anyway (unless you REALLY know what you are doing like you certainly did in Greece . In other words: such high mag variances are probably needed for testing or making extreme setups work but shouldn't be the default. But to be honest - I don't know if a halfway "clean" setup (from an electromagnetic point of view) is possible on a plane with battery in front and motor in the back. External magnetometers would be a perfect fix here but that's a different story of course. Btw. would the supression of extrem mag readings that you implemented lately probably have been enough to avoid the problem you saw in Greece?

you could make a temporary modification to the airspeed filter that feeds a series of sin(x) to the butterworth filter and outputs to a file as CSV for postanalysis in matlab you can use simposi...

you could make a temporary modification to the airspeed filter that feeds a series of

 sin(x) 

to the butterworth filter and outputs to a file as CSV for postanalysis in matlab you can use simposix for that. (should be a 5 minute thing)

Yep, first order Butterworth is the same as the usual LPF. A nice pic of the difference in gain depending on the order is found on Wikipedia: http://de.wikipedia.org/wiki/Butterworth-Filter#mediav...

Yep, first order Butterworth is the same as the usual LPF. A nice pic of the difference in gain depending on the order is found on Wikipedia:

http://de.wikipedia.org/wiki/Butterworth-Filter#mediaviewer/Datei:Butterworth_orders.svg

It performs better anywhere where a good cut-off behaviour is needed, so in particular when the values are differentiated, The overhead is not that much higher: 3 coefficients and 2 storage variables (5 *4 = 20 bytes) and a couple more operations. By the way, higher orders can be obtained by chaining.

I implemented the changes and commited these. However, I need to test the code here on the dry to be sure that I didn't add any errors during optimization of the code...

OP-1412 do not dicard mags after init

P.GyroDrift is the initialization value for P at filter start, aka the initial state variance assumed for the initial value for GyroDrift. The initial value for gyrodrift is zero, which is usually ...

P.GyroDrift is the initialization value for P at filter start, aka the initial state variance assumed for the initial value for GyroDrift. The initial value for gyrodrift is zero, which is usually quite accurate if the user has calibrated their gyros. The previous higher value was tuned to be able to cope with uncalibrated gyros, which sometimes had a bias of up to 7 deg/s. Thanks to the gyrocalibration and temperature calibration that is no longer necessary, so the filter can init with a lower variance, making it converge on a stable state estimation faster.

By the way, the variance of each state variable can be observed on runtime, there's an UAVObject for that (EKFVariance)

you weren't in Greece last year when we increased R.Mag to 5000. The original value was lower (I think 500, would have to check git log) but we had a near crash due to in flight mag distortion. We ...

you weren't in Greece last year when we increased R.Mag to 5000.
The original value was lower (I think 500, would have to check git log) but we had a near crash due to in flight mag distortion.
We were flying a phantom flying wing - the same used for the 20km flight - in an early test flight. PID's were already setup, and I wanted to test nav flight, so I had the flightmodes stabilized (for takeoff) positionhold and waypoint nav)
When the autopilot requested high throttle, the magnetic field of the battery power cables (although twisted, but they might have shifted closer to the revo-board in the air) caused the attitude to shift simulating a pitch up manouver. With the mag variance relatively low, it was low enough to partially override the accelerometers, so the attitude assumed almost 10 degrees nose up when really it was level.

Stabilization of course corrected by pushing the nose down, as it should.
Then the Autopilot corrected - seeing an increase in descent speed (VelocityActual.Down) and demanded both higher pitch and higher throttle.
The higher throttle created an even greater magnetic field ans thus attitude error, while the craft staid level (higher pitch demand eaten up by increased pitch state estimation error)
Eventually the pitch increased beyond the maximum positive pitch configured for the autopilot and it was no longer willing and able to pitch up more, so it just increased throttle to maximum. At that time the phantom wing was in a shallow descent at very high speed, aiming at the RC-hotel bar.

At that point I switched to Stabilized mode and tried to pitch up. Problem is, even in stabilized mode there is a maximum pitch configured (I think 40 degrees) - and at that time the attitude error was that severe that even while I was pulling up with all I had, the vehicle kept going straight - it passed over the hotel by just a few meters.

All of that happened within only a few seconds. By then I cut throttle, as the plane was beyond line of sight behind the roof. As soon as throttle was cut the attitude state corrected itself almost instantly, and the plane went into a steep climb, barely missing a tree. I had it back in sight and flew it back to the runway with low throttle and was able to land.

We were able to reproduce the issue on the ground, observing the severe pitch up on the FPV when throttle was increased - while the plane was stationary.

After that we increased the magnetometer variance, so that even completely fucked up mags will not be able to override roll and pitch estimate as indicated by accelerometers.

Increasing the mag warning level and at the same time decreasing R.Mag would possibly bring this quite dangerous behaviour back. Therefore I'm very hesitant to decrease R.Mag

i fully agree as well. the Butterworth filter definitely belongs in libraries/math. It might not be necessary in all cases where we do a low pass filter (the filter here is a 2nd order butterworth ...

i fully agree as well. the Butterworth filter definitely belongs in libraries/math. It might not be necessary in all cases where we do a low pass filter
(the filter here is a 2nd order butterworth filter, the lpf we are usually using mathematically equivalent to a first order butterworth filter if i'm not mistaken. it's decay below the cutoff frequency is I think 12 db per octave, while the LPF has only 6db per octave, but both share the same nice ripple-free filter properties, and both create unwanted lag/phase-shift/filter-delay)
but it's definitely something that should be available for reuse wherever needed

I don't think lowering P.GyroDrift really helps with the issue described in OP-1412. If the gyro drift estimate is perfect it makes sense sticking to it but if not a low P will make it harder to co...

I don't think lowering P.GyroDrift really helps with the issue described in OP-1412. If the gyro drift estimate is perfect it makes sense sticking to it but if not a low P will make it harder to correct this. The only thing that can really stop gyro drift is the magnetometer so my proposal would be to increase MagnetometerMaxDeviation and decrease EKFConfiguration.R.Mag. We currently have R.Mag set to 5000 which means we are nearly ignoring the mags. My current setup (which is probably a bit too extrem) has R.MagXYZ = 10 and MagnetometerMaxDeviation.Warning/Error = 0.5/0.8. I really think even a somehat bad mag update is better than no update at all. If this sometimes leads to a heading error of 10 or 20 degress that's certainly not nice but also not fatal while having a free drift that stays uncorrected can lead to any heading over time (-> flyaway).

OP-1317 uncrustify

    • -1
    • +0
    /flight/modules/Airspeed/imu_airspeed.c
OP-1317 removed comments

    • -101
    • +3
    /flight/modules/Airspeed/imu_airspeed.c
OP-1317 added M_2PI_F and M_2PI_D constants for 2*pi in pios_math.h

OP-1412 change initial gyro bias uncertainty variance setting
OP-1412 change initial gyro bias uncertainty variance setting
OP-1412 change systemalarms to update periodic to not loose data

OP-1412 delay ekf initialization until magnetometers are reporting valid data

OP-1412 change initial gyro bias uncertainty variance setting

from 1e-4 to 1e-6 to allow more stable filter initialization.

this is now valid thanks to available temp compensation and gyro bias

calibration in GCS

OP-1317 added Butterworth filter code files flight/libraries/math/butterworth.*

    • -0
    • +102
    /flight/libraries/math/butterworth.c
    • -0
    • +46
    /flight/libraries/math/butterworth.h