I've been thinking a lot lately about how cool it would be to implement inertial dead reckoning on ArduCopter for a gps-free loiter mode of sorts. I just wanted to get some discussion going from people who have studied this or have tried implementing it, as I know it is difficult.
To begin with, this is a good read about getting position from accelerometer data: http://perso-etis.ensea.fr/~pierandr/cours/M1_SIC/AN3397.pdf
So my thoughts are that we could integrate the acceleration reading from the accel, subtracting out the acceleration due to tilt angle (we can do this since we have a nice filtered angle reference, or gyro integration). This, once filtered nicely, should give us a pretty good reading of lateral velocity. Once that was accomplished, we do one more integration, and obtain lateral position. Since all we really need for position hold is a relative position, we could experiement with resetting the position integration at some time interval (or every time the sticks are released) to keep our drift error down. How cool would this be if it actually worked?!!
I am thinking to buy an ArduIMU v3 just to play around with this to see if I can get a robust measurement.
Please chime in on this! If this worked even remotely well, there may no longer be a need for optical flow, or even sonar (as we could get relative Z position too)!
-Jamie
Comments
That's looking really good Randy. I wonder if the climb rate noise on the second graph is due to the aerodynamic effects that Bill brought up? Or is that just random walk? (ie: would do it sitting on a desk).
As for the fall at the end, it does appear that the system can see the problem, so that's hopeful. Just have to figure out why.
Bill,
Thanks for the feedback. I've been working closely with Jonathan Challinger and we've made some further improvements to the results by using raw baro readings instead of filtered which reduces the lag from 400ms -> 150ms. Also there was a typo in the complementary filter.
The results from above are both real flights of a small quad indoors. The first one is a manual flight where I flew the quad up to about 1m..then repeatedly used manual throttle to make it climb to about 3m. You can see now that the accel alt (green) tracks the baro alt very nicely and in fact, it's slightly ahead of the baro.
The 2nd flight is alt hold using the accel altitude as it's input. It worked for the most part pretty well except after returning to level after I flew it at a steep angle for a while. So I would roll it left to about 25 degrees and it would maintain altitude nicely until I leveled it out at which point it would drop 1m..then recover within a few seconds. The recovery is caused by the baro reading I'm sure which is generally pretty accurate although it wanders around a bit.
It's a total mystery as to why it would always drop like that. Maybe it's this "problem of inflight acceleration contaminating the roll-pitch reference vector" although I think in arducopter our attitude solution is heavily weighted towards the gyros so it's not much of an issue.
When we do the correction of the accerometer values using the baro (i.e. we nudge the accel offsets in the direction that would correct the discrepancy with the baro) we actually rotate the correction back into the body frame so it should be applied to the x,y or z axis correctly...but maybe i need to check that more.
thanks again for thinking this through with me. I'll read the rest of the pdf when my mind is a little more fresh tomorrow.
Hi R_Lefebvre,
The effect that you describe (dropping after return to level after lateral translation) could possibly be an aerodynamic effect: while the quad is translating, its propellers encounter mostly air that is not moving vertically, so the propellers develop more thrust than in a hover. Once it stops, it is then sitting in its own downwash, which might cause it to drop until the control compensates by boosting the speed of the propellers back up to what is needed in a hover.
One thing to look at is the altitude that the barometer indicates. I assume that the 1 meter drop is apparent visually, and is real. In that case, if it is a problem with the barometer, the barometer would show either that the quad did not drop, or that it rose slightly. In which case the issue is a measurement problem. However, if the barometer shows that the quad did drop, then it is a control issue having to do with the transition to a hover.
Best regards,
Bill
Yes, we have a problem when moving as well, which could be the explanation for Randy's latest testing. He and Jonathon Challinger have been working on this together and made improvements. Then his latest test showed this, I'll paste it here since he's sleeping now:
Hi R_Lefebvre,
Another factor at play is lateral motion. When the quad is hovering, it is sitting in a flow field that is more-or-less centered on the quad with some nice symmetry properties. However, during rapid lateral motion, the symmetry is broken, and the flow field takes on an entirely different shape.
So, the barometer is a mixed blessing.
I think one possible solution would be some sort of approach that takes advantage of the characteristics of the accelerometers, the GPS, and the barometer in terms of frequency response.
I would think that the accelerometers would be the most accurate way to measure position and velocity changes at high frequencies, that GPS would be good at reporting changes at moderate frequencies, and barometer would be best at reporting long term drift.
Best regards,
Bill
Bill, on your point #1, I had been thinking about that myself. The problem is even worse because you could have a feedback loop, I would think? The quad loses altitude, so the Alt_Hold controller throttles up. When throttle increases, the pressure at the top of the quad (where most IMU are mounted) decreases, making the baro report higher altitude, so the Alt_Hold controller would then throttle down. I would think if the alt_hold gains are high enough, it could cause a really bad oscillation? Really, just a pulsing.
Trad Helis have the opposite problem since the baro is normally under the rotor disk, so pressure goes up when when you raise collective pitch.
It's almost like the baro needs to have a standpipe to raise the sample point out of the affected air space. Easier on a quad, almost impossible on a heli.
Hi Randy,
A couple more things for you to think about.
1. You note that dead reckoning tracked baro pretty well in a ground test, but not so much during flight. One possible factor at play is that the baro is not so accurate in flight, mounted on a quad. The quad sets up a flow field with significant pressure variations. For example, just above the quad the pressure is lowered, and just below it, it is raised. Even in the center of the quad, there can be a pressure disturbance, such as when the quad is moving laterally, and even when there is no airflow over the barometer. So, if baro and dead reckoning disagree in flight, it is difficult to say which one is correct.
2. I assume that you are using velocity in your drift compensation. If you are using a MediaTek GPS, it is my understanding that it does not furnish vertical velocity, so you have to take the first derivative of either the GPS or barometer altitude. Taking the derivative of either of them introduces noise. I think it would be better to have a vertical velocity signal directly from a GPS. A GPS velocity signal is generally computed by the GPS from doppler shift, so it is more accurate than the derivative of the position. So, you might want to try either an EM406A or a uBlox instead of the MediaTek.
Best regards,
Bill
Hi Randy,
I like the least squares method you are using to compute accelerometer gains and offsets and the third order complementary filter for removing residual drift. Great ideas.
That still leaves the problem of inflight acceleration contaminating the roll-pitch reference vector, which will ultimately will corrupt transformation of acceleration from body to earth frame. I have been working with Tridge and Jonathan Challinger on a solution for that. The last time I talked to Jonathan, he was using a variation of the new method I developed for accounting for acceleration in roll-pitch drift correction. We did make some improvements to the original idea. A relatively new version is described here. However, we made a few improvements since then, you should check with Jonathan for details.
Best regards,
Bill
Not only would this be cool for Quads and planes, but it would be awesome for applications like submarines which have no clear line of site to the sky. In fact I was thinking about this over the weekend. A few years ago I built an ROV submarine with cameras etc. It was good, but I always wanted to have intertial navigation on it so it could get a GPS locale at the surface then navigate underwater inertially I'd love to see this idea get up and progress.
Incidentally this is exactly how aircraft used to precision navigate before GPS. On the gate's at each airport the lat and long for the actual gate (down to the second) was noted on a placard. The flight engineer or second officer would key this location into the flight computer before departure after the gyro's had spun up. A friend of mine was a flight engineer on a 727 for years and he said this method was EXTREMELY accurate, being no more than a few metres off when they flew from one side of Australia to the other.
I think this method, even with a 1m drift over a minute would be awesome. Just think of all the threads on position hold issues. The gyros could give super accurate information regarding a short-term trend in position hold, supplementing the gps. Additionally, even without GPS the drift correction could be used in stabilize mode to aid in an unbalanced quad.
-
1
-
2
-
3
of 3 Next