Replies to This Discussion

Permalink Reply by Tom Yochum on October 5, 2010 at 3:56pm

Well, that's the theory. If you can pull off the implementation, you should get accuracy better than 1 meter.

I personally think the best way to sub-meter precision is to do tightly-coupled GPS/INS.

• ▶ Reply

Permalink Reply by William Premerlani on October 12, 2010 at 6:23pm

Hi Tom,

When you say "tightly-coupled GPS/INS", I assume you mean there is a single CPU that is running an single, integrated algorithm that freely uses radio, gyro, and accelerometer information? If so, I agree that you could get sub-meter resolution, possibly even sub-meter accuracy.

We recently implemented a loosely-coupled GPS/INS algorithm in MatrixPilot. It achieves centimeter resolution and high bandwidth, but the accuracy is still only what the underlying GPS provides. Here is how it works:

1. Gyros, accelerometers, GPS, and optional magnetometer are used to compute the 9 elements of the direction cosine matrix (DCM) to determine attitude.

2. Accelerometer information is transformed from body frame to earth frame with the DCM.

3. Earth frame acceleration is integrated twice to provide a high resolution, high bandwidth, velocity and position estimate.

4. The acceleration based velocity and position estimate is filtered with a replica of the GPS dynamic model.

5. The difference between the GPS and replica velocity and position is used to provide drift compensation for the acceleration integrators.

The implementation has been imbedded in MatrixPilot for several months now, there is plenty of flying experience. What we have achieved is the following for position and velocity estimates:

1. Centimeter resolution.
2. Full PWM bandwidth.
3. Compensation for GPS dynamics.
4. Capability of continued navigation during brief GPS outages, such as during turns.

However, the accuracy is still the underlying GPS accuracy. Basically, unless there is "tight-coupling", there is no way around this. In order to improve things any further, in my opinion, the INS information will have to be fed back into the GPS calculations.

By the way, one of the discoveries that we made along the way, when Peter Hollands landed his plane in a tree, is that the dynamics of the uBlox and the EM406 are comparable. During the flight in question, the uBlox reported the plane was flying for 2 seconds after it stopped in the tree. The recorded response suggests that the dynamics of the uBlox approximates a 2 second moving average.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Mike L. on October 12, 2010 at 6:30pm

Hi Bill,

That sounds like a really cool algorithm! What kind of processor / uC are you using to run that? Are you using an EKF for data fusion? May I have a peek at you're awesome work. :-)

• ▶ Reply

Permalink Reply by William Premerlani on October 12, 2010 at 6:51pm

Hi Mike,

The algorithm, attached, is running on a dsPIC30F4011. Actually, it is rather simple. I am not using an EKF for data fusion, but that would probably be a good idea, and would improve performance a bit. What I am using seems to work well enough. It is a simple negative feedback scheme. Each time new GPS information comes in, the GPS replica data is subtracted from it to form an error signal. The velocity error provides negative feedback for the integrator that accumulates acceleration into velocity. The position error provides negative feedback for the integrator that accumulates velocity into position.

Best regards,
Bill

Attachments:

• deadReckoning.c, 6 KB

• ▶ Reply

Permalink Reply by Mike L. on October 12, 2010 at 7:07pm

Hi BIll,

Thanks, It looks nice I'll have to give it a try one of these days. What measurement rate were you running the u-blox to get the 2 second drift? not sure if 1Hz or 5Hz would make a difference. Also, what are you using for your Clock? Unless you're using a crystal or the PPS from the GPS receiver, could it be likely that the 2 second drift could be from the micro-controller?

Thanks,

Mike

• ▶ Reply

Permalink Reply by William Premerlani on October 15, 2010 at 6:27pm

Mike,

The filter delay of GPS receivers is real. See Brian Wolfe's comment, below.

Our board (UAV DevBoard) uses a crystal clock, though the measurement we made does not require much in the way of clock accuracy.

Basically, here is what happened during a series of tests that I ran:

1. All flight data, including acceleration, and everything you could possibly imagine, was being snapshot 4 times per second.

2. I hand launched, plane level, high over my head, with motor off, with controls set to keep the plane level.

3. Let the plane land on its own.

repeat.

I made about 20 flights and analyzed them afterward.

The accelerometers clearly marked the time at which the plane was launched. Acceleration was less than 1/4 second.

Then, it took about 2 seconds for the GPS reports to ramp up to actual speed over ground.

For the duration of the flight, speed over ground was approximately constant.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Simon Wood on October 18, 2010 at 8:47am

