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 -~----------~----~----~----~------~----~------~--~---
