Proyecto Butiá - Contribuciones del usuario [es]

Plantilla:Tlx

2012-02-29T22:01:08Z

Mbattistella: Página creada con '{{fusionar en|Plantilla:ep}} {{Subpágina de documentación}} === Uso === Enlace a plantilla, muestra una presentación mejorada y hasta tres parámetros y [[Ayuda:Enlace interl...'

{{fusionar en|Plantilla:ep}}
{{Subpágina de documentación}}
=== Uso ===
Enlace a plantilla, muestra una presentación mejorada y hasta tres parámetros y [[Ayuda:Enlace interlingüístico|enlaces interlingüísticos]].
<includeonly>
[[Categoría:Wikipedia:Plantillas de enlaces internos]]

[[en:Template:Tlx]]
</includeonly>

Plantilla:Listaref/doc

2012-02-29T22:00:25Z

Mbattistella:

{{Subpágina de documentación}}
{{Metaplantilla de avisos
|texto = '''Las referencias en columnas múltiples son compatibles únicamente con las versiones más recientes de [[Gecko (motor de renderizado)|Gecko]] ([[Firefox]]) y [[WebKit]] ([[Google Chrome]], [[Safari (navegador)|Safari]]).'''<br>Cualquier versión anterior a la '''10''' de [[Internet Explorer]], así como cualquier versión anterior a la '''11''' de [[Opera (navegador)|Opera]], no es compatible con las columnas múltiples.<br>
<span style="font-size:88%">Véase [[#Separación en columnas según el navegador en uso|más abajo]] para más información.</span>
}}

=== Uso ===
Parámetros:

* '''n =''' número de columnas.
* '''ancho =''' ancho de la(s) columna(s).

En definitiva, si quieres utilizar esta plantilla, debes colocar:

<pre>{{listaref|n|ancho=xxx}}</pre>

Donde n corresponde al número de columnas y «xxx» define el mínimo ancho en píxeles de cada columna.

El número de columnas solo se aplica si la anchura del navegador lo permite. Es decir, si n=2 y <code>ancho=600px</code>, la plantilla generará dos columnas cuando la anchura de la ventana del navegador sea superior a 1200 píxeles, y sólo una única columna cuando la anchura sea inferior.

=== Referencias por grupo ===
Desde junio de 2008, el sistema de notas al pie soporta la separación de referencias en grupos. Los grupos permiten tener separadas las notas aclaratorias, las referencias de tablas y más.

El formato general para una etiqueta de referencia de grupo es:

:{{tag|ref group=''"nombre_del_grupo"''|apertura}}

y para la plantilla de lista de referencias:
:{{tlx|listaref|grupo=''"nombre_del_grupo"''}}

:Donde ''nombre_del_grupo'' será el identificador de grupo tal como "nota", "n" o el nombre deseado.

;Parámetro refs

Dentro de las referencias se coloca:
<pre>
{{listaref|group="nombre_del_grupo"|refs=
<ref name="nombre1">contenido1</ref>
<ref name="nombre2">contenido2</ref>
}}</pre>

Así, estas referencias pueden ser invocadas en el artículo como:
<pre><ref group="nombre_del_grupo" name="nombre1" /><ref group="nombre_del_grupo" name="nombre2" /></pre>

=== Estilos de lista ===
El parámetro {{parámetro|estilolista}} permite especificar el estilo de los numerales de las referencias.
{{Lista desplegable
|título=Tipos de estilos de lista
|título_estilo=background:#ccccff; text-align:center;
|1={{Listaref/doc/estilolista}}}}

=== Detalles técnicos ===
==== Separación en columnas según el navegador en uso ====
{| class="wikitable" style="float:right; margin:0 0 1em 1em; text-align:center; font-size:90%;"
|+ Soporte de navegador web para esquemas de columnas múltiples CSS3
! Internet<br>Explorer !! Firefox !! Safari !! Chrome !! Opera
|-
| {{no|6}} || {{sí|3}} || {{sí|3}} || {{sí|8}} || {{no|10}}
|-
| {{no|7}} || {{sí|4}} || {{sí|4}} || {{sí|9}} || {{no|11}}
|-
| {{no|8}} || {{sí|5}} || {{sí|5}} || {{sí|10}} || {{sí|11.1}}
|-
| {{no|9}} || || || {{sí|11}} || {{sí|12}}
|-
| {{yes|10}} || || || {{sí|12}} ||
|}
Las columnas múltiples se generan usando [[Cascading Style Sheets|CSS3]], aún en fase de desarrollo; por ello sólo los navegadores de Internet que soportan esta función mostrarán columnas múltiples.<ref>{{cita web|fechaacceso=31 de marzo de 2009|título=CSS3 Multi-Column Thriller|url=http://www.stuffandnonsense.co.uk/archives/css3_multi-column_thriller.html}}</ref><ref>{{cita web|url=http://www.w3.org/TR/css3-multicol/|título=CSS3 module: Multi-column layout|editorial=[[World Wide Web Consortium|W3C]]|fechaacceso=31 de marzo de 2009}}</ref>

Los siguientes navegadores '''soportan''' columnas CSS3:
* Navegadores basados en [[Gecko (motor de renderizado)|Gecko]], como [[Mozilla Firefox]]
* Navegadores basados en [[WebKit]], como [[Safari (navegador)|Safari]] y [[Google Chrome]]
* [[Opera (navegador)|Opera]] a partir de la versión 11.10
* [[Internet Explorer 10]] Platform Preview

Los siguientes navegadores '''no soportan''' columnas CSS3:
* Navegadores basados en [[Trident]], incluyendo Internet Explorer hasta la versión 9<ref>{{Cita web |url=http://msdn.microsoft.com/en-us/library/cc351024(VS.85).aspx#multicolumn |title=CSS Compatibility and Internet Explorer: Multi-column Layout |work=Microsoft Developer Network |publisher=Microsoft |accessdate=March 16, 2011}}</ref>
* [[Opera (navegador)|Opera]] hasta la versión 11

=== Véase también ===
* [[Wikipedia:Referencias]]

=== Referencias ===
{{listaref}}
<includeonly>
[[Categoría:Wikipedia:Plantillas de listas]]
[[Categoría:Wikipedia:Plantillas de referencias]]

[[ar:قالب:ثبت المراجع]]
[[be-x-old:Шаблён:Зноскі]]
[[br:Patrom:Daveoù]]
[[ca:Plantilla:Referències]]
[[cy:Nodyn:Cyfeiriadau]]
[[en:Template:Reflist]]
[[eo:Ŝablono:Referencoj]]
[[eu:Txantiloi:Erreferentzia zerrenda]]
[[fa:الگو:پانویس]]
[[fi:Malline:Viitteet]]
[[fr:Modèle:Références]]
[[hi:साँचा:टिप्पणीसूची]]
[[hr:Predložak:Izvori]]
[[hsb:Předłoha:Referency]]
[[hu:Sablon:Reflist]]
[[ia:Patrono:Reflist]]
[[it:Template:References]]
[[ja:Template:Reflist]]
[[ka:თარგი:სქოლიოს სია]]
[[ko:틀:주석]]
[[lv:Veidne:Reflist]]
[[ml:ഫലകം:Reflist]]
[[ms:Templat:Reflist]]
[[no:Mal:Reflist]]
[[pl:Szablon:Przypisy]]
[[pt:Predefinição:Referências]]
[[ro:Format:Listănote]]
[[ru:Шаблон:Примечания]]
[[sr:Шаблон:Напомене]]
[[th:แม่แบบ:รายการอ้างอิง]]
[[uk:Шаблон:Reflist]]
[[vi:Bản mẫu:Tham khảo]]
[[zh:Template:Reflist]]
</includeonly>

Plantilla:Purgar

2012-02-29T21:57:50Z

Mbattistella: Página creada con '<span class="noprint plainlinks purgelink">[{{fullurl:{{{página|{{{page|{{FULLPAGENAME}}}}}}}}|action=purge}} <span title="Purga esta página">{{{1|purgar}}}</span>]<noinclude>...'

<span class="noprint plainlinks purgelink">[{{fullurl:{{{página|{{{page|{{FULLPAGENAME}}}}}}}}|action=purge}} <span title="Purga esta página">{{{1|purgar}}}</span>]<noinclude>{{documentación}}</noinclude>

Plantilla:Tag

2012-02-29T21:33:33Z

Mbattistella: Página creada con '<code style="white-space:nowrap;">{{#switch:{{{2|par}}} |cierre |simple =  |apertura |par |#default = <{{{1|tag}}}{{#if:{{{params|}}}| {{{params}}}}}...'

<code style="white-space:nowrap;">{{#switch:{{{2|par}}}
|cierre
|simple = 
|apertura
|par
|#default = <{{{1|tag}}}{{#if:{{{params|}}}| {{{params}}}}}>
}}{{#switch:{{{2|pair}}}
|apertura
|cierre
|simple = 
|par
|#default = {{{contenido|}}}
}}{{#switch:{{{2|par}}}
|apertura
|simple = 
|cierre
|par
|#default = </{{{1|tag}}}>
}}{{#switch:{{{2|par}}}
|simple = <{{{1|tag}}}{{#if:{{{params|}}}| {{{params}}}}}/>
}}</code><noinclude>
{{documentación}}
</noinclude>

Plantilla:Listaref/doc

2012-02-29T21:27:45Z

Mbattistella: Página blanqueada

2012-02-24T03:06:00Z

Mbattistella:

<big><big>'''Introducción:'''</big></big>

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:

[[Archivo:IMG_3872.JPG|250px|Figura 1: Sensores y boton, en el conector se pueden observar los puentes de pin a pin|thumb|dcha]]
{| class="wikitable" style="width:250px; height:210px" border="2"
|-
|info1|Sensor de distancia||info2|10
|-
|Sensor de temperatura||info2|11
|-
|Sensor de luz||info2|12
|-
|Sensor de grises||info2|13
|-
|Sensor botón||info2|30
|-
|Sensor contacto||info2|31
|-
|Sensor Tilt||info2|32
|-
|Sensor de vibración||info2|33
|-
|Sensor magnético||info2|34
|-
|Actuador Led||info2|53
|-
|Parlante||info2|10
|-
|Sensor potenciómetro||info2|21
|-
|Desconocido||info2|15
|}
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.

[[Archivo:probando3.jpg|thumb|Fig.7: Dispositivos colocados|dcha]]

<gallery>
Archivo:IMG_3876.JPG|Fig.2: Shield
Archivo:IMG_3879.JPG|Fig.3: Shield
Archivo:Image_(1).png|Fig.4: Arduino Mega + Shield
Archivo:Image.png|Fig.5: Arduino Mega + Shield
</gallery>

=='''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:===
[[Archivo:probando3.jpg|thumb|Fig.6: Robot sin XO armado |dcha]]
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===

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

*USB4all '''(enlazar)'''
*Arduino Mega 03 '''(enlazar)'''

[[Archivo:IMG_3887.JPG|dcha|thumb|Figura 4: Placa entrada/salida Arduino Mega]]

El firmware 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".

En primer lugar modificamos el código del módulo butia, incluido en el archivo modulos.pde, para incluir una nueva operación que actualice los dispositivos conectados al Butiá. Esta nueva operacion consta de un for, donde se recorren los conectores, revisando su estado. Anexamos el código añadido

<big><source lang="c">
for (k=0; k<NUM_CONNECTORS; k++)
{
if (conector[k].get_type() != 0)
{add_module(k) };
}
</source>
</big>

* Al anexar esta nueva operación, debemos modificar también los drivers, incluidos en la carpeta bobot. Cambiamos, en particular, el archivo butia.lua, para poder invocar a la nueva función, que llamamos get_hot_plug. Incluimos el código:

<big>
<source lang="lua">
api.hot_plug = {}
api.hot_plug.parameters = {} -- no se envian parámetros
api.hot_plug.returns = {} --nos devuelve el estado de los conectores
api.hot_plug.call = function ()
device:send(HOT_PLUG) --envío el código de operación

end
</source></big>

*Luego de realizar varias pruebas (detalladas en la próxima sesión) decidimos cambiar el enfoque y optamos por quitar el FOR agregado inicialmente en el módulo butiá. Lo sustituimos por el siguiente código incluido en el archivo butia_firmware_mega_0_2.pde:

<big>
<source lang="c">
if (time_act-time_last2 >= 5000) { // cada 20ms llamamos a la sample(). Ojo porque esto afecta al "cuentapasos"

// explora los conectores
for (byte f=0; f<NUM_CONNECTORS; f++) {
byte tipoOld = conector[f].get_type();
byte subtipoOld = conector[f].get_subtype();

conector[f].update_config ();
// conecte algo donde no habia nada, o cambie lo que estaba conectado
if (conector[f].get_type() != 0 &&
(conector[f].get_type() != tipoOld || conector[f].get_subtype() != subtipoOld))

{
//primero borrar el viejo en la lista de handlers si es que
//el viejo no era el tipo 0 (el caso q no hay nada)

add_module(f);
}else if (conector[f].get_type() == 0 && //desconecte algo
(conector[f].get_type() != tipoOld || conector[f].get_subtype() != subtipoOld))){
//borrar el modulo que se acaba de desconectar

} // si hay algo en el conector, agrega 1 módulo PnP para él

}

time_last2 = time_act;
}
</source></big>

Este código realiza las siguientes acciones:

-Recorremos los conectores, y guardamos su tipo y sub-tipo anteriores.

-Si no había un conector en la lista de handlers y además, los tipos y sub-tipos son distintos, agregamos el conector llamando a '''add_module(f);''' de PnP.pde

-Sino, debemos borrar del handler el módulo que acabamos de desconectar. Debemos implementar esta función, a la que llamaremos '''remove_module.'''

* Para implementar remove_module, exploramos el handler, buscando el módulo a borrar y lo sustituimos por el módulo que se encuentra en la última posición ocupada del handler. Actualizamos, también, la cantidad de módulos. Incluimos la primera versión de nuestro código:

<big>
<source lang="c">
void remove_module (byte num_conector) {
int i=8; //Comenzamos a recorrer desde el 8 ya que desde el 8 se comienzan a agregar los nuevos conectores.
while ( (i< num_modules) && (handler[i].num_conector != num_conector) ) //Buscamos el conector con "num_conector" en el arreglo.
i++;
if (i< num_modules) //El conector con "num_conector" no es el ultimo.
{
//Hacemos el intercambio, dejando en la posicion i, al conector que se encontraba en la ultima posicion (num_modules).
strcpy (handler[i].nombre, handler[num_modules].nombre);
handler[i].funcion = handler[num_modules].funcion;
handler[i].num_conector = handler[num_modules].num_conector;
}
num_modules--;

}
</source></big>

=='''Comenzando las pruebas:'''==

==='''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.

[[Archivo:Probando.jpg|centro|500px]]

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

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:

[[Archivo:probando2.png|Figura 6: Control del robot mediante un explorador web|thumb|borde|dcha]]

[[Archivo:probando3.jpg|Figura 7: Placa Arduino + Shield|thumb|dcha]]

[[Archivo:probando3.jpg|thumb|Fig.6: Robot con XO armado |dcha]]
<big>
<source lang="c">
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;
}
}
}
</source></big>

===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. Se puede ver más información sobre este paso en http://arduino.cc/en/Reference/HomePage

[[Archivo:Cuadro Serial Monitor.png|750px|centro]]

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.

Primero debuggeamos usando ./lua bobot-server.lua DEBUG en la Terminal para ver más información los sensores y actuadores aparecían como unknown.
Probando con el monitor del compilador 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)
[[Archivo:probando4.png|thumb|borde|dcha|Figura 9: Código anterior]]

<big> <source lang="c">
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);
</source></big>

En base a estas pruebas decidimos eliminar el FOR original del modulo butiá

Luego 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 el monitor del compilador. Pero probando con: ./lua bobot-server.lua DEBUG (Terminal) no funcionó, ahora el sensor de grises no aparece como unknown, sino como "grises", pero al desconectar y volver a conectar el anterior no se borra y aparece repetidas veces.

===Luego de las primeras pruebas===

Probando con el bobot-server, comprobamos que se detecta correctamente cuando se conecta/desconecta un sensor. Sin embargo, cuando conectamos/desconectamos sensores del mismo tipo, los nombres asignados no se actualizan. Es decir, si conectamos dos sensores del tipo X y listamos los sensores conectados (usando LIST), veremos conectados: X, X1. Al desconectar en este caso X1, veremos un comportamiento correcto. Pero, al conectar nuevamente el sensor, y listar apreciaremos: X, X2 La instancia debería ser 1 y no 2.
Para solucionar este problema, relacionado con la cantidad de instancias de cada conector del handler, optamos por:

1) Crear una nueva estructura (un array de bytes), llamada instancias, en la cual guardaremos las instancias de cada conector, mapeandolos según los siguientes criterios:
<big>
<source lang="c">byte globaltype = 12*conector[num_conector].get_type() + conector[num_conector].get_subtype();</source>
</big>

En cada lugar del array, correspondiente a alguno de estos valores, guardaremos la cantidad de instancias de ese sensor.

{| class="wikitable" style="width:250px; height:210px" border="2"
|-
| SENSOR_DISTANCIA || 10
|-
| SENSOR_TEMPERATURA|| 11
|-
| SENSOR_LUZ || 12
|-
| SENSOR_GRISES || 13
|-
| SENSOR_BOTON || 30
|-
| SENSOR_CONTACTO || 31
|-
| SENSOR_TILT || 32
|-
| SENSOR_VIBRACION || 33
|-
| SENSOR_MAGNETICO || 34
|-
| ACTUADOR_LED || 53
|-
| MAX_CALLBACKS || 10
|-
| SENSOR_POTE || 21
|-
| UNKNOWN || 15
|}

El objetivo primordial de esta estructura es tener en una variable global el numero de instancias, para poder actualizarlo en el procedimiento remove_module, ya que antes estas variables solo se podían modificar en get_config al agregar un nuevo sensor.

2) Modificamos la estructura H, agregándole un nuevo campo, instancia, que guardará a qué instancia de ese sensor corresponde el dispositivo ubicado en ese lugar del handler.
De esta forma podremos acceder al valor de instacias totales para cada tipo de conector (buscando en el array instancias) y a su vez, al valor particular de cada sensor (que corresponde con la nomenclatura de su nombre). Es importante destacar, que cuando existe sólo un sensor conectado, en el array instancias habrá un 1, mientras que el valor de instancia en el handler será 0.

3)Una vez hecho esto, tenemos que actualizar distintas partes del código, para incluir las nuevas estructuras. En particular, hicimos cambios relevantes en los procedimientos get_config, add_module y remove_module.

