2013-03-26 25 views
2

我正在寫一個應用程序,每40ms(以25Hz)記錄移動電話的加速度。這個幀速率可以保持平均,但有時我會在時間範圍內出現5'000ms到50,000ms的延遲。我想知道爲什麼會發生這種情況。加速計記錄器:經歷幀間的偶爾長延遲

這裏有延遲的曲線圖,你可以看到,他們發生得相當頻繁:

occasional long delays between accelerometer measurements

下面是我在做什麼(這可能是壞的):

  • 的activity指向一個加速計記錄器類(singleton,純java,沒有android類擴展)。
  • 加速計記錄器單身繼續登錄後臺。
  • 加速計記錄器將每個日誌直接保存到sqlite數據庫。
  • 我也在後臺記錄GPS數據。
  • DAO(數據訪問對象)將每個日誌分配給LinkedBlockingQueue並將它們保存在單獨的線程中。

這裏就是我想可能是這個問題:

  • 也許我要實現進一步的生命週期方法,或延長一個特定的Android類,使accererometer記錄收益的優先級(或只是設置優先級某處)。
  • 我可能會使用event.timestamp而不是System.currentTimeMills()。 (我寧願不這樣做,因爲一些傳感器具有不同的時區,這就是爲什麼我使用System.currentTimeMillis(),但如果需要的話我會切換。)

你有這個或建議的任何體驗,這個問題可能大概說謊?

這裏是我的代碼:

@SuppressLint("NewApi") 
public class AccelerometerLogger implements SensorEventListener { 

    private static AccelerometerLogger singleton = new AccelerometerLogger(); 

    private LoggerDao loggerDao; 

    private SensorManager sensorManager; 

    private Sensor accelerometer; 

    private double acceleorometerRate = 25; // Hz 

    int accelerometerDelayMicroseconds = (int) (Math.round(((1/this.acceleorometerRate)*1000000.0))); 

    private AccelerometerLogger() 
    { 
     this.loggerDao = LoggerDao.getInstance(); 
    } 

    public static AccelerometerLogger getInstance() 
    { 
     return singleton; 
    } 

    public void start(Context context) 
    { 
     this.sensorManager = (SensorManager) context.getSystemService(Context.SENSOR_SERVICE); 
     this.accelerometer = this.sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER); 

     int accelerometerMinDelay = this.accelerometer.getMinDelay(); 

     //Log.d("lggr-r", "desired delay: "+this.accelerometerDelayMicroseconds+" microseconds"); 
     //Log.d("lggr-r", "provided min delay: "+accelerometerMinDelay+" microseconds"); 

     if(accelerometerMinDelay < this.accelerometerDelayMicroseconds) 
     { 
      this.sensorManager.registerListener(this, this.accelerometer, this.accelerometerDelayMicroseconds); 
      //Log.d("lggr-r", "listener registered for desired rate: "+this.acceleorometerRate+"Hz (delay of "+this.accelerometerDelayMicroseconds+" microseconds)."); 
     } 
     else if(accelerometerMinDelay==0) 
     {   
      this.sensorManager.registerListener(this, this.accelerometer, SensorManager.SENSOR_DELAY_FASTEST); 
      // Log.d("lggr-r", "listener registered for streaming api. only changes will be notified (interrupt)."); 
     } 
     else 
     { 
      int providedRate = (int) Math.round(1/(accelerometerMinDelay/1000000.0)); 
      this.sensorManager.registerListener(this, this.accelerometer, SensorManager.SENSOR_DELAY_FASTEST); 
      // Log.d("lggr-r", "can't read at the desired rate ("+this.acceleorometerRate+"Hz), app will read at "+providedRate+"Hz instead (delay of "+accelerometerMinDelay+" microseconds)."); 
     } 
    } 

    public void stop() 
    { 
     this.sensorManager.unregisterListener(this); 
    } 

    @Override 
    public void onAccuracyChanged(Sensor sensor, int accuracy) 
    { 
     // String name = sensor.getName(); 
     // Log.d("lggr", "the accurracy of "+name+" changed to "+accuracy+"."); 
    } 

    @Override 
    public void onSensorChanged(SensorEvent event) 
    { 
     // lazy load loggerDao (TODO: fix all of those) 
     if(this.loggerDao == null) 
     { 
      this.loggerDao = LoggerDao.getInstance(); 
     } 


     String values = ""; 
     for(float value : event.values) values += value+","; 
     values = values.substring(0,values.length()-2); 

     // long timestamp = System.currentTimeMillis(); 
     // Log.d("lggr", "acc = {time:"+timestamp+", data: ["+values+"]}"); 

     AccelerometerSample accelerometerSample = new AccelerometerSample(); 
     accelerometerSample.setTimestamp(System.currentTimeMillis()); 
     accelerometerSample.setValues(event.values); 

     this.loggerDao.save(accelerometerSample); 
    } 

} 

