I have built and installed HelloSensor sample app on my Android/SmartWatch2 devices.
After commenting //sensor.getType().getName().equals(Registration.SensorTypeValue.MAGNETIC_FIELD)
to avoid accelerometer values display to be scratched by magnetic field values display, I was very happy with the result: I clearly saw the expression of "SW2 acceleration - gravity" displayed on my SmartWatch (clearly seeing ~(0, 0, 9.8) when the watch is layed down on a table, and ~(0, 9.8, 0) when I hold the SW vertically).
My problem is that, today, whatever orientation I give to my SmartWatch, values do not change anymore => ~(0, 0, 9.8) is always displayed, even if I hold the SW vertically.
Since it worked fine at first, I wonder if my sensor is not "broken". How can I check this?
Did you try restarting and/or resetting your SW2? Also you can try unpairing/repairing the watch with the phone.
If it still isn't working, not sure there is much you can do to check the sensor otherwise. If your watch is still under warranty would suggest sending it in for repairs.
Related
I'd like to test android's behavior on all possible combinations of the following "inputs":
top activity's setRequestedOrientation() (15 possible values, not including SCREEN_ORIENTATION_BEHIND)
Settings.System.ACCELEROMETER_ROTATION (2 possible values)
Settings.System.USER_ROTATION (4 possible values)
device's physical orientation (queryable by OrientationEventListener) (4 possible quadrants)
Specifically, I want to see how the inputs affect the following "output":
getWindowManager().getDefaultDisplay().getRotation() (4 possible values)
So this will require testing at least all 15*2*4*4=480 possible input states.
Additionally, since rotation behavior is often dependent on the history
of the inputs (not just the current input values),
I want to test (at least) all possible transitions from one input state to an "adjacent" input state,
i.e. to an input state that differs from the given input state by one input parameter.
The number of such input state transitions is:
(number of input states) * (number of states adjacent to a given input state)
= (15*2*4*4) * ((15-1) + (2-1) + (4-1) + (4-1))
= 480 * 21
= 10080
Furthermore, sometimes output is dependent on the previous output as well as previous and current
input (e.g. SCREEN_ORIENTATION_LOCKED, SCREEN_ORIENTATION_SENSOR_LANDSCAPE).
The number of possible outputs for a given input state can be between 1 and 4,
so this multiplies the number of transitions that must be tested by up to 4:
10080 * 4 = 40320
That's a lot of transitions to test, so the testing would have to be programmatic/scripted.
Three out of the four input params are straightforward to control programmatically;
the one that's not straightforward to control is the device's physical orientation.
So, how would one go about scripting it? I can think of the following approaches.
Approach #1: Replace the (physical or emulated) device's accelerometer with a scriptable mock accelerometer
for the duration of the test. But, if I understand correctly, mock accelerometers do not exist for android.
Approach #2: Use the android emulator, and script pressing of the "rotate counterclockwise" and
"rotate clockwise" buttons using an interaction automation tool on the host machine (e.g. applescript / autohotkey / xdotool).
Any other ideas?
It turns out this is actually a duplicate of the following excellent question:
How can i simulate accelerometer in android emulator?
which has this excellent answer from #user1302884 :
Unfortunately, that question got no respect and was closed as off-topic (?!) so I won't mark this as a duplicate.
But here's the answer: no need for applescript/autohotkey/xdotool to drive the emulator's ui;
instead, telnet to the emulator and tell it which direction you want "up" to be.
telnet localhost 5554 # or whatever the port is
telnet> sensor # to get help on the sensor command
telnet> sensor get acceleration
acceleration = 0:9.81:0 # if in natural orientation
telnet> sensor get acceleration
acceleration = -9.81:0:0 # if rotated 90 degrees CW from natural orientation
telnet> sensor set orientation -1:1:0 # to set to 45 degrees CW from natural orientation
It would be nice if the emulated display would appear rotated by the specified number of degrees in response, but you can't have everything.
I am using an input processor for touchinput on a flappy bird like game. This works fine on my droid turbo, and a couple other newer phones. But with my two older tables, a xoom, and verizon tablet, touchDown occasionally doesn't fire. I should mention that the FPS is 60 throughout gameplay. Also, I use an inputMultiplexer which adds both the playerInput and hud/play stages. Could this just be a problem with older android? Any fix? I am sure it's not my code for the fact that it works on newer phones.
EDIT
I tried using Gdx.input.isTouched like so :
if(Gdx.input.isTouched()){
if(!touched){
jump();
}
touched = true;
} else{
touched = false;
}
But it gives me the same results as input processor :\
This is not a problem with the jump method, as of right now it just prints "touched" to the console.
it is the issue with the viewPort. that is the different phone has different screen size. please check the below link which will help you
http://stackoverflow.com/questions/39810169/libgdx-text-not-rendering-properly-on-larger-screens/39946652#39946652
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.
I'm interested in AR applications of mobile devices and naturally I would like to make better use of the compass.
The only issue I've been having to work against isn't how twitchy the compass is. (Angular Smoothing seems to solve this issue just fine) My main issue is that when the device is held Vertical the compass values start freaking out. Causing an on screen compass to flip about all over the place. I don't have a lot of experience with mobile application development so I'm not sure what would be causing this issue, if its a Unity issue or if its just a limitation of the digital compass. I know other apps do seem to be able to use the compass fine in any orientation, but this is all stupidly new to me.
I've definitely tried moving the phone in a figure of 8. The device I have to play around with is a Nexus 4.
using UnityEngine;
using System.Collections;
public class Compass : MonoBehaviour {
// Use this for initialization
void Start () {
Input.location.Start ();
Input.compass.enabled = true;
}
// Update is called once per frame
void Update ()
{
var heading = Input.compass.trueHeading;
transform.eulerAngles = new Vector3 (0, 0, heading);
}
}
Preamble :)
First of, I'm not an expert (unfortunately) in subjects that I will talk about. But still, I've decided to share my thoughts.
Theory
The problem can be generalized in the following way. You want to have some continuous function that takes a 3D vector (which is device orientation in your case) and returns another vector that is orthogonal to original vector. Theory says (see hairy ball theorem) that for some arguments that function will return zero vectors. In case when such a function is compass, zero vectors are returned when device is oriented vertical (and this fells quite natural if you have ever used an ordinary compass).
Practice
Sometimes you want your app to tell which side of the world does phone back (rear camera) is pointing to.
Or maybe even you want combined approach:
If the phone is oriented flat, show what is the phone's top pointing to.
If the phone is oriented vertical, show what is the phone's back pointing to.
In both cases you need to use gyroscope in addition to compass.
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.