*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:

[http://www.box.com/s/jk0nr1jnes9sa7gjrfkk 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:'''==

[http://linux-hotplug.sourceforge.net HotPlug sorceforge]

[http://lua-users.org/wiki/LuaTypesTutorial Wiki de Lua]

[http://es.wikipedia.org/wiki/Arduino Articulo wikipedia Arduino]

[http://www.arduino.cc/es/ Web Arduino]

Grupo HotPlug

2012-02-24T03:04:19Z

Mbattistella:

<big><big>'''Introducción:'''</big></big>

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:

[[Archivo:IMG_3872.JPG|250px|Figura 1: Sensores y boton, en el conector se pueden observar los puentes de pin a pin|thumb|dcha]]
{| class="wikitable" style="width:250px; height:210px" border="2"
|-
|info1|Sensor de distancia||info2|10
|-
|Sensor de temperatura||info2|11
|-
|Sensor de luz||info2|12
|-
|Sensor de grises||info2|13
|-
|Sensor botón||info2|30
|-
|Sensor contacto||info2|31
|-
|Sensor Tilt||info2|32
|-
|Sensor de vibración||info2|33
|-
|Sensor magnético||info2|34
|-
|Actuador Led||info2|53
|-
|Parlante||info2|10
|-
|Sensor potenciómetro||info2|21
|-
|Desconocido||info2|15
|}
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.

[[Archivo:probando3.jpg|Fig.7: Dispositivos colocados|dcha]]

<gallery>
Archivo:IMG_3876.JPG|Fig.2: Shield
Archivo:IMG_3879.JPG|Fig.3: Shield
Archivo:Image_(1).png|Fig.4: Arduino Mega + Shield
Archivo:Image.png|Fig.5: Arduino Mega + Shield
</gallery>

=='''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:===
[[Archivo:probando3.jpg|Fig.6: Robot sin XO armado |dcha]]
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===

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

*USB4all '''(enlazar)'''
*Arduino Mega 03 '''(enlazar)'''

[[Archivo:IMG_3887.JPG|dcha|thumb|Figura 4: Placa entrada/salida Arduino Mega]]

El firmware 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".

En primer lugar modificamos el código del módulo butia, incluido en el archivo modulos.pde, para incluir una nueva operación que actualice los dispositivos conectados al Butiá. Esta nueva operacion consta de un for, donde se recorren los conectores, revisando su estado. Anexamos el código añadido

<big><source lang="c">
for (k=0; k<NUM_CONNECTORS; k++)
{
if (conector[k].get_type() != 0)
{add_module(k) };
}
</source>
</big>

* Al anexar esta nueva operación, debemos modificar también los drivers, incluidos en la carpeta bobot. Cambiamos, en particular, el archivo butia.lua, para poder invocar a la nueva función, que llamamos get_hot_plug. Incluimos el código:

<big>
<source lang="lua">
api.hot_plug = {}
api.hot_plug.parameters = {} -- no se envian parámetros
api.hot_plug.returns = {} --nos devuelve el estado de los conectores
api.hot_plug.call = function ()
device:send(HOT_PLUG) --envío el código de operación

end
</source></big>

*Luego de realizar varias pruebas (detalladas en la próxima sesión) decidimos cambiar el enfoque y optamos por quitar el FOR agregado inicialmente en el módulo butiá. Lo sustituimos por el siguiente código incluido en el archivo butia_firmware_mega_0_2.pde:

<big>
<source lang="c">
if (time_act-time_last2 >= 5000) { // cada 20ms llamamos a la sample(). Ojo porque esto afecta al "cuentapasos"

// explora los conectores
for (byte f=0; f<NUM_CONNECTORS; f++) {
byte tipoOld = conector[f].get_type();
byte subtipoOld = conector[f].get_subtype();

conector[f].update_config ();
// conecte algo donde no habia nada, o cambie lo que estaba conectado
if (conector[f].get_type() != 0 &&
(conector[f].get_type() != tipoOld || conector[f].get_subtype() != subtipoOld))

{
//primero borrar el viejo en la lista de handlers si es que
//el viejo no era el tipo 0 (el caso q no hay nada)

add_module(f);
}else if (conector[f].get_type() == 0 && //desconecte algo
(conector[f].get_type() != tipoOld || conector[f].get_subtype() != subtipoOld))){
//borrar el modulo que se acaba de desconectar

} // si hay algo en el conector, agrega 1 módulo PnP para él

}

time_last2 = time_act;
}
</source></big>

Este código realiza las siguientes acciones:

-Recorremos los conectores, y guardamos su tipo y sub-tipo anteriores.

-Si no había un conector en la lista de handlers y además, los tipos y sub-tipos son distintos, agregamos el conector llamando a '''add_module(f);''' de PnP.pde

-Sino, debemos borrar del handler el módulo que acabamos de desconectar. Debemos implementar esta función, a la que llamaremos '''remove_module.'''

* Para implementar remove_module, exploramos el handler, buscando el módulo a borrar y lo sustituimos por el módulo que se encuentra en la última posición ocupada del handler. Actualizamos, también, la cantidad de módulos. Incluimos la primera versión de nuestro código:

<big>
<source lang="c">
void remove_module (byte num_conector) {
int i=8; //Comenzamos a recorrer desde el 8 ya que desde el 8 se comienzan a agregar los nuevos conectores.
while ( (i< num_modules) && (handler[i].num_conector != num_conector) ) //Buscamos el conector con "num_conector" en el arreglo.
i++;
if (i< num_modules) //El conector con "num_conector" no es el ultimo.
{
//Hacemos el intercambio, dejando en la posicion i, al conector que se encontraba en la ultima posicion (num_modules).
strcpy (handler[i].nombre, handler[num_modules].nombre);
handler[i].funcion = handler[num_modules].funcion;
handler[i].num_conector = handler[num_modules].num_conector;
}
num_modules--;

}
</source></big>

=='''Comenzando las pruebas:'''==

==='''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.

[[Archivo:Probando.jpg|centro|500px]]

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

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:

[[Archivo:probando2.png|Figura 6: Control del robot mediante un explorador web|thumb|borde|dcha]]

[[Archivo:probando3.jpg|Figura 7: Placa Arduino + Shield|thumb|dcha]]

[[Archivo:probando3.jpg|Fig.6: Robot con XO armado |dcha]]
<big>
<source lang="c">
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;
}
}
}
</source></big>

===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. Se puede ver más información sobre este paso en http://arduino.cc/en/Reference/HomePage

[[Archivo:Cuadro Serial Monitor.png|750px|centro]]

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.

Primero debuggeamos usando ./lua bobot-server.lua DEBUG en la Terminal para ver más información los sensores y actuadores aparecían como unknown.
Probando con el monitor del compilador 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)
[[Archivo:probando4.png|thumb|borde|dcha|Figura 9: Código anterior]]

<big> <source lang="c">
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);
</source></big>

