algorithm for step detection and sampling frequency of sensors

[courdi95]

Hello

I had a look to your code and particularly to core.java which integrates all the signal processing on sensors data.

I am just wondering : . Masked code : a lot of code is under comments, what is the purpose of this code ? . Explanation of the algorithm : do you have a document that presents the algorithm ? (reverse engineering is not easy) . It seems that a kind of filtering is done samples ? Low pass ? Which value for cut off frequency ? Which kind of fir or iir ? . It seems that you are doing same filtering without detecting real sampling frequency, but it may be different on various devices (from 50 to 200 hz or 100 hz) : filter coefficients should be different

Best regards.

[Phantast]

First of all, thanks for your interest in SmartNavi!

• the masked code belongs to two different "features". The first method "berechneSchrittfrequenz" was used to determine the frequency in that steps are made. You could use this frequency to increase or decrease the step length of the user. Because if a user walks faster, his step length is automatically longer, vice versa. This has not been implemented yet.
• The two following methods: korrekturAz and berechneSollYBeschl. are historic methods that have been used to correct the azimuth at every sample. This worked well on some devices, but for a more general approach this has been deactivated. So just historic stuff.
• It is a low pass filter and the design is done with the help of this site: http://www-users.cs.york.ac.uk/~fisher/mkfilter/ As you can see in the code I used a LowPassFilter 3. Order - Corner frequency at 0.3 Hz. On the Design Website it is a Butterworth Lowpass Filter.
• You are right that the frequencies can vary on different devices. That is why SmartNavi adapts the filterung frequency every 2 seconds. Have a look at GoogleMapActivity.class at line 1407. There the change method of the core is used every 2 seconds. Same can be found in the OsmMapActivity.class.

Additional Notes: There are many different ways of filterung or correcting the orientation data. You may experiment with your own device to find a good solution. If you think you have a good enhancement for SmartNavi, I would be happy to discuss with you further or to see a pull request on github. ;)

[courdi95]

Hello Martin

Thank you for your answer.

I had a look to the code :

• aclUnit give the number of detection during two seconds
• so changeDelay (aclUnit/2,) gets the number in one second
• the problem is the following ;
  • you begin by applying same filter for devices with freq > 125 (based on a 130 Hz sampling rate value ? indicated in comments line 532)
  • BUT some new devices are using 200 Hz sampling and not 130 Hz, so your filter parameteres are not good ....
  • for example : SAMSUNG GS3, SAMSUNG GS5, or Nexus 5.....
• the other point is the 0.3 Hz cutoff frequency : seems very low .... most of signal could be lost ? have you the frequency response of your filters ?
• the important point is the algorithme in "stepDetection" : could you explain it little ? what are the role of threshold 0.24 and 0.8 ? and the role of "value" ? I have some troubles to understand it.

Concerning sampling frequency you can easily get them with the app "Check the sensors sampling rate" (https://play.google.com/store/apps/details?id=cn.mountqi.sensor.rate.checker). I have only a smartphone with 100 Hz : GS3 mini.

Best regards.

[Phantast]

First of all, I am not Martin. :) Who is that?

• You are right, in the case of a sensor frequency of 200Hz the filter would be for 130Hz. But be aware that the sensors are not running with the fastest speed! Actually, because of the anonymous usage tracking, I can see that the highest frequency reported is 125. If you havn't unchecked anonymous usage tracking, you can be sure that your device is running with max. 125Hz.

For future development of the code, it would be nice if the frequency of the sensors is lowered if it is higher than needed. For example if the meanAclFreq is 125 we should lower down the frequency, because even 25Hz would be fine - and would save even more energy.

• The frequency response can be seen, if you try the link for the filter design in my first answer. Choose a buttworth lowpass filter with 0.3Hz corner freq. The filter is quite heavy, you are right. But pedestrians dont change their direction with a high frequency, as they are not moving fast. This filter is not optimal. You are free to implement your own version. Maybe we can also provide an option for the user to choose between different filtering methods - or even use the gyroscope for better filtering. Feel free.
• Regarding the step detection algorithm, see the attached image. First the algorithm searches for the acl (Y-Axis) to cross a positive threshold. After that the algorithm waits until the correct timeframe has reached. Within the correct timeframe the algorithm looks for the acceleration to cross the negative threshold. So, between the positive and negative crossing, a minimal amount of time (0.24s) and a maximum amount of time (0.8s) has to be passed to make a step more trustworthy. It is impossible for a human to do so fast steps, that you can detect one within a few milliseconds. Thats why the timeframe is important.

[courdi95]

Hello Christian or Phantast,

"Martin" : I don't know him ?!? .... I have made first version of this message on my G Tab, certainly it is the automatic spelling correction that made this trick :-( ....

Concerning algorithm, you are right, I have not checked if the rate was maximum, but I tried smartnavi on my Nexus 5 it gave me so foolish direction that I wanted to check the basic algorithms.

Thank you for the diagram, it will help me understand what it is inside stepdetection().

I will look this. Do you have a figure with displayed signal explaining threshold ? Especially, what are you using only y axis ?

Could you use a combined value of all directions x2 + y2 + z**2 ? But it would give only positive values ?

[Phantast]

Hey courdi, you are getting into it. Keep it up! ;)

• Orientation: The orientation data is only filtered. As I told you, historically it was also corrected, but now the correction is disabled to support more devices.
• Step Detection: SmartNavi uses only the Y-Axis because on this axis the signal is always strong enough to detect your steps. The Y-Axis points roughly towards the ground, because as a pedestrian you hold your device in an angle between flat and 60 degree. A detection on the energy of the acceleration (x^2+y^2...., as you proposed) may also work quite well. But the stepDetection is really the easiest part for pedestrians.

The really difficult task is to compute the direction well. This is even more difficult because in Android we are talking about ~6000 different devices that the app can be downloaded on. And even devices of the same model (e.g. two Galaxy S) may differ because of cheap sensor hardware that is built in.

Just carry on! ;)