DPRG
DPRG List  



[DPRG] REMINDER: Kalman Filter Tutorial at October 15th RBNO

Subject: [DPRG] REMINDER: Kalman Filter Tutorial at October 15th RBNO
From: Paul Bouchier bouchier at classicnet.net
Date: Tue Nov 5 05:25:49 CST 2013

Brian,

 

Excellent question and observation that odometry & IMU don’t give you
localization, and GPS does. There’s an important concept here: There are two
frames within which position and motion are tracked: 

1.       the Absolute frame (Abs for short), which is referenced to earth
coordinates such as latitude, longitude & elevation & heading

2.       the vehicle-relative frame (Rel for short), which is referenced to
the vehicle

 

IMU & odometer gives you motion/position in the rel frame. By definition,
when the system powers on and the IMU starts, you are at (0,0,0) in the rel
frame, with a heading of 0, and as the vehicle moves it does so in the rel
frame, relative to it’s program-start location of (0,0,0). Vehicle position
in the rel frame has no uncertainty, error or drift – it is what the sensors
say it is.

 

GPS, compass, barometer provide an estimate of pose in the abs frame.
Accelerometer measures pitch, roll and magnetometer measures yaw in the abs
frame. They have uncertainty and error.

 

The trick is to map the rel frame to the abs frame, and to keep re-mapping
it as time goes on and the mapping of the rel frame to abs frame changes due
to IMU drift.

 

At time 0 you can use gps, compass, accelerometers to say rel position
(0,0,0) and attitude (pitch, roll, yaw) in the rel frame maps to abs
position (latt,lon,el) and (abs-pitch, abs-roll, abs-yaw). At later times,
when the vehicle is moving, you can use the IMU & odemetry to say “in the
rel frame I’m at (relX, relY, relZ, pitchP, rollR, yawY) and that used to
map to (lat1, lon1, el1,pitch1,roll1,yaw1), but gps tells me with some
uncertainty that it now maps to (lat2, lon2, el2). Estimating this mapping
is the heart of what the Kalman filter that’s fusing IMU/odometry data with
GPS data does – the exact value of the mapping is unknown but is estimated
along with an estimate of the uncertainty of the estimation. Thus you get
sigma-X, Y, Z: an estimate of how accurately your position is considered to
be known. Also, the mapping of pitch, roll & yaw in the rel frame to the abs
frame changes over time.

 

The rel-frame sensors are sampled very fast (e.g. 100Hz), whereas GPS only
comes in at maybe 5 Hz, so an estimate of current position in the abs frame
(which is what’s interesting) is based off rel-frame sensors (IMU) adjusted
by the last estimate of rel-abs frame mapping.

 

Most of David’s reply below deals with estimating position in the rel frame,
and as his last paragraph says, the GPS plus Kalman filter maps the
rel-frame position into the abs frame, thereby fusing abs-frame position
estimate from sensors such as GPS, compass, accelerometers, barometer with
rel-frame estimate to produce a position/attitude estimate that’s better
than either and is estimated between (possibly infrequent or inaccurate)
abs-frame measurements. 

 

GPS may be lost, the compass may pass over rebar, and the accelerometers are
noisy, but in the short-term, these don’t affect the solution a lot – IMU &
odometry carries you through. Over the longer-term if they stay wrong they
will produce an incorrect final estimate of position. In a way it behaves
similarly to the complementary filter, but it’s not as naïve as just giving
an estimated time-constant to individual sensors.

 

It’s pretty interesting to view a vehicle track in abs & rel, overlayed on
one another, with initial offsets removed. You see the rel track deviate
from the abs track and end up maybe 20 – 60m away from the starting point
after a 6km loop returning to the same location, whereas GPS jumps around
now and then, but the final solution output from the position estimation
filter is a smooth track that generally follows GPS but not exactly, and
ends up maybe 30cm from the start after that same 6km loop.

 