En base a estas pruebas decidimos eliminar el FOR original del modulo butiá

Luego 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 el monitor del compilador. Pero probando con: ./lua bobot-server.lua DEBUG (Terminal) no funcionó, ahora el sensor de grises no aparece como unknown, sino como "grises", pero al desconectar y volver a conectar el anterior no se borra y aparece repetidas veces.

===Luego de las primeras pruebas===

Probando con el bobot-server, comprobamos que se detecta correctamente cuando se conecta/desconecta un sensor. Sin embargo, cuando conectamos/desconectamos sensores del mismo tipo, los nombres asignados no se actualizan. Es decir, si conectamos dos sensores del tipo X y listamos los sensores conectados (usando LIST), veremos conectados: X, X1. Al desconectar en este caso X1, veremos un comportamiento correcto. Pero, al conectar nuevamente el sensor, y listar apreciaremos: X, X2 La instancia debería ser 1 y no 2.
Para solucionar este problema, relacionado con la cantidad de instancias de cada conector del handler, optamos por:

1) Crear una nueva estructura (un array de bytes), llamada instancias, en la cual guardaremos las instancias de cada conector, mapeandolos según los siguientes criterios:
<big>
<source lang="c">byte globaltype = 12*conector[num_conector].get_type() + conector[num_conector].get_subtype();</source>
</big>

