Jump to content


Photo

Revo yaw attitude drift problem


  • Please log in to reply
56 replies to this topic

#1 D-Lite

D-Lite

    Core Team

  • Members
  • PipPipPip
  • 1648 posts
  • Country: flag of Germany Germany


Posted 24 July 2012 - 10:01 AM

I currently have a problem which don't understand. The boad is calibrated and sits flat on the desk, not moving at all. But yaw attitude indicates a constant rotation which I cannot get rid of. The only thing I can do is to decrease mag variance way below what I have for accles and gyros (0.001 vs. 0.01 for example). this obviously isn't the right thing to do.

What I don't understand when I look at the scopes is that the attitude z-rotation is in positive direction while the z-gyro is lowly increasing from it's original 0 setpoint - just as if there a gyro compensation in place that works in the wrong direction. This is how it looks like:

Attached File  scope.JPG   116.16K   41 downloads

if I set "BiasCorrectedRaw" to false, the z-gyro is not increasing so this isn't gyro drift itself but something with the compensation that goes wrong. Any ideas? Oh, the branch is james/revo, I'm going to test this on revo-next also.

#2 peabody124

peabody124

    Banned

  • Banned
  • PipPipPip
  • 5870 posts
  • LocationHouston, TX
  • Country: flag of United States United States


Posted 25 July 2012 - 06:52 AM

Which estimation mode are you using? Indoor, outdoor or complimentary? I was working on that the other day and now if I initialize it to the wrong value it was converging to the right one. (Using indoor). I'm recompiling GCS now and will retest in a few.
Testing crumple zones

#3 peabody124

peabody124

    Banned

  • Banned
  • PipPipPip
  • 5870 posts
  • LocationHouston, TX
  • Country: flag of United States United States


Posted 25 July 2012 - 07:03 AM

Indoor mode:
  • Accelerometer bias calibration correctly zeros gyros
  • It corrects 1 or 2 degrees of bias without issue Posted Image
Complimentary mode:
  • Accelerometer bias calibration zeros properly
  • It corrects the X & Y fine although more slowly that Indoor mode (check AccelKi).. Z it corrects too slowly but there is a magKp and magKi in attitude.c that you can tweak.
Feel feel to send you UAVO file.
Testing crumple zones

#4 peabody124

peabody124

    Banned

  • Banned
  • PipPipPip
  • 5870 posts
  • LocationHouston, TX
  • Country: flag of United States United States


Posted 25 July 2012 - 07:08 AM

One thing I noticed from your result - if the gyro is off enough to make it start spinning then I'm not sure it will be able to fix it. Try dialing the mag var to 0.01 (or check what I had in my position hold thread uavo).

Also if you run the accel level button it should also zero out the gyros better than your screen shot.
Testing crumple zones

#5 D-Lite

D-Lite

    Core Team

  • Members
  • PipPipPip
  • 1648 posts
  • Country: flag of Germany Germany


Posted 25 July 2012 - 08:19 AM

Which estimation mode are you using? Indoor, outdoor or complimentary?


That was Indoors. Complimentary has no issues at all. What I also saw when raising accel and mag variance (to see the "raw" influence of gyros to the attitude) is that attitude was oscillating at 0.07 - 0.1 Hz with 10-20deg amplitude. I would expect drift but not oscillations. In fact, it's drift+ oscillations what I'm seeing.


Try dialing the mag var to 0.01 (or check what I had in my position hold thread uavo).


That's what I did and it helps a bit but after some fast movements, the yaw attitude was totally of again (up to 180 deg). I'll do some tests later this day. I should probably also do the mag calibration more accurately (but from the scope it looks good). In the end, we cannot expect to get more than 1-2deg accuracy from the mag (I think), even if calibrated well. And in reallity, it will be much worse because of all the magnetic fields on a quad.

#6 Corvus Corax

Corvus Corax

    subversive revolutionist

  • Administrators
  • 995 posts
  • LocationStuttgart, Germany
  • Country: flag of Germany Germany


Posted 25 July 2012 - 12:40 PM

