Depuración de controladores y modelos de espacio de estado

Comprobación de señales

Una de las causas más comunes de errores con los controladores de espacio de estado son los letreros que se invierten. Por ejemplo, los modelos incluidos en WPILib esperan que el voltaje positivo dé como resultado una aceleración positiva y viceversa. Si la aplicación de un voltaje positivo no hace que el mecanismo se acelere hacia adelante, o si el movimiento hacia «adelante» hace que el encoder (u otras lecturas del sensor) disminuyan, deben invertirse para que la entrada de voltaje positivo dé como resultado una lectura del codificador positivo. Por ejemplo, si aplico una term:entrada de \([12, 12]^T\) (hacia adelante completo para los motores izquierdo y derecho) a mi transmisión diferencial, mis ruedas deberían impulsar mi robot hacia «adelante » (a lo largo del eje + X localmente), y para que mis codificadores lean una velocidad positiva.

Importante

El WPILib DifferentialDrive por defecto invierte los motores correctos. Este comportamiento se puede cambiar llamando a setRightSideInverted(false)/SetRightSideInverted(false) (Java / C ++) en el objeto DifferentialDrive.

La importancia de los gráficos

Los datos confiables de estados del sistema , entradas y salidas en el tiempo son importantes cuando se depuran controladores y observadores del espacio de estado. Un enfoque común es enviar estos datos a través de NetworkTables y usar herramientas como Shuffleboard, que nos permite graficar los datos en tiempo real y guardarlos en un archivo CSV para trazarlos más tarde con herramientas como como Hojas de cálculo de Google, Excel o Python.

Nota

De forma predeterminada, NetworkTables está limitado a una tasa de actualización de 10 Hz. Para las pruebas, esto se puede omitir con el siguiente fragmento de código para enviar datos a una velocidad de hasta 100 hz. Este código debe ejecutarse periódicamente para publicar nuevos datos a la fuerza.

Peligro

Esto enviará datos adicionales (hasta 100 hz) a través de NetworkTables, lo que puede causar retrasos tanto con el código de usuario como con los paneles de control del robot. Esto también aumentará la utilización de la red. Suele ser una buena idea desactivarlo durante las competencias.

@Override
public void robotPeriodic() {
   NetworkTableInstance.getDefault().flush();
}

Compensación por retraso de entrada

Con frecuencia, algunos datos de entrada del sensor (es decir, lecturas de velocidad) pueden retrasarse debido al filtrado integrado que los controladores de motor inteligentes tienden a realizar. De forma predeterminada, la ganancia K de LQR asume que no hay retardo de entrada, por lo que introducir un retardo significativo del orden de decenas de milisegundos puede provocar inestabilidad. Para combatir esto, se puede reducir la ganancia K del LQR, intercambiando rendimiento por estabilidad. Está disponible un ejemplo de código sobre cómo compensar esta latencia de una manera matemáticamente rigurosa aquí.