jueves, 23 de diciembre de 2010

La fuente de alimentación

El sistema de alimentación del robot se compone de dos baterías de LiPo y un sistema regulador de tensiones que suministra 12V(3A), 6V(1A)  y 5V(3+3 A).

En la imagen se ve la placa de la que se alimenta el robot y sus partes.



Hemos usado dos baterías ya que necesitamos tensiones desde 12V a 5V y al usamos reguladores de tensión de la seria 78XX.


El problemas es el siguiente:
 Si usamos un regulador de 12 V como el 7812, para que funcione correctamente se ha de alimentar como mínimo con 12V + 2V = 14V, nuestra batería es de 14,8 V, si el sistema consume 1 A a 12 V estaremos consumiendo 12W, pero como la batería suministra 14,8 V el consumo total del sistema será de

                                                       14,8 V x 1 A = 14,8W

los 2,8 W restante los disipa el regulador en forma de calor.

2,8 sobre 12 representa aproximadamente el 10% lo que puede ser aceptable, pero si con la misma batería alimentamos un regulador de 5V y suponemos que el sistema consume también 1 A

      Potencia consumida por el robot = 1 A x 5 V = 5W
      Potencia suministrada por la batería = 1 A x 14,8 V = 14,8 W

En este caso estamos disipando en forma de calor 9,8 W, ¡casi el doble que el consumo del propio robot!. El regulador se calentará muchísimo y el rendimiento de la batería es bajísimo.

Si para proporcionar 5V utilizamos una batería de 7,4 V
  
     Potencia consumida por el robot = 1 A x 5 V =  5W
     Potencia suministrada por la batería = 1 A x 7,4 V = 7,4 W

La diferencia es de 2,4 W que representa el 50% de la energía consumida por el robot, no es muy eficiente pero no es el caso anterior.
Hay que darse cuenta de que los cálculos los he hecho con un consumo de 1A, si este fuera mayor el rendimiento bajaría aun más.
Existen reguladores que tienen un eficiencia mucho mayor (96%)  que la serie 78XX pero son más caros (30$), http://www.robotgear.com.au/Product.aspx/Details/465 o más difíciles de conectar. En cualquier caso si la autonomía del robot es crítica se deberá recurrir a ellos. Con nuestro sistema el robot tiene un autonomía de dos hora aproximadamente.


En la placa se puede apreciar como los conectores de alimentación son de tres contactos con la siguiente configuración:


Hemos puesto el conector de alimentación de 3 pines en lugar de 2 para evitar accidentes, no tenemos que pensar cuál el + y cual GND y aunque lo giremos siempre tendrá + y GND en los mismos pines. Todas las placas que necesitan 5V tienen los conectores iguales. Además los cables serán todos iguales con lo cual son intercambiables.

El conector de las baterías son dobles en una se conectan los cables de la batería y en la otra los del cargador, de esta manera no tenemos que retirarlas, ni desconectarlas para cargarlas.

En caso de que el robot esté inmovil y queramos ahorrar carga de batería podemos alimentar el robot con un alimentador de proporciones 15V como mínimo (conector negro).
También existe un conector (el de color azul) para conectar un sola batería.

En esta foto se puede apreciar que falta un regulador de 5V que aún no se había instalado.

El conector de la derecha se usa para alimentar el router wifi y la placa de motores (12V).

Las Comunicaciones


   Finalmente las comunicaciones entre el robot y el PC se hacen a través de un router wifi sitecom 54g con 4 entradas ethernet, nos ha costado 30€, y va muy bien, en el no solo conectamos la CPU XMOS, sino también la camara IP. 



Se alimenta a 12V de la fuente de alimentación de robot y su consumo es bajo (menos de 0.2 A).
Con este router hemos solucionado "por fin" el problema de las comunicaciones entre PC y robot.

sábado, 11 de diciembre de 2010

La CPU (3ª parte)

La primera entrada de la CPU había finalizado diciendo que las comunicaciones por radio a través de un transceptor eran lentas para lo que necesitamos, decidimos entonces utilizar otra alternativa sin tener que modificar mucho nuestro sistema. Buscamos y encontramos un módulo RS232-Bluetooth que nos ofrecía unas transferencias de 2Mb/s, parecía bastante adecuado.


