UDB behavior during GPS outages

[Phil Giacalone]

Hi guys,

Questions about how the UDB behaves during GPS outages. Does it
continue to calculate position and velocity using inertial data for
dead reckoning until the GPS signal is restored? How long will it
operated this way without GPS? Is this the same for all modes?

Thanks and best regards,
Phil

[William Premerlani]

Hi Phil,

During GPS outages, MatrixPilot continues to calculate position and velocity using inertial data. This is the same in all flight modes.

In fact, MatrixPilot uses inertial data as the primary source for navigation information. GPS is for drift compensation.

So, what happens during GPS outage is that the drift compensation gets turned off.

MatrixPilot will continue to operate on inertial data only for as long as the GPS is out. However, without drift compensation, velocity and position error will grow rather quickly. Velocity error is proportional to time, positional error is proportional to time square.

I have never made any measurements, so I do not know how quickly the error grows, but lets take a numerical example.

Lets suppose that inertial data is off by 2%. That translates to an acceleration error of about 0.2 meters/sec/sec.

So, in 10 seconds, the velocity error could be as large as 2 meters/sec.

The position error would be 1/2*a*t*t, that would come out to be 10 meters.

In 100 seconds, the velocity error could be 20 meters/second, and position 1000 meters.

So, for an order of magnitude, you would not want GPS to be off for more than about 10 seconds....unless we improve the accuracy of the inertial data....I am working on that, I am hoping to get down to 0.5% error. But because the positional error grows with the square of the time the GPS is out, the best that we will be able to do is to ride through a 10 second GPS outage.

Best regards,

Bill

[Coby]

Bill,
Is this drift correction only required for accuracy in navigation?

In other words can UDB support inertial stabilization only without GPS
the way DCM works (for more than 10 seconds)?

E.g. If I wanted to use it to stabilize a trainer or 3D aircraft and
had no intention of trying to navigate a route.

Sorry, still trying to wrap my head around why the GPS is a
requirement on the UDB for stabilization only.

Happy Holidays!
Coby

[Phil Giacalone]

Thanks for that explanation, Bill.

I assume the position/velocity error growth over time is due to sensor
bias in one direction and not due to noise around the true value,
which would bounce around on either side of the true value. Correct?
If I recall correctly, your decision to use high sample rates allowed
for some mathematical filtering of the noise, greatly improving
calculation accuracy.

Are your future improvements to inertial data accuracy going to based
on figuring out the bias in flight so they can be offset/reduced? I'm
wondering if some simple ground calibration tests could also be
performed with the measured offsets put in the options.h file.

Best regards,
Phil

> On Wed, Dec 21, 2011 at 4:31 PM, Phil Giacalone <scienceth...@gmail.com>wrote:
>
>
>
> > Hi guys,
>
> > Questions about how the UDB behaves during GPS outages. Does it
> > continue to calculate position and velocity using inertial data for
> > dead reckoning until the GPS signal is restored? How long will it
> > operated this way without GPS? Is this the same for all modes?
>
> > Thanks and best regards,

> > Phil- Hide quoted text -
>
> - Show quoted text -

[William Premerlani]

Hi Coby,

Stabilization requires airspeed for the centrifugal compensation calculations. This requires either GPS or an airspeed sensor. Also, if you want to have speed control, you need to know speed.

There are a couple of things we could do (but do not do now.) to address GPS-less operation, or loss of GPS.

1. Add an airspeed sensor. If you did that, you could do stabilization and speed control without GPS.

2. Assume an airspeed. Paul Bizard did some simulations that show this will work pretty well, as long as the airspeed is overestimated. If you do this, you could eliminate GPS and still have stabilization, but no speed control.

3. For the case of loss of GPS, we could improve the present situation somewhat by switching to an assumed airspeed for centrifugal compensation when the GPS drops out.