Very very important detail: Unlike the accelerometer calibration (for which the board is best put in a lab with a spirit level to place it completely flat) the magnetometer calibration needs to be done in the frame in ready to fly condition.

We had cases in Portugal on fixed wings where simply switching the battery of the plane led to an almost 50% offset of the raw magnetometer reading and required recalibration.

If the board is fixed with metal screws that actually gets worse, since those often carry a magnetic field from magnetic screwdrivers and are very close to the sensor. The sensor still works perfectly but it needs to be re-calibrated if one just as much as turned one of those screws!

In Portugal I did a little ritual prior to any flight - the hillarious "magnetometer dance". during this I had telemetry connected and magnetometer values displayed. as you turn all three axis in and out of the magnetic field vector, each curve must go throgh the same range (typically between +500 and -500 - ish or +1000 to -1000 depending on calibration) the total scale of the minima and maxima doesn't matter much , but if they are offset to each other, you can forget the magnetometer, the EKF cannot compensate that and it can be worse than flying without.

#7 D-Lite

D-Lite

    Core Team

  • Members
  • PipPipPip
  • 1648 posts
  • Country: flag of Germany Germany


Posted 25 July 2012 - 01:03 PM

the magnetometer calibration needs to be done in the frame in ready to fly condition.


Yes, I'm aware of that. I currently do bench tests only on wooden table, so no metal close to the mag :).

We had cases in Portugal on fixed wings where simply switching the battery of the plane led to an almost 50% offset of the raw magnetometer reading and required recalibration.


Yes, that's an additional problem (and a very serious one because the current through the wires isn't static). That's why I'm a bit concerned about giving the mag too much weight in the EKF but if I don't do that, yaw drifts like hell, even if gyro-z is pretty close to zero and that's something I don't understand. E.g. if I let the GCS do the variance calculation, it tells something about 2-3 for the gyro variance. It fells wrong to have to set it to 0.01 just to compensate for the yaw drift..

Here's some strange behaviour I see after booting the board. the first 20 seconds looks okay, then "something" kicks in and starts to mess up the yaw attitude, don't know what this could be.. mags have been set to variance 100 so practically disabling them.:

Attached File  reboot.JPG   118.84K   38 downloads

Here's the uavconfig.

Attached File  reboottest.uav   13.41K   2 downloads

Don't nail me down on that config, I also tried a lot of different settings :-)

#8 peabody124

peabody124

    Banned

  • Banned
  • PipPipPip
  • 5870 posts
  • LocationHouston, TX
  • Country: flag of United States United States


Posted 25 July 2012 - 01:20 PM

Yea so the first point about the magnetic variance actually it would be good to have Dale comment on. The mag is actually scaled to unity before being used by the EKF. That means the variance is also interpreted on that scale. This is next on my list of fucking-with-mag things to do. In the old AHRS code I would scale the mag variances by dividing by the square of the home.Be norm. I haven't implemented that on Revo which is why it's probably not WHOLY inappropriate to set it that low.

The oscillation is something I have seen too and started looking into. What ends up happening, back when I measured it, was that with the mag variance too high compared to other things, you end up getting a lot of non-zero elements building up in the correction gain matrix. Surprisingly it was the vertical position updates that end up bashing the yaw heading around.

Essentially without any movement or mag to ground out the direction, the uncertainty about heading keeps growing (it becomes unobservable) so anything can influence it.
Testing crumple zones

#9 peabody124

peabody124

    Banned

  • Banned
  • PipPipPip
  • 5870 posts
  • LocationHouston, TX
  • Country: flag of United States United States


Posted 25 July 2012 - 03:22 PM

I just pushed james/revo_mag_var which measures the mag variances after norming each sample. That produces values like 1e-5. I brought a fridge magnetic fairly close to the board at 0.01 and it wasn't very strongly affected so I'm thinking that's a safer value.
Testing crumple zones

#10 peabody124

peabody124

    Banned

  • Banned
  • PipPipPip
  • 5870 posts
  • LocationHouston, TX
  • Country: flag of United States United States


Posted 25 July 2012 - 06:23 PM

I pushed james/mag_bias_nulling which runs Bill Premerlani's nulling algorithm. I'm processing logs from a flight now so we'll see how it performs.

