Home | History | Annotate | only in /frameworks/base/tools/orientationplot
Up to higher level directory
NameDateSize
orientationplot.py08-Oct-201518.8K
README.txt08-Oct-20153.9K

README.txt

      1 This directory contains a simple python script for visualizing
      2 the behavior of the WindowOrientationListener.
      3 
      4 
      5 PREREQUISITES
      6 -------------
      7 
      8 1. Python 2.6
      9 2. numpy
     10 3. matplotlib
     11 
     12 eg. sudo apt-get install python-numpy python-matplotlib
     13 
     14 
     15 USAGE
     16 -----
     17 
     18 The tool works by scaping the debug log output from WindowOrientationListener
     19 for interesting data and then plotting it.
     20 
     21 1. Plug in the device.  Ensure that it is the only device plugged in
     22    since this script is of very little brain and will get confused otherwise.
     23 
     24 2. Enable the Window Orientation Listener debugging data log.
     25    adb shell setprop debug.orientation.log true
     26    adb shell stop
     27    adb shell start
     28 
     29 3. Run "orientationplot.py".
     30 
     31 
     32 WHAT IT ALL MEANS
     33 -----------------
     34 
     35 The tool displays several time series graphs that plot the output of the
     36 WindowOrientationListener.  Here you can see the raw accelerometer data,
     37 filtered accelerometer data, measured tilt and orientation angle, confidence
     38 intervals for the proposed orientation and accelerometer latency.
     39 
     40 Things to look for:
     41 
     42 1. Ensure the filtering is not too aggressive.  If the filter cut-off frequency is
     43    less than about 1Hz, then the filtered accelorometer data becomes too smooth
     44    and the latency for orientation detection goes up.  One way to observe this
     45    is by holding the device vertically in one orientation then sharply turning
     46    it 90 degrees to a different orientation.  Compared the rapid changes in the
     47    raw accelerometer data with the smoothed out filtered data.  If the filtering
     48    is too aggressive, the filter response may lag by hundreds of milliseconds.
     49 
     50 2. Ensure that there is an appropriate gap between adjacent orientation angles
     51    for hysteresis.  Try holding the device in one orientation and slowly turning
     52    it 90 degrees.  Note that the confidence intervals will all drop to 0 at some
     53    point in between the two orientations; that is the gap.  The gap should be
     54    observed between all adjacent pairs of orientations when turning the device
     55    in either direction.
     56 
     57    Next try holding the device in one orientation and rapidly turning it end
     58    over end to a midpoint about 45 degrees between two opposing orientations.
     59    There should be no gap observed initially.  The algorithm should pick one
     60    of the orientations and settle into it (since it is obviously quite
     61    different from the original orientation of the device).  However, once it
     62    settles, the confidence values should start trending to 0 again because
     63    the measured orientation angle is now within the gap between the new
     64    orientation and the adjacent orientation.
     65 
     66    In other words, the hysteresis gap applies only when the measured orientation
     67    angle (say, 45 degrees) is between the current orientation's ideal angle
     68    (say, 0 degrees) and an adjacent orientation's ideal angle (say, 90 degrees).
     69 
     70 3. Accelerometer jitter.  The accelerometer latency graph displays the interval
     71    between sensor events as reported by the SensorEvent.timestamp field.  It
     72    should be a fairly constant 60ms.  If the latency jumps around wildly or
     73    greatly exceeds 60ms then there is a problem with the accelerometer or the
     74    sensor manager.
     75 
     76 4. The orientation angle is not measured when the tilt is too close to 90 or -90
     77    degrees (refer to MAX_TILT constant).  Consequently, you should expect there
     78    to be no data.  Likewise, all dependent calculations are suppressed in this case
     79    so there will be no orientation proposal either.
     80 
     81 5. Each orientation has its own bound on allowable tilt angles.  It's a good idea to
     82    verify that these limits are being enforced by gradually varying the tilt of
     83    the device until it is inside/outside the limit for each orientation.
     84 
     85 6. Orientation changes should be significantly harder when the device is held
     86    overhead.  People reading on tablets in bed often have their head turned
     87    a little to the side, or they hold the device loosely so its orientation
     88    can be a bit unusual.  The tilt is a good indicator of whether the device is
     89    overhead.
     90