Comment by Roy Brewer on May 6, 2012 at 10:37am

Bill,

Great work, as always. I have some suggestions for improving the efficiency of the calculation:

- Work in the body axes - that is, transform the GPS velocity into the body axes, instead of transforming the accelerometer reading into earth-axes. This saves one transform (the one in eq 6 of the paper).

- Subtract the GPS velocity from the sensed accelerometer value. This gives the sensed gravity vector (ignoring noise, sensor imperfections, etc.). Then take the cross product of this with the estimated gravity vector - i.e. the bottom row of DCM. This calculation could then be used as the error vector, eliminating the concerns of quadratic data in eq 4 and the need to "normalize" in eq 5.

Yes, the calculations technically would be done in the body axes instead of the earth axes, but mathematically this approach is equivalent.

Also, I think the same technique could be performed using (3-D) optical flow sensors (with suitable care to account for coordinate system misalignment).

- Roy

Comment by William Premerlani on May 6, 2012 at 4:42pm

Hi Roy,

Its great to hear from you, as always. I am glad that you are interested in this topic, and have given it some thought...

Regarding doing the computations in the earth frame versus doing them in the body frame...

Because the gyro/accelerometer update rate is much greater than the GPS reporting rate, there is a distinct improvement in accuracy by doing the calculations in the earth frame. That is because, in the earth frame, the integral of the rotation matrix times the accelerometer readings are compared with changes in velocity.

However, in the body frame, we need the integral of the transpose of the rotation rate times the instantaneous acceleration. Except the GPS does not report instantaneous acceleration, it reports change in velocity over finite time periods. We might be tempted to use the average acceleration computed from GPS change in velocity, but in the body frame, that leads to an approximation that dilutes the accuracy of the calculation.

So, it is much better to do the computations in the earth frame.

I revised my report to include an appendix with some math that shows the computations can be done exactly in earth frame, but only approximately in the body frame. So, if you would like to study the math, read the appendix in this revised report.

Best regards,

Bill

Comment by dusl on August 28, 2012 at 12:18am

good

Comment by Dave Whittington on September 27, 2012 at 10:36am

Bill,

   Thanks so much for your expertise and help to us APM folks with probably the most sophisticated DIY autopilot code - especially in the area of attitude computation with wind. One question I have is whether GPS signal blackouts for a "short" time will confuse this new attitude code.

   Thanks again

Dave

Comment by William Premerlani on September 28, 2012 at 5:56pm

Hi Dave,

With this new acceleration compensation code, you do need to use an alternate approach during GPS blackouts.

For fixed wing, aircraft, my recommendation is to use the older method for acceleration compensation using the last known value of air speed if there is no air speed sensor, or the actual air speed if there is a sensor.

For multicopters, there are a couple of approaches you could use, perhaps Tridge or Jonathan might comment if they read this, they have implemented this technique. There are several things you could do during GPS blackouts:

1. You could turn off the roll-pitch feedback loop during the blackout. This would work if the blackout period is short.

2. You could extend the "delta time" in the computation to include the blackout, continue to perform the integral of the accelerometer measurements, and complete the computation when the next GPS velocity measurement becomes available. This would work if the blackout period is not too long.

3. You could leave the acceleration compensation out of the computations. (This is equivalent to the previous approach used by ArduCopter.) For implementation, you simply set the GPS change in velocity used in the computations to zero.

Best regards,

BIll

Comment by Dave Whittington on September 29, 2012 at 5:39pm

Bill,

    Thanks for your response. During the GPS blackout, is it primarily just the wind estimation that will suffer or will it feed into the general attitude signals as well?

    On another subject, is there a way to estimate angle of attack and sideslip angle from the data coming from the APM 2.5 code?

Your expertise is much appreciated!!

 

Dave

Comment by William Premerlani on September 29, 2012 at 6:26pm

Hi Dave,

First, a disclaimer: I am not familiar with the APM code, so the final word should come from the Ardu team. The following is based on how MatrixPilot operates:

One of the effects of GPS blackout will depend on whether or not you have a magnetometer. Without a magnetometer, an extended GPS blackout will impact yaw attitude estimation.

Regarding angle of attack and sideslip angle, I think in order to get any sort of accuracy, you would need a dynamic model of your aircraft. Then you could estimate sideslip and angle of attack from airspeed, acceleration, and rotation rate.

Otherwise it would be difficult to make accurate estimates, because of the wind. The wind estimation algorithm assumes zero angle of attack and zero side slip.

Best regards,

Bill

Developer Comment by leonardthall on January 19, 2013 at 7:05pm

So to summarize what you have said here Bill,

1. GPS black out will result in similar performance to what we have already for a copter.

2. Magnetometer is used to correct the yaw during blackout but is supplemented when we have GPS.

Three questions:

How will Magnetometer errors impact this algorithm?

How this algorithm handle GPS errors for a copter in hover?

Can anything here be used to improve or supplement the inertial navigation we are working on? (improved yaw measurement for example)

Thanks for your work Bill! And nice to finally meet you!

Leonard

Comment by William Premerlani on January 20, 2013 at 9:41am

Hi Leonard,

Nice to meet you, too.

I have not thought about this algorithm for a while. I think that the ArduCopter team, including Tridge, Randy, and Jonathan Challinger, are carrying this work forward. If they notice this they might comment, if not you might want to contact them. They would be in the best position to answer your questions. I think that they have this algorithm working, and they have made some improvements, including incorporating barometer information. Also, I think they have done some work in the areas relating to your questions. For example, I think they have done some work to compensate for magnetometer errors, as well as for handling loss of GPS.  They have developed a dead-reckoning algorithm that will work fairly well during loss of GPS, although I think it works only for fixed wing, but not multicopters.

Best regards,

Bill

Comment

• ‹ Previous
• 1
• 2
• Next ›
• Page