Como continuación a Programación Arduino Parte 1 escribo esta entrada con los progresos sobre los primeros problemas surgidos.
El problema de la inestabilidad de la velocidad de los motores, con bajones de velocidad a intervalos regulares y que de algún modo eran debidos a la transmisión de datos de la IMU a Arduino, ha quedado solucionada. He hecho una pequeña modificación en el código del AHRS 9DOF Razor IMU con el que sólo se calculan los ángulos y envían los datos a petición. Así quedan sincronizados el cálculo de los ángulos y envío de los datos con el tiempo de ciclo de la programación en Arduino. Con este cambio la velocidad de los motores es estable.
El nuevo código para el AHRS 9DOF Razor IMU podéis encontrarlo en AHRS 9DOF Razor IMU Parte 3.
Al tener Arduino que realizar la petición nos encontramos con que tanto la recepción como la transmisión de la UART de la placa van a estar ocupadas con la IMU así que tenemos que buscarnos un sistema alternativo para el envío de datos para diagnosis. La solución es la librería SoftwareSerial. Esta librería la usaremos sólo para transmitir ya que al ser todo por software la recepción produce interrupciones que afectarían a nuestro código.
Con todo esto también he realizado la primera placa con la que poder montar todos los componentes y ensamblar todas las partes para poder hacer las primeras pruebas. La placa es muy mejorable e incluso hay alguna cosa que no puede funcionar... en concreto la transmisión de datos desde Arduino para diagnosis. Le habilité la salida A7 hacia un conector en el que ensamblar un emisor de 433 MHz para más tarde encontrarme que la librería SoftwareSerial sólo funciona en las salidas digitales y no en las analógicas como la A7. En el código lo hago a través del pin 12, como de momento la placa tenía previsto conectores para futuros servos puedo conectar ahí un cable.
Otro fallo que he cometido y que daría marcha atrás si estuviera a tiempo es la placa que utilizo. Me decanté por una placa en eBay que llaman Meduino. La placa en sí está bastante bien, muy parecida a la Arduino Pro Mini. Sin embargo ahí radica el problema. Para ganar en compatibilidad veo mucho mejor usar un clon de la Arduino Pro Mini (o la original, vamos). Por ejemplo yo tengo el riesgo de que dejen de fabricar esa Meduino y no pueda hacer más placas o o pueda sustituir la que tengo ante una avería. Tal vez en la siguiente placa de componentes que haga me plantee "rehacerla" incorporando una Arduino Pro Mini 100% compatible.
A continuación os adjunto los archivos en Eagle de la placa y el programa de Arduino (disculpad que en algunos sitios esté un poco caótico, está sin depurar ya que está desarrollado en fase de pruebas).
El código está hecho para hacer las primeras pruebas sobre la estabilización del roll. Con los tres mandos circulares de la emisora, a los que tengo asignados los canales 5, 6 y 7, puedo variar en tiempo real los parámetros Kp, Ki y Kd del PID del roll.
Archivo para Arduino 1.0.3: Cuadricóptero v1.0
Archivos Eagle placa: Placa Cuadricóptero v2.0
Esquema placa: Esquema v2.0
jueves, 18 de julio de 2013
AHRS 9DOF Razor IMU Parte 3
Como continuación a AHRS 9DOF Razor IMU Parte 2 escribo esta entrada para subir el código con las mejoras necesarias explicadas en Programación Arduino Parte 2.
Este código permite el cálculo y envío de datos a petición externa, desde Arduino.
Archivo para 9DOF Razor: Razor AHRS v2.0
Archivo para leer los datos enviados: Leer 9DOF Razor v2.0
Este código permite el cálculo y envío de datos a petición externa, desde Arduino.
Archivo para 9DOF Razor: Razor AHRS v2.0
Archivo para leer los datos enviados: Leer 9DOF Razor v2.0
sábado, 8 de junio de 2013
ESC Parte 2
Como continuación a ESC Parte 1 escribo esta entrada para comentar una incidencia que he tenido. Probablemente es algo obvio para aquellos que vienen del aeromodelismo pero lo anoto por sí alguien se encuentra en la misma situación que yo.
Yo adquirí dos ESC para ir realizando diversas pruebas. Cuando el proyecto estaba más adelantado fui a comprar los otros dos ESC pero me encontré con que ya no estaban. Así qué tubería que adquirir dos unidades muy parecidas. En principio la única diferencia es que los primeros traían el conector para la "Monitorización de descarga balanceada" y los segundos no.
Tiempo después haciendo pruebas con los cuatro ESC y motores comprobé que no todos tenían la misma respuesta. Con el mismo pulso unos iban a una velocidad y otros a otra. Lo primero fue pensar en que fueran distintos los ESC comprados en dos veces pero no había una correlación. Tras muchas pruebas, estudios y búsqueda de información encontré la respuesta y con ella la solución. Los ESC se pueden calibrar y de hecho será una rutina para un aeromodelista. Se trata simplemente de indicar al ESC los puntos mínimo y máximo para los pulsos. Con una emisora de RC se hace con la correspondiente palanca llevándola al máximo y mínimo recorrido. Yo lo he hecho con el programa de control de los motores estableciendo el mínimo en 1000 µs y el máximo en 2000 µs. Llevando este procedimiento de la misma manera en los cuatro ESC desaparece el "problema". Y yo que me veía estableciendo linealizaciones particulares para cada ESC en la programación en Arduino...
Yo adquirí dos ESC para ir realizando diversas pruebas. Cuando el proyecto estaba más adelantado fui a comprar los otros dos ESC pero me encontré con que ya no estaban. Así qué tubería que adquirir dos unidades muy parecidas. En principio la única diferencia es que los primeros traían el conector para la "Monitorización de descarga balanceada" y los segundos no.
Tiempo después haciendo pruebas con los cuatro ESC y motores comprobé que no todos tenían la misma respuesta. Con el mismo pulso unos iban a una velocidad y otros a otra. Lo primero fue pensar en que fueran distintos los ESC comprados en dos veces pero no había una correlación. Tras muchas pruebas, estudios y búsqueda de información encontré la respuesta y con ella la solución. Los ESC se pueden calibrar y de hecho será una rutina para un aeromodelista. Se trata simplemente de indicar al ESC los puntos mínimo y máximo para los pulsos. Con una emisora de RC se hace con la correspondiente palanca llevándola al máximo y mínimo recorrido. Yo lo he hecho con el programa de control de los motores estableciendo el mínimo en 1000 µs y el máximo en 2000 µs. Llevando este procedimiento de la misma manera en los cuatro ESC desaparece el "problema". Y yo que me veía estableciendo linealizaciones particulares para cada ESC en la programación en Arduino...
sábado, 11 de mayo de 2013
Programación Arduino Parte 1
En las distintas entradas he ido desarrollando el código para el funcionamiento de los bloques principales. Ahora hay que juntarlos todos. Por supuesto hay que tener en cuenta que el desarrollo del código de los distintos bloques se ha hecho pensando que tendrá que ir unido al resto.
Cuando empecé a estudiar un poco sobre cuadricópteros y la programación en Arduino una característica que tuve claro que quería para mi proyecto fue que el código funcionara sin interrupciones. Hay aplicaciones para las que las interrupciones no suponen ningún problema. Sin embargo en un cuadricóptero lo considero un aspecto fundamental. Las interrupciones producen pequeños fallos en el timing que generan por ejemplo inexactitudes en las medidas de los canales de la emisora RC o saltos en los pulsos enviados a los ESC (y servos si los hay). Estos efectos tienen como consecuencia una mala estabilización del cuadricóptero.
Quiero aclarar la problemática de las interrupciones. Lo que no podemos hacer es, por ejemplo, utilizar una librería ya confeccionada que utiliza interrupciones. Generalmente estas librerías no podemos activar y desactivar sus interrupciones según nos interese así que si la utilizamos sus interrupciones se producirán en cualquier momento dentro de nuestro código. En algunas partes no tendrá importancia pero en otras nos producirá grandes errores en los timing produciendo los fallos antes nombrados.
Sin embargo sí que podríamos utilizar interrupciones si nos interesara si somos nosotros los que las controlamos, activándolas en el momento en que nos interese y desactivándolas una vez terminado ese proceso para que no intercepten el resto del código. Por ejemplo se puede desarrollar el código para el control de los motores (los disparos a los variadores) mediante interrupciones. Estas interrupciones estarán activadas justo el tiempo de duración de esta pequeña parte de código (entre 1 ms y 2,1 ms) con lo que no habrá problemas. Por el momento lo cierto es que yo no me he puesto más a fondo con las interrupciones y mis códigos los he desarrollado sin ellas pero probablemente se gane en precisión utilizándolas de esta manera. Este es un aspecto mejorable que tal vez aborde en el futuro.
Según lo explicado, que el código no tenga interrupciones básicamente supone:
- No poder usar la librería Servo.h para el control de los ESC (ni de servos). Esta librería funciona mediante interrupciones.
- No poder utilizarlas para tomar las lecturas de los canales de la emisora RC (tal vez podrían utilizarse si las podemos desactivar pero no estoy seguro si conseguiríamos alguna mejora).
- Secuencia del código totalmente lineal con estricto estudio de los tiempos de ejecución para que no se desborde el tiempo de ciclo.
El tiempo de ejecución del código en el AHRS 9DOF Razor IMU con el envío de los datos está alrededor de los 15 ms, inferior a los 20 ms aproximados (medido en 19,58 ms) del ciclo de la emisora que marca el ciclo del programa. Por tanto en cada ciclo dispondremos de una lectura del IMU. La secuencia del programa será:
1 - Lectura de los canales de la emisora. Si queremos leer los 8 canales esto nos consume un tiempo entre 8,5 ms y 15 ms. Durante la lectura de la emisora tenemos limitado el uso del micro para otras tareas (sólo los intervalos sueltos de 1 ms anotados en el código). Por tanto nos quedan 19,58 ms del ciclo de la emisora menos los 15 ms del tiempo de ejecución, unos 4,5 ms para ejecutar el resto de tareas.
2 - Lectura de los datos del AHRS 9DOF Razor IMU enviados por puerto serie. Aunque el envío tarda unos 3 ms a la velocidad de 57600 baudios, Arduino tiene un buffer donde se van almacenando y la lectura cuando toda la trama de 17 bytes ha llegado es de sólo 0,13 ms.
3 - Ejecución de los PID para la estabilización que darán los valores necesarios para los cuatro motores. En este momento este apartado está sin terminar de desarrollar. No tengo datos de tiempos de ejecución pero la previsión es que no sean críticos.
4 - Control de los motores. Secuencia de código ya desarrollada que envía los disparos a los los ESC de los cuatro motores. El tiempo de ejecución está entre 1 ms y 2,1 ms.
5 - Otras tareas que se irán implementando con tiempos de ejecución previsibles muy cortos. Por ejemplo lectura de las tensiones de las celdas de la batería para prevenir que se descarguen en exceso.
Con estos datos tenemos que el micro está ocupado 15 + 0,13 + 2,1 = 17,23 ms lo que nos deja 19,58 - 17,23 = 2,35 ms para la ejecución de los PID y otras tareas menores.
En este punto he empezado a hacer pruebas con un código que engloba los puntos 1, 2, 4 y 5 y he tropezado con un problema. La velocidad de los motores no es estable, se acelera y frena un poco a intervalos regulares de algo menos de 1 segundo. Tras mucho investigar estoy llegando a una conclusión: la lectura del puerto serie produce interrupciones. Como el ciclo del envío de datos del AHRS 9DOF Razor IMU es distinto al del código en Arduino la recepción de datos se va produciendo en distintos momentos del código. Según cuándo se produzca nos interferirá en distintas partes del programa como ahora estamos viendo que lo hace en los pulsos a los motores.
¿Y cuál es la solución a este problema? Se me ocurre sincronizar la comunicación entre AHRS 9DOF Razor IMU y Arduino. Es decir, Arduino tiene que solicitar a AHRS 9DOF Razor IMU los datos y en ese momento es cuando tiene que enviarlos. Así tenemos que tener previsto que en ese instante de recepción de datos Arduino no esté haciendo otras tareas para que no interfiera con las mismas. Tenemos dos formas de hacerlo. Una es que AHRS 9DOF Razor IMU ejecute todo su código y envíe los datos ante la petición de Arduino. La otra es que AHRS 9DOF Razor IMU esté siempre ejecutando su código y sólo envíe los datos ante la petición de Arduino. Tendré que probar las dos opciones y ver los pros y contras de cada una. Por el momento se produce un gran inconveniente y es que al usar la transmisión de Arduino hacia el AHRS 9DOF Razor IMU ya no podemos usarlo para monitorizar resultados en el Monitor Serial del ordenador. Toca hacer pruebas y encontrar soluciones.
Tenéis una nueva entrada en Programación Arduino Parte 2.
Cuando empecé a estudiar un poco sobre cuadricópteros y la programación en Arduino una característica que tuve claro que quería para mi proyecto fue que el código funcionara sin interrupciones. Hay aplicaciones para las que las interrupciones no suponen ningún problema. Sin embargo en un cuadricóptero lo considero un aspecto fundamental. Las interrupciones producen pequeños fallos en el timing que generan por ejemplo inexactitudes en las medidas de los canales de la emisora RC o saltos en los pulsos enviados a los ESC (y servos si los hay). Estos efectos tienen como consecuencia una mala estabilización del cuadricóptero.
Quiero aclarar la problemática de las interrupciones. Lo que no podemos hacer es, por ejemplo, utilizar una librería ya confeccionada que utiliza interrupciones. Generalmente estas librerías no podemos activar y desactivar sus interrupciones según nos interese así que si la utilizamos sus interrupciones se producirán en cualquier momento dentro de nuestro código. En algunas partes no tendrá importancia pero en otras nos producirá grandes errores en los timing produciendo los fallos antes nombrados.
Sin embargo sí que podríamos utilizar interrupciones si nos interesara si somos nosotros los que las controlamos, activándolas en el momento en que nos interese y desactivándolas una vez terminado ese proceso para que no intercepten el resto del código. Por ejemplo se puede desarrollar el código para el control de los motores (los disparos a los variadores) mediante interrupciones. Estas interrupciones estarán activadas justo el tiempo de duración de esta pequeña parte de código (entre 1 ms y 2,1 ms) con lo que no habrá problemas. Por el momento lo cierto es que yo no me he puesto más a fondo con las interrupciones y mis códigos los he desarrollado sin ellas pero probablemente se gane en precisión utilizándolas de esta manera. Este es un aspecto mejorable que tal vez aborde en el futuro.
Según lo explicado, que el código no tenga interrupciones básicamente supone:
- No poder usar la librería Servo.h para el control de los ESC (ni de servos). Esta librería funciona mediante interrupciones.
- No poder utilizarlas para tomar las lecturas de los canales de la emisora RC (tal vez podrían utilizarse si las podemos desactivar pero no estoy seguro si conseguiríamos alguna mejora).
- Secuencia del código totalmente lineal con estricto estudio de los tiempos de ejecución para que no se desborde el tiempo de ciclo.
El tiempo de ejecución del código en el AHRS 9DOF Razor IMU con el envío de los datos está alrededor de los 15 ms, inferior a los 20 ms aproximados (medido en 19,58 ms) del ciclo de la emisora que marca el ciclo del programa. Por tanto en cada ciclo dispondremos de una lectura del IMU. La secuencia del programa será:
1 - Lectura de los canales de la emisora. Si queremos leer los 8 canales esto nos consume un tiempo entre 8,5 ms y 15 ms. Durante la lectura de la emisora tenemos limitado el uso del micro para otras tareas (sólo los intervalos sueltos de 1 ms anotados en el código). Por tanto nos quedan 19,58 ms del ciclo de la emisora menos los 15 ms del tiempo de ejecución, unos 4,5 ms para ejecutar el resto de tareas.
2 - Lectura de los datos del AHRS 9DOF Razor IMU enviados por puerto serie. Aunque el envío tarda unos 3 ms a la velocidad de 57600 baudios, Arduino tiene un buffer donde se van almacenando y la lectura cuando toda la trama de 17 bytes ha llegado es de sólo 0,13 ms.
3 - Ejecución de los PID para la estabilización que darán los valores necesarios para los cuatro motores. En este momento este apartado está sin terminar de desarrollar. No tengo datos de tiempos de ejecución pero la previsión es que no sean críticos.
4 - Control de los motores. Secuencia de código ya desarrollada que envía los disparos a los los ESC de los cuatro motores. El tiempo de ejecución está entre 1 ms y 2,1 ms.
5 - Otras tareas que se irán implementando con tiempos de ejecución previsibles muy cortos. Por ejemplo lectura de las tensiones de las celdas de la batería para prevenir que se descarguen en exceso.
Con estos datos tenemos que el micro está ocupado 15 + 0,13 + 2,1 = 17,23 ms lo que nos deja 19,58 - 17,23 = 2,35 ms para la ejecución de los PID y otras tareas menores.
En este punto he empezado a hacer pruebas con un código que engloba los puntos 1, 2, 4 y 5 y he tropezado con un problema. La velocidad de los motores no es estable, se acelera y frena un poco a intervalos regulares de algo menos de 1 segundo. Tras mucho investigar estoy llegando a una conclusión: la lectura del puerto serie produce interrupciones. Como el ciclo del envío de datos del AHRS 9DOF Razor IMU es distinto al del código en Arduino la recepción de datos se va produciendo en distintos momentos del código. Según cuándo se produzca nos interferirá en distintas partes del programa como ahora estamos viendo que lo hace en los pulsos a los motores.
¿Y cuál es la solución a este problema? Se me ocurre sincronizar la comunicación entre AHRS 9DOF Razor IMU y Arduino. Es decir, Arduino tiene que solicitar a AHRS 9DOF Razor IMU los datos y en ese momento es cuando tiene que enviarlos. Así tenemos que tener previsto que en ese instante de recepción de datos Arduino no esté haciendo otras tareas para que no interfiera con las mismas. Tenemos dos formas de hacerlo. Una es que AHRS 9DOF Razor IMU ejecute todo su código y envíe los datos ante la petición de Arduino. La otra es que AHRS 9DOF Razor IMU esté siempre ejecutando su código y sólo envíe los datos ante la petición de Arduino. Tendré que probar las dos opciones y ver los pros y contras de cada una. Por el momento se produce un gran inconveniente y es que al usar la transmisión de Arduino hacia el AHRS 9DOF Razor IMU ya no podemos usarlo para monitorizar resultados en el Monitor Serial del ordenador. Toca hacer pruebas y encontrar soluciones.
Tenéis una nueva entrada en Programación Arduino Parte 2.
domingo, 13 de enero de 2013
Estabilización
Llegamos al punto que creo es el más crítico: la estabilización del cuadricóptero, que consigamos que se mantenga en vuelo lo más estático posible minimizando los vaivenes y vibraciones. Pensando que sería uno de los puntos sobre los que más podría aportar por el momento he tenido un pequeño gran tropiezo.
Empecé haciendo una modelización matemática con su correspondiente bucle de realimentación con control mediante un PID. Para las primeras pruebas particularicé con un brazo del cuadricóptero (dos motores con sus dos hélices). Mis cálculos dieron que el sistema era estable con un PD. Sin embargo las pruebas reales con un brazo con sus dos motores sobre un balancín fueron bastante desastrosas. Varias son las causas por las que creo que no obtuve ningún buen resultado.
- Puede influir que la modelización que hice para simplificarla haya llevado a producir resultados erróneos (por ejemplo desprecio el tiempo que a un motor con su hélice le cuesta alcanzar la velocidad que se le marca, es decir, desprecio el momento de inercia el conjunto motor-hélice).
- Los rozamientos del brazo con el pie vertical que lo sujeta como balancín afectan al sistema como también los cables que iban de los motores y la IMU (situados en el brazo) a la batería y la placa Arduino (situados externamente junto al ordenador), desvirtuando la respuesta que realmente tendría en el aire.
- También empiezo a creer que la estabilización de un cuadricóptero mediante un control PID es un sistema un poco caótico, es decir, pequeñas variaciones en las variables de entrada (los parámetros PID) producen salidas muy dispares.
Añadir también que el sistema es tan complejo como que cuando estamos cerca de la posición de equilibrio necesitamos unos valores PID distintos a cuando estemos lejos de esa posición. O aunque no sea estrictamente necesario para que el sistema sea estable el cambio de valores del PID hace que tengamos una estabilidad del vuelo mayor. Tenemos que calcular los mejores valores PID en ambos casos y cambiarlos en el programa según intervengan unos u otros. También tendremos que decidir en qué situación (a qué ángulo sobre el punto de equilibrio) cambiamos esos valores.
Cuando tengamos todo esto (para lo cual veo que aún me falta lo suyo...) un paso más allá será detectar si sobre una posición estática del cuadricóptero éste se está desplazando para que el bucle de control actúe y lo devuelva automáticamente a su posición. Esto espero que algún día llegue al punto de ponerme con ello...
El siguiente paso es hacer unas pruebas más reales para lo cual estoy montando todos los elementos del cuadricóptero en un montaje prácticamente definitivo. No tendré cables que desvirtúen los resultados. Las primeras pruebas la idea era hacerlas estando colgado el cuadricóptero de dos hilos sobre un brazo. De este modo vuelvo a la sencillez del balancín pero con menos rozamientos ya que puedo dar a los 4 motores una pequeña fuerza de modo que los hilos sean sólo un elemento de seguridad sustentándolo ligeramente. Sin embargo me han sugerido que lo mejor es hacer las pruebas sujetando el cuadricóptero con una mano en el centro. Probablemente empezaré de esa forma y cuando lo tenga algo controlado pasaré a lo de los hilos.
Empecé haciendo una modelización matemática con su correspondiente bucle de realimentación con control mediante un PID. Para las primeras pruebas particularicé con un brazo del cuadricóptero (dos motores con sus dos hélices). Mis cálculos dieron que el sistema era estable con un PD. Sin embargo las pruebas reales con un brazo con sus dos motores sobre un balancín fueron bastante desastrosas. Varias son las causas por las que creo que no obtuve ningún buen resultado.
- Puede influir que la modelización que hice para simplificarla haya llevado a producir resultados erróneos (por ejemplo desprecio el tiempo que a un motor con su hélice le cuesta alcanzar la velocidad que se le marca, es decir, desprecio el momento de inercia el conjunto motor-hélice).
- Los rozamientos del brazo con el pie vertical que lo sujeta como balancín afectan al sistema como también los cables que iban de los motores y la IMU (situados en el brazo) a la batería y la placa Arduino (situados externamente junto al ordenador), desvirtuando la respuesta que realmente tendría en el aire.
- También empiezo a creer que la estabilización de un cuadricóptero mediante un control PID es un sistema un poco caótico, es decir, pequeñas variaciones en las variables de entrada (los parámetros PID) producen salidas muy dispares.
Añadir también que el sistema es tan complejo como que cuando estamos cerca de la posición de equilibrio necesitamos unos valores PID distintos a cuando estemos lejos de esa posición. O aunque no sea estrictamente necesario para que el sistema sea estable el cambio de valores del PID hace que tengamos una estabilidad del vuelo mayor. Tenemos que calcular los mejores valores PID en ambos casos y cambiarlos en el programa según intervengan unos u otros. También tendremos que decidir en qué situación (a qué ángulo sobre el punto de equilibrio) cambiamos esos valores.
Cuando tengamos todo esto (para lo cual veo que aún me falta lo suyo...) un paso más allá será detectar si sobre una posición estática del cuadricóptero éste se está desplazando para que el bucle de control actúe y lo devuelva automáticamente a su posición. Esto espero que algún día llegue al punto de ponerme con ello...
El siguiente paso es hacer unas pruebas más reales para lo cual estoy montando todos los elementos del cuadricóptero en un montaje prácticamente definitivo. No tendré cables que desvirtúen los resultados. Las primeras pruebas la idea era hacerlas estando colgado el cuadricóptero de dos hilos sobre un brazo. De este modo vuelvo a la sencillez del balancín pero con menos rozamientos ya que puedo dar a los 4 motores una pequeña fuerza de modo que los hilos sean sólo un elemento de seguridad sustentándolo ligeramente. Sin embargo me han sugerido que lo mejor es hacer las pruebas sujetando el cuadricóptero con una mano en el centro. Probablemente empezaré de esa forma y cuando lo tenga algo controlado pasaré a lo de los hilos.
Suscribirse a:
Entradas (Atom)