So for the last week or two I have been looking a bit at the performance of the Tau Labs altitude control and INS filter we have and the altitude control loop.
One issue I was suffering from is that the velocity estimate would be biased because of variations in the accelerometer bias. I switched to using a 16 state version of the INS written by Dale Schinstock that included an estimate of the bias terms for hte accels which improved things somewhat.
I'm still not happy with the performance It is a dual loop control - the position error sets a velocity desired which then runs through a PI controller.
So the first question I had was whether there was a problem in the estimation or in the control system. I grabbed some logs with my Freedom board and then also did some video processing. I swept a number of settings for hte baro variance and definitely if I assign to much noise to the barometer, then it doesn't track well enough. However, with the typical settings I use then it does a pretty good job of estimating the altitude. I made a video showing it with two values of the variance:
The plot on the right in some segments shows the segmented quad location from the video stream (i.e. ground truth)
One thing that struck me. When I tune it up to get a good estimate of position, that increases the noise in the velocity estimate. I feel like this ends up limiting my tuning parameters. I've also implemented the ardupilot complementary filter, (keep meaning to grab a video log of that too) and cannot tune it to the point I'm happy.
Anyway, the solution I'm considering is to apply some low pass filtering to the velocity estimate in the controller. Essentially the velocity control component is like a derivative of the position estimate, and this seems like a reasonable / sensible technique. However, I'd love to hear any comments from others here.
Discussion at new Tau Labs forum: http://forum.taulabs.org/viewtopic.php?f=17&t=27&start=20
Comments
Hi James,
I think the reason you can't trust your accels is the rigid mounting of the flight controller.
Interestingly, you also see some vibration effect on the baro as well.
As a general solution a small square of Kyosho Zeal at each corner of the flight controller will reign in vibrations satisfactorily for most airframes and applications.
If you are uncomfortable with the zeal's adhesive for retention by itself either a rubber band or a loose velcro tie can be used.
There are other vibration damping / isolation products, but so far none have yielded as consistent results (for flight controllers) as Kyosho Zeal.
I definitely recommend you revisit the vibration isolation thing as otherwise you will be chasing a lot of vibration related phenomena instead of the underlying issues you are looking for.
It is also a good idea to provide a "strain relief loop" in all wiring connected to the flight control board as well to minimize vibration transferred through the wire bundle.
This wiki page might help: http://copter.ardupilot.com/wiki/vibration-damping/
Best Regards,
Gary
@Bill Nesbitt: thanks. I've had less success than you I think in terms of trusting the accel, but given the performance I've seen in your videos, it is probably time to revisit that and see why. Do you apply much or any vibration damping? I tend to rigidly mount my flight controllers.
So I rescaled the video output to match fairly well with the INS output. In terms of position, they are doing quite well. However, the velocity shows the noise I described in the previous video. Interestingly, you can really see the latency in the velocity estimate versus the ground truth - probably as a result of the fact it is being driven by the baro instead of the accelerometer.
Now in the first clip, where the baro variance was lower, which should make it trust the accel more and approximate integration, the position itself was not tracking well - and specifically looked like it was lower amplitude than the real movement. I need to make 100% sure there isn't some scaling issue (e.g. incorrect dt) happening that makes accels not drive enough change in velocity.
Time to do what you suggest: drag out my code for rerunning the sensor data through the filter on the PC and optimize some parameters. Do you have a good recommendation for formal ways to do that. I've seen two approaches: optimization procedure on the params themselves to maximize the likelihood of the observed data, and including the params as augmented state variables and running the EKF that way. It isn't something I've found good literature on.
@Crashpilot1000: nice, you actually rediscovered the median filter, and it is really good for exactly what you described: throwing outliers out.
In my video, that lower left plot you can see a faint white line, especially in the first section. That is the raw baro data median filtered with a window of 21 samples. It ends up introducing the amount of lag as the window size. One problem with implementing that on a flight controller is that sort is actually a relatively expensive operation (in computer science it is typically one of the prototype algorithms to study the O() of various algorithms), and to run it on a time series you need to perform a sort for each new sample. It's probably still doable. The real question becomes if you have a lot of outliers when you have the raw data at the full sampling rate. From my brief glances, it looks like the data is fairly gaussian, at which point some cheaper filters can get a long way. In this case, in principle the INS is trying to do the same thing - which is the yellow curve in the lower left plot. Compare how well it tracks the white (median filter) line in the first video clip versus second and you will see it starts to do better.
With the optical ground truth data, you have enough information to replay the flight in a ground simulation and compare and score the results against reality. This could be used to create an iterative goal seeking function aimed at driving the error towards zero by manipulating all filter process and measurement variances. In the end you will find that you can trust the ACC data to a very high degree if they are being biased correctly by the filter. Integration will then provide very smooth velocity estimates.
Hi! To get better rawdata you can use a spikefilter on raw baro data. It adds no to minimal lag but gets rid of those nasty barospikes a great deal and can therfor minimize further filtering needs. I once proposed it here: http://diydrones.com/forum/topics/perhaps-useful-spikefilter?page=1 . I still use it in my althold code (and some part of GPS) and I think it's practically useful. Just saying.
-
1
-
2
of 2 Next