DPRG
DPRG List  



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

Subject: [DPRG] REMINDER: Kalman Filter Tutorial at October 15th RBNO
From: David Anderson davida at smu.edu
Date: Thu Oct 24 16:54:36 CDT 2013

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 <http://www.hitechnic.com/blog/gyro-sensor/htway/> 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 <http://www.x-firm.com/?page_id=148> 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 
> <http://docs.opencv.org/modules/video/doc/video.html>.  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 
> <http://www.amazon.com/Learning-OpenCV-Computer-Vision-Library/dp/0596516134/ref=sr_1_2?ie=UTF8&qid=1382043937&sr=8-2&keywords=opencv>.  
> 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] 
> *On Behalf Of *paradug
> *Sent:* Monday, October 14, 2013 8:46 AM
> *To:* dprglist
> *Cc:* 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
> http://list.dprg.org/mailman/listinfo/dprglist

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

More information about the DPRG mailing list