En cada lugar del array, correspondiente a alguno de estos valores, guardaremos la cantidad de instancias de ese sensor.

{| class="wikitable" style="width:250px; height:210px" border="2"
|-
| SENSOR_DISTANCIA || 10
|-
| SENSOR_TEMPERATURA|| 11
|-
| SENSOR_LUZ || 12
|-
| SENSOR_GRISES || 13
|-
| SENSOR_BOTON || 30
|-
| SENSOR_CONTACTO || 31
|-
| SENSOR_TILT || 32
|-
| SENSOR_VIBRACION || 33
|-
| SENSOR_MAGNETICO || 34
|-
| ACTUADOR_LED || 53
|-
| MAX_CALLBACKS || 10
|-
| SENSOR_POTE || 21
|-
| UNKNOWN || 15
|}

El objetivo primordial de esta estructura es tener en una variable global el numero de instancias, para poder actualizarlo en el procedimiento remove_module, ya que antes estas variables solo se podían modificar en get_config al agregar un nuevo sensor.

2) Modificamos la estructura H, agregándole un nuevo campo, instancia, que guardará a qué instancia de ese sensor corresponde el dispositivo ubicado en ese lugar del handler.
De esta forma podremos acceder al valor de instacias totales para cada tipo de conector (buscando en el array instancias) y a su vez, al valor particular de cada sensor (que corresponde con la nomenclatura de su nombre). Es importante destacar, que cuando existe sólo un sensor conectado, en el array instancias habrá un 1, mientras que el valor de instancia en el handler será 0.