Even more interesting is converting the solution to a kml file and
overlaying it on google maps in satellite view. You see it show your track
cutting a corner and running off the road when you know you didn’t. Then you
have to ask, is google maps geo-accurate or is your position estimate
incorrect, or a bit of both. Obviously, neither is absolutely accurate, but
the key question is “how accurate is your estimated position relative to the
road in the real world”.

 

This rel-frame and abs-frame concept was new to me, but it’s a nice way to
think about what the different kinds of sensors are telling you. You only
map one to the other at one place in the system: the final output of the
position-estimation filter. How the abs sensors got fused with the IMU was
previously unclear to me, but the abs-rel mapping concept makes it easy to
see.

 

Good luck with your quad Brian.

 

Paul

 

From: dprglist-bounces at dprg.org [mailto:dprglist-bounces at dprg.org] On Behalf
Of David P. Anderson
Sent: Sunday, November 3, 2013 7:21 PM
To: dprglist at dprg.org
Subject: Re: [DPRG] REMINDER: Kalman Filter Tutorial at October 15th RBNO

 

Brian,

I'm mostly familiar with AHRS devices from R/C aircraft and helicopters.
For ground based robots a more common location method is to combine wheel
odometry with an IMU to correct for slip and drift in the wheels.   

An odometry location is calculated as a series of little right triangles
based on the input from two wheel encoders at a regular rate, say 25Hz.
Like this:

    distance = (left_encoder + right_encoder) / 2;

    theta = theta + ((left_encoder - right_encoder) / WHEEL_BASE);

    X_position = X_position + (sin(theta)*distance);
    Y_position = Y_position + (cos(theta)*distance);

What the IMU provides is an angular rotation;  a vector, and a rotation
around that vector.  That can be converted into Pitch, Yaw, and Roll.  
Basically the YAW value replace theta in the above equation.  Like this:

  distance = (left_encoder + right_encoder) / 2;

  theta = imu(YAW);

   X_position = X_position + (sin(theta)*distance);
   Y_position = Y_position + (cos(theta)*distance);

So the orientation of the robot is derived from the IMU and the translation
is derived from the wheels, and the whole thing is called, perhaps
incorrectly,  odometry.  This is the way my jbot robot navigates.   

The idea here is to combine the location created by the odometry with the
location returned by the GPS using a Kalman filter. Or maybe just a
complementary filter.  In order to produce a location more accurate than
either.  This appears to be what Paul is playing with even as we speak.

cheers,
dpa



On 11/03/2013 01:18 PM, Brian A. Stott wrote:

@Paul and all --- 

 

Question regarding the stressing of an IMU in your testing? IMU, unless
containing a Barometer for height and compass for direction/heading, will
not be useful to calculate/determine locations with a GPS. The filters you
mention are simply integrating the various IMU sensor angles to determine an
accurate orientation of the device in which they are attached. This is the
heart of an Attitude Heading Reference System (AHRS). GPS is different and
for location.

 

Am I on the right track? I'm not working as a 'Know It All.' IMU is for AHRS
which will keep you from falling over, listing to one side and let you know
you are upside down.  ;-)  But, as to where you are on the planet? An
accelerometer and a gyro just won't tell you where you are at or how far
you've come?  Nor, how fast you are going. Yes?

 

Note: Don't get grumpy at me. I'm a year long lurker and am getting on board
late with all the new tech. I'm testing my understanding and trying to work
out the logic here. I just got my quad w/AHRS(IMU), GPS, & GCS working.
Next is FPV, 3DG and more 3D printed.  :-)   Acronym(s)   whoo! yaahh!

 





Subject: Re: [DPRG] REMINDER: Kalman Filter Tutorial at October 15th
    RBNO
To: "'Karim Virani'" <karim at compuguru.com <mailto:karim at compuguru.com> >,
<davida at smu.edu <mailto:davida at smu.edu> >,
    "'dprglist'" <dprglist at dprg.org <mailto:dprglist at dprg.org> >