In practice, GPS is pretty reliable, so loss of GPS is really a non-issue. If there are enough satellites in view to get through initialization on the ground, the situation only gets better as the plane gets off the ground and time goes by. It is possible to lose GPS for very short periods of time during steeply banked turns, but in reviewing hundreds of flight logs that come across my desk, I have never seen evidence of sustained GPS dropout.

Regarding GPS-less operation for stabilization only operation, it has been on my list of things to do, but it is not very high priority, because there does not seem to be a very strong interest in it from the community. Also, without GPS, you cannot have return to launch, and that is a very popular feature for any of these sorts of systems.

Best regards,

Bill

[Phil Giacalone]

Yes, RTL is very popular at my house. It's saved my butt numerous
times :-)

The cost of GPS is cheap compared to a lost airplane.

Best regards,
Phil

[William Premerlani]

Hi Phil,

There are two "hard" problems still on my list of things to solve. One of them is relevant to your question. The two problems are:

1. Measuring accelerometer offsets and calibration in flight.

2. Performing centrifugal compensation without assuming angle of attack and side-slip. (Somewhat useful for fixed wing, very useful for quads.)

I have the theory for the solutions to both problems. Now I just have to implement.

The first problem is the major contributor to error in dead-reckoning. (You are correct, noise is not the major problem any more, because of our high sampling rate.) Solving it would provide improved performance across the board, including more accurate dead-reckoning.

Best regards,

Bill

[Phil Giacalone]

Hi Bill,

<<I have the theory for the solutions to both problems. Now I just
have to implement>>

Gotta love it! Solving "hard" problems... Just another routine day at
the office, eh? :-)

Looking forward to those new features.

Best regards and happy holidays,
Phil

On Dec 22, 10:28 am, William Premerlani <wpremerl...@gmail.com> wrote:
> Hi Phil,
>

> There are two "hard" problems still on my list of things to solve. One of
> them is relevant to your question. The two problems are:
>
> 1. Measuring accelerometer offsets and calibration in flight.
> 2. Performing centrifugal compensation without assuming angle of attack and
> side-slip. (Somewhat useful for fixed wing, very useful for quads.)
>
> I have the theory for the solutions to both problems. Now I just have to
> implement.
>
> The first problem is the major contributor to error in dead-reckoning. (You
> are correct, noise is not the major problem any more, because of our high
> sampling rate.) Solving it would provide improved performance across the
> board, including more accurate dead-reckoning.
>
> Best regards,
> Bill
>

> > > - Show quoted text -- Hide quoted text -

[Coby]

Bill,
Sorry for bringing up issues I know you have answered already in this
group in several different flavors. I went back and reviewed your DCM
paper since it's been some time. My math is 20 years out of date, but
can follow the concepts. And my fault for beating around the bush. I
agree with you and Phil - GPS and RTL is a great feature.

Our issue is not wanting to put a GPS on the platform; we do. Our
challenge is we test indoors which makes stabilization the priority.
The UDB does well in systems similar to a hovering foamy - even if you
initialize and launch with the board and aircraft in that
orientation. For now we are just focused on inertial stabilization,
and requiring a GPS lock prior to flight is an issue for us indoors.
Luckily the 406a still gets a lock in some pretty tough places; I have
become a big fan of that GPS.

Anyway, I know it's an edge case and don't want to distract you and
the team from the main work to support the rest of the community.
Just needed to know if we were wasting our time if we wanted to mod
the firmware to let the thing fly in stabilization only mode minus GPS
lock. We'll see what we can figure out on our end and get it back to
the community if it works.

So I guess I am proposing a new mode:

- Inertial stab only (no gps required)
-- UDB will not navigate or control throttle.
-- Pitch, roll, yaw (we have not added a Mag yet but intent to on our
next test)
-- Will need to get rid of the GPS lock aileron waggles since we do
not want that happening in flight. LED status will need to be good
enough.

R,
C

Sorry for hijacking the thread. I'll start a new one once we know a
bit more.