3)Una vez hecho esto, tenemos que actualizar distintas partes del código, para incluir las nuevas estructuras. En particular, hicimos cambios relevantes en los procedimientos get_config, add_module y remove_module.

*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:

[http://www.box.com/s/jk0nr1jnes9sa7gjrfkk 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:'''==

[http://linux-hotplug.sourceforge.net HotPlug sorceforge]

[http://lua-users.org/wiki/LuaTypesTutorial Wiki de Lua]

[http://es.wikipedia.org/wiki/Arduino Articulo wikipedia Arduino]

[http://www.arduino.cc/es/ Web Arduino]

Grupo HotPlug

2012-02-24T03:03:14Z

Mbattistella:

<big><big>'''Introducción:'''</big></big>

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:

[[Archivo:IMG_3872.JPG|250px|Figura 1: Sensores y boton, en el conector se pueden observar los puentes de pin a pin|thumb|dcha]]
{| class="wikitable" style="width:250px; height:210px" border="2"
|-
|info1|Sensor de distancia||info2|10
|-
|Sensor de temperatura||info2|11
|-
|Sensor de luz||info2|12
|-
|Sensor de grises||info2|13
|-
|Sensor botón||info2|30
|-
|Sensor contacto||info2|31
|-
|Sensor Tilt||info2|32
|-
|Sensor de vibración||info2|33
|-
|Sensor magnético||info2|34
|-
|Actuador Led||info2|53
|-
|Parlante||info2|10
|-
|Sensor potenciómetro||info2|21
|-
|Desconocido||info2|15
|}
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.

[[Archivo: colcar imagen |Fig.7: Dispositivos colocados|dcha]]

<gallery>
Archivo:IMG_3876.JPG|Fig.2: Shield
Archivo:IMG_3879.JPG|Fig.3: Shield
Archivo:Image_(1).png|Fig.4: Arduino Mega + Shield
Archivo:Image.png|Fig.5: Arduino Mega + Shield
</gallery>

=='''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:===
[[Archivo: colcar imagen |Fig.6: Robot sin XO armado |dcha]]
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===

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

*USB4all '''(enlazar)'''
*Arduino Mega 03 '''(enlazar)'''

[[Archivo:IMG_3887.JPG|dcha|thumb|Figura 4: Placa entrada/salida Arduino Mega]]

El firmware 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".

En primer lugar modificamos el código del módulo butia, incluido en el archivo modulos.pde, para incluir una nueva operación que actualice los dispositivos conectados al Butiá. Esta nueva operacion consta de un for, donde se recorren los conectores, revisando su estado. Anexamos el código añadido

<big><source lang="c">
for (k=0; k<NUM_CONNECTORS; k++)
{
if (conector[k].get_type() != 0)
{add_module(k) };
}
</source>
</big>

* Al anexar esta nueva operación, debemos modificar también los drivers, incluidos en la carpeta bobot. Cambiamos, en particular, el archivo butia.lua, para poder invocar a la nueva función, que llamamos get_hot_plug. Incluimos el código:

<big>
<source lang="lua">
api.hot_plug = {}
api.hot_plug.parameters = {} -- no se envian parámetros
api.hot_plug.returns = {} --nos devuelve el estado de los conectores
api.hot_plug.call = function ()
device:send(HOT_PLUG) --envío el código de operación

end
</source></big>

*Luego de realizar varias pruebas (detalladas en la próxima sesión) decidimos cambiar el enfoque y optamos por quitar el FOR agregado inicialmente en el módulo butiá. Lo sustituimos por el siguiente código incluido en el archivo butia_firmware_mega_0_2.pde:

<big>
<source lang="c">
if (time_act-time_last2 >= 5000) { // cada 20ms llamamos a la sample(). Ojo porque esto afecta al "cuentapasos"

// explora los conectores
for (byte f=0; f<NUM_CONNECTORS; f++) {
byte tipoOld = conector[f].get_type();
byte subtipoOld = conector[f].get_subtype();

conector[f].update_config ();
// conecte algo donde no habia nada, o cambie lo que estaba conectado
if (conector[f].get_type() != 0 &&
(conector[f].get_type() != tipoOld || conector[f].get_subtype() != subtipoOld))

{
//primero borrar el viejo en la lista de handlers si es que
//el viejo no era el tipo 0 (el caso q no hay nada)

add_module(f);
}else if (conector[f].get_type() == 0 && //desconecte algo
(conector[f].get_type() != tipoOld || conector[f].get_subtype() != subtipoOld))){
//borrar el modulo que se acaba de desconectar

} // si hay algo en el conector, agrega 1 módulo PnP para él

}

time_last2 = time_act;
}
</source></big>

Este código realiza las siguientes acciones:

-Recorremos los conectores, y guardamos su tipo y sub-tipo anteriores.

-Si no había un conector en la lista de handlers y además, los tipos y sub-tipos son distintos, agregamos el conector llamando a '''add_module(f);''' de PnP.pde

-Sino, debemos borrar del handler el módulo que acabamos de desconectar. Debemos implementar esta función, a la que llamaremos '''remove_module.'''

* Para implementar remove_module, exploramos el handler, buscando el módulo a borrar y lo sustituimos por el módulo que se encuentra en la última posición ocupada del handler. Actualizamos, también, la cantidad de módulos. Incluimos la primera versión de nuestro código:

<big>
<source lang="c">
void remove_module (byte num_conector) {
int i=8; //Comenzamos a recorrer desde el 8 ya que desde el 8 se comienzan a agregar los nuevos conectores.
while ( (i< num_modules) && (handler[i].num_conector != num_conector) ) //Buscamos el conector con "num_conector" en el arreglo.
i++;
if (i< num_modules) //El conector con "num_conector" no es el ultimo.
{
//Hacemos el intercambio, dejando en la posicion i, al conector que se encontraba en la ultima posicion (num_modules).
strcpy (handler[i].nombre, handler[num_modules].nombre);
handler[i].funcion = handler[num_modules].funcion;
handler[i].num_conector = handler[num_modules].num_conector;
}
num_modules--;

}
</source></big>

=='''Comenzando las pruebas:'''==

==='''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.

[[Archivo:Probando.jpg|centro|500px]]

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

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:

[[Archivo:probando2.png|Figura 6: Control del robot mediante un explorador web|thumb|borde|dcha]]

[[Archivo:probando3.jpg|Figura 7: Placa Arduino + Shield|thumb|dcha]]

[[Archivo: colcar imagen |Fig.6: Robot con XO armado |dcha]]
<big>
<source lang="c">
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;
}
}
}
</source></big>

===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. Se puede ver más información sobre este paso en http://arduino.cc/en/Reference/HomePage

[[Archivo:Cuadro Serial Monitor.png|750px|centro]]

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.

Primero debuggeamos usando ./lua bobot-server.lua DEBUG en la Terminal para ver más información los sensores y actuadores aparecían como unknown.
Probando con el monitor del compilador 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)
[[Archivo:probando4.png|thumb|borde|dcha|Figura 9: Código anterior]]

<big> <source lang="c">
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);
</source></big>

