Develop Reference

Accelerometer QML

Attempt to measure distance based acceleration (accelerometer mobile). If that's true
Accelerometer {
id: accel
dataRate: 1000 / 25
onReadingChanged: {
console.log(reading.x, reading.y, reading.z);
}
}
In console
D/libsensor.so(16533): qrc:/main.qml:20 (onReadingChanged): qml: 1.359906554222107,8.791508674621582,-0.4405331015586853
Now when you display information and having the mobile completely still (motionless). Shows acceleration in all axes, which is absurd! You have any idea why?

That's certainly not absurd.
According to Einstein's widely accepted (but still disturbing) theories, your phone can't tell if it's sitting still on planet Earth or accelerating inside a spaceship in deep space - that's called the "equivalence principle". So it's just assuming it's in an accelerating spaceship, because why not ? And that's so much cooler, don't you think ?
If you're near (or on) a planet and reading a zero acceleration, that's bad news, because that means you're freefalling in the distorted spacetime around the planet, and you're probably about to hit something.
You're reading an acceleration of about 9m/s^2, which is close to Earth's g value, so that's approximatively right, depending on your phone orientation. Maybe the accerelometer calibration is not quite right, you can test it with a dedicated application, if you've not done it already. NB Some apps will compensate for the gravity of Earth.
Of course, there's also the possibility of bugs in the phone or in Qt or in your code, or hardware failure, but you have to know what to expect.
Hope that helps.

How to avoid sluggish d3 force layout on Android?

We're using a d3.layout.force on a web app, and I've been investigating a bug report that it is sluggish on Android: it feels like the nodes are in oil, compared to how it works on desktop browsers, or iOS.
(By the way, we only ever have between 4 and 9 nodes, and the sluggishness does not feel different between 4 and 9.)
We set size(), linkDistance() and charge(); so we're using the defaults for friction, theta, alpha, gravity, etc. I experimented with these to try and reproduce the effect on desktop, but couldn't. (friction(0.67), instead of default of 0.9, was closest, but still felt different, somehow.)
I then set up an FPS meter (based on calls to the tick() function). We get 60fps on desktop, and it seems in the 40s and 50s on an ipad. But on Android Chrome (on a Nexus 7) it seems capped at 30fps, and is often half that. Android Firefox was in the 20s normally, but sometimes into the 30s.
So, is it a reasonable hypothesis that are Android devices are just slower? Could there be a cap of 30fps in Android Chrome?
Then how can I fix this? I believe d3.js uses requestAnimationFrame(). Often animation libraries take the time between calls to requestAnimationFrame() to decide how far to move objects (so when the CPU gets overloaded the animation becomes jerkier, but takes the same amount of time to complete). But it appears that d3.js does not do this, and moves everything the same amount by tick, not by elapsed time. What can I do about this?
(Ideally I'd like a solution based on how slow/fast the machine is, rather than having to sniff the browser.)

Curiously, adding more calls to force.tick() in my own requestAnimationFrame() handler (see https://stackoverflow.com/a/26189110/841830), does increase the FPS. That suggests it is not CPU bound, but instead a limit that Android is enforcing (perhaps to save battery?).
Here is the code I'm using, that tries to adapt dynamically to the current fps; it ain't beautiful but seems to be getting the job done in my test android devices, without changing the behaviour in iOS or desktop.
First, where you set up the force layout:
var ticksPerRender = 0;
var animStartTime,animFrameCount;
force.on('start',function start(){
animStartTime = new Date();animFrameCount=0;
});
requestAnimationFrame(function render() {
for(var i = 0;i < ticksPerRender;i++)force.tick();
if(force.alpha() > 0)requestAnimationFrame(render);
});
The above does two things:
sets up the fps counter
sets up our own animation callback, which does nothing by default (ticksPerRender starts off as zero).
Then at the end of your tick handler:
++animFrameCount;
if(animFrameCount>=15){ //Wait for 15, to get an accurate count
var now = new Date();
var fps = (animFrameCount / (now - animStartTime))*1000;
if(fps < 30){
ticksPerRender++;
animStartTime = now;animFrameCount = 0; //Reset the fps counter
}
if(fps > 60 && ticksPerRender >= 1){
ticksPerRender--;
animStartTime = now;animFrameCount = 0; //Reset the fps counter
}
}
This says that if the FPS is low (below 30), do an extra call to tick() on each animation frame. And if it goes high (over 60), remove that extra call.
Each time ticksPerRender is changed, we measure the FPS from scratch.

Android - Camera flash light blinking in wrong intervals in different devices

I am developing an app, in which I want to blink the flash light in specific interval.
Below are the steps I have followed.
1) Set the Timer for specific interval.
2) In run() method i did the code for TurnOn and TurnOff flash.
But the interval of flash blinking is different on different devices. The timer time is same for all devices, I have also put a Log in between, I am getting same values but, still the problem is there.
Is it a Hardware issue, because the hardware is different for different devices. I have also tested in iPhone 5s (By converting same code in iOS) but, the flash blinking is much faster than Android.
For Android, I have tested on Nexus 4, Motorola G2, Sony Xperia Neo and it is working fine.
Problem is with Nexus 5 and Samsung Galaxy S4.
EDIT
Code of Timer :
long delayLong = 200;
long timerValueLong = 500;
Timer timer;
timer = new Timer();
timer.schedule(new TimerTask() {
#Override
public void run() {
if (!mLightOn) {
turnOnFlash();
} else {
turnOffFlash();
}
}
}, delayLong, timerValueLong);