Are you configuring the dynamic mode of the Ublox? This can be done in U-Center.
Simon

• ▶ Reply

Permalink Reply by Tom Yochum on October 13, 2010 at 8:43am

Bill,

You sure do push the state-of-the-art for open-source autopilots, don't you? :)

I would call your design "loosely-coupled", but there aren't any hard and fast rules on what constitutes loose vs. tight. What rate do you sample your gyros? I found that the gyro integration (coning errors) drives the accuracy of the position/velocity solution.

I have some tightly-coupled code running in Matlab, but not on a microprocessor (yet). I used two pieces of code: an INS and a Kalman. The INS does a pure-inertial position/velocity/attitude solution that feeds into the Kalman. The Kalman uses an inertial error propogation model to track the errors in the INS, and the GPS data is the measurement used to correct the error model. I am calculating the bias and scale factor errors in all 6 inertial sensors, and I feed that back into the INS. In simulation I get 95% position errors of 1-1.5 meters, and attitude errors on the order of 0.5 degrees. Real-world performance remains to be seen.

This method is pretty processor-intensive, so we are looking at an ARM7 to start with. We have a CHR-6d that we would like to try to run this code on. That would make for one tiny GPS/INS board! I'm not sure if we can pull it off.

Tom

• ▶ Reply

Permalink Reply by William Premerlani on October 14, 2010 at 2:28pm

Hi Tom,

Gyros and accelerometers are sampled 40 times/second, and velocity and position vectors are computed at that rate. A key to getting it to work right for the method that I am using is to account for the GPS dynamics.

Real world performance is pretty good. The high bandwidth altitude estimates produce very smooth landings.

Computational loading is miniscule.

Your method sounds like it will be very accurate.

In the real world, I think the biggest "spoiler" of X and Y accuracy is going to be error in the yaw estimate will introduce error into the calculations. I think it will be difficult, in the real world, to achieve 0.5 degrees yaw accuracy. I think you will be lucky if you get 2 degree yaw accuracy, especially under windy conditions. It will help if you are using a magnetometer.

Best regards,
Bill

• ▶ Reply

Permalink Reply by Tom Yochum on October 14, 2010 at 2:43pm

Bill,

I would love to hear more about how you account for the GPS dynamics.

You are correct about the yaw accuracy; the 0.5 degrees was only for roll and pitch. The yaw accuracy (in simulation) has been within 2-3 degrees most of the time (without a magnometer). As I am sure you are aware, there is very poor coupling between the yaw state and everything else. I get the best estimates when the aircraft is undergoing lots of manouvering. I have the same issue with the altitude state, but so long as GPS altitude is available it remains stable. Once we start putting this to hardware I plan on adding barometric altitude as well. I need something to keep the altitude stable if GPS is lost.

Tom

• ▶ Reply

Permalink Reply by William Premerlani on October 15, 2010 at 6:15pm

Hi Tom,

Regarding accounting for GPS dynamics in dead-reckoning, here is the approach, based on an idea that Paul Bizard had:

1. You make your best estimate of the true velocity and position, using accelerometers.

2. You feed the true velocity and position into a model of the GPS dynamics. Call this the true filtered velocity and position.

3. The true filtered values should match what actually comes out of the real GPS. Use the difference to perform drift adjustment for the dead reckoning computations.

The trick is building a dynamic model of the GPS. I am using a simple first order filter to approximate either the uBlox or the EM406. According to Brian Wolfe, this might not be accurate under all conditions for the uBlox.

Most of the testing I have done is with an EM406, and have gotten good results during autonomous landings, which I consider to be the "acid test".

Best regards,
Bill

• ▶ Reply

Permalink Reply by Brian Wolfe on October 14, 2010 at 9:34pm

Hey Bill,
I haven't had a chance to poke through your code yet. I was wondering if your using the bias corrected accelerometer data back in the attitude correction loop. The reason I ask is when I tried to do that I got some undesirable coupling between the attitude loop and the pos/vel loop. I finally had to separate the two by not using the bias corrected accelerometer data back in the attitude loop.
On the 2 second moving average, I noticed a similar thing in some testing I was doing and was told by someone from uBlox that the KF running in the GPS receiver was dynamic in that the filtering and hence delay was increased in the presence of acceleration and high signal noise. The variation could range from .4 sec to 3 sec depending on the circumstances. It's hard to compensate for when it can vary so widely.
Great work as always,
Brian

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• …
• 7
• Next ›
• Page