En base a estas pruebas decidimos eliminar el FOR original del modulo butiá

Luego 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 el monitor del compilador. Pero probando con: ./lua bobot-server.lua DEBUG (Terminal) no funcionó, ahora el sensor de grises no aparece como unknown, sino como "grises", pero al desconectar y volver a conectar el anterior no se borra y aparece repetidas veces.

===Luego de las primeras pruebas===

Probando con el bobot-server, comprobamos que se detecta correctamente cuando se conecta/desconecta un sensor. Sin embargo, cuando conectamos/desconectamos sensores del mismo tipo, los nombres asignados no se actualizan. Es decir, si conectamos dos sensores del tipo X y listamos los sensores conectados (usando LIST), veremos conectados: X, X1. Al desconectar en este caso X1, veremos un comportamiento correcto. Pero, al conectar nuevamente el sensor, y listar apreciaremos: X, X2 La instancia debería ser 1 y no 2.
Para solucionar este problema, relacionado con la cantidad de instancias de cada conector del handler, optamos por:

1) Crear una nueva estructura (un array de bytes), llamada instancias, en la cual guardaremos las instancias de cada conector, mapeandolos según los siguientes criterios:
<big>
<source lang="c">byte globaltype = 12*conector[num_conector].get_type() + conector[num_conector].get_subtype();</source>
</big>

