DPRG List

 [DPRG] REMINDER: Kalman Filter Tutorial at October 15th RBNO Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] Previous message: [DPRG] REMINDER: Kalman Filter Tutorial at October 15th RBNO Next message: [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'" >, >, "'dprglist'" > Message-ID: <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 ] On Behalf Of Karim Virani Sent: Friday, October 25, 2013 3:47 PM To: 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 ] 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 ] 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: > > > > > > 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 > 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 > 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 ------------------------------ _______________________________________________ DPRGlist mailing list 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 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 ``` Previous message: [DPRG] REMINDER: Kalman Filter Tutorial at October 15th RBNO Next message: [DPRG] REMINDER: Kalman Filter Tutorial at October 15th RBNO Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the DPRG mailing list