I stumbled across this thread and thought it would be good to share my experience with trying to use the G1 to implement a GPS-augmented INS system. The purpose was to provide a much higher resolution of position. Since the G1 has yaw, pitch, and roll sensors along with the corresponding accelerometers I thought this should (theoretically) work. Attitude and acceleration changes in the G1 platform could be translated to the global frame to give additional latitude and longitude coordinates between GPS updates. I spent a lot of time trying implement the math behind it, but just continued to have problems making it work. I discovered the yaw sensor was causing my problems. It was horribly inaccurate. The yaw sensor uses the magnetic compass and would frequently be 20 to 45 degrees off consistently. It also lagged quite a bit. Other posts also complained about similar problems with the compass. I also verified this with the Orienteer application. The roll and pitch sensors on the other hand were accurate.
On Dec 8, 6:29 pm, wellwatch <[email protected]> wrote: > I've done some work withGPSand INS systems, and essentially what an > extended Kalman filter (GPS/INS data is not linear so you can't use a > linear function to represent it, and this is what the EKF was invented > for correcting) is a way of correcting a measured value with an > estimate. I can estimate position based on data from an > accelerometer, and then since I know the noise distribution of my > estimate (based on accelerometer specs) and I know the noise > distribution ofGPSdata (based onGPSspecs) I can correct my > location with the estimated position, and weight them appropriately in > varied conditions. > > From what I have seen with G1GPSdata is that it is very poor > quality, the only time I get aGPSlock is when I have a clear sky > with a great deal of constellation visibility (hard to say for certain > since I've only looked at this data as a user, rather than seeing how > many satellites the receiver can hear, and how well it can hear > them). > > I am completely unaware of what accelerometer data is available to an > andriod developer, or its quality. > > If you truly just want to smooth the data, you could simply take the > mean of theGPSdata that you're getting, and that will deal with > outliers pretty well, if you want to really accurately estimate your > position in the case of low signal level, and possibleGPSlock loss > you could try and implement an EKF, based on theGPSdata and the > accelerometer data (I've been thinking about doing this but am not > sure when I'll have the time). > > This site:http://www.cs.unc.edu/~welch/kalman/ > > Has some great information on Kalman filters. > > On Dec 8, 7:06 pm, Brian Abbott <[email protected]> wrote: > > > Interesting. I did some R&D/Simple prototype coding for a WiFi Indoor > > Location Positioning System in 2001/2. I experimented with Kalman > > filters as well as RBFs in order to calm down the random jumping that > > occurs with indoor non-triangulated positioning. I say non- > > triangulated because, in truth it wasnt, and I assumed such problems > > would've disappeared had we been using Angle-of-Arrival or Time-of- > > Flight methods, similiar toGPS. I'd never heard ofGPSjumping or > > giving inaccurate positions in the scenario of a weak signal however, > > after having gone through the task of WiFi LPS, I dont doubt it, RF is > > a strange place that can through some interesting curve balls at > > you. > > > It's a hard problem to solve if it's the case thatGPScould give rise > > to the same issues. I'm sure with Cellular-EnhancedGPS, it becomes > > more likely. However, in order to implement something like this, I > > believe you would need decibal data from theGPS/Cellular Receievers > > for each signal incorporated into the measurement in order to weight > > each reading, I dont believe you would want to throw all readings in > > any kind of a filter equally weighted. Most of the time, say when the > > average Californian is driving on a busy roadway or highway, you > > should be able to receive a clean signal since, in terms of an average > > over distance traveled, you dont have too many tall buildings. Of > > course the anecotal response to that is that the large asian cities is > > where most users of these systems will probably reside however, the > > truth remains that good signals shouldnt be weighted the same as > > something that had poor signal quality to begin with. Although it's > > been.. six years since I've looked at Kalman Filters... time to > > refresh! I'm not sure if it's a problem but, It will be interesting to > > see what kind of problems come up with regard to positioning > > availability andaccuracy! I think their will probably be a need for > > hybrid systems with something like Zigbee or, a kind of ultra- > > sensitive custom indoor time-of-flight/AoA system as people begin to > > realize the value of Location and not only demand to be tracked but, > > down to the foot, especially in heavily populated environments.. in > > say 5 years? > > > Cheers, > > > Brian A. > > > On Dec 7, 2:12 pm, [email protected] wrote: > > > > hi all, > > > > so i understand that there are lots of smart people at google, so > > > maybe maybe this is > > > already in shipping libraries :) > > > > My guess is that theGPSdata coming back from the my android is just > > > raw, unmassaged > > > data as it gets it from whatever chipset the T1 is using (just like > > > what happens in the > > > emulator :). As people I'm sure realize,GPSdata is really really > > > noisy, especially when > > > the signal is weak, etc. > > > > I've been googling around and it seems like Kalman filters forGPS > > > would be a good > > > way of doing curve fitting so that outliers and other nasties would > > > get smoothed out. > > > Does anybody know of either this filter, or some otherGPSfiltering > > > mechanism that > > > are either available through the API's, or elsewhere? > > > > TIA, Mike --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
