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.
sábado, 11 de mayo de 2013
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.
martes, 28 de agosto de 2012
Control motores Parte 2
Como continuación a Control motores Parte 1 escribo esta entrada en la que explico el cambio en la concepción del código que permite tener una gran precisión en los tiempos, sumamente importantes para que las señales enviadas a los variadores produzcan una regulación suave y precisa. Es tan grande el cambio en la concepción del programa y su precisión que paso a la versión 2.0.
El código está preparado para el control de los 4 motores si bien su estructura permite de forma fácil ampliarlo para el control de más motores o servos.
Para no aburrir con todo el largo proceso de prueba y error de las distintas formas que se me ocurría y que finalmente no funcionaban, paso a describir el funcionamiento de la opción adoptada.
Hay que tener en cuenta que donde necesitamos gran precisión es en el tiempo que están activadas (en HIGH) las salidas. El tiempo de ciclo de 20 ms no tiene gran importancia que tenga pequeñas variaciones, de hecho las hay de una emisora a otra (en mi emisora Turnigy TGY 9X tengo calculado unos 19 ms) y si movemos varias palancas de la emisora a la vez el tiempo de ciclo de cada canal puede variar en algún milisegundo. Es más, podéis hacer la prueba en el código a cambiar el tiempo de ciclo en
if (micros() - TiempoControlCiclo >= 20000)
y en lugar de los 20000 µs poner valores mayores o inferiores. Si lo probáis con un servo con tiempos inferiores (por ejemplo 5000) veréis que al intentar mover la palanca del servo su respuesta es más limpia y no tiembla tanto ya que está actualizando su posición más veces por segundo (el cuádruple para un tiempo de 5000). En cambio si hacemos la prueba con valores más grandes, por ejemplo 50000, comprobamos que podemos mover más fácilmente la palanca de su posición ya que el servo está actualizándose menos veces por segundo, en nuestro ejemplo 2,5 veces más lento.
Para conseguir la mayor precisión en tiempo en el HIGH tenemos que utilizar la instrucción delaymicroseconds() que tiene una precisión de 1 µs. Si utilizamos la función micros() su precisión es de 4 µs. La idea es ordenar los pulsos de menor a mayor, activar todas las salidas e ir desactivándolas con los delay. El tema es que esas instrucciones llevan un tiempo ejecutarlas además de que no se puede utilizar el delay si queremos que sea de 0 segundos. La solución es decalar los pulsos, es la constante "Retardo" que establezco en 10 µs. Así siempre podemos utilizar la instrucción delaymicroseconds() cuyo valor para cada salida se calcula según el pulso, el retardo y el tiempo de ejecución de las instrucciones que ha sido calculado empíricamente. Los cálculos de ordenar los pulsos y recalcular los tiempos de delay se calculan antes de establecer los HIGH de modo que conseguimos tener unos tiempos muy precisos para los pulsos. Además todo el código es ejecutado en un tiempo reducido, unos 32 µs los primeros cálculos más el decalaje (para 4 motores son 30 µs) más el tiempo del mayor pulso que en el caso de motores es de unos 2000 µs y para servos 2500 µs.
Aquí tenéis el código con algún comentario que espero sea suficiente para entenderlo. Mi idea a medio plazo es sacar otra versión preparada para manejar algunos servos además de los 4 motores.
Archivo para Arduino 1.0.1: Control motores v2.0
El código está preparado para el control de los 4 motores si bien su estructura permite de forma fácil ampliarlo para el control de más motores o servos.
Para no aburrir con todo el largo proceso de prueba y error de las distintas formas que se me ocurría y que finalmente no funcionaban, paso a describir el funcionamiento de la opción adoptada.
Hay que tener en cuenta que donde necesitamos gran precisión es en el tiempo que están activadas (en HIGH) las salidas. El tiempo de ciclo de 20 ms no tiene gran importancia que tenga pequeñas variaciones, de hecho las hay de una emisora a otra (en mi emisora Turnigy TGY 9X tengo calculado unos 19 ms) y si movemos varias palancas de la emisora a la vez el tiempo de ciclo de cada canal puede variar en algún milisegundo. Es más, podéis hacer la prueba en el código a cambiar el tiempo de ciclo en
if (micros() - TiempoControlCiclo >= 20000)
y en lugar de los 20000 µs poner valores mayores o inferiores. Si lo probáis con un servo con tiempos inferiores (por ejemplo 5000) veréis que al intentar mover la palanca del servo su respuesta es más limpia y no tiembla tanto ya que está actualizando su posición más veces por segundo (el cuádruple para un tiempo de 5000). En cambio si hacemos la prueba con valores más grandes, por ejemplo 50000, comprobamos que podemos mover más fácilmente la palanca de su posición ya que el servo está actualizándose menos veces por segundo, en nuestro ejemplo 2,5 veces más lento.
Para conseguir la mayor precisión en tiempo en el HIGH tenemos que utilizar la instrucción delaymicroseconds() que tiene una precisión de 1 µs. Si utilizamos la función micros() su precisión es de 4 µs. La idea es ordenar los pulsos de menor a mayor, activar todas las salidas e ir desactivándolas con los delay. El tema es que esas instrucciones llevan un tiempo ejecutarlas además de que no se puede utilizar el delay si queremos que sea de 0 segundos. La solución es decalar los pulsos, es la constante "Retardo" que establezco en 10 µs. Así siempre podemos utilizar la instrucción delaymicroseconds() cuyo valor para cada salida se calcula según el pulso, el retardo y el tiempo de ejecución de las instrucciones que ha sido calculado empíricamente. Los cálculos de ordenar los pulsos y recalcular los tiempos de delay se calculan antes de establecer los HIGH de modo que conseguimos tener unos tiempos muy precisos para los pulsos. Además todo el código es ejecutado en un tiempo reducido, unos 32 µs los primeros cálculos más el decalaje (para 4 motores son 30 µs) más el tiempo del mayor pulso que en el caso de motores es de unos 2000 µs y para servos 2500 µs.
Aquí tenéis el código con algún comentario que espero sea suficiente para entenderlo. Mi idea a medio plazo es sacar otra versión preparada para manejar algunos servos además de los 4 motores.
Archivo para Arduino 1.0.1: Control motores v2.0
martes, 24 de julio de 2012
Leer emisora RC Parte 2
Como continuación a Leer emisora RC Parte 1 escribo esta entrada en la que explico las mejoras necesarias que he introducido en el código. Son varios los cambios introducidos que producen una estabilidad muy grande en la medición de los canales y por eso paso a la versión 2.0.
Recordemos que el código original tenía unas variaciones en las mediciones que oscilaban en unos 12 µs. Aunque pueda parecer poco con las pruebas que he ido haciendo es relativamente importante. Si en 20 ms o 40 ms (uno o dos ciclos) se produce esa variación brusca le estamos indicando al programa del cuadricóptero que queríamos esa variación brusca, los PID se pondrán en marcha y las señales finales a los motores también. Uno o dos ciclos más tarde estaremos indicando un cambio brusco en dirección contrario. El resultado será que no conseguiremos un ajuste fino del cuadricóptero ni una buena estabilidad. El suavizado de las lecturas mediante el promedio de las últimas lecturas (6 por defecto) aminora estos efectos pero tras estudiar el problema a fondo podemos mejorarlo mucho más.
En primer lugar tenemos que estudiar por qué se produce esa variación en las medidas y he encontrado dos causas. Lo primero es pensar en la precisión de la propia emisora pero elimino esta posibilidad ya que cualquier motor con su ESC o servo funciona con una precisión y estabilidad exquisita cuando se maneja directamente con la emisora.
Causas encontradas:
La primera es la precisión en la medición del tiempo. La función micros() tiene una medición mínima de 4 µs, esto es, no nos da lecturas de por ejemplo 9 µs, 10 µs o 11 µs. Nos da lecturas de 8 µs o 12 µs. Sobre esta función no podemos hacer directamente nada.
La segunda es la velocidad en la ejecución del código. Para muchas cosas Arduino es suficientemente rápido pero en casos como el que nos lleva vemos que se vuelve lento. Vamos con la pequeña parte del código en la que esto se produce:
while (digitalRead(2) == 1) {
if ((micros() - TiempoParcial1) > 2000) {
ErrorRadio = true;
break;
}
else {
ErrorRadio = false;
}
}
Aunque son muy pocas instrucciones cada una de ellas lleva algún microsegundo ejecutarla. El problema es que al estar todo dentro de un while el tiempo de ejecución no es fijo. Pongamos que el micro ejecuta la primera instrucción, el while. Lee la entrada y ve que es 1. Entonces sigue ejecutando todo el resto de instrucciones de modo que si nada más ejecutar la primera la entrada pasa a 0 no se dará cuenta hasta que vuelva otra vez al while lo que supone añadir el tiempo de ejecutar todas las instrucciones. Y eso para Arduino son unos cuantos microsegundos. En el siguiente ciclo sin embargo puede pasar que justo cuando la entrada cambia a 0 es cuando se ejecuta el while por lo que saldrá ya del mismo sin apenas pérdida de tiempo.
Aleatoriamente las dos causas se van sumando o restando. Entre la anulación máxima o la suma máxima tenemos esa variación de 12 µs (que en alguna lectura esporádica llega incluso a 16 µs).
Entonces, ¿qué podemos hacer? Sobre la precisión de micros() directamente nada. Y en la serie de instrucciones del while todas son necesarias y no conozco ninguna forma de optimizarlo salvo la instrucción (digitalRead(2) == 1). Esta instrucción del IDE está compuesta por una docena de instrucciones del micro. Las mediciones que he realizado me da que el tiempo de ejecución para la instrucción a = digitalRead(2) es de 4,8 µs. Hay otra forma de leer una entrada que es con los registros del micro. Para un Atmega 168/328 la instrucción es a = bitRead(PIND, 2) y he calculado un tiempo de ejecución de tan solo 0,06 µs. Utilizando esto el ahorro de tiempo es muy importante. Una prueba preliminar simplemente cambiando esta instrucción hace que el rizado en la medición baje a 8 µs con muchas zonas de 4 µs. Es más esporádica una variación de 12 µs. Pero además el rizado es menos caótico haciendo que el promedio de lecturas sea más estable.
Sólo hay un problema y es que el mapeo de pines puede ser distinto y de hecho lo es de un micro a otro en el IDE. En concreto para los micros Atmega 8/168/328 el mapeo es el mismo pero en el Atmega 2560 cambia y en el Atmega 32U4 de la nueva placa Leonardo también. La instrucción sólo está probada para Atmega 8/168/328 pero anoto cómo debería ser para los otros micros aunque repito que no lo he probado:
Cualquier micro Atmega 8/168/328 Atmega 2560 Atmega 32U4
Pin digital 2 digitalRead(2) bitRead(PIND, 2) bitRead(PINE, 4) bitRead(PIND, 1)
Pin digital 3 digitalRead(3) bitRead(PIND, 3) bitRead(PINE, 5) bitRead(PIND, 0)
Pin digital 4 digitalRead(4) bitRead(PIND, 4) bitRead(PING, 5) bitRead(PIND, 4)
Implementada esta mejora y con el promedio de los últimos 6 valores tomados se consigue tener un rizado máximo de unos 2 µs. Aunque tengo en mente otra posible mejora a nivel de filtrado por el momento considero el código totalmente operativo aunque más adelante tal vez me ponga a mejorarlo.
Por último, como este código es el que usaremos como base de tiempos en el código completo del cuadricóptero hay que tener previsto un sustituto ante fallo de la emisora. Así, si se produce algún fallo la variable ErrorRadio se vuelve true pero tenemos que, además de seguir intentando volver a leer la emisora, establecer una rutina que haga que el resto del código siga ejecutándose cada 20 ms. Con tan sólo tres líneas de código ha quedado implementado
Archivo para Arduino 1.0.1: Leer radio v2.0
Recordemos que el código original tenía unas variaciones en las mediciones que oscilaban en unos 12 µs. Aunque pueda parecer poco con las pruebas que he ido haciendo es relativamente importante. Si en 20 ms o 40 ms (uno o dos ciclos) se produce esa variación brusca le estamos indicando al programa del cuadricóptero que queríamos esa variación brusca, los PID se pondrán en marcha y las señales finales a los motores también. Uno o dos ciclos más tarde estaremos indicando un cambio brusco en dirección contrario. El resultado será que no conseguiremos un ajuste fino del cuadricóptero ni una buena estabilidad. El suavizado de las lecturas mediante el promedio de las últimas lecturas (6 por defecto) aminora estos efectos pero tras estudiar el problema a fondo podemos mejorarlo mucho más.
En primer lugar tenemos que estudiar por qué se produce esa variación en las medidas y he encontrado dos causas. Lo primero es pensar en la precisión de la propia emisora pero elimino esta posibilidad ya que cualquier motor con su ESC o servo funciona con una precisión y estabilidad exquisita cuando se maneja directamente con la emisora.
Causas encontradas:
La primera es la precisión en la medición del tiempo. La función micros() tiene una medición mínima de 4 µs, esto es, no nos da lecturas de por ejemplo 9 µs, 10 µs o 11 µs. Nos da lecturas de 8 µs o 12 µs. Sobre esta función no podemos hacer directamente nada.
La segunda es la velocidad en la ejecución del código. Para muchas cosas Arduino es suficientemente rápido pero en casos como el que nos lleva vemos que se vuelve lento. Vamos con la pequeña parte del código en la que esto se produce:
while (digitalRead(2) == 1) {
if ((micros() - TiempoParcial1) > 2000) {
ErrorRadio = true;
break;
}
else {
ErrorRadio = false;
}
}
Aunque son muy pocas instrucciones cada una de ellas lleva algún microsegundo ejecutarla. El problema es que al estar todo dentro de un while el tiempo de ejecución no es fijo. Pongamos que el micro ejecuta la primera instrucción, el while. Lee la entrada y ve que es 1. Entonces sigue ejecutando todo el resto de instrucciones de modo que si nada más ejecutar la primera la entrada pasa a 0 no se dará cuenta hasta que vuelva otra vez al while lo que supone añadir el tiempo de ejecutar todas las instrucciones. Y eso para Arduino son unos cuantos microsegundos. En el siguiente ciclo sin embargo puede pasar que justo cuando la entrada cambia a 0 es cuando se ejecuta el while por lo que saldrá ya del mismo sin apenas pérdida de tiempo.
Aleatoriamente las dos causas se van sumando o restando. Entre la anulación máxima o la suma máxima tenemos esa variación de 12 µs (que en alguna lectura esporádica llega incluso a 16 µs).
Entonces, ¿qué podemos hacer? Sobre la precisión de micros() directamente nada. Y en la serie de instrucciones del while todas son necesarias y no conozco ninguna forma de optimizarlo salvo la instrucción (digitalRead(2) == 1). Esta instrucción del IDE está compuesta por una docena de instrucciones del micro. Las mediciones que he realizado me da que el tiempo de ejecución para la instrucción a = digitalRead(2) es de 4,8 µs. Hay otra forma de leer una entrada que es con los registros del micro. Para un Atmega 168/328 la instrucción es a = bitRead(PIND, 2) y he calculado un tiempo de ejecución de tan solo 0,06 µs. Utilizando esto el ahorro de tiempo es muy importante. Una prueba preliminar simplemente cambiando esta instrucción hace que el rizado en la medición baje a 8 µs con muchas zonas de 4 µs. Es más esporádica una variación de 12 µs. Pero además el rizado es menos caótico haciendo que el promedio de lecturas sea más estable.
Sólo hay un problema y es que el mapeo de pines puede ser distinto y de hecho lo es de un micro a otro en el IDE. En concreto para los micros Atmega 8/168/328 el mapeo es el mismo pero en el Atmega 2560 cambia y en el Atmega 32U4 de la nueva placa Leonardo también. La instrucción sólo está probada para Atmega 8/168/328 pero anoto cómo debería ser para los otros micros aunque repito que no lo he probado:
Cualquier micro Atmega 8/168/328 Atmega 2560 Atmega 32U4
Pin digital 2 digitalRead(2) bitRead(PIND, 2) bitRead(PINE, 4) bitRead(PIND, 1)
Pin digital 3 digitalRead(3) bitRead(PIND, 3) bitRead(PINE, 5) bitRead(PIND, 0)
Pin digital 4 digitalRead(4) bitRead(PIND, 4) bitRead(PING, 5) bitRead(PIND, 4)
Implementada esta mejora y con el promedio de los últimos 6 valores tomados se consigue tener un rizado máximo de unos 2 µs. Aunque tengo en mente otra posible mejora a nivel de filtrado por el momento considero el código totalmente operativo aunque más adelante tal vez me ponga a mejorarlo.
Por último, como este código es el que usaremos como base de tiempos en el código completo del cuadricóptero hay que tener previsto un sustituto ante fallo de la emisora. Así, si se produce algún fallo la variable ErrorRadio se vuelve true pero tenemos que, además de seguir intentando volver a leer la emisora, establecer una rutina que haga que el resto del código siga ejecutándose cada 20 ms. Con tan sólo tres líneas de código ha quedado implementado
Archivo para Arduino 1.0.1: Leer radio v2.0
Control motores Parte 1
Tal y como ya se ha comentado en Motores el tipo de los mismos es brushless y su control se realiza mediante los ESC. La forma de controlar un ESC es la misma que la de un servo ya que los dos elementos están pensados para ser manejados directamente desde una emisora RC.
La forma más sencilla de manejarlos desde Arduino es con la libraría Servo.h. Sin embargo esta librería funciona mediante interrupciones y en mi código quiero evitarlas. ¿Por qué? Porque las interrupciones afectan a la precisión en la medición de tiempos algo que es vital en el cuadricóptero. Por un lado estoy tratando de eliminar al máximo el rizado que se produce en la lectura de los canales de la emisora RC, si se produce una interrupción en un momento cercano a la toma de tiempos éstos varían produciendo rizados mayores.
Por tanto el código que estoy desarrollando tendrá un tiempo de ciclo de 20 ms que es el que tiene las señales de la emisora RC y por tanto el de los ESC (para los motores). Las lecturas del AHRS también se realizan cada 20 ms. En cada ciclo realizaremos todas las operaciones de forma secuencial y no será necesario utilizar interrupciones.
Esta primera versión del código es poco eficiente ya que adolece de los mismos fallos que se producen en Leer emisora RC en cuanto a la precisión de tiempos y el rizado que se produce sobre el que también estoy trabajando. Sin embargo lo expongo para que se vea el proceso básico de programación y así también será más fácil seguir la programación del código mejorado para cuando lo tenga implementado.
Archivo para Arduino 1.0.1: Control motores v1.0
Tenéis una nueva entrada en Control motores Parte 2 en donde he desarrollado un nuevo código muy preciso.
La forma más sencilla de manejarlos desde Arduino es con la libraría Servo.h. Sin embargo esta librería funciona mediante interrupciones y en mi código quiero evitarlas. ¿Por qué? Porque las interrupciones afectan a la precisión en la medición de tiempos algo que es vital en el cuadricóptero. Por un lado estoy tratando de eliminar al máximo el rizado que se produce en la lectura de los canales de la emisora RC, si se produce una interrupción en un momento cercano a la toma de tiempos éstos varían produciendo rizados mayores.
Por tanto el código que estoy desarrollando tendrá un tiempo de ciclo de 20 ms que es el que tiene las señales de la emisora RC y por tanto el de los ESC (para los motores). Las lecturas del AHRS también se realizan cada 20 ms. En cada ciclo realizaremos todas las operaciones de forma secuencial y no será necesario utilizar interrupciones.
Esta primera versión del código es poco eficiente ya que adolece de los mismos fallos que se producen en Leer emisora RC en cuanto a la precisión de tiempos y el rizado que se produce sobre el que también estoy trabajando. Sin embargo lo expongo para que se vea el proceso básico de programación y así también será más fácil seguir la programación del código mejorado para cuando lo tenga implementado.
Archivo para Arduino 1.0.1: Control motores v1.0
Tenéis una nueva entrada en Control motores Parte 2 en donde he desarrollado un nuevo código muy preciso.
domingo, 27 de mayo de 2012
Batería
Mucho se ha avanzado en el desarrollo de baterías y sin embargo se sigue investigando ya que todavía distan de ser el elemento con las características que nos gustaría que tuviera. ¿Cuáles son las características esenciales de una batería?
- La tensión.
- La capacidad: la cantidad de energía que puede acumular.
- El peso.
- Intensidad de descarga.
- Tiempo de carga.
- La tensión: las distintas tecnologías existentes almacenan energía eléctrica primariamente a niveles de tensión relativamente bajos, entre 1 V y 4 V aproximadamente. Para la mayoría de usos se necesitan tensiones mayores. La solución es que construyen las baterías con varias celdas en serie de modo que la tensión total es la suma de las tensiones de todas las celdas. En los procesos de carga y descarga las tensiones van aumentando y disminuyendo respectivamente. Tener variaciones en la tensión de alimentación en principio no es bueno sin embargo tiene su pequeña ventaja y es que estas variaciones nos sirven para detectar el estado de carga de la batería y sabremos cuándo hay que terminar la carga o la descarga.
- La capacidad: es la cantidad de energía que almacena. Suele expresarse en mAh (miliamperios hora). Así, una batería de 2.600 mAh nos puede suministrar 2.600 mA durante una hora. Sabiendo el consumo medio que le vamos a solicitar podremos calcular el tiempo aproximado que nos durará. Si con esa batería estamos consumiendo 0,8 A el tiempo que nos durará será 2.600 / 800 = 3,25 horas (3 horas y 15 minutos).
- El peso: es un dato muy importante ya que una batería actualmente tiene un peso considerable para la cantidad de energía que puede almacenar. En general será una limitación en muchas aplicaciones y en particular en vehículos, ya sean terrestres y sobretodo aéreos, supone una gran limitación ya que gran parte de la energía de la batería se gasta en tener que transportar el propio peso de la batería. Y eso que podemos considerar el gran avance que han supuesto las batería de tecnología lipo (polímero de litio) que han reducido el peso considerablemente con respecto a las tecnologías existentes hasta entonces. Planteo un pequeño cálculo rápido para hacernos a la idea del gran peso de una batería para la energía que almacena. La compararemos con la energía que produce el gasoil. Aproximadamente un kg de gasoil puede producir unos 40 MJ (megajulios). El rendimiento de un motor térmico diesel puede llegar hasta un máximo de un 45%. Esto hace que de un kg de gasoil en nuestro motor aprovecharemos 40 x 0,45 = 18 MJ. Por otro lado una batería lipo de 5000 mAh y 3S pesa unos 390 g. La energía que almacena es 5 x 11,1 = 55,5 Wh. Por kg la energía almacenada será 55,5 / 0,39 = 142,3 Wh que son unos 0,5 MJ. Los motores brushless pueden tener un rendimiento del 80% lo que hace que el aprovechamiento final sea de 0,5 x 0,8 = 0,4 MJ. Si comparamos el aprovechamiento del gasoil y de una batería lipo tenemos 18 / 0,4 = 45 veces. En términos de combustible y su peso vemos que a la tecnología de almacenamiento eléctrico le falta mucho, tendrían que disminuir en 45 veces el peso de una batería. Es uno de los grandes retos tecnológicos actuales.
- Intensidad de descarga: cada batería tiene una intensidad máxima que puede suministrar que se expresa en el número de veces la intensidad nominal. Nosotros tenemos en mente que nos interesa una batería con la mayor intensidad de descarga. Pero a nivel práctico hay que tener un par de consideraciones. La primera y en general para las aplicaciones de las baterías, no todos los usos necesitan priorizar la posibilidad de una gran descarga. Hay casos en los que se necesita una descarga muy baja a base de mejorar otras características como una baja autodescarga.
En el caso de aeromodelos hay que tener muy presente que no siempre la batería con mayor intensidad de descarga será la mejor ya que aumentar esto hace aumentar también el peso de la batería. Mi recomendación es que si se construye un aeromodelo (en nuestro caso un cuadricóptero) para vuelo acrobático por supuesto que buscaremos una batería de alta intensidad de descarga; para que no aporte excesivo peso a nuestro cuadricóptero tendremos que ajustar su capacidad y tendremos vuelos de corta duración, hablamos de 6 ó 7 minutos.
Pero si lo que queremos es vuelos tranquilos y aumentar el tiempo de vuelo (por ejemplo para uso en fotografía o vídeo aéreo) lo que haremos es elegir una batería con la mínima intensidad de descarga para que sea más ligera. El peso ahorrado lo podremos utilizar en aumentar la capacidad de la batería. Por supuesto siempre hay que tener en cuenta que la batería sea capaz de suministrar la intensidad requerida por los motores, la suma de los cuatro en el caso de un cuadricóptero.
- Tiempo de carga: interesa que sea lo más corto posible. Pero hay que saber que cuanto más apuremos el tiempo de carga y lo hagamos a una intensidad mayor, más se acorta la vida de nuestra batería.
Con estos parámetros pasamos a concretar los que tienen las baterías lipo ampliamente usadas en la actualidad.
La tensión nominal de una celda básica es de 3,7 V. Cuando está totalmente cargada llega a 4,2 V (momento en el que hay que dejar de cargar) y al descargarse nunca hay que dejar que baje de los 3 V ya que se destruye sin opción a ser recuperada. Para tener tensiones mayores se unen en serie varias celdas y se expresa con el número de celdas seguido de una S mayúscula. Así las más usadas, una batería 3S tiene 3 celdas en serie y por tanto una tensión nominal de 3 x 3,7 = 11,1 V.
La capacidad, el peso y la intensidad de descarga son tres parámetros estrechamente relacionados. Si queremos mejorar alguno nos empeorará otro.
El tiempo de carga depende de la intensidad a la que realicemos la carga. La intensidad máxima a la que se puede cargar viene expresada mediante un número seguido de una C mayúscula. La mayoría de las lipo actuales suelen ser 2C, es decir, admiten una intensidad de carga de 2 veces la capacidad nominal. Una lipo de 2600 mAh y 2C podremos cargarla a 2 x 2,6 = 5,2 A. Sin embargo apurar esta intensidad de carga acortará la vida de nuestra batería. Yo recomiendo cargarlas a 1C.
Por último hay que extremar las precauciones con las lipo debido al riesgo potencial que tienen. En determinadas circunstancias pueden llegar incluso a explotar. Es imperativo comprar una bolsa aislante especial en la que meteremos la batería siempre que vayamos a cargarla. No me extiendo en este tema pero os recomiendo que hagáis algunas búsquedas en Google sobre las precauciones que hay que tomar con las lipo.
- La tensión.
- La capacidad: la cantidad de energía que puede acumular.
- El peso.
- Intensidad de descarga.
- Tiempo de carga.
- La tensión: las distintas tecnologías existentes almacenan energía eléctrica primariamente a niveles de tensión relativamente bajos, entre 1 V y 4 V aproximadamente. Para la mayoría de usos se necesitan tensiones mayores. La solución es que construyen las baterías con varias celdas en serie de modo que la tensión total es la suma de las tensiones de todas las celdas. En los procesos de carga y descarga las tensiones van aumentando y disminuyendo respectivamente. Tener variaciones en la tensión de alimentación en principio no es bueno sin embargo tiene su pequeña ventaja y es que estas variaciones nos sirven para detectar el estado de carga de la batería y sabremos cuándo hay que terminar la carga o la descarga.
- La capacidad: es la cantidad de energía que almacena. Suele expresarse en mAh (miliamperios hora). Así, una batería de 2.600 mAh nos puede suministrar 2.600 mA durante una hora. Sabiendo el consumo medio que le vamos a solicitar podremos calcular el tiempo aproximado que nos durará. Si con esa batería estamos consumiendo 0,8 A el tiempo que nos durará será 2.600 / 800 = 3,25 horas (3 horas y 15 minutos).
- El peso: es un dato muy importante ya que una batería actualmente tiene un peso considerable para la cantidad de energía que puede almacenar. En general será una limitación en muchas aplicaciones y en particular en vehículos, ya sean terrestres y sobretodo aéreos, supone una gran limitación ya que gran parte de la energía de la batería se gasta en tener que transportar el propio peso de la batería. Y eso que podemos considerar el gran avance que han supuesto las batería de tecnología lipo (polímero de litio) que han reducido el peso considerablemente con respecto a las tecnologías existentes hasta entonces. Planteo un pequeño cálculo rápido para hacernos a la idea del gran peso de una batería para la energía que almacena. La compararemos con la energía que produce el gasoil. Aproximadamente un kg de gasoil puede producir unos 40 MJ (megajulios). El rendimiento de un motor térmico diesel puede llegar hasta un máximo de un 45%. Esto hace que de un kg de gasoil en nuestro motor aprovecharemos 40 x 0,45 = 18 MJ. Por otro lado una batería lipo de 5000 mAh y 3S pesa unos 390 g. La energía que almacena es 5 x 11,1 = 55,5 Wh. Por kg la energía almacenada será 55,5 / 0,39 = 142,3 Wh que son unos 0,5 MJ. Los motores brushless pueden tener un rendimiento del 80% lo que hace que el aprovechamiento final sea de 0,5 x 0,8 = 0,4 MJ. Si comparamos el aprovechamiento del gasoil y de una batería lipo tenemos 18 / 0,4 = 45 veces. En términos de combustible y su peso vemos que a la tecnología de almacenamiento eléctrico le falta mucho, tendrían que disminuir en 45 veces el peso de una batería. Es uno de los grandes retos tecnológicos actuales.
- Intensidad de descarga: cada batería tiene una intensidad máxima que puede suministrar que se expresa en el número de veces la intensidad nominal. Nosotros tenemos en mente que nos interesa una batería con la mayor intensidad de descarga. Pero a nivel práctico hay que tener un par de consideraciones. La primera y en general para las aplicaciones de las baterías, no todos los usos necesitan priorizar la posibilidad de una gran descarga. Hay casos en los que se necesita una descarga muy baja a base de mejorar otras características como una baja autodescarga.
En el caso de aeromodelos hay que tener muy presente que no siempre la batería con mayor intensidad de descarga será la mejor ya que aumentar esto hace aumentar también el peso de la batería. Mi recomendación es que si se construye un aeromodelo (en nuestro caso un cuadricóptero) para vuelo acrobático por supuesto que buscaremos una batería de alta intensidad de descarga; para que no aporte excesivo peso a nuestro cuadricóptero tendremos que ajustar su capacidad y tendremos vuelos de corta duración, hablamos de 6 ó 7 minutos.
Pero si lo que queremos es vuelos tranquilos y aumentar el tiempo de vuelo (por ejemplo para uso en fotografía o vídeo aéreo) lo que haremos es elegir una batería con la mínima intensidad de descarga para que sea más ligera. El peso ahorrado lo podremos utilizar en aumentar la capacidad de la batería. Por supuesto siempre hay que tener en cuenta que la batería sea capaz de suministrar la intensidad requerida por los motores, la suma de los cuatro en el caso de un cuadricóptero.
- Tiempo de carga: interesa que sea lo más corto posible. Pero hay que saber que cuanto más apuremos el tiempo de carga y lo hagamos a una intensidad mayor, más se acorta la vida de nuestra batería.
Con estos parámetros pasamos a concretar los que tienen las baterías lipo ampliamente usadas en la actualidad.
La tensión nominal de una celda básica es de 3,7 V. Cuando está totalmente cargada llega a 4,2 V (momento en el que hay que dejar de cargar) y al descargarse nunca hay que dejar que baje de los 3 V ya que se destruye sin opción a ser recuperada. Para tener tensiones mayores se unen en serie varias celdas y se expresa con el número de celdas seguido de una S mayúscula. Así las más usadas, una batería 3S tiene 3 celdas en serie y por tanto una tensión nominal de 3 x 3,7 = 11,1 V.
La capacidad, el peso y la intensidad de descarga son tres parámetros estrechamente relacionados. Si queremos mejorar alguno nos empeorará otro.
El tiempo de carga depende de la intensidad a la que realicemos la carga. La intensidad máxima a la que se puede cargar viene expresada mediante un número seguido de una C mayúscula. La mayoría de las lipo actuales suelen ser 2C, es decir, admiten una intensidad de carga de 2 veces la capacidad nominal. Una lipo de 2600 mAh y 2C podremos cargarla a 2 x 2,6 = 5,2 A. Sin embargo apurar esta intensidad de carga acortará la vida de nuestra batería. Yo recomiendo cargarlas a 1C.
Por último hay que extremar las precauciones con las lipo debido al riesgo potencial que tienen. En determinadas circunstancias pueden llegar incluso a explotar. Es imperativo comprar una bolsa aislante especial en la que meteremos la batería siempre que vayamos a cargarla. No me extiendo en este tema pero os recomiendo que hagáis algunas búsquedas en Google sobre las precauciones que hay que tomar con las lipo.
lunes, 30 de abril de 2012
ESC
Probablemente ya sabes lo que es un ESC. En cualquier caso lo explico de forma rápida. Un ESC (Electronic Speed Control) es un equipo que lee la señal PWM de salida de una emisora RC y la convierte a la señal de potencia necesaria para alimentar un motor brushless. El ESC también nos permite el control de la velocidad del motor. La señal de control al ESC, típicamente la salida de los canales de una emisora RC, es la que reproduciremos desde nuestro Arduino.
Dos son las características principales que hay que tener en cuenta para la elección de un ESC.
En primer lugar el rango de tensión con el que está preparado para funcionar, normalmente expresado en las celdas de baterías lipo. Lo más común es un ESC para un rango entre 2S y 4S. En el caso de cuadricópteros lo más normal es con baterías lipo de 3S. Proyectos más ambiciosos de cuadricópteros de mayores tamaños para llevar más peso pueden proyectarse con baterías 4S.
La segunda característica es la intensidad capaz de suministrar. Este dato va directamente relacionado con las características de los motores seleccionados. Como es lógico nuestro ESC tiene que ser capaz de suministrar como mínimo la intensidad máxima del motor elegido, siempre teniendo en cuenta un pequeño margen de seguridad.
En mi caso como expliqué en Motores el consumo de los Turnigy 2209 a máxima potencia en continuo es de 12 A y el máximo puntual de 15 A. Por tanto mi elección de ESC es el Turnigy Sentry 18 A, con capacidad de 18 A en continuo y un pico puntual de hasta 22 A.
Siento no poder poner el enlace de este modelo de ESC pero es que Hobbyking ha dejado de fabricarlos, al menos no se encuentran en su catálogo de la web. Tal es así que yo había adquirido dos unidades de este modelo para hacer las primeras pruebas y al ir a comprar los otros dos tuve que coger el modelo Turnigy Plush 18 A. La diferencia es mínima, referente a otra característica de los ESC que explicaré un poco más adelante.
Otro aspecto de los ESC es que pueden llevar integrado un BEC, Battery Eliminator Circuit, traducido Circuito Eliminador de Batería. Así es, para nuestros motores necesitamos una batería por ejemplo de 3S que da 11,1 V. Sin embargo la alimentación de los servos y la electrónica de control se hace con 5 V. Pues bien, en lugar de poner otra batería que nos suministre esos 5 V la eliminamos y el BEC es quien nos los va a proporcionar.
Una última opción que puede llevar un ESC es el conector para la "Monitorización de descarga balanceada". Este conector está estandarizado y se denomina JST-XH. Es el mismo conector que traen las baterías lipo para la carga balanceada. Así conectaremos ESC y lipo con esta conexión de modo que el ESC estará midiendo continuamente la tensión de cada una de las celdas de la lipo. Cuando cualquiera de las celdas baje hasta los 3 voltios el ESC reducirá potencia a los motores protegiendo nuestra lipo de una descarga mayor que la haría inservible sin opción de recuperarla.
Los ESC de intensidades bajas y para tensiones sobre 3S o 4S como mucho el BEC suele ser lineal, es decir, lleva un regulador de tensión que hace que la diferencia de tensión de la lipo con los 5 V que suministra por la intensidad que circula la disipa en forma de calor. Sin duda es pérdida de energía que estamos sufriendo aunque no sea mucha comparada con la potencia consumida por los motores. Para evitar esta pérdida de energía están los BEC conmutados (en inglés switch). Su función es la misma pero su rendimiento energético está cercano al 100%. Muy útil cuando el consumo a través de los 5 V empieza a ser importante y sobre todo cuando la lipo es de 4S o superior.
Si nuestro ESC no tiene BEC o si es lineal y por las características de nuestro montaje nos supone una pérdida de energía a tener en cuenta podemos hacernos con un BEC externo. Comercialmente se denominan SBEC o UBEC, depende de fabricantes. En los dos casos son un BEC de conmutación.
Dos son las características principales que hay que tener en cuenta para la elección de un ESC.
En primer lugar el rango de tensión con el que está preparado para funcionar, normalmente expresado en las celdas de baterías lipo. Lo más común es un ESC para un rango entre 2S y 4S. En el caso de cuadricópteros lo más normal es con baterías lipo de 3S. Proyectos más ambiciosos de cuadricópteros de mayores tamaños para llevar más peso pueden proyectarse con baterías 4S.
La segunda característica es la intensidad capaz de suministrar. Este dato va directamente relacionado con las características de los motores seleccionados. Como es lógico nuestro ESC tiene que ser capaz de suministrar como mínimo la intensidad máxima del motor elegido, siempre teniendo en cuenta un pequeño margen de seguridad.
En mi caso como expliqué en Motores el consumo de los Turnigy 2209 a máxima potencia en continuo es de 12 A y el máximo puntual de 15 A. Por tanto mi elección de ESC es el Turnigy Sentry 18 A, con capacidad de 18 A en continuo y un pico puntual de hasta 22 A.
Siento no poder poner el enlace de este modelo de ESC pero es que Hobbyking ha dejado de fabricarlos, al menos no se encuentran en su catálogo de la web. Tal es así que yo había adquirido dos unidades de este modelo para hacer las primeras pruebas y al ir a comprar los otros dos tuve que coger el modelo Turnigy Plush 18 A. La diferencia es mínima, referente a otra característica de los ESC que explicaré un poco más adelante.
Otro aspecto de los ESC es que pueden llevar integrado un BEC, Battery Eliminator Circuit, traducido Circuito Eliminador de Batería. Así es, para nuestros motores necesitamos una batería por ejemplo de 3S que da 11,1 V. Sin embargo la alimentación de los servos y la electrónica de control se hace con 5 V. Pues bien, en lugar de poner otra batería que nos suministre esos 5 V la eliminamos y el BEC es quien nos los va a proporcionar.
Una última opción que puede llevar un ESC es el conector para la "Monitorización de descarga balanceada". Este conector está estandarizado y se denomina JST-XH. Es el mismo conector que traen las baterías lipo para la carga balanceada. Así conectaremos ESC y lipo con esta conexión de modo que el ESC estará midiendo continuamente la tensión de cada una de las celdas de la lipo. Cuando cualquiera de las celdas baje hasta los 3 voltios el ESC reducirá potencia a los motores protegiendo nuestra lipo de una descarga mayor que la haría inservible sin opción de recuperarla.
Los ESC de intensidades bajas y para tensiones sobre 3S o 4S como mucho el BEC suele ser lineal, es decir, lleva un regulador de tensión que hace que la diferencia de tensión de la lipo con los 5 V que suministra por la intensidad que circula la disipa en forma de calor. Sin duda es pérdida de energía que estamos sufriendo aunque no sea mucha comparada con la potencia consumida por los motores. Para evitar esta pérdida de energía están los BEC conmutados (en inglés switch). Su función es la misma pero su rendimiento energético está cercano al 100%. Muy útil cuando el consumo a través de los 5 V empieza a ser importante y sobre todo cuando la lipo es de 4S o superior.
Si nuestro ESC no tiene BEC o si es lineal y por las características de nuestro montaje nos supone una pérdida de energía a tener en cuenta podemos hacernos con un BEC externo. Comercialmente se denominan SBEC o UBEC, depende de fabricantes. En los dos casos son un BEC de conmutación.
Suscribirse a:
Entradas (Atom)