bayesclasses-general

[Bayes++] Square-root UKF

[Matt H. <mwh...@gm...>]

Is there any support for Square-root (cholesky decomposition, etc)
formulations of the Unscented Kalman filter in Bayes++? I'm working on a
GPS/INS system purposed for real-time control of a helicopter UAV; any
computational cost reduction on the estimation end could directly lead to a
performance gain in the controller.

Also, what is the best way to organize the state and measurement vectors? I
hope to use the UKF to estimate the bias and scale-factor errors present in
the signals from 3-axis rate gyros, 3-axis accelerometers, 3-axis
magnetometers, GPS, and barometric altitude/airspeed sensors. Of course,
only the sensor measurements are directly observable (the bias/sf errors
can't be measured) - any suggestions on the best way to represent this in
the observation implementation?

Right now I'm just working on getting the correct predict/observe cycle. I'm
using an Addative_predict_model and an Uncorrelated_addative_observe_model.
Are there underlying assumptions for these models that make them less
suitable than the base model (Unscented_scheme::observe, for instance?)

Thanks for your advice,

Matt Hazard
NCSU Aerial Robotics Club
http://art1.mae.ncsu.edu
North Carolina State University

Re: [Bayes++] Square-root UKF

[Michael S. <ma...@mi...>]

Hello Matt,

On Wednesday 10 January 2007 00:14, Matt Hazard wrote:
> Is there any support for Square-root (cholesky decomposition, etc)
> formulations of the Unscented Kalman filter in Bayes++?

Sorry there are no Square-root Unscented implementations in Bayes++. The only 
unscented filter implemented is that described in the original Unscented 
paper. Simon (Julier) has

> I'm working on a 
> GPS/INS system purposed for real-time control of a helicopter UAV; any
> computational cost reduction on the estimation end could directly lead to a
> performance gain in the controller.

OK I have a lot of experience in the GPS/INS fusion field so maybe I can help 
here. I would be interested in what sensors you are using.


> Also, what is the best way to organize the state and measurement vectors? I
> hope to use the UKF to estimate the bias and scale-factor errors present in
> the signals from 3-axis rate gyros, 3-axis accelerometers, 3-axis
> magnetometers, GPS, and barometric altitude/airspeed sensors. Of course,
> only the sensor measurements are directly observable (the bias/sf errors
> can't be measured) - any suggestions on the best way to represent this in
> the observation implementation?

It is probably a bad idea to try and estimate bias and scale-factor error in 
the inertial sensors on-line. Most affordable strapdown sensors tend to have 
a variety of horrible non-linear and dynamic effects (hysteresis etc) which 
prevent the estimation of their values while in motion.
You can do a lot with off-line calibration and you will probably need to do 
this anyway to get some idea of the sensor noise. Alan variance analysis of 
the sensor noise can be quite helpful to get an idea of how well they will 
perform without correction.

I would start with 9 variables in your  systems state vector: position, 
velocity and attitude in 3 dimensions.In this case observations of the 
inertial rates and accelerations (after calibration) are control inputs into 
the filter prediction and not observations.

For efficiency (high rate inertial data, 100Hz for example) an indirect filter 
architecture is normally used. In this case the navigation state is 
intergrated directly from the inertial observation and the filter only 
estimates error corrections. A further advantage of an indirect filter 
architecture is that you can represent attitude in a redundant form, either 
as a direction cosine matrix or using quaternions. This avoids the nasty 
problems associated with Euler angles.

With regard to GPS observations you will need to choose and appropriate 
coordinate frame. If you are going to be moving in a limited area (with 
differential GPS for example) then you can represent position using simple 
Local Tangent Plane coordinates such as North, East, Down. Your GPS receiver 
can either report them directly or you can use a universal transverse 
Mercator projection to convert from lat,long. In this form the GPS 
observation model is simple. Your GPS may also give observations of velocity 
which can be used in the filter if the GPS unit has not already used them to 
estimate position.

A good reference to all this is "Global Positioning Systems, Inertial 
Navigation, and Integration" ISBN 0-471-35032-X

> Right now I'm just working on getting the correct predict/observe cycle.
> I'm using an Addative_predict_model and an
> Uncorrelated_addative_observe_model. Are there underlying assumptions for
> these models that make them less suitable than the base model
> (Unscented_scheme::observe, for instance?)

I am a bit confused by you "base model". 'Unscented_scheme::observe' is a 
member function of Unscented_scheme.
Specifying the model as 'Uncorrelated_addative_observe_model' is fine for the 
Unscented_scheme however.

Michael
-- 
___________________________________
Michael Stevens Systems Engineering

34128 Kassel, Germany
Phone/Fax: +49 561 5218038

Navigation Systems, Estimation  and
                 Bayesian Filtering
    http://bayesclasses.sf.net
___________________________________

Re: [Bayes++] Square-root UKF

[Matt H. <mwh...@gm...>]

One more idea.

Would a full dynamic model of the airframe be necessary in an indirect
formulation? It seems like you'd only be correcting the inertial navigation
solution with the aiding sensors - only requiring an error model.

A tightly-coupled filter with a nonlinear dynamics model of the airframe
could use the control surface deflections as inputs in the predict_model,
and the inertial and aiding sensors as measurements in the observe_model,
correct? It's a more complicated system, but wouldn't the specification of
the system dynamics model improve the results?

Matt Hazard
mwh...@nc...


On 1/11/07, Matt Hazard <mwh...@gm...> wrote:
>
> On 1/11/07, Michael Stevens <ma...@mi...> wrote:
> >
> > Hello Matt,
> >
> > On Wednesday 10 January 2007 00:14, Matt Hazard wrote:
> > > Is there any support for Square-root (cholesky decomposition, etc)
> > > formulations of the Unscented Kalman filter in Bayes++?
> >
> > Sorry there are no Square-root Unscented implementations in Bayes++. The
> > only
> > unscented filter implemented is that described in the original Unscented
> > paper. Simon (Julier) has
> >
> > > I'm working on a
> > > GPS/INS system purposed for real-time control of a helicopter UAV; any
> > > computational cost reduction on the estimation end could directly lead
> > to a
> > > performance gain in the controller.
> >
> > OK I have a lot of experience in the GPS/INS fusion field so maybe I can
> > help
> > here. I would be interested in what sensors you are using.
>
>
> Our sensor board prototype uses Analog Devices' gyros (ADXRS300) and
> accelerometers (ADXL330, I think). The magnetometer is a PNI MicroMag3. We
> also have a complete (working) Crista IMU, which uses basically the same
> gyros/accelerometers, but lacks the magnetometers. At any rate we should see
> comparable results between the two sensor packages.
>
> > Also, what is the best way to organize the state and measurement
> > vectors? I
> > > hope to use the UKF to estimate the bias and scale-factor errors
> > present in
> > > the signals from 3-axis rate gyros, 3-axis accelerometers, 3-axis
> > > magnetometers, GPS, and barometric altitude/airspeed sensors. Of
> > course,
> > > only the sensor measurements are directly observable (the bias/sf
> > errors
> > > can't be measured) - any suggestions on the best way to represent this
> > in
> > > the observation implementation?
> >
> > It is probably a bad idea to try and estimate bias and scale-factor
> > error in
> > the inertial sensors on-line. Most affordable strapdown sensors tend to
> > have
> > a variety of horrible non-linear and dynamic effects (hysteresis etc)
> > which
> > prevent the estimation of their values while in motion.
> > You can do a lot with off-line calibration and you will probably need to
> > do
> > this anyway to get some idea of the sensor noise. Alan variance analysis
> > of
> > the sensor noise can be quite helpful to get an idea of how well they
> > will
> > perform without correction.
>
>
> OK.
>
>
> I would start with 9 variables in your  systems state vector: position,
> > velocity and attitude in 3 dimensions.In this case observations of the
> > inertial rates and accelerations (after calibration) are control inputs
> > into
> > the filter prediction and not observations.
>
>
> I see. In that case, the other sensors (GPS, altimeter, airspeed
> indicator, pitch/roll corrected magnetic heading) would be the observations,
> correct?
>
> For efficiency (high rate inertial data, 100Hz for example) an indirect
> > filter
> > architecture is normally used. In this case the navigation state is
> > intergrated directly from the inertial observation and the filter only
> > estimates error corrections. A further advantage of an indirect filter
> > architecture is that you can represent attitude in a redundant form,
> > either
> > as a direction cosine matrix or using quaternions. This avoids the nasty
> >
> > problems associated with Euler angles.
> >
> > With regard to GPS observations you will need to choose and appropriate
> > coordinate frame. If you are going to be moving in a limited area (with
> > differential GPS for example) then you can represent position using
> > simple
> > Local Tangent Plane coordinates such as North, East, Down. Your GPS
> > receiver
> > can either report them directly or you can use a universal transverse
> > Mercator projection to convert from lat,long. In this form the GPS
> > observation model is simple. Your GPS may also give observations of
> > velocity
> > which can be used in the filter if the GPS unit has not already used
> > them to
> > estimate position.
>
>
> UTM coordinates sound like a logical choice. I'm already using the proj
> cartographic library for similar conversions.
>
> A good reference to all this is "Global Positioning Systems, Inertial
> > Navigation, and Integration" ISBN 0-471-35032-X
>
>
> Wow! I just picked that book up from the library *before* I got your
> email. Thanks for the tip.
>
> > Right now I'm just working on getting the correct predict/observe cycle.
> > > I'm using an Addative_predict_model and an
> > > Uncorrelated_addative_observe_model. Are there underlying assumptions
> > for
> > > these models that make them less suitable than the base model
> > > (Unscented_scheme::observe, for instance?)
> >
> > I am a bit confused by you "base model". 'Unscented_scheme::observe' is
> > a
> > member function of Unscented_scheme.
> > Specifying the model as 'Uncorrelated_addative_observe_model' is fine
> > for the
> > Unscented_scheme however.
>
>
> My mistake. I  copied the wrong thing. What happens if I use the
> uncorrelated noise model and the noise turns out to be correlated?
>
> Michael
> >
>
> Thanks for all the clarifications,
>
> Matt Hazard
> mwh...@nc...
>
> -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your
> > opinions on IT & business topics through brief surveys - and earn cash
> >
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Bayesclasses-general mailing list
> > Bay...@li...
> > https://lists.sourceforge.net/lists/listinfo/bayesclasses-general
> >
>
>

Re: [Bayes++] Square-root UKF

[Michael S. <ma...@mi...>]

On Thursday 11 January 2007 18:20, Matt Hazard wrote:
> One more idea.
>
> Would a full dynamic model of the airframe be necessary in an indirect
> formulation? It seems like you'd only be correcting the inertial navigation
> solution with the aiding sensors - only requiring an error model.

Nothing is made 'necessary' by the indirect formulation. In it simpliest form 
it is mathematically (though not numerically) the same as a simple direct 
filter. It does however allow you more flexibility in the state 
representation and how it is updated.



> A tightly-coupled filter with a nonlinear dynamics model of the airframe
> could use the control surface deflections as inputs in the predict_model,
> and the inertial and aiding sensors as measurements in the observe_model,
> correct?

To use gyro rates and acceleration as observation you need to represent them 
in the state vector. This requires a 15 variable state composed of position, 
velocity, acceleration, attitude, and attitude rate! Possible on a modern 
computers.

> It's a more complicated system, but wouldn't the specification of 
> the system dynamics model improve the results?

Hard question to answer on paper! Possibly. It would require a lot of work to 
model the sensors and dynamics such that the filter would work with the 
observation. Possibly you would not gain anything of much value for 
navigation but data that could be used by the controller.


All the best,
	Michael
-- 
___________________________________
Michael Stevens Systems Engineering

34128 Kassel, Germany
Phone/Fax: +49 561 5218038

Navigation Systems, Estimation  and
                 Bayesian Filtering
    http://bayesclasses.sf.net
___________________________________

Re: [Bayes++] Square-root UKF

[Michael S. <ma...@mi...>]

On Thursday 11 January 2007 18:01, you wrote:
> On 1/11/07, Michael Stevens <ma...@mi...> wrote:
> > Hello Matt,
> >
> > On Wednesday 10 January 2007 00:14, Matt Hazard wrote:
> > > Is there any support for Square-root (cholesky decomposition, etc)
> > > formulations of the Unscented Kalman filter in Bayes++?
> >
> > Sorry there are no Square-root Unscented implementations in Bayes++. The
> > only
> > unscented filter implemented is that described in the original Unscented
> > paper. Simon (Julier) has
> >
> > > I'm working on a
> > > GPS/INS system purposed for real-time control of a helicopter UAV; any
> > > computational cost reduction on the estimation end could directly lead
> >
> > to a
> >
> > > performance gain in the controller.
> >
> > OK I have a lot of experience in the GPS/INS fusion field so maybe I can
> > help
> > here. I would be interested in what sensors you are using.
>
> Our sensor board prototype uses Analog Devices' gyros (ADXRS300) and
> accelerometers (ADXL330, I think). The magnetometer is a PNI MicroMag3. We
> also have a complete (working) Crista IMU, which uses basically the same
> gyros/accelerometers, but lacks the magnetometers. At any rate we should
> see comparable results between the two sensor packages.

OK. Low cost MEMS type sensors. With this kind of low accuracy sensor you will 
need good differential GPS position to maintain the platform attitude.

The Crista unit look very sensible. It avoid ny attitude processing, which 
usually gets in the way. The temperature compensation and 1pps syncronisation 
are are worth having.


> > > I'm using an Addative_predict_model and an
> > > Uncorrelated_addative_observe_model. Are there underlying assumptions
> >
> > for
> >
> > > these models that make them less suitable than the base model
> > > (Unscented_scheme::observe, for instance?)
> >
> > I am a bit confused by you "base model". 'Unscented_scheme::observe' is a
> > member function of Unscented_scheme.
> > Specifying the model as 'Uncorrelated_addative_observe_model' is fine for
> > the
> > Unscented_scheme however.
>
> My mistake. I  copied the wrong thing. What happens if I use the
> uncorrelated noise model and the noise turns out to be correlated?

Not a problem for the Unscented_scheme. For most square root filters it is 
however a problem! The factorisations use to put the system into squareroot 
form require that the noise can be decorrelated and there is only a general 
solution for this for linear observation models. Luckily most observation 
generally only have weak cross correlations!

Michael
-- 
___________________________________
Michael Stevens Systems Engineering

34128 Kassel, Germany
Phone/Fax: +49 561 5218038

Navigation Systems, Estimation  and
                 Bayesian Filtering
    http://bayesclasses.sf.net
___________________________________