r00tat / wificompass

Automatically exported from code.google.com/p/wificompass
9 stars 10 forks source link

Step Detection #11

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Describe the task:
Research, design and develop a step and direction detection system, which 
allows a user to navigate through an indoor room. 

Also developed by Uni Aachen:
http://www.comsys.rwth-aachen.de/research/projects/footpath/
http://www.umic.rwth-aachen.de/uploads/media/2012-MWC-Flyer-FootPath.jpg

and before by the Swedish Hansson and Tufvesson begining from page 40

Original issue reported on code.google.com by paul.woe...@gmail.com on 4 Mar 2012 at 5:43

GoogleCodeExporter commented 9 years ago
Source of Footpath could be found at https://github.com/COMSYS/FootPath

Original comment by paul.woe...@gmail.com on 4 Mar 2012 at 6:15

GoogleCodeExporter commented 9 years ago
This issue was updated by revision r103.

started to implement StepDetection with base code from footpath

Original comment by paul.woe...@gmail.com on 20 Mar 2012 at 9:40

GoogleCodeExporter commented 9 years ago

Original comment by paul.woe...@gmail.com on 20 Mar 2012 at 9:42

GoogleCodeExporter commented 9 years ago
This issue was updated by revision r114.

added popup info to north drawable with relative degrees
angles of drawable are no always in the range 0 to 2*PI
checked calculation of steps, implemented in r112, looks fine

Original comment by paul.woe...@gmail.com on 1 Apr 2012 at 4:31

GoogleCodeExporter commented 9 years ago
update from r128
added Step Size to Calibrate Sensors

Original comment by paul.woe...@gmail.com on 21 Apr 2012 at 10:44

GoogleCodeExporter commented 9 years ago
This issue was updated by revision r130.

when starting step detection, wifi scans are also started every 3 seconds. If 
we receive a result before 3 seconds, we just save the result and don't start a 
new one, because we don't want to have to frequent results. If we don't receive 
a result in time, we try to remind the driver, we wanted to get a result. Maybe 
it helps. 

On a Samsung Galaxy Tab 1000 with only a few (1-2) WiFi networks around, the 
driver does not return any results even after minutes. This seams to be device 
and driver related. We can't affect this, but we send the asynchronous start 
scan to the wifiservice. 

If you are in a location with more wifi networks, the scanning with the Samsung 
GT1000 works fine though. 

Original comment by paul.woe...@gmail.com on 28 Apr 2012 at 10:18

GoogleCodeExporter commented 9 years ago
This issue was updated by revision r141.

Created an sensor auto configuration wizard.
The user has to walk arround and tab on the device on every step. An algorithm 
tries to find the best suitable paramters for the user and the specific device.

Original comment by paul.woe...@gmail.com on 11 May 2012 at 8:25

GoogleCodeExporter commented 9 years ago
This issue was updated by revision r142.

copied StepTrigger to UserLocation Package, renamed some methods. 
CalibratorActivity: set rewards and punishments as static variables and do not 
forget the last step

Original comment by paul.woe...@gmail.com on 12 May 2012 at 10:15

GoogleCodeExporter commented 9 years ago
This issue was updated by revision r148.

tested on Android 2.2 device, function call changed, because String.isEmpty 
does not exist in Android 2.2. 
Changed PaintBoxHistory from a SurfaceView to View and now update the view 
every 25ms and not with a separate thread without any delay. Should perform 
better on slow devices.

Original comment by paul.woe...@gmail.com on 12 May 2012 at 8:05

GoogleCodeExporter commented 9 years ago
This issue was updated by revision r149.

Added auto calibration for low performance devices. The graph could be toggled, 
so now CPU must be used to process the graph.

Also changed some strings from Wi-Fi to WiFi

Original comment by paul.woe...@gmail.com on 13 May 2012 at 10:35

GoogleCodeExporter commented 9 years ago
do'h, typo: I mean no CPU, not now ...

Original comment by paul.woe...@gmail.com on 13 May 2012 at 10:37

GoogleCodeExporter commented 9 years ago
This issue was updated by revision r150.

changed the auto configuration sensor data to be not persistent. Now it also 
works on a ZTE blade.

Original comment by paul.woe...@gmail.com on 13 May 2012 at 11:21

GoogleCodeExporter commented 9 years ago
This issue was updated by revision r151.

synchronize the step and sensor data arrays. On a Galaxy S 2 sensor data was 
wrote, after the auto calibration ended and calculation started. This should 
not happen, because autoCalibrationRunning is false. To be sure this does not 
appear again, the Async task sychronizes on the two arraylists.

Original comment by paul.woe...@gmail.com on 14 May 2012 at 10:59

GoogleCodeExporter commented 9 years ago
This issue was updated by revision r166.

compass values had been incorrect, so the position was calculated wrong. Fixed 
this by using CompassMonitor.

Original comment by paul.woe...@gmail.com on 16 May 2012 at 5:06