Message-ID:  <mailto:000d01ced8b2$9c507560$d4f16020$@classicnet.net>
<000d01ced8b2$9c507560$d4f16020$@classicnet.net>
Content-Type: text/plain;    charset="us-ascii"

Karim, David,

Great discussion. Let me add some experiential data, and reiterate David's
question.

I'm driving around in trucks these days taking GPS/IMU fused data and
analyzing it's accuracy as I qual a new Nav unit containing GPS and IMU (aka
gyro & accelerometers) and odometry, all of which is fused using Kalman
filters.

Our GPS uses a base-station correction system called Omnistar HP (from a
company called Omnistar), which offers a subscription service to corrections
from base stations that they maintain in many parts of the world. It does
not use RTK (wavelength-accurate) AFIK, but the corrections from base
stations (which are broadcast from a satellite) are sufficient to get
best-case accuracy of 7 - 10cm. In practice, I see reported GPS accuracy
drop to 20cm - 50cm when we go under trees or high-tension power-lines.
Under some sections of trees it loses all satellites, and can take a couple
of minutes/500m to reacquire and get accuracy back to Omnistar-HP levels.
This answers the question of "why use odometry at all" - gps accuracy is
easily degraded and can be out for a while, and you need something to guide
you in the interim. BTW, these are Novatel GPS units - commercial-grade.

I've also seen a calibrated reference Novatel SPAN unit using rtk and highly
accurate IMU be off by between 0.4 - 1.5m at the end of a 6km run around a
loop, where we actually ended up within 10cm of the starting location, as
judged by a reference mark on the curb. Conclusion: fusing rtk GPS and IMU
doesn't necessarily give you perfect localization - the IMU drifts and can
drag the solution away from the truth, especially during times of reduced
GPS accuracy.

