I would like to detect location of bluetooth enabled devices automatically using bluetooth accesspoints. Is it possible? If so, how can I do it?
Bluetooth devices have unique MAC addresses so I think this would be possible but has a number of constraints:
You would want the devices to be either discoverable, or to have already paired with them
Bluetooth devices don't tend to be screwed to the ceiling like enterprise access points, or tethered to a phoneline like their domestic counterparts.
The range of bluetooth is typically less than WiFi, which will potentially increase the difficulty in accurate localisation.
No such database already exists to my knowledge.
You can get the signal strength information you'd need to do this from BlueZ on Linux, so I assume similar is possible on other platforms. It's then a question of building a database of measured signal strengths at known location to "map" an area. With this database an unknown set of signal strengths can be matched to a large radius, by just using the set of all known positions of all of the devices seen. With that knowledge you could either:
Triangulate properly if you actually know locations of individual devices
or:
See which location in your database, within the trivially calculated radius best matches the strengths you are measuring on the device currently.
Related
I am reading about Received Signal Strength Indicator(RSSI). This could be used for our particular case, a rough estimation of distance between devices. But maybe there could be something to combine in order to improve the accuracy.
There are too many variables at play to accurately determine such data.
It's completely impractical to obtain a reliable distance figure just looking at the RSSI. It may give you an order of magnitude but nothing remotely accurate.
Most notable is the variety of devices and underlying hardware used. But take into account this simple example: you have 2 pairs of devices, 1 pair has good signal for a range of 30m without obstacles within and another pair has the same value for what would be considered a good signal but they are within 1m but with an obstacle which causes heavy interefernce. Any interpretation from empirical data would be awfully inaccurate.
The best change you have is to pinpoint each device's location by GPS and communicate&compare coordinates. But again, the underlying hardware comes at play. Also the length of time it takes to pinpoint with a better accuracy. We're talking about 5-50 meters. So it's basically mostly noise.
Go beyond that and you go out of wi-fi direct / peer-to-peer range.
As such, trying to estimate distances begtween 2 android devices at this time would be in my view an utter waste of time. (unless you are building a huge network of interconnected wi-fi direct devices in which case you could come up with some cool applications, or at least visualisation stuff - that's a bit of a stretch considering one-to-many limitations).
I'm new to android programing. I know how to get a position of a user in outdoor environment using GPS.
But i'm faced with a problem to find the location of a person inside a building where you don't have GPS available.
I can handle the coding part but i need an idea in how to use compass, accelerometer, and gyroscope data or any other sensor data except GPS to get the current position of the user inside the building after you pass the compass, accelerometer, and gyroscope data to the server. Here consider that the inside of the building is mapped.
Sorry if this is a stupid question.
It sounds like you intend to perform inertial navigation using accelerometer data based on the last good GPS fix. I think you'll find this is not feasible on a mobile phone. Accelerometers used in inertial navigation -- for example, in aircraft -- have to be extremely accurate and highly calibrated to minimize errors. Even then, all inertial systems drift over time. With the relatively low accuracy of a phone, these errors will accumulate quite rapidly and render your position solution unusable very quickly.
Without GPS, most phones can still give you a rough position estimate using cell-site multilateration. This is nowhere near as accurate as a GPS fix, but it's better than nothing.
See also this excellent discussion of indoor locationing (inertial navigation is mentioned there too):
Android accelerometer accuracy (Inertial navigation)
Indoor locationing is quite difficult, if not impossible today.
What works is mounting Low energy Blue Tooth "Beacons" at multiple places in the building,
and use that as info. (see ios Beacons) (But you have to manage that yourself, relation between beaconID and location inside bulding).
With compass, accelerometre and gyroscope you will not have (much) success:
In this Google Tech Talk video it is quite detailed explained why a gyro / accelerometer (relaive) navigation cannot work because the slight inaccuracies accumulate within 2 or 3 seconds so strong that you cannot use the result. This is cause by the double integration, see video at 23:30.
Private WLAN (inside your building) triangulation can work, but not inside an (limited) phone which does not give you the info which WLANs are vissible, at which strength.
What remains the already build it GSM-Cell or Wlan location in your smart phone for indoor usage.
There is one further approach:
Evaluating the magnet fields of an building.
This can work, and at least one company works on that, but you have to calibrate that for each building.
But this is more a reasearch topic, than a well known technic.
Further info
My Algorithm to Calculate Position of Smartphone - GPS and Sensors
Hi
I'm working with google maps api in both javascript and java on respectively a pc and android. There's probably a difference, but I've been looking around in the documentation for a max number of markers that is a good idea to put on the map, to not have a system crash. It's probably a lot smaller on android, but I really have no idea of an estimate is it 25 - 100 - 1000?
So that's why I'm asking you. What is the maximum number of markers on a map that the user system can handle on pc and android? I know that it depends on the individual system, but I also bet that there are some guidelines I'm not aware of, that I can follow to optimize the user friendliness of my applications.
thanks
From the Google documentation
There is no limit to the number of
markers or path vertices supported by
the Google Static Maps API. However
Static Maps API URLs can be a maximum
of approximately 2,000 characters
which constrains the number of markers
and path vertices that can be
specified based on the number of
decimal places used when specifying
each latitude/longitude pair.
However, you should consider whether your application is overloading the users ability to select from so many markers. Ideally, your application should be doing the filtering for them and only showing a few simple, well spaced choices to allow for big thumbs on the touchscreen.
I would suggest that you use a zoom level manager after reading this article that describes one.
Will J2ME Location Based API work without GPS?can you gave me example ?
Depends on the device implementation!
On many devices you can specify the behaviour during accessing the Location API. (Nokia s40 lets you search for bluetooth gps devices e.g.)
If the location API is able to use data like cellID, LAC, ... (if you specify low accuracy criteria) depends on the device implementation and even if your operator lets you use those values. ( http://www.easywms.com/easywms/?q=en/node/3589 )
Many devices do have the API on board even if they are not equipped with gps functionality.
I believe it will work, but it will be less accurate because it has to use the cell towers to determine location, not GPS.
Well, the call will work, but how will it know where you are?
See the discussion at Oracle, which says:
"To discover the location of the
device, LBS must use real-time
positioning methods. Accuracy depends
on the method used."
In the United States, to provide semi-accurate tracking data for the 911 emergency system, all phones must be able to be located within a few hundred feet. It's done by triangulating distance from the nearest three or so towers.
GPS simply makes that (existing) data more accurate.
My goal is to recognize simple gestures from accelerometers mounted on a sun spot. A gesture could be as simple as rotating the device or moving the device in several different motions. The device currently only has accelerometers but we are considering adding gyroscopes if it would make it easier/more accurate.
Does anyone have recommendations for how to do this? Any available libraries in Java? Sample projects you recommend I check out? Papers you recommend?
The sun spot is a Java platform to help you make quick prototypes of systems. It is programmed using Java and can relay commands back to a base station attached to a computer. If I need to explain how the hardware works more leave a comment.
The accelerometers will be registering a constant acceleration due to gravity, plus any acceleration the device is subjected to by the user, plus noise.
You will need to low pass filter the samples to get rid of as much irrelevant noise as you can. The worst of the noise will generally be higher frequency than any possible human-induced acceleration.
Realise that when the device is not being accelerated by the user, the only force is due to gravity, and therefore you can deduce its attitude in space. Moreover, when the total acceleration varies greatly from 1g, it must be due to the user accelerating the device; by subtracting last known estimate of gravity, you can roughly estimate in what direction and by how much the user is accelerating the device, and so obtain data you can begin to match against a list of known gestures.
With a single three-axis accelerometer you can detect the current pitch and roll, and also acceleration of the device in a straight line. Integrating acceleration minus gravity will give you an estimate of current velocity, but the estimate will rapidly drift away from reality due to noise; you will have to make assumptions about the user's behaviour before / between / during gestures, and guide them through your UI, to provide points where the device is not being accelerated and you can reset your estimates and reliably estimate the direction of gravity. Integrating again to find position is unlikely to provide usable results over any useful length of time at all.
If you have two three-axis accelerometers some distance apart, or one and some gyros, you can also detect rotation of the device (by comparing the acceleration vectors, or from the gyros directly); integrating angular momentum over a couple of seconds will give you an estimate of current yaw relative to that when you started integrating, but again this will drift out of true rapidly.
Since no one seems to have mentioned existing libraries, as requested by OP, here goes:
http://www.wiigee.org/
Meant for use with the Wiimote, wiigee is an open-source Java based implementation for pattern matching based on accelerometer readings. It accomplishes this using Hidden Markov Models[1].
It was apparently used to great effect by a company, Thorn Technologies, and they've mentioned their experience here : http://www.thorntech.com/2013/07/mobile-device-3d-accelerometer-based-gesture-recognition/
Alternatively, you could consider FastDTW (https://code.google.com/p/fastdtw/). It's less accurate than regular DTW[2], but also computationally less expensive, which is a big deal when it comes to embedded systems or mobile devices.
[1] https://en.wikipedia.org/wiki/Hidden_Markov_model
[2] https://en.wikipedia.org/wiki/Dynamic_time_warping
EDIT: The OP has mentioned in one of the comments that he completed his project, with 90% accuracy in the field and a sub-millisecond compute time, using a variant of $1 Recognizer. He also mentions that rotation was not a criteria in his project.
What hasn't been mentioned yet is the actual gesture recognition. This is the hard part. After you have cleaned up your data (low pass filtered, normalized, etc) you still have most of the work to do.
Have a look at Hidden Markov Models. This seems to be the most popular approach, but using them isn't trivial. There is usually a preprocessing step. First doing STFT and clustering the resultant vector into a dictionary, then feeding that into a HMM. Have a look at jahmm in google code for a java lib.
Adding to moonshadow's point about having to reset your baseline for gravity and rotation...
Unless the device is expected to have stable moments of rest (where the only force acting on it is gravity) to reset its measurement baseline, your system will eventually develop an equivalent of vertigo.