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: Fri Oct 25 16:07:21 CDT 2013

Great link!  Thanks.

Looks like they are using Carrier Phase Enhancement, which they call 
Real Time Kinematics (RTK).

My understanding according to the physicists that have described this to 
me is that the signal from the satellite is a certain integer number of 
wavelengths from sat to receiver, plus some fraction of a wavelength.  
It is a measure of that fraction of a wavelength that is used to provide 
the additional accuracy.

Additionally, I believe that this also requires a reference base station 
at a fixed, known location in order to provide the necessary 
correction.  Not sure if that is another piece of equipment that you 
need to haul around with you when you want to run the robot, which would 
be ok, or just some known station within the range of the GPS, which 
would be more difficult to deploy, I think.   Seems worth exploring.  
Thanks.

dpa




On 10/25/2013 12:58 PM, Karim Virani wrote:
> Oops.  Here's the link:
>
> http://www.kickstarter.com/projects/swiftnav/piksi-the-rtk-gps-receiver
>
>
> -----Original Message-----
> From: dprglist-bounces at dprg.org [mailto:dprglist-bounces at dprg.org] On Behalf
> Of Karim Virani
> Sent: Friday, October 25, 2013 12:54 PM
> To: davida at smu.edu
> Cc: 'dprglist'
> Subject: Re: [DPRG] REMINDER: Kalman Filter Tutorial at October 15th RBNO
>
> 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] 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>
>
>
> 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> 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> 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]
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> DPRGlist mailing list
>>>>> DPRGlist at dprg.org
>>>>> http://list.dprg.org/mailman/listinfo/dprglist
>>>>>
>>> _______________________________________________
>>> DPRGlist mailing list
>>> DPRGlist at dprg.org
>>> http://list.dprg.org/mailman/listinfo/dprglist
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://list.dprg.org/mailman/listinfo/dprglist
>
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at dprg.org
> http://list.dprg.org/mailman/listinfo/dprglist
>
>

More information about the DPRG mailing list