I am developing an Android app that records the inertial data on a smartphone to then further processes it. Different Android devices have different behaviors depending on the firmware interfacing the inertial sensors to Android and that's crystal clear. One thing I cannot answer myself though is, how come only the moto g 2nd gen yet showed that when the app is recording I have significantly different numbers of sensors samples?
For example, few second of recording and I see:
~6000 samples for the gyro
~5200 samples for the acc
~2000 samples for the magnetometer
Assume as well that the activity I am recording affects all sensors at all time and hence I'd expect the onSensorChange function to be called evenly. That happens for every other smartphone I tried (5 or 6 different ones).
Any suggestions how come the magnetos mostly seem to not change values as often as the other sensors in order for the onSensorChange to record it?
The obvious answer is because of the firmware, but do you have any idea how to mitigate the effect I am seeing?
Thanks folks!
This question is really old, but I figured I'd answer it for the community's sake:
I work as an app developer at a startup that specializes in sensor processing on smartphones. We have a couple 2nd Gen Moto G's and we've found that they do a really bad job of giving uniform sampling rates both for one sensor as well as across sensors.
To mitigate the problems, we write a whole row of samples at once with the most recent data, every time we get a sample from the accelerometer. If a new sample hasn't come in on any other sensors since the last accelerometer sample, the same values get printed twice.
ie.)
Accel (3-axis) | Gyro (3-axis)
0,0,0|0,0,0
<new accelerometer sample>
1,1,1|0,0,0
<5 gyro samples and 1 accelerometer>
2,2,2|5,5,5
...
Anyways, hope this helps someone!
TLDR; The 2nd Gen Moto G has inconsistent sampling rates both for one sensor and across multiple sensors.
Related
I'm working on Sensor fusion with Accelerometer, Gyroscope and Magnetic Field on Android. Thanks to SensorsManager I can be noticed for each new value of theses sensors.
In reality and this is the case for my Nexus 5 (I'm not sure for others Android devices), acceleration, rotation rate and magnetic field are sampled in same time. We can verify it using event.timestamp.
On others systems (like iOS, xSens...), Sensor SDK provides a notification with these 3 vectors in same time.
Of course, when I receive an acceleration(t), I can write some lines of codes with arrays to wait rotationRate(t) and magneticField(t). But if there is a way to have an access directly to these 3 vectors together it could be very interesting to know!
An other question relative to sensors data:
Is there advices from Android team to device constructors to provide data in chronological order ?
Thank you,
Thibaud
Short answer, no, Android doesn't provide a way to get all the sensor readings as it reads them.
Furthermore, the behavior that you've observed with SensorManager, namely that readings from different sensors happen to have the same timestamp suggesting that they were read together - should not be relied upon. There isn't documentation that guarantees this behavior (also, this is likely a quirk of your testing and update configuration), so relying upon it could come to bite you in some future update (and trying to take advantage of this is likely much more difficult to get right or fast than the approach I outline below).
Generally, unless all results are generated by the same sensor, it is impossible to get them all "at the same time". Furthermore, just about all the sensors are noisy so you'd already need to do some smoothing if you read them as fast as possible.
So, what you could do is sample them pretty quickly, then at specific intervals, report the latest sample from all sensors (or some smoothed value that accounts for the delta between sample time and report time). This is a trivial amount of extra code, especially if you're already smoothing noisy sensor data.
There is a workaround for this particular problem. When multiple registered listeners are present in an activty at the same time, timestamp for those event may be misleading. But you can multiple fragment objects into the said activity which have different context's. Then listen to every sensor in these fragments. With this approach the sensor reading timestamps become reliable.
Or listen in parallel threads if you know about concurrency...
I have observed the accelerometer data in several android devices are different in same place with same orientation.
I am developing a game based on accelerometer X and Y data and it is working fine with tablet, but unusual result in android phones.
Please suggest to overcome this issue.
Thanks,
Biplab
This is natural because every device has different hardware specifications, that means that they also have different accelerometer implementations each having different noises in their readings. Even the time bettween two consecutive polls intitialized with the same sensor delay flag (such as SENSOR_DELAY_GAME) will probably differ in different devices. I suggest you apply filtering in your data for smoother readings.
See here for low pass filter.
See here for high pass filter.
The examples are not in java but they will give you the idea.
I was trying to port Sebastian Madgwich's sensor fusion algorithm ( http://www.x-io.co.uk/node/8 ) to Android, but the first results seem not to be correct, and the resulting quaternion is moving everywhere when the phone is steady. One of the problem might be that I'm not able to sample at the same time the three sensors (gyro, accelerometer and magnetometer), but it looks like Android sensor manager doesn't allow to do so.
Did anybody succeeded in porting the algorithm with more success?
thanks in advance
I haven't implemented this in Android, but I have it working on an iPad 2 for an augmented reality application i'm working on for my MSc thesis. To get it working smoothly I found that it's best to set the update rate for the sensors inline with the frame rate (so, 30hz for me), but it's probably worth experimenting to see what's best for your device.
I'm not sure exactly what you mean by flying everywhere, but sensor drift will probably cause a noticeable amount of error - my objects slowly rotate randomly when the device is at rest. Very annoying, but something you have to accept when using IMUs.
Also, make sure you update the quaternion after you have a new reading from all of the sensors, instead of ofter each sensor gets a new reading separately.
I'm working with android sensor data. My application use
SensorManager.getRotationMatrixFromVector(
mRotationMatrix , event.values);
and it has been working well until this morning, when the rotation matrix started to send a lot of noise data (Change N to W in a second).
It's not a problem with my code, because on friday was working and no changes have been done. I have used a compass app from the market, and the compass is giving random data.
I have tested my app on another tablet, and it is working well.
Does someone know why is this happening? A problem with the sensor? Does it need a calibration?
I've worked quite a lot with these electronic compasses on mobile phones and its quite possible that there is nothing wrong with your code or sensor.
Instead it could very well be a problem with your environment. There are magnetic fields interfering with the earth's magnetic fields all the time. From electrical equipment interference to the metal structure holding up a building. At the end of the day a compass is just a magnet. If you stand beside a large lump of metal the compass will be attracted to it and point to it rather than the magnetic north pole.
Try this:
Install GPS status
then turn off all filtering (settings... gps & sensors...sensor filtering... no filtering).
Do the calibration (figure of 8 wavy stuff) and then move the phone around your desk.. near monitors, cables, etc. You'll see it go crazy. The information is completely unreliable. I found in the past that moving the phone a few inches to the right completely changed its reading. The same happens with a real compass. Strictly speaking there is no "problem". The device's compass is assigning itself with the strongest magnetic field. Even the magnetic content of nearby rocks can interfere with the compass.
As a further test I've just placed a real (orienteering) compass over my phone which has a compass app installed. The real compass is now pointing everywhere but magnetic North. The two devices are interfering with each other.
So my advice is.. go somewhere in the open, like a park or field, away from any potential interference and power lines, (if you have one bring a real compass to check that the GPS status app is pointing the right way), and see if your compass works as you'd expect.
Extra: The answer from #resus is also important when calibrating. Rotate the phone a few times in each axis. Looks silly but it does calibrate it properly.
Extra 2: Would it be possible/practical to use the compass bearing of your GPS? It would require that the device be moving (walking speed should be fine) but you would not need to worry about any interference. It should give an accurate reading provided your GPS signal is good.
Extra 3: Another thought just occurred to me.. You could try apply a low pass filter to the sensor. This means that the sudden changes in the sensor reading are filtered out .. have a look at this answer. And if that doesn't do a good job there are lots of algorithms on the web for you to choose from.
If you definitely haven't changed anything in your code, and it still works fine on other devices, it would suggest a problem with that particular device.
While your app is running (i.e. the compass is in use), you should be able to wave it in a figure of 8 in order to automatically recalibrate the compass. You should also make sure you aren't standing next to any large lumps of metal etc. that might interfere with readings.
You can override the onAccuracyChanged() method of SensorEventListener to flash up a message to the user when the compass requires recalibration (probably when accuracy drops to SENSOR_STATUS_ACCURACY_LOW).
In my experience of playing with the compass on android phones, they can be pretty unreliable...
If your application work on another tablet and other compass application do not work on your device, this is probably due to a bad calibration.
As said in the post above, to make the calibration, wave your device in a figure of 8. I just want to add that you should do it for EACH axis. This should fix your problem.
If it is not a calibration error, as some people have already answered, it is possible that the compass had gone through a magnetic field and now it is desmagnetized, so it is not working properly.
Where do you usually keep the tablet? Could it be that it was near big servers or magnets?
You should check the compass just in case, talk to to android's tech support.
Hope it helps.
I think the question was if calibration could be done without sending any data to compass. Because not everybody says that the compass is calibrated as shown in this video: https://support.google.com/maps/answer/6145351?hl=en and obviously you can not do anything else than advise the user to calibrate before using the program or when you get too much changes.
For example going left and right 90 degrees in about 25 ms.
Anyway I think it's good to give some seconds to the app before start taking data, because it gives some unstable values (too high and low in short time without movement) at the app loading moment.
Just let the handler onSensorChanged() coded with a conditional, and start a thread on the onCreate() handler, which will set a boolean to true, after some seconds.
Then you start to capture data on the onSensorChanged() handler.
Also this thread can help to detect the sensor accuracy, and then you can popup: In Android can I programmatically detect that the compass is not yet calibrated?
I know because I am building a robot using the compass of the smartphone, and I'm having this experience. So, if you are making a robot, make sure to give an spaced place between electronics and hardware to the smartphone, but remember that it's on any compass: electromagnetic fields can be altered by metals so heavily.
Nowadays I have the luck of developing a robot with an HMC-5983 and an MPU-6050, which can be calibrated by using its libraries with Arduino.
That code is compatible/portable to other uController but for not also so easy for smartphones, I guess that the offsets needed for calibrating the compass, the gyro and the accelerometer are inside some internals of Android, not available in the SDK.
I answered before thinking that maybe calibration was only for some devices, but realized that must be as I said before.
So, if playing with robots its possible, I mean it's also easy, but when using an smartphone maybe some custom firmware as CyanogenMod would bring the possibility of investigating the way of setting that offsets, but more important to run some program ported from sketch (following its concept only) to get them first ...
So, good luck ! What is also true, is that in both devices (smartphone and my robot) it's need to move them for them to get working well, as I showed you in the video of latest answer, also helpful on robots.
Good luck and a lot of fun with those things, are very powerful.
I'm working on Android navigation app which uses complex of sensors to determine position changes. In some cases device cannot achieve GPS signal for a while (tunnel or multilevel parking) and I want to compensate these gaps using INS approach.
Yes I know that there're another approaches like cell-id or data got from device's carrier, but currently I'm focused on sensors.
Well, INS approach can be divided into two big tasks:
1. attitude determination (gyro or accelerometer + magnetometer or some combination)
2. velocity and distance calculation. Here I double integrate linear accelerometer values.
Now I try to resolve the second task.
I prepared all calculation and made contrastive analysis of data got from linear accelerometer on different Android devices: Sensation, Motorola Xoom and Nexus S. I put all devices on a platform and moved the platform on 8 meeters with an acceleration on Y axis.
After that I built graphics and they really confused me - all 3 graphics has the same amplitude but peak values are different.
For example at the same moment I have 0.2 m/s^2 on Xoom and 1.2 m/s^2 on Sensation.
Hence after calculation I had a big difference in distance.
Official documentation doesn't explain it. I surfed the web but didn't find any answer about that issue.
So my question is: did someone faced to it? Or maybe you know an advice which will help me to solve it?
In addition, android Sensor class has few parameters. I found that Sensation and Xoom has different RESOLUITON values - Sensor.getResolution().
Sensation - 1.0
Xoom - 0.009576807
I'm stack with it, so any help will be really good!
Thanks in advance.
You cannot solve your second task with MEMS sensors.
You would need a fibre optic gyroscope or a ring laser gyroscope to solve your second task.
Although I talk about calculating position in the above linked answer, the same holds for velocity.