Desde el punto de vista del robot y del PC seguía siendo un RS232, en el PC conectamos bluetooth por USB ya que nuestro ordenador no veía con bluetooth.

Comenzamos con la pruebas de transmisión y efectivamente el bluetooth es muy rápido, pero .....,
resulta que una vez que el modulo recibe un paquete de datos espera entre 200ms y 300ms antes de empezar la transmisión, eso significa que si el robot le envía un mensaje al PC el módulo tarda sobre 300ms, el PC recibe el mensaje, lo procesa y da una respuesta que tarda otra vez !300ms! en llegar al robot, solamente en los retardos hemos empleado !600ms!, inaceptablemente lento, con los retardos era más lento que el transceptor.
Investigamos la forma de eliminar los retardos y no encontramos solución, parecía que era algo propio del módulo y del protocolo bluetooth.

Y ahora que hacemos, ¿como comunicamos el robot y el PC?. ¿Podríamos hacero por WIFI?, sería ideal, transmisiones muy rápidas. Pero entonces tendríamos que encontrar algún sistema RS232-ethernet-wifi, y buscando en la red encontramos el WIPORT, funcionaba muy bien, pero...., electrónicamente muy frágiles, le cambiamos la configuración por defecto y el wiport murió, escribimos a la casa pidiendo soporte y no nos solucionaron el problema. Era ideal si hubiera funcionado.

Empezamos a plantearnos cambiar el controlador PIC por otro que tuviera salida ethernet, pero entonces tendríamos que modificar la arquitectura del robot. Buscamos controladores basados en micro ARM y hay una gama interesantísima de placas para usarlas en robots, tienen compiladores y entornos de programación gratuitos y muchas ampliaciones, funcionan bajo el SO Linux.

Y en esas estabamos cuando en una página de placas controladoras ARM veo un anuncio de XMOS,
http://www.xmos.com/products/development-kits/xc-2-ethernet-kit, accedo a el y encuentro unos nuevos chips diseñados especialmente para controlar elementos de hardware y que parecía la respuesta perfecta a nuestras plegarias.
Esta placa tenía salida ethernet, se programaba en C, C++ y XC (XC es un C escrito específicamente para estos micros y cuya característica más importante es la de carecer de punteros) en un entorno de desarrollo gratuito basado en eclipse, con lo cual corría en cualquier sistema operativo.


   Existen varias tipos de chips XMOS, estos micros son "alucinantes", el que tiene la placa ethernet contiene 4 núcleos, tiene tanta potencia que es capaz de hacer una ethernet por software, manejando uno de los núcleos todas las señales y los protocolos ethernet y TCP/IP, como demo viene grabado un servidor WEB en la flash.
   Cada uno de los núcleos es capaz de ejecutar 8 tareas simultaneamente sin cargar ningún sistema operativo, cada tarea tiene su propio juego exclusivo de registros , es como si cada cpu fueran ocho.
Las tareas se comunican entre si por medio de canales de comunicaciones definidos por software.
Recomiendo leer la documentación que suministra XMOS.

Con este controlador no hubo necesidad de cambiar la arquitectura de nuestro robot, utilizamos cada una de las tareas como si se tratara de un controlador con un PIC, con lo cual la capacidad de esta placa es de 8 tareas x 4 núcleos = 32 tareas o 32 placas controladoras como la que teníamos, en realidad es más potente que esos 32 pic juntos.
En lugar del bus I2C tenemos los canales de comunicaciones y la ethernet como el sustituto del RS232.
El funcionamiento es impresionante por su elegancia y rápidez.
El consumo de la placa es aproximandemente 500mA a 5V = 2,5 W. bastante contenido.

Para conectar los sensores al controlador diseñamos un placa que nos expande los buses, esta placa la enviamos a fabricar a http://www.custompcb.com/ que ofrece un servicio rápido (en 15 días desde el envio por correo electrónico del diseño a la recepción en casa) y aceptable de precio (80€ por 6 placas).


Existen dos placas como esta, cada uno de los núcleos (1, 2 y 3) tiene dos conectores, con lo cual el número de puertos y conectores es el doble del de la foto.

