Diferencia entre revisiones de «Grupo HotPlug»

Revisión del 18:57 23 feb 2012

Introducción:

El proyecto Butiá trata de ampliar las capacidades sensoriales y de actuación de la computadora XO del proyecto OLPC en una plataforma robótica móvil, simple y económica que permita a alumnos de instituciones educativas , en coordinación con docentes e inspectores de Enseñanza Secundaria, interiorizarse con la programación del comportamiento de robots. Se utiliza una Placa entrada/salida (Figura 4) donde se conecta un Shield (Figura 2) con 9 conectores de 9 pines genéricos para motores, sensores y actuadores para la interactividad con el ambiente que pueden controlarse fácilmente desde cualquier lenguaje de programación con soporte de conexiones TCP/IP.

Estos dispositivos se conectan a la placa entrada/salida a través del Shield. Al encender el la Placa entrada/salida, ésta revisa cada conector para ver si algo está conectado. Cada sensor y actuador tiene uno o más puentes en sus conectores (Figura 1) que respetan los valores de una tabla (enlazar la tabla acá) uniéndo a partir de 2 pines, uno tierra y otro positivo, otros pines, para que la placa entrada/salida identifique lo que se conectó e informe a la computadora que hay conectado en cada conector a travéz de su conexión por el puerto USB.

A cada sensor y actuador le corresponde un valor (un número entero) entre los que podemos encontrar:

Figura 1: Sensores y boton, en el conector se pueden observar los puentes de pin a pin

Estos valores se pueden encontrar en el firmware con el que trabaja la Placa. Un firmware especial para el funcionamiento de este robot desarrollado en la Facultad de Ingeniería de la Universidad de la República que se puede descargar y modificar. (colocar sitio aquí) Nuestro trabajo se concentra en mayor parte a este nivel.

• 

  Shield

• 

  Shield

El Proyecto:

Integrantes:

• Juan La Cruz
• Sofía Maiolo
• Mathias Battistella

Tema elegido:

Firmware + Software : soporte HotPlug.

Motivación:

Hasta el momento para que el robot funcione correctamente con todos los sensores y actuadores que se conecten, éstos deben estar conectados antes de el encendido para que cuando la Placa entrada/salida revise los conectores, los encuentre. La idea es que esto suceda también durante la ejecución del programa para mantener actualizada la lista de dispositivos conectados. Esto traería grandes ventajas entre las que podemos considerar:

• Evitar reiniciar el robot cada vez que se conectan más dispositivos, lo que permitiría ahorrar tiempo y obtener un mayor dinamismo.

• Un uso más sencillo de los dispositivos del Butiá.

• En cuanto al trabajo, nos interesó la idea de trabajar en varios niveles (firmware, bobot, tortugarte) y poder comprender mejor como se relacionan.

Objetivos:

Que la actualización de los módulos de usuario y drivers del Butiá sea "on the fly" es decir, dinámico. Se desea que durante la ejecución del Bobot-Server, podamos conectar y tener disponible para su uso sensores o actuadores.

Desarrollo del problema:

El Firmware

Figura 4: Placa entrada/salida Arduino Mega

Consta de 11 archivos, "PnP", "ax12.h", "ax12.cpp", "comunicacion", "conector.cpp", "conector.h", "info", "modulos", "perifericos", "servicios" y el principal "butia_mega_firmware_0_2" donde se levantan los otros 10 (describir brevemente cada archivo). El lenguaje utilizado es similar al C++. Para este trabajo modificamos los archivos "butia_mega_firmware_0_2", "modulos" y "PnP".

Algunas de las placas entrada/salida (E/S, I/O, in/out) utilizadas son:

- USB4all (enlazar) - Arduino Mega 03 (enlazar)

.

Uso de la placa desde el navegador

Bobot-Server, monitoreo desde la terminal de Linux

Brinda una interfaz de alto nivel para poder interactuar con los módulos (sensores/actuadores). Se interactua directamente con la placa e/s mediante una Terminal Telnet con el protocolo de transmición TCP/IP por el puerto 2009.

Algunos comandos que se pueden utilizar son:

• LIST 

Lista los módulos detectados.

• DESCRIBE moduleName

Devuelve una descripción del módulo.

• CALL moduleName operation param1, param2, ... , paramN

Invoca la función indicada en el módulo dado. Los parámetros dependen de la función.

• CLOSEALL

Cierra todos los módulos.

• OPEN moduleName

Abre el módulo.

Como se puede ver en la imagen, hacemos un LIST para ver la lista de módulos detectados en donde podemos ver correctamente cada dispositivo, con el INIT actualizamos la lista

Monitoreo desde el compilador

El compilador de la placa Arduino dispone también de un monitor para ver y controlar lo que pasa en la placa e/s, indicando desde el código lo que tiene que imprimir el firmware durante su ejecución.

En este caso lo utilizamos, como se puede ver en la imagen para controlar que es lo que detecta la placa en cada recorrida de los conectores. indicando en tipo y subtipo el número que representa al dispositivo que se conectó. Esta recorrida la hace cada cierto tiempo y eso se va actualizando en el monitor del compilador. Como se puede ver en la imagen, en el conector 0, se detecta un dispositivo al que le corresponde el número 10, que como se puede ver en la tabla le corresponde el sensor de distancia. Hasta ahora pudimos comprobar que se detectó correctamente el sensor.Si se desconecta dicho sensor, en la próxima recorrida, deberá indicar 0, lo que nos dice que la placa no detectó nada.

Código:

Pruebas realizadas:

Hemos realizado pruebas en las distintas etapas de nuestro trabajo. Incluimos algunas de ellas.

• En primer instancia, probamos nuestra implementación conectando un boton y un sensor de distancia. Hacemos un LIST y los reconoce bien.

Los desconectamos, llamamos a nuestra operación y al INIT. Sin embargo, al usar el comando LIST, los sensores y el botón siguen apareciendo, lo cual nos hace pensar que la placa no fue reseteada

Vista desde la Terminal de Linux

Vista desde un explorador

Probando y consultando con docentes, nos dimos cuenta de que faltaba actualizar el tipo de los conectores, antes de hacer la recorrida en el for. Para ello, usamos una función implementada en conector.cpp, llamada update_config (). Incluimos el código de dicha función.

void Conector::update_config () {
  byte id = digitalRead (pin_id0) + 2*digitalRead (pin_id1);
  switch (id) {
    case 3:                                                      // NADA       
      pinMode (pin_dig0, INPUT); 
      pinMode (pin_dig1, INPUT);
      type = 0;
      subtype = 0;
      break;   
    case 2:                                                      // sensor analógico       
      pinMode (pin_dig0, INPUT); 
      pinMode (pin_dig1, INPUT);
      digitalWrite (pin_dig0, HIGH);             // activa los pull-ups
      digitalWrite (pin_dig1, HIGH);             // activa los pull-ups
      type = 1;
      subtype = digitalRead (pin_dig0) + 2*digitalRead (pin_dig1);
      break;         
    case 1:                                                      // sensor analógico c/pin de control       
      pinMode (pin_dig0, OUTPUT); 
      pinMode (pin_dig1, INPUT);
      digitalWrite (pin_dig1, HIGH);             // activa los pull-ups
      type = 2;
      subtype = digitalRead (pin_dig1);
      break;
    case 0:                                                     // sensor o actuador digital
    {  
      int analog_id = analogRead (pin_analog);   
      byte i;
      for (i=0; i<NUM_VALORES; i++) {
          if (abs(analog_id-values[i]) <= TOLERANCIA) {break;}
      } 
      switch (i) {
        case 0: case 1: case 2: case 3: case 4:
          pinMode (pin_dig0, INPUT); 
          pinMode (pin_dig1, INPUT);
          type = 3;                                             // sensor digital
          subtype = i;
          break;        
        case 5: case 6: case 7: case 8:
          pinMode (pin_dig0, OUTPUT); 
          pinMode (pin_dig1, INPUT);
          type = 4;
          subtype = i-5;
          break;
        case 9: case 10: case 11: case 12:
          pinMode (pin_dig0, OUTPUT); 
          pinMode (pin_dig1, OUTPUT);
          type = 5;                                            // sensor digital c/pin de control
          subtype = i-9;
          break;
        case NUM_VALORES:              // si la red de resistencias no coincide con ningun valor, se deja en modo manual
          pinMode (pin_dig0, INPUT); 
          pinMode (pin_dig1, INPUT);
          type = 0;
          subtype = 0;
          break;   
      }  
    }
  }

• Usamos ./lua bobot-server.lua DEBUG en la Terminal para ver más información.

• Probando con "Serial monitor" el FOR original de tal forma que repita cada 5 seg sin el init que aparece antes del codigo. Se puede ver el Print indicado mostrando correctamente la lista de dispositivos conectados. Para ello agregamos en butia.lua, linea 35: Print ("tipo leido",devolver); (devolver integer)

 Serial.print("conector ");
      Serial.print(f,DEC);
      Serial.print(" tipo= ");
      Serial.print(conector[f].get_type(), DEC);
      Serial.print(" subtipo= ");
      Serial.println(conector[f].get_subtype(), DEC);

En base a estas pruebas decidimos eliminar el FOR original del modulo butiá (tal como se detalla en la sesión anterior.)

• Haciendo para cada conector update_config: "conector[f].update_config (); funionó, se probó con un boton y un sensor y verificó que el codigo los reconocía correctamente desde Serial Monitor. Pero probando con: ./lua bobot-server.lua DEBUG (Terminal) no funcionó, ahora el sensor de grises no aparece como unknown, sino como "grises", pero se repite como antes.

• Luego de agregar las nuevas estructuras, volvimos a repetir las pruebas y sin embargo, el problema no se solucionó.

Conclusiones:

• Hasta este momento hemos logrado que se detecte correctamente cuando se conecta/desconecta un sensor. Sin embargo, a pesar de todos los cambios hechos, no hemos podido solucionar el problema de la nomenclatura de los conectores.

• El proyecto nos motivó mucho, ya que nos permitió utilizar herramientas que ya teníamos y observar de una forma mucho más práctica a la cual estamos acostumbrados, los cambios introducidos en el código.

• Nuestra idea es culminar el proyecto, tratando de solucionar el problema antes explicado.

Presentación de nuestro trabajo:

Para ver la presentación de nuestro proyecto:

Presentación HotPlug

Trabajo a futuro:

• Creemos que los cambios introducidos deberían permitirnos completar nuestro proyecto solucionando los problemas ahora existentes. Nuestro trabajo a futuro se centrará en identificar qué estamos haciendo mal, para poder cumplir íntegramente los objetivos planteados.

• Por otro lado, también evaluamos la posibilidad de incluir un "botón refresh" dentro del Tortugarte, para permitir al usuario, actualizar los sensores cuando lo desee.

Referencia:

HotPlug sorceforge

Wiki de Lua

Articulo wikipedia Arduino

Web Arduino