Kalman filters produce a best estimate of un-observable state, given noisy
measurements of state and inputs, for an arbitrary set of state. David's
question still stands and can be restated as "if my application is such that
a complementary filter might work (e.g I have a sensor accurate in the
short-term but that drifts long-term, and a second that jumps in the short
term but has long-term average accuracy, why do I need a kalman filter,
which is more complicated? Why can't I use the simpler complementary filter"
I'd like to know the answer too.

A consideration is that ionospheric delay variations which cause some of the
gps inaccuracy don't have a fixed time constant - AFIK you can't count on
how long they're going to push the reading in one direction or another.

One hypothesis answering David's question is that Kalman is a general
solution for N state variables. In practice you have GPS, odometers, gyros &
accelerometers, each of which has its own variance characteristic. The
complementary filter only has a time-constant that is supposed to model the
various sensor's time-related accuracy. However, GPS doesn't really have a
time-constant - variance is a better model of its uncertainty. Odometers
don't have a time-related accuracy either - when the vehicle is sitting
still they're very accurate :-) - their accuracy is distance and driving
condition-related - better modeled as a variance. Accelerometers have a
fixed variance, whereas gyros have a time-dependent variance. All-in-all the
update-estimate kalman cycle using sensor variances seems like a more
complete model than a simple time-related accuracy that places different
weights on gps vs. IMU & odometry. But that's just a hypothesis - it would
be good to hear from someone who really knows.

OTOH, you'd think a complementary filter should be fine in a simple system
like a gyro and accelerometer in a balancing robot - the sensors there are
much more complementary than those used for vehicle localization.

Paul

-----Original Message-----
From: dprglist-bounces at dprg.org <mailto:dprglist-bounces at dprg.org>
[mailto:dprglist-bounces at dprg.org <mailto:dprglist-bounces at dprg.org> ] On
Behalf
Of Karim Virani
Sent: Friday, October 25, 2013 3:47 PM
To: davida at smu.edu <mailto:davida at smu.edu> ; 'dprglist'
Subject: Re: [DPRG] REMINDER: Kalman Filter Tutorial at October 15th RBNO

Yes, Francis, please jump in.  In the interests of a interesting discussion:

>So  if the GPS is used without the odometery the location errors would 
>be on the order of 3 to 5 meters.    That doesn't sound like a good 
>argument for the proposition "why use odometry at all?"  so I'm not 
>sure I
see your logic here.

This is where my writing skills are to blame.  The proposition of "why use
odometry at all" was meant to be linked to the accuracy of RTK GPS.  But I
wasn't sure about whether it would work at NASCAR speeds.  I'm still not
sure RTK technology is inherently incapable of working at speed once the
initial lock is achieved.  There is no reason for products implemented for
surveying applications to work at speed.  But if the claims of the Piksi
folks are correct, they used the technology to track kites moving in 3D
figure 8s at up to 100mph with centimeter level accuracy.  Still not NASCAR
speeds, but getting close. So if it turns out to work at speed, it obviates
the need for odometry. This could be a fairly recent development that was
not available to Francis at the time.

On the other hand, if the solution is just DGPS+WAAS, then the faster you
are going, the less the fixed ~3 meter certainty range matters.  If you are
traveling at 100 meters per second in relatively straight lines and
constrained curves (leading to a better model), a kalman filter might do
some things for you that would not be so apparent on a robot wandering at
1/200 that speed with the same precision of fix?


-----Original Message-----
From: David Anderson [mailto:davida at smu.edu <mailto:davida at smu.edu> ]
Sent: Friday, October 25, 2013 3:13 PM
To: Karim Virani; dprglist
Subject: Re: [DPRG] REMINDER: Kalman Filter Tutorial at October 15th RBNO

Hi Karim,

Fair enough.  If this is the case, then the odometry measurements get off
over time and so they are also "noisy" and need to be constrained by 
the Kalman filter via the GPS.  That's what made sense to me, so I 
asked that question specifically at the talk, and was told no.  Francis 
said that the odometery was used to correct the GPS locations, but not the
other way around.

So  if the GPS is used without the odometery the location errors would 
be on the order of 3 to 5 meters.    That doesn't sound like a good 
argument for the proposition "why use odometry at all?"  so I'm not sure I
see your logic here.

Francis told us he uses an expensive GPS, but the cost seems to be
associated with the 40Hz data rate rather than the precision of the
instrument.  The errors he referenced needing to correct were on the order
of 3-5 meters.

We have surveyor grade equipment at SMU, but it needs to remain in the same
position for quite a while to produce centimeter accuracy --- not something
a robot or NASCAR can do.

So, to summarize, we know that odometery can work very accurately without
GPS (see jBot) and we know that GPS accuracy is on the order of
3 to 5 meters and cannot work accurately without some sort of location
correction derived from the odometery.

Francis, are you lurking out there?  We need your input.

best,
dpa



On 10/25/2013 12:54 PM, Karim Virani wrote:
> My question would be - why use odometry at all? If they were using 
> DGPS + WAAS then I could see how odometry could help with the 
> interpolations between fixes of about 1-3 meter accuracy.  Over the 
> longer term (10s of
> seconds) under extreme racing conditions, I think odometry errors 
> would build pretty rapidly.  So it makes sense to me the way the 
> solution was described.
>
> I missed the early part of the presentation so I didn't see the specs 
> of the GPS solution.  Surveyor grade RTK GPS has been around for some 
> time and that can provide sub decimeter accuracy.  While expensive 
> from a hobbiest perspective, I'd think the NASCAR could absorb that 
> kind of cost.  It makes sense to set up an accurately positioned 
> reference station under those conditions.  Maybe RTK doesn't work well 
> at really high speed?  By the way, the cost is coming down rapidly.  I
just missed out on this kickstarter:
>
> Lots of interesting info there if follow through to the website, wiki, 
> forums and repositories.
>
>
>
> -----Original Message-----
> From: dprglist-bounces at dprg.org <mailto:dprglist-bounces at dprg.org>
[mailto:dprglist-bounces at dprg.org <mailto:dprglist-bounces at dprg.org> ] On 
> Behalf Of David Anderson
> Sent: Thursday, October 24, 2013 5:59 PM
> Cc: dprglist
> Subject: Re: [DPRG] REMINDER: Kalman Filter Tutorial at October 15th 
> RBNO
>
> The GARMIN website gives 3-5 meter accuracy for DGPS and  <3 meter for
WAAS.
> That fits my experience working in the field with the units we have 
> here at SMU Geology.  Three meters is reasonable but it is hardly 
> inches, or fractions thereof, which can be had with odometry, even 
> over a very long
> course:
>
> <http://www.geology.smu.edu/~dpa-www/robo/jbot/jbot_hatrick2_2.mpg
<http://www.geology.smu.edu/%7Edpa-www/robo/jbot/jbot_hatrick2_2.mpg> >
>
>
> regards,
> dpa
>
>
> On 10/24/2013 05:46 PM, Tom Brusehaver wrote:
>> If the odometry is perfect, then you can skip everything. In a small 
>> robot over a short course, this might be good enough.
>>
>> If there is any wheel slip, then you may need to re-calibrate 
>> occasionally. Beacons and other known locations can help.
>>
>> GPS won't work indoors usually.
>>
>>
>> With DGPS and WAAS the accuracy ought to be inches most of the time.
>> If your GPS has the capability to output DOP then you can derive the 
>> accuracy of the GPSs current location. The aviation GPS's have a RAIM 
>> check that measures the accuracy of the current GPS location, and if 
>> it isn't good enough, then it will put up an alert on the display.
>> (what the pilot does with that information depends on the situation).
>>
>>
>>
>>
>> On Thu, Oct 24, 2013 at 5:28 PM, David Anderson <davida at smu.edu
<mailto:davida at smu.edu> > wrote:
>>> Hey Tom,
>>>
>>> That makes sense for big jets.  For our robots, and the NASCAR races 
>>> that Francis works on,  the location in terms of lat/lon is pretty 
>>> constrained.  We're not flying cross-country... :)
>>>
>>> For example, on the outdoor robot jBot, the position calculations are
>>> all based on a flat rectangular mapping space.  The world may be a
>>> sphere, but little jBot can't tell that.  There is not enough
>>> battery/speed/runtime/patience to go more than a few miles.  So the 
>>> robot initializes it's position on a rectangular grid from the 
>>> lat/lon returned by the GPS when it comes up, just like the big 
>>> jets, and
> that's
>>> the only time it uses the GPS.  All the location calculations and
>>> navigation are done thereafter with odometry, which seems to work fine.
>>>
>>> Seems like Francis' NASCAR systems could do the same thing.  So the 
>>> question remains, if odometry is more accurate than the GPS, why use 
>>> a GPS at all?  Why not just go with the (more accurate) odometry, 
>>> and skip the GPS and Kalman filter?
>>>
>>> thanks
>>> dpa
>>>
>>>
>>>
>>> On 10/24/2013 05:11 PM, Tom Brusehaver wrote:
>>>> I know for the big jets, the flight management system or computer 
>>>> (FMS or FMC) needed to be initialized with a Lat/Lon. Now that the 
>>>> aircraft have GPS, the GPS is used to initialize the FMS 
>>>> automatically.
>>>>
>>>> Kalman filters are just taking noisy data and making it usable.
>>>> The data the filter is using can come from any source.
>>>>
>>>> Air Traffic RADAR processors use Kalman filters to predict tracks 
>>>> of aircraft. They don't have any accelerometer or gyros, just range 
>>>> and azimuth inputs from the RADAR.
>>>>
>>>> On Thu, Oct 24, 2013 at 4:54 PM, David Anderson <davida at smu.edu
<mailto:davida at smu.edu> > wrote:
>>>>> I want to add my thanks also for Francis' presentation last week 
>>>>> at
> RBNO.
>>>>> Excellent.
>>>>>
>>>>> The lecture cleared some things up for me, and also prompted some
> questions.
>>>>> The technique as it was presented and I understand it essentially 
>>>>> used position calculations derived from wheel odometry to correct 
>>>>> noisy GPS locations, and included a nice graph showing the signal 
>>>>> and noise and where the correction was needed.
>>>>>
>>>>> My question is, if the odometry is more accurate than the GPS, and 
>>>>> in fact is used to correct the GPS, then why is the GPS used at 
>>>>> all?  Why not just use the odometry?
>>>>>
>>>>> The kalman filter on my two wheel balancer reads a two axis 
>>>>> accelerometer and a single axis gyro to determine the tilt angle.
>>>>> The accelerometer measures the vector of gravity and it is correct 
>>>>> over the long term, but, because it also measures the transient 
>>>>> accelerations of the robot platform, it is not correct over the 
>>>>> short
> term.
>>>>> The gyro, by contrast, gives correct angular readings in the short 
>>>>> term but tends to drift over time because of errors in the 
>>>>> integration,
> and is not
>>>>> reliable in the long term.  If you only need to balance for 10s of
> seconds
>>>>> or maybe a few minutes, then you could probably get by with just a
> gyro.
>>>>> IF the robot is to travel around  and be stable for hours, or 
>>>>> indefintely, then the gyro needs the accelerometers combined with 
>>>>> the kalman filter, to keep it from drifting.
>>>>>
>>>>> So there is one sensor that can be trusted for short term but not 
>>>>> long term measurements (gyro), and one that can be trusted for 
>>>>> long term but not short term (accelerometers).  The kalman filter 
>>>>> combines these two sensors into a single signal which is reliable 
>>>>> both
> short term and long term.
>>>>>    From Francis' presentation at the RBNO as I understood it, 
>>>>> odometry was used to correct the GPS errors, but not the other way 
>>>>> around --- the GPS was not correcting errors in the odometry.  I 
>>>>> asked
> this question specifically.
>>>>> So, if that is the case, then again, why use the GPS at all?  I'm 
>>>>> not clear here.  Any help will be appreciated.
>>>>>
>>>>> best regards,
>>>>> dpa
>>>>>
>>>>>
>>>>>
>>>>> On 10/17/2013 05:33 PM, Karim Virani wrote:
>>>>>
>>>>> Francis, thanks for the talk - It definitely helped me out.  Are 
>>>>> you sharing the slides? I look forward to the video being 
>>>>> published so I can catch up on what I missed at the beginning.
>>>>>
>>>>>
>>>>>
>>>>> There were some questions asked about generally available 
>>>>> implementations of Kalman filters and balancing algorithms.
>>>>>
>>>>>
>>>>>
>>>>> For the VEX IQ balancer I've ported the HTWay example published by 
>>>>> HiTechnic into ROBOTC.  This implementation has no Kalman filter 
>>>>> because it is not dependent on an accelerometer to correct the 
>>>>> gyro.  Instead it relies on an exponential moving average of the 
>>>>> gyro to correct for drift, based on the assumption that while the 
>>>>> robot is balancing, the moving average should converge to zero.
>>>>> This might be a more fragile solution that incorporating 
>>>>> accelerometer
> correction, but seems to work well-ish on smooth surfaces.
>>>>> The EV3 gyroboy example uses the same method.
>>>>>
>>>>>
>>>>>
>>>>> Outside of the work David has done, this is the most approachable 
>>>>> description and sample code I've seen so far on a two wheel 
>>>>> balancing platform.  It's an arduino-based solution using both a 
>>>>> gyro and accelerometer.  It incorporates a very simple Kalman 
>>>>> filter.  It's not a general purpose Kalman calculator - it is 
>>>>> built specifically to fuse the gyro and accelerometer inputs and 
>>>>> the matrix math is already 'unrolled.'  I can't speak to how well 
>>>>> this
> implementation works - haven't tried it yet.
>>>>>
>>>>>
>>>>> I mentioned that OpenCV has a general purpose C++ KalmanFilter 
>>>>> class.  It is dependent on other bits (mostly matrix operations) 
>>>>> of OpenCV so you can't just separate it out for use in your pet 
>>>>> microcontroller.  OpenCV has been ported to Android and iOS and 
>>>>> there are plenty of videos and examples out there.  You're 
>>>>> probably not going to dive into OpenCV for just the KahlmanFilter 
>>>>> though - OpenCV has too steep a learning curve unless you are 
>>>>> committed to serious machine vision.  There is a pretty decent 
>>>>> treatment of the KalmanFilter class usage in the classic OpenCV 
>>>>> book.  Wish they could
> solve the delay in getting the updated C++ edition published.
>>>>>
>>>>>
>>>>> Hope this helps,
>>>>>
>>>>>
>>>>>
>>>>> Karim
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: dprglist-bounces at dprg.org <mailto:dprglist-bounces at dprg.org>
[mailto:dprglist-bounces at dprg.org <mailto:dprglist-bounces at dprg.org> ]
>>>>> On Behalf Of paradug
>>>>> Sent: Monday, October 14, 2013 8:46 AM
>>>>> To: dprglist
>>>>> Cc: fxgrovers at yahoo.com <mailto:fxgrovers at yahoo.com> 
>>>>> Subject: [DPRG] REMINDER: Kalman Filter Tutorial at October 15th 
>>>>> RBNO
>>>>>
>>>>>
>>>>>
>>>>> -All,
>>>>>
>>>>>        DPRG member Francis Grover has agreed to conduct a Kalman 
>>>>> filter tutorial at the October 15th RBNO at 7:30. Francis not only 
>>>>> teaches the use of Kalman filters at the college level, he also 
>>>>> uses them. Francis was heavily involved in the technology that is 
>>>>> used by television networks to track NASCAR race cars during a race.
>>>>>
>>>>>
>>>>>
>>>>>        This is a golden opportunity for you to learn about the 
>>>>> "magic" that makes auto pilots and automatous cars possible using 
>>>>> inertial measurement units (IMU).  If you have investigated Kalman 
>>>>> filters, you know that they are matrix intensive and hard to 
>>>>> understand. Francis will show how to construct the necessary 
>>>>> matrixes using sensor outputs and give us insight into how they 
>>>>> work. He will also touch on data fusion and plans to leave us with 
>>>>> some
> sample code so we can get started.
>>>>>
>>>>>
>>>>>        See you on the 15th!
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Doug P.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> DPRGlist mailing list
>>>>> DPRGlist at dprg.org <mailto:DPRGlist at dprg.org> 
>>>>> http://list.dprg.org/mailman/listinfo/dprglist
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> DPRGlist mailing list
>>>>> DPRGlist at dprg.org <mailto:DPRGlist at dprg.org> 
>>>>> http://list.dprg.org/mailman/listinfo/dprglist
>>>>>
>>> _______________________________________________
>>> DPRGlist mailing list
>>> DPRGlist at dprg.org <mailto:DPRGlist at dprg.org> 
>>> http://list.dprg.org/mailman/listinfo/dprglist
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org <mailto:DPRGlist at dprg.org> 
> http://list.dprg.org/mailman/listinfo/dprglist
>
>


_______________________________________________
DPRGlist mailing list
DPRGlist at dprg.org <mailto:DPRGlist at dprg.org> 
http://list.dprg.org/mailman/listinfo/dprglist



------------------------------

_______________________________________________
DPRGlist mailing list
DPRGlist at dprg.org <mailto:DPRGlist at dprg.org> 
http://list.dprg.org/mailman/listinfo/dprglist


End of DPRGlist Digest, Vol 114, Issue 1
****************************************








_______________________________________________
DPRGlist mailing list
DPRGlist at dprg.org <mailto:DPRGlist at dprg.org> 
http://list.dprg.org/mailman/listinfo/dprglist

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.dprg.org/pipermail/dprglist/attachments/20131105/026119f6/attachment.html 

More information about the DPRG mailing list