sábado, 22 de enero de 2011

Watson, el superordenador de IBM más listo del mundo gana los encuentros previos de Jeopardy

He leido en http://sinapsis-aom.blogspot.com/2011/01/watson-el-superordenador-de-ibm-mas.html  el artículo que título a esta entrada y la verdad que es deprimente si albergamos la esperanza de ver algún día una inteligencia artificial, el sistema creado por IBM no reconoce ni el lenguaje hablado y el ordenador es una auténtica bestia:


  • 10 racks servidores POWER7 750
  • ejecutando el sistema operativo Linux
  • con 15 terabytes de RAM y 2,880 nucleos (cores) de procesador
  • hasta 80 teraflops (80.000.000.000.000 operaciones por segundo)
¿Que podemos hacer nosotros con un sistema móvil como el que estamos construyendo?, aunque el nuestro tiene un enlace WIFI de alta velocidad que nos permite que el tratamiento de la información que recogen los sensores sean tratados en el PC (o una red de PC's si el programa podemos hacerlos distribuido). 
No se que actitud tomar, si deprimirme o pensar que pueda existir algún paradigma sobre la inteligencia y la programación que permita simplificar los programas y ejecutarlos en una máquina menos potente. 
Alan Turing en su artículo Maquinaria, computadora e inteligencia ("Mind" vol. LIX n. 236, 1950) donde se pregunta s¿pueden pensar las máquinas?, hace una estimación de  que capacidad de almacenamiento deberá tener un ordenador para jugar el juego de la imitación, este juego consiste en la interacción a través de un terminal entre dos humanos o entre un humano y un ordenador, si el humano no es capaz de distinguir si está hablando con un humano o con un ordenador se puede suponer que el ordenador es capaz de pensar, este es el famoso test de Turing.

 Pues bien el Sr Turing estimaba que con una capacidad de memoria de 10^7 bits y sin necesidad de aumentar la velocidad del procesador y los programas adecuados se podría superar la prueba. 10^7 bits son aproximadamente 10^6 bytes = 1 MByte, ¡Solamente 1 MByte de memoria!, aunque Alan Turing  se equivocara en un factor de 1000 tendríamos un capacidad de 1 GByte, hay que aclarar que esta capacidad se refiere a la que ocuparía el programa, si turing estuviera en lo cierto deberíamos ser capaces de tener un sistema inteligente en cualquier PC  que se vende actualmente, el ordenador de IBM tiene 15 Terabytes de RAM = 15.000 GBytes = 15.000.000 MBytes es decir 15 millones de veces la estimación original de Turing.

   Me gustaría pensar que Alan Turing tenía razón aunque se equivocara en varios ordenes de magnitud y podamos implementar algunos algoritmos "inteligentes" en el robot sin necesidad de semejante bestia.

   Recomiendo a los interesados la lectura del artículo de sinapsis.

La placa de sensores

Aunque el sonar, la cámara, la brújula ..., son sensores, esta placa que hemos llamado de sensores nos permite conectar bumpers, sensores de infrarrojos IR, y todo tipo de sensor cuyo funcionamiento sea del tipo ON/OFF - CONECTADO/DESCONECTADO. La placa de la fotografía permite conectar hasta seis de estos sensores, el número está limitado por el IC 4010 que dispone de 6 inversores triger-smith.


   Como puede verse en la imagen los conectores proporcionan alimentación a los sensores que lo necesiten, como pueden ser los IR. Los dos conectores ocupados son los CNY70 del sigue-linea.

   Esta placa es de las primeras que hicimos, se ve que esta hecha a una cara y hemos necesitado 3 puentes para completarla.




   Actualmente hemos terminado el diseño de una nueva que nos permitirá conectar hasta 12 sensores ya que tiene 2 chip 4010. Simplemente hemos duplicado el circuito, situando 8 sensores en un conector y 4 en otro.

Podemos rodear ahora el robot con bumpers que detecten cuando ha chocado con algo y añadir sensores IR de proximidad 20-30 cm para distancias cortas y probablemente nos sobren entradas que se reservarán para futuras ampliaciones.

Este diseño lo enviaremos a custompcb, y en cuento lo recibamos pondré una imagen de la nueva placa.

lunes, 10 de enero de 2011

Cables y conectores.

   El problema: En un sistema como un robot donde disponemos de una variedad grande de sensores y actuadores todos conectados a la fuente de potencia y a la CPU, podemos encontrarnos fácilmente con 7-8 placas diferentes, lo que significa que tendremos 7-8 conexiones a la CPU y las mismas a la fuente de potencia. Si estos cables fueran específicos para cada una de las placas tendríamos muchos tipos de cables, habría que construir cada uno a medida y la posibilidad de equivocarnos de cable sería muy grande, además, en caso de fallo de un cable tendríamos que construirlo específicamente con la consiguiente pedida de tiempo y parada del robot.
Los cables deben ser iguales y tener una posición de conexión única para evitar conexiones erróneas y averías, esto es especialmente importante con los conectores de alimentación.

   En nuestro robot, todos las conexiones a la CPU de las placas de sensores o actuares son los mismos, es la placa del sensor/actuador la que se adapta al conector y no al contrario. Esto facilita la construcción de los cables y en caso de sospechar que un cable no está en bien lo cambiamos rápidamente y fácilmente por otro.


   Los cables que conectan la fuente de potencia con las placas también son todos iguales y evitan equivocaciones de cambio de polaridad que provocan cortocircuitos y la consiguiente avería y si aplicamos la ley de Murphy el componente que se estropea es el más caro de todos los que están conectados, "ya nos ha pasado".



   Tenemos tres excepciones en nuestro robot, el cable de alimentación de los motores (12V), debido a la potencia que pueden llegar a consumir hemos construido un cable específico con un conector de potencia diferente al resto, y el router-wifi que necesitamos un cable que en un extremo tenga una banana de alimentación y por lo tanto el cable debe ser diferente por necesidad.

  Y los cables ethernet que conectan la CPU XMOS  y la camara ip con el router wifi.
   En las placas de los sensores/actuadores solamente se conectan los bits que se van a usar, el resto se deja sin conectar.

martes, 4 de enero de 2011

Control de Potencia

     En esta entrada hablaré del control de potencia ("Motores y servos"), hemos diseñado una placa que nos proporciona la capacidad de controlar hasta 4 motores de corriente continua y 2 servos, además hemos instalado un chip ULM20003 que nos permite 7 salidas de alta corriente hasta 500 mA, se puede sustituir este chip por otros equivalente que suministran más corriente aún, con el podemos controlar por ejemplo: servos (hasta 7) u otros dispositivos.

En la imagen podemos ver la placa:



    He cometido un error al editar la foto, se dice que son (8) driver de corriente cuando en realidad son 7.

    Los chips utilizados para controlar los motores son el L293B que permiten un consumo de hasta 1 A y tienen integrados los diodos de protección contra las corrientes inducidas que producen los motores de cc.

    Los motores se pueden alimentar a 12V y 6V para ello dispone de dos jumper sobre la placa (rojo y azul).

   Los servos se alimentan a 6V.

   A continuación el esquema:



  Todas estas tensiones son suministradas por la fuente de alimentación que comentamos en la anterior entrada.

  La complejidad de la placa nos ha obligado a hacerla a doble cara, la placa tiene alrededor de 51 agujeros pasantes de la cara superior a la inferior ya que no disponemos de la tecnología para hacer la metalización de los agujeros, hemos llegado a la conclusión que no merece la pena el trabajo de hacerla y lo mejor es encargarla a alguna empresa especializada como custompcb.

  Esta placa no permite la conexión de los encoders de los motores, por lo que hemos rediseñado la placa y hemos incluido estos conectores, además hemos sustituido el chip L293B por el 298 que permite motores de más potencia, además en el nuevo diseño podemos controlar 4 servos y 2 motores de cc. (no vemos la necesidad de más motores). Se ha suprimido también la posibilidad de alimentar los motores con 6V o 12V mediante jumpers, aunque sumistrando 6V en la entrada de 12V conseguimos el mismo efecto.
   Hemos aprovechado la ocasión para compactar el tamaño y hemos suprimido el driver de corriente que lo incluiremos en la placa de sensores y por supuesto hemos encargado la construcción a custompcb.

   En la imagen vemos una placa de motores sin montar, por supuesto es a doble cara y no le cabe un componente más, estamos montado una para verificar que el diseño es correcto:



   En este diseño se han incluido los diodos de protección ya que el L298 no los incorpora, además el conector de los encoders es específico de nuestros motores, esto es una limitación si en alguna ocasión queremos cambiarlos, entonces deberíamos hacer una pequeña placa adaptadora de la salida de los nuevos encoders a estos. Perdemos flexibilidad pero ganamos en integración, simplicidad y espacio.

La placa dispone además de dos conectores con los cuales podemos monitorizar la corriente que se le suministra a los motores (es una característica que tiene el L298) que por el momento no usaremos.


   En la próxima entrada hablaré de los conectores, su normalización y su importancia.

   Actualización(10/01/2011): Ya hemos montado la nueva placa de motores:

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.