加速度计记录器:偶尔遇到帧之间的长时间延迟 [英] Accelerometer logger: experiencing occasional long delays between frames
问题描述
我正在编写一个应用程序，每 40 毫秒(25 赫兹)记录一次手机的加速度.这个帧速率可以保持平均，但有时我会遇到时间帧之间 5'000 毫秒 - 50'000 毫秒的延迟.我想知道为什么会发生这种情况.
这里有一个延迟图表，您可以看到它们经常发生:
这就是我正在做的事情(可能很糟糕):
- 该活动指向一个加速度计记录器类(单例、纯 Java、无 android 类扩展).
- 加速度计记录器单例继续在后台登录.
- 加速度计记录器将每个日志直接保存到 sqlite 数据库.
- 我也在后台记录 GPS 数据.
- DAO(数据访问对象)将每个日志分配给 LinkedBlockingQueue 并将它们保存在单独的线程中.
以下是我认为可能存在的问题:
- 也许我必须实现进一步的生命周期方法，或扩展特定的 android 类，以便加速计记录器获得优先级(或只是在某处设置优先级).
- 我可能会使用
event.timestamp而不是System.currentTimeMills().(我不想这样做，因为有些传感器有不同的时区，这就是我使用System.currentTimeMillis()的原因，但如有必要，我会切换.)
您有这方面的经验或建议可能存在的问题吗?
这是我的代码:
@SuppressLint("NewApi")公共类 AccelerometerLogger 实现 SensorEventListener {私有静态 AccelerometerLogger 单例 = 新的 AccelerometerLogger();私有 LoggerDao loggerDao;私人 SensorManager sensorManager;私人传感器加速度计；私人双加速度计Rate = 25;//赫兹int accelerometerDelayMicroseconds = (int) (Math.round(((1/this.acceleorometerRate)*1000000.0)));私人 AccelerometerLogger(){this.loggerDao = LoggerDao.getInstance();}公共静态 AccelerometerLogger getInstance(){返回单身人士；}公共无效开始(上下文上下文){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", "所需延迟:"+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", "监听器注册所需速率:"+this.acceleorometerRate+"Hz ("+this.acceleorometerDelayMicroseconds+" 微秒的延迟);}否则如果(加速度计MinDelay==0){this.sensorManager.registerListener(this, this.accelerator, SensorManager.SENSOR_DELAY_FASTEST);//Log.d("lggr-r", "listener 为流 api 注册.只有更改才会被通知(中断).");}别的{int providedRate = (int) Math.round(1/(accelerometerMinDelay/1000000.0));this.sensorManager.registerListener(this, this.accelerator, SensorManager.SENSOR_DELAY_FASTEST);//Log.d("lggr-r", "无法以所需的速率读取 ("+this.acceleorometerRate+"Hz)，应用程序将以 "+providedRate+"Hz 读取(延迟 "+accelerometerMinDelay+" 微秒).");}}公共无效停止(){this.sensorManager.unregisterListener(this);}@覆盖public void onAccuracyChanged(传感器传感器，整数精度){//字符串名称 = sensor.getName();//Log.d("lggr", ""+name+"的精度改为"+accuracy+".");}@覆盖public void onSensorChanged(SensorEvent 事件){//延迟加载 loggerDao(TODO:修复所有这些)if(this.loggerDao == null){this.loggerDao = LoggerDao.getInstance();}字符串值 = "";for(float value : event.values) values += value+",";values = values.substring(0,values.length()-2);//长时间戳 = System.currentTimeMillis();//Log.d("lggr", "acc = {time:"+timestamp+", data: ["+values+"]}");AccelerometerSample AccelerometerSample = new AccelerometerSample();accelerometerSample.setTimestamp(System.currentTimeMillis());加速度计Sample.setValues(event.values);this.loggerDao.save(加速度计样品);}}显然这个问题只发生在三星 Galaxy SIII mini 上.我已经用三星 Galaxy SII(自定义 ROM)对其进行了测试，延迟始终约为 0.04 秒(介于 0.005 和 0.12 秒之间 - 好多了).
您对三星 Galaxy SIII mini 出现这种情况的原因有什么建议吗?
更新:
Ben Voigts 的回答旨在使用 event.timestamp 显着改善了延迟.不过，我有时会遇到一些更长的延迟.你知道我可以如何进一步改进它们吗?
你绝对应该使用 event.timestamp.如果需要本地时间，请计算第一个事件的 event.timestamp 和 System.currentTimeMills() 之间的调整因子，并将相同的调整应用于后续样本.>
附加到样本的硬件提供时间戳的全部意义在于它不会被线程调度延迟弄乱.
I am writing an app that logs the accelerations of the mobile phone every 40ms (at 25Hz). This frame rate can be held on average, but sometimes I am experiencing delays of 5'000ms - 50'000ms between timeframes. I am wondering why this happens.
Here you have a graph of the delays where you can see that they occur quite often:
Here's what I am doing (which might be bad):
- The activity points to a accelerometer logger class (singleton, pure java, no android class extensions).
- The accelerometer logger singleton continues to log in the background.
- The accelerometer logger saves every log directly to the sqlite db.
- I am also logging GPS data in the background.
- The DAO (Data Access Object) assigns every Log to a LinkedBlockingQueue and saves them in a separate thread.
Here's what I think might be the problem:
- Maybe i have to implement further lifecycle methods, or extend a specific android class, so that the accererometer logger gains priority (or just set the priority somewhere).
- I might use the
event.timestampinstead ofSystem.currentTimeMills(). (I would prefer not to do this, as some sensors have different timezones, thats why i useSystem.currentTimeMillis(), but if necessary I'd switch.)
Do you have any experience with this or suggestions where the problem could probably lie?
Here's my code:
@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);
}
}
Apparently the problem only happens on the Samsung Galaxy SIII mini. I've tested it with a Samsung Galaxy SII (custom ROM) and the delays were always about 0.04s (ranging between 0.005 and 0.12s - much better).
Do you have any suggestions why this happens on the Samsung Galaxy SIII mini?
UPDATE:
Ben Voigts answer which purposed to use the event.timestamp has improved the delays significantly. Still, i am experiencing sometimes some longer delays. Do you know how I can further improve them?
You absolutely should be using event.timestamp. If you want local time, calculate the adjustment factor between event.timestamp and System.currentTimeMills() on the first event, and apply the same adjustment to subsequent samples.
The whole point of a hardware-provided timestamp attached to the sample is that it isn't messed up by thread scheduling delays.
这篇关于加速度计记录器:偶尔遇到帧之间的长时间延迟的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