This is an older problem, but the problem still persists today so I'll post how I solved this.
The problem is that the call to turn the LED on or off takes variable amount of time to traverse through the Android operating system. The way these calls are handled are phone dependent.
First off you need to measure the time it takes for the LED to turn on and off starting from the time the call to do so. Use the input from the camera, keep the phone close to a surface and measure the change in brightness in the frame. You can use glReadPixels if working with OpenGL and read out the center line only each frame. You will need to make multiple measurements, as the call can be shorter or longer depending on the state of the OS. Preferably you'd want to have no buffer or a fixed buffer of frames, so timing of the frames is reliable (which might not be the case with compression). I used OpenGL and a SurfaceTexture and this is a snappy way.
You now know the minimum(1) and maximum(2) time it takes for the call to traverse the OS. Using this information you can make the LED blink as fast as possible on the phone. To truly get the most out of it, start the second call to the flash before maximum(2) time has passed; maximum(2) - minium(1).
Using the last trick, the speed of the flashing is mostly dependent on the difference in minimum and maximum time of the call traversal. This is typically very different per phone, from 10ms to 100ms+.
Also note that because the measuring of the call traversal time happens with the camera, times are rounded up/down to 33ms segments (#30fps).

I had the same issue with the flashlight and the problem is not related to the Timer. It is about how you are turning the flash on and off. On some devices like Nexus 5, you have to have and use a SurfaceView inside of your layout. It would be useful to show us the methods you are using for turning the flashlight on and off.

long delayLong = 20;
long timerValueLong = 100;
Timer timer;
final Parameters p = camera.getParameters();
timer = new Timer();
timer.schedule(new TimerTask() {
#Override
public void run() {
if (!isLighOn) {
p.setFlashMode(Parameters.FLASH_MODE_ON);
p.setFlashMode(Parameters.FLASH_MODE_TORCH);
camera.setParameters(p);
isLighOn = true;
} else {
p.setFlashMode(Parameters.FLASH_MODE_OFF);
camera.setParameters(p);
isLighOn = false;
}
}
}, delayLong, timerValueLong);

Maybe you can try to use Alarm functions like:
https://developer.android.com/training/scheduling/alarms.html
https://developer.android.com/reference/android/provider/AlarmClock.html
your can set repeat period for alarm. make 2 alarms, one for On and one for Off.
Even phone has hard working, alarm will work depending on clock time. so maybe it will not Off and twice On by error, but solution will be same.
and also you are using 200 milliseconds. it's hard for device catch such small time interval. maybe you'll try to increase you time intervals?

Gyroscope does not show any drift

I'm in a little bit weird situation. The situation I currently have is typically a good one - no gyro drift at all - but I have no clue why this is the case. I expected the gyroscope to drift a lot as reported everywhere. Therefore this question to find the reason why I do not see any drift.
I use a Galaxy Nexus (Android 4.0.3) and its gyroscope to do some orientation change detection in the end. In the first place, I just wanted to log the sensor readings and expected to see large drifting values as for example here. Also on other websites I read of drifting of about 1 degree per second or similar measurements.
My code to log the sensor data is very basic:
SensorManager sm = (SensorManager) getSystemService(SENSOR_SERVICE);
LogSensorEventListener listener = new LogSensorEventListener(
SensorLoggerActivity.this, Sensor.TYPE_GYROSCOPE);
sm.registerListener(listener, sm.getDefaultSensor(Sensor.TYPE_GYROSCOPE),
SensorManager.SENSOR_DELAY_FASTEST);
LogSensorEventListener is also a very basic implementation of the SensorEventListenerInterface:
#Override
public void onSensorChanged(SensorEvent event) {
final float dT = (event.timestamp - mTimestamp) / 1000000000.f;
if (dT < 1) { // just a fix for the first step
mRelZ += event.values[2] * dT;
list.add(mRelZ);
list2.add(event.timestamp);
}
mTimestamp = event.timestamp;
mRelZ is initially set to 0 and the two lists should keep track of time and measured value. If finished with my measurement (clicking a button) the values are written to file:
try {
for (int i = 0; i < list.size(); i++) {
long time = list2.get(i);
if (mStartTime < 0) {
mStartTime = time;
time = 0;
} else {
time = time - mStartTime;
}
float timef = time / 1000000000.0f;
sb.append(timef);
sb.append(";");
sb.append(Math.toDegrees(list.get(i)));
sb.append("\n");
}
mOutFileStream.write(sb.toString().getBytes());
mOutFileStream.flush();
mOutFileStream.close();
} catch (IOException e) {
}
Everything works fine but the only drift I can see (for example when having the device lying on a table and logging values for let's say 60 seconds) is about 0.2 degree.
If I move the device to get something like in the screenshot above no drift can be observed at all...
What I'm I doing wrong (or right?)??
Thanks for any advice!

the gyro you have might be a post-filtered one, i found this in some of the SAMSUNG I9100 devices. they use gyros produced by INVENSENSE CORP.
edit 2014/12/10 for commenting #Lourenço Castro
i believe #Lourenço Castro was right about the 'factory drift'(or zero-drift) and 'accumulated drift';
Concerning to complementary/kalman filters, on Android, the 6dof(ACC+GYRO) impl. works fine, it can remove both factory and accumulated drift of gyroscope thanks to accelerometer's calibration;
However, the 9dof impl., or adding a magnetometer sensor into consideration, filter runs into status you dont want. According to my tests, it is caused by uncalibed status of magnetometer which need guys to shake (known as drawing 'eight')the phone to remove before fusion.
9dof provides a full rotation estimation while 6dof can not handle the accumulated drift of rotating around y axis(see android's ref. for axis definition). And I dont think that 'shaking-and-drawing-number-8' before one starts an app is a good UE, so we have to go back to 6dof method and try to find a way to remove factory drift of rotation around y-axis.
(a lot of boring but amazing content about complementary/kalman filter should be here. but i guess those come here already know it.)
You can try a 360 panorama app included in Google Camera which can be downloaded from market. This app use a visual-aid(image processing based motion estimation) for calibrating the sensor before we really start to capturing, it's easy to verify this. And no use of Magnetometer, i guess.
So my advice to use sensor-fusion on Android is:
1. no magnetometer; (dont know if this is a hardware problem or can be solved by software.)
2. accelerometer+gyroscope provides smooth and stable 6dof motion estimation;
3. try to solve the drift around y-axis, mainly means that visual-method should be added to;
4. try 3 and try 3...
Maybe someone will run into this question and i hope all above might be helpful.
thanks to those posts related to this questions on StackOverflow.
i dont remember your names exactly but you all helped me a lot. :)

I was browsing for this subject and, although this is an old question, I don't believe the accepted answer is correct.
The drift that is "reported everywhere" is caused by the integration of noisy gyroscope data (as seen on the link provided by the O.P.), not by simply outputting the sensor data. You will need this integration to calculate orientation changes over time.
Longer integration periods will contain larger noise amounts which will accumulate drift fairly quickly. I believe the internal filtering of the signal which happens on Invensense hardware is used to remove drift caused by their own pre-processing of the gyroscope.
In Android's case, in API 18 (Jelly Bean MR2), a GYROSCOPE_UNCALIBRATED sensor was added, in which you can (presumably) verify this factory drift calibration. Anyway, when you try to integrate either the calibrated and uncalibrated sensor events, you will get drift, since both are pretty noisy. To reduce this issue you will have to delve into complementary or Kalman filters.
(Sorry about not posting more informational links, not enough reputation).
Hope this helps future users.

Detect if the Person falls down

I am creating an app in android where i need to detect if the person has fall down. I know that this question has been asked and answered as to use vector mathematics in other forums but i am not getting the accurate results out of it.
Below is my code to detect the fall:
#Override
public void onSensorChanged(SensorEvent arg0) {
// TODO Auto-generated method stub
if (arg0.sensor.getType()==Sensor.TYPE_ACCELEROMETER) {
double gvt=SensorManager.STANDARD_GRAVITY;
float vals[] = arg0.values;
//int sensor=arg0.sensor.getType();
double xx=arg0.values[0];
double yy=arg0.values[1];
double zz=arg0.values[2];
double aaa=Math.round(Math.sqrt(Math.pow(xx, 2)
+Math.pow(yy, 2)
+Math.pow(zz, 2)));
if (aaa<=6.0) {
min=true;
//mintime=System.currentTimeMillis();
}
if (min==true) {
i++;
if(aaa>=13.5) {
max=true;
}
}
if (min==true && max==true) {
Toast.makeText(FallDetectionActivity.this,"FALL DETECTED!!!!!" ,Toast.LENGTH_LONG).show();
i=0;
min=false;
max=false;
}
if (i>4) {
i=0;
min=false;
max=false;
}
}
}
To explain the above code i have used the vector sum and checking if the value has reached below or equal to 6(while fall) and suddenly greater than 13.5(while landing) to confirm the fall.
Now i was been told in the forums that if the device is still the vector sum will return the value of 9.8. While fall it should be close to 0 and should go to around 20 while landing. This doesn't seem to happen in my case. Please can anybody suggest if i am going wrong anywhere?

There is a guy who developed an android app for that. Maybe you can get some information from his site: http://ww2.cs.fsu.edu/~sposaro/iFall/. He also made an article explaining how he detected the fall. It is really interesting, you should check it out!
Link for the paper: http://ww2.cs.fsu.edu/~sposaro/publications/iFall.pdf
Resuming, the fall detection is based on the resultant of the X-Y-Z acceleration. Based on this value:
When falling, the falling generally starts with a free fall period, making the resultand drop significantly below 1g.
On the impact on the ground, there is a peak in the amplitude of the resultant, with values higher than 3g.
After that, if the person could not move due to the fall, the resultant will remain close to 1G.

Following will happen if person / phone falls down:
absolute acceleration vector value goes to 0 ( with some noise of course )
there will be fair spike in absolute vector value on landing ( up to maximal value provided by accelerometer )
When phone is immobile, you have vector of modulo earth gravity pointing up
Your code is basically correct, but I would use some averaging because accelerometers used in phones are cheap crap - noisy and lacking precision

To add averaging to your signal means:- moving average. It depends on your windows size. For example. Say I have a one vector with the following numbers: 1,2,3,4,5,6. and my window size is 2. Then the moving average is to take every two numbers from your vector and average them by 2. So you would take 1+2/2, and then move one to the next twos. 2+3/2, and so on.