whitemice, Your description is technically in focus in that we are looking at the same thing, I just want phone to use the accelerometer(s) to emulate 1 meter GPS and compass functions when no GPS or compass is available.
1.) So all the programming involves is: behavior is f(dx,dy,dz,orientation). The system provides the data from whatever costs the least. The function is already there on location, but accelerometer (inertial) estimates were not on the list of location service providers. This should be on the list with whatever caveats come with it (like requires consistent orientation since last known good). 2.) The other thing is that when data is bad and tower location cannot resolve exactly where the phones are I want the system to present choices in addition to precision estimates. The local program can have stored information about routes and history to pick from several possible positions. This will maintain continuity in the application whereas having precision suddenly go to a km with no more bearing data really blows up a pedestrian level program that requires a simulated compass. 3). Also, when comparing two poor signals (think like interpolating steam tables), the comparison needs to be done before any rounding. I want the phones to be able to share and compare raw data with each other without asking the system to make an independent (non- differential) estimate of where each is. If I am trying to locate someone and I cannot read a map, all I care about is relative position. The system can act like some systems engineer and insist on giving me only absolute data and throw the baby out with the bathwater, but it does not have to. In other words, android location services can be more robust than systems costing 4 times as much. This is a difference all customers will recognize when they do the inevitable side by side comparisons. Each time that happens Android takes share. ed (the systems engineer :-) On Jul 9, 7:05 am, whitemice <[EMAIL PROTECTED]> wrote: > There are a lot of interesting use cases for sub 1m accuracy and/or > indoor positioning on a mobile phone – hence I am following your ideas > with interest. > > Your proposal as I understand it: > If the communication API (at either the server or the client side) > gives you access to signal strength and packet delay information, you > may be able to get some idea of distance (but not direction?). This > estimate would become less reliable as more walls and furniture get in > the path of the signal. > > Communicating with two Wi-Fi transmitters (if this is possible on the > client side?) with known positions and coverage areas, would give you > two or more overlapping regions where the handset might currently be > located. > > By fixing your results along known walking routes and integrating path > data (from the accelerometer) you might be able to guestimate a user’s > current position. > > With all these uncertainties, I think claims of sub 1m accuracy are > overly optimistic (but not unachievable), although such a system could > have other benefits. > > To the original question: the Android Wi-Fi API has not yet been > released, so I can’t comment on how well your proposal might work on a > real device. > > Also, I am also investigating using accelerometers for estimating > position *inaccuracy* for my Snowball platform, which has > significantly lower accuracy requirements:http://blog.zedray.com/snowball/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to android-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
