Esto es 'prueba de hipótesis en presencia de ruido'.
Cuando estamos haciendo una prueba de hipótesis, definimos un par de condiciones entre las que queremos discriminar, luego definimos una prueba para hacerlo mejor.
Ha definido una condición 'es estacionaria' y una prueba | (current_avg - previous_avg) | < delta. Implícito en esa definición hay otras dos condiciones, subir y bajar.
Si bien la definición de 'es estacionario' no está bien definida, si aplicamos ingeniería inversa a la prueba que ha ideado para averiguar qué significa realmente, el cambio en la posición promedio tomada entre los primeros 1000 y los próximos 1000 Una muestra larga de posiciones de 2000, encontramos que es algo bastante razonable de hacer.
El promedio de 1000 muestras es la mejor manera de calcular una posición promedio, si asumimos que el ruido en cada muestra es independiente. También es rápido, usa pocos recursos, es fácil de entender y usa poca memoria (no necesita almacenar todas las entradas).
La diferencia entre el primer y el segundo conjunto te da la mejor estimación de la velocidad media del pozo durante ese tiempo.
Ahora considere este caso de prueba. Para las primeras 1000 muestras, el bote está girando rápidamente hacia arriba, para las siguientes 1000 está girando rápidamente hacia abajo. El movimiento medio durante ese período, calculado por su estimador, será cero.
¿Estás contento de que esta condición se detecte como estacionaria? Si no, entonces tenemos que cambiar nuestra definición de estacionario. Según tu comentario, no estás contento con algo. ¿Pero qué?
Como ve, el problema no está en la prueba en sí, sino en (a) su definición deficiente de lo que significa "estacionario" y (b) su definición deficiente de lo que considera insatisfactorio sobre el desempeño de la prueba actual.
La prueba que ha definido es la prueba más razonable que existe para detectar la velocidad promedio en presencia de ruido. Si esto funciona bien con la física del mundo real y el comportamiento del usuario es otra cuestión.
Si encuentra que realmente necesita detectar la aceleración, para mejorarla en su caso, es bastante fácil tomar tres muestras promediadas sucesivas, calcular ambos deltas y luego calcular el delta delta.
Si encuentra que un cambio de tamaño promedio, para cambiar la velocidad a la que puede detectar cambios, funciona mejor, entonces haga eso.
Hay otras alternativas que prueban diferentes hipótesis. El primero sería calcular dos medios de ejecución con diferentes constantes de tiempo. Este es un filtro común para usar como detector de bordes en el procesamiento de imágenes, pero también detectará "bordes" en datos unidimensionales. Como los filtros son recursivos, esto es bastante barato de implementar. Sin embargo, tendría que ajustar las dos constantes de tiempo a su situación, entonces, ¿cómo lo haría sintonizar mejor que la única constante de tiempo de su probador actual?
El segundo es hacer un FFT de tus muestras. A continuación, puede comparar la energía en el contenedor de CC (cantidad de estacionario) con la energía en los contenedores de baja frecuencia (cantidad de movimiento, aceleración, cambio de aceleración ...) mientras descarta la energía en los contenedores de alta frecuencia (ruido de lectura) . Pero eso necesita una gran capacidad de memoria y procesamiento, y parece una exageración.
Un tercero, basado en su comentario sobre el problema de la latencia, sería estimar simultáneamente la posición y la pendiente de la línea mediante regresión lineal. Hay una fórmula recursiva para esto, por lo que es relativamente eficiente para usted calcular en tiempo real sin más memoria. Esto le permitiría "corregir" el retraso en la recopilación de datos extrapolando ambas estimaciones hacia adelante para obtener la posición promedio "ahora". Tenga en cuenta que la regresión lineal puede tener problemas de rango dinámico si se realiza para grandes conjuntos de datos, y como está usando la aritmética de enteros, tendría que pensar detenidamente en la implementación. Una forma de mejorar las cosas sería diezmar y ejecutar la regresión lineal a una frecuencia de muestreo mucho más baja, más consistente con la velocidad a la que se está moviendo su pozo del mundo real y el tiempo de respuesta que desea que tenga el programa.