Edit: Oh, and D-Lite. Do you mind if I move this into the public forums? If we are going to takl about mag correction techniques we might get useful input from a wider audience.
Testing crumple zones

#11 peabody124

peabody124

    Banned

  • Banned
  • PipPipPip
  • 5870 posts
  • LocationHouston, TX
  • Country: flag of United States United States


Posted 25 July 2012 - 06:58 PM

First result is pretty promising:
Posted Image

Top row is without compensation, bottom is with. You can see the bottom is more spread since it was obvious wandering around the correct value. However, it's centered at zero versus the other which passes through zero.
This was basically spinning around indoors. I have a longer flight outdoors I'm parsing now. However it does have the problem I was concerned about when you don't spin enough. Sitting still it seems to choke a bit (e.g. it was adjusting a lot of points at the beginning and end to be zero. So I'll start looking into some methods that use the magnitude too.
Testing crumple zones

#12 D-Lite

D-Lite

    Core Team

  • Members
  • PipPipPip
  • 1648 posts
  • Country: flag of Germany Germany


Posted 25 July 2012 - 07:00 PM

Edit: Oh, and D-Lite. Do you mind if I move this into the public forums? If we are going to takl about mag correction techniques we might get useful input from a wider audience.


Sure no problem. I'd really like to see the mag being auto-calibrated for exactly the reasons Eric already mentioned.


The oscillation is something I have seen too and started looking into. What ends up happening, back when I measured it, was that with the mag variance too high compared to other things, you end up getting a lot of non-zero elements building up in the correction gain matrix. Surprisingly it was the vertical position updates that end up bashing the yaw heading around.


That's really strange... What I also don't understand why things go well for 20-30 second and suddenly things are freaking out. It's not a slow buildup of oscillation but more like some gain that's suddenly turned on and things go bang. I see same behavior when I'm switching to complementary filter and then back to Indoor - for the first 20 seconds, everythings looks good and then the behavior is exactly like in the graphs above after reboot.

#13 peabody124

peabody124

    Banned

  • Banned
  • PipPipPip
  • 5870 posts
  • LocationHouston, TX
  • Country: flag of United States United States


Posted 25 July 2012 - 07:05 PM

Yeah that was what I saw - but if you look carefully there is a small slow oscillation before hand it just "breaks" out of bounds suddenly. I wouldn't swear to this but my guess would be because the variances can span orders of magnitude and probably only when it hits a threshold does it really blow up like that.

However, since I put the mag variance to something reasonable (for the scale) it does seem to be behaving well for me, except for the aforementioned issues with the mag calibration causing the heading to diverge.
Testing crumple zones

#14 dschin

dschin

    INS Developer

  • Members
  • PipPipPip
  • 363 posts
  • Country: flag of United States United States


Posted 25 July 2012 - 08:31 PM

Yea so the first point about the magnetic variance actually it would be good to have Dale comment on. The mag is actually scaled to unity before being used by the EKF. That means the variance is also interpreted on that scale. This is next on my list of fucking-with-mag things to do. In the old AHRS code I would scale the mag variances by dividing by the square of the home.Be norm. I haven't implemented that on Revo which is why it's probably not WHOLY inappropriate to set it that low.


Yes, from the theory, that is an appropriate scaling of the mag variance assuming the following:
1) the output of the mags are in the same units as home.Be and the mags are actually measuring something close to home.Be in magnitude.
2) everything is as it is supposed to be according to Kalman filter theory :). Noise is white, (no biases, occasional nasty things like a flying near a big metal beam...)

Of course the second assumption is likely to be innaccurate. So raising the variance a couple/three orders of magnitude from what we measure in a calibration step may be appropriate. I wouldn't do this for the gyros and accels. But the mags are sensitive to so many extraneous things.

If we think about it, setting the variance of the normalized mags to 0.01 is like saying the std dev is 0.1 (or ten percent of full scale). That is pretty damn big but maybe appropriate. Setting the variance to 1 is pretty much saying ignore these things completely, they are just noise. 0.001 is like saying the std dev is like 3 percent of full scale, which may be too small. If i were pulling a number out of a hat, which is what I kinda do with the mags, I would probably set it at 0.005 or something like that.

