Hi Redhunt,
Thanks for your interest in the accelerometer. Without any
acceleration (in outer space or when the phone falls freely), the
values are "0,0,0", showing no acceleration. If you put the phone on a
table, then you will actually see acceleration in the z-direction.
("x,y,z" = "0,0,-1"). The acceleration is nothing else than gravity
that tries to pull the phone down. Now, if you turn the phone upside
down, the phone will think it will be pulled up and hence show
"0,0,+1". If you put it sideways, it may feel the gravity to the side
and show "0,1,0", and so on.
So the numbers tell you the direction in which gravity pulls, and this
changes as you change the position of the phone. Note that this is not
a full orientation sensor, though, because the phone can not say where
north, south, west, and so on are. It can only tell you in which
direction "up" or "down" is, or more precisely, in which direction
gravity pulls.
To test whether the phone is "at rest" on earth, you have to test
whether the length of the vector equals to 1: That is if the
accelerometer shows values "x, y, z", then sqrt(x^2 + y^2 + z^2) == 1
means the phone is at rest in the Earth gravity field. If it is larger
or smaller, then someone else (besides gravity alone) is actively
accelerating the phone.
To test for a "flick", you could remember the current values, and if
they change by, say, more that 20% between two time-steps, then you
have a "flick". Beware though that the values may be slightly changing
all the time in a real sensor by small movements that you don't want
to register in your application. You can use the "Random component"
settings in the Settings pane to simulate sensor noise or small
inaccuracies while holding the phone in a hand.
Hope this helps,
Peli
On Apr 14, 8:45 pm, Redhunt <[EMAIL PROTECTED]> wrote:
> Peli,
>
> I was looking at you Sensor Simulator. VERY Cool !!!
>
> I was hoping you culd help with some thing. What would I be looking
> for if for example I wanted to detect a "flick" of the device in pitch
> and a flick in roll?
> I undestand the orientation stuff. But for acceleration how do the
> sensors work?. I noticed that the simulator shows the accelerometer
> values when you move the device around. But what am I looking at? I
> would have expect the value to go to a certain range, while a force is
> applied and then go back to 0 as the force dies down. Is that even
> correct?
>
> Thanks
>
> On Feb 15, 10:20 am, Peli <[EMAIL PROTECTED]> wrote:
>
> > I've noticed that 4 new functions have been included in Sensors,
> > related tosensorupdate rate:
> > *http://code.google.com/android/reference/android/hardware/Sensors.html
>
> > So there must be someone in the Android team working on that. It would
> > be nice, if that person would also decide on the units for compass,
> > orientation, and temperature sensors and write this into the
> > documentation. In principle, this is arbitrary, but one should make
> > sure that both sides (sensorand software) use the same units:
>
> > Accelerometer:
> > [X] unit 1 = 1g = 9.8 m/s^2.
>
> > Compass: Magnetic field:
> > [ ] unit 1 = 1 nT (nano Tesla)? (typical value: 48000 nT)
> > [ ] unit 1 = 1 µT (micro Tesla)? (typical value: 48 µT) <- I'd prefer
> > this SI unit.
> > [ ] unit 1 = 1 G (Gauss)? (typical value 0.48 G)
> > [ ] unit 1 = value of magnetic field at equator, lon=lat=0? <-
> > dangerous, may vary with time.
>
> > (depending on your position, the magnetic field may vary between 30 µT
> > and 55 µT, and it may vary with time).
>
> > Orientation:
> > [ ] unit 1° (degree)? <- I'd prefer this: easy to read, used in
> > OpenGL.
> > [ ] unit 1 rad?
> > [ ] unit 1 = 180°? (then [-1,+1] would map to [-180°, +180°])
>
> > Temperature:
> > [ ] unit 1 °C (Celsius) <- I'd prefer this, as it simply relates to
> > the SI unit Kelvin.
> > [ ] unit 1 °F (Fahrenheit)
> > [ ] unit 1 K (Kelvin)
>
> > For temperature sensors, it should be avoided that e.g. American
> > hardware producers return "Fahrenheit" while European hardware
> > producers return "Celsius".
>
> > Transforming between any of these units is easy on the software side,
> > but not knowing which unit is being returned is difficult to handle...
> > Alternatively, a new function should be included which returns the
> > unit used (e.g. "nT", "G", "°C", ...)
>
> > Maybe you can quickly contact the hardware manufacturers of the OHA
> > and survey on units, and decide on one. (it should not take longer
> > than a few moments to forward this message to the relevant people).
>
> > Thanks,
> > Peli
>
> > PS: The documentation of the compass
> > (http://code.google.com/android/reference/android/hardware/Sensors.html
> > ) mentions the "degree of magnetic flux (change)", but I think this
> > should be replaced by "magnetic field". The *magnetic flux* would
> > depend on the area of thesensor, and it would *change* only if you
> > move thesensoraround. What you really want to measure is the
> > direction of the magnetic field (which is a vector field).
>
> > On Jan 28, 5:23 am, Peli <[EMAIL PROTECTED]> wrote:
>
> > > Hi,
>
> > > Here is the brand-new SensorSimulator. Please have a look:
> > > *http://www.openintents.org/sensorsimulator
> > > *http://code.google.com/p/openintents/wiki/SensorSimulator
>
> > > I changed the definition of orientation from "radian" to "degree"
> > > because OpenGL uses degree as input, and furthermore many real
> > > orientation sensors seem to give degree as output.
> > > Furthermore, I took "microTesla" as the unit for the magnetic field.
> > > It could be specified using nanoTesla, Tesla, or Gauss instead. So if
> > > you happen to see any specifications on this issue, let me know so
> > > that I can keep the SensorSimulator up-to-date.
>
> > > Peli
>
> > > On 18 Jan., 20:02, Peli <[EMAIL PROTECTED]> wrote:
>
> > > > Hi Dianne,
>
> > > > I'm currently trying to write asimulatorto simulate accelerator and
> > > > orientationsensordata. The idea is to convert mouse movement to
> > > > Androidsensordata. For now I am using the conventions as I outlined
> > > > above. I just wondered, if there were any conventions worked out by
> > > > Google lying around somewhere, so that I could use the correct ones
> > > > right from the beginning...
>
> > > > If it has not been specified so far, I'll just continue with my
> > > > conventions for now and have to adjust them when they become
> > > > available...
>
> > > > It is clear that this will not replace testing things with real
> > > > sensors, but it could give some early feeling of how sensors could
> > > > potentially enhance the user experience and I wanted to play with this
> > > > possibility.
>
> > > > Peli
>
> > > > On 18 Jan., 19:05, hackbod <[EMAIL PROTECTED]> wrote:
>
> > > > > For these things, I don't know if I'd make assumptions about them
> > > > > until there are devices with them. :) Trying to do anything with this
> > > > > data, without running against realsensorhardware, is probably not
> > > > > going result in a very good implementation; this is pretty low-level
> > > > > data.
>
> > > > > On Jan 18, 4:52 am, Peli <[EMAIL PROTECTED]> wrote:
>
> > > > > > Hello,
>
> > > > > > The android.hardware.Sensors
> > > > > > (http://code.google.com/android/reference/android/hardware/Sensors.html
> > > > > > ) currently define the conventions for "accelerometer" and "compass"
> > > > > > accurately, but not yet the conventions for the "orientation"sensor.
>
> > > > > > Can I assume the following (as a working hypothesis) for my
> > > > > > application:
>
> > > > > > The coordinate system with XYZ directions is defined as described
> > > > > > inhttp://code.google.com/android/reference/android/hardware/Sensors.html
>
> > > > > > 1) The three orientation values returned by thesensor"orientation"
> > > > > > indicate yaw, pitch, and roll angles in RADIANS, with values
> > > > > > between -
> > > > > > PI (exclusive) and +PI (inclusive).
>
> > > > > > 2) All three values, yaw, pitch, and roll, equal to "0" (zero)
> > > > > > indicate that the device is oriented in standard position ("lying
> > > > > > flat
> > > > > > on a horizontal surface in front of the user, oriented so the screen
> > > > > > is readable by the user in the normal
> > > > > > fashion",http://code.google.com/android/reference/android/hardware/Sensors.html
> > > > > > )
>
> > > > > > 3) The yaw, pitch, and roll values indicate, how the DEVICE should
> > > > > > be
> > > > > > rotated starting from the standard position in order to reach the
> > > > > > current orientation that is measured by thesensor.
>
> > > > > > 3) Starting from the device in standard position, rotations are
> > > > > > performed in the XYZ fixed coordinate system in the following order:
> > > > > > first the device is ROLLed around the Y axis (positive roll means to
> > > > > > rotate the Z vector towards the X vector), then the device is
> > > > > > PITCHed
> > > > > > around the X axis (positive pitch means to rotate the Y vector
> > > > > > towards
> > > > > > the Z vector), and finally the device is YAWed around the Z axis
> > > > > > (positive yaw means to rotate the Y vector towards the X vector).
>
> > > > > > (If I'm not wrong, this should be equivalent to performing the
> > > > > > following steps in a coordinate system that is moving along with the
> > > > > > device: first yaw, then pitch, finally roll).
>
> > > > > > Note that these definitions DO NOT agree with the definitions
> > > > > > commonly
> > > > > > used in flight dynamics (http://en.wikipedia.org/wiki/
> > > > > > Flight_dynamics), regarding the XYZ coordinate system (e.g. in
> > > > > > flight
> > > > > > dynamics, the Z axis is defined to point downwards.).
> > > > > > But these definitions DO AGREE with the meaning in flight dynamics,
> > > > > > assuming that the Y axis pointing away corresponds to the
> > > > > > longitudinal
> > > > > > axis of a plane:
> > > > > > "The most common aeronautical convention defines the roll as acting
> > > > > > about the longitudinal axis, positive with the starboard wing down.
> > > > > > The yaw is about the vertical body axis, positive with the nose to
> > > > > > starboard. Pitch is about an axis perpendicular to the longitudinal
> > > > > > plane of symmetry, positive nose up."
> > > > > > (http://en.wikipedia.org/wiki/Flight_dynamics
> > > > > > )
>
> > > > > > I think that the definitions given above feel "most natural" for a
> > > > > > device in the given coordinate system, and would be straightforward
> > > > > > to
> > > > > > implement, but of course it is a matter of convention.
>
> > > > > > I would be very happy if some Google member could comment on these.
>
> > > > > > Regards,
> > > > > > Peli
>
> > > > > > PS: are there also hints about the other sensors mentioned on that
> > > > > > page (in
> > > > > > getNumSensorValues(..),http://code.google.com/android/reference/android/hardware/Sensors.html
> > > > > > ), that is "temperature" and "pedometer"? Could one assume that
> > > > > > "temperature" gives the temperature in degree Celsius, and the
> > > > > > pedometer returns the number of steps since the last readout of the
> > > > > >sensor? (will this be multi-threaded in the sense that several
> > > > > > applications can access the pedometer concurrently in a sensible
> > > > > > way?)- Zitierten Text ausblenden -
>
> > > > > - Zitierten Text anzeigen -- Zitierten Text ausblenden -
>
> > > > - Zitierten Text anzeigen -- Hide quoted text -
>
> > - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
Announcing the new M5 SDK!
http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
