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
So playing around I'm finding that some amount of care towards vibration is definitely key. My crappy HT-FPV frame was definitely a part of the problem. Some more work on the filter and now I'm pretty happy with the result:
Tangentially related, I wrote up how I'm generating the video overlays etc in case anyone is interested http://buildandcrash.blogspot.com/2014/03/logging-and-python-parsin... . Most of it would probably generalize across flight controllers if you can get the data into python.
A lot of improvements are in next, but nothing in the last week. All the stuff with the 16 state INS and these videos I am still testing.
Yeah, found something suboptimal about INS updates. Will fix and post more tests. I'll also make a similar plot/video for the ardupilot altitude complementary filter if you guys would find that useful.
Ok, so integrating raw z accel (no compensation for tilt, but it was fairly level) looks quite good. Also notable, it is not underestimating the velocity so something else is going on.
So for now the latency from the filtering does seem to be what is probably limiting my tuning, more than control structure.
I think everyone would agree getting noise out of the accels would be is useful, and if it starts to not track the frame that is bad. The performance I've seen from Bill's AutoQuad navigation videos and the fact he doesn't use any additional damping indicates it can be done. I think his point about sampling rate is pretty key - I know we run at a minimum of a couple hundred Hz and at least in terms of attitude estimation do not need any damping. I've had pretty fair navigation performance without it too.
We did, interestingly, find it was necessary to apply some LPF to the accels before attitude estimation with the complementary filter. That surprised me since it should behave somewhat like an LPF itself. Going through the math though, it was apparent that if you take gaussian noise (independent on x and z), then a atan2 transform, then filter the output results in a bias in the attitude. However, if you filter and then run atan2 you reduce the bias in the estimated orientation. So it really becomes the interplay of the noise and your estimator if you can handle it well.
My goal is always to try and make our code work in a rigid system if possible (although reasonably balanced frame) because it makes it much easier for people to mount and use. Then if people take more care and add damping and it works even better - great. For what it's worth, almost all of my navigation videos are without any damping and the performance is pretty good.
I had the scaling wrong in that last plot, looks like the INS is underestimating the velocity:
So yeah, time to work on the accels.
There is a difference between dampening and isolation. There is nothing wrong with rigidly attaching a hunk of lead to the IMU. But isolating the IMU from the craft's frame is counter productive. My point is that neither is actually necessary, especially if one takes the time to try to reasonably reduce vibrations at their source.
BTW: What's your definition of a professional AP? And, why do you think they would they know best?
A thin piece of gel pad under a relatively light flight controller causes negligible lag.
Its job is to mitigate high frequency low amplitude vibrations which it does very well, but its density is such that it moves very little under normal flying maneuvers.
Short of full stop acrobatics, it's "lag" is not meaningful at all, but its capability for mitigating high frequency low amplitude vibration is excellent, please look at actual use comparisons on wiki page referenced above.
On multicopters, accels are of severely limited use without sufficient vibration damping.
Virtually every professional AP system uses some sort of dampening of the accelerometers.
No, I use only hard mount. Vibration insulation will tend to create another rotational body somewhat independent of the frame. I've found that ACC noise does not really hurt the integration if your timstep is short enough. What does hurt is a shifting bias caused by VRE. You will see a shift in ACC bias between when the craft is static on the ground vs vibrating in the air during flight. How much will depend on the sensors and the amplitude and frequency of the vibration.
Adding another large set of parameter to try to estimate in real time will probably not work out very well. There will be too many more parameters than there are observations to drive it. Pre-estimating variances on the ground will likely be your best bet.
You may need to add noise terms to the process update step of your Kalman filter to add some cross variance isolation and account for measurement time differences like the lag of the realized baro reading vs the ACC data. In my filters, I do include these terms as additional states to be estimated with the rest of the system, but their initial state is again, pre-calculated.
-
1
-
2
of 2 Next