#15 D-Lite

D-Lite

    Core Team

  • Members
  • PipPipPip
  • 1648 posts
  • Country: flag of Germany Germany


Posted 25 July 2012 - 09:34 PM

1) the output of the mags are in the same units as home.Be and the mags are actually measuring something close to home.Be in magnitude.


This seems to be true (despite my concerns about home Be being not very accurate). We measure in milliGauss and the output of the sensor seems also be converted to that. I'm not sure but it looks like we actually scale the mag readings to match home.Be which somehow feels a bit wrong to me. I'd rather like to see mag scale being fixed to 1 as I think we can trust the sensor about it's internal scaling.


2) everything is as it is supposed to be according to Kalman filter theory :). Noise is white, (no biases, occasional nasty things like a flying near a big metal beam...)

Of course the second assumption is likely to be innaccurate.


Pretty sure yes, for all the sensors :-). Vibrations on gyros and accels and all sorts of periodic magnetic fields on the mag. I don't know if there's lot a KF can do to make the sensor readings cleaner but at least it does a good job on fusing them :-)

If we think about it, setting the variance of the normalized mags to 0.01 is like saying the std dev is 0.1 (or ten percent of full scale). That is pretty damn big but maybe appropriate.


So are we currently using normalized variances in the GCS or absolute once? From the units I'd say they are absolute?

#16 dschin

dschin

    INS Developer

  • Members
  • PipPipPip
  • 363 posts
  • Country: flag of United States United States


Posted 25 July 2012 - 09:34 PM

You know, seriously since I left a lot has changed. One big thing is the complimentary filter, which makes sense when you are pretty much hovering and don't have GPS. We should maybe not even have the "indoor" algo anymore. It is susceptible to things like the covariance matrix blowing up on unobservable states. I was thinking of looking at a way to cap the biases on the gyros based on what sensors were available, but maybe the point is that we shouldn't be running the EKF when they aren't observable. We used to keep them in check with the mags and by lying to the EKF saying vel and pos are zero (i.e. the indoor algo), but they weren't actually being estimated correctly. In this case does the complementary filter work just as well? I have no experience with it.

Don't get me wrong, I am not advocating we throw out the EKF. With it: 1) we don't need mags on a fixed wing for yaw, 2) we can add lots of sensors easily (like my SLAM solution), 3) for fixed wing it easily accounts for the centripetal acceleration correctly, 4) for a quad flying radically with good GPS, I am betting it works better than the complimentary filter.

#17 peabody124

peabody124

    Banned

  • Banned
  • PipPipPip
  • 5870 posts
  • LocationHouston, TX
  • Country: flag of United States United States


Posted 25 July 2012 - 09:44 PM

Yeah the CF works really well for when you don't have other sensors. There is also a standalone altitude hold that allows altitude hold in GPS deprived locations using just the barometer. It's nice ot keep the EKF indoor mode for testing purposes though. For example you can illicit this rotation behavior in that mode too when the mag is acting up.

I think for the MPU6000 we can probably get away with a cap on the bias, but it won't do much. Over 40 deg C error you can get a few deg/s rate error. That doesn't cause a problem (in my testing) when the mag var is 0.01.

There's also appropriate switches in the guidance system so it can source information directly from the complimentary filter, GPS-VEL and GPS-POS messages.
Testing crumple zones

#18 dschin

dschin

    INS Developer

  • Members
  • PipPipPip
  • 363 posts
  • Country: flag of United States United States


Posted 25 July 2012 - 10:57 PM

Pretty sure yes, for all the sensors :-). Vibrations on gyros and accels and all sorts of periodic magnetic fields on the mag. I don't know if there's lot a KF can do to make the sensor readings cleaner but at least it does a good job on fusing them :-)

I still believe we should pick the accel and gyro variances from a measurement. I used to spin my motors up to get the vibrations in there when doing that measurement. The mags are a bit more open to some funky behavior in my opinion.

So are we currently using normalized variances in the GCS or absolute once? From the units I'd say they are absolute?

