¿Cuál es el mejor lenguaje para la programación en tiempo real en una Raspberry Pi?

Tienes que tener cuidado con lo que esperas en tiempo real. He oído que solía significar una respuesta garantizada a un estímulo dentro de un límite de tiempo específico, aunque el estímulo real al tiempo de respuesta no es predecible y el límite es de unos pocos segundos. Con computadoras más rápidas disponibles ahora, esto se puede reducir a milisegundos. El otro tipo tiene una respuesta de tiempo determinista, donde no solo se le garantiza una respuesta, sino que sabe cuánto tiempo llevará.

Una instancia (hace mucho tiempo) involucró un controlador PID escrito en Fortran, apenas podía administrar el tiempo de ciclo de 100 ms y a menudo omitía causar fallas de control. Terminé codificando un reemplazo como un controlador de dispositivo que podría usar una rutina de interrupción del núcleo que se ejecuta a 5 ms y dividí el código en 6 secciones para lograr un muestreo de 25 ms, en este punto estaba usando aproximadamente un 50% de tiempo de CPU dejando suficiente capacidad para ejecutar la interfaz de usuario etc.

Por lo tanto, si desea lograr el tiempo exacto y tiene la intención de usar Linux, tendrá que crear un controlador de dispositivo para poder acceder al tiempo regular basado en interrupciones, y eso sería usar C como ese es el lenguaje de los controladores de Linux. Sin embargo, aún recibirá jitter ya que su interrupción del temporizador tendrá su propio nivel de prioridad entre otras fuentes de interrupción. Además, el acceso a DMA retrasará la señal de interrupción de su temporizador. En general, tendrá mucho menos fluctuación de fase en un controlador que en un proceso de modo de usuario, ya que no se puede evitar como programas de usuario.

Tengo otra sugerencia: ¿por qué no usar un Arduino para implementar el servo control y solo hacer que el PI actualice el punto de ajuste? Eso implicaría la programación en C ++, y usted tiene el control total del hardware ya que no tiene sistema operativo. Hay Alamode – Placa Raspberry Pi compatible con Arduino que he usado antes porque se conecta directamente al PI. Hay muchas otras placas Arduino (y compatibles) de varias fuentes que podría considerar, algunas son muy pequeñas y funcionan a 3.3v, por lo que se conectarían directamente al PI. En dicho sistema, los Arduinos manejarían la sincronización precisa del servo y usted podría codificar el código de supervisión Pi y la interfaz de usuario en Python, ya que cualquier inquietud no importaría.

Si quieres un servocontrol mucho más preciso con Python en un RPi, prueba PIGPIO. No se menciona que a menudo en los artículos, pero el servo control es sorprendentemente malo en el RPi a menos que esté usando PIGPIO. Aquí hay un enlace a la biblioteca: http://abyz.co.uk/rpi/pigpio/&nbsp ; Realmente recomiendo esto antes de cambiar de idioma. Si realmente desea un lenguaje diferente, C es mejor para el control de servo de bajo nivel en el RPi, pero ¿por qué molestarse si puede obtener un rendimiento de servo satisfactorio sin cambiar los idiomas?

La razón por la que los servo son tan nerviosos en el RPi no tiene nada que ver con el ‘tiempo real’. Es por la forma en que funciona el servo. Para mantener un ángulo deseado en un servo, una señal de una frecuencia particular debe ser precisa en unos pocos microsegundos. Si se desvía en absoluto, obtienes nerviosismo. Si está utilizando Python y las bibliotecas de E / S comunes, entonces confía en el software, y no en el hardware, para ser precisos en microsegundos, lo cual no es así. PIGPIO hace un buen trabajo de compensación.

Hay un JDK / JVM en tiempo real que podría considerar.

El JDK normal también funcionará siempre que no esté creando una destrucción de muchos objetos, al menos no durante las operaciones intensivas donde el GC puede causar un hipo. (Las variables / objetos locales creados en la pila de subprocesos son un poco diferentes). Si apaga el recolector de basura por completo, como se hacía en los viejos tiempos con servlets, incluso eso no será un problema.

Parece que tiene alguna comprensión de los diferentes niveles y tipos de preocupaciones de “tiempo real” (RTC).

Si es práctico, podría considerar usar un tipo diferente de servo. Un servo digital en lugar de analógico puede resolver el problema, aunque eso no es algo que he visto en bastante tiempo.