顯然,問題只發生在三星Galaxy SIII的迷你。我用三星Galaxy SII(自定義ROM)測試了它,延遲時間總是在0.04s左右(介於0.005到0.12s之間 - 好得多)。

你有什麼建議,爲什麼發生這種情況在三星Galaxy SIII迷你?

UPDATE:

本福格茨答案,意要使用event.timestamp有顯著改善的延遲。不過,我有時會遇到更長的延誤。你知道我可以如何進一步改進它們嗎?

enter image description here

+0

你可以發表你的傳感器管理器代碼 – nayab 2013-03-27 16:08:28

+0

肯定,我只是增加了它。 – ndrizza 2013-03-27 19:10:40

+0

這可能是因爲日誌記錄。將數據記錄在一個線程中。 – 2013-03-27 21:47:16

回答

4

你絕對應該使用event.timestamp。如果您需要本地時間,請計算第一個事件的event.timestampSystem.currentTimeMills()之間的調整因子,並將相同的調整應用於後續樣本。

附加到示例的硬件提供的時間戳的整點是它不會被線程調度延遲搞砸。

+0

這使得延誤時間縮短了很多。他們仍然像我上面的例子那樣激增,並且在0.18秒之前仍然有很大的延遲(相比0.04秒) - 但帽子已經好多了。你有一個想法,我可以如何進一步改善這一點? – ndrizza 2013-03-29 18:49:20

+0

@ndrizza:硬件可能有一個FIFO緩衝區,可以在等待軟件收集它們時保存有限數量的樣本。通常,當FIFO接近滿時,驅動程序需要處理中斷,並將採樣移到系統內存中較大的緩衝區。如果看到多秒跳過,那可能比驅動程序緩衝區可以處理的多,所以增加線程的優先級可能有助於確保在緩衝區溢出之前讀取樣本。 – 2013-03-30 16:04:51

+0

由於您的問題在特定設備或ROM上更糟糕,可能是硬件FIFO較小,或者驅動程序不緩衝數據,或者兩者都有。我會嘗試在設備上的其他ROM上性能差,並嘗試查看問題是硬件還是軟件(當然,不同的ROM不一定使用不同的驅動程序版本) – 2013-03-30 16:06:07

0

正如Ben Voigt所說,有必要使用event.timestamp來獲得傳感器測量的準確時間戳。下面是一個代碼示例我用我自己和我的工作:

@Override 
public void onSensorChanged(SensorEvent event) { 
    if (sampleCounter == 0) { 
     long miliTime = System.currentTimeMillis(); 

     long nanoTime = event.timestamp; 

     timeDiff = miliTime - nanoTime/1000000; 
     log.info("Synchornizing sensor clock. Current time= " + miliTime 
       + ", difference between clocks = " + timeDiff); 
    } 

    float x = event.values[0]; 
    float y = event.values[1]; 
    float z = event.values[2]; 
    long ts = event.timestamp/1000000 + timeDiff; 

    //Do your stuff 

    sampleCounter++; 
}