I am really just getting back into the code and hunting around for how things work. I think I am in the wrong branch to check I think. But from what James said above it sounds like the variance in the in the UAVO was being applied directly to the variances on the mags after the mags were normalized. I can tell you that the filter assumes the mags are normalized, unless that changed. It also sounds like James created a new branch that calculates the variances after normalization.

All the calibration stuff has been very confusing for me. I wrote a simple six position cal when I first worked on OP. James actually folded it in and made it work. It found biases and scales on accels and mags. James added the variance calculations. Then we went to a more complicated one that everyone hated last I checked. It sounds like there is a new one again. I REALLY NEED TO DIVE BACK IN.

Long story to say I don't know but will be figuring it out shortly.

#19 peabody124

peabody124

    Banned

  • Banned
  • PipPipPip
  • 5870 posts
  • LocationHouston, TX
  • Country: flag of United States United States


Posted 25 July 2012 - 11:05 PM

So are we currently using normalized variances in the GCS or absolute once? From the units I'd say they are absolute?


Agreed. I'll add back the code which divides the RevoCalibration.mag_var by norm(Home.Be)^2, then we'll probably want the noise at ~50 mGau^2.

All the calibration stuff has been very confusing for me. I wrote a simple six position cal when I first worked on OP. James actually folded it in and made it work. It found biases and scales on accels and mags. James added the variance calculations. Then we went to a more complicated one that everyone hated last I checked. It sounds like there is a new one again. I REALLY NEED TO DIVE BACK IN.


Nope, I reverted back to the 6pt calibration. For accels, we now only do a level calibration instead of 6pt as the scale is really reliable. However, after playing around I think for the mag we might want to simply spin it around, collect a bunch of points in 3D, and sphere it. Online adjustment will probably be required to take it the rest of the way there.
Testing crumple zones

#20 dschin

dschin

    INS Developer

  • Members
  • PipPipPip
  • 363 posts
  • Country: flag of United States United States


Posted 26 July 2012 - 02:34 AM

Agreed. I'll add back the code which divides the RevoCalibration.mag_var by norm(Home.Be)^2, then we'll probably want the noise at ~50 mGau^2.


I sorta liked the normalized version. Then I could just think in percentages :). But then again, the units are useful for checking sanity. I checked D-Lites plot to make sure his mags were sensible. Although 400 mGau seemed a little low for vertical component in Germany (450 maybe) the horizontal was also a little low. I have found in some indoor locations they can be really incorrect and vary in different parts of a room. Lots of structural steel maybe - I'm not an electromag person.

However the units on the inertial sensors, gyros and accels, are important since that ties them into the filter correctly.

Nope, I reverted back to the 6pt calibration. For accels, we now only do a level calibration instead of 6pt as the scale is really reliable.


I'd know that if I would get a system flying again. I had a student get CopterControl flying on my old quad yesterday. But he did it on his own. And I just test flew for him and handed him the sticks. I did say it seemed a little weird. Then when we got back to the lab he said, which mode should I have the stabilization in? I think he had roll in attitude mode, pitch in the "axis lock", and yaw in rate. I don't know what the axis lock does :).

However, after playing around I think for the mag we might want to simply spin it around, collect a bunch of points in 3D, and sphere it. Online adjustment will probably be required to take it the rest of the way there.


Okay, down to business... I like this and it is what I was hoping that 24 pt cal, or whatever it was, would end up being. What's the plan? Could just apply Levenberg (or similar) optimization on the points to minimize Sum{(norm(point)-norm(Home.Be))^2} where each point has a scale and offset for each axis. That would vary nine (edit:six) parameters in the minimization and will converge quickly on the GCS (I guarantee it). That would only require inversion of a nine by nine (edit: six by six) matrix (symmetric and positive definite) at each iteration -- and all the scaling would be pretty uniform keeping condition numbers nice. The trick is to make sure we have a fairly even distribution of points over the six "sides" of the sphere/cube and maybe applying RANSAC or something to throw out outliers if we want good accuracy. I could write the optimization code if needed. Easy-Peasy for a numerical person, which I am not actually. However it needs a good visualization of the sphere on the GCS for sanity checks (not for me - I'm not doing).