Podemos tener por núcleo (excepto el 0):

8 puertos de I/O de 1 bit.
2 puertos de I/O de 8 bits o 1 puerto de 16 bit, o 4 puertos de 4  bits o 1 puerto de 8 bits y 2 de 4 bits.

Algunos de estos puertos están ocupados en el núcleo 2 por el conector ethernet (4 bits creo).

Cada conector de la placa tiene además pines de +5V y GND.

miércoles, 8 de diciembre de 2010

La CPU (2ª parte)

   En esta entrada mostraré una imagen del estado del robot cuando "funcionaba" con la emisora, en ella se ven apiladas las placas de CPU con el cable de conexión del bus I2C a la derecha y el transceptor en la parte superior del robot y a su lado el compás (brújula), se aprecian también los conectores del puerto A de las placas en la parte delantera, en la parte inferior la fuente de alimentación del sistema y en la parte posterior el controlador de motores y servos.

  El robot esta ejecutando pruebas de comunicaciones, para ello hemos hecho un sigue lineas (permite olvidarnos de controlar los movimientos del robot) mientras nos comunicamos y leemos los sensores, paramos y lo arrancamos nuevamente,  todo ello controlado desde el PC.

martes, 7 de diciembre de 2010

La CPU

   Una vez visto los componentes del robot y como se distribuyen sobre la plataforma pasemos a hablar del controlador.

   Desde el inicio del proyecto planteamos para el robot una arquitectura distribuida, donde múltiples cpu's se reparten la tarea de controlar el robot, cada cpu se encarga de controlar un sensor. Todas las cpu's se comunican entre sí por medio del bus I2C en modo multimaster y una de ellas con el PC a través del bus RS232  a un transceptor que transmite y recibe la información.

   Esta arquitectura distribuida tiene la ventaja de que no necesitaremos un procesador muy potente,  costoso o difícil de programar, además en caso de que fallará un sensor tanto en software como en hardware no bloquearía el sistema, se bloquearía la cpu encargada de ese sensor, pudiendo además implementar un sistema de reinicio de esa cpu. Los microcontrolares tienen un sistema contra bloqueos que se llama watchdog (consiste en un contador que si no se actualiza su valor reinicia la cpu), que garantiza que siempre este activa.

   La mayor dificultad en diseñar un sistema distribuido está en la programación del sistema de comunicaciones entre cpu's y entre las cpu's y el PC.

   Nosotros diseñamos un sistema de comunicaciones basado en mensajes, cuyo formato es:

  [ longitud | cpu | comando | byte1 | byte2 | ... | byten | checksum ]

 donde:

  longitud = longitud del paquete
  cpu = número de la cpu a la que se dirige el paquete
  comando = comando que debe ejecutar la cpu
  byte1, byte2, ..., byten = n  byte que forman el comando,  n>=0
  checksum = suma de comprobación del mensaje

   La primera version del sistema estaba basada en el microcontrolador PIC 16F876, con tres puertos de i/o, puertos RS232, I2C, convertidores A/D, múltiples contadores, etc., bastante adecuado y completo para nuestro robot.

  En la imagen muestro una de las placas controladoras (1 cara y 2 puentes):



 Se pueden observar todos los conectores, además del de programación y depuración y el de reset externo.

 Como se ha indicado el sistema lo componían múltiples CPU conectadas entre sí por el bus I2C y a traves del un puerto RS232 con un transceptor al robot, el primer transceptor que usamos es el que se muestra en la foto:

permite transmitir en modo half duplex (transmitir o recibir información no simultaneamente) hasta 115200 bits/seg.

   El sistema funcionaba razonablemente bien, una CPU se ocupaba de las transmisiones, otra del sistema servo/sonar, otra de la brújula y otra de los bumpers/sensores IR, aunque era muy lento en las comunicaciones con el PC para lo que pretendíamos.


   En esos momentos pensamos en alguna alternativa a las comunicaciones por radio, y encontramos la posibilidad de hacerlas por bluetooth, ya que existen conversores RS232-bluetooth con lo cual solo tendríamos que sustituir el transceptor por el bluetooth, y este alcanzaba los 2Mb/sg.