En cada lugar del array, correspondiente a alguno de estos valores, guardaremos la cantidad de instancias de ese sensor.

{| class="wikitable" style="width:250px; height:210px" border="2"
|-
| SENSOR_DISTANCIA || 10
|-
| SENSOR_TEMPERATURA|| 11
|-
| SENSOR_LUZ || 12
|-
| SENSOR_GRISES || 13
|-
| SENSOR_BOTON || 30
|-
| SENSOR_CONTACTO || 31
|-
| SENSOR_TILT || 32
|-
| SENSOR_VIBRACION || 33
|-
| SENSOR_MAGNETICO || 34
|-
| ACTUADOR_LED || 53
|-
| MAX_CALLBACKS || 10
|-
| SENSOR_POTE || 21
|-
| UNKNOWN || 15
|}

El objetivo primordial de esta estructura es tener en una variable global el numero de instancias, para poder actualizarlo en el procedimiento remove_module, ya que antes estas variables solo se podían modificar en get_config al agregar un nuevo sensor.

2) Modificamos la estructura H, agregándole un nuevo campo, instancia, que guardará a qué instancia de ese sensor corresponde el dispositivo ubicado en ese lugar del handler.
De esta forma podremos acceder al valor de instacias totales para cada tipo de conector (buscando en el array instancias) y a su vez, al valor particular de cada sensor (que corresponde con la nomenclatura de su nombre). Es importante destacar, que cuando existe sólo un sensor conectado, en el array instancias habrá un 1, mientras que el valor de instancia en el handler será 0.

3)Una vez hecho esto, tenemos que actualizar distintas partes del código, para incluir las nuevas estructuras. En particular, hicimos cambios relevantes en los procedimientos get_config, add_module y remove_module.

*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:

[http://www.box.com/s/jk0nr1jnes9sa7gjrfkk 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:'''==

[http://linux-hotplug.sourceforge.net HotPlug sorceforge]

[http://lua-users.org/wiki/LuaTypesTutorial Wiki de Lua]

[http://es.wikipedia.org/wiki/Arduino Articulo wikipedia Arduino]

[http://www.arduino.cc/es/ Web Arduino]