Proyecto Butiá - Contribuciones del usuario [es]

Butia reconocimiento marcas

2013-10-28T14:01:58Z

Rsisto: /* Documentación de la solución */

== Integrantes ==
* Nicolás Fúrquez
* Rafael Sisto

== Objetivos ==
* Utilizando [http://www.hitl.washington.edu/artoolkit/ ARToolKit] construir un plugin para Tortugarte/Tortublocks que permita reconocer las marcas. Esto puede ser utilizado para que el robot se localice y navegue en un entorno.

Ejemplos de marcas: 
[[Archivo:StopMark.png|300px]] [[Archivo:YieldMark.png|300px]]

Una de las cosas que nos permite la librería (ARToolKit) es que las marcas no necesariamente tienen que estar en color, permitiendo así imprimirlas en cualquier impresora siempre y cuando se mantenga el tamaño.

== Documentación de la solución ==
Se desarrolló un api que obtiene la información almacenada de las marcas y mediante la ayuda de ARToolKit se detectan las mismas en las capturas de la cámara.

El código fuente e instrucciones de instalación se pueden encontrar en el repositorio utilizado:
[http://sourceforge.net/p/butia/code/ci/master/tree/turtlebots/pattern_detection/]

Los archivos para imprimir las marcas, se encuentran en:
[http://sourceforge.net/p/butia/code/ci/master/tree/turtlebots/pattern_detection/doc/]

=== Diagrama de componentes ===
En el siguiente diagrama pueden visualizarse los componentes y su interacción. pattern_detection funciona como plugin de TurtleBlocks, que a su vez utiliza la librería multiPatternDetection (a través de un binding de python a C). Esta última utiliza funciones de ARToolKit para la detección de marcas.

[[Archivo:Arq_pattern_detection.png|400px|Arquitectura de detección de patrones con ARToolKit]]

=== Paleta reconocimiento de marcas ===
Paleta:

[[Archivo:Paleta_reco_marcas.png|700px]]

La paleta posee botones fijos que son:

'''"Viendo Señal"''':Este icono recibe como parámetro un icono de señal (imagen o texto), y nos dice si la cámara lo esta viendo o no.

'''"Distancia Señal"''':Este icono devuelve la distancia trigonométrica desde la cámara hasta el centro de la señal, la magnitud utilizada son mm. Se asume un tamaño de marcas de 16x16cm, salvo que se configure de forma distinta.

El resto se autogenera leyendo el archivo pattern_detection/library/multiPatternDetection/Data/object_data, en este archivo están todos las marcas que se pueden ver con la paleta, uno de los datos que se ponen dentro es un identificador (nombre) que al iniciarse se lee y luego se busca en la carpeta pattern_detection/images/ si tiene el icono correspondiente, si está pone la imagen como aparece en la paleta, sino lo encuentra generara el icono pero con el texto del nombre. En la sección [[Butia_reconocimiento_marcas]] se puede ver las características de estos iconos.

En este ejemplo se puede ver como se utiliza, en el código de la izquierda si la cámara ve, la señal de curva, moverá 100 la tortuga hacia adelante y luego girara a la derecha un angulo aleatorio entre -30 y 30.
En el ejemplo de la derecha si ve la señal de ''Contramano'' se movera hacia atras y cambiara la pluma a rojo, sino cambiara a azul y se movera 100 hacia adelante

[[Archivo:reconociendo_seniales_Ejemplo.png|700px]]

==== Ejemplos usando la paleta y Butia ====

Usando la marca de ''Pare'', el Butia detiene la marcha.

[[Archivo:ButiaSenialesEjemplo1.png|300px|left]] <videoflash>vF9ZhQYIwVg</videoflash>

 Usando la marca de ''Ceda el paso'', el Butia disminuye la velocidad.

[[Archivo:ButiaSenialesEjemplo2.png|300px|left]]<videoflash>Mbs5GT8vuIM</videoflash>

 Usando la marca de ''Contramano'', el Butia gira hasta no ver la marca y luego sigue adelante.

[[Archivo:ButiaSenialesEjemplo3.png|300px|left]] <videoflash>m04N9YJ7qd4</videoflash>

=== Desafíos y problemas encontrados ===
* La librería ARToolKit requiere la librería libglut.so.3 para funcionar, sin embargo en las XO no es posible instalar la librería en carpetas del sistema. Esto causa que al intentar cargar la librería con C types en python se devuelva el error ''OSError: libglut.so.3: cannot open shared object file: No such file or directory''. Para evitar este problema, se adjunta la librería en la carpeta del plugin y se carga en python previo a cargar la librería de ARToolkit con el siguiente comando: ''cdll.LoadLibrary("lib/libglut.so.3")''.

== Instalación de plugin ==
===Compilar archivos===
Son necesarias los siguientes paquetes debian para poder compilar:
libglib2.0-dev, freeglut3-dev, libgstreamer0.10-dev, libxi-dev

===Ejecución===
Para la ejecución del plugin es necesario instalar el paquete gst-plugins-good.

Si se ejecuta en una máquina configurada en idioma inglés, es necesario substituir "0,0" por "0.0" en el archivo turtle_art_plugin/pattern_recognition/library/multiPatternRecognition/Data/object_data.

===Correr script de prueba===
Opcionalmente, es posible correr pruebas para asegurarse que la detección de marcas está funcionando correctamente.

En la carpeta turtle_art_plugin/pattern_recognition/doc del código butiá, hay un pdf con la marca NotEnter. Imprimir el pdf.

Luego, ejecutar turtle_art_plugin/pattern_recognition/library/apiTestDetectMarkers.py. Al posicionar la marca impresa frente a la cámara, debería imprimirse un número en consola, que representa la distancia a la marca detectada.

== Generación de nuevas marcas ==
Es posible generar nuevas marcas utilizando una actividad creada para ese fin o de forma manual.

=== Actividad para agregar marcas ===

Se creo una actividad por la cual se puede agregar o quitar marcas, de una manera mas amena al usuario (docentes o educandos), se puede descargar la misma desde [http://download.sugarlabs.org/activities/4650/ el sitio de Sugar Labs],
La actividad se puede instalar sin tener el Plugin o Tortugarte/TortuBots, pero al abrirla avisa al usuario que no se encuentra alguno de estos elementos.
En la primer pestaña se puede ver una lista con los identificadores de las señales que están instaladas.

[[Archivo:NewPattersSegundaPestaña.png|600px]]

Si existe un icono asociado se muestra a la derecha al seleccionarlo, si no lo tiene se muestra un icono general.

[[Archivo:NewPatternsListaConSeleccion.png|600px]]

En la segunda pestaña se encuentran los campos para poder agregar una señal, Identificador, tamaño, ruta al archivo .patt y como opcional la ruta al archivo .svg que servirá de icono en la paleta.

[[Archivo:NewPattersSegundaPestaña.png|600px]]

En esta pestaña se encuentra el link a la wiki que dice como generar el .patt
En el caso que se quiera poner una identificador de señal que ya exista, la actividad preguntara si se quiere sobrescribir.

=== Manualmente a partir de patrones impresos ===
Se debe generar un archivo de la marca con un recuadro negro. Al comienzo de este artículo pueden verse imágenes de ejemplo. Al imprimirlas, recordar dejar un margen blanco de al menos 1 cm.

Luego de generados los archivos para imprimir, se deberán generar los archivos de patrones.
Para realizar esto:
# Acceder al [[Generador de patrones para plugin Reconocimento de marcas]]
# Seleccionar el origen de donde se generará el patrón. Si se utiliza la cámara, seleccionar ''Camera Mode''. Si se carga la imagen del patrón (incluyendo el recuadro negro) desde un archivo, seleccionar ''Load marker Image''
# Seleccionar tamaño de patrón, por ejemplo, si el patrón (incluyendo el recuadro negro) mide 16x16 cm, seleccionar ''16x16''
# Seleccionar porcentaje del recuadro que representa el patrón. Por ejemplo, si todo el recuadro mide 16cm y el borde negro mide 2cm, el patrón mide 12x12cm, por lo tanto 75%.
# Una vez que se vea un recuadro rojo alrededor de la marca con el rectángulo negro, presionar el botón ''Get Pattern''. Aparecerá un recuadro con los patrones reconocidos, navegar con el botón ''next'' al deseado y presionar ''Save current''. Darle un nombre al archivo en minúsculas, con la extensión '''.patt''', por ejemplo mimarca.patt

En este punto se tiene el archivo .patt generado y como último paso se debe configurar el plugin para poder comenzar a utilizarlo. Para esto:
# Copiar archivo generado (extensión .patt) a la carpeta ''pattern_detection/library/multiPatternDetection/Data/''
# Editar el archivo '''object_data''' en esa misma carpeta:
## Incrementar en 1 el número que aparece al principio (Cantidad de marcas a ser detectados).
## Agregar a continuación en el mismo archivo las líneas correspondientes al patrón, de la siguiente manera:
### Una línea representando el id de la marca
### Línea con el nombre de archivo .patt generado anteriormente
### Línea conteniendo tamaño en milímetros de la marca
### Línea conteniendo 2 decimales, separados por 1 espacio representando el punto medio de la marca.
## Guardar el archivo y cerrar.
# La marca está lista para ser utilizada y aparecerá en la paleta de Tortugarte luego de reiniciar. Por defecto aparecerá un texto con el id de la marca, pero es posible agregar un ícono, generando 1 imagen en formato svg y colocándola en la carpeta '''images/'''. Por ejemplo, para la marca con id '''Stop''' dentro del archivo '''object_data''', se debe generar 2 imágenes, una nombrándola como '''Stop'''small.svg de 40x40px y creando una copia de la misma con el nombre '''Stop'''off.svg pero de 70x70px.

== Trabajos a Futuro ==
* '''Mayor versatilidad para marcas''': El reconocimiento de marcas con ARToolKit facilitó el desarrollo de la solución, ya que al ser utilizado en otras actividades en las terminales XO acortaba el tiempo del proyecto, ya que no se tuvo que hacer un análisis de factibilidad y se tenía la librería ya compilada para los mismos, además que la generación de patrones ya viene resuelta. Sin embargo, al utilizar este API, las marcas están limitadas a una forma cuadrada y que estén contenidas dentro de un recuadro negro. Para poder evitar estas limitantes se sugiere utilizar un API de más bajo nivel como OpenCV para poder reconocer otros tipos de marcas, como por ejemplo, personas, caras, objetos, etc.
* <strike>'''Bloque para obtener distancia a marca''': La librería creada en C actualiza el estado de las marcas cuando detecta la presencia de las mismas. Entre esa información, se encuentra una matriz que tiene la posición de la marca respecto a la cámara. Se sugiere que con esta información se cree un nuevo bloque '''Distancia a la marca''', similar al detectar marca, que reciba como parámetro el id de marca y devuelva la distancia a la marca.</strike>
* <strike> '''Internacionalización''': La paleta desarrollada se realizó en idioma español, pero sería recomendable internacionalizar las etiquetas para que pueda ser localizado a otros idiomas de TurtleArt, por lo menos en inglés.</strike>

Módulo sensor Luz

2013-05-18T01:06:17Z

Rsisto: /* Materiales */

===Breve descripción===
El valor de la resistencia para la identificación del sensor de Luz es de 68kΩ. 
[[Archivo: descpLuz.jpg | 300px | Módulo Luz]]

===Diseño===

Puede descargar los archivos fuentes del diseños para kicad haciendo click [[Media: luz.tar.gz | aqui]]

Si desea construirse la placa a través del método de transferencia por tóner [http://www.fing.edu.uy/inco/proyectos/butia/files/luz-copper.pdf aqui] puede descargar el diesño de PCB en formato pdf.

===Materiales===

* Placa Sensor Modulo Luz/LDR x 1
* Sensor LDR x 1
* Resistencia 68kΩ x 2
* Conector Rj45 acodado Hembra x 1

===Construcción===
Se puede utilizar el mismo PCB que el sensor de grises

===Información adicional===
Un LDR, por sus siglas en inglés: Light Dependent Resistor (Resistor Dependiente de la Luz) también conocido en español como: foto-resistencia.

Más información, en: [http://es.wikipedia.org/wiki/Fotorresistencia Wikipedia LDR]

Testear USB4Butia

2013-05-17T23:25:26Z

Rsisto: Página creada con '== Introducción == El siguiente instructivo detalla como hacer para probar una USB4Butia nueva. == Qué se necesita? == * Placa USB4Butia * Sensor de Grises * Sensor Botón * ...'

== Introducción ==
El siguiente instructivo detalla como hacer para probar una USB4Butia nueva.

== Qué se necesita? ==
* Placa USB4Butia
* Sensor de Grises
* Sensor Botón
* Un Butiá armado (con motores y pilas)
* [https://dl.dropboxusercontent.com/u/23894356/Butia/test_usb4butia.tb Programa Turtlebots con el código aquí compartido]

== Tutorial paso a paso ==

Para probar la placa, lo primero que debemos hacer es enchufar la placa por usb a la computadora (prendida).
Si se prende el led de la placa, vamos por buen camino! En caso contrario, hay algún desperfecto en la construcción.

A continuación, si la placa no tiene grabado el bootloader, hay que grabarlo con herramientas para quemar un PIC.
Para mayor referencia, consultar la página de [[Firmware]]

Una vez que el PIC tenga grabado el bootlader, debemos grabar el firmware y actualizarlo utilizando FUA, como se detalla en [[Grabar_Firmware]]

Si todo sale bien, es posible abrir el TurtleBots y realizar los siguientes programas:

[[Archivo:Porsiempre_boton.png|300px]] [[Archivo:Porsiempre_gris.png|300px]]

Con la placa conectada a la PC, conectar un sensor [[Módulo_sensor_Boton|Botón]], esperar a que actualice la placa, y el bloque del sensor Botón, que anteriormente era gris, se pintará de verde.
Una vez que pase esto, debemos ejecutar el primer programa, presionar el botón y verificar que el valor cambie entre 0 y 1 al presionar y soltar el botón.
Realizar esta operación enchufando el botón en los distintos puertos de la placa, para verificar que todos funcionan correctamente.

Si el sensor botón funciona en todos los puertos, ejecutaremos el segundo programa, pero esta vez enchufando un sensor de [[Módulo_sensor_Grises|grises]].
El valor del sensor de grises debería mostrar distintos valores, colocando primero una hoja blanca en frente al sensor y luego una hoja negra.

Una vez que funcione todo lo anterior, estamos listos para probar los motores!
Para realizar esto:
* desenchufar la placa del usb de la PC
* enchufar las 8 pilas al robot butiá
* conectar los motores entre sí y a la placa USB4Butia.
* Encender el butiá
* Conectar el Butiá al usb de la PC.

En este momento, si tenemos el TortuBots abierto, luego de 2 ó 3 segundos, los motores girarán un poco para indicar que está todo funcionando correctamente.

Si queremos probar toda la USB4Butiá funcionando correctamente con los motores, conectamos un sensor botón y ejecutar el siguiente programa

[[Archivo:por_siempre_boton_motor.png|400px]]

Listo! Tenemos una placa USB4Butiá para programar robots!

Archivo:Porsiempre gris.png

2013-05-17T22:46:18Z

Rsisto:

Archivo:Por siempre boton motor.png

2013-05-17T22:46:09Z

Rsisto:

Archivo:Porsiempre boton.png

2013-05-17T22:46:02Z

Rsisto:

Actas Reuniones Butia

2013-03-20T23:13:45Z

Rsisto: /* 13/03/2013 */

== 20/03/2013 ==
====Firmware y Hardware====

* Se discute la alternativa elegida la reunión anterior de conectar a los hack-points y rj45 como previo a módulo motor.
** Se manda mail para discutir alternativas a futuro sobre objetivos y motores de chata CC.

== 13/03/2013 ==
====Firmware y Hardware====
*Control de motores CC:
**Módulo hardware para pwm, se descarta pwm hablado en reunión anterior (utilizando pic de usb4all), se va a hacer puente H con control binario, como paso intermedio a placa enchufada a puerto rj45. Aylen va a tener algo para mostrar jueves 14

*Hardware para controlar motores:
**Opción de identificación a rj45, con shield y cable. Se enchufa H-Bridge a los hackpoints, Rodrigo y John generan un prototipo para jueves 14.
**Shield con autoidentificacion, idea de Guille, se puede manejar a futuro, por ejemplo para módulo Bluetooth.
====Software====
*Software para controlar motores CC
**Alan adapta software, si detecta módulo de motores CC, utiliza hack points para controlar motores.

== 28/02/2013 ==

====Mecánica====
* Barandas al revés: no se cambia, el usuario debería redefinir el adelante del robot.

====Firmware y Hardware====

* puente h, llegaron unos micros que se pueden utilizar
** Se discuten alternativas:
** 1-implementar control de motores utilizando hack-points como primera alternativa - aylen empieza el desarrollo del firmware.
** Se va a diseñar un conector estandar para conectar los hack-points al módulo motores. Se discuten alternativas de como usar los pines:
*** a- Utilizar 2 pines por motor, utilizando transistores para puentear los estados del L293d
*** b- utilizar 3 pines por motor, evitando más componentes eléctricos, sacrificando hack-point
** 2-implementar protocolo ax-12 con un pic independiente (John estaba trabajando con esto), luego de la versión 2.0.

== 14/02/2013 ==

====Firmware y Hardware====

* se hicieron pruebas con el sensor de distancia a partir de un comportamiento extraño que encontró daniel. Lo raro es que el sensor no se comporta como debería para diferentes distancias da el mismo valor de voltaje. El resultado es que se aprovecha la mitad del rango del sensor en lugar de poder aprovechar todo. Probamos si era un tema de voltaje y alimentando con una fuente externa mediante un hub sigue dando el problema. Probamos conectarlo directamente a una fuente de corriente y medir con tester y funciona correctamente al parecer es un problema de ruido.

* Mejorar la serigrafía de los sensores especificando el pinout de los sensores de distancia al conectarse al PCB.

* Agregar logo butiá a los sensores.

====Software====

* Vamos a agregar a turtlebots que se deahabilite el control automático de energía para que no se suspenda el USB, tenemos lo que nos mandaron de la lista de sugar-dev. Hay que estudiar porque parece que el turtlebot ya trae un código para esto pero esta fallando, en el log se ven unos errores al intentarlo en la clase activity.

====Otros====
* Se resolvió poner en la wiki mejor documentación en la parte de construcción, en particular falta poner el conector rj45 y especificar su pinout
* El sábado 23 es el primer taller del año en colón.

== 7/02/2013 ==

====Participantes====
Alan, Pablo, Andres, John, Faivel, Humberto, Guille, Enrique, Javier, Rafael, Nicolás, Edgardo, Mario, Lucio

====minutas====
Empieza reunión a las 18:50

====Mecánica====
* Se está preparando versión de acrílicos final de Butiá SAM.

====Software====
* Bloque nuevo de casteo para adaptar el valor del sensor a un rango conocido, y los bloques de usurio a bloques conocido. En paleta extra, agrega un bloque nuevo.
** Problema: que pasa cuando se levanta devuelta el archivo, despues de reiniciar el programa? Hay que probar
* Bloque módulo user 1,2,3
* Bloque python de tortuga no funciona, no almacena el código, si no referencia al archivo. Corregir (Walter?)

====Firmware y Hardware====
* Es complicado agregar un nuevo módulo de firmware, por más que sea parecido a los anteriores.
** Agregar módulo genérico, al instanciarlo por sw, pasarle parametro el rango de identificación. (Descartado por la siguiente opción)
** Agregar módulos de usuario en fw, que sean genéricos, permitiendo así compartir el sensor con otras placas. Mantiene estructura actual de firmware. Cuando se instancia se define si es digital o análogo. Se genera un alias al instanciar en código. Tiene metodo getValue y setValue.
* Puente H, se le va a poner un micro, se está trabajando
** Generar entrada en wiki para discutir como conectar motores (placa con cantidad variable de motores, 2 motores, etc)
** El h-bridge diseñado va a permitir conectar a los hack-points o al puerto.
** Módulo usando un pin de los puertos y 2 hack-points
** Módulo utilizando un puerto con 2 pines de datos.
* Implementar módulo de PWM

== 31/01/2013 ==

====Participantes====
Alan, Pablo, Andres, John, Faivel, Humberto, Guille, Enrique, Javier

====minutas====
Empieza reunión a las 18:09

====Mecánica====
*Se realizo la prueba de colocar la rueda en el eje del motor con un prisionero directo a la rueda y dio muy buen resultado. De momento parece ser la mejor idea y queda muy prolijo.
*Se le agrego los agujeros para trasladar la placa chica de acrílico para dejar espacio para los motores de continua
*Se le agrega una ficha butia para ensamblar los motores al butia
*Parece que con esa modificación el puerto USB de la placa queda muy cerca de la rueda loca y queda tocando con el cable USB.
** Se discutio si se rota 180 la placa USB4butia quedando el USB hacia la otra direccion y los 4 conectores para sensores hacia la rueda, igual va a tocar con la rueda pero los cables de los sensores son mas flexibles y el conector no sobresale tanto o también lo de rotar todo el modulo que contiene placa, pilas y chasis chico de acrilico 180 o Intercambiar la placa con las pilas. Se decidio intercambiar la placa con las pilas.
*Se discutió sobre simetrizar los agujeros para amurar de la placa, pero se decidió que no porque pierde compatibilidad con los butias anteriores
* Se probo colocarle una rueda con el sistema del prisionero al motor de DX, el sistema de la ficha no es compatible con este pues tienen diametros distintos, se quiere llegar a una ficha mas universal por lo que se discutieron varias ideas sobre eso, quedamos en que se va a seguir investigando.
*Se dise;o el topecito para la parte de enfre con el logo de butia

====Firmware y Hardware====
*Se siguieron plantenado ideas sobre la USB4butia avanzada y lo de usar otro micro. Se va a seguir investigando
*Se planteo un idea de usar un circuito analogico con 3 estados para conectar los motores directamente a los puertos de la USB4butia

== 24/01/2013 ==

====Participantes====
Alan, Rodrigo, Pablo, Jorge, Andres, Daniel, John, Rafael, Aylen, Fiorella, Faivel, Guille, Humberto

====minutas====
Empieza reunión a las 18:26

====Mecánica====
*Se trajeron las piezas de formacril, se probaron las dos alternativas de barandas y se discutio. Se decidio que la mejor alternativa de barandas cortas con topes es mejor, pues muestra mas robustez frente a la de baranda larga y el laptop queda mas estable.
** El tope serian dos piezas universales butia, (No esta bueno que estas piezas sean de tope)
** Se decidio que el largo ideal de los tornillos para las piezas es de 4 x 0.7 de 20 mm.
*Motores: Se hizo una prueba con un prisionero y dio muy buen resultado.
*colocar el prisionero en la rueda directamente?

====Firmware====
*Seguir investigando sobre los micros buscar uno micro que sea Economico, Mercado Local, Chico y se pueda hacer PWM.
*Replantearse la idea de implementar serial por sofware y la de pwm.

====Hardware====
*Se resolvió quitar el Cristal de 32.768 que libera dos pines en la placa de los cuales uno es el PWM que se buscaba obtener
*El botón de bootloader permanece en la placa
*Colocar 2 puertos en la USB4butia compatibles con el el conector de los servos para los PWM.
*USB4butia simple y utilizar los hackpoints para controlar opción estable.
*Se hablo de hacer una placa usb4butia avanzada en dos capas y se planteo la interrogante de que es mejor: Si hacer la placa usb4butia doble capa avanzada con mas pines de datos y quizás con potencia, o mantenes la usb4butia con una capa agragando un modulo motor con otro microcontrolador.
*Crear una whish lista sobre la USB4butia

== 17/01/2013 ==

====Participantes====
Alan, Rodrigo, Pablo, Jorge, Andres, Daniel, John, Rafael

====minutas====
Empieza reunion a las 18:26

====Mecánica====
* se habló del módulo motor y la elección del pic, parece que utilizar
el micro con menos prestaciones es la opción más adecuada.
* como colocar los motores de CC : correa/directo
** se decidió que ya que tenemos motores con un buen par, no tiene
mucho sentido tener una correa.
** Surge el tema de donde colocar los motores para que siga siendo
ax12 y CC compatible, una opción para no cambiar las distribuciones
actuales es colocar los motores de CC atrás y permitir cambiar de
lugar la rueda loca para el lado opuesto al que está ahora. Hay que
tener ojo de que no obstaculice la conexión de puertos actual lo cual
es el problema que tiene ahora.
** Otro tema es como amurar la rueda a los motores, el motor que
compramos es de eje cilíndirco, hay otros con un perfil lo cual
permite que se pueda diseñar una rueda con un prisionero. Otra opción
es perforar el eje del motor y ponerle una espina para amurar la
rueda.

====Hardware====
*resolver que hacer con PWM: hackpoints, puertos
** PWM, mantener por hackpoint y generar módulo de firmware para PWM
por software utilizando Timer1 (inteligente, interrumpir solo cuando
es necesario).
** Generar informe con opciones de mantener o quitar botón de programación
* Módulo GPIO: no es equivalente al resistencia? Aporta algo?
** Evaluar quitar módulo port (porque no aporta nada)
** Evaluar agregar módulo de GPIO, permite por lo menos avisar al
usuario que está realizando una acción que puede dañar el equipo.
* Gadgets de sensore en DX, que hacer, definir ids o usar módulo
lector de voltaje, en general utilizar el de voltaje
** Crear módulos de temperatura y magnético, para laboratorios de física.
* chequear si el sensor de campo mag es analogico o digi

== 10/01/2013 ==

====Participantes====
Guillermo, Alan, , Fiorella, Pablo, Jorge, Andres, Faviel, John

====minutas====
Empieza reunion a las 18:26

====Documentación====
*Sensores de resistencia y voltage (John y Guille)
*Sensor de flexión ya esta documentado por Enrique

====Mecánica====
*Se estan haciendo los acrílicos en formacril, fecha aproximada 24
*Módulo motor hecho con carcasa de linterna utilizando una ficha butia, carcasa de un enchufe, arrancador de tubo y zunchos.
**Se discutio sobre utilizarlo con una correa o adicionarle una rueda, se decidio adicionarle la rueda y colocar el modulo en el lugar actual de las ruedas, manteniendo la estructura de los AX12, incorporándolo al butia por fuera. (Butia PUNK)
*Se habló de hacer un banco de prueba de motores para obtener datos útiles como el par, rpm , etc ...
*Se probaron los tornillos de plástico y dan buen resultado ya que protege el acrílico, son mas fácil de enroscar, mas amigables para los niños

====Hardware====
*Se discutió sobre los cambios de la USB4butia, estudiar lo de hacer una USB4butia solo para controlar motores y evaluar Modulito con microcontrolador propio para manejar motores, PIC16F628A buscar compilador GNU, buscar otro PIC de 8 patas
*Evaluar de quitar el clock de 37 khz y utilizar el pin 16 que es el CCP2 y asi evitar de quitar el boton de programacion
*Se hablo sobre sacar el boton de programacion, se decidio quitarlo y cambiar el bootloader y agregar dos puertos pwm (Si es necesario)
*Se discutió lo de quitar el bus AX12, se decidió que no porque permite agregar motores con control más complejo de forma fácil.
*Sacar los pines de programación ... ?

====Software====
*Serial por software (si se va hacer el modulo motor con pic propio)

== 03/01/2013 ==
====Participantes====
Rafa, Pablo, Pancho, Jorge, John

====Mecánica====
*Se dibujaron barandas nuevas con el tope , y se hicieron prototipos en goma eva para presentar en el butiá. Se presentó junto a la magallanes. Se discutió y se decidió hacer las barandas un poco más altas. Diseñar y construir 2 juegos de barandas: unas más largas con tope flotando y otras más cortas sin tope.
*Se mostró la nueva rueda butiá con agujero en el medio
*Se habló del modulo motor se agregan dos piezas de acrílico para mantener la estructura de los AX12 y no tener que hacer un butia distinto para la versión con otros motores. Hay dos opciones, una posee lengüetas como los AX12 y van en el mismo lugar con las ranuras existentes para los AX12 y la otra serían las fichas universales con el sistema de encastre butia.
*Estudiar agujeros para "ensanguchar" las dos planchas de acrílicos, agregar un tornillo más alineado con los que ya están con la medida de los AX12
*Se acomodó la ojiva del encastre butiá centrándola para que quede un poquito mas separdo de los rectángulos
*Se le agrega al logo la palabra SAM
*Ejemplo de logos para autoadhesivos
*Se van hacer arcilicos y autoadhesivos.
*Se va a probar el logo calado otra vez

== 27/12/2012 ==

====Participantes====
Daniel, Guillermo, Alan John, Fiorella, Aylen, Rodrigo, Enrique, Rafael, Pablo

====minutas====
* Empieza reunion a las 18:41

====Hardware====
* Acrílico había quedado mal grabado el logo la última vez, quedó una línea entrecortada.
** Se va a pedir devuelta con los logos bien grabados. Pablo trae planos el 3 de enero. Al pedir los nuevos acrílicos preguntar opciones de:
*** Pintar logos luego de grabarlos
*** Mejorar calidad del grabado para que no queden manchados.
*** Incrementar ancho de línea para que queden mejor marcados los logos.
** Pablo va a mandar a hacer pegotines calados de logos para manejar otra alternativa
** Se discute si poner nombre 2.0 o "sam". Mayoría eligió Sam (2 en charrúa)

====Motores====
* Se vio prototipo con motores de cargadores USB a dínamo, utilizando hack points.

====Software====
* Salió paquete de TortuBots v18, faltan paquetes Debian actualizar changelog (Aylen)
* Alan corrigió bug de memory leak de TortuBots, ahora no se bloquea en la XO. Está probado.
* PyBot (librería python para acceder a placa butiá) está casi listo, falta testear.
* Validación al tratar de grabar o escribir en hackpoint configurado para entrada o salida respectivamente. Hacerlo en api y agregarlo a TortuBots cuando trata de hacer una operación incorrecta. (Alan)

====Firmware====
* Módulo de Firmware de hackpoint no tiene que cambiar el modo del pin (Aylen)

== 10/12/2012 ==
====Participantes====

John, Aylen, Pablo, Gonzalo, Guillermo, Andrés, Diego, Rafael, Luis, Rodrigo, Marcelo

====minutas====
* Empieza reunion a las 19:50

====Hardware====
* Falta documentar prototipo con motores de linternas (Pancho)
* Piezas para anexar sensores: Pablo muestra 3 piezas, genérica de 2 lados, de 1 lado y una cortita.
** También se hizo pieza para reemplazar motores AX12.
** Se llega a un acuerdo de como tienen que ser las placas de sensores
* Se decide cambiar las piezas por piezas únicas para armado y reemplazo de AX12.
* Barandas, se van a cambiar por unas que empiezan finitas en la parte frontal y terminan gruesas en la parte trasera como guardabarros. En la parte delantera, tienen tope para aguantar una laptop.

====Motores====
* Motores "argentinos" no tienen certificado de origen (motor chino, engranajes argentinos)
* Guille va a mandar un mail a Fede para que averigüe en Brasil por alternativas de motores CC.
* Rodrigo, Gonzalo, van a armar prototipo con motores de cargadores USB a dínamo.

== 3/12/2012 ==
====Participantes====

John, Aylen, Pablo, Gonzalo, Guillermo, Francisco, Andrés, Daniel, Rafael, Alan, Luis

====minutas====
* Empieza reunion a las 19:30

====Hardware====
* Hay que definir los componentes para construir una serie de robots, de la mano de Antel (esperando h-bridge)
** Definir que motores de CC usar, de AP&S, modelo SP6-50, similar a AX12 ($80 argentinos), faltan definir los de Ignis (MR83-100, con pocas revoluciones y poco par), Pablo trae 2 de cada uno para probar.
* Ida a Triex sugerida por Daniel. Hay varios interesados, coordinar por mail.
* John, Andrés, definiendo USB4Motores, placa USB4All genérica, con H-bridge integrado.

====Motores====
* Motor de linterna recargable, funciona bien, Gonzalo va a comprar lintenrnas para armar un Butiá.
* Documentación de alternativas de motores: Daniel, Pablo y Francisco (documentar motores descartados - Daniel, motores de linternas recargables, Soportes Discos duros y contra chata. Motores a usar) Rafa va a mandar link de como crear usuario y stub de documento.
* Edgardo está armando el H-Bridge para controlar motores (Edgardo está armando)
* Se vieron acrílicos con logo

====firmware====
* Se solucionó problema en firmware (se estaba usando memoria inexistente)
* Andrés, Aylen, John: Trabajando en Módulo PWM por software en firmware.
* John - Falta módulo GPIO

====Sensores====
* Guille, John - Documentar en wiki como crear sensores nuevos.
* Gonzalo, mirando como funciona sensor de color.

====Software====
* Alan está escribiendo API en Python para Butia, falta contemplar varias placas USB
* Firmware update activity , está pronta la actividad 90%
* Andrés - Actualizar butialo a 2.0 (no dio el tiempo)

====Organización====
* Andrés comenta sugerencias del sumo.uy
** Agregar agujeros para tornillos
** Quejas de sensor de distancia, no se puede enganchar
** Robot Butiá triangular - Omni

== 26/11/2012 ==
====Participantes====
Luis, Marcelo, Guillermo R., Pablo Margenat, Gonzalo, Rafael Sisto, Andrés Aguirre, Aylen, Enrique, Diego, Martín , John, Javier, Alan, Fiorella

====minutas====
* Empieza reunion a las 19:30

====Hardware====
* Hay que definir los componentes para construir una serie de robots
** Definir que motores de CC usar (Quién va a definir esto?)
* Ida a Triex sugerida por Daniel. Hay varios interesados, coordinar por mail.

====Motores====
* Comisión continua Falta probar con mosfets (esperando módulo PWM de firmware)
** Cambiar circuito de muestra buscando mosfets de menor amperaje (Diego)
* Soportes de motores
** Acrílico (prontos para el 29/11), demo para 3/12
** Pancho y Pablo: cortando chasis de disco, pensando alternativas.
** Transmisión, se propone probar goma en el motor y goma en la rueda, en vez de una correa.
* Alternativas de motores:
** Linternas con generadores, se pueden usar como motores (menos de $200 en supermercados), hay que escribir en la wiki
** Andrés, Enrique - Consultar a Eneka por motores de continua hechos en Argentina (cerca de $700), modelo MR4-100, ver si tiene suficiente torque.

====firmware====
* Andrés, Aylen: Módulo PWM por software en firmware.
** (Andrés, Micho) Falta solucionar bug extraño cuando hay muchos módulos (posiblemente una asignación errónea de memoria), probar con Ida.
* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.(Se puede hacer)
** Faltan módulos GPIO y LED (Prontos, falta corregir bug).
* Pendiente Andrés - Liberar motores cuando se le mande orden velocidad cero.

====Sensores====

* Fibra óptica, se puede conseguir en Tilsit (6 metros con terminales, aprox U$ 35). Daniel va conseguir una nueva muestra actual para probar.
** Se consigue en el Clon por $65 una lámpara decorativa
** Luego de tener fibra, segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Sensores de efecto Hall (No se trató )
** Propuesta de Diego: sensor de imanes utilizando una bobina y con pin analógico.(No se trató )

====Software====

* Alan: bloque para configurar hack points, pronto, falta configurar como entrada.
* Bloque LED está.
* Alan, falta bloque GPIO
* Alan está escribiendo API en Python para Butia (falta testear, branch pybot)
* Guille, haciendo paquete Debian (armado makefile estilo GNU)
* Rodrigo, el tortuga tiene un uso excesivo de CPU (hay que ver si es nuestro o de walter) cuando se usan muchos bloques. Reproducir problema. (No se habló)
* Firmware update activity , está pronta la actividad 90%
* Andrés - Actualizar butialo a 2.0

== 19/11/2012 ==
====Participantes====
Guillermo R., Pablo Margenat, Rafael Sisto, Andrés Aguirre, Alan Aguiar , Rodrigo, Aylen, Gonzalo, Enrique, Diego

====minutas====
* Empieza reunion a las 19:30

====Motores====

* Comisión continua Falta probar con mosfets (esperando módulo PWM de firmware)
** Cambiar circuito de muestra buscando mosfets de menor amperaje (Diego)
* Soportes de motores
** Se hizo modelo, está pedido el acrílico (prontos para el 29/11), demo para 3/12
** Pancho y Pablo: cortando chasis de disco
* Buscar alternativas de motores:
** lectoras de CD, disketeras, discos duros (Diego está consiguiendo con Integra)
** Andrés está consultando en Eneka por motores de continua hechos en Argentina (cerca de $700), serían similares a los secadores de pelo, pero con reducción.
* Comision PaP - Se sigue trabajando para un prototipo, se propone controlar con circuito casero.

====firmware====

* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.
* Andrés - Liberar motores cuando se le mande orden velocidad cero.
* Andrés, Aylen: Módulo PWM por software en firmware.
* Andrés: Notificar placa como dispositivo serial al PC (avanzando).

====Sensores====

* Fibra óptica, se puede conseguir en Tilsit (6 metros con terminales, aprox U$ 35). Daniel va conseguir una nueva muestra actual para probar.
* Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Sensores de efecto Hall
** Propuesta de Diego: sensor de imanes utilizando una bobina y con pin analógico.

====Software====
* Alan: bloque para configurar hack points.
* Tortubots, tema pendiente: Generar un evento a los plugins cuando finalice la ejecución de los bloques (por ejemplo, para liberar cámara, parar motores, etc).
* Migración TurtleBlocks a android, falta librería GTK, trancado por ese tema
* Alan está escribiendo un API en python con funcionalidad similar a bobot (ventaja: no requiere lua ni dependencias de binarios adicionales, para arm no requeriría link a binarios extra, no requiere comunicación por sockets.)
* normalizar velocidades de 0 a 100. Se descarta porque no hay un problema concreto en que pueda beneficiar. En principio sirve para buscar la curiosidad de los alumnos.
* Separar paleta, ya está.
* Guille, haciendo paquete Debian.
* Rodrigo, el tortuga tiene un uso excesivo de CPU (hay que ver si es nuestro o de walter) cuando se usan muchos bloques. Reproducir problema.
* Guille, Aylen: Firmware update activity
** Actividad con un botón para actualizar (Rodrigo)

====Documentación====
* Rafael: Revisar documentación de entregables a Antel

====Resumen de Comisiones====
Soportes de motores: Pablo y Francisco

motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 12/11/2012 ==
====Participantes====
Guillermo Reisch, Diego, Daniel, John Pereira, Pablo Margenat, Rafael Sisto, Francisco Puignau, Andrés Aguirre, Martín Giachino, Alan Aguiar

====minutas====
* Empieza reunion a las 19:30

====Motores====
* Comisión continua - trajo demo con motores distintos y quedó bien el seguidoor de líneas.
** Falta probar con mosfets
* Soportes de motores
** Falta soporte para gomitas, propuesta de hacer 2 ruedas de acrílico más chicas para sostener.
** Falta soporte para rueda,
*** Proponen utilizar el mismo plato del soporte de gomitas, eje con rulemanes
*** Otra alternativa, usar motor de disco duro como rulemán (módulo independiente). (Guillermo va a traer discos duros para desarmar)
** Buscar alternativas de motores: secador de pelo (12v), lectoras de CD, disketeras
* Comision PaP - utilizar motor de impresora con driver. (para lunes 19/11)

====firmware====

* módulo firmware para bus pines digitales pronto, PWM se va a manejar por software
* firmware para sensor de voltaje pronto
* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.
* Andrés, Aylen: Módulo PWM por software en firmware.
* Andrés: Notificar placa como dispositivo serial al PC.

====Sensores====

* Demo de Módulo voltaje y resistencia
** Algunos detalles por corregir
* Fibra óptica, Daniel va a conseguir una muestra para el lunes siguiente
* (no se habló) Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises

====Software====

* Se creó bloque de sensor de voltaje
* Separar paleta, normalizar velocidades de 0 a 100 (Alan)
* Alan, el tortuga tiene un memory Leak (hay que ver si es nuestro o de walter) cuando se usan muchos bloques
* Alan, quitar compatibilidad para V1
* Guille, Aylen: Firmware update activity - postergado para próxima reunión.

====Resumen de Comisiones====
Soportes de motores: Pablo y Francisco

motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 05/11/2012 ==
====Participantes====
Gonzalo Tejera, Guillermo Reisch, Enrique Madruga, Daniel Cancela, John Pereira, Pablo Margenat, Rafael Sisto.

====minutas====
* Empieza reunion a las 19:30
* resumen, software/hardware/mecanica etc...

====Motores====
* Enrique averiguó motores alza-cristales: son caros (cerca de los $ 1000)
* Daniel mandó mail a SEMPRE, va a relevar que tipo de motores (otra chatarra) se pueden conseguir
* Comisión continua - va a avanzar con el módulo de relés
* Comisión continua - motores de secador de pelo (12v), lectoras de CD, disketeras
* Comisión continua - Preguntar a "Lechuga" qué motores usaron
* Comision PaP - utilizar motor de impresora con driver. (para lunes 19/11)
* Reducciones - 2 alternativas, correas o engranajes impresos.

====firmware====

* Aylen, agregar módulo firmware para bus pines digitales y PWM (pin 17). Si puede estar para esta semana, mejor.
* John - Otra alternativa para manejar motores, utilizar el puerto ax12 y un pic conversor a otro tipo de motores.
* Aylen - falta firmware para sensor de voltaje (estaría pronto)

====Sensores====
* sensor distancia auto chino - Enrique consultó en comercio electrónico y superan los $1000, seguir consultando alternativas.
* Fibra óptica, intentar utilizar fibra óptica de cotillón (adornos de colores)
** Daniel para el lunes se comprometió en traer un par de tramos (quizás se consigue en SEMPRE)
** Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Módulo voltaje y resistencia (demo lunes 12)
** Se decidió utilizar jumper en vez de switch
** Se creó módulo en kicad
* Firmware update activity (trabajando...)

====Software====
* Alan, crear bloque de sensor de voltaje
* Alan, hablar con Andrés y Rodrigo - El tortuga tiene un memory Leak (hay que ver si es nuestro o de walter) cuando se usan muchos bloques

====Hardware====
* Chata va a comenzar a llevar logo de Antel

====Gestión====
* Intentar convertir las reuniones en talleres

====Resumen de Comisiones====
motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 29/10/2012 ==

====Participantes====
margenat, sisto, andrew, madruga, chino, john, santiago, gonchi, pancho, aylen, rodrigo

====Minutas====
* hora de comienzo: 19:25 (19:00)
* motores...
*

====motores====
* Otra discusión sobre PaP. Andrés se va a encargar de los motores PaP.
* Motores de alza-cristales/limpia-vidrios parece una buena idea. Se consiguen en plaza, son reciclables, tienen la reducción.
* Pablo propone pieza para mantener la estructura del AX-12 y mantener la estética

====hardware====
* ver los pines que están sin utilizar.
* averiguar sensor distancia auto chino
* sensor enrique de fibra óptica para el butiá, sensor antena

==== mecánica ====
* pablo mostró la nueva chata butiá.

==== gestión ====
* se agrega a gonchi a comisión motores de continua.

== 18/10/2012 ==

====Participantes====
Gonzalo, Jorge, Luis, Martin(Chino), Aylen, John, Rodrigo, Diego (Antel), Guille, Daniel Cancela(montacargas) y Pablo(Estudiante nuevo)

====Minuta====
* Reunión del día 18/10/2012
* Hora de comienzo: 14.50
* Asisten: Gonzalo, Jorge, Luis, Martin(Chino), Aylen, John, Rodrigo, Diego (Antel), Guille, Daniel Cancela(montacargas) y Pablo(Estudiante nuevo)
* Presentación del proyecto a la gente nueva
* Motores
* Modulo voltaje,
* Fin reunión 17.15

====motores====
* discusión por motores nuevamente
* Comisión motores no hizo mucho. Se presentó precio de servos 28u$s de 15kg, 16u$s de 6,8kg. Se va a seguir averiguando en otros lados.
* NO steppers (daniel va a averiguar algo sobre steppers)
* Hay que conseguir los motores de destornillador.

====hardware====
* modulo voltaje y resistencia (guille, egardo, enrique)
* bornera o jack? (jack hace corto,[los jack machos truchos, los buenos NO HACEN CORTO {Guille}])
* protección? volver al diodo que no pusimos
* egardo y guille hoy van a encargarse del hardware
* conseguir conectores bosch mas chicos o cables mejores (guille) llevar el cable de ax12 original

====software====
* activity cambiar id (rodrigo)
* ayle john chino van a agregar funcionalidades al modulo ax12 para actividad de id
* (chequear wiki de mtbutia que estan haciendo algo parecido)
* Tortuga con varios hilos (elemichele, alan el hombre tortuga, andres) quiere hacer un tortuga con varios hilos

====firmware====
* firmware modulo voltaje y resistencia listo
* a FUA agregar un browse para poder grabar un .hex propio
* agregar consultar versión y la id de placa
* pasaje a serial jorge
* discusión sobre versionado de firmware y hardware
* gonchi propone agregar resistencia para versionado de placa
* versionado del firmware
* john va a revisar codigo, hotplug en motores
* git migrar pnp a master, ya estaría pronto
* hackpoint (andres)

====gestión====
* Diego Antel propone: taller utu-antel en la teja segunda quincena enero (john y jorge)
* antel pide un butia mas (hay que discutir esto)
* Daniel plantea tirar lineas a ute (manejando como se manejó con ANTel)
* comisión conseguir openmoko (gonchi jorge)
* openmoko??????? es probable dijo pablo sigue en camino.
* Chino va a compartir la documentación para antel. (NO METER MANO SIN CONSULTARLO A ÉL)
* Pedido por parte de edgardo, chino y enrique para cambiar la reunión
* Se propone reunion los LUNES 18:30

== 11/10/2012 ==

====Participantes====
Rodrigo, John, Edgardo, Enrique, Gonzalo.

====Minuta====
* Acta de la reunión realizada el 11/10/2012
* Motores reciclados
* firmware: actualizador y mejoras
* devolución de robots

====hardware====
* Andrés opina que los servos no cumplen con lo propuesto por el proyecto butiá 2.0 ya que no se pueden reciclar.
* Gonzalo opina que los motores stepper no son aptos.
* Se decidió comenzar a investigar motores de corriente continua y servos que se consigan en uruguay.
* Rodri va a averiguar el costo de servos con gran torque en el mercado local y de corriente continua en casas del estilo repuestos de auto. Incluso se puede ver si la reducción de alguno de los respuestos de auto no es de utilidad.
* Luego se hará una prueba con motores del tipo stepper para mantener una alternativa de reciclado que es abundante en Uruguay.
* Por otro lado se priorizó la construcción de los módulos para leer voltaje y resistencia. Esto sería una alternativa a lo que la XO trae para leer del puerto de audio, pero independiente de la computadora. Tanto Guzmán como Enrique hoy día están haciendo muchos sensores interesantes que pueden prototiparse rápido de esta manera, además de dar continuidad al proyecto Física con XO. La idea es comenzar con una primer versión para tener algo para pasarle a Guzmán lo antes posible. La idea es que a futuro incluya protección pero si los tiempos no dan realizar la primer versión simple sin protección que de hecho es lo que tiene la XO hoy día.

====firmware/software====
* aplicación cambiar el id, cambiar id de los motores (rodrigo)
* aplicación FUA (inc hex) rompemos compatibilidad para la v1
* hotplug en motores
* hackpoint módulo firmware
* pasaje a dispositivo serial (toribio compatibilidad) por defecto esta activado el control de energía de la XO definir versionado de firmware

====mecánica:====
* fichas, metodos conexión, eles, rivetes, compatibilidad con mecano, mejorar la compatiblidad con lego compatibilidad con otras computadoras? Compatibilidad lego ser menos dependiente de las cruces dejar solo agujeros con separación lego y más grandes. De 4.6 mm a 5mm explorar motores continua y servo (enrique servo + edgardo) comisión de encastre (pablo, rodrigo)y sin espacio para la mano baranda cuadrada con agujeritos computadora sobre la baranda pinza: 1 o 2 motores, ver si no es muy complicado usar 1 motor.
* Git migrar pnp a master

====gestión:====
* a fin de año tiene que devolver el robot (prestamo por un año)
* Se definió la comisión de motores: Rodrigo, John, Edgardo y Enrique

TurtleBots

2013-03-17T19:04:25Z

Rsisto: Redirigiendo a TortuBots

#REDIRECCIÓN [[TortuBots]]

Actas Reuniones Butia

2013-03-13T23:26:48Z

Rsisto: /* 28/02/2013 */

== 13/03/2013 ==
====Firmware y Hardware====
*Control de motores CC:
**Módulo hardware para pwm, se descarta pwm hablado en reunión anterior (utilizando pic de usb4all), se va a hacer puente H con control binario, como paso intermedio a placa enchufada a puerto rj45. Aylen va a tener algo para mostrar jueves 14

*Hardware para controlar motores:
**Opción de identificación a rj45, con shield y cable. Se enchufa H-Bridge a los hackpoints, Rodrigo y John generan un prototipo para jueves 14.
**Shield con autoidentificacion, idea de Guille, se puede manejar a futuro, por ejemplo para módulo Bluetooth.
====Software====
*Software para controlar motores CC
**Alan adapta software, si detecta módulo de motores CC, utiliza hack points para controlar motores.

== 28/02/2013 ==

====Mecánica====
* Barandas al revés: no se cambia, el usuario debería redefinir el adelante del robot.

====Firmware y Hardware====

* puente h, llegaron unos micros que se pueden utilizar
** Se discuten alternativas:
** 1-implementar control de motores utilizando hack-points como primera alternativa - aylen empieza el desarrollo del firmware.
** Se va a diseñar un conector estandar para conectar los hack-points al módulo motores. Se discuten alternativas de como usar los pines:
*** a- Utilizar 2 pines por motor, utilizando transistores para puentear los estados del L293d
*** b- utilizar 3 pines por motor, evitando más componentes eléctricos, sacrificando hack-point
** 2-implementar protocolo ax-12 con un pic independiente (John estaba trabajando con esto), luego de la versión 2.0.

== 14/02/2013 ==

====Firmware y Hardware====

* se hicieron pruebas con el sensor de distancia a partir de un comportamiento extraño que encontró daniel. Lo raro es que el sensor no se comporta como debería para diferentes distancias da el mismo valor de voltaje. El resultado es que se aprovecha la mitad del rango del sensor en lugar de poder aprovechar todo. Probamos si era un tema de voltaje y alimentando con una fuente externa mediante un hub sigue dando el problema. Probamos conectarlo directamente a una fuente de corriente y medir con tester y funciona correctamente al parecer es un problema de ruido.

* Mejorar la serigrafía de los sensores especificando el pinout de los sensores de distancia al conectarse al PCB.

* Agregar logo butiá a los sensores.

====Software====

* Vamos a agregar a turtlebots que se deahabilite el control automático de energía para que no se suspenda el USB, tenemos lo que nos mandaron de la lista de sugar-dev. Hay que estudiar porque parece que el turtlebot ya trae un código para esto pero esta fallando, en el log se ven unos errores al intentarlo en la clase activity.

====Otros====
* Se resolvió poner en la wiki mejor documentación en la parte de construcción, en particular falta poner el conector rj45 y especificar su pinout
* El sábado 23 es el primer taller del año en colón.

== 7/02/2013 ==

====Participantes====
Alan, Pablo, Andres, John, Faivel, Humberto, Guille, Enrique, Javier, Rafael, Nicolás, Edgardo, Mario, Lucio

====minutas====
Empieza reunión a las 18:50

====Mecánica====
* Se está preparando versión de acrílicos final de Butiá SAM.

====Software====
* Bloque nuevo de casteo para adaptar el valor del sensor a un rango conocido, y los bloques de usurio a bloques conocido. En paleta extra, agrega un bloque nuevo.
** Problema: que pasa cuando se levanta devuelta el archivo, despues de reiniciar el programa? Hay que probar
* Bloque módulo user 1,2,3
* Bloque python de tortuga no funciona, no almacena el código, si no referencia al archivo. Corregir (Walter?)

====Firmware y Hardware====
* Es complicado agregar un nuevo módulo de firmware, por más que sea parecido a los anteriores.
** Agregar módulo genérico, al instanciarlo por sw, pasarle parametro el rango de identificación. (Descartado por la siguiente opción)
** Agregar módulos de usuario en fw, que sean genéricos, permitiendo así compartir el sensor con otras placas. Mantiene estructura actual de firmware. Cuando se instancia se define si es digital o análogo. Se genera un alias al instanciar en código. Tiene metodo getValue y setValue.
* Puente H, se le va a poner un micro, se está trabajando
** Generar entrada en wiki para discutir como conectar motores (placa con cantidad variable de motores, 2 motores, etc)
** El h-bridge diseñado va a permitir conectar a los hack-points o al puerto.
** Módulo usando un pin de los puertos y 2 hack-points
** Módulo utilizando un puerto con 2 pines de datos.
* Implementar módulo de PWM

== 31/01/2013 ==

====Participantes====
Alan, Pablo, Andres, John, Faivel, Humberto, Guille, Enrique, Javier

====minutas====
Empieza reunión a las 18:09

====Mecánica====
*Se realizo la prueba de colocar la rueda en el eje del motor con un prisionero directo a la rueda y dio muy buen resultado. De momento parece ser la mejor idea y queda muy prolijo.
*Se le agrego los agujeros para trasladar la placa chica de acrílico para dejar espacio para los motores de continua
*Se le agrega una ficha butia para ensamblar los motores al butia
*Parece que con esa modificación el puerto USB de la placa queda muy cerca de la rueda loca y queda tocando con el cable USB.
** Se discutio si se rota 180 la placa USB4butia quedando el USB hacia la otra direccion y los 4 conectores para sensores hacia la rueda, igual va a tocar con la rueda pero los cables de los sensores son mas flexibles y el conector no sobresale tanto o también lo de rotar todo el modulo que contiene placa, pilas y chasis chico de acrilico 180 o Intercambiar la placa con las pilas. Se decidio intercambiar la placa con las pilas.
*Se discutió sobre simetrizar los agujeros para amurar de la placa, pero se decidió que no porque pierde compatibilidad con los butias anteriores
* Se probo colocarle una rueda con el sistema del prisionero al motor de DX, el sistema de la ficha no es compatible con este pues tienen diametros distintos, se quiere llegar a una ficha mas universal por lo que se discutieron varias ideas sobre eso, quedamos en que se va a seguir investigando.
*Se dise;o el topecito para la parte de enfre con el logo de butia

====Firmware y Hardware====
*Se siguieron plantenado ideas sobre la USB4butia avanzada y lo de usar otro micro. Se va a seguir investigando
*Se planteo un idea de usar un circuito analogico con 3 estados para conectar los motores directamente a los puertos de la USB4butia

== 24/01/2013 ==

====Participantes====
Alan, Rodrigo, Pablo, Jorge, Andres, Daniel, John, Rafael, Aylen, Fiorella, Faivel, Guille, Humberto

====minutas====
Empieza reunión a las 18:26

====Mecánica====
*Se trajeron las piezas de formacril, se probaron las dos alternativas de barandas y se discutio. Se decidio que la mejor alternativa de barandas cortas con topes es mejor, pues muestra mas robustez frente a la de baranda larga y el laptop queda mas estable.
** El tope serian dos piezas universales butia, (No esta bueno que estas piezas sean de tope)
** Se decidio que el largo ideal de los tornillos para las piezas es de 4 x 0.7 de 20 mm.
*Motores: Se hizo una prueba con un prisionero y dio muy buen resultado.
*colocar el prisionero en la rueda directamente?

====Firmware====
*Seguir investigando sobre los micros buscar uno micro que sea Economico, Mercado Local, Chico y se pueda hacer PWM.
*Replantearse la idea de implementar serial por sofware y la de pwm.

====Hardware====
*Se resolvió quitar el Cristal de 32.768 que libera dos pines en la placa de los cuales uno es el PWM que se buscaba obtener
*El botón de bootloader permanece en la placa
*Colocar 2 puertos en la USB4butia compatibles con el el conector de los servos para los PWM.
*USB4butia simple y utilizar los hackpoints para controlar opción estable.
*Se hablo de hacer una placa usb4butia avanzada en dos capas y se planteo la interrogante de que es mejor: Si hacer la placa usb4butia doble capa avanzada con mas pines de datos y quizás con potencia, o mantenes la usb4butia con una capa agragando un modulo motor con otro microcontrolador.
*Crear una whish lista sobre la USB4butia

== 17/01/2013 ==

====Participantes====
Alan, Rodrigo, Pablo, Jorge, Andres, Daniel, John, Rafael

====minutas====
Empieza reunion a las 18:26

====Mecánica====
* se habló del módulo motor y la elección del pic, parece que utilizar
el micro con menos prestaciones es la opción más adecuada.
* como colocar los motores de CC : correa/directo
** se decidió que ya que tenemos motores con un buen par, no tiene
mucho sentido tener una correa.
** Surge el tema de donde colocar los motores para que siga siendo
ax12 y CC compatible, una opción para no cambiar las distribuciones
actuales es colocar los motores de CC atrás y permitir cambiar de
lugar la rueda loca para el lado opuesto al que está ahora. Hay que
tener ojo de que no obstaculice la conexión de puertos actual lo cual
es el problema que tiene ahora.
** Otro tema es como amurar la rueda a los motores, el motor que
compramos es de eje cilíndirco, hay otros con un perfil lo cual
permite que se pueda diseñar una rueda con un prisionero. Otra opción
es perforar el eje del motor y ponerle una espina para amurar la
rueda.

====Hardware====
*resolver que hacer con PWM: hackpoints, puertos
** PWM, mantener por hackpoint y generar módulo de firmware para PWM
por software utilizando Timer1 (inteligente, interrumpir solo cuando
es necesario).
** Generar informe con opciones de mantener o quitar botón de programación
* Módulo GPIO: no es equivalente al resistencia? Aporta algo?
** Evaluar quitar módulo port (porque no aporta nada)
** Evaluar agregar módulo de GPIO, permite por lo menos avisar al
usuario que está realizando una acción que puede dañar el equipo.
* Gadgets de sensore en DX, que hacer, definir ids o usar módulo
lector de voltaje, en general utilizar el de voltaje
** Crear módulos de temperatura y magnético, para laboratorios de física.
* chequear si el sensor de campo mag es analogico o digi

== 10/01/2013 ==

====Participantes====
Guillermo, Alan, , Fiorella, Pablo, Jorge, Andres, Faviel, John

====minutas====
Empieza reunion a las 18:26

====Documentación====
*Sensores de resistencia y voltage (John y Guille)
*Sensor de flexión ya esta documentado por Enrique

====Mecánica====
*Se estan haciendo los acrílicos en formacril, fecha aproximada 24
*Módulo motor hecho con carcasa de linterna utilizando una ficha butia, carcasa de un enchufe, arrancador de tubo y zunchos.
**Se discutio sobre utilizarlo con una correa o adicionarle una rueda, se decidio adicionarle la rueda y colocar el modulo en el lugar actual de las ruedas, manteniendo la estructura de los AX12, incorporándolo al butia por fuera. (Butia PUNK)
*Se habló de hacer un banco de prueba de motores para obtener datos útiles como el par, rpm , etc ...
*Se probaron los tornillos de plástico y dan buen resultado ya que protege el acrílico, son mas fácil de enroscar, mas amigables para los niños

====Hardware====
*Se discutió sobre los cambios de la USB4butia, estudiar lo de hacer una USB4butia solo para controlar motores y evaluar Modulito con microcontrolador propio para manejar motores, PIC16F628A buscar compilador GNU, buscar otro PIC de 8 patas
*Evaluar de quitar el clock de 37 khz y utilizar el pin 16 que es el CCP2 y asi evitar de quitar el boton de programacion
*Se hablo sobre sacar el boton de programacion, se decidio quitarlo y cambiar el bootloader y agregar dos puertos pwm (Si es necesario)
*Se discutió lo de quitar el bus AX12, se decidió que no porque permite agregar motores con control más complejo de forma fácil.
*Sacar los pines de programación ... ?

====Software====
*Serial por software (si se va hacer el modulo motor con pic propio)

== 03/01/2013 ==
====Participantes====
Rafa, Pablo, Pancho, Jorge, John

====Mecánica====
*Se dibujaron barandas nuevas con el tope , y se hicieron prototipos en goma eva para presentar en el butiá. Se presentó junto a la magallanes. Se discutió y se decidió hacer las barandas un poco más altas. Diseñar y construir 2 juegos de barandas: unas más largas con tope flotando y otras más cortas sin tope.
*Se mostró la nueva rueda butiá con agujero en el medio
*Se habló del modulo motor se agregan dos piezas de acrílico para mantener la estructura de los AX12 y no tener que hacer un butia distinto para la versión con otros motores. Hay dos opciones, una posee lengüetas como los AX12 y van en el mismo lugar con las ranuras existentes para los AX12 y la otra serían las fichas universales con el sistema de encastre butia.
*Estudiar agujeros para "ensanguchar" las dos planchas de acrílicos, agregar un tornillo más alineado con los que ya están con la medida de los AX12
*Se acomodó la ojiva del encastre butiá centrándola para que quede un poquito mas separdo de los rectángulos
*Se le agrega al logo la palabra SAM
*Ejemplo de logos para autoadhesivos
*Se van hacer arcilicos y autoadhesivos.
*Se va a probar el logo calado otra vez

== 27/12/2012 ==

====Participantes====
Daniel, Guillermo, Alan John, Fiorella, Aylen, Rodrigo, Enrique, Rafael, Pablo

====minutas====
* Empieza reunion a las 18:41

====Hardware====
* Acrílico había quedado mal grabado el logo la última vez, quedó una línea entrecortada.
** Se va a pedir devuelta con los logos bien grabados. Pablo trae planos el 3 de enero. Al pedir los nuevos acrílicos preguntar opciones de:
*** Pintar logos luego de grabarlos
*** Mejorar calidad del grabado para que no queden manchados.
*** Incrementar ancho de línea para que queden mejor marcados los logos.
** Pablo va a mandar a hacer pegotines calados de logos para manejar otra alternativa
** Se discute si poner nombre 2.0 o "sam". Mayoría eligió Sam (2 en charrúa)

====Motores====
* Se vio prototipo con motores de cargadores USB a dínamo, utilizando hack points.

====Software====
* Salió paquete de TortuBots v18, faltan paquetes Debian actualizar changelog (Aylen)
* Alan corrigió bug de memory leak de TortuBots, ahora no se bloquea en la XO. Está probado.
* PyBot (librería python para acceder a placa butiá) está casi listo, falta testear.
* Validación al tratar de grabar o escribir en hackpoint configurado para entrada o salida respectivamente. Hacerlo en api y agregarlo a TortuBots cuando trata de hacer una operación incorrecta. (Alan)

====Firmware====
* Módulo de Firmware de hackpoint no tiene que cambiar el modo del pin (Aylen)

== 10/12/2012 ==
====Participantes====

John, Aylen, Pablo, Gonzalo, Guillermo, Andrés, Diego, Rafael, Luis, Rodrigo, Marcelo

====minutas====
* Empieza reunion a las 19:50

====Hardware====
* Falta documentar prototipo con motores de linternas (Pancho)
* Piezas para anexar sensores: Pablo muestra 3 piezas, genérica de 2 lados, de 1 lado y una cortita.
** También se hizo pieza para reemplazar motores AX12.
** Se llega a un acuerdo de como tienen que ser las placas de sensores
* Se decide cambiar las piezas por piezas únicas para armado y reemplazo de AX12.
* Barandas, se van a cambiar por unas que empiezan finitas en la parte frontal y terminan gruesas en la parte trasera como guardabarros. En la parte delantera, tienen tope para aguantar una laptop.

====Motores====
* Motores "argentinos" no tienen certificado de origen (motor chino, engranajes argentinos)
* Guille va a mandar un mail a Fede para que averigüe en Brasil por alternativas de motores CC.
* Rodrigo, Gonzalo, van a armar prototipo con motores de cargadores USB a dínamo.

== 3/12/2012 ==
====Participantes====

John, Aylen, Pablo, Gonzalo, Guillermo, Francisco, Andrés, Daniel, Rafael, Alan, Luis

====minutas====
* Empieza reunion a las 19:30

====Hardware====
* Hay que definir los componentes para construir una serie de robots, de la mano de Antel (esperando h-bridge)
** Definir que motores de CC usar, de AP&S, modelo SP6-50, similar a AX12 ($80 argentinos), faltan definir los de Ignis (MR83-100, con pocas revoluciones y poco par), Pablo trae 2 de cada uno para probar.
* Ida a Triex sugerida por Daniel. Hay varios interesados, coordinar por mail.
* John, Andrés, definiendo USB4Motores, placa USB4All genérica, con H-bridge integrado.

====Motores====
* Motor de linterna recargable, funciona bien, Gonzalo va a comprar lintenrnas para armar un Butiá.
* Documentación de alternativas de motores: Daniel, Pablo y Francisco (documentar motores descartados - Daniel, motores de linternas recargables, Soportes Discos duros y contra chata. Motores a usar) Rafa va a mandar link de como crear usuario y stub de documento.
* Edgardo está armando el H-Bridge para controlar motores (Edgardo está armando)
* Se vieron acrílicos con logo

====firmware====
* Se solucionó problema en firmware (se estaba usando memoria inexistente)
* Andrés, Aylen, John: Trabajando en Módulo PWM por software en firmware.
* John - Falta módulo GPIO

====Sensores====
* Guille, John - Documentar en wiki como crear sensores nuevos.
* Gonzalo, mirando como funciona sensor de color.

====Software====
* Alan está escribiendo API en Python para Butia, falta contemplar varias placas USB
* Firmware update activity , está pronta la actividad 90%
* Andrés - Actualizar butialo a 2.0 (no dio el tiempo)

====Organización====
* Andrés comenta sugerencias del sumo.uy
** Agregar agujeros para tornillos
** Quejas de sensor de distancia, no se puede enganchar
** Robot Butiá triangular - Omni

== 26/11/2012 ==
====Participantes====
Luis, Marcelo, Guillermo R., Pablo Margenat, Gonzalo, Rafael Sisto, Andrés Aguirre, Aylen, Enrique, Diego, Martín , John, Javier, Alan, Fiorella

====minutas====
* Empieza reunion a las 19:30

====Hardware====
* Hay que definir los componentes para construir una serie de robots
** Definir que motores de CC usar (Quién va a definir esto?)
* Ida a Triex sugerida por Daniel. Hay varios interesados, coordinar por mail.

====Motores====
* Comisión continua Falta probar con mosfets (esperando módulo PWM de firmware)
** Cambiar circuito de muestra buscando mosfets de menor amperaje (Diego)
* Soportes de motores
** Acrílico (prontos para el 29/11), demo para 3/12
** Pancho y Pablo: cortando chasis de disco, pensando alternativas.
** Transmisión, se propone probar goma en el motor y goma en la rueda, en vez de una correa.
* Alternativas de motores:
** Linternas con generadores, se pueden usar como motores (menos de $200 en supermercados), hay que escribir en la wiki
** Andrés, Enrique - Consultar a Eneka por motores de continua hechos en Argentina (cerca de $700), modelo MR4-100, ver si tiene suficiente torque.

====firmware====
* Andrés, Aylen: Módulo PWM por software en firmware.
** (Andrés, Micho) Falta solucionar bug extraño cuando hay muchos módulos (posiblemente una asignación errónea de memoria), probar con Ida.
* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.(Se puede hacer)
** Faltan módulos GPIO y LED (Prontos, falta corregir bug).
* Pendiente Andrés - Liberar motores cuando se le mande orden velocidad cero.

====Sensores====

* Fibra óptica, se puede conseguir en Tilsit (6 metros con terminales, aprox U$ 35). Daniel va conseguir una nueva muestra actual para probar.
** Se consigue en el Clon por $65 una lámpara decorativa
** Luego de tener fibra, segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Sensores de efecto Hall (No se trató )
** Propuesta de Diego: sensor de imanes utilizando una bobina y con pin analógico.(No se trató )

====Software====

* Alan: bloque para configurar hack points, pronto, falta configurar como entrada.
* Bloque LED está.
* Alan, falta bloque GPIO
* Alan está escribiendo API en Python para Butia (falta testear, branch pybot)
* Guille, haciendo paquete Debian (armado makefile estilo GNU)
* Rodrigo, el tortuga tiene un uso excesivo de CPU (hay que ver si es nuestro o de walter) cuando se usan muchos bloques. Reproducir problema. (No se habló)
* Firmware update activity , está pronta la actividad 90%
* Andrés - Actualizar butialo a 2.0

== 19/11/2012 ==
====Participantes====
Guillermo R., Pablo Margenat, Rafael Sisto, Andrés Aguirre, Alan Aguiar , Rodrigo, Aylen, Gonzalo, Enrique, Diego

====minutas====
* Empieza reunion a las 19:30

====Motores====

* Comisión continua Falta probar con mosfets (esperando módulo PWM de firmware)
** Cambiar circuito de muestra buscando mosfets de menor amperaje (Diego)
* Soportes de motores
** Se hizo modelo, está pedido el acrílico (prontos para el 29/11), demo para 3/12
** Pancho y Pablo: cortando chasis de disco
* Buscar alternativas de motores:
** lectoras de CD, disketeras, discos duros (Diego está consiguiendo con Integra)
** Andrés está consultando en Eneka por motores de continua hechos en Argentina (cerca de $700), serían similares a los secadores de pelo, pero con reducción.
* Comision PaP - Se sigue trabajando para un prototipo, se propone controlar con circuito casero.

====firmware====

* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.
* Andrés - Liberar motores cuando se le mande orden velocidad cero.
* Andrés, Aylen: Módulo PWM por software en firmware.
* Andrés: Notificar placa como dispositivo serial al PC (avanzando).

====Sensores====

* Fibra óptica, se puede conseguir en Tilsit (6 metros con terminales, aprox U$ 35). Daniel va conseguir una nueva muestra actual para probar.
* Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Sensores de efecto Hall
** Propuesta de Diego: sensor de imanes utilizando una bobina y con pin analógico.

====Software====
* Alan: bloque para configurar hack points.
* Tortubots, tema pendiente: Generar un evento a los plugins cuando finalice la ejecución de los bloques (por ejemplo, para liberar cámara, parar motores, etc).
* Migración TurtleBlocks a android, falta librería GTK, trancado por ese tema
* Alan está escribiendo un API en python con funcionalidad similar a bobot (ventaja: no requiere lua ni dependencias de binarios adicionales, para arm no requeriría link a binarios extra, no requiere comunicación por sockets.)
* normalizar velocidades de 0 a 100. Se descarta porque no hay un problema concreto en que pueda beneficiar. En principio sirve para buscar la curiosidad de los alumnos.
* Separar paleta, ya está.
* Guille, haciendo paquete Debian.
* Rodrigo, el tortuga tiene un uso excesivo de CPU (hay que ver si es nuestro o de walter) cuando se usan muchos bloques. Reproducir problema.
* Guille, Aylen: Firmware update activity
** Actividad con un botón para actualizar (Rodrigo)

====Documentación====
* Rafael: Revisar documentación de entregables a Antel

====Resumen de Comisiones====
Soportes de motores: Pablo y Francisco

motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 12/11/2012 ==
====Participantes====
Guillermo Reisch, Diego, Daniel, John Pereira, Pablo Margenat, Rafael Sisto, Francisco Puignau, Andrés Aguirre, Martín Giachino, Alan Aguiar

====minutas====
* Empieza reunion a las 19:30

====Motores====
* Comisión continua - trajo demo con motores distintos y quedó bien el seguidoor de líneas.
** Falta probar con mosfets
* Soportes de motores
** Falta soporte para gomitas, propuesta de hacer 2 ruedas de acrílico más chicas para sostener.
** Falta soporte para rueda,
*** Proponen utilizar el mismo plato del soporte de gomitas, eje con rulemanes
*** Otra alternativa, usar motor de disco duro como rulemán (módulo independiente). (Guillermo va a traer discos duros para desarmar)
** Buscar alternativas de motores: secador de pelo (12v), lectoras de CD, disketeras
* Comision PaP - utilizar motor de impresora con driver. (para lunes 19/11)

====firmware====

* módulo firmware para bus pines digitales pronto, PWM se va a manejar por software
* firmware para sensor de voltaje pronto
* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.
* Andrés, Aylen: Módulo PWM por software en firmware.
* Andrés: Notificar placa como dispositivo serial al PC.

====Sensores====

* Demo de Módulo voltaje y resistencia
** Algunos detalles por corregir
* Fibra óptica, Daniel va a conseguir una muestra para el lunes siguiente
* (no se habló) Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises

====Software====

* Se creó bloque de sensor de voltaje
* Separar paleta, normalizar velocidades de 0 a 100 (Alan)
* Alan, el tortuga tiene un memory Leak (hay que ver si es nuestro o de walter) cuando se usan muchos bloques
* Alan, quitar compatibilidad para V1
* Guille, Aylen: Firmware update activity - postergado para próxima reunión.

====Resumen de Comisiones====
Soportes de motores: Pablo y Francisco

motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 05/11/2012 ==
====Participantes====
Gonzalo Tejera, Guillermo Reisch, Enrique Madruga, Daniel Cancela, John Pereira, Pablo Margenat, Rafael Sisto.

====minutas====
* Empieza reunion a las 19:30
* resumen, software/hardware/mecanica etc...

====Motores====
* Enrique averiguó motores alza-cristales: son caros (cerca de los $ 1000)
* Daniel mandó mail a SEMPRE, va a relevar que tipo de motores (otra chatarra) se pueden conseguir
* Comisión continua - va a avanzar con el módulo de relés
* Comisión continua - motores de secador de pelo (12v), lectoras de CD, disketeras
* Comisión continua - Preguntar a "Lechuga" qué motores usaron
* Comision PaP - utilizar motor de impresora con driver. (para lunes 19/11)
* Reducciones - 2 alternativas, correas o engranajes impresos.

====firmware====

* Aylen, agregar módulo firmware para bus pines digitales y PWM (pin 17). Si puede estar para esta semana, mejor.
* John - Otra alternativa para manejar motores, utilizar el puerto ax12 y un pic conversor a otro tipo de motores.
* Aylen - falta firmware para sensor de voltaje (estaría pronto)

====Sensores====
* sensor distancia auto chino - Enrique consultó en comercio electrónico y superan los $1000, seguir consultando alternativas.
* Fibra óptica, intentar utilizar fibra óptica de cotillón (adornos de colores)
** Daniel para el lunes se comprometió en traer un par de tramos (quizás se consigue en SEMPRE)
** Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Módulo voltaje y resistencia (demo lunes 12)
** Se decidió utilizar jumper en vez de switch
** Se creó módulo en kicad
* Firmware update activity (trabajando...)

====Software====
* Alan, crear bloque de sensor de voltaje
* Alan, hablar con Andrés y Rodrigo - El tortuga tiene un memory Leak (hay que ver si es nuestro o de walter) cuando se usan muchos bloques

====Hardware====
* Chata va a comenzar a llevar logo de Antel

====Gestión====
* Intentar convertir las reuniones en talleres

====Resumen de Comisiones====
motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 29/10/2012 ==

====Participantes====
margenat, sisto, andrew, madruga, chino, john, santiago, gonchi, pancho, aylen, rodrigo

====Minutas====
* hora de comienzo: 19:25 (19:00)
* motores...
*

====motores====
* Otra discusión sobre PaP. Andrés se va a encargar de los motores PaP.
* Motores de alza-cristales/limpia-vidrios parece una buena idea. Se consiguen en plaza, son reciclables, tienen la reducción.
* Pablo propone pieza para mantener la estructura del AX-12 y mantener la estética

====hardware====
* ver los pines que están sin utilizar.
* averiguar sensor distancia auto chino
* sensor enrique de fibra óptica para el butiá, sensor antena

==== mecánica ====
* pablo mostró la nueva chata butiá.

==== gestión ====
* se agrega a gonchi a comisión motores de continua.

== 18/10/2012 ==

====Participantes====
Gonzalo, Jorge, Luis, Martin(Chino), Aylen, John, Rodrigo, Diego (Antel), Guille, Daniel Cancela(montacargas) y Pablo(Estudiante nuevo)

====Minuta====
* Reunión del día 18/10/2012
* Hora de comienzo: 14.50
* Asisten: Gonzalo, Jorge, Luis, Martin(Chino), Aylen, John, Rodrigo, Diego (Antel), Guille, Daniel Cancela(montacargas) y Pablo(Estudiante nuevo)
* Presentación del proyecto a la gente nueva
* Motores
* Modulo voltaje,
* Fin reunión 17.15

====motores====
* discusión por motores nuevamente
* Comisión motores no hizo mucho. Se presentó precio de servos 28u$s de 15kg, 16u$s de 6,8kg. Se va a seguir averiguando en otros lados.
* NO steppers (daniel va a averiguar algo sobre steppers)
* Hay que conseguir los motores de destornillador.

====hardware====
* modulo voltaje y resistencia (guille, egardo, enrique)
* bornera o jack? (jack hace corto,[los jack machos truchos, los buenos NO HACEN CORTO {Guille}])
* protección? volver al diodo que no pusimos
* egardo y guille hoy van a encargarse del hardware
* conseguir conectores bosch mas chicos o cables mejores (guille) llevar el cable de ax12 original

====software====
* activity cambiar id (rodrigo)
* ayle john chino van a agregar funcionalidades al modulo ax12 para actividad de id
* (chequear wiki de mtbutia que estan haciendo algo parecido)
* Tortuga con varios hilos (elemichele, alan el hombre tortuga, andres) quiere hacer un tortuga con varios hilos

====firmware====
* firmware modulo voltaje y resistencia listo
* a FUA agregar un browse para poder grabar un .hex propio
* agregar consultar versión y la id de placa
* pasaje a serial jorge
* discusión sobre versionado de firmware y hardware
* gonchi propone agregar resistencia para versionado de placa
* versionado del firmware
* john va a revisar codigo, hotplug en motores
* git migrar pnp a master, ya estaría pronto
* hackpoint (andres)

====gestión====
* Diego Antel propone: taller utu-antel en la teja segunda quincena enero (john y jorge)
* antel pide un butia mas (hay que discutir esto)
* Daniel plantea tirar lineas a ute (manejando como se manejó con ANTel)
* comisión conseguir openmoko (gonchi jorge)
* openmoko??????? es probable dijo pablo sigue en camino.
* Chino va a compartir la documentación para antel. (NO METER MANO SIN CONSULTARLO A ÉL)
* Pedido por parte de edgardo, chino y enrique para cambiar la reunión
* Se propone reunion los LUNES 18:30

== 11/10/2012 ==

====Participantes====
Rodrigo, John, Edgardo, Enrique, Gonzalo.

====Minuta====
* Acta de la reunión realizada el 11/10/2012
* Motores reciclados
* firmware: actualizador y mejoras
* devolución de robots

====hardware====
* Andrés opina que los servos no cumplen con lo propuesto por el proyecto butiá 2.0 ya que no se pueden reciclar.
* Gonzalo opina que los motores stepper no son aptos.
* Se decidió comenzar a investigar motores de corriente continua y servos que se consigan en uruguay.
* Rodri va a averiguar el costo de servos con gran torque en el mercado local y de corriente continua en casas del estilo repuestos de auto. Incluso se puede ver si la reducción de alguno de los respuestos de auto no es de utilidad.
* Luego se hará una prueba con motores del tipo stepper para mantener una alternativa de reciclado que es abundante en Uruguay.
* Por otro lado se priorizó la construcción de los módulos para leer voltaje y resistencia. Esto sería una alternativa a lo que la XO trae para leer del puerto de audio, pero independiente de la computadora. Tanto Guzmán como Enrique hoy día están haciendo muchos sensores interesantes que pueden prototiparse rápido de esta manera, además de dar continuidad al proyecto Física con XO. La idea es comenzar con una primer versión para tener algo para pasarle a Guzmán lo antes posible. La idea es que a futuro incluya protección pero si los tiempos no dan realizar la primer versión simple sin protección que de hecho es lo que tiene la XO hoy día.

====firmware/software====
* aplicación cambiar el id, cambiar id de los motores (rodrigo)
* aplicación FUA (inc hex) rompemos compatibilidad para la v1
* hotplug en motores
* hackpoint módulo firmware
* pasaje a dispositivo serial (toribio compatibilidad) por defecto esta activado el control de energía de la XO definir versionado de firmware

====mecánica:====
* fichas, metodos conexión, eles, rivetes, compatibilidad con mecano, mejorar la compatiblidad con lego compatibilidad con otras computadoras? Compatibilidad lego ser menos dependiente de las cruces dejar solo agujeros con separación lego y más grandes. De 4.6 mm a 5mm explorar motores continua y servo (enrique servo + edgardo) comisión de encastre (pablo, rodrigo)y sin espacio para la mano baranda cuadrada con agujeritos computadora sobre la baranda pinza: 1 o 2 motores, ver si no es muy complicado usar 1 motor.
* Git migrar pnp a master

====gestión:====
* a fin de año tiene que devolver el robot (prestamo por un año)
* Se definió la comisión de motores: Rodrigo, John, Edgardo y Enrique

Discusiones para las reuniones

2013-02-28T22:30:52Z

Rsisto: Página blanqueada

Actas Reuniones Butia

2013-02-28T22:23:34Z

Rsisto: /* 14/02/2013 */

== 28/02/2013 ==

====Mecánica====
* Barandas al revés: no se cambia, el usuario debería redefinir el adelante del robot.

====Firmware y Hardware====

* puente h, llegaron unos micros que se pueden utilizar
** Se discuten alternativas:
** 1-implementar control de motores utilizando hack-points como primera alternativa - aylen empieza el desarrollo del firmware.
** Se va a diseñar un conector estandar para conectar los hack-points al módulo motores. Se discuten alternativas de como usar los pines:
*** a- Utilizar 2 pines por motor, utilizando transistores para puentear los estados del L293d
*** b- utilizar 3 pines por motor, evitando más componentes eléctricos, sacrificando hack-point
** 2-implementar protocolo ax-12 con un pic independiente (John estaba trabajando con esto), luego de la versión 2.0.

== 14/02/2013 ==

====Firmware y Hardware====

* se hicieron pruebas con el sensor de distancia a partir de un comportamiento extraño que encontró daniel. Lo raro es que el sensor no se comporta como debería para diferentes distancias da el mismo valor de voltaje. El resultado es que se aprovecha la mitad del rango del sensor en lugar de poder aprovechar todo. Probamos si era un tema de voltaje y alimentando con una fuente externa mediante un hub sigue dando el problema. Probamos conectarlo directamente a una fuente de corriente y medir con tester y funciona correctamente al parecer es un problema de ruido.

* Mejorar la serigrafía de los sensores especificando el pinout de los sensores de distancia al conectarse al PCB.

* Agregar logo butiá a los sensores.

====Software====

* Vamos a agregar a turtlebots que se deahabilite el control automático de energía para que no se suspenda el USB, tenemos lo que nos mandaron de la lista de sugar-dev. Hay que estudiar porque parece que el turtlebot ya trae un código para esto pero esta fallando, en el log se ven unos errores al intentarlo en la clase activity.

====Otros====
* Se resolvió poner en la wiki mejor documentación en la parte de construcción, en particular falta poner el conector rj45 y especificar su pinout
* El sábado 23 es el primer taller del año en colón.

== 7/02/2013 ==

====Participantes====
Alan, Pablo, Andres, John, Faivel, Humberto, Guille, Enrique, Javier, Rafael, Nicolás, Edgardo, Mario, Lucio

====minutas====
Empieza reunión a las 18:50

====Mecánica====
* Se está preparando versión de acrílicos final de Butiá SAM.

====Software====
* Bloque nuevo de casteo para adaptar el valor del sensor a un rango conocido, y los bloques de usurio a bloques conocido. En paleta extra, agrega un bloque nuevo.
** Problema: que pasa cuando se levanta devuelta el archivo, despues de reiniciar el programa? Hay que probar
* Bloque módulo user 1,2,3
* Bloque python de tortuga no funciona, no almacena el código, si no referencia al archivo. Corregir (Walter?)

====Firmware y Hardware====
* Es complicado agregar un nuevo módulo de firmware, por más que sea parecido a los anteriores.
** Agregar módulo genérico, al instanciarlo por sw, pasarle parametro el rango de identificación. (Descartado por la siguiente opción)
** Agregar módulos de usuario en fw, que sean genéricos, permitiendo así compartir el sensor con otras placas. Mantiene estructura actual de firmware. Cuando se instancia se define si es digital o análogo. Se genera un alias al instanciar en código. Tiene metodo getValue y setValue.
* Puente H, se le va a poner un micro, se está trabajando
** Generar entrada en wiki para discutir como conectar motores (placa con cantidad variable de motores, 2 motores, etc)
** El h-bridge diseñado va a permitir conectar a los hack-points o al puerto.
** Módulo usando un pin de los puertos y 2 hack-points
** Módulo utilizando un puerto con 2 pines de datos.
* Implementar módulo de PWM

== 31/01/2013 ==

====Participantes====
Alan, Pablo, Andres, John, Faivel, Humberto, Guille, Enrique, Javier

====minutas====
Empieza reunión a las 18:09

====Mecánica====
*Se realizo la prueba de colocar la rueda en el eje del motor con un prisionero directo a la rueda y dio muy buen resultado. De momento parece ser la mejor idea y queda muy prolijo.
*Se le agrego los agujeros para trasladar la placa chica de acrílico para dejar espacio para los motores de continua
*Se le agrega una ficha butia para ensamblar los motores al butia
*Parece que con esa modificación el puerto USB de la placa queda muy cerca de la rueda loca y queda tocando con el cable USB.
** Se discutio si se rota 180 la placa USB4butia quedando el USB hacia la otra direccion y los 4 conectores para sensores hacia la rueda, igual va a tocar con la rueda pero los cables de los sensores son mas flexibles y el conector no sobresale tanto o también lo de rotar todo el modulo que contiene placa, pilas y chasis chico de acrilico 180 o Intercambiar la placa con las pilas. Se decidio intercambiar la placa con las pilas.
*Se discutió sobre simetrizar los agujeros para amurar de la placa, pero se decidió que no porque pierde compatibilidad con los butias anteriores
* Se probo colocarle una rueda con el sistema del prisionero al motor de DX, el sistema de la ficha no es compatible con este pues tienen diametros distintos, se quiere llegar a una ficha mas universal por lo que se discutieron varias ideas sobre eso, quedamos en que se va a seguir investigando.
*Se dise;o el topecito para la parte de enfre con el logo de butia

====Firmware y Hardware====
*Se siguieron plantenado ideas sobre la USB4butia avanzada y lo de usar otro micro. Se va a seguir investigando
*Se planteo un idea de usar un circuito analogico con 3 estados para conectar los motores directamente a los puertos de la USB4butia

== 24/01/2013 ==

====Participantes====
Alan, Rodrigo, Pablo, Jorge, Andres, Daniel, John, Rafael, Aylen, Fiorella, Faivel, Guille, Humberto

====minutas====
Empieza reunión a las 18:26

====Mecánica====
*Se trajeron las piezas de formacril, se probaron las dos alternativas de barandas y se discutio. Se decidio que la mejor alternativa de barandas cortas con topes es mejor, pues muestra mas robustez frente a la de baranda larga y el laptop queda mas estable.
** El tope serian dos piezas universales butia, (No esta bueno que estas piezas sean de tope)
** Se decidio que el largo ideal de los tornillos para las piezas es de 4 x 0.7 de 20 mm.
*Motores: Se hizo una prueba con un prisionero y dio muy buen resultado.
*colocar el prisionero en la rueda directamente?

====Firmware====
*Seguir investigando sobre los micros buscar uno micro que sea Economico, Mercado Local, Chico y se pueda hacer PWM.
*Replantearse la idea de implementar serial por sofware y la de pwm.

====Hardware====
*Se resolvió quitar el Cristal de 32.768 que libera dos pines en la placa de los cuales uno es el PWM que se buscaba obtener
*El botón de bootloader permanece en la placa
*Colocar 2 puertos en la USB4butia compatibles con el el conector de los servos para los PWM.
*USB4butia simple y utilizar los hackpoints para controlar opción estable.
*Se hablo de hacer una placa usb4butia avanzada en dos capas y se planteo la interrogante de que es mejor: Si hacer la placa usb4butia doble capa avanzada con mas pines de datos y quizás con potencia, o mantenes la usb4butia con una capa agragando un modulo motor con otro microcontrolador.
*Crear una whish lista sobre la USB4butia

== 17/01/2013 ==

====Participantes====
Alan, Rodrigo, Pablo, Jorge, Andres, Daniel, John, Rafael

====minutas====
Empieza reunion a las 18:26

====Mecánica====
* se habló del módulo motor y la elección del pic, parece que utilizar
el micro con menos prestaciones es la opción más adecuada.
* como colocar los motores de CC : correa/directo
** se decidió que ya que tenemos motores con un buen par, no tiene
mucho sentido tener una correa.
** Surge el tema de donde colocar los motores para que siga siendo
ax12 y CC compatible, una opción para no cambiar las distribuciones
actuales es colocar los motores de CC atrás y permitir cambiar de
lugar la rueda loca para el lado opuesto al que está ahora. Hay que
tener ojo de que no obstaculice la conexión de puertos actual lo cual
es el problema que tiene ahora.
** Otro tema es como amurar la rueda a los motores, el motor que
compramos es de eje cilíndirco, hay otros con un perfil lo cual
permite que se pueda diseñar una rueda con un prisionero. Otra opción
es perforar el eje del motor y ponerle una espina para amurar la
rueda.

====Hardware====
*resolver que hacer con PWM: hackpoints, puertos
** PWM, mantener por hackpoint y generar módulo de firmware para PWM
por software utilizando Timer1 (inteligente, interrumpir solo cuando
es necesario).
** Generar informe con opciones de mantener o quitar botón de programación
* Módulo GPIO: no es equivalente al resistencia? Aporta algo?
** Evaluar quitar módulo port (porque no aporta nada)
** Evaluar agregar módulo de GPIO, permite por lo menos avisar al
usuario que está realizando una acción que puede dañar el equipo.
* Gadgets de sensore en DX, que hacer, definir ids o usar módulo
lector de voltaje, en general utilizar el de voltaje
** Crear módulos de temperatura y magnético, para laboratorios de física.
* chequear si el sensor de campo mag es analogico o digi

== 10/01/2013 ==

====Participantes====
Guillermo, Alan, , Fiorella, Pablo, Jorge, Andres, Faviel, John

====minutas====
Empieza reunion a las 18:26

====Documentación====
*Sensores de resistencia y voltage (John y Guille)
*Sensor de flexión ya esta documentado por Enrique

====Mecánica====
*Se estan haciendo los acrílicos en formacril, fecha aproximada 24
*Módulo motor hecho con carcasa de linterna utilizando una ficha butia, carcasa de un enchufe, arrancador de tubo y zunchos.
**Se discutio sobre utilizarlo con una correa o adicionarle una rueda, se decidio adicionarle la rueda y colocar el modulo en el lugar actual de las ruedas, manteniendo la estructura de los AX12, incorporándolo al butia por fuera. (Butia PUNK)
*Se habló de hacer un banco de prueba de motores para obtener datos útiles como el par, rpm , etc ...
*Se probaron los tornillos de plástico y dan buen resultado ya que protege el acrílico, son mas fácil de enroscar, mas amigables para los niños

====Hardware====
*Se discutió sobre los cambios de la USB4butia, estudiar lo de hacer una USB4butia solo para controlar motores y evaluar Modulito con microcontrolador propio para manejar motores, PIC16F628A buscar compilador GNU, buscar otro PIC de 8 patas
*Evaluar de quitar el clock de 37 khz y utilizar el pin 16 que es el CCP2 y asi evitar de quitar el boton de programacion
*Se hablo sobre sacar el boton de programacion, se decidio quitarlo y cambiar el bootloader y agregar dos puertos pwm (Si es necesario)
*Se discutió lo de quitar el bus AX12, se decidió que no porque permite agregar motores con control más complejo de forma fácil.
*Sacar los pines de programación ... ?

====Software====
*Serial por software (si se va hacer el modulo motor con pic propio)

== 03/01/2013 ==
====Participantes====
Rafa, Pablo, Pancho, Jorge, John

====Mecánica====
*Se dibujaron barandas nuevas con el tope , y se hicieron prototipos en goma eva para presentar en el butiá. Se presentó junto a la magallanes. Se discutió y se decidió hacer las barandas un poco más altas. Diseñar y construir 2 juegos de barandas: unas más largas con tope flotando y otras más cortas sin tope.
*Se mostró la nueva rueda butiá con agujero en el medio
*Se habló del modulo motor se agregan dos piezas de acrílico para mantener la estructura de los AX12 y no tener que hacer un butia distinto para la versión con otros motores. Hay dos opciones, una posee lengüetas como los AX12 y van en el mismo lugar con las ranuras existentes para los AX12 y la otra serían las fichas universales con el sistema de encastre butia.
*Estudiar agujeros para "ensanguchar" las dos planchas de acrílicos, agregar un tornillo más alineado con los que ya están con la medida de los AX12
*Se acomodó la ojiva del encastre butiá centrándola para que quede un poquito mas separdo de los rectángulos
*Se le agrega al logo la palabra SAM
*Ejemplo de logos para autoadhesivos
*Se van hacer arcilicos y autoadhesivos.
*Se va a probar el logo calado otra vez

== 27/12/2012 ==

====Participantes====
Daniel, Guillermo, Alan John, Fiorella, Aylen, Rodrigo, Enrique, Rafael, Pablo

====minutas====
* Empieza reunion a las 18:41

====Hardware====
* Acrílico había quedado mal grabado el logo la última vez, quedó una línea entrecortada.
** Se va a pedir devuelta con los logos bien grabados. Pablo trae planos el 3 de enero. Al pedir los nuevos acrílicos preguntar opciones de:
*** Pintar logos luego de grabarlos
*** Mejorar calidad del grabado para que no queden manchados.
*** Incrementar ancho de línea para que queden mejor marcados los logos.
** Pablo va a mandar a hacer pegotines calados de logos para manejar otra alternativa
** Se discute si poner nombre 2.0 o "sam". Mayoría eligió Sam (2 en charrúa)

====Motores====
* Se vio prototipo con motores de cargadores USB a dínamo, utilizando hack points.

====Software====
* Salió paquete de TortuBots v18, faltan paquetes Debian actualizar changelog (Aylen)
* Alan corrigió bug de memory leak de TortuBots, ahora no se bloquea en la XO. Está probado.
* PyBot (librería python para acceder a placa butiá) está casi listo, falta testear.
* Validación al tratar de grabar o escribir en hackpoint configurado para entrada o salida respectivamente. Hacerlo en api y agregarlo a TortuBots cuando trata de hacer una operación incorrecta. (Alan)

====Firmware====
* Módulo de Firmware de hackpoint no tiene que cambiar el modo del pin (Aylen)

== 10/12/2012 ==
====Participantes====

John, Aylen, Pablo, Gonzalo, Guillermo, Andrés, Diego, Rafael, Luis, Rodrigo, Marcelo

====minutas====
* Empieza reunion a las 19:50

====Hardware====
* Falta documentar prototipo con motores de linternas (Pancho)
* Piezas para anexar sensores: Pablo muestra 3 piezas, genérica de 2 lados, de 1 lado y una cortita.
** También se hizo pieza para reemplazar motores AX12.
** Se llega a un acuerdo de como tienen que ser las placas de sensores
* Se decide cambiar las piezas por piezas únicas para armado y reemplazo de AX12.
* Barandas, se van a cambiar por unas que empiezan finitas en la parte frontal y terminan gruesas en la parte trasera como guardabarros. En la parte delantera, tienen tope para aguantar una laptop.

====Motores====
* Motores "argentinos" no tienen certificado de origen (motor chino, engranajes argentinos)
* Guille va a mandar un mail a Fede para que averigüe en Brasil por alternativas de motores CC.
* Rodrigo, Gonzalo, van a armar prototipo con motores de cargadores USB a dínamo.

== 3/12/2012 ==
====Participantes====

John, Aylen, Pablo, Gonzalo, Guillermo, Francisco, Andrés, Daniel, Rafael, Alan, Luis

====minutas====
* Empieza reunion a las 19:30

====Hardware====
* Hay que definir los componentes para construir una serie de robots, de la mano de Antel (esperando h-bridge)
** Definir que motores de CC usar, de AP&S, modelo SP6-50, similar a AX12 ($80 argentinos), faltan definir los de Ignis (MR83-100, con pocas revoluciones y poco par), Pablo trae 2 de cada uno para probar.
* Ida a Triex sugerida por Daniel. Hay varios interesados, coordinar por mail.
* John, Andrés, definiendo USB4Motores, placa USB4All genérica, con H-bridge integrado.

====Motores====
* Motor de linterna recargable, funciona bien, Gonzalo va a comprar lintenrnas para armar un Butiá.
* Documentación de alternativas de motores: Daniel, Pablo y Francisco (documentar motores descartados - Daniel, motores de linternas recargables, Soportes Discos duros y contra chata. Motores a usar) Rafa va a mandar link de como crear usuario y stub de documento.
* Edgardo está armando el H-Bridge para controlar motores (Edgardo está armando)
* Se vieron acrílicos con logo

====firmware====
* Se solucionó problema en firmware (se estaba usando memoria inexistente)
* Andrés, Aylen, John: Trabajando en Módulo PWM por software en firmware.
* John - Falta módulo GPIO

====Sensores====
* Guille, John - Documentar en wiki como crear sensores nuevos.
* Gonzalo, mirando como funciona sensor de color.

====Software====
* Alan está escribiendo API en Python para Butia, falta contemplar varias placas USB
* Firmware update activity , está pronta la actividad 90%
* Andrés - Actualizar butialo a 2.0 (no dio el tiempo)

====Organización====
* Andrés comenta sugerencias del sumo.uy
** Agregar agujeros para tornillos
** Quejas de sensor de distancia, no se puede enganchar
** Robot Butiá triangular - Omni

== 26/11/2012 ==
====Participantes====
Luis, Marcelo, Guillermo R., Pablo Margenat, Gonzalo, Rafael Sisto, Andrés Aguirre, Aylen, Enrique, Diego, Martín , John, Javier, Alan, Fiorella

====minutas====
* Empieza reunion a las 19:30

====Hardware====
* Hay que definir los componentes para construir una serie de robots
** Definir que motores de CC usar (Quién va a definir esto?)
* Ida a Triex sugerida por Daniel. Hay varios interesados, coordinar por mail.

====Motores====
* Comisión continua Falta probar con mosfets (esperando módulo PWM de firmware)
** Cambiar circuito de muestra buscando mosfets de menor amperaje (Diego)
* Soportes de motores
** Acrílico (prontos para el 29/11), demo para 3/12
** Pancho y Pablo: cortando chasis de disco, pensando alternativas.
** Transmisión, se propone probar goma en el motor y goma en la rueda, en vez de una correa.
* Alternativas de motores:
** Linternas con generadores, se pueden usar como motores (menos de $200 en supermercados), hay que escribir en la wiki
** Andrés, Enrique - Consultar a Eneka por motores de continua hechos en Argentina (cerca de $700), modelo MR4-100, ver si tiene suficiente torque.

====firmware====
* Andrés, Aylen: Módulo PWM por software en firmware.
** (Andrés, Micho) Falta solucionar bug extraño cuando hay muchos módulos (posiblemente una asignación errónea de memoria), probar con Ida.
* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.(Se puede hacer)
** Faltan módulos GPIO y LED (Prontos, falta corregir bug).
* Pendiente Andrés - Liberar motores cuando se le mande orden velocidad cero.

====Sensores====

* Fibra óptica, se puede conseguir en Tilsit (6 metros con terminales, aprox U$ 35). Daniel va conseguir una nueva muestra actual para probar.
** Se consigue en el Clon por $65 una lámpara decorativa
** Luego de tener fibra, segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Sensores de efecto Hall (No se trató )
** Propuesta de Diego: sensor de imanes utilizando una bobina y con pin analógico.(No se trató )

====Software====

* Alan: bloque para configurar hack points, pronto, falta configurar como entrada.
* Bloque LED está.
* Alan, falta bloque GPIO
* Alan está escribiendo API en Python para Butia (falta testear, branch pybot)
* Guille, haciendo paquete Debian (armado makefile estilo GNU)
* Rodrigo, el tortuga tiene un uso excesivo de CPU (hay que ver si es nuestro o de walter) cuando se usan muchos bloques. Reproducir problema. (No se habló)
* Firmware update activity , está pronta la actividad 90%
* Andrés - Actualizar butialo a 2.0

== 19/11/2012 ==
====Participantes====
Guillermo R., Pablo Margenat, Rafael Sisto, Andrés Aguirre, Alan Aguiar , Rodrigo, Aylen, Gonzalo, Enrique, Diego

====minutas====
* Empieza reunion a las 19:30

====Motores====

* Comisión continua Falta probar con mosfets (esperando módulo PWM de firmware)
** Cambiar circuito de muestra buscando mosfets de menor amperaje (Diego)
* Soportes de motores
** Se hizo modelo, está pedido el acrílico (prontos para el 29/11), demo para 3/12
** Pancho y Pablo: cortando chasis de disco
* Buscar alternativas de motores:
** lectoras de CD, disketeras, discos duros (Diego está consiguiendo con Integra)
** Andrés está consultando en Eneka por motores de continua hechos en Argentina (cerca de $700), serían similares a los secadores de pelo, pero con reducción.
* Comision PaP - Se sigue trabajando para un prototipo, se propone controlar con circuito casero.

====firmware====

* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.
* Andrés - Liberar motores cuando se le mande orden velocidad cero.
* Andrés, Aylen: Módulo PWM por software en firmware.
* Andrés: Notificar placa como dispositivo serial al PC (avanzando).

====Sensores====

* Fibra óptica, se puede conseguir en Tilsit (6 metros con terminales, aprox U$ 35). Daniel va conseguir una nueva muestra actual para probar.
* Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Sensores de efecto Hall
** Propuesta de Diego: sensor de imanes utilizando una bobina y con pin analógico.

====Software====
* Alan: bloque para configurar hack points.
* Tortubots, tema pendiente: Generar un evento a los plugins cuando finalice la ejecución de los bloques (por ejemplo, para liberar cámara, parar motores, etc).
* Migración TurtleBlocks a android, falta librería GTK, trancado por ese tema
* Alan está escribiendo un API en python con funcionalidad similar a bobot (ventaja: no requiere lua ni dependencias de binarios adicionales, para arm no requeriría link a binarios extra, no requiere comunicación por sockets.)
* normalizar velocidades de 0 a 100. Se descarta porque no hay un problema concreto en que pueda beneficiar. En principio sirve para buscar la curiosidad de los alumnos.
* Separar paleta, ya está.
* Guille, haciendo paquete Debian.
* Rodrigo, el tortuga tiene un uso excesivo de CPU (hay que ver si es nuestro o de walter) cuando se usan muchos bloques. Reproducir problema.
* Guille, Aylen: Firmware update activity
** Actividad con un botón para actualizar (Rodrigo)

====Documentación====
* Rafael: Revisar documentación de entregables a Antel

====Resumen de Comisiones====
Soportes de motores: Pablo y Francisco

motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 12/11/2012 ==
====Participantes====
Guillermo Reisch, Diego, Daniel, John Pereira, Pablo Margenat, Rafael Sisto, Francisco Puignau, Andrés Aguirre, Martín Giachino, Alan Aguiar

====minutas====
* Empieza reunion a las 19:30

====Motores====
* Comisión continua - trajo demo con motores distintos y quedó bien el seguidoor de líneas.
** Falta probar con mosfets
* Soportes de motores
** Falta soporte para gomitas, propuesta de hacer 2 ruedas de acrílico más chicas para sostener.
** Falta soporte para rueda,
*** Proponen utilizar el mismo plato del soporte de gomitas, eje con rulemanes
*** Otra alternativa, usar motor de disco duro como rulemán (módulo independiente). (Guillermo va a traer discos duros para desarmar)
** Buscar alternativas de motores: secador de pelo (12v), lectoras de CD, disketeras
* Comision PaP - utilizar motor de impresora con driver. (para lunes 19/11)

====firmware====

* módulo firmware para bus pines digitales pronto, PWM se va a manejar por software
* firmware para sensor de voltaje pronto
* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.
* Andrés, Aylen: Módulo PWM por software en firmware.
* Andrés: Notificar placa como dispositivo serial al PC.

====Sensores====

* Demo de Módulo voltaje y resistencia
** Algunos detalles por corregir
* Fibra óptica, Daniel va a conseguir una muestra para el lunes siguiente
* (no se habló) Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises

====Software====

* Se creó bloque de sensor de voltaje
* Separar paleta, normalizar velocidades de 0 a 100 (Alan)
* Alan, el tortuga tiene un memory Leak (hay que ver si es nuestro o de walter) cuando se usan muchos bloques
* Alan, quitar compatibilidad para V1
* Guille, Aylen: Firmware update activity - postergado para próxima reunión.

====Resumen de Comisiones====
Soportes de motores: Pablo y Francisco

motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 05/11/2012 ==
====Participantes====
Gonzalo Tejera, Guillermo Reisch, Enrique Madruga, Daniel Cancela, John Pereira, Pablo Margenat, Rafael Sisto.

====minutas====
* Empieza reunion a las 19:30
* resumen, software/hardware/mecanica etc...

====Motores====
* Enrique averiguó motores alza-cristales: son caros (cerca de los $ 1000)
* Daniel mandó mail a SEMPRE, va a relevar que tipo de motores (otra chatarra) se pueden conseguir
* Comisión continua - va a avanzar con el módulo de relés
* Comisión continua - motores de secador de pelo (12v), lectoras de CD, disketeras
* Comisión continua - Preguntar a "Lechuga" qué motores usaron
* Comision PaP - utilizar motor de impresora con driver. (para lunes 19/11)
* Reducciones - 2 alternativas, correas o engranajes impresos.

====firmware====

* Aylen, agregar módulo firmware para bus pines digitales y PWM (pin 17). Si puede estar para esta semana, mejor.
* John - Otra alternativa para manejar motores, utilizar el puerto ax12 y un pic conversor a otro tipo de motores.
* Aylen - falta firmware para sensor de voltaje (estaría pronto)

====Sensores====
* sensor distancia auto chino - Enrique consultó en comercio electrónico y superan los $1000, seguir consultando alternativas.
* Fibra óptica, intentar utilizar fibra óptica de cotillón (adornos de colores)
** Daniel para el lunes se comprometió en traer un par de tramos (quizás se consigue en SEMPRE)
** Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Módulo voltaje y resistencia (demo lunes 12)
** Se decidió utilizar jumper en vez de switch
** Se creó módulo en kicad
* Firmware update activity (trabajando...)

====Software====
* Alan, crear bloque de sensor de voltaje
* Alan, hablar con Andrés y Rodrigo - El tortuga tiene un memory Leak (hay que ver si es nuestro o de walter) cuando se usan muchos bloques

====Hardware====
* Chata va a comenzar a llevar logo de Antel

====Gestión====
* Intentar convertir las reuniones en talleres

====Resumen de Comisiones====
motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 29/10/2012 ==

====Participantes====
margenat, sisto, andrew, madruga, chino, john, santiago, gonchi, pancho, aylen, rodrigo

====Minutas====
* hora de comienzo: 19:25 (19:00)
* motores...
*

====motores====
* Otra discusión sobre PaP. Andrés se va a encargar de los motores PaP.
* Motores de alza-cristales/limpia-vidrios parece una buena idea. Se consiguen en plaza, son reciclables, tienen la reducción.
* Pablo propone pieza para mantener la estructura del AX-12 y mantener la estética

====hardware====
* ver los pines que están sin utilizar.
* averiguar sensor distancia auto chino
* sensor enrique de fibra óptica para el butiá, sensor antena

==== mecánica ====
* pablo mostró la nueva chata butiá.

==== gestión ====
* se agrega a gonchi a comisión motores de continua.

== 18/10/2012 ==

====Participantes====
Gonzalo, Jorge, Luis, Martin(Chino), Aylen, John, Rodrigo, Diego (Antel), Guille, Daniel Cancela(montacargas) y Pablo(Estudiante nuevo)

====Minuta====
* Reunión del día 18/10/2012
* Hora de comienzo: 14.50
* Asisten: Gonzalo, Jorge, Luis, Martin(Chino), Aylen, John, Rodrigo, Diego (Antel), Guille, Daniel Cancela(montacargas) y Pablo(Estudiante nuevo)
* Presentación del proyecto a la gente nueva
* Motores
* Modulo voltaje,
* Fin reunión 17.15

====motores====
* discusión por motores nuevamente
* Comisión motores no hizo mucho. Se presentó precio de servos 28u$s de 15kg, 16u$s de 6,8kg. Se va a seguir averiguando en otros lados.
* NO steppers (daniel va a averiguar algo sobre steppers)
* Hay que conseguir los motores de destornillador.

====hardware====
* modulo voltaje y resistencia (guille, egardo, enrique)
* bornera o jack? (jack hace corto,[los jack machos truchos, los buenos NO HACEN CORTO {Guille}])
* protección? volver al diodo que no pusimos
* egardo y guille hoy van a encargarse del hardware
* conseguir conectores bosch mas chicos o cables mejores (guille) llevar el cable de ax12 original

====software====
* activity cambiar id (rodrigo)
* ayle john chino van a agregar funcionalidades al modulo ax12 para actividad de id
* (chequear wiki de mtbutia que estan haciendo algo parecido)
* Tortuga con varios hilos (elemichele, alan el hombre tortuga, andres) quiere hacer un tortuga con varios hilos

====firmware====
* firmware modulo voltaje y resistencia listo
* a FUA agregar un browse para poder grabar un .hex propio
* agregar consultar versión y la id de placa
* pasaje a serial jorge
* discusión sobre versionado de firmware y hardware
* gonchi propone agregar resistencia para versionado de placa
* versionado del firmware
* john va a revisar codigo, hotplug en motores
* git migrar pnp a master, ya estaría pronto
* hackpoint (andres)

====gestión====
* Diego Antel propone: taller utu-antel en la teja segunda quincena enero (john y jorge)
* antel pide un butia mas (hay que discutir esto)
* Daniel plantea tirar lineas a ute (manejando como se manejó con ANTel)
* comisión conseguir openmoko (gonchi jorge)
* openmoko??????? es probable dijo pablo sigue en camino.
* Chino va a compartir la documentación para antel. (NO METER MANO SIN CONSULTARLO A ÉL)
* Pedido por parte de edgardo, chino y enrique para cambiar la reunión
* Se propone reunion los LUNES 18:30

== 11/10/2012 ==

====Participantes====
Rodrigo, John, Edgardo, Enrique, Gonzalo.

====Minuta====
* Acta de la reunión realizada el 11/10/2012
* Motores reciclados
* firmware: actualizador y mejoras
* devolución de robots

====hardware====
* Andrés opina que los servos no cumplen con lo propuesto por el proyecto butiá 2.0 ya que no se pueden reciclar.
* Gonzalo opina que los motores stepper no son aptos.
* Se decidió comenzar a investigar motores de corriente continua y servos que se consigan en uruguay.
* Rodri va a averiguar el costo de servos con gran torque en el mercado local y de corriente continua en casas del estilo repuestos de auto. Incluso se puede ver si la reducción de alguno de los respuestos de auto no es de utilidad.
* Luego se hará una prueba con motores del tipo stepper para mantener una alternativa de reciclado que es abundante en Uruguay.
* Por otro lado se priorizó la construcción de los módulos para leer voltaje y resistencia. Esto sería una alternativa a lo que la XO trae para leer del puerto de audio, pero independiente de la computadora. Tanto Guzmán como Enrique hoy día están haciendo muchos sensores interesantes que pueden prototiparse rápido de esta manera, además de dar continuidad al proyecto Física con XO. La idea es comenzar con una primer versión para tener algo para pasarle a Guzmán lo antes posible. La idea es que a futuro incluya protección pero si los tiempos no dan realizar la primer versión simple sin protección que de hecho es lo que tiene la XO hoy día.

====firmware/software====
* aplicación cambiar el id, cambiar id de los motores (rodrigo)
* aplicación FUA (inc hex) rompemos compatibilidad para la v1
* hotplug en motores
* hackpoint módulo firmware
* pasaje a dispositivo serial (toribio compatibilidad) por defecto esta activado el control de energía de la XO definir versionado de firmware

====mecánica:====
* fichas, metodos conexión, eles, rivetes, compatibilidad con mecano, mejorar la compatiblidad con lego compatibilidad con otras computadoras? Compatibilidad lego ser menos dependiente de las cruces dejar solo agujeros con separación lego y más grandes. De 4.6 mm a 5mm explorar motores continua y servo (enrique servo + edgardo) comisión de encastre (pablo, rodrigo)y sin espacio para la mano baranda cuadrada con agujeritos computadora sobre la baranda pinza: 1 o 2 motores, ver si no es muy complicado usar 1 motor.
* Git migrar pnp a master

====gestión:====
* a fin de año tiene que devolver el robot (prestamo por un año)
* Se definió la comisión de motores: Rodrigo, John, Edgardo y Enrique

Sensores 2.0

2013-02-27T21:35:25Z

Rsisto:

* Tabla de Identificadores
* [[PCB módulo sensor|PCB módulo sensor]]
* [[ Módulo sensor LDR |Módulo sensor LDR]]
* [[ Módulo sensor Boton | Módulo sensor Boton]]
* [[ Módulo sensor Sharp | Módulo sensor Sharp]]
* [[ Módulo_sensor_Resistencia | Módulo sensor Resistencia]]

Mecánica Butiá V2.0

2013-02-26T23:16:43Z

Rsisto:

[[Archivo:ButiaV20.JPG | 900px | center]]

== Mejoras Butiá v2.0 ==

* [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Compatibilidad Compatibilidad con Lego].
* Sistema [http://es.wikipedia.org/wiki/Conexi%C3%B3n_en_caliente HotPlug].
* Compatibilidad con Lego y Mecano
* Nueva Barra de encastres.
* Estructura alternativa libre de AX12.
* Desarrollado 100% en Facultad de Ingenieria.
* Componentes disponibles en Uruguay.

== Materiales para la nueva versión de Butiá v2.0 ==

Lista de elementos necesarios para la construcción:
* 1 Placa [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Usb4butia USB4Butiá v2.0].
* 2 [[Motores | Motores compatibles]].
* 1 [[Sensores_2.0 | Sensores v2.0]].
* 1 [[Pack de baterías]].
* 1 Rueda loca.
* 1 Chasis.
* 1 Chata.
* 2 Barandas.
* 2 Rueda Interior.
* 4 Rueda Exterior.
* Bloques y Placas.
* 1 Llave de encendido.
* Tornillos, tuercas y arandelas.
* [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Construcci%C3%B3n_Buti%C3%A1_V1.8#Cables_RJ45 Cables RJ45 para sensores].
* Varios Cables para motores y alimentación.
* 1 Cable USB A-B (usados comunmente para conectar impresoras a PC).

 

== Chata Butiá ==
 
<gallery>
File:Placa.png|Placa principal
File:Chasis.png|Chasis
File:Baranda_corta.png|Baranda
</gallery>
 
 
El archivo .zip contiene los planos para el acrilico de la chata. (En formato .cdr, .svg y .pdf)
 
[http://www.fing.edu.uy/inco/proyectos/butia/files/ChataButia20.zip Chata Butiá]
 
 

== Soportes y Rueda Butiá ==
 
<gallery>
File:Soportes.png|Soportes para sensores, motores, etc.
File:Rueda.png|Rueda
</gallery>
 
El archivo .zip contiene los planos para las ruedas, los bloques y la placa de la chata. (En formato .cdr, .svg y .pdf)
 
[http://www.fing.edu.uy/inco/proyectos/butia/files/RuedaBloquePlaca20.zip Ruedas, bloques y placa] 
 

== Barra de Encastre Butiá ==

Luego de recorrer distintos diseños de encastre que buscaban la funcionalidad en la instalación de sensores y compatibilidad con otros kits llegamos a una barra de encastre que contempla todas las opciones que se nos presentaron hasta el momento y que es la barra de encastre Butiá.

[[Archivo:Barra_de_encastre_butia.png | 400px | center]]

En la figura podemos ver la la barra de encastre Butiá y las distintas compatibilidades que tiene.
La distancia entre el centro de la ojiva y los agujeros laterales es de 16mm donde se puede atornillar cualquier barra de lego, entre los extremos de la ojiva y los agujeros hay una distancias de 12,7mm que permite atornillar cualquier pieza de mecano y finalmente con el centro de la ojiva y los dos rectángulos a su lado se encastran las placas de sensores Butiá.

''Pieza lego agarrada al butia''
<gallery>
File:CompatibilidadLego1.JPG
File:CompatibilidadLego2.JPG
File:CompatibilidadLego3.JPG
File:CompatibilidadLego4.JPG
</gallery>

''Pieza mecano agarrada al butia''
<gallery>
File:CompatibilidadMeccano1.JPG
File:CompatibilidadMeccano2.JPG
</gallery>

''Foto de placa montada en butia''

Es importante que con esta barra de encastre el Butiá no pierde la posibilidad de añadirle elementos y asegurarlos con zunchos, collarines o tornillos de menos de 5mm de diámetro.

''Foto de escuadras de acrílico con sensor agarrado con collarines''

=== Placa de Sensores Butiá ===

La placa de sensores ya no solo es un soporte de sensores sino que puede ser parte de una estructura creada con más de una placa encastrada para distintos fines como por ejemplo; brazo, pinza, sensores alejados, sensores altos y bajos, etc. Esto es posible ya que la placa porta encastres Butiá hembra y macho en todos los sentidos.

''Foto de la placas sensor''

''Fotos de sensores montados en butia y alguna estructura''

También puede servir de estructura para montar el chasis a la placa sin necesidad de tener motores AX12. Esta ultima propiedad se busco con el fin de poder tener la estructura del Butiá sin depender de los motores AX12 y así poder montar cualquier motor de corriente continua de menor costo. El agujero central de 6mm en la placa montada como estructura permite que se use de soporte para el eje de la rueda.

=== Accesorios de montaje ===

Como accesorios de montaje se pueden encontrar en el Kit los encastres para placas en paralelo que permite colocar 2 placas de sensor en paralelo entre ellas o una placa de sensor en paralelo con la chata o el chasis.

''Foto del encastre para placas en paralelo''

''Foto de 2 placas encastradas en paralelo y placa con chasis''

Los tornillos son M4 de 20mm y cabeza hexagonal para que sea sencillo su montaje y sean compatibles para colocar placas de sensor en paralelo o perpendiculares. El material de los tornillos es Nylon que no provoca daños en el acrílico y se puede lograr un buen ajuste enroscando solo con la mano.

''Foto de los tornillos y de alguno colocado''

Es importante tener en cuenta que se pueden usar tornillos M4 de cabeza hexagonal de cualquier largo en acero o hierro o tornillos M4 con cualquier tipo de cabeza pero de 15mm de largo

''Foto de uso de tornillo cabeza hexagonal y cabeza philips''

=== Algunos ejemplos: ===

Ampliar en longitud.

''Foto de un ejemplo''

Ampliar en altura.

''Foto de un ejemplo''

Acercarse al piso.

''Foto de un ejemplo''

Poder hacer un Butiá de varias chatas de altura.

''Foto de un ejemplo''

Archivo:CompatibilidadMeccano2.JPG

2013-02-26T23:15:37Z

Rsisto:

Archivo:CompatibilidadMeccano1.JPG

2013-02-26T23:15:32Z

Rsisto:

Archivo:CompatibilidadLego4.JPG

2013-02-26T23:15:25Z

Rsisto:

Archivo:CompatibilidadLego3.JPG

2013-02-26T23:15:19Z

Rsisto:

Archivo:CompatibilidadLego2.JPG

2013-02-26T23:15:14Z

Rsisto:

Archivo:CompatibilidadLego1.JPG

2013-02-26T23:15:08Z

Rsisto:

Archivo:ButiaV20.JPG

2013-02-26T23:09:43Z

Rsisto:

Discusiones para las reuniones

2013-02-20T20:17:15Z

Rsisto: Página reemplazada por 'Hay que invertir los orificios de barandas (atrás es adelante)'

Hay que invertir los orificios de barandas (atrás es adelante)

Actas Reuniones Butia

2013-02-20T20:13:29Z

Rsisto: /* 7/02/2013 */

== 14/02/2013 ==

====Firmware y Hardware====

* se hicieron pruebas con el sensor de distancia a partir de un comportamiento extraño que encontró daniel. Lo raro es que el sensor no se comporta como debería para diferentes distancias da el mismo valor de voltaje. El resultado es que se aprovecha la mitad del rango del sensor en lugar de poder aprovechar todo. Probamos si era un tema de voltaje y alimentando con una fuente externa mediante un hub sigue dando el problema. Probamos conectarlo directamente a una fuente de corriente y medir con tester y funciona correctamente al parecer es un problema de ruido.

* Mejorar la serigrafía de los sensores especificando el pinout de los sensores de distancia al conectarse al PCB.

* Agregar logo butiá a los sensores.

====Software====

* Vamos a agregar a turtlebots que se deahabilite el control automático de energía para que no se suspenda el USB, tenemos lo que nos mandaron de la lista de sugar-dev. Hay que estudiar porque parece que el turtlebot ya trae un código para esto pero esta fallando, en el log se ven unos errores al intentarlo en la clase activity.

====Otros====
* Se resolvió poner en la wiki mejor documentación en la parte de construcción, en particular falta poner el conector rj45 y especificar su pinout
* El sábado 23 es el primer taller del año en colón.

== 7/02/2013 ==

====Participantes====
Alan, Pablo, Andres, John, Faivel, Humberto, Guille, Enrique, Javier, Rafael, Nicolás, Edgardo, Mario, Lucio

====minutas====
Empieza reunión a las 18:50

====Mecánica====
* Se está preparando versión de acrílicos final de Butiá SAM.

====Software====
* Bloque nuevo de casteo para adaptar el valor del sensor a un rango conocido, y los bloques de usurio a bloques conocido. En paleta extra, agrega un bloque nuevo.
** Problema: que pasa cuando se levanta devuelta el archivo, despues de reiniciar el programa? Hay que probar
* Bloque módulo user 1,2,3
* Bloque python de tortuga no funciona, no almacena el código, si no referencia al archivo. Corregir (Walter?)

====Firmware y Hardware====
* Es complicado agregar un nuevo módulo de firmware, por más que sea parecido a los anteriores.
** Agregar módulo genérico, al instanciarlo por sw, pasarle parametro el rango de identificación. (Descartado por la siguiente opción)
** Agregar módulos de usuario en fw, que sean genéricos, permitiendo así compartir el sensor con otras placas. Mantiene estructura actual de firmware. Cuando se instancia se define si es digital o análogo. Se genera un alias al instanciar en código. Tiene metodo getValue y setValue.
* Puente H, se le va a poner un micro, se está trabajando
** Generar entrada en wiki para discutir como conectar motores (placa con cantidad variable de motores, 2 motores, etc)
** El h-bridge diseñado va a permitir conectar a los hack-points o al puerto.
** Módulo usando un pin de los puertos y 2 hack-points
** Módulo utilizando un puerto con 2 pines de datos.
* Implementar módulo de PWM

== 31/01/2013 ==

====Participantes====
Alan, Pablo, Andres, John, Faivel, Humberto, Guille, Enrique, Javier

====minutas====
Empieza reunión a las 18:09

====Mecánica====
*Se realizo la prueba de colocar la rueda en el eje del motor con un prisionero directo a la rueda y dio muy buen resultado. De momento parece ser la mejor idea y queda muy prolijo.
*Se le agrego los agujeros para trasladar la placa chica de acrílico para dejar espacio para los motores de continua
*Se le agrega una ficha butia para ensamblar los motores al butia
*Parece que con esa modificación el puerto USB de la placa queda muy cerca de la rueda loca y queda tocando con el cable USB.
** Se discutio si se rota 180 la placa USB4butia quedando el USB hacia la otra direccion y los 4 conectores para sensores hacia la rueda, igual va a tocar con la rueda pero los cables de los sensores son mas flexibles y el conector no sobresale tanto o también lo de rotar todo el modulo que contiene placa, pilas y chasis chico de acrilico 180 o Intercambiar la placa con las pilas. Se decidio intercambiar la placa con las pilas.
*Se discutió sobre simetrizar los agujeros para amurar de la placa, pero se decidió que no porque pierde compatibilidad con los butias anteriores
* Se probo colocarle una rueda con el sistema del prisionero al motor de DX, el sistema de la ficha no es compatible con este pues tienen diametros distintos, se quiere llegar a una ficha mas universal por lo que se discutieron varias ideas sobre eso, quedamos en que se va a seguir investigando.
*Se dise;o el topecito para la parte de enfre con el logo de butia

====Firmware y Hardware====
*Se siguieron plantenado ideas sobre la USB4butia avanzada y lo de usar otro micro. Se va a seguir investigando
*Se planteo un idea de usar un circuito analogico con 3 estados para conectar los motores directamente a los puertos de la USB4butia

== 24/01/2013 ==

====Participantes====
Alan, Rodrigo, Pablo, Jorge, Andres, Daniel, John, Rafael, Aylen, Fiorella, Faivel, Guille, Humberto

====minutas====
Empieza reunión a las 18:26

====Mecánica====
*Se trajeron las piezas de formacril, se probaron las dos alternativas de barandas y se discutio. Se decidio que la mejor alternativa de barandas cortas con topes es mejor, pues muestra mas robustez frente a la de baranda larga y el laptop queda mas estable.
** El tope serian dos piezas universales butia, (No esta bueno que estas piezas sean de tope)
** Se decidio que el largo ideal de los tornillos para las piezas es de 4 x 0.7 de 20 mm.
*Motores: Se hizo una prueba con un prisionero y dio muy buen resultado.
*colocar el prisionero en la rueda directamente?

====Firmware====
*Seguir investigando sobre los micros buscar uno micro que sea Economico, Mercado Local, Chico y se pueda hacer PWM.
*Replantearse la idea de implementar serial por sofware y la de pwm.

====Hardware====
*Se resolvió quitar el Cristal de 32.768 que libera dos pines en la placa de los cuales uno es el PWM que se buscaba obtener
*El botón de bootloader permanece en la placa
*Colocar 2 puertos en la USB4butia compatibles con el el conector de los servos para los PWM.
*USB4butia simple y utilizar los hackpoints para controlar opción estable.
*Se hablo de hacer una placa usb4butia avanzada en dos capas y se planteo la interrogante de que es mejor: Si hacer la placa usb4butia doble capa avanzada con mas pines de datos y quizás con potencia, o mantenes la usb4butia con una capa agragando un modulo motor con otro microcontrolador.
*Crear una whish lista sobre la USB4butia

== 17/01/2013 ==

====Participantes====
Alan, Rodrigo, Pablo, Jorge, Andres, Daniel, John, Rafael

====minutas====
Empieza reunion a las 18:26

====Mecánica====
* se habló del módulo motor y la elección del pic, parece que utilizar
el micro con menos prestaciones es la opción más adecuada.
* como colocar los motores de CC : correa/directo
** se decidió que ya que tenemos motores con un buen par, no tiene
mucho sentido tener una correa.
** Surge el tema de donde colocar los motores para que siga siendo
ax12 y CC compatible, una opción para no cambiar las distribuciones
actuales es colocar los motores de CC atrás y permitir cambiar de
lugar la rueda loca para el lado opuesto al que está ahora. Hay que
tener ojo de que no obstaculice la conexión de puertos actual lo cual
es el problema que tiene ahora.
** Otro tema es como amurar la rueda a los motores, el motor que
compramos es de eje cilíndirco, hay otros con un perfil lo cual
permite que se pueda diseñar una rueda con un prisionero. Otra opción
es perforar el eje del motor y ponerle una espina para amurar la
rueda.

====Hardware====
*resolver que hacer con PWM: hackpoints, puertos
** PWM, mantener por hackpoint y generar módulo de firmware para PWM
por software utilizando Timer1 (inteligente, interrumpir solo cuando
es necesario).
** Generar informe con opciones de mantener o quitar botón de programación
* Módulo GPIO: no es equivalente al resistencia? Aporta algo?
** Evaluar quitar módulo port (porque no aporta nada)
** Evaluar agregar módulo de GPIO, permite por lo menos avisar al
usuario que está realizando una acción que puede dañar el equipo.
* Gadgets de sensore en DX, que hacer, definir ids o usar módulo
lector de voltaje, en general utilizar el de voltaje
** Crear módulos de temperatura y magnético, para laboratorios de física.
* chequear si el sensor de campo mag es analogico o digi

== 10/01/2013 ==

====Participantes====
Guillermo, Alan, , Fiorella, Pablo, Jorge, Andres, Faviel, John

====minutas====
Empieza reunion a las 18:26

====Documentación====
*Sensores de resistencia y voltage (John y Guille)
*Sensor de flexión ya esta documentado por Enrique

====Mecánica====
*Se estan haciendo los acrílicos en formacril, fecha aproximada 24
*Módulo motor hecho con carcasa de linterna utilizando una ficha butia, carcasa de un enchufe, arrancador de tubo y zunchos.
**Se discutio sobre utilizarlo con una correa o adicionarle una rueda, se decidio adicionarle la rueda y colocar el modulo en el lugar actual de las ruedas, manteniendo la estructura de los AX12, incorporándolo al butia por fuera. (Butia PUNK)
*Se habló de hacer un banco de prueba de motores para obtener datos útiles como el par, rpm , etc ...
*Se probaron los tornillos de plástico y dan buen resultado ya que protege el acrílico, son mas fácil de enroscar, mas amigables para los niños

====Hardware====
*Se discutió sobre los cambios de la USB4butia, estudiar lo de hacer una USB4butia solo para controlar motores y evaluar Modulito con microcontrolador propio para manejar motores, PIC16F628A buscar compilador GNU, buscar otro PIC de 8 patas
*Evaluar de quitar el clock de 37 khz y utilizar el pin 16 que es el CCP2 y asi evitar de quitar el boton de programacion
*Se hablo sobre sacar el boton de programacion, se decidio quitarlo y cambiar el bootloader y agregar dos puertos pwm (Si es necesario)
*Se discutió lo de quitar el bus AX12, se decidió que no porque permite agregar motores con control más complejo de forma fácil.
*Sacar los pines de programación ... ?

====Software====
*Serial por software (si se va hacer el modulo motor con pic propio)

== 03/01/2013 ==
====Participantes====
Rafa, Pablo, Pancho, Jorge, John

====Mecánica====
*Se dibujaron barandas nuevas con el tope , y se hicieron prototipos en goma eva para presentar en el butiá. Se presentó junto a la magallanes. Se discutió y se decidió hacer las barandas un poco más altas. Diseñar y construir 2 juegos de barandas: unas más largas con tope flotando y otras más cortas sin tope.
*Se mostró la nueva rueda butiá con agujero en el medio
*Se habló del modulo motor se agregan dos piezas de acrílico para mantener la estructura de los AX12 y no tener que hacer un butia distinto para la versión con otros motores. Hay dos opciones, una posee lengüetas como los AX12 y van en el mismo lugar con las ranuras existentes para los AX12 y la otra serían las fichas universales con el sistema de encastre butia.
*Estudiar agujeros para "ensanguchar" las dos planchas de acrílicos, agregar un tornillo más alineado con los que ya están con la medida de los AX12
*Se acomodó la ojiva del encastre butiá centrándola para que quede un poquito mas separdo de los rectángulos
*Se le agrega al logo la palabra SAM
*Ejemplo de logos para autoadhesivos
*Se van hacer arcilicos y autoadhesivos.
*Se va a probar el logo calado otra vez

== 27/12/2012 ==

====Participantes====
Daniel, Guillermo, Alan John, Fiorella, Aylen, Rodrigo, Enrique, Rafael, Pablo

====minutas====
* Empieza reunion a las 18:41

====Hardware====
* Acrílico había quedado mal grabado el logo la última vez, quedó una línea entrecortada.
** Se va a pedir devuelta con los logos bien grabados. Pablo trae planos el 3 de enero. Al pedir los nuevos acrílicos preguntar opciones de:
*** Pintar logos luego de grabarlos
*** Mejorar calidad del grabado para que no queden manchados.
*** Incrementar ancho de línea para que queden mejor marcados los logos.
** Pablo va a mandar a hacer pegotines calados de logos para manejar otra alternativa
** Se discute si poner nombre 2.0 o "sam". Mayoría eligió Sam (2 en charrúa)

====Motores====
* Se vio prototipo con motores de cargadores USB a dínamo, utilizando hack points.

====Software====
* Salió paquete de TortuBots v18, faltan paquetes Debian actualizar changelog (Aylen)
* Alan corrigió bug de memory leak de TortuBots, ahora no se bloquea en la XO. Está probado.
* PyBot (librería python para acceder a placa butiá) está casi listo, falta testear.
* Validación al tratar de grabar o escribir en hackpoint configurado para entrada o salida respectivamente. Hacerlo en api y agregarlo a TortuBots cuando trata de hacer una operación incorrecta. (Alan)

====Firmware====
* Módulo de Firmware de hackpoint no tiene que cambiar el modo del pin (Aylen)

== 10/12/2012 ==
====Participantes====

John, Aylen, Pablo, Gonzalo, Guillermo, Andrés, Diego, Rafael, Luis, Rodrigo, Marcelo

====minutas====
* Empieza reunion a las 19:50

====Hardware====
* Falta documentar prototipo con motores de linternas (Pancho)
* Piezas para anexar sensores: Pablo muestra 3 piezas, genérica de 2 lados, de 1 lado y una cortita.
** También se hizo pieza para reemplazar motores AX12.
** Se llega a un acuerdo de como tienen que ser las placas de sensores
* Se decide cambiar las piezas por piezas únicas para armado y reemplazo de AX12.
* Barandas, se van a cambiar por unas que empiezan finitas en la parte frontal y terminan gruesas en la parte trasera como guardabarros. En la parte delantera, tienen tope para aguantar una laptop.

====Motores====
* Motores "argentinos" no tienen certificado de origen (motor chino, engranajes argentinos)
* Guille va a mandar un mail a Fede para que averigüe en Brasil por alternativas de motores CC.
* Rodrigo, Gonzalo, van a armar prototipo con motores de cargadores USB a dínamo.

== 3/12/2012 ==
====Participantes====

John, Aylen, Pablo, Gonzalo, Guillermo, Francisco, Andrés, Daniel, Rafael, Alan, Luis

====minutas====
* Empieza reunion a las 19:30

====Hardware====
* Hay que definir los componentes para construir una serie de robots, de la mano de Antel (esperando h-bridge)
** Definir que motores de CC usar, de AP&S, modelo SP6-50, similar a AX12 ($80 argentinos), faltan definir los de Ignis (MR83-100, con pocas revoluciones y poco par), Pablo trae 2 de cada uno para probar.
* Ida a Triex sugerida por Daniel. Hay varios interesados, coordinar por mail.
* John, Andrés, definiendo USB4Motores, placa USB4All genérica, con H-bridge integrado.

====Motores====
* Motor de linterna recargable, funciona bien, Gonzalo va a comprar lintenrnas para armar un Butiá.
* Documentación de alternativas de motores: Daniel, Pablo y Francisco (documentar motores descartados - Daniel, motores de linternas recargables, Soportes Discos duros y contra chata. Motores a usar) Rafa va a mandar link de como crear usuario y stub de documento.
* Edgardo está armando el H-Bridge para controlar motores (Edgardo está armando)
* Se vieron acrílicos con logo

====firmware====
* Se solucionó problema en firmware (se estaba usando memoria inexistente)
* Andrés, Aylen, John: Trabajando en Módulo PWM por software en firmware.
* John - Falta módulo GPIO

====Sensores====
* Guille, John - Documentar en wiki como crear sensores nuevos.
* Gonzalo, mirando como funciona sensor de color.

====Software====
* Alan está escribiendo API en Python para Butia, falta contemplar varias placas USB
* Firmware update activity , está pronta la actividad 90%
* Andrés - Actualizar butialo a 2.0 (no dio el tiempo)

====Organización====
* Andrés comenta sugerencias del sumo.uy
** Agregar agujeros para tornillos
** Quejas de sensor de distancia, no se puede enganchar
** Robot Butiá triangular - Omni

== 26/11/2012 ==
====Participantes====
Luis, Marcelo, Guillermo R., Pablo Margenat, Gonzalo, Rafael Sisto, Andrés Aguirre, Aylen, Enrique, Diego, Martín , John, Javier, Alan, Fiorella

====minutas====
* Empieza reunion a las 19:30

====Hardware====
* Hay que definir los componentes para construir una serie de robots
** Definir que motores de CC usar (Quién va a definir esto?)
* Ida a Triex sugerida por Daniel. Hay varios interesados, coordinar por mail.

====Motores====
* Comisión continua Falta probar con mosfets (esperando módulo PWM de firmware)
** Cambiar circuito de muestra buscando mosfets de menor amperaje (Diego)
* Soportes de motores
** Acrílico (prontos para el 29/11), demo para 3/12
** Pancho y Pablo: cortando chasis de disco, pensando alternativas.
** Transmisión, se propone probar goma en el motor y goma en la rueda, en vez de una correa.
* Alternativas de motores:
** Linternas con generadores, se pueden usar como motores (menos de $200 en supermercados), hay que escribir en la wiki
** Andrés, Enrique - Consultar a Eneka por motores de continua hechos en Argentina (cerca de $700), modelo MR4-100, ver si tiene suficiente torque.

====firmware====
* Andrés, Aylen: Módulo PWM por software en firmware.
** (Andrés, Micho) Falta solucionar bug extraño cuando hay muchos módulos (posiblemente una asignación errónea de memoria), probar con Ida.
* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.(Se puede hacer)
** Faltan módulos GPIO y LED (Prontos, falta corregir bug).
* Pendiente Andrés - Liberar motores cuando se le mande orden velocidad cero.

====Sensores====

* Fibra óptica, se puede conseguir en Tilsit (6 metros con terminales, aprox U$ 35). Daniel va conseguir una nueva muestra actual para probar.
** Se consigue en el Clon por $65 una lámpara decorativa
** Luego de tener fibra, segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Sensores de efecto Hall (No se trató )
** Propuesta de Diego: sensor de imanes utilizando una bobina y con pin analógico.(No se trató )

====Software====

* Alan: bloque para configurar hack points, pronto, falta configurar como entrada.
* Bloque LED está.
* Alan, falta bloque GPIO
* Alan está escribiendo API en Python para Butia (falta testear, branch pybot)
* Guille, haciendo paquete Debian (armado makefile estilo GNU)
* Rodrigo, el tortuga tiene un uso excesivo de CPU (hay que ver si es nuestro o de walter) cuando se usan muchos bloques. Reproducir problema. (No se habló)
* Firmware update activity , está pronta la actividad 90%
* Andrés - Actualizar butialo a 2.0

== 19/11/2012 ==
====Participantes====
Guillermo R., Pablo Margenat, Rafael Sisto, Andrés Aguirre, Alan Aguiar , Rodrigo, Aylen, Gonzalo, Enrique, Diego

====minutas====
* Empieza reunion a las 19:30

====Motores====

* Comisión continua Falta probar con mosfets (esperando módulo PWM de firmware)
** Cambiar circuito de muestra buscando mosfets de menor amperaje (Diego)
* Soportes de motores
** Se hizo modelo, está pedido el acrílico (prontos para el 29/11), demo para 3/12
** Pancho y Pablo: cortando chasis de disco
* Buscar alternativas de motores:
** lectoras de CD, disketeras, discos duros (Diego está consiguiendo con Integra)
** Andrés está consultando en Eneka por motores de continua hechos en Argentina (cerca de $700), serían similares a los secadores de pelo, pero con reducción.
* Comision PaP - Se sigue trabajando para un prototipo, se propone controlar con circuito casero.

====firmware====

* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.
* Andrés - Liberar motores cuando se le mande orden velocidad cero.
* Andrés, Aylen: Módulo PWM por software en firmware.
* Andrés: Notificar placa como dispositivo serial al PC (avanzando).

====Sensores====

* Fibra óptica, se puede conseguir en Tilsit (6 metros con terminales, aprox U$ 35). Daniel va conseguir una nueva muestra actual para probar.
* Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Sensores de efecto Hall
** Propuesta de Diego: sensor de imanes utilizando una bobina y con pin analógico.

====Software====
* Alan: bloque para configurar hack points.
* Tortubots, tema pendiente: Generar un evento a los plugins cuando finalice la ejecución de los bloques (por ejemplo, para liberar cámara, parar motores, etc).
* Migración TurtleBlocks a android, falta librería GTK, trancado por ese tema
* Alan está escribiendo un API en python con funcionalidad similar a bobot (ventaja: no requiere lua ni dependencias de binarios adicionales, para arm no requeriría link a binarios extra, no requiere comunicación por sockets.)
* normalizar velocidades de 0 a 100. Se descarta porque no hay un problema concreto en que pueda beneficiar. En principio sirve para buscar la curiosidad de los alumnos.
* Separar paleta, ya está.
* Guille, haciendo paquete Debian.
* Rodrigo, el tortuga tiene un uso excesivo de CPU (hay que ver si es nuestro o de walter) cuando se usan muchos bloques. Reproducir problema.
* Guille, Aylen: Firmware update activity
** Actividad con un botón para actualizar (Rodrigo)

====Documentación====
* Rafael: Revisar documentación de entregables a Antel

====Resumen de Comisiones====
Soportes de motores: Pablo y Francisco

motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 12/11/2012 ==
====Participantes====
Guillermo Reisch, Diego, Daniel, John Pereira, Pablo Margenat, Rafael Sisto, Francisco Puignau, Andrés Aguirre, Martín Giachino, Alan Aguiar

====minutas====
* Empieza reunion a las 19:30

====Motores====
* Comisión continua - trajo demo con motores distintos y quedó bien el seguidoor de líneas.
** Falta probar con mosfets
* Soportes de motores
** Falta soporte para gomitas, propuesta de hacer 2 ruedas de acrílico más chicas para sostener.
** Falta soporte para rueda,
*** Proponen utilizar el mismo plato del soporte de gomitas, eje con rulemanes
*** Otra alternativa, usar motor de disco duro como rulemán (módulo independiente). (Guillermo va a traer discos duros para desarmar)
** Buscar alternativas de motores: secador de pelo (12v), lectoras de CD, disketeras
* Comision PaP - utilizar motor de impresora con driver. (para lunes 19/11)

====firmware====

* módulo firmware para bus pines digitales pronto, PWM se va a manejar por software
* firmware para sensor de voltaje pronto
* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.
* Andrés, Aylen: Módulo PWM por software en firmware.
* Andrés: Notificar placa como dispositivo serial al PC.

====Sensores====

* Demo de Módulo voltaje y resistencia
** Algunos detalles por corregir
* Fibra óptica, Daniel va a conseguir una muestra para el lunes siguiente
* (no se habló) Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises

====Software====

* Se creó bloque de sensor de voltaje
* Separar paleta, normalizar velocidades de 0 a 100 (Alan)
* Alan, el tortuga tiene un memory Leak (hay que ver si es nuestro o de walter) cuando se usan muchos bloques
* Alan, quitar compatibilidad para V1
* Guille, Aylen: Firmware update activity - postergado para próxima reunión.

====Resumen de Comisiones====
Soportes de motores: Pablo y Francisco

motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 05/11/2012 ==
====Participantes====
Gonzalo Tejera, Guillermo Reisch, Enrique Madruga, Daniel Cancela, John Pereira, Pablo Margenat, Rafael Sisto.

====minutas====
* Empieza reunion a las 19:30
* resumen, software/hardware/mecanica etc...

====Motores====
* Enrique averiguó motores alza-cristales: son caros (cerca de los $ 1000)
* Daniel mandó mail a SEMPRE, va a relevar que tipo de motores (otra chatarra) se pueden conseguir
* Comisión continua - va a avanzar con el módulo de relés
* Comisión continua - motores de secador de pelo (12v), lectoras de CD, disketeras
* Comisión continua - Preguntar a "Lechuga" qué motores usaron
* Comision PaP - utilizar motor de impresora con driver. (para lunes 19/11)
* Reducciones - 2 alternativas, correas o engranajes impresos.

====firmware====

* Aylen, agregar módulo firmware para bus pines digitales y PWM (pin 17). Si puede estar para esta semana, mejor.
* John - Otra alternativa para manejar motores, utilizar el puerto ax12 y un pic conversor a otro tipo de motores.
* Aylen - falta firmware para sensor de voltaje (estaría pronto)

====Sensores====
* sensor distancia auto chino - Enrique consultó en comercio electrónico y superan los $1000, seguir consultando alternativas.
* Fibra óptica, intentar utilizar fibra óptica de cotillón (adornos de colores)
** Daniel para el lunes se comprometió en traer un par de tramos (quizás se consigue en SEMPRE)
** Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Módulo voltaje y resistencia (demo lunes 12)
** Se decidió utilizar jumper en vez de switch
** Se creó módulo en kicad
* Firmware update activity (trabajando...)

====Software====
* Alan, crear bloque de sensor de voltaje
* Alan, hablar con Andrés y Rodrigo - El tortuga tiene un memory Leak (hay que ver si es nuestro o de walter) cuando se usan muchos bloques

====Hardware====
* Chata va a comenzar a llevar logo de Antel

====Gestión====
* Intentar convertir las reuniones en talleres

====Resumen de Comisiones====
motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 29/10/2012 ==

====Participantes====
margenat, sisto, andrew, madruga, chino, john, santiago, gonchi, pancho, aylen, rodrigo

====Minutas====
* hora de comienzo: 19:25 (19:00)
* motores...
*

====motores====
* Otra discusión sobre PaP. Andrés se va a encargar de los motores PaP.
* Motores de alza-cristales/limpia-vidrios parece una buena idea. Se consiguen en plaza, son reciclables, tienen la reducción.
* Pablo propone pieza para mantener la estructura del AX-12 y mantener la estética

====hardware====
* ver los pines que están sin utilizar.
* averiguar sensor distancia auto chino
* sensor enrique de fibra óptica para el butiá, sensor antena

==== mecánica ====
* pablo mostró la nueva chata butiá.

==== gestión ====
* se agrega a gonchi a comisión motores de continua.

== 18/10/2012 ==

====Participantes====
Gonzalo, Jorge, Luis, Martin(Chino), Aylen, John, Rodrigo, Diego (Antel), Guille, Daniel Cancela(montacargas) y Pablo(Estudiante nuevo)

====Minuta====
* Reunión del día 18/10/2012
* Hora de comienzo: 14.50
* Asisten: Gonzalo, Jorge, Luis, Martin(Chino), Aylen, John, Rodrigo, Diego (Antel), Guille, Daniel Cancela(montacargas) y Pablo(Estudiante nuevo)
* Presentación del proyecto a la gente nueva
* Motores
* Modulo voltaje,
* Fin reunión 17.15

====motores====
* discusión por motores nuevamente
* Comisión motores no hizo mucho. Se presentó precio de servos 28u$s de 15kg, 16u$s de 6,8kg. Se va a seguir averiguando en otros lados.
* NO steppers (daniel va a averiguar algo sobre steppers)
* Hay que conseguir los motores de destornillador.

====hardware====
* modulo voltaje y resistencia (guille, egardo, enrique)
* bornera o jack? (jack hace corto,[los jack machos truchos, los buenos NO HACEN CORTO {Guille}])
* protección? volver al diodo que no pusimos
* egardo y guille hoy van a encargarse del hardware
* conseguir conectores bosch mas chicos o cables mejores (guille) llevar el cable de ax12 original

====software====
* activity cambiar id (rodrigo)
* ayle john chino van a agregar funcionalidades al modulo ax12 para actividad de id
* (chequear wiki de mtbutia que estan haciendo algo parecido)
* Tortuga con varios hilos (elemichele, alan el hombre tortuga, andres) quiere hacer un tortuga con varios hilos

====firmware====
* firmware modulo voltaje y resistencia listo
* a FUA agregar un browse para poder grabar un .hex propio
* agregar consultar versión y la id de placa
* pasaje a serial jorge
* discusión sobre versionado de firmware y hardware
* gonchi propone agregar resistencia para versionado de placa
* versionado del firmware
* john va a revisar codigo, hotplug en motores
* git migrar pnp a master, ya estaría pronto
* hackpoint (andres)

====gestión====
* Diego Antel propone: taller utu-antel en la teja segunda quincena enero (john y jorge)
* antel pide un butia mas (hay que discutir esto)
* Daniel plantea tirar lineas a ute (manejando como se manejó con ANTel)
* comisión conseguir openmoko (gonchi jorge)
* openmoko??????? es probable dijo pablo sigue en camino.
* Chino va a compartir la documentación para antel. (NO METER MANO SIN CONSULTARLO A ÉL)
* Pedido por parte de edgardo, chino y enrique para cambiar la reunión
* Se propone reunion los LUNES 18:30

== 11/10/2012 ==

====Participantes====
Rodrigo, John, Edgardo, Enrique, Gonzalo.

====Minuta====
* Acta de la reunión realizada el 11/10/2012
* Motores reciclados
* firmware: actualizador y mejoras
* devolución de robots

====hardware====
* Andrés opina que los servos no cumplen con lo propuesto por el proyecto butiá 2.0 ya que no se pueden reciclar.
* Gonzalo opina que los motores stepper no son aptos.
* Se decidió comenzar a investigar motores de corriente continua y servos que se consigan en uruguay.
* Rodri va a averiguar el costo de servos con gran torque en el mercado local y de corriente continua en casas del estilo repuestos de auto. Incluso se puede ver si la reducción de alguno de los respuestos de auto no es de utilidad.
* Luego se hará una prueba con motores del tipo stepper para mantener una alternativa de reciclado que es abundante en Uruguay.
* Por otro lado se priorizó la construcción de los módulos para leer voltaje y resistencia. Esto sería una alternativa a lo que la XO trae para leer del puerto de audio, pero independiente de la computadora. Tanto Guzmán como Enrique hoy día están haciendo muchos sensores interesantes que pueden prototiparse rápido de esta manera, además de dar continuidad al proyecto Física con XO. La idea es comenzar con una primer versión para tener algo para pasarle a Guzmán lo antes posible. La idea es que a futuro incluya protección pero si los tiempos no dan realizar la primer versión simple sin protección que de hecho es lo que tiene la XO hoy día.

====firmware/software====
* aplicación cambiar el id, cambiar id de los motores (rodrigo)
* aplicación FUA (inc hex) rompemos compatibilidad para la v1
* hotplug en motores
* hackpoint módulo firmware
* pasaje a dispositivo serial (toribio compatibilidad) por defecto esta activado el control de energía de la XO definir versionado de firmware

====mecánica:====
* fichas, metodos conexión, eles, rivetes, compatibilidad con mecano, mejorar la compatiblidad con lego compatibilidad con otras computadoras? Compatibilidad lego ser menos dependiente de las cruces dejar solo agujeros con separación lego y más grandes. De 4.6 mm a 5mm explorar motores continua y servo (enrique servo + edgardo) comisión de encastre (pablo, rodrigo)y sin espacio para la mano baranda cuadrada con agujeritos computadora sobre la baranda pinza: 1 o 2 motores, ver si no es muy complicado usar 1 motor.
* Git migrar pnp a master

====gestión:====
* a fin de año tiene que devolver el robot (prestamo por un año)
* Se definió la comisión de motores: Rodrigo, John, Edgardo y Enrique

Mecánica Butiá V2.0

2013-02-19T21:32:35Z

Rsisto: /* Materiales para la nueva versión de Butiá v2.0 */

== '''En construcción''' ==
[[Archivo:Butia18.jpg | 900px | center]]

== Mejoras Butiá v2.0 ==

* [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Compatibilidad Compatibilidad con Lego].
* Sistema [http://es.wikipedia.org/wiki/Conexi%C3%B3n_en_caliente HotPlug].
* Desarrollado 100% en Facultad de Ingenieria.
* Componentes disponibles en Uruguay.

== Materiales para la nueva versión de Butiá v2.0 ==

Lista de elementos necesarios para la construcción:
* 1 Placa [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Usb4butia USB4Butiá v2.0].
* 2 [[Motores | Motores compatibles]].
* 1 [[Sensores_2.0 | Sensores v2.0]].
* 1 [[Pack de baterías]].
* 1 Rueda loca.
* 1 Chasis.
* 1 Chata.
* 2 Barandas.
* 2 Rueda Interior.
* 4 Rueda Exterior.
* Bloques y Placas.
* 1 Llave de encendido.
* Tornillos, tuercas y arandelas.
* [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Construcci%C3%B3n_Buti%C3%A1_V1.8#Cables_RJ45 Cables RJ45 para sensores].
* Varios Cables para motores y alimentación.
* 1 Cable USB A-B (usados comunmente para conectar impresoras a PC).

 

== Chata Butiá ==
 
[[Archivo:ChataButiav1-8.jpg | 800px]]
 
 
El archivo .zip contiene los planos para el acrilico de la chata. (En formato .cdr, .svg y .pdf)
 
[http://www.fing.edu.uy/inco/proyectos/butia/files/ChataButia20.zip Chata Butiá]
 
 

== Rueda Bloque y Placa Butiá ==
 
[[Archivo:Rueda-Bloque-PlacaButiav1-8.jpg | 800 px]]
 
El archivo .zip contiene los planos para las ruedas, los bloques y la placa de la chata. (En formato .cdr, .svg y .pdf)
 
[http://www.fing.edu.uy/inco/proyectos/butia/files/RuedaBloquePlaca20.zip Ruedas, bloques y placa] 
 

== Barra de Encastre Butiá ==

Luego de recorrer distintos diseños de encastre que buscaban la funcionalidad en la instalación de sensores y compatibilidad con otros kits llegamos a una barra de encastre que contempla todas las opciones que se nos presentaron hasta el momento y que es la barra de encastre Butiá.

[[Archivo:Barra_de_encastre_butia.png | center]]

En la figura podemos ver la la barra de encastre Butiá y las distintas compatibilidades que tiene.
La distancia entre el centro de la ojiva y los agujeros laterales es de 16mm donde se puede atornillar cualquier barra de lego, entre los extremos de la ojiva y los agujeros hay una distancias de 12,7mm que permite atornillar cualquier pieza de mecano y finalmente con el centro de la ojiva y los dos rectángulos a su lado se encastran las placas de sensores Butiá.

''Foto de pieza lego agarrada al butia''

''Foto de pieza mecano agarrada al butia''

''Foto de placa montada en butia''

Es importante que con esta barra de encastre el Butiá no pierde la posibilidad de añadirle elementos y asegurarlos con zunchos, collarines o tornillos de menos de 5mm de diámetro.

''Foto de escuadras de acrílico con sensor agarrado con collarines''

=== Placa de Sensores Butiá ===

La placa de sensores ya no solo es un soporte de sensores sino que puede ser parte de una estructura creada con más de una placa encastrada para distintos fines como por ejemplo; brazo, pinza, sensores alejados, sensores altos y bajos, etc. Esto es posible ya que la placa porta encastres Butiá hembra y macho en todos los sentidos.

''Foto de la placas sensor''

''Fotos de sensores montados en butia y alguna estructura''

También puede servir de estructura para montar el chasis a la placa sin necesidad de tener motores AX12. Esta ultima propiedad se busco con el fin de poder tener la estructura del Butiá sin depender de los motores AX12 y así poder montar cualquier motor de corriente continua de menor costo. El agujero central de 6mm en la placa montada como estructura permite que se use de soporte para el eje de la rueda.

=== Accesorios de montaje ===

Como accesorios de montaje se pueden encontrar en el Kit los encastres para placas en paralelo que permite colocar 2 placas de sensor en paralelo entre ellas o una placa de sensor en paralelo con la chata o el chasis.

''Foto del encastre para placas en paralelo''

''Foto de 2 placas encastradas en paralelo y placa con chasis''

Los tornillos son M4 de 20mm y cabeza hexagonal para que sea sencillo su montaje y sean compatibles para colocar placas de sensor en paralelo o perpendiculares. El material de los tornillos es Nylon que no provoca daños en el acrílico y se puede lograr un buen ajuste enroscando solo con la mano.

''Foto de los tornillos y de alguno colocado''

Es importante tener en cuenta que se pueden usar tornillos M4 de cabeza hexagonal de cualquier largo en acero o hierro o tornillos M4 con cualquier tipo de cabeza pero de 15mm de largo

''Foto de uso de tornillo cabeza hexagonal y cabeza philips''

=== Algunos ejemplos: ===

Ampliar en longitud.

''Foto de un ejemplo''

Ampliar en altura.

''Foto de un ejemplo''

Acercarse al piso.

''Foto de un ejemplo''

Poder hacer un Butiá de varias chatas de altura.

''Foto de un ejemplo''

Mecánica Butiá V2.0

2013-02-19T21:32:07Z

Rsisto:

== '''En construcción''' ==
[[Archivo:Butia18.jpg | 900px | center]]

== Mejoras Butiá v2.0 ==

* [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Compatibilidad Compatibilidad con Lego].
* Sistema [http://es.wikipedia.org/wiki/Conexi%C3%B3n_en_caliente HotPlug].
* Desarrollado 100% en Facultad de Ingenieria.
* Componentes disponibles en Uruguay.

== Materiales para la nueva versión de Butiá v2.0 ==

Lista de elementos necesarios para la construcción:
* 1 Placa [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Usb4butia USB4Butiá v2.0].
* 2 [[Motores | Motores compatibles]].
* 1 [[Sensores_1.8 | Sensores v1.8]].
* 1 [[Pack de baterías]].
* 1 Rueda loca.
* 1 Chasis.
* 1 Chata.
* 2 Barandas.
* 2 Rueda Interior.
* 4 Rueda Exterior.
* Bloques y Placas.
* 1 Llave de encendido.
* Tornillos, tuercas y arandelas.
* [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Construcci%C3%B3n_Buti%C3%A1_V1.8#Cables_RJ45 Cables RJ45 para sensores].
* Varios Cables para motores y alimentación.
* 1 Cable USB A-B (usados comunmente para conectar impresoras a PC).

 

== Chata Butiá ==
 
[[Archivo:ChataButiav1-8.jpg | 800px]]
 
 
El archivo .zip contiene los planos para el acrilico de la chata. (En formato .cdr, .svg y .pdf)
 
[http://www.fing.edu.uy/inco/proyectos/butia/files/ChataButia20.zip Chata Butiá]
 
 

== Rueda Bloque y Placa Butiá ==
 
[[Archivo:Rueda-Bloque-PlacaButiav1-8.jpg | 800 px]]
 
El archivo .zip contiene los planos para las ruedas, los bloques y la placa de la chata. (En formato .cdr, .svg y .pdf)
 
[http://www.fing.edu.uy/inco/proyectos/butia/files/RuedaBloquePlaca20.zip Ruedas, bloques y placa] 
 

== Barra de Encastre Butiá ==

Luego de recorrer distintos diseños de encastre que buscaban la funcionalidad en la instalación de sensores y compatibilidad con otros kits llegamos a una barra de encastre que contempla todas las opciones que se nos presentaron hasta el momento y que es la barra de encastre Butiá.

[[Archivo:Barra_de_encastre_butia.png | center]]

En la figura podemos ver la la barra de encastre Butiá y las distintas compatibilidades que tiene.
La distancia entre el centro de la ojiva y los agujeros laterales es de 16mm donde se puede atornillar cualquier barra de lego, entre los extremos de la ojiva y los agujeros hay una distancias de 12,7mm que permite atornillar cualquier pieza de mecano y finalmente con el centro de la ojiva y los dos rectángulos a su lado se encastran las placas de sensores Butiá.

''Foto de pieza lego agarrada al butia''

''Foto de pieza mecano agarrada al butia''

''Foto de placa montada en butia''

Es importante que con esta barra de encastre el Butiá no pierde la posibilidad de añadirle elementos y asegurarlos con zunchos, collarines o tornillos de menos de 5mm de diámetro.

''Foto de escuadras de acrílico con sensor agarrado con collarines''

=== Placa de Sensores Butiá ===

La placa de sensores ya no solo es un soporte de sensores sino que puede ser parte de una estructura creada con más de una placa encastrada para distintos fines como por ejemplo; brazo, pinza, sensores alejados, sensores altos y bajos, etc. Esto es posible ya que la placa porta encastres Butiá hembra y macho en todos los sentidos.

''Foto de la placas sensor''

''Fotos de sensores montados en butia y alguna estructura''

También puede servir de estructura para montar el chasis a la placa sin necesidad de tener motores AX12. Esta ultima propiedad se busco con el fin de poder tener la estructura del Butiá sin depender de los motores AX12 y así poder montar cualquier motor de corriente continua de menor costo. El agujero central de 6mm en la placa montada como estructura permite que se use de soporte para el eje de la rueda.

=== Accesorios de montaje ===

Como accesorios de montaje se pueden encontrar en el Kit los encastres para placas en paralelo que permite colocar 2 placas de sensor en paralelo entre ellas o una placa de sensor en paralelo con la chata o el chasis.

''Foto del encastre para placas en paralelo''

''Foto de 2 placas encastradas en paralelo y placa con chasis''

Los tornillos son M4 de 20mm y cabeza hexagonal para que sea sencillo su montaje y sean compatibles para colocar placas de sensor en paralelo o perpendiculares. El material de los tornillos es Nylon que no provoca daños en el acrílico y se puede lograr un buen ajuste enroscando solo con la mano.

''Foto de los tornillos y de alguno colocado''

Es importante tener en cuenta que se pueden usar tornillos M4 de cabeza hexagonal de cualquier largo en acero o hierro o tornillos M4 con cualquier tipo de cabeza pero de 15mm de largo

''Foto de uso de tornillo cabeza hexagonal y cabeza philips''

=== Algunos ejemplos: ===

Ampliar en longitud.

''Foto de un ejemplo''

Ampliar en altura.

''Foto de un ejemplo''

Acercarse al piso.

''Foto de un ejemplo''

Poder hacer un Butiá de varias chatas de altura.

''Foto de un ejemplo''

Construcción Butiá V1.8

2013-02-19T21:26:25Z

Rsisto:

*[[Electrónica_Butiá_v1.8| Electrónica]]
*[[Software|Software]]
*[[Mecánica_Butiá_V1.8|Mecanica]]
*[http://www.fing.edu.uy/inco/proyectos/butia/files/hardware/Presentacion_Butia_Taller_Armado.odp Presentacion Taller de Armado ]

Electrónica Butiá v2.0

2013-02-19T21:09:24Z

Rsisto: Página creada con '* USB4butiá * Sensores 2.0'

* [[ USB4butiá | USB4butiá]]
* [[Sensores 2.0| Sensores 2.0]]

Electrónica

2013-02-19T21:08:56Z

Rsisto: Redirigiendo a Electrónica Butiá v2.0

#REDIRECCIÓN [[Electrónica Butiá v2.0]]

Electrónica Butiá v1.8

2013-02-19T21:08:35Z

Rsisto: Electrónica trasladada a Electrónica Butiá v1.8

* [[ USB4butiá | USB4butiá]]
* [[Sensores 1.8| Sensores 1.8]]

Electrónica

2013-02-19T21:08:35Z

Rsisto: Electrónica trasladada a Electrónica Butiá v1.8

#REDIRECCIÓN [[Electrónica Butiá v1.8]]

Mecanica

2013-02-19T21:03:38Z

Rsisto: Deshecha la revisión 4049 de Rsisto (disc.)

#REDIRECCIÓN [[Mecánica Butiá V2.0]]

Mi Butiá

2013-02-19T20:54:24Z

Rsisto: Deshecha la revisión 3635 de Johnnieway9 (disc.)

[[Archivo:Mi Butiá 2.jpg]]

Bienvenidos a la wiki de Mi Butiá, aquí podras encontrar información para poder saber un poco más sobre el robot butiá, a travez de imágenes, videos y descargas.

Mecánica Butiá V2.0

2013-02-19T20:44:55Z

Rsisto:

== '''En construcción''' ==
[[Archivo:Butia18.jpg | 900px | center]]

== Mejoras Butiá v1.8 ==

* [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Compatibilidad Compatibilidad con Lego].
* Sistema [http://es.wikipedia.org/wiki/Conexi%C3%B3n_en_caliente HotPlug].
* Desarrollado 100% en Facultad de Ingenieria.
* Componentes disponibles en Uruguay.

== Materiales para la nueva versión de Butiá v1.8 ==

Lista de elementos necesarios para la construcción:
* 1 Placa [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Usb4butia USB4Butiá v1.8].
* 2 [http://www.robotis.com/xe/dynamixel_en Motores Dinamixel AX-12A].
* 1 [[Sensores_1.8 | Sensores v1.8]].
* 1 [[Pack de baterías]].
* 1 Rueda loca.
* 1 Chasis.
* 1 Chata.
* 2 Barandas.
* 2 Rueda Interior.
* 4 Rueda Exterior.
* Bloques y Placas.
* 1 Llave de encendido.
* Tornillos, tuercas y arandelas.
* [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Construcci%C3%B3n_Buti%C3%A1_V1.8#Cables_RJ45 Cables RJ45 para sensores].
* Varios Cables para motores y alimentación.
* 1 Cable USB A-B (usados comunmente para conectar impresoras a PC).

 

== Chata Butiá ==
 
[[Archivo:ChataButiav1-8.jpg | 800px]]
 
 
El archivo .zip contiene los planos para el acrilico de la chata. (En formato .cdr, .svg y .pdf)
 
[http://www.fing.edu.uy/inco/proyectos/butia/files/ChataButia20.zip Chata Butiá]
 
 

== Rueda Bloque y Placa Butiá ==
 
[[Archivo:Rueda-Bloque-PlacaButiav1-8.jpg | 800 px]]
 
El archivo .zip contiene los planos para las ruedas, los bloques y la placa de la chata. (En formato .cdr, .svg y .pdf)
 
[http://www.fing.edu.uy/inco/proyectos/butia/files/RuedaBloquePlaca20.zip Ruedas, bloques y placa] 
 

== Barra de Encastre Butiá ==

Luego de recorrer distintos diseños de encastre que buscaban la funcionalidad en la instalación de sensores y compatibilidad con otros kits llegamos a una barra de encastre que contempla todas las opciones que se nos presentaron hasta el momento y que es la barra de encastre Butiá.

[[Archivo:Barra_de_encastre_butia.png | center]]

En la figura podemos ver la la barra de encastre Butiá y las distintas compatibilidades que tiene.
La distancia entre el centro de la ojiva y los agujeros laterales es de 16mm donde se puede atornillar cualquier barra de lego, entre los extremos de la ojiva y los agujeros hay una distancias de 12,7mm que permite atornillar cualquier pieza de mecano y finalmente con el centro de la ojiva y los dos rectángulos a su lado se encastran las placas de sensores Butiá.

''Foto de pieza lego agarrada al butia''

''Foto de pieza mecano agarrada al butia''

''Foto de placa montada en butia''

Es importante que con esta barra de encastre el Butiá no pierde la posibilidad de añadirle elementos y asegurarlos con zunchos, collarines o tornillos de menos de 5mm de diámetro.

''Foto de escuadras de acrílico con sensor agarrado con collarines''

=== Placa de Sensores Butiá ===

La placa de sensores ya no solo es un soporte de sensores sino que puede ser parte de una estructura creada con más de una placa encastrada para distintos fines como por ejemplo; brazo, pinza, sensores alejados, sensores altos y bajos, etc. Esto es posible ya que la placa porta encastres Butiá hembra y macho en todos los sentidos.

''Foto de la placas sensor''

''Fotos de sensores montados en butia y alguna estructura''

También puede servir de estructura para montar el chasis a la placa sin necesidad de tener motores AX12. Esta ultima propiedad se busco con el fin de poder tener la estructura del Butiá sin depender de los motores AX12 y así poder montar cualquier motor de corriente continua de menor costo. El agujero central de 6mm en la placa montada como estructura permite que se use de soporte para el eje de la rueda.

=== Accesorios de montaje ===

Como accesorios de montaje se pueden encontrar en el Kit los encastres para placas en paralelo que permite colocar 2 placas de sensor en paralelo entre ellas o una placa de sensor en paralelo con la chata o el chasis.

''Foto del encastre para placas en paralelo''

''Foto de 2 placas encastradas en paralelo y placa con chasis''

Los tornillos son M4 de 20mm y cabeza hexagonal para que sea sencillo su montaje y sean compatibles para colocar placas de sensor en paralelo o perpendiculares. El material de los tornillos es Nylon que no provoca daños en el acrílico y se puede lograr un buen ajuste enroscando solo con la mano.

''Foto de los tornillos y de alguno colocado''

Es importante tener en cuenta que se pueden usar tornillos M4 de cabeza hexagonal de cualquier largo en acero o hierro o tornillos M4 con cualquier tipo de cabeza pero de 15mm de largo

''Foto de uso de tornillo cabeza hexagonal y cabeza philips''

=== Algunos ejemplos: ===

Ampliar en longitud.

''Foto de un ejemplo''

Ampliar en altura.

''Foto de un ejemplo''

Acercarse al piso.

''Foto de un ejemplo''

Poder hacer un Butiá de varias chatas de altura.

''Foto de un ejemplo''

Mecánica Butiá V1.8

2013-02-19T20:44:44Z

Rsisto:

Mecánica Butiá V2.0

2013-02-19T20:44:14Z

Rsisto: Página creada con ' == Barra de Encastre Butiá == Luego de recorrer distintos diseños de encastre que buscaban la funcionalidad en la instalación de sensores y compatibilidad con otros kits ll...'

== Barra de Encastre Butiá ==

Luego de recorrer distintos diseños de encastre que buscaban la funcionalidad en la instalación de sensores y compatibilidad con otros kits llegamos a una barra de encastre que contempla todas las opciones que se nos presentaron hasta el momento y que es la barra de encastre Butiá.

[[Archivo:Barra_de_encastre_butia.png | center]]

En la figura podemos ver la la barra de encastre Butiá y las distintas compatibilidades que tiene.
La distancia entre el centro de la ojiva y los agujeros laterales es de 16mm donde se puede atornillar cualquier barra de lego, entre los extremos de la ojiva y los agujeros hay una distancias de 12,7mm que permite atornillar cualquier pieza de mecano y finalmente con el centro de la ojiva y los dos rectángulos a su lado se encastran las placas de sensores Butiá.

''Foto de pieza lego agarrada al butia''

''Foto de pieza mecano agarrada al butia''

''Foto de placa montada en butia''

Es importante que con esta barra de encastre el Butiá no pierde la posibilidad de añadirle elementos y asegurarlos con zunchos, collarines o tornillos de menos de 5mm de diámetro.

''Foto de escuadras de acrílico con sensor agarrado con collarines''

=== Placa de Sensores Butiá ===

La placa de sensores ya no solo es un soporte de sensores sino que puede ser parte de una estructura creada con más de una placa encastrada para distintos fines como por ejemplo; brazo, pinza, sensores alejados, sensores altos y bajos, etc. Esto es posible ya que la placa porta encastres Butiá hembra y macho en todos los sentidos.

''Foto de la placas sensor''

''Fotos de sensores montados en butia y alguna estructura''

También puede servir de estructura para montar el chasis a la placa sin necesidad de tener motores AX12. Esta ultima propiedad se busco con el fin de poder tener la estructura del Butiá sin depender de los motores AX12 y así poder montar cualquier motor de corriente continua de menor costo. El agujero central de 6mm en la placa montada como estructura permite que se use de soporte para el eje de la rueda.

=== Accesorios de montaje ===

Como accesorios de montaje se pueden encontrar en el Kit los encastres para placas en paralelo que permite colocar 2 placas de sensor en paralelo entre ellas o una placa de sensor en paralelo con la chata o el chasis.

''Foto del encastre para placas en paralelo''

''Foto de 2 placas encastradas en paralelo y placa con chasis''

Los tornillos son M4 de 20mm y cabeza hexagonal para que sea sencillo su montaje y sean compatibles para colocar placas de sensor en paralelo o perpendiculares. El material de los tornillos es Nylon que no provoca daños en el acrílico y se puede lograr un buen ajuste enroscando solo con la mano.

''Foto de los tornillos y de alguno colocado''

Es importante tener en cuenta que se pueden usar tornillos M4 de cabeza hexagonal de cualquier largo en acero o hierro o tornillos M4 con cualquier tipo de cabeza pero de 15mm de largo

''Foto de uso de tornillo cabeza hexagonal y cabeza philips''

=== Algunos ejemplos: ===

Ampliar en longitud.

''Foto de un ejemplo''

Ampliar en altura.

''Foto de un ejemplo''

Acercarse al piso.

''Foto de un ejemplo''

Poder hacer un Butiá de varias chatas de altura.

''Foto de un ejemplo''

Construcción Butiá V1.8

2013-02-19T20:43:07Z

Rsisto:

*[[Electrónica| Electrónica]]
*[[Software|Software]]
*[[Mecánica_Butiá_V1.8|Mecanica]]
*[http://www.fing.edu.uy/inco/proyectos/butia/files/hardware/Presentacion_Butia_Taller_Armado.odp Presentacion Taller de Armado ]

Mecanica

2013-02-19T20:40:29Z

Rsisto: Página blanqueada

Butia reconocimiento marcas

2013-02-19T20:25:14Z

Rsisto: /* Paleta reconocimiento de marcas */

== Integrantes ==
* Nicolás Fúrquez
* Rafael Sisto

== Objetivos ==
* Utilizando [http://www.hitl.washington.edu/artoolkit/ ARToolKit] construir un plugin para Tortugarte/Tortublocks que permita reconocer las marcas. Esto puede ser utilizado para que el robot se localice y navegue en un entorno.

Ejemplos de marcas: 
[[Archivo:StopMark.png|300px]] [[Archivo:YieldMark.png|300px]]

Una de las cosas que nos permite la librería (ARToolKit) es que las marcas no necesariamente tienen que estar en color, permitiendo así imprimirlas en cualquier impresora siempre y cuando se mantenga el tamaño.

== Documentación de la solución ==
Se desarrolló un api que obtiene la información almacenada de las marcas y mediante la ayuda de ARToolKit se detectan las mismas en las capturas de la cámara.

El código fuente e instrucciones de instalación se pueden encontrar en el repositorio utilizado:
[https://github.com/rsisto/multiPatternRecognition multiPatternRecognition]

=== Diagrama de componentes ===
En el siguiente diagrama pueden visualizarse los componentes y su interacción. pattern_detection funciona como plugin de TurtleBlocks, que a su vez utiliza la librería multiPatternDetection (a través de un binding de python a C). Esta última utiliza funciones de ARToolKit para la detección de marcas.

[[Archivo:Arq_pattern_detection.png|400px|Arquitectura de detección de patrones con ARToolKit]]

=== Paleta reconocimiento de marcas ===
Paleta:

[[Archivo:Paleta_reco_marcas.png|700px]]

La paleta posee botones fijos que son:

'''"Viendo Señal"''':Este icono recibe como parámetro un icono de señal (imagen o texto), y nos dice si la cámara lo esta viendo o no.

'''"Distancia Señal"''':Este icono devuelve la distancia trigonométrica desde la cámara hasta el centro de la señal, la magnitud utilizada son mm. Se asume un tamaño de marcas de 16x16cm, salvo que se configure de forma distinta.

El resto se autogenera leyendo el archivo pattern_detection/library/multiPatternDetection/Data/object_data, en este archivo están todos las marcas que se pueden ver con la paleta, uno de los datos que se ponen dentro es un identificador (nombre) que al iniciarse se lee y luego se busca en la carpeta pattern_detection/images/ si tiene el icono correspondiente, si está pone la imagen como aparece en la paleta, sino lo encuentra generara el icono pero con el texto del nombre. En la sección [[Butia_reconocimiento_marcas]] se puede ver las características de estos iconos.

En este ejemplo se puede ver como se utiliza, en el código de la izquierda si la cámara ve, la señal de curva, moverá 100 la tortuga hacia adelante y luego girara a la derecha un angulo aleatorio entre -30 y 30.
En el ejemplo de la derecha si ve la señal de ''Contramano'' se movera hacia atras y cambiara la pluma a rojo, sino cambiara a azul y se movera 100 hacia adelante

[[Archivo:reconociendo_seniales_Ejemplo.png|700px]]

==== Ejemplos usando la paleta y Butia ====

Usando la marca de ''Pare'', el Butia detiene la marcha.

[[Archivo:ButiaSenialesEjemplo1.png|300px|left]] <videoflash>vF9ZhQYIwVg</videoflash>

 Usando la marca de ''Ceda el paso'', el Butia disminuye la velocidad.

[[Archivo:ButiaSenialesEjemplo2.png|300px|left]]<videoflash>Mbs5GT8vuIM</videoflash>

 Usando la marca de ''Contramano'', el Butia gira hasta no ver la marca y luego sigue adelante.

[[Archivo:ButiaSenialesEjemplo3.png|300px|left]] <videoflash>m04N9YJ7qd4</videoflash>

=== Desafíos y problemas encontrados ===
* La librería ARToolKit requiere la librería libglut.so.3 para funcionar, sin embargo en las XO no es posible instalar la librería en carpetas del sistema. Esto causa que al intentar cargar la librería con C types en python se devuelva el error ''OSError: libglut.so.3: cannot open shared object file: No such file or directory''. Para evitar este problema, se adjunta la librería en la carpeta del plugin y se carga en python previo a cargar la librería de ARToolkit con el siguiente comando: ''cdll.LoadLibrary("lib/libglut.so.3")''.

== Instalación de plugin ==
===Compilar archivos===
Son necesarias los siguientes paquetes debian para poder compilar:
libglib2.0-dev, freeglut3-dev, libgstreamer0.10-dev, libxi-dev

===Ejecución===
Para la ejecución del plugin es necesario instalar el paquete gst-plugins-good.

Si se ejecuta en una máquina configurada en idioma inglés, es necesario substituir "0,0" por "0.0" en el archivo turtle_art_plugin/pattern_recognition/library/multiPatternRecognition/Data/object_data.

===Correr script de prueba===
Opcionalmente, es posible correr pruebas para asegurarse que la detección de marcas está funcionando correctamente.

En la carpeta turtle_art_plugin/pattern_recognition/doc del código butiá, hay un pdf con la marca NotEnter. Imprimir el pdf.

Luego, ejecutar turtle_art_plugin/pattern_recognition/library/apiTestDetectMarkers.py. Al posicionar la marca impresa frente a la cámara, debería imprimirse un número en consola, que representa la distancia a la marca detectada.

== Generación de nuevas marcas ==
Es posible generar nuevas marcas utilizando una actividad creada para ese fin o de forma manual.

=== Actividad para agregar marcas ===

Se creo una actividad por la cual se puede agregar o quitar marcas, de una manera mas amena al usuario (docentes o educandos), se puede descargar la misma desde [http://download.sugarlabs.org/activities/4650/ el sitio de Sugar Labs],
La actividad se puede instalar sin tener el Plugin o Tortugarte/TortuBots, pero al abrirla avisa al usuario que no se encuentra alguno de estos elementos.
En la primer pestaña se puede ver una lista con los identificadores de las señales que están instaladas.

[[Archivo:NewPattersSegundaPestaña.png|600px]]

Si existe un icono asociado se muestra a la derecha al seleccionarlo, si no lo tiene se muestra un icono general.

[[Archivo:NewPatternsListaConSeleccion.png|600px]]

En la segunda pestaña se encuentran los campos para poder agregar una señal, Identificador, tamaño, ruta al archivo .patt y como opcional la ruta al archivo .svg que servirá de icono en la paleta.

[[Archivo:NewPattersSegundaPestaña.png|600px]]

En esta pestaña se encuentra el link a la wiki que dice como generar el .patt
En el caso que se quiera poner una identificador de señal que ya exista, la actividad preguntara si se quiere sobrescribir.

=== Manualmente a partir de patrones impresos ===
Se debe generar un archivo de la marca con un recuadro negro. Al comienzo de este artículo pueden verse imágenes de ejemplo. Al imprimirlas, recordar dejar un margen blanco de al menos 1 cm.

Luego de generados los archivos para imprimir, se deberán generar los archivos de patrones.
Para realizar esto:
# Acceder al [[Generador de patrones para plugin Reconocimento de marcas]]
# Seleccionar el origen de donde se generará el patrón. Si se utiliza la cámara, seleccionar ''Camera Mode''. Si se carga la imagen del patrón (incluyendo el recuadro negro) desde un archivo, seleccionar ''Load marker Image''
# Seleccionar tamaño de patrón, por ejemplo, si el patrón (incluyendo el recuadro negro) mide 16x16 cm, seleccionar ''16x16''
# Seleccionar porcentaje del recuadro que representa el patrón. Por ejemplo, si todo el recuadro mide 16cm y el borde negro mide 2cm, el patrón mide 12x12cm, por lo tanto 75%.
# Una vez que se vea un recuadro rojo alrededor de la marca con el rectángulo negro, presionar el botón ''Get Pattern''. Aparecerá un recuadro con los patrones reconocidos, navegar con el botón ''next'' al deseado y presionar ''Save current''. Darle un nombre al archivo en minúsculas, con la extensión '''.patt''', por ejemplo mimarca.patt

En este punto se tiene el archivo .patt generado y como último paso se debe configurar el plugin para poder comenzar a utilizarlo. Para esto:
# Copiar archivo generado (extensión .patt) a la carpeta ''pattern_detection/library/multiPatternDetection/Data/''
# Editar el archivo '''object_data''' en esa misma carpeta:
## Incrementar en 1 el número que aparece al principio (Cantidad de marcas a ser detectados).
## Agregar a continuación en el mismo archivo las líneas correspondientes al patrón, de la siguiente manera:
### Una línea representando el id de la marca
### Línea con el nombre de archivo .patt generado anteriormente
### Línea conteniendo tamaño en milímetros de la marca
### Línea conteniendo 2 decimales, separados por 1 espacio representando el punto medio de la marca.
## Guardar el archivo y cerrar.
# La marca está lista para ser utilizada y aparecerá en la paleta de Tortugarte luego de reiniciar. Por defecto aparecerá un texto con el id de la marca, pero es posible agregar un ícono, generando 1 imagen en formato svg y colocándola en la carpeta '''images/'''. Por ejemplo, para la marca con id '''Stop''' dentro del archivo '''object_data''', se debe generar 2 imágenes, una nombrándola como '''Stop'''small.svg de 40x40px y creando una copia de la misma con el nombre '''Stop'''off.svg pero de 70x70px.

== Trabajos a Futuro ==
* '''Mayor versatilidad para marcas''': El reconocimiento de marcas con ARToolKit facilitó el desarrollo de la solución, ya que al ser utilizado en otras actividades en las terminales XO acortaba el tiempo del proyecto, ya que no se tuvo que hacer un análisis de factibilidad y se tenía la librería ya compilada para los mismos, además que la generación de patrones ya viene resuelta. Sin embargo, al utilizar este API, las marcas están limitadas a una forma cuadrada y que estén contenidas dentro de un recuadro negro. Para poder evitar estas limitantes se sugiere utilizar un API de más bajo nivel como OpenCV para poder reconocer otros tipos de marcas, como por ejemplo, personas, caras, objetos, etc.
* <strike>'''Bloque para obtener distancia a marca''': La librería creada en C actualiza el estado de las marcas cuando detecta la presencia de las mismas. Entre esa información, se encuentra una matriz que tiene la posición de la marca respecto a la cámara. Se sugiere que con esta información se cree un nuevo bloque '''Distancia a la marca''', similar al detectar marca, que reciba como parámetro el id de marca y devuelva la distancia a la marca.</strike>
* <strike> '''Internacionalización''': La paleta desarrollada se realizó en idioma español, pero sería recomendable internacionalizar las etiquetas para que pueda ser localizado a otros idiomas de TurtleArt, por lo menos en inglés.</strike>

Butia reconocimiento marcas

2013-02-19T20:24:14Z

Rsisto: /* Generación de nuevas marcas */

== Integrantes ==
* Nicolás Fúrquez
* Rafael Sisto

== Objetivos ==
* Utilizando [http://www.hitl.washington.edu/artoolkit/ ARToolKit] construir un plugin para Tortugarte/Tortublocks que permita reconocer las marcas. Esto puede ser utilizado para que el robot se localice y navegue en un entorno.

Ejemplos de marcas: 
[[Archivo:StopMark.png|300px]] [[Archivo:YieldMark.png|300px]]

Una de las cosas que nos permite la librería (ARToolKit) es que las marcas no necesariamente tienen que estar en color, permitiendo así imprimirlas en cualquier impresora siempre y cuando se mantenga el tamaño.

== Documentación de la solución ==
Se desarrolló un api que obtiene la información almacenada de las marcas y mediante la ayuda de ARToolKit se detectan las mismas en las capturas de la cámara.

El código fuente e instrucciones de instalación se pueden encontrar en el repositorio utilizado:
[https://github.com/rsisto/multiPatternRecognition multiPatternRecognition]

=== Diagrama de componentes ===
En el siguiente diagrama pueden visualizarse los componentes y su interacción. pattern_detection funciona como plugin de TurtleBlocks, que a su vez utiliza la librería multiPatternDetection (a través de un binding de python a C). Esta última utiliza funciones de ARToolKit para la detección de marcas.

[[Archivo:Arq_pattern_detection.png|400px|Arquitectura de detección de patrones con ARToolKit]]

=== Paleta reconocimiento de marcas ===
Paleta:

[[Archivo:Paleta_reco_marcas.png|700px]]

La paleta posee botones fijos que son:

'''"Viendo Señal"''':Este icono recibe como parámetro un icono de señal (imagen o texto), y nos dice si la cámara lo esta viendo o no.

'''"Distancia Señal"''':Este icono devuelve la distancia trigonométrica desde la cámara hasta el centro de la señal, la magnitud utilizada son mm.

El resto se autogenera leyendo el archivo pattern_detection/library/multiPatternDetection/Data/object_data, en este archivo están todos las marcas que se pueden ver con la paleta, uno de los datos que se ponen dentro es un identificador (nombre) que al iniciarse se lee y luego se busca en la carpeta pattern_detection/images/ si tiene el icono correspondiente, si está pone la imagen como aparece en la paleta, sino lo encuentra generara el icono pero con el texto del nombre. En la sección [[Butia_reconocimiento_marcas]] se puede ver las características de estos iconos.

En este ejemplo se puede ver como se utiliza, en el código de la izquierda si la cámara ve, la señal de curva, moverá 100 la tortuga hacia adelante y luego girara a la derecha un angulo aleatorio entre -30 y 30.
En el ejemplo de la derecha si ve la señal de ''Contramano'' se movera hacia atras y cambiara la pluma a rojo, sino cambiara a azul y se movera 100 hacia adelante

[[Archivo:reconociendo_seniales_Ejemplo.png|700px]]

==== Ejemplos usando la paleta y Butia ====

Usando la marca de ''Pare'', el Butia detiene la marcha.

[[Archivo:ButiaSenialesEjemplo1.png|300px|left]] <videoflash>vF9ZhQYIwVg</videoflash>

 Usando la marca de ''Ceda el paso'', el Butia disminuye la velocidad.

[[Archivo:ButiaSenialesEjemplo2.png|300px|left]]<videoflash>Mbs5GT8vuIM</videoflash>

 Usando la marca de ''Contramano'', el Butia gira hasta no ver la marca y luego sigue adelante.

[[Archivo:ButiaSenialesEjemplo3.png|300px|left]] <videoflash>m04N9YJ7qd4</videoflash>

=== Desafíos y problemas encontrados ===
* La librería ARToolKit requiere la librería libglut.so.3 para funcionar, sin embargo en las XO no es posible instalar la librería en carpetas del sistema. Esto causa que al intentar cargar la librería con C types en python se devuelva el error ''OSError: libglut.so.3: cannot open shared object file: No such file or directory''. Para evitar este problema, se adjunta la librería en la carpeta del plugin y se carga en python previo a cargar la librería de ARToolkit con el siguiente comando: ''cdll.LoadLibrary("lib/libglut.so.3")''.

== Instalación de plugin ==
===Compilar archivos===
Son necesarias los siguientes paquetes debian para poder compilar:
libglib2.0-dev, freeglut3-dev, libgstreamer0.10-dev, libxi-dev

===Ejecución===
Para la ejecución del plugin es necesario instalar el paquete gst-plugins-good.

Si se ejecuta en una máquina configurada en idioma inglés, es necesario substituir "0,0" por "0.0" en el archivo turtle_art_plugin/pattern_recognition/library/multiPatternRecognition/Data/object_data.

===Correr script de prueba===
Opcionalmente, es posible correr pruebas para asegurarse que la detección de marcas está funcionando correctamente.

En la carpeta turtle_art_plugin/pattern_recognition/doc del código butiá, hay un pdf con la marca NotEnter. Imprimir el pdf.

Luego, ejecutar turtle_art_plugin/pattern_recognition/library/apiTestDetectMarkers.py. Al posicionar la marca impresa frente a la cámara, debería imprimirse un número en consola, que representa la distancia a la marca detectada.

== Generación de nuevas marcas ==
Es posible generar nuevas marcas utilizando una actividad creada para ese fin o de forma manual.

=== Actividad para agregar marcas ===

Se creo una actividad por la cual se puede agregar o quitar marcas, de una manera mas amena al usuario (docentes o educandos), se puede descargar la misma desde [http://download.sugarlabs.org/activities/4650/ el sitio de Sugar Labs],
La actividad se puede instalar sin tener el Plugin o Tortugarte/TortuBots, pero al abrirla avisa al usuario que no se encuentra alguno de estos elementos.
En la primer pestaña se puede ver una lista con los identificadores de las señales que están instaladas.

[[Archivo:NewPattersSegundaPestaña.png|600px]]

Si existe un icono asociado se muestra a la derecha al seleccionarlo, si no lo tiene se muestra un icono general.

[[Archivo:NewPatternsListaConSeleccion.png|600px]]

En la segunda pestaña se encuentran los campos para poder agregar una señal, Identificador, tamaño, ruta al archivo .patt y como opcional la ruta al archivo .svg que servirá de icono en la paleta.

[[Archivo:NewPattersSegundaPestaña.png|600px]]

En esta pestaña se encuentra el link a la wiki que dice como generar el .patt
En el caso que se quiera poner una identificador de señal que ya exista, la actividad preguntara si se quiere sobrescribir.

=== Manualmente a partir de patrones impresos ===
Se debe generar un archivo de la marca con un recuadro negro. Al comienzo de este artículo pueden verse imágenes de ejemplo. Al imprimirlas, recordar dejar un margen blanco de al menos 1 cm.

Luego de generados los archivos para imprimir, se deberán generar los archivos de patrones.
Para realizar esto:
# Acceder al [[Generador de patrones para plugin Reconocimento de marcas]]
# Seleccionar el origen de donde se generará el patrón. Si se utiliza la cámara, seleccionar ''Camera Mode''. Si se carga la imagen del patrón (incluyendo el recuadro negro) desde un archivo, seleccionar ''Load marker Image''
# Seleccionar tamaño de patrón, por ejemplo, si el patrón (incluyendo el recuadro negro) mide 16x16 cm, seleccionar ''16x16''
# Seleccionar porcentaje del recuadro que representa el patrón. Por ejemplo, si todo el recuadro mide 16cm y el borde negro mide 2cm, el patrón mide 12x12cm, por lo tanto 75%.
# Una vez que se vea un recuadro rojo alrededor de la marca con el rectángulo negro, presionar el botón ''Get Pattern''. Aparecerá un recuadro con los patrones reconocidos, navegar con el botón ''next'' al deseado y presionar ''Save current''. Darle un nombre al archivo en minúsculas, con la extensión '''.patt''', por ejemplo mimarca.patt

En este punto se tiene el archivo .patt generado y como último paso se debe configurar el plugin para poder comenzar a utilizarlo. Para esto:
# Copiar archivo generado (extensión .patt) a la carpeta ''pattern_detection/library/multiPatternDetection/Data/''
# Editar el archivo '''object_data''' en esa misma carpeta:
## Incrementar en 1 el número que aparece al principio (Cantidad de marcas a ser detectados).
## Agregar a continuación en el mismo archivo las líneas correspondientes al patrón, de la siguiente manera:
### Una línea representando el id de la marca
### Línea con el nombre de archivo .patt generado anteriormente
### Línea conteniendo tamaño en milímetros de la marca
### Línea conteniendo 2 decimales, separados por 1 espacio representando el punto medio de la marca.
## Guardar el archivo y cerrar.
# La marca está lista para ser utilizada y aparecerá en la paleta de Tortugarte luego de reiniciar. Por defecto aparecerá un texto con el id de la marca, pero es posible agregar un ícono, generando 1 imagen en formato svg y colocándola en la carpeta '''images/'''. Por ejemplo, para la marca con id '''Stop''' dentro del archivo '''object_data''', se debe generar 2 imágenes, una nombrándola como '''Stop'''small.svg de 40x40px y creando una copia de la misma con el nombre '''Stop'''off.svg pero de 70x70px.

== Trabajos a Futuro ==
* '''Mayor versatilidad para marcas''': El reconocimiento de marcas con ARToolKit facilitó el desarrollo de la solución, ya que al ser utilizado en otras actividades en las terminales XO acortaba el tiempo del proyecto, ya que no se tuvo que hacer un análisis de factibilidad y se tenía la librería ya compilada para los mismos, además que la generación de patrones ya viene resuelta. Sin embargo, al utilizar este API, las marcas están limitadas a una forma cuadrada y que estén contenidas dentro de un recuadro negro. Para poder evitar estas limitantes se sugiere utilizar un API de más bajo nivel como OpenCV para poder reconocer otros tipos de marcas, como por ejemplo, personas, caras, objetos, etc.
* <strike>'''Bloque para obtener distancia a marca''': La librería creada en C actualiza el estado de las marcas cuando detecta la presencia de las mismas. Entre esa información, se encuentra una matriz que tiene la posición de la marca respecto a la cámara. Se sugiere que con esta información se cree un nuevo bloque '''Distancia a la marca''', similar al detectar marca, que reciba como parámetro el id de marca y devuelva la distancia a la marca.</strike>
* <strike> '''Internacionalización''': La paleta desarrollada se realizó en idioma español, pero sería recomendable internacionalizar las etiquetas para que pueda ser localizado a otros idiomas de TurtleArt, por lo menos en inglés.</strike>

Butia reconocimiento marcas

2013-02-19T20:18:48Z

Rsisto: /* Actividad para agregar marcas */

== Integrantes ==
* Nicolás Fúrquez
* Rafael Sisto

== Objetivos ==
* Utilizando [http://www.hitl.washington.edu/artoolkit/ ARToolKit] construir un plugin para Tortugarte/Tortublocks que permita reconocer las marcas. Esto puede ser utilizado para que el robot se localice y navegue en un entorno.

Ejemplos de marcas: 
[[Archivo:StopMark.png|300px]] [[Archivo:YieldMark.png|300px]]

Una de las cosas que nos permite la librería (ARToolKit) es que las marcas no necesariamente tienen que estar en color, permitiendo así imprimirlas en cualquier impresora siempre y cuando se mantenga el tamaño.

== Documentación de la solución ==
Se desarrolló un api que obtiene la información almacenada de las marcas y mediante la ayuda de ARToolKit se detectan las mismas en las capturas de la cámara.

El código fuente e instrucciones de instalación se pueden encontrar en el repositorio utilizado:
[https://github.com/rsisto/multiPatternRecognition multiPatternRecognition]

=== Diagrama de componentes ===
En el siguiente diagrama pueden visualizarse los componentes y su interacción. pattern_detection funciona como plugin de TurtleBlocks, que a su vez utiliza la librería multiPatternDetection (a través de un binding de python a C). Esta última utiliza funciones de ARToolKit para la detección de marcas.

[[Archivo:Arq_pattern_detection.png|400px|Arquitectura de detección de patrones con ARToolKit]]

=== Paleta reconocimiento de marcas ===
Paleta:

[[Archivo:Paleta_reco_marcas.png|700px]]

La paleta posee botones fijos que son:

'''"Viendo Señal"''':Este icono recibe como parámetro un icono de señal (imagen o texto), y nos dice si la cámara lo esta viendo o no.

'''"Distancia Señal"''':Este icono devuelve la distancia trigonométrica desde la cámara hasta el centro de la señal, la magnitud utilizada son mm.

El resto se autogenera leyendo el archivo pattern_detection/library/multiPatternDetection/Data/object_data, en este archivo están todos las marcas que se pueden ver con la paleta, uno de los datos que se ponen dentro es un identificador (nombre) que al iniciarse se lee y luego se busca en la carpeta pattern_detection/images/ si tiene el icono correspondiente, si está pone la imagen como aparece en la paleta, sino lo encuentra generara el icono pero con el texto del nombre. En la sección [[Butia_reconocimiento_marcas]] se puede ver las características de estos iconos.

En este ejemplo se puede ver como se utiliza, en el código de la izquierda si la cámara ve, la señal de curva, moverá 100 la tortuga hacia adelante y luego girara a la derecha un angulo aleatorio entre -30 y 30.
En el ejemplo de la derecha si ve la señal de ''Contramano'' se movera hacia atras y cambiara la pluma a rojo, sino cambiara a azul y se movera 100 hacia adelante

[[Archivo:reconociendo_seniales_Ejemplo.png|700px]]

==== Ejemplos usando la paleta y Butia ====

Usando la marca de ''Pare'', el Butia detiene la marcha.

[[Archivo:ButiaSenialesEjemplo1.png|300px|left]] <videoflash>vF9ZhQYIwVg</videoflash>

 Usando la marca de ''Ceda el paso'', el Butia disminuye la velocidad.

[[Archivo:ButiaSenialesEjemplo2.png|300px|left]]<videoflash>Mbs5GT8vuIM</videoflash>

 Usando la marca de ''Contramano'', el Butia gira hasta no ver la marca y luego sigue adelante.

[[Archivo:ButiaSenialesEjemplo3.png|300px|left]] <videoflash>m04N9YJ7qd4</videoflash>

=== Desafíos y problemas encontrados ===
* La librería ARToolKit requiere la librería libglut.so.3 para funcionar, sin embargo en las XO no es posible instalar la librería en carpetas del sistema. Esto causa que al intentar cargar la librería con C types en python se devuelva el error ''OSError: libglut.so.3: cannot open shared object file: No such file or directory''. Para evitar este problema, se adjunta la librería en la carpeta del plugin y se carga en python previo a cargar la librería de ARToolkit con el siguiente comando: ''cdll.LoadLibrary("lib/libglut.so.3")''.

== Instalación de plugin ==
===Compilar archivos===
Son necesarias los siguientes paquetes debian para poder compilar:
libglib2.0-dev, freeglut3-dev, libgstreamer0.10-dev, libxi-dev

===Ejecución===
Para la ejecución del plugin es necesario instalar el paquete gst-plugins-good.

Si se ejecuta en una máquina configurada en idioma inglés, es necesario substituir "0,0" por "0.0" en el archivo turtle_art_plugin/pattern_recognition/library/multiPatternRecognition/Data/object_data.

===Correr script de prueba===
Opcionalmente, es posible correr pruebas para asegurarse que la detección de marcas está funcionando correctamente.

En la carpeta turtle_art_plugin/pattern_recognition/doc del código butiá, hay un pdf con la marca NotEnter. Imprimir el pdf.

Luego, ejecutar turtle_art_plugin/pattern_recognition/library/apiTestDetectMarkers.py. Al posicionar la marca impresa frente a la cámara, debería imprimirse un número en consola, que representa la distancia a la marca detectada.

== Generación de nuevas marcas ==
TODO: Generación de pdf con marca para imprimir.

Luego de generados los archivos para imprimir, se deberán generar los archivos de patrones.
Para realizar esto:
# Acceder al [[Generador de patrones para plugin Reconocimento de marcas]]
# Seleccionar el origen de donde se generará el patrón. Si se utiliza la cámara, seleccionar ''Camera Mode''. Si se carga la imagen del patrón (incluyendo el recuadro negro) desde un archivo, seleccionar ''Load marker Image''
# Seleccionar tamaño de patrón, por ejemplo, si el patrón (incluyendo el recuadro negro) mide 16x16 cm, seleccionar ''16x16''
# Seleccionar porcentaje del recuadro que representa el patrón. Por ejemplo, si todo el recuadro mide 16cm y el borde negro mide 2cm, el patrón mide 12x12cm, por lo tanto 75%.
# Una vez que se vea un recuadro rojo alrededor de la marca con el rectángulo negro, presionar el botón ''Get Pattern''. Aparecerá un recuadro con los patrones reconocidos, navegar con el botón ''next'' al deseado y presionar ''Save current''. Darle un nombre al archivo en minúsculas, con la extensión '''.patt''', por ejemplo mimarca.patt

En este punto se tiene el archivo .patt generado y como último paso se debe configurar el plugin para poder comenzar a utilizarlo. Para esto:
# Copiar archivo generado (extensión .patt) a la carpeta ''pattern_detection/library/multiPatternDetection/Data/''
# Editar el archivo '''object_data''' en esa misma carpeta:
## Incrementar en 1 el número que aparece al principio (Cantidad de marcas a ser detectados).
## Agregar a continuación en el mismo archivo las líneas correspondientes al patrón, de la siguiente manera:
### Una línea representando el id de la marca
### Línea con el nombre de archivo .patt generado anteriormente
### Línea conteniendo tamaño en milímetros de la marca
### Línea conteniendo 2 decimales, separados por 1 espacio representando el punto medio de la marca.
## Guardar el archivo y cerrar.
# La marca está lista para ser utilizada y aparecerá en la paleta de Tortugarte luego de reiniciar. Por defecto aparecerá un texto con el id de la marca, pero es posible agregar un ícono, generando 1 imagen en formato svg y colocándola en la carpeta '''images/'''. Por ejemplo, para la marca con id '''Stop''' dentro del archivo '''object_data''', se debe generar 2 imágenes, una nombrándola como '''Stop'''small.svg de 40x40px y creando una copia de la misma con el nombre '''Stop'''off.svg pero de 70x70px.

=== Actividad para agregar marcas ===

Se creo una actividad por la cual se puede agregar o quitar marcas, de una manera mas amena al usuario (docentes o educandos), se puede descargar la misma desde [http://download.sugarlabs.org/activities/4650/ el sitio de Sugar Labs],
La actividad se puede instalar sin tener el Plugin o Tortugarte/TortuBots, pero al abrirla avisa al usuario que no se encuentra alguno de estos elementos.
En la primer pestaña se puede ver una lista con los identificadores de las señales que están instaladas.

[[Archivo:NewPattersSegundaPestaña.png|600px]]

Si existe un icono asociado se muestra a la derecha al seleccionarlo, si no lo tiene se muestra un icono general.

[[Archivo:NewPatternsListaConSeleccion.png|600px]]

En la segunda pestaña se encuentran los campos para poder agregar una señal, Identificador, tamaño, ruta al archivo .patt y como opcional la ruta al archivo .svg que servirá de icono en la paleta.

[[Archivo:NewPattersSegundaPestaña.png|600px]]

En esta pestaña se encuentra el link a la wiki que dice como generar el .patt
En el caso que se quiera poner una identificador de señal que ya exista, la actividad preguntara si se quiere sobrescribir.

== Trabajos a Futuro ==
* '''Mayor versatilidad para marcas''': El reconocimiento de marcas con ARToolKit facilitó el desarrollo de la solución, ya que al ser utilizado en otras actividades en las terminales XO acortaba el tiempo del proyecto, ya que no se tuvo que hacer un análisis de factibilidad y se tenía la librería ya compilada para los mismos, además que la generación de patrones ya viene resuelta. Sin embargo, al utilizar este API, las marcas están limitadas a una forma cuadrada y que estén contenidas dentro de un recuadro negro. Para poder evitar estas limitantes se sugiere utilizar un API de más bajo nivel como OpenCV para poder reconocer otros tipos de marcas, como por ejemplo, personas, caras, objetos, etc.
* <strike>'''Bloque para obtener distancia a marca''': La librería creada en C actualiza el estado de las marcas cuando detecta la presencia de las mismas. Entre esa información, se encuentra una matriz que tiene la posición de la marca respecto a la cámara. Se sugiere que con esta información se cree un nuevo bloque '''Distancia a la marca''', similar al detectar marca, que reciba como parámetro el id de marca y devuelva la distancia a la marca.</strike>
* <strike> '''Internacionalización''': La paleta desarrollada se realizó en idioma español, pero sería recomendable internacionalizar las etiquetas para que pueda ser localizado a otros idiomas de TurtleArt, por lo menos en inglés.</strike>

Mecánica Butiá V1.8

2013-02-19T00:01:45Z

Rsisto: Mecanica trasladada a Mecánica Butiá V1.8: Se respalda para crear página de versión 2.0

Mecanica

2013-02-19T00:01:45Z

Rsisto: Mecanica trasladada a Mecánica Butiá V1.8: Se respalda para crear página de versión 2.0

#REDIRECCIÓN [[Mecánica Butiá V1.8]]

Actas Reuniones Butia

2013-02-14T11:39:00Z

Rsisto: /* Participantes */

== 7/02/2013 ==

====Participantes====
Alan, Pablo, Andres, John, Faivel, Humberto, Guille, Enrique, Javier, Rafael, Nicolás, Edgardo, Mario, Lucio

====minutas====
Empieza reunión a las 18:50

====Mecánica====
* Se está preparando versión de acrílicos final de Butiá SAM.

====Software====
* Bloque nuevo de casteo para adaptar el valor del sensor a un rango conocido, y los bloques de usurio a bloques conocido. En paleta extra, agrega un bloque nuevo.
** Problema: que pasa cuando se levanta devuelta el archivo, despues de reiniciar el programa? Hay que probar
* Bloque módulo user 1,2,3
* Bloque python de tortuga no funciona, no almacena el código, si no referencia al archivo. Corregir (Walter?)

====Firmware y Hardware====
* Es complicado agregar un nuevo módulo de firmware, por más que sea parecido a los anteriores.
** Agregar módulo genérico, al instanciarlo por sw, pasarle parametro el rango de identificación. (Descartado por la siguiente opción)
** Agregar módulos de usuario en fw, que sean genéricos, permitiendo así compartir el sensor con otras placas. Mantiene estructura actual de firmware. Cuando se instancia se define si es digital o análogo. Se genera un alias al instanciar en código. Tiene metodo getValue y setValue.
* Puente H, se le va a poner un micro, se está trabajando
** Generar entrada en wiki para discutir como conectar motores (placa con cantidad variable de motores, 2 motores, etc)
** El h-bridge diseñado va a permitir conectar a los hack-points o al puerto.
** Módulo usando un pin de los puertos y 2 hack-points
** Módulo utilizando un puerto con 2 pines de datos.
* Implementar módulo de PWM

== 31/01/2013 ==

====Participantes====
Alan, Pablo, Andres, John, Faivel, Humberto, Guille, Enrique, Javier

====minutas====
Empieza reunión a las 18:09

====Mecánica====
*Se realizo la prueba de colocar la rueda en el eje del motor con un prisionero directo a la rueda y dio muy buen resultado. De momento parece ser la mejor idea y queda muy prolijo.
*Se le agrego los agujeros para trasladar la placa chica de acrílico para dejar espacio para los motores de continua
*Se le agrega una ficha butia para ensamblar los motores al butia
*Parece que con esa modificación el puerto USB de la placa queda muy cerca de la rueda loca y queda tocando con el cable USB.
** Se discutio si se rota 180 la placa USB4butia quedando el USB hacia la otra direccion y los 4 conectores para sensores hacia la rueda, igual va a tocar con la rueda pero los cables de los sensores son mas flexibles y el conector no sobresale tanto o también lo de rotar todo el modulo que contiene placa, pilas y chasis chico de acrilico 180 o Intercambiar la placa con las pilas. Se decidio intercambiar la placa con las pilas.
*Se discutió sobre simetrizar los agujeros para amurar de la placa, pero se decidió que no porque pierde compatibilidad con los butias anteriores
* Se probo colocarle una rueda con el sistema del prisionero al motor de DX, el sistema de la ficha no es compatible con este pues tienen diametros distintos, se quiere llegar a una ficha mas universal por lo que se discutieron varias ideas sobre eso, quedamos en que se va a seguir investigando.
*Se dise;o el topecito para la parte de enfre con el logo de butia

====Firmware y Hardware====
*Se siguieron plantenado ideas sobre la USB4butia avanzada y lo de usar otro micro. Se va a seguir investigando
*Se planteo un idea de usar un circuito analogico con 3 estados para conectar los motores directamente a los puertos de la USB4butia

== 24/01/2013 ==

====Participantes====
Alan, Rodrigo, Pablo, Jorge, Andres, Daniel, John, Rafael, Aylen, Fiorella, Faivel, Guille, Humberto

====minutas====
Empieza reunión a las 18:26

====Mecánica====
*Se trajeron las piezas de formacril, se probaron las dos alternativas de barandas y se discutio. Se decidio que la mejor alternativa de barandas cortas con topes es mejor, pues muestra mas robustez frente a la de baranda larga y el laptop queda mas estable.
** El tope serian dos piezas universales butia, (No esta bueno que estas piezas sean de tope)
** Se decidio que el largo ideal de los tornillos para las piezas es de 4 x 0.7 de 20 mm.
*Motores: Se hizo una prueba con un prisionero y dio muy buen resultado.
*colocar el prisionero en la rueda directamente?

====Firmware====
*Seguir investigando sobre los micros buscar uno micro que sea Economico, Mercado Local, Chico y se pueda hacer PWM.
*Replantearse la idea de implementar serial por sofware y la de pwm.

====Hardware====
*Se resolvió quitar el Cristal de 32.768 que libera dos pines en la placa de los cuales uno es el PWM que se buscaba obtener
*El botón de bootloader permanece en la placa
*Colocar 2 puertos en la USB4butia compatibles con el el conector de los servos para los PWM.
*USB4butia simple y utilizar los hackpoints para controlar opción estable.
*Se hablo de hacer una placa usb4butia avanzada en dos capas y se planteo la interrogante de que es mejor: Si hacer la placa usb4butia doble capa avanzada con mas pines de datos y quizás con potencia, o mantenes la usb4butia con una capa agragando un modulo motor con otro microcontrolador.
*Crear una whish lista sobre la USB4butia

== 17/01/2013 ==

====Participantes====
Alan, Rodrigo, Pablo, Jorge, Andres, Daniel, John, Rafael

====minutas====
Empieza reunion a las 18:26

====Mecánica====
* se habló del módulo motor y la elección del pic, parece que utilizar
el micro con menos prestaciones es la opción más adecuada.
* como colocar los motores de CC : correa/directo
** se decidió que ya que tenemos motores con un buen par, no tiene
mucho sentido tener una correa.
** Surge el tema de donde colocar los motores para que siga siendo
ax12 y CC compatible, una opción para no cambiar las distribuciones
actuales es colocar los motores de CC atrás y permitir cambiar de
lugar la rueda loca para el lado opuesto al que está ahora. Hay que
tener ojo de que no obstaculice la conexión de puertos actual lo cual
es el problema que tiene ahora.
** Otro tema es como amurar la rueda a los motores, el motor que
compramos es de eje cilíndirco, hay otros con un perfil lo cual
permite que se pueda diseñar una rueda con un prisionero. Otra opción
es perforar el eje del motor y ponerle una espina para amurar la
rueda.

====Hardware====
*resolver que hacer con PWM: hackpoints, puertos
** PWM, mantener por hackpoint y generar módulo de firmware para PWM
por software utilizando Timer1 (inteligente, interrumpir solo cuando
es necesario).
** Generar informe con opciones de mantener o quitar botón de programación
* Módulo GPIO: no es equivalente al resistencia? Aporta algo?
** Evaluar quitar módulo port (porque no aporta nada)
** Evaluar agregar módulo de GPIO, permite por lo menos avisar al
usuario que está realizando una acción que puede dañar el equipo.
* Gadgets de sensore en DX, que hacer, definir ids o usar módulo
lector de voltaje, en general utilizar el de voltaje
** Crear módulos de temperatura y magnético, para laboratorios de física.
* chequear si el sensor de campo mag es analogico o digi

== 10/01/2013 ==

====Participantes====
Guillermo, Alan, , Fiorella, Pablo, Jorge, Andres, Faviel, John

====minutas====
Empieza reunion a las 18:26

====Documentación====
*Sensores de resistencia y voltage (John y Guille)
*Sensor de flexión ya esta documentado por Enrique

====Mecánica====
*Se estan haciendo los acrílicos en formacril, fecha aproximada 24
*Módulo motor hecho con carcasa de linterna utilizando una ficha butia, carcasa de un enchufe, arrancador de tubo y zunchos.
**Se discutio sobre utilizarlo con una correa o adicionarle una rueda, se decidio adicionarle la rueda y colocar el modulo en el lugar actual de las ruedas, manteniendo la estructura de los AX12, incorporándolo al butia por fuera. (Butia PUNK)
*Se habló de hacer un banco de prueba de motores para obtener datos útiles como el par, rpm , etc ...
*Se probaron los tornillos de plástico y dan buen resultado ya que protege el acrílico, son mas fácil de enroscar, mas amigables para los niños

====Hardware====
*Se discutió sobre los cambios de la USB4butia, estudiar lo de hacer una USB4butia solo para controlar motores y evaluar Modulito con microcontrolador propio para manejar motores, PIC16F628A buscar compilador GNU, buscar otro PIC de 8 patas
*Evaluar de quitar el clock de 37 khz y utilizar el pin 16 que es el CCP2 y asi evitar de quitar el boton de programacion
*Se hablo sobre sacar el boton de programacion, se decidio quitarlo y cambiar el bootloader y agregar dos puertos pwm (Si es necesario)
*Se discutió lo de quitar el bus AX12, se decidió que no porque permite agregar motores con control más complejo de forma fácil.
*Sacar los pines de programación ... ?

====Software====
*Serial por software (si se va hacer el modulo motor con pic propio)

== 03/01/2013 ==
====Participantes====
Rafa, Pablo, Pancho, Jorge, John

====Mecánica====
*Se dibujaron barandas nuevas con el tope , y se hicieron prototipos en goma eva para presentar en el butiá. Se presentó junto a la magallanes. Se discutió y se decidió hacer las barandas un poco más altas. Diseñar y construir 2 juegos de barandas: unas más largas con tope flotando y otras más cortas sin tope.
*Se mostró la nueva rueda butiá con agujero en el medio
*Se habló del modulo motor se agregan dos piezas de acrílico para mantener la estructura de los AX12 y no tener que hacer un butia distinto para la versión con otros motores. Hay dos opciones, una posee lengüetas como los AX12 y van en el mismo lugar con las ranuras existentes para los AX12 y la otra serían las fichas universales con el sistema de encastre butia.
*Estudiar agujeros para "ensanguchar" las dos planchas de acrílicos, agregar un tornillo más alineado con los que ya están con la medida de los AX12
*Se acomodó la ojiva del encastre butiá centrándola para que quede un poquito mas separdo de los rectángulos
*Se le agrega al logo la palabra SAM
*Ejemplo de logos para autoadhesivos
*Se van hacer arcilicos y autoadhesivos.
*Se va a probar el logo calado otra vez

== 27/12/2012 ==

====Participantes====
Daniel, Guillermo, Alan John, Fiorella, Aylen, Rodrigo, Enrique, Rafael, Pablo

====minutas====
* Empieza reunion a las 18:41

====Hardware====
* Acrílico había quedado mal grabado el logo la última vez, quedó una línea entrecortada.
** Se va a pedir devuelta con los logos bien grabados. Pablo trae planos el 3 de enero. Al pedir los nuevos acrílicos preguntar opciones de:
*** Pintar logos luego de grabarlos
*** Mejorar calidad del grabado para que no queden manchados.
*** Incrementar ancho de línea para que queden mejor marcados los logos.
** Pablo va a mandar a hacer pegotines calados de logos para manejar otra alternativa
** Se discute si poner nombre 2.0 o "sam". Mayoría eligió Sam (2 en charrúa)

====Motores====
* Se vio prototipo con motores de cargadores USB a dínamo, utilizando hack points.

====Software====
* Salió paquete de TortuBots v18, faltan paquetes Debian actualizar changelog (Aylen)
* Alan corrigió bug de memory leak de TortuBots, ahora no se bloquea en la XO. Está probado.
* PyBot (librería python para acceder a placa butiá) está casi listo, falta testear.
* Validación al tratar de grabar o escribir en hackpoint configurado para entrada o salida respectivamente. Hacerlo en api y agregarlo a TortuBots cuando trata de hacer una operación incorrecta. (Alan)

====Firmware====
* Módulo de Firmware de hackpoint no tiene que cambiar el modo del pin (Aylen)

== 10/12/2012 ==
====Participantes====

John, Aylen, Pablo, Gonzalo, Guillermo, Andrés, Diego, Rafael, Luis, Rodrigo, Marcelo

====minutas====
* Empieza reunion a las 19:50

====Hardware====
* Falta documentar prototipo con motores de linternas (Pancho)
* Piezas para anexar sensores: Pablo muestra 3 piezas, genérica de 2 lados, de 1 lado y una cortita.
** También se hizo pieza para reemplazar motores AX12.
** Se llega a un acuerdo de como tienen que ser las placas de sensores
* Se decide cambiar las piezas por piezas únicas para armado y reemplazo de AX12.
* Barandas, se van a cambiar por unas que empiezan finitas en la parte frontal y terminan gruesas en la parte trasera como guardabarros. En la parte delantera, tienen tope para aguantar una laptop.

====Motores====
* Motores "argentinos" no tienen certificado de origen (motor chino, engranajes argentinos)
* Guille va a mandar un mail a Fede para que averigüe en Brasil por alternativas de motores CC.
* Rodrigo, Gonzalo, van a armar prototipo con motores de cargadores USB a dínamo.

== 3/12/2012 ==
====Participantes====

John, Aylen, Pablo, Gonzalo, Guillermo, Francisco, Andrés, Daniel, Rafael, Alan, Luis

====minutas====
* Empieza reunion a las 19:30

====Hardware====
* Hay que definir los componentes para construir una serie de robots, de la mano de Antel (esperando h-bridge)
** Definir que motores de CC usar, de AP&S, modelo SP6-50, similar a AX12 ($80 argentinos), faltan definir los de Ignis (MR83-100, con pocas revoluciones y poco par), Pablo trae 2 de cada uno para probar.
* Ida a Triex sugerida por Daniel. Hay varios interesados, coordinar por mail.
* John, Andrés, definiendo USB4Motores, placa USB4All genérica, con H-bridge integrado.

====Motores====
* Motor de linterna recargable, funciona bien, Gonzalo va a comprar lintenrnas para armar un Butiá.
* Documentación de alternativas de motores: Daniel, Pablo y Francisco (documentar motores descartados - Daniel, motores de linternas recargables, Soportes Discos duros y contra chata. Motores a usar) Rafa va a mandar link de como crear usuario y stub de documento.
* Edgardo está armando el H-Bridge para controlar motores (Edgardo está armando)
* Se vieron acrílicos con logo

====firmware====
* Se solucionó problema en firmware (se estaba usando memoria inexistente)
* Andrés, Aylen, John: Trabajando en Módulo PWM por software en firmware.
* John - Falta módulo GPIO

====Sensores====
* Guille, John - Documentar en wiki como crear sensores nuevos.
* Gonzalo, mirando como funciona sensor de color.

====Software====
* Alan está escribiendo API en Python para Butia, falta contemplar varias placas USB
* Firmware update activity , está pronta la actividad 90%
* Andrés - Actualizar butialo a 2.0 (no dio el tiempo)

====Organización====
* Andrés comenta sugerencias del sumo.uy
** Agregar agujeros para tornillos
** Quejas de sensor de distancia, no se puede enganchar
** Robot Butiá triangular - Omni

== 26/11/2012 ==
====Participantes====
Luis, Marcelo, Guillermo R., Pablo Margenat, Gonzalo, Rafael Sisto, Andrés Aguirre, Aylen, Enrique, Diego, Martín , John, Javier, Alan, Fiorella

====minutas====
* Empieza reunion a las 19:30

====Hardware====
* Hay que definir los componentes para construir una serie de robots
** Definir que motores de CC usar (Quién va a definir esto?)
* Ida a Triex sugerida por Daniel. Hay varios interesados, coordinar por mail.

====Motores====
* Comisión continua Falta probar con mosfets (esperando módulo PWM de firmware)
** Cambiar circuito de muestra buscando mosfets de menor amperaje (Diego)
* Soportes de motores
** Acrílico (prontos para el 29/11), demo para 3/12
** Pancho y Pablo: cortando chasis de disco, pensando alternativas.
** Transmisión, se propone probar goma en el motor y goma en la rueda, en vez de una correa.
* Alternativas de motores:
** Linternas con generadores, se pueden usar como motores (menos de $200 en supermercados), hay que escribir en la wiki
** Andrés, Enrique - Consultar a Eneka por motores de continua hechos en Argentina (cerca de $700), modelo MR4-100, ver si tiene suficiente torque.

====firmware====
* Andrés, Aylen: Módulo PWM por software en firmware.
** (Andrés, Micho) Falta solucionar bug extraño cuando hay muchos módulos (posiblemente una asignación errónea de memoria), probar con Ida.
* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.(Se puede hacer)
** Faltan módulos GPIO y LED (Prontos, falta corregir bug).
* Pendiente Andrés - Liberar motores cuando se le mande orden velocidad cero.

====Sensores====

* Fibra óptica, se puede conseguir en Tilsit (6 metros con terminales, aprox U$ 35). Daniel va conseguir una nueva muestra actual para probar.
** Se consigue en el Clon por $65 una lámpara decorativa
** Luego de tener fibra, segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Sensores de efecto Hall (No se trató )
** Propuesta de Diego: sensor de imanes utilizando una bobina y con pin analógico.(No se trató )

====Software====

* Alan: bloque para configurar hack points, pronto, falta configurar como entrada.
* Bloque LED está.
* Alan, falta bloque GPIO
* Alan está escribiendo API en Python para Butia (falta testear, branch pybot)
* Guille, haciendo paquete Debian (armado makefile estilo GNU)
* Rodrigo, el tortuga tiene un uso excesivo de CPU (hay que ver si es nuestro o de walter) cuando se usan muchos bloques. Reproducir problema. (No se habló)
* Firmware update activity , está pronta la actividad 90%
* Andrés - Actualizar butialo a 2.0

== 19/11/2012 ==
====Participantes====
Guillermo R., Pablo Margenat, Rafael Sisto, Andrés Aguirre, Alan Aguiar , Rodrigo, Aylen, Gonzalo, Enrique, Diego

====minutas====
* Empieza reunion a las 19:30

====Motores====

* Comisión continua Falta probar con mosfets (esperando módulo PWM de firmware)
** Cambiar circuito de muestra buscando mosfets de menor amperaje (Diego)
* Soportes de motores
** Se hizo modelo, está pedido el acrílico (prontos para el 29/11), demo para 3/12
** Pancho y Pablo: cortando chasis de disco
* Buscar alternativas de motores:
** lectoras de CD, disketeras, discos duros (Diego está consiguiendo con Integra)
** Andrés está consultando en Eneka por motores de continua hechos en Argentina (cerca de $700), serían similares a los secadores de pelo, pero con reducción.
* Comision PaP - Se sigue trabajando para un prototipo, se propone controlar con circuito casero.

====firmware====

* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.
* Andrés - Liberar motores cuando se le mande orden velocidad cero.
* Andrés, Aylen: Módulo PWM por software en firmware.
* Andrés: Notificar placa como dispositivo serial al PC (avanzando).

====Sensores====

* Fibra óptica, se puede conseguir en Tilsit (6 metros con terminales, aprox U$ 35). Daniel va conseguir una nueva muestra actual para probar.
* Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Sensores de efecto Hall
** Propuesta de Diego: sensor de imanes utilizando una bobina y con pin analógico.

====Software====
* Alan: bloque para configurar hack points.
* Tortubots, tema pendiente: Generar un evento a los plugins cuando finalice la ejecución de los bloques (por ejemplo, para liberar cámara, parar motores, etc).
* Migración TurtleBlocks a android, falta librería GTK, trancado por ese tema
* Alan está escribiendo un API en python con funcionalidad similar a bobot (ventaja: no requiere lua ni dependencias de binarios adicionales, para arm no requeriría link a binarios extra, no requiere comunicación por sockets.)
* normalizar velocidades de 0 a 100. Se descarta porque no hay un problema concreto en que pueda beneficiar. En principio sirve para buscar la curiosidad de los alumnos.
* Separar paleta, ya está.
* Guille, haciendo paquete Debian.
* Rodrigo, el tortuga tiene un uso excesivo de CPU (hay que ver si es nuestro o de walter) cuando se usan muchos bloques. Reproducir problema.
* Guille, Aylen: Firmware update activity
** Actividad con un botón para actualizar (Rodrigo)

====Documentación====
* Rafael: Revisar documentación de entregables a Antel

====Resumen de Comisiones====
Soportes de motores: Pablo y Francisco

motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 12/11/2012 ==
====Participantes====
Guillermo Reisch, Diego, Daniel, John Pereira, Pablo Margenat, Rafael Sisto, Francisco Puignau, Andrés Aguirre, Martín Giachino, Alan Aguiar

====minutas====
* Empieza reunion a las 19:30

====Motores====
* Comisión continua - trajo demo con motores distintos y quedó bien el seguidoor de líneas.
** Falta probar con mosfets
* Soportes de motores
** Falta soporte para gomitas, propuesta de hacer 2 ruedas de acrílico más chicas para sostener.
** Falta soporte para rueda,
*** Proponen utilizar el mismo plato del soporte de gomitas, eje con rulemanes
*** Otra alternativa, usar motor de disco duro como rulemán (módulo independiente). (Guillermo va a traer discos duros para desarmar)
** Buscar alternativas de motores: secador de pelo (12v), lectoras de CD, disketeras
* Comision PaP - utilizar motor de impresora con driver. (para lunes 19/11)

====firmware====

* módulo firmware para bus pines digitales pronto, PWM se va a manejar por software
* firmware para sensor de voltaje pronto
* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.
* Andrés, Aylen: Módulo PWM por software en firmware.
* Andrés: Notificar placa como dispositivo serial al PC.

====Sensores====

* Demo de Módulo voltaje y resistencia
** Algunos detalles por corregir
* Fibra óptica, Daniel va a conseguir una muestra para el lunes siguiente
* (no se habló) Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises

====Software====

* Se creó bloque de sensor de voltaje
* Separar paleta, normalizar velocidades de 0 a 100 (Alan)
* Alan, el tortuga tiene un memory Leak (hay que ver si es nuestro o de walter) cuando se usan muchos bloques
* Alan, quitar compatibilidad para V1
* Guille, Aylen: Firmware update activity - postergado para próxima reunión.

====Resumen de Comisiones====
Soportes de motores: Pablo y Francisco

motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 05/11/2012 ==
====Participantes====
Gonzalo Tejera, Guillermo Reisch, Enrique Madruga, Daniel Cancela, John Pereira, Pablo Margenat, Rafael Sisto.

====minutas====
* Empieza reunion a las 19:30
* resumen, software/hardware/mecanica etc...

====Motores====
* Enrique averiguó motores alza-cristales: son caros (cerca de los $ 1000)
* Daniel mandó mail a SEMPRE, va a relevar que tipo de motores (otra chatarra) se pueden conseguir
* Comisión continua - va a avanzar con el módulo de relés
* Comisión continua - motores de secador de pelo (12v), lectoras de CD, disketeras
* Comisión continua - Preguntar a "Lechuga" qué motores usaron
* Comision PaP - utilizar motor de impresora con driver. (para lunes 19/11)
* Reducciones - 2 alternativas, correas o engranajes impresos.

====firmware====

* Aylen, agregar módulo firmware para bus pines digitales y PWM (pin 17). Si puede estar para esta semana, mejor.
* John - Otra alternativa para manejar motores, utilizar el puerto ax12 y un pic conversor a otro tipo de motores.
* Aylen - falta firmware para sensor de voltaje (estaría pronto)

====Sensores====
* sensor distancia auto chino - Enrique consultó en comercio electrónico y superan los $1000, seguir consultando alternativas.
* Fibra óptica, intentar utilizar fibra óptica de cotillón (adornos de colores)
** Daniel para el lunes se comprometió en traer un par de tramos (quizás se consigue en SEMPRE)
** Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Módulo voltaje y resistencia (demo lunes 12)
** Se decidió utilizar jumper en vez de switch
** Se creó módulo en kicad
* Firmware update activity (trabajando...)

====Software====
* Alan, crear bloque de sensor de voltaje
* Alan, hablar con Andrés y Rodrigo - El tortuga tiene un memory Leak (hay que ver si es nuestro o de walter) cuando se usan muchos bloques

====Hardware====
* Chata va a comenzar a llevar logo de Antel

====Gestión====
* Intentar convertir las reuniones en talleres

====Resumen de Comisiones====
motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 29/10/2012 ==

====Participantes====
margenat, sisto, andrew, madruga, chino, john, santiago, gonchi, pancho, aylen, rodrigo

====Minutas====
* hora de comienzo: 19:25 (19:00)
* motores...
*

====motores====
* Otra discusión sobre PaP. Andrés se va a encargar de los motores PaP.
* Motores de alza-cristales/limpia-vidrios parece una buena idea. Se consiguen en plaza, son reciclables, tienen la reducción.
* Pablo propone pieza para mantener la estructura del AX-12 y mantener la estética

====hardware====
* ver los pines que están sin utilizar.
* averiguar sensor distancia auto chino
* sensor enrique de fibra óptica para el butiá, sensor antena

==== mecánica ====
* pablo mostró la nueva chata butiá.

==== gestión ====
* se agrega a gonchi a comisión motores de continua.

== 18/10/2012 ==

====Participantes====
Gonzalo, Jorge, Luis, Martin(Chino), Aylen, John, Rodrigo, Diego (Antel), Guille, Daniel Cancela(montacargas) y Pablo(Estudiante nuevo)

====Minuta====
* Reunión del día 18/10/2012
* Hora de comienzo: 14.50
* Asisten: Gonzalo, Jorge, Luis, Martin(Chino), Aylen, John, Rodrigo, Diego (Antel), Guille, Daniel Cancela(montacargas) y Pablo(Estudiante nuevo)
* Presentación del proyecto a la gente nueva
* Motores
* Modulo voltaje,
* Fin reunión 17.15

====motores====
* discusión por motores nuevamente
* Comisión motores no hizo mucho. Se presentó precio de servos 28u$s de 15kg, 16u$s de 6,8kg. Se va a seguir averiguando en otros lados.
* NO steppers (daniel va a averiguar algo sobre steppers)
* Hay que conseguir los motores de destornillador.

====hardware====
* modulo voltaje y resistencia (guille, egardo, enrique)
* bornera o jack? (jack hace corto,[los jack machos truchos, los buenos NO HACEN CORTO {Guille}])
* protección? volver al diodo que no pusimos
* egardo y guille hoy van a encargarse del hardware
* conseguir conectores bosch mas chicos o cables mejores (guille) llevar el cable de ax12 original

====software====
* activity cambiar id (rodrigo)
* ayle john chino van a agregar funcionalidades al modulo ax12 para actividad de id
* (chequear wiki de mtbutia que estan haciendo algo parecido)
* Tortuga con varios hilos (elemichele, alan el hombre tortuga, andres) quiere hacer un tortuga con varios hilos

====firmware====
* firmware modulo voltaje y resistencia listo
* a FUA agregar un browse para poder grabar un .hex propio
* agregar consultar versión y la id de placa
* pasaje a serial jorge
* discusión sobre versionado de firmware y hardware
* gonchi propone agregar resistencia para versionado de placa
* versionado del firmware
* john va a revisar codigo, hotplug en motores
* git migrar pnp a master, ya estaría pronto
* hackpoint (andres)

====gestión====
* Diego Antel propone: taller utu-antel en la teja segunda quincena enero (john y jorge)
* antel pide un butia mas (hay que discutir esto)
* Daniel plantea tirar lineas a ute (manejando como se manejó con ANTel)
* comisión conseguir openmoko (gonchi jorge)
* openmoko??????? es probable dijo pablo sigue en camino.
* Chino va a compartir la documentación para antel. (NO METER MANO SIN CONSULTARLO A ÉL)
* Pedido por parte de edgardo, chino y enrique para cambiar la reunión
* Se propone reunion los LUNES 18:30

== 11/10/2012 ==

====Participantes====
Rodrigo, John, Edgardo, Enrique, Gonzalo.

====Minuta====
* Acta de la reunión realizada el 11/10/2012
* Motores reciclados
* firmware: actualizador y mejoras
* devolución de robots

====hardware====
* Andrés opina que los servos no cumplen con lo propuesto por el proyecto butiá 2.0 ya que no se pueden reciclar.
* Gonzalo opina que los motores stepper no son aptos.
* Se decidió comenzar a investigar motores de corriente continua y servos que se consigan en uruguay.
* Rodri va a averiguar el costo de servos con gran torque en el mercado local y de corriente continua en casas del estilo repuestos de auto. Incluso se puede ver si la reducción de alguno de los respuestos de auto no es de utilidad.
* Luego se hará una prueba con motores del tipo stepper para mantener una alternativa de reciclado que es abundante en Uruguay.
* Por otro lado se priorizó la construcción de los módulos para leer voltaje y resistencia. Esto sería una alternativa a lo que la XO trae para leer del puerto de audio, pero independiente de la computadora. Tanto Guzmán como Enrique hoy día están haciendo muchos sensores interesantes que pueden prototiparse rápido de esta manera, además de dar continuidad al proyecto Física con XO. La idea es comenzar con una primer versión para tener algo para pasarle a Guzmán lo antes posible. La idea es que a futuro incluya protección pero si los tiempos no dan realizar la primer versión simple sin protección que de hecho es lo que tiene la XO hoy día.

====firmware/software====
* aplicación cambiar el id, cambiar id de los motores (rodrigo)
* aplicación FUA (inc hex) rompemos compatibilidad para la v1
* hotplug en motores
* hackpoint módulo firmware
* pasaje a dispositivo serial (toribio compatibilidad) por defecto esta activado el control de energía de la XO definir versionado de firmware

====mecánica:====
* fichas, metodos conexión, eles, rivetes, compatibilidad con mecano, mejorar la compatiblidad con lego compatibilidad con otras computadoras? Compatibilidad lego ser menos dependiente de las cruces dejar solo agujeros con separación lego y más grandes. De 4.6 mm a 5mm explorar motores continua y servo (enrique servo + edgardo) comisión de encastre (pablo, rodrigo)y sin espacio para la mano baranda cuadrada con agujeritos computadora sobre la baranda pinza: 1 o 2 motores, ver si no es muy complicado usar 1 motor.
* Git migrar pnp a master

====gestión:====
* a fin de año tiene que devolver el robot (prestamo por un año)
* Se definió la comisión de motores: Rodrigo, John, Edgardo y Enrique

Actas Reuniones Butia

2013-02-08T11:48:57Z

Rsisto: /* 31/01/2013 */

== 7/02/2013 ==

====Participantes====
Alan, Pablo, Andres, John, Faivel, Humberto, Guille, Enrique, Javier, Rafael, Nicolás, Edgardo, Mario

====minutas====
Empieza reunión a las 18:50

====Mecánica====
* Se está preparando versión de acrílicos final de Butiá SAM.

====Software====
* Bloque nuevo de casteo para adaptar el valor del sensor a un rango conocido, y los bloques de usurio a bloques conocido. En paleta extra, agrega un bloque nuevo.
** Problema: que pasa cuando se levanta devuelta el archivo, despues de reiniciar el programa? Hay que probar
* Bloque módulo user 1,2,3
* Bloque python de tortuga no funciona, no almacena el código, si no referencia al archivo. Corregir (Walter?)

====Firmware y Hardware====
* Es complicado agregar un nuevo módulo de firmware, por más que sea parecido a los anteriores.
** Agregar módulo genérico, al instanciarlo por sw, pasarle parametro el rango de identificación. (Descartado por la siguiente opción)
** Agregar módulos de usuario en fw, que sean genéricos, permitiendo así compartir el sensor con otras placas. Mantiene estructura actual de firmware. Cuando se instancia se define si es digital o análogo. Se genera un alias al instanciar en código. Tiene metodo getValue y setValue.
* Puente H, se le va a poner un micro, se está trabajando
** Generar entrada en wiki para discutir como conectar motores (placa con cantidad variable de motores, 2 motores, etc)
** El h-bridge diseñado va a permitir conectar a los hack-points o al puerto.
** Módulo usando un pin de los puertos y 2 hack-points
** Módulo utilizando un puerto con 2 pines de datos.
* Implementar módulo de PWM

== 31/01/2013 ==

====Participantes====
Alan, Pablo, Andres, John, Faivel, Humberto, Guille, Enrique, Javier

====minutas====
Empieza reunión a las 18:09

====Mecánica====
*Se realizo la prueba de colocar la rueda en el eje del motor con un prisionero directo a la rueda y dio muy buen resultado. De momento parece ser la mejor idea y queda muy prolijo.
*Se le agrego los agujeros para trasladar la placa chica de acrílico para dejar espacio para los motores de continua
*Se le agrega una ficha butia para ensamblar los motores al butia
*Parece que con esa modificación el puerto USB de la placa queda muy cerca de la rueda loca y queda tocando con el cable USB.
** Se discutio si se rota 180 la placa USB4butia quedando el USB hacia la otra direccion y los 4 conectores para sensores hacia la rueda, igual va a tocar con la rueda pero los cables de los sensores son mas flexibles y el conector no sobresale tanto o también lo de rotar todo el modulo que contiene placa, pilas y chasis chico de acrilico 180 o Intercambiar la placa con las pilas. Se decidio intercambiar la placa con las pilas.
*Se discutió sobre simetrizar los agujeros para amurar de la placa, pero se decidió que no porque pierde compatibilidad con los butias anteriores
* Se probo colocarle una rueda con el sistema del prisionero al motor de DX, el sistema de la ficha no es compatible con este pues tienen diametros distintos, se quiere llegar a una ficha mas universal por lo que se discutieron varias ideas sobre eso, quedamos en que se va a seguir investigando.
*Se dise;o el topecito para la parte de enfre con el logo de butia

====Firmware y Hardware====
*Se siguieron plantenado ideas sobre la USB4butia avanzada y lo de usar otro micro. Se va a seguir investigando
*Se planteo un idea de usar un circuito analogico con 3 estados para conectar los motores directamente a los puertos de la USB4butia

== 24/01/2013 ==

====Participantes====
Alan, Rodrigo, Pablo, Jorge, Andres, Daniel, John, Rafael, Aylen, Fiorella, Faivel, Guille, Humberto

====minutas====
Empieza reunión a las 18:26

====Mecánica====
*Se trajeron las piezas de formacril, se probaron las dos alternativas de barandas y se discutio. Se decidio que la mejor alternativa de barandas cortas con topes es mejor, pues muestra mas robustez frente a la de baranda larga y el laptop queda mas estable.
** El tope serian dos piezas universales butia, (No esta bueno que estas piezas sean de tope)
** Se decidio que el largo ideal de los tornillos para las piezas es de 4 x 0.7 de 20 mm.
*Motores: Se hizo una prueba con un prisionero y dio muy buen resultado.
*colocar el prisionero en la rueda directamente?

====Firmware====
*Seguir investigando sobre los micros buscar uno micro que sea Economico, Mercado Local, Chico y se pueda hacer PWM.
*Replantearse la idea de implementar serial por sofware y la de pwm.

====Hardware====
*Se resolvió quitar el Cristal de 32.768 que libera dos pines en la placa de los cuales uno es el PWM que se buscaba obtener
*El botón de bootloader permanece en la placa
*Colocar 2 puertos en la USB4butia compatibles con el el conector de los servos para los PWM.
*USB4butia simple y utilizar los hackpoints para controlar opción estable.
*Se hablo de hacer una placa usb4butia avanzada en dos capas y se planteo la interrogante de que es mejor: Si hacer la placa usb4butia doble capa avanzada con mas pines de datos y quizás con potencia, o mantenes la usb4butia con una capa agragando un modulo motor con otro microcontrolador.
*Crear una whish lista sobre la USB4butia

== 17/01/2013 ==

====Participantes====
Alan, Rodrigo, Pablo, Jorge, Andres, Daniel, John, Rafael

====minutas====
Empieza reunion a las 18:26

====Mecánica====
* se habló del módulo motor y la elección del pic, parece que utilizar
el micro con menos prestaciones es la opción más adecuada.
* como colocar los motores de CC : correa/directo
** se decidió que ya que tenemos motores con un buen par, no tiene
mucho sentido tener una correa.
** Surge el tema de donde colocar los motores para que siga siendo
ax12 y CC compatible, una opción para no cambiar las distribuciones
actuales es colocar los motores de CC atrás y permitir cambiar de
lugar la rueda loca para el lado opuesto al que está ahora. Hay que
tener ojo de que no obstaculice la conexión de puertos actual lo cual
es el problema que tiene ahora.
** Otro tema es como amurar la rueda a los motores, el motor que
compramos es de eje cilíndirco, hay otros con un perfil lo cual
permite que se pueda diseñar una rueda con un prisionero. Otra opción
es perforar el eje del motor y ponerle una espina para amurar la
rueda.

====Hardware====
*resolver que hacer con PWM: hackpoints, puertos
** PWM, mantener por hackpoint y generar módulo de firmware para PWM
por software utilizando Timer1 (inteligente, interrumpir solo cuando
es necesario).
** Generar informe con opciones de mantener o quitar botón de programación
* Módulo GPIO: no es equivalente al resistencia? Aporta algo?
** Evaluar quitar módulo port (porque no aporta nada)
** Evaluar agregar módulo de GPIO, permite por lo menos avisar al
usuario que está realizando una acción que puede dañar el equipo.
* Gadgets de sensore en DX, que hacer, definir ids o usar módulo
lector de voltaje, en general utilizar el de voltaje
** Crear módulos de temperatura y magnético, para laboratorios de física.
* chequear si el sensor de campo mag es analogico o digi

== 10/01/2013 ==

====Participantes====
Guillermo, Alan, , Fiorella, Pablo, Jorge, Andres, Faviel, John

====minutas====
Empieza reunion a las 18:26

====Documentación====
*Sensores de resistencia y voltage (John y Guille)
*Sensor de flexión ya esta documentado por Enrique

====Mecánica====
*Se estan haciendo los acrílicos en formacril, fecha aproximada 24
*Módulo motor hecho con carcasa de linterna utilizando una ficha butia, carcasa de un enchufe, arrancador de tubo y zunchos.
**Se discutio sobre utilizarlo con una correa o adicionarle una rueda, se decidio adicionarle la rueda y colocar el modulo en el lugar actual de las ruedas, manteniendo la estructura de los AX12, incorporándolo al butia por fuera. (Butia PUNK)
*Se habló de hacer un banco de prueba de motores para obtener datos útiles como el par, rpm , etc ...
*Se probaron los tornillos de plástico y dan buen resultado ya que protege el acrílico, son mas fácil de enroscar, mas amigables para los niños

====Hardware====
*Se discutió sobre los cambios de la USB4butia, estudiar lo de hacer una USB4butia solo para controlar motores y evaluar Modulito con microcontrolador propio para manejar motores, PIC16F628A buscar compilador GNU, buscar otro PIC de 8 patas
*Evaluar de quitar el clock de 37 khz y utilizar el pin 16 que es el CCP2 y asi evitar de quitar el boton de programacion
*Se hablo sobre sacar el boton de programacion, se decidio quitarlo y cambiar el bootloader y agregar dos puertos pwm (Si es necesario)
*Se discutió lo de quitar el bus AX12, se decidió que no porque permite agregar motores con control más complejo de forma fácil.
*Sacar los pines de programación ... ?

====Software====
*Serial por software (si se va hacer el modulo motor con pic propio)

== 03/01/2013 ==
====Participantes====
Rafa, Pablo, Pancho, Jorge, John

====Mecánica====
*Se dibujaron barandas nuevas con el tope , y se hicieron prototipos en goma eva para presentar en el butiá. Se presentó junto a la magallanes. Se discutió y se decidió hacer las barandas un poco más altas. Diseñar y construir 2 juegos de barandas: unas más largas con tope flotando y otras más cortas sin tope.
*Se mostró la nueva rueda butiá con agujero en el medio
*Se habló del modulo motor se agregan dos piezas de acrílico para mantener la estructura de los AX12 y no tener que hacer un butia distinto para la versión con otros motores. Hay dos opciones, una posee lengüetas como los AX12 y van en el mismo lugar con las ranuras existentes para los AX12 y la otra serían las fichas universales con el sistema de encastre butia.
*Estudiar agujeros para "ensanguchar" las dos planchas de acrílicos, agregar un tornillo más alineado con los que ya están con la medida de los AX12
*Se acomodó la ojiva del encastre butiá centrándola para que quede un poquito mas separdo de los rectángulos
*Se le agrega al logo la palabra SAM
*Ejemplo de logos para autoadhesivos
*Se van hacer arcilicos y autoadhesivos.
*Se va a probar el logo calado otra vez

== 27/12/2012 ==

====Participantes====
Daniel, Guillermo, Alan John, Fiorella, Aylen, Rodrigo, Enrique, Rafael, Pablo

====minutas====
* Empieza reunion a las 18:41

====Hardware====
* Acrílico había quedado mal grabado el logo la última vez, quedó una línea entrecortada.
** Se va a pedir devuelta con los logos bien grabados. Pablo trae planos el 3 de enero. Al pedir los nuevos acrílicos preguntar opciones de:
*** Pintar logos luego de grabarlos
*** Mejorar calidad del grabado para que no queden manchados.
*** Incrementar ancho de línea para que queden mejor marcados los logos.
** Pablo va a mandar a hacer pegotines calados de logos para manejar otra alternativa
** Se discute si poner nombre 2.0 o "sam". Mayoría eligió Sam (2 en charrúa)

====Motores====
* Se vio prototipo con motores de cargadores USB a dínamo, utilizando hack points.

====Software====
* Salió paquete de TortuBots v18, faltan paquetes Debian actualizar changelog (Aylen)
* Alan corrigió bug de memory leak de TortuBots, ahora no se bloquea en la XO. Está probado.
* PyBot (librería python para acceder a placa butiá) está casi listo, falta testear.
* Validación al tratar de grabar o escribir en hackpoint configurado para entrada o salida respectivamente. Hacerlo en api y agregarlo a TortuBots cuando trata de hacer una operación incorrecta. (Alan)

====Firmware====
* Módulo de Firmware de hackpoint no tiene que cambiar el modo del pin (Aylen)

== 10/12/2012 ==
====Participantes====

John, Aylen, Pablo, Gonzalo, Guillermo, Andrés, Diego, Rafael, Luis, Rodrigo, Marcelo

====minutas====
* Empieza reunion a las 19:50

====Hardware====
* Falta documentar prototipo con motores de linternas (Pancho)
* Piezas para anexar sensores: Pablo muestra 3 piezas, genérica de 2 lados, de 1 lado y una cortita.
** También se hizo pieza para reemplazar motores AX12.
** Se llega a un acuerdo de como tienen que ser las placas de sensores
* Se decide cambiar las piezas por piezas únicas para armado y reemplazo de AX12.
* Barandas, se van a cambiar por unas que empiezan finitas en la parte frontal y terminan gruesas en la parte trasera como guardabarros. En la parte delantera, tienen tope para aguantar una laptop.

====Motores====
* Motores "argentinos" no tienen certificado de origen (motor chino, engranajes argentinos)
* Guille va a mandar un mail a Fede para que averigüe en Brasil por alternativas de motores CC.
* Rodrigo, Gonzalo, van a armar prototipo con motores de cargadores USB a dínamo.

== 3/12/2012 ==
====Participantes====

John, Aylen, Pablo, Gonzalo, Guillermo, Francisco, Andrés, Daniel, Rafael, Alan, Luis

====minutas====
* Empieza reunion a las 19:30

====Hardware====
* Hay que definir los componentes para construir una serie de robots, de la mano de Antel (esperando h-bridge)
** Definir que motores de CC usar, de AP&S, modelo SP6-50, similar a AX12 ($80 argentinos), faltan definir los de Ignis (MR83-100, con pocas revoluciones y poco par), Pablo trae 2 de cada uno para probar.
* Ida a Triex sugerida por Daniel. Hay varios interesados, coordinar por mail.
* John, Andrés, definiendo USB4Motores, placa USB4All genérica, con H-bridge integrado.

====Motores====
* Motor de linterna recargable, funciona bien, Gonzalo va a comprar lintenrnas para armar un Butiá.
* Documentación de alternativas de motores: Daniel, Pablo y Francisco (documentar motores descartados - Daniel, motores de linternas recargables, Soportes Discos duros y contra chata. Motores a usar) Rafa va a mandar link de como crear usuario y stub de documento.
* Edgardo está armando el H-Bridge para controlar motores (Edgardo está armando)
* Se vieron acrílicos con logo

====firmware====
* Se solucionó problema en firmware (se estaba usando memoria inexistente)
* Andrés, Aylen, John: Trabajando en Módulo PWM por software en firmware.
* John - Falta módulo GPIO

====Sensores====
* Guille, John - Documentar en wiki como crear sensores nuevos.
* Gonzalo, mirando como funciona sensor de color.

====Software====
* Alan está escribiendo API en Python para Butia, falta contemplar varias placas USB
* Firmware update activity , está pronta la actividad 90%
* Andrés - Actualizar butialo a 2.0 (no dio el tiempo)

====Organización====
* Andrés comenta sugerencias del sumo.uy
** Agregar agujeros para tornillos
** Quejas de sensor de distancia, no se puede enganchar
** Robot Butiá triangular - Omni

== 26/11/2012 ==
====Participantes====
Luis, Marcelo, Guillermo R., Pablo Margenat, Gonzalo, Rafael Sisto, Andrés Aguirre, Aylen, Enrique, Diego, Martín , John, Javier, Alan, Fiorella

====minutas====
* Empieza reunion a las 19:30

====Hardware====
* Hay que definir los componentes para construir una serie de robots
** Definir que motores de CC usar (Quién va a definir esto?)
* Ida a Triex sugerida por Daniel. Hay varios interesados, coordinar por mail.

====Motores====
* Comisión continua Falta probar con mosfets (esperando módulo PWM de firmware)
** Cambiar circuito de muestra buscando mosfets de menor amperaje (Diego)
* Soportes de motores
** Acrílico (prontos para el 29/11), demo para 3/12
** Pancho y Pablo: cortando chasis de disco, pensando alternativas.
** Transmisión, se propone probar goma en el motor y goma en la rueda, en vez de una correa.
* Alternativas de motores:
** Linternas con generadores, se pueden usar como motores (menos de $200 en supermercados), hay que escribir en la wiki
** Andrés, Enrique - Consultar a Eneka por motores de continua hechos en Argentina (cerca de $700), modelo MR4-100, ver si tiene suficiente torque.

====firmware====
* Andrés, Aylen: Módulo PWM por software en firmware.
** (Andrés, Micho) Falta solucionar bug extraño cuando hay muchos módulos (posiblemente una asignación errónea de memoria), probar con Ida.
* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.(Se puede hacer)
** Faltan módulos GPIO y LED (Prontos, falta corregir bug).
* Pendiente Andrés - Liberar motores cuando se le mande orden velocidad cero.

====Sensores====

* Fibra óptica, se puede conseguir en Tilsit (6 metros con terminales, aprox U$ 35). Daniel va conseguir una nueva muestra actual para probar.
** Se consigue en el Clon por $65 una lámpara decorativa
** Luego de tener fibra, segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Sensores de efecto Hall (No se trató )
** Propuesta de Diego: sensor de imanes utilizando una bobina y con pin analógico.(No se trató )

====Software====

* Alan: bloque para configurar hack points, pronto, falta configurar como entrada.
* Bloque LED está.
* Alan, falta bloque GPIO
* Alan está escribiendo API en Python para Butia (falta testear, branch pybot)
* Guille, haciendo paquete Debian (armado makefile estilo GNU)
* Rodrigo, el tortuga tiene un uso excesivo de CPU (hay que ver si es nuestro o de walter) cuando se usan muchos bloques. Reproducir problema. (No se habló)
* Firmware update activity , está pronta la actividad 90%
* Andrés - Actualizar butialo a 2.0

== 19/11/2012 ==
====Participantes====
Guillermo R., Pablo Margenat, Rafael Sisto, Andrés Aguirre, Alan Aguiar , Rodrigo, Aylen, Gonzalo, Enrique, Diego

====minutas====
* Empieza reunion a las 19:30

====Motores====

* Comisión continua Falta probar con mosfets (esperando módulo PWM de firmware)
** Cambiar circuito de muestra buscando mosfets de menor amperaje (Diego)
* Soportes de motores
** Se hizo modelo, está pedido el acrílico (prontos para el 29/11), demo para 3/12
** Pancho y Pablo: cortando chasis de disco
* Buscar alternativas de motores:
** lectoras de CD, disketeras, discos duros (Diego está consiguiendo con Integra)
** Andrés está consultando en Eneka por motores de continua hechos en Argentina (cerca de $700), serían similares a los secadores de pelo, pero con reducción.
* Comision PaP - Se sigue trabajando para un prototipo, se propone controlar con circuito casero.

====firmware====

* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.
* Andrés - Liberar motores cuando se le mande orden velocidad cero.
* Andrés, Aylen: Módulo PWM por software en firmware.
* Andrés: Notificar placa como dispositivo serial al PC (avanzando).

====Sensores====

* Fibra óptica, se puede conseguir en Tilsit (6 metros con terminales, aprox U$ 35). Daniel va conseguir una nueva muestra actual para probar.
* Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Sensores de efecto Hall
** Propuesta de Diego: sensor de imanes utilizando una bobina y con pin analógico.

====Software====
* Alan: bloque para configurar hack points.
* Tortubots, tema pendiente: Generar un evento a los plugins cuando finalice la ejecución de los bloques (por ejemplo, para liberar cámara, parar motores, etc).
* Migración TurtleBlocks a android, falta librería GTK, trancado por ese tema
* Alan está escribiendo un API en python con funcionalidad similar a bobot (ventaja: no requiere lua ni dependencias de binarios adicionales, para arm no requeriría link a binarios extra, no requiere comunicación por sockets.)
* normalizar velocidades de 0 a 100. Se descarta porque no hay un problema concreto en que pueda beneficiar. En principio sirve para buscar la curiosidad de los alumnos.
* Separar paleta, ya está.
* Guille, haciendo paquete Debian.
* Rodrigo, el tortuga tiene un uso excesivo de CPU (hay que ver si es nuestro o de walter) cuando se usan muchos bloques. Reproducir problema.
* Guille, Aylen: Firmware update activity
** Actividad con un botón para actualizar (Rodrigo)

====Documentación====
* Rafael: Revisar documentación de entregables a Antel

====Resumen de Comisiones====
Soportes de motores: Pablo y Francisco

motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 12/11/2012 ==
====Participantes====
Guillermo Reisch, Diego, Daniel, John Pereira, Pablo Margenat, Rafael Sisto, Francisco Puignau, Andrés Aguirre, Martín Giachino, Alan Aguiar

====minutas====
* Empieza reunion a las 19:30

====Motores====
* Comisión continua - trajo demo con motores distintos y quedó bien el seguidoor de líneas.
** Falta probar con mosfets
* Soportes de motores
** Falta soporte para gomitas, propuesta de hacer 2 ruedas de acrílico más chicas para sostener.
** Falta soporte para rueda,
*** Proponen utilizar el mismo plato del soporte de gomitas, eje con rulemanes
*** Otra alternativa, usar motor de disco duro como rulemán (módulo independiente). (Guillermo va a traer discos duros para desarmar)
** Buscar alternativas de motores: secador de pelo (12v), lectoras de CD, disketeras
* Comision PaP - utilizar motor de impresora con driver. (para lunes 19/11)

====firmware====

* módulo firmware para bus pines digitales pronto, PWM se va a manejar por software
* firmware para sensor de voltaje pronto
* Guille - Investigando como configurar de forma combinada pines de E/S como digitales y analógicos.
* Andrés, Aylen: Módulo PWM por software en firmware.
* Andrés: Notificar placa como dispositivo serial al PC.

====Sensores====

* Demo de Módulo voltaje y resistencia
** Algunos detalles por corregir
* Fibra óptica, Daniel va a conseguir una muestra para el lunes siguiente
* (no se habló) Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises

====Software====

* Se creó bloque de sensor de voltaje
* Separar paleta, normalizar velocidades de 0 a 100 (Alan)
* Alan, el tortuga tiene un memory Leak (hay que ver si es nuestro o de walter) cuando se usan muchos bloques
* Alan, quitar compatibilidad para V1
* Guille, Aylen: Firmware update activity - postergado para próxima reunión.

====Resumen de Comisiones====
Soportes de motores: Pablo y Francisco

motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 05/11/2012 ==
====Participantes====
Gonzalo Tejera, Guillermo Reisch, Enrique Madruga, Daniel Cancela, John Pereira, Pablo Margenat, Rafael Sisto.

====minutas====
* Empieza reunion a las 19:30
* resumen, software/hardware/mecanica etc...

====Motores====
* Enrique averiguó motores alza-cristales: son caros (cerca de los $ 1000)
* Daniel mandó mail a SEMPRE, va a relevar que tipo de motores (otra chatarra) se pueden conseguir
* Comisión continua - va a avanzar con el módulo de relés
* Comisión continua - motores de secador de pelo (12v), lectoras de CD, disketeras
* Comisión continua - Preguntar a "Lechuga" qué motores usaron
* Comision PaP - utilizar motor de impresora con driver. (para lunes 19/11)
* Reducciones - 2 alternativas, correas o engranajes impresos.

====firmware====

* Aylen, agregar módulo firmware para bus pines digitales y PWM (pin 17). Si puede estar para esta semana, mejor.
* John - Otra alternativa para manejar motores, utilizar el puerto ax12 y un pic conversor a otro tipo de motores.
* Aylen - falta firmware para sensor de voltaje (estaría pronto)

====Sensores====
* sensor distancia auto chino - Enrique consultó en comercio electrónico y superan los $1000, seguir consultando alternativas.
* Fibra óptica, intentar utilizar fibra óptica de cotillón (adornos de colores)
** Daniel para el lunes se comprometió en traer un par de tramos (quizás se consigue en SEMPRE)
** Enrique - Segunda versión de sensor: emisor y receptor en mismo lado (fibra formando un círculo), posiblemente utilizando sensor de grises
* Módulo voltaje y resistencia (demo lunes 12)
** Se decidió utilizar jumper en vez de switch
** Se creó módulo en kicad
* Firmware update activity (trabajando...)

====Software====
* Alan, crear bloque de sensor de voltaje
* Alan, hablar con Andrés y Rodrigo - El tortuga tiene un memory Leak (hay que ver si es nuestro o de walter) cuando se usan muchos bloques

====Hardware====
* Chata va a comenzar a llevar logo de Antel

====Gestión====
* Intentar convertir las reuniones en talleres

====Resumen de Comisiones====
motores: John, Edgardo y Enrique

motores PaP: Andrew, Daniel

motores continua: Gonzalo, Rodrigo,

Firmware : Aylen, John, Andrew, Guille

Firmware Update Activity: Guille, Aylen

Módulo Voltaje y resistencia: Guille, Aylen

== 29/10/2012 ==

====Participantes====
margenat, sisto, andrew, madruga, chino, john, santiago, gonchi, pancho, aylen, rodrigo

====Minutas====
* hora de comienzo: 19:25 (19:00)
* motores...
*

====motores====
* Otra discusión sobre PaP. Andrés se va a encargar de los motores PaP.
* Motores de alza-cristales/limpia-vidrios parece una buena idea. Se consiguen en plaza, son reciclables, tienen la reducción.
* Pablo propone pieza para mantener la estructura del AX-12 y mantener la estética

====hardware====
* ver los pines que están sin utilizar.
* averiguar sensor distancia auto chino
* sensor enrique de fibra óptica para el butiá, sensor antena

==== mecánica ====
* pablo mostró la nueva chata butiá.

==== gestión ====
* se agrega a gonchi a comisión motores de continua.

== 18/10/2012 ==

====Participantes====
Gonzalo, Jorge, Luis, Martin(Chino), Aylen, John, Rodrigo, Diego (Antel), Guille, Daniel Cancela(montacargas) y Pablo(Estudiante nuevo)

====Minuta====
* Reunión del día 18/10/2012
* Hora de comienzo: 14.50
* Asisten: Gonzalo, Jorge, Luis, Martin(Chino), Aylen, John, Rodrigo, Diego (Antel), Guille, Daniel Cancela(montacargas) y Pablo(Estudiante nuevo)
* Presentación del proyecto a la gente nueva
* Motores
* Modulo voltaje,
* Fin reunión 17.15

====motores====
* discusión por motores nuevamente
* Comisión motores no hizo mucho. Se presentó precio de servos 28u$s de 15kg, 16u$s de 6,8kg. Se va a seguir averiguando en otros lados.
* NO steppers (daniel va a averiguar algo sobre steppers)
* Hay que conseguir los motores de destornillador.

====hardware====
* modulo voltaje y resistencia (guille, egardo, enrique)
* bornera o jack? (jack hace corto,[los jack machos truchos, los buenos NO HACEN CORTO {Guille}])
* protección? volver al diodo que no pusimos
* egardo y guille hoy van a encargarse del hardware
* conseguir conectores bosch mas chicos o cables mejores (guille) llevar el cable de ax12 original

====software====
* activity cambiar id (rodrigo)
* ayle john chino van a agregar funcionalidades al modulo ax12 para actividad de id
* (chequear wiki de mtbutia que estan haciendo algo parecido)
* Tortuga con varios hilos (elemichele, alan el hombre tortuga, andres) quiere hacer un tortuga con varios hilos

====firmware====
* firmware modulo voltaje y resistencia listo
* a FUA agregar un browse para poder grabar un .hex propio
* agregar consultar versión y la id de placa
* pasaje a serial jorge
* discusión sobre versionado de firmware y hardware
* gonchi propone agregar resistencia para versionado de placa
* versionado del firmware
* john va a revisar codigo, hotplug en motores
* git migrar pnp a master, ya estaría pronto
* hackpoint (andres)

====gestión====
* Diego Antel propone: taller utu-antel en la teja segunda quincena enero (john y jorge)
* antel pide un butia mas (hay que discutir esto)
* Daniel plantea tirar lineas a ute (manejando como se manejó con ANTel)
* comisión conseguir openmoko (gonchi jorge)
* openmoko??????? es probable dijo pablo sigue en camino.
* Chino va a compartir la documentación para antel. (NO METER MANO SIN CONSULTARLO A ÉL)
* Pedido por parte de edgardo, chino y enrique para cambiar la reunión
* Se propone reunion los LUNES 18:30

== 11/10/2012 ==

====Participantes====
Rodrigo, John, Edgardo, Enrique, Gonzalo.

====Minuta====
* Acta de la reunión realizada el 11/10/2012
* Motores reciclados
* firmware: actualizador y mejoras
* devolución de robots

====hardware====
* Andrés opina que los servos no cumplen con lo propuesto por el proyecto butiá 2.0 ya que no se pueden reciclar.
* Gonzalo opina que los motores stepper no son aptos.
* Se decidió comenzar a investigar motores de corriente continua y servos que se consigan en uruguay.
* Rodri va a averiguar el costo de servos con gran torque en el mercado local y de corriente continua en casas del estilo repuestos de auto. Incluso se puede ver si la reducción de alguno de los respuestos de auto no es de utilidad.
* Luego se hará una prueba con motores del tipo stepper para mantener una alternativa de reciclado que es abundante en Uruguay.
* Por otro lado se priorizó la construcción de los módulos para leer voltaje y resistencia. Esto sería una alternativa a lo que la XO trae para leer del puerto de audio, pero independiente de la computadora. Tanto Guzmán como Enrique hoy día están haciendo muchos sensores interesantes que pueden prototiparse rápido de esta manera, además de dar continuidad al proyecto Física con XO. La idea es comenzar con una primer versión para tener algo para pasarle a Guzmán lo antes posible. La idea es que a futuro incluya protección pero si los tiempos no dan realizar la primer versión simple sin protección que de hecho es lo que tiene la XO hoy día.

====firmware/software====
* aplicación cambiar el id, cambiar id de los motores (rodrigo)
* aplicación FUA (inc hex) rompemos compatibilidad para la v1
* hotplug en motores
* hackpoint módulo firmware
* pasaje a dispositivo serial (toribio compatibilidad) por defecto esta activado el control de energía de la XO definir versionado de firmware

====mecánica:====
* fichas, metodos conexión, eles, rivetes, compatibilidad con mecano, mejorar la compatiblidad con lego compatibilidad con otras computadoras? Compatibilidad lego ser menos dependiente de las cruces dejar solo agujeros con separación lego y más grandes. De 4.6 mm a 5mm explorar motores continua y servo (enrique servo + edgardo) comisión de encastre (pablo, rodrigo)y sin espacio para la mano baranda cuadrada con agujeritos computadora sobre la baranda pinza: 1 o 2 motores, ver si no es muy complicado usar 1 motor.
* Git migrar pnp a master

====gestión:====
* a fin de año tiene que devolver el robot (prestamo por un año)
* Se definió la comisión de motores: Rodrigo, John, Edgardo y Enrique

Discusiones para las reuniones

2013-02-07T20:46:26Z

Rsisto:

Sería interesante permitir que usuarios que no son muy entusiastas de la programación de firmware pueda agregar sensores y módulos en firmware para controlarlos sin necesidad de estar tocando firmware.

La idea es que exista pre-hecho en firmware un módulo genérico, que tenga la primitiva getValue. Desde el PC el usuario envía un pedido para que ese módulo se instancie con un nombre y valor de identificación. A lo mejor lo ideal es que el firmware le proponga al usuario una lista de valores de id libres que pueden ser apropiadas. El resultado final es que el módulo queda agregado a los módulos disponibles en la placa, vemos después como, si usando memoria eeprom del micro y guardando en una tabla nombre, id o algo similar.
Eso va acompañado de un dispositivo de hardware genérico, como el que teníamos por la vuelta en el que se tiene una bornera para colocar el sensor y un slot para poner la resistencia.
Creo que cubriría una gama grande de sensores que la gente quiere hacer para probar y son muy simples, generalmente un sensor análogico o digital y no les interesa agregar lógica en el módulo de usuario. Lo bueno es que permite que la gente de forma fácil utilice las bondades como plug and play, hotlug, mecanismo robusto de conexión de la placa de una forma simple.

TortuBots

2013-02-05T22:23:51Z

Rsisto: /* Plugin SumBot */

== TortuBots ==

[http://wiki.sugarlabs.org/go/Activities/TurtleArt TortugArte] es una actividad Sugar inspirada en [http://en.wikipedia.org/wiki/Logo_(programming_language) Logo] la cual pone al alcance de niños conceptos de programación, mediante una interfaz gráfica icónica, donde cada instrucción se mapea como un bloque.
El proyecto butiá realizó modificaciones sobre TortugArte agregando algunos plugins en forma de paletas que permiten controlar diferentes kits robóticos como [http://www.fing.edu.uy/inco/proyectos/butia/ Butiá], [http://en.wikipedia.org/wiki/Lego_Mindstorms_NXT_2.0 Lego NXT],[http://www.legoeducation.us/eng/product/lego_education_wedo_robotics_construction_set/2096 Lego WeDo],[http://activities.sugarlabs.org/es-ES/sugar/addon/4368 FollowMe] y Sumbot). Se puede descargar la actividad TortuBots que contiene todo lo actual de TortugArte más los plugins de robótica mencionados.

[[Archivo:Tb.png|En ésta imagen pueden verse las diferentes paletas agregadas.]] 
Paletas de izq. a der.: Lego WeDo - Butiá - Butiá Extras - SumBot - FollowMe - Lego NXT (motores) - Lego NXT (sensores)

Pueden descargarse las últimas versiones del siguiente [http://www.fing.edu.uy/inco/proyectos/butia/files/package/ repositorio] o desde el [http://activities.sugarlabs.org/es-ES/sugar/addon/4434 repositorio de actividades Sugar]. En este momento se encuentran disponible para su uso en XO, y computadoras con Ubuntu 10.04 o posterior.

== Plugin Butiá ==

El robot Butiá tiene soporte [[plug and play]] y [[plug and play|hotplug]] para los sensores/actuadores que se conectan a él, este aspecto fue utilizado a la hora de implementar el plugin cambiando el color de los bloques correspondientes a los elementos de sensado/actuación según lo que se haya conectado al robot.

[[Archivo:Tb1.png|En ésta imagen puede verse la paleta cuando no hay robot conectado]] 

[[Archivo:Tb2.png|En ésta imagen puede verse la paleta cuando hay robot conectado y un sensor botón]] 

Instalación:

* Cualquier distribución de GNU/Linux:

Si usted tiene una versión de linux basada en ''debian'' puede descargar la actividad para su arquitectura directamente desde nuestro [http://www.fing.edu.uy/inco/proyectos/butia/files/package/ repositorio]

Sino puede seguir este [[Generando_xo | instructivo]]

* En Sugar:

[[instalacion_XO|XO 1.0 y 1.5]]

Para comenzar...

* [[Tortugarte_variables|Como manejar variables en TortuBots]]

* [[Modularizando|Como modularizar un programa en TortuBots]]

* [[Transformando_a_cms_el_valor_del_sensor_de_distancia|Transformando a centímetros la salida del sensor de distancia]]

* [[Ejemplos de comportamientos robóticos con TortuBots|Ejemplos de comportamientos que pueden realizarse en TortuBots]]

* [[video_tutoriales|Video Tutoriales]]

== Butiá Extras ==

[[Archivo:Tb3.png|En ésta imagen puede verse la paleta de extras cuando hay robot conectado]] 

La paleta de extras de butiá nos permite profundizar otras funcionalidades de la placa:

* [[HackPoints|Como utilizar los HackPoints]]

* [[Módulo sensor Voltaje | Módulo Voltaje]]

* [[Módulo sensor Resistencia | Módulo Resistencia]]

== Plugin Lego NXT ==

[[Archivo:Lnxt1.png]] 

[[Archivo:Lnxt2.png]] 

Toda la información en: [http://wiki.sugarlabs.org/go/Activities/Turtle_Art/Plugins#LEGO_NxT <big>'''NxT'''</big>]

== Plugin Lego WeDo ==

[[Archivo:Wdo.png]] 

Toda la información en: [http://wiki.sugarlabs.org/go/Activities/Turtle_Art/Plugins#WeDo <big>'''WeDo'''</big>]

== Plugin FollowMe ==

[[Archivo:Fm.png]]

La idea detrás de la paleta es retornar posiciones x y y del color de un objeto de manera de mover el robot Butiá de acuerdo a estos valores.

Toda la información en: [[FollowMe | <big>'''FollowMe'''</big>]]

== Plugin SumBot ==

Este plugin permite comunicarse con el sistema de visión utilizado en la categoría sumbot del evento sumo.uy [http://www.fing.edu.uy/inco/eventos/sumo.uy/].
A partir de la versión 5 de tortugarteButiá viene incluido, puede consultarse más sobre su funcionamiento en la wiki del evento sumo.uy [http://www.fing.edu.uy/inco/eventos/sumo.uy/wiki/index.php/Actividad_Tortugarte].

[[Archivo:SumB.png]] 

== Plugin Pattern Detection ==

Este plugin permite detectar señales y patrones con la cámara de la pc. La versión incluida del plugin incluye el reconocimiento de señales de tránsito, pero es posible agregar marcas adicionales como se detalla en la página del plugin: [[Butia_reconocimiento_marcas]]

La paleta trae bloques que permiten detectar la presencia de marcas además de la distancia a las mismas.

[[Archivo:Paleta_reco_marcas.png|700px]]

Archivo:Paleta reco marcas.png

2013-02-05T21:54:28Z

Rsisto: subió una nueva versión de «Archivo:Paleta reco marcas.png»

Paleta de reconocimiento de marcas

Archivo:Paleta reco marcas.png

2013-02-05T21:50:23Z

Rsisto: subió una nueva versión de «Archivo:Paleta reco marcas.png»

Paleta de reconocimiento de marcas

Butia reconocimiento marcas

2013-02-05T21:38:14Z

Rsisto: /* Actividad para agregar marcas */

== Integrantes ==
* Nicolás Fúrquez
* Rafael Sisto

== Objetivos ==
* Utilizando [http://www.hitl.washington.edu/artoolkit/ ARToolKit] construir un plugin para Tortugarte/Tortublocks que permita reconocer las marcas. Esto puede ser utilizado para que el robot se localice y navegue en un entorno.

Ejemplos de marcas: 
[[Archivo:StopMark.png|300px]] [[Archivo:YieldMark.png|300px]]

Una de las cosas que nos permite la librería (ARToolKit) es que las marcas no necesariamente tienen que estar en color, permitiendo así imprimirlas en cualquier impresora siempre y cuando se mantenga el tamaño.

== Documentación de la solución ==
Se desarrolló un api que obtiene la información almacenada de las marcas y mediante la ayuda de ARToolKit se detectan las mismas en las capturas de la cámara.

El código fuente e instrucciones de instalación se pueden encontrar en el repositorio utilizado:
[https://github.com/rsisto/multiPatternRecognition multiPatternRecognition]

=== Diagrama de componentes ===
En el siguiente diagrama pueden visualizarse los componentes y su interacción. pattern_detection funciona como plugin de TurtleBlocks, que a su vez utiliza la librería multiPatternDetection (a través de un binding de python a C). Esta última utiliza funciones de ARToolKit para la detección de marcas.

[[Archivo:Arq_pattern_detection.png|400px|Arquitectura de detección de patrones con ARToolKit]]

=== Paleta reconocimiento de marcas ===
Paleta:

[[Archivo:Paleta_reco_marcas.png|700px]]

La paleta posee botones fijos que son:

'''"Viendo Señal"''':Este icono recibe como parámetro un icono de señal (imagen o texto), y nos dice si la cámara lo esta viendo o no.

'''"Distancia Señal"''':Este icono devuelve la distancia trigonométrica desde la cámara hasta el centro de la señal, la magnitud utilizada son mm.

El resto se autogenera leyendo el archivo pattern_detection/library/multiPatternDetection/Data/object_data, en este archivo están todos las marcas que se pueden ver con la paleta, uno de los datos que se ponen dentro es un identificador (nombre) que al iniciarse se lee y luego se busca en la carpeta pattern_detection/images/ si tiene el icono correspondiente, si está pone la imagen como aparece en la paleta, sino lo encuentra generara el icono pero con el texto del nombre. En la sección [[Butia_reconocimiento_marcas]] se puede ver las características de estos iconos.

En este ejemplo se puede ver como se utiliza, en el código de la izquierda si la cámara ve, la señal de curva, moverá 100 la tortuga hacia adelante y luego girara a la derecha un angulo aleatorio entre -30 y 30.
En el ejemplo de la derecha si ve la señal de ''Contramano'' se movera hacia atras y cambiara la pluma a rojo, sino cambiara a azul y se movera 100 hacia adelante

[[Archivo:reconociendo_seniales_Ejemplo.png|700px]]

==== Ejemplos usando la paleta y Butia ====

Usando la marca de ''Pare'', el Butia detiene la marcha.

[[Archivo:ButiaSenialesEjemplo1.png|300px|left]] <videoflash>vF9ZhQYIwVg</videoflash>

 Usando la marca de ''Ceda el paso'', el Butia disminuye la velocidad.

[[Archivo:ButiaSenialesEjemplo2.png|300px|left]]<videoflash>Mbs5GT8vuIM</videoflash>

 Usando la marca de ''Contramano'', el Butia gira hasta no ver la marca y luego sigue adelante.

[[Archivo:ButiaSenialesEjemplo3.png|300px|left]] <videoflash>m04N9YJ7qd4</videoflash>

=== Desafíos y problemas encontrados ===
* La librería ARToolKit requiere la librería libglut.so.3 para funcionar, sin embargo en las XO no es posible instalar la librería en carpetas del sistema. Esto causa que al intentar cargar la librería con C types en python se devuelva el error ''OSError: libglut.so.3: cannot open shared object file: No such file or directory''. Para evitar este problema, se adjunta la librería en la carpeta del plugin y se carga en python previo a cargar la librería de ARToolkit con el siguiente comando: ''cdll.LoadLibrary("lib/libglut.so.3")''.

== Instalación de plugin ==
===Compilar archivos===
Son necesarias los siguientes paquetes debian para poder compilar:
libglib2.0-dev, freeglut3-dev, libgstreamer0.10-dev, libxi-dev

===Ejecución===
Para la ejecución del plugin es necesario instalar el paquete gst-plugins-good.

Si se ejecuta en una máquina configurada en idioma inglés, es necesario substituir "0,0" por "0.0" en el archivo turtle_art_plugin/pattern_recognition/library/multiPatternRecognition/Data/object_data.

===Correr script de prueba===
Opcionalmente, es posible correr pruebas para asegurarse que la detección de marcas está funcionando correctamente.

En la carpeta turtle_art_plugin/pattern_recognition/doc del código butiá, hay un pdf con la marca NotEnter. Imprimir el pdf.

Luego, ejecutar turtle_art_plugin/pattern_recognition/library/apiTestDetectMarkers.py. Al posicionar la marca impresa frente a la cámara, debería imprimirse un número en consola, que representa la distancia a la marca detectada.

== Generación de nuevas marcas ==
TODO: Generación de pdf con marca para imprimir.

Luego de generados los archivos para imprimir, se deberán generar los archivos de patrones.
Para realizar esto:
# Acceder al [[Generador de patrones para plugin Reconocimento de marcas]]
# Seleccionar el origen de donde se generará el patrón. Si se utiliza la cámara, seleccionar ''Camera Mode''. Si se carga la imagen del patrón (incluyendo el recuadro negro) desde un archivo, seleccionar ''Load marker Image''
# Seleccionar tamaño de patrón, por ejemplo, si el patrón (incluyendo el recuadro negro) mide 16x16 cm, seleccionar ''16x16''
# Seleccionar porcentaje del recuadro que representa el patrón. Por ejemplo, si todo el recuadro mide 16cm y el borde negro mide 2cm, el patrón mide 12x12cm, por lo tanto 75%.
# Una vez que se vea un recuadro rojo alrededor de la marca con el rectángulo negro, presionar el botón ''Get Pattern''. Aparecerá un recuadro con los patrones reconocidos, navegar con el botón ''next'' al deseado y presionar ''Save current''. Darle un nombre al archivo en minúsculas, con la extensión '''.patt''', por ejemplo mimarca.patt

En este punto se tiene el archivo .patt generado y como último paso se debe configurar el plugin para poder comenzar a utilizarlo. Para esto:
# Copiar archivo generado (extensión .patt) a la carpeta ''pattern_detection/library/multiPatternDetection/Data/''
# Editar el archivo '''object_data''' en esa misma carpeta:
## Incrementar en 1 el número que aparece al principio (Cantidad de marcas a ser detectados).
## Agregar a continuación en el mismo archivo las líneas correspondientes al patrón, de la siguiente manera:
### Una línea representando el id de la marca
### Línea con el nombre de archivo .patt generado anteriormente
### Línea conteniendo tamaño en milímetros de la marca
### Línea conteniendo 2 decimales, separados por 1 espacio representando el punto medio de la marca.
## Guardar el archivo y cerrar.
# La marca está lista para ser utilizada y aparecerá en la paleta de Tortugarte luego de reiniciar. Por defecto aparecerá un texto con el id de la marca, pero es posible agregar un ícono, generando 1 imagen en formato svg y colocándola en la carpeta '''images/'''. Por ejemplo, para la marca con id '''Stop''' dentro del archivo '''object_data''', se debe generar 2 imágenes, una nombrándola como '''Stop'''small.svg de 40x40px y creando una copia de la misma con el nombre '''Stop'''off.svg pero de 70x70px.

=== Actividad para agregar marcas ===

Se creo una actividad por la cual se puede agregar o quitar marcas, de una manera mas amena al usuario (docentes o educandos), se puede descargar la misma desde (Agregar link),
La actividad se puede instalar sin tener el Plugin o Tortugarte/TortuBots, pero al abrirla avisa al usuario que no se encuentra alguno de estos elementos.
En la primer pestaña se puede ver una lista con los identificadores de las señales que están instaladas.

[[Archivo:NewPattersSegundaPestaña.png|600px]]

Si existe un icono asociado se muestra a la derecha al seleccionarlo, si no lo tiene se muestra un icono general.

[[Archivo:NewPatternsListaConSeleccion.png|600px]]

En la segunda pestaña se encuentran los campos para poder agregar una señal, Identificador, tamaño, ruta al archivo .patt y como opcional la ruta al archivo .svg que servirá de icono en la paleta.

[[Archivo:NewPattersSegundaPestaña.png|600px]]

En esta pestaña se encuentra el link a la wiki que dice como generar el .patt
En el caso que se quiera poner una identificador de señal que ya exista, la actividad preguntara si se quiere sobrescribir.

== Trabajos a Futuro ==
* '''Mayor versatilidad para marcas''': El reconocimiento de marcas con ARToolKit facilitó el desarrollo de la solución, ya que al ser utilizado en otras actividades en las terminales XO acortaba el tiempo del proyecto, ya que no se tuvo que hacer un análisis de factibilidad y se tenía la librería ya compilada para los mismos, además que la generación de patrones ya viene resuelta. Sin embargo, al utilizar este API, las marcas están limitadas a una forma cuadrada y que estén contenidas dentro de un recuadro negro. Para poder evitar estas limitantes se sugiere utilizar un API de más bajo nivel como OpenCV para poder reconocer otros tipos de marcas, como por ejemplo, personas, caras, objetos, etc.
* <strike>'''Bloque para obtener distancia a marca''': La librería creada en C actualiza el estado de las marcas cuando detecta la presencia de las mismas. Entre esa información, se encuentra una matriz que tiene la posición de la marca respecto a la cámara. Se sugiere que con esta información se cree un nuevo bloque '''Distancia a la marca''', similar al detectar marca, que reciba como parámetro el id de marca y devuelva la distancia a la marca.</strike>
* <strike> '''Internacionalización''': La paleta desarrollada se realizó en idioma español, pero sería recomendable internacionalizar las etiquetas para que pueda ser localizado a otros idiomas de TurtleArt, por lo menos en inglés.</strike>

Butia reconocimiento marcas

2013-02-05T21:36:10Z

Rsisto: /* Paleta reconocimiento de marcas */

== Integrantes ==
* Nicolás Fúrquez
* Rafael Sisto

== Objetivos ==
* Utilizando [http://www.hitl.washington.edu/artoolkit/ ARToolKit] construir un plugin para Tortugarte/Tortublocks que permita reconocer las marcas. Esto puede ser utilizado para que el robot se localice y navegue en un entorno.

Ejemplos de marcas: 
[[Archivo:StopMark.png|300px]] [[Archivo:YieldMark.png|300px]]

Una de las cosas que nos permite la librería (ARToolKit) es que las marcas no necesariamente tienen que estar en color, permitiendo así imprimirlas en cualquier impresora siempre y cuando se mantenga el tamaño.

== Documentación de la solución ==
Se desarrolló un api que obtiene la información almacenada de las marcas y mediante la ayuda de ARToolKit se detectan las mismas en las capturas de la cámara.

El código fuente e instrucciones de instalación se pueden encontrar en el repositorio utilizado:
[https://github.com/rsisto/multiPatternRecognition multiPatternRecognition]

=== Diagrama de componentes ===
En el siguiente diagrama pueden visualizarse los componentes y su interacción. pattern_detection funciona como plugin de TurtleBlocks, que a su vez utiliza la librería multiPatternDetection (a través de un binding de python a C). Esta última utiliza funciones de ARToolKit para la detección de marcas.

[[Archivo:Arq_pattern_detection.png|400px|Arquitectura de detección de patrones con ARToolKit]]

=== Paleta reconocimiento de marcas ===
Paleta:

[[Archivo:Paleta_reco_marcas.png|700px]]

La paleta posee botones fijos que son:

'''"Viendo Señal"''':Este icono recibe como parámetro un icono de señal (imagen o texto), y nos dice si la cámara lo esta viendo o no.

'''"Distancia Señal"''':Este icono devuelve la distancia trigonométrica desde la cámara hasta el centro de la señal, la magnitud utilizada son mm.

El resto se autogenera leyendo el archivo pattern_detection/library/multiPatternDetection/Data/object_data, en este archivo están todos las marcas que se pueden ver con la paleta, uno de los datos que se ponen dentro es un identificador (nombre) que al iniciarse se lee y luego se busca en la carpeta pattern_detection/images/ si tiene el icono correspondiente, si está pone la imagen como aparece en la paleta, sino lo encuentra generara el icono pero con el texto del nombre. En la sección [[Butia_reconocimiento_marcas]] se puede ver las características de estos iconos.

En este ejemplo se puede ver como se utiliza, en el código de la izquierda si la cámara ve, la señal de curva, moverá 100 la tortuga hacia adelante y luego girara a la derecha un angulo aleatorio entre -30 y 30.
En el ejemplo de la derecha si ve la señal de ''Contramano'' se movera hacia atras y cambiara la pluma a rojo, sino cambiara a azul y se movera 100 hacia adelante

[[Archivo:reconociendo_seniales_Ejemplo.png|700px]]

==== Ejemplos usando la paleta y Butia ====

Usando la marca de ''Pare'', el Butia detiene la marcha.

[[Archivo:ButiaSenialesEjemplo1.png|300px|left]] <videoflash>vF9ZhQYIwVg</videoflash>

 Usando la marca de ''Ceda el paso'', el Butia disminuye la velocidad.

[[Archivo:ButiaSenialesEjemplo2.png|300px|left]]<videoflash>Mbs5GT8vuIM</videoflash>

 Usando la marca de ''Contramano'', el Butia gira hasta no ver la marca y luego sigue adelante.

[[Archivo:ButiaSenialesEjemplo3.png|300px|left]] <videoflash>m04N9YJ7qd4</videoflash>

=== Desafíos y problemas encontrados ===
* La librería ARToolKit requiere la librería libglut.so.3 para funcionar, sin embargo en las XO no es posible instalar la librería en carpetas del sistema. Esto causa que al intentar cargar la librería con C types en python se devuelva el error ''OSError: libglut.so.3: cannot open shared object file: No such file or directory''. Para evitar este problema, se adjunta la librería en la carpeta del plugin y se carga en python previo a cargar la librería de ARToolkit con el siguiente comando: ''cdll.LoadLibrary("lib/libglut.so.3")''.

== Instalación de plugin ==
===Compilar archivos===
Son necesarias los siguientes paquetes debian para poder compilar:
libglib2.0-dev, freeglut3-dev, libgstreamer0.10-dev, libxi-dev

===Ejecución===
Para la ejecución del plugin es necesario instalar el paquete gst-plugins-good.

Si se ejecuta en una máquina configurada en idioma inglés, es necesario substituir "0,0" por "0.0" en el archivo turtle_art_plugin/pattern_recognition/library/multiPatternRecognition/Data/object_data.

===Correr script de prueba===
Opcionalmente, es posible correr pruebas para asegurarse que la detección de marcas está funcionando correctamente.

En la carpeta turtle_art_plugin/pattern_recognition/doc del código butiá, hay un pdf con la marca NotEnter. Imprimir el pdf.

Luego, ejecutar turtle_art_plugin/pattern_recognition/library/apiTestDetectMarkers.py. Al posicionar la marca impresa frente a la cámara, debería imprimirse un número en consola, que representa la distancia a la marca detectada.

== Generación de nuevas marcas ==
TODO: Generación de pdf con marca para imprimir.

Luego de generados los archivos para imprimir, se deberán generar los archivos de patrones.
Para realizar esto:
# Acceder al [[Generador de patrones para plugin Reconocimento de marcas]]
# Seleccionar el origen de donde se generará el patrón. Si se utiliza la cámara, seleccionar ''Camera Mode''. Si se carga la imagen del patrón (incluyendo el recuadro negro) desde un archivo, seleccionar ''Load marker Image''
# Seleccionar tamaño de patrón, por ejemplo, si el patrón (incluyendo el recuadro negro) mide 16x16 cm, seleccionar ''16x16''
# Seleccionar porcentaje del recuadro que representa el patrón. Por ejemplo, si todo el recuadro mide 16cm y el borde negro mide 2cm, el patrón mide 12x12cm, por lo tanto 75%.
# Una vez que se vea un recuadro rojo alrededor de la marca con el rectángulo negro, presionar el botón ''Get Pattern''. Aparecerá un recuadro con los patrones reconocidos, navegar con el botón ''next'' al deseado y presionar ''Save current''. Darle un nombre al archivo en minúsculas, con la extensión '''.patt''', por ejemplo mimarca.patt

En este punto se tiene el archivo .patt generado y como último paso se debe configurar el plugin para poder comenzar a utilizarlo. Para esto:
# Copiar archivo generado (extensión .patt) a la carpeta ''pattern_detection/library/multiPatternDetection/Data/''
# Editar el archivo '''object_data''' en esa misma carpeta:
## Incrementar en 1 el número que aparece al principio (Cantidad de marcas a ser detectados).
## Agregar a continuación en el mismo archivo las líneas correspondientes al patrón, de la siguiente manera:
### Una línea representando el id de la marca
### Línea con el nombre de archivo .patt generado anteriormente
### Línea conteniendo tamaño en milímetros de la marca
### Línea conteniendo 2 decimales, separados por 1 espacio representando el punto medio de la marca.
## Guardar el archivo y cerrar.
# La marca está lista para ser utilizada y aparecerá en la paleta de Tortugarte luego de reiniciar. Por defecto aparecerá un texto con el id de la marca, pero es posible agregar un ícono, generando 1 imagen en formato svg y colocándola en la carpeta '''images/'''. Por ejemplo, para la marca con id '''Stop''' dentro del archivo '''object_data''', se debe generar 2 imágenes, una nombrándola como '''Stop'''small.svg de 40x40px y creando una copia de la misma con el nombre '''Stop'''off.svg pero de 70x70px.

=== Actividad para agregar marcas ===

Se creo una actividad por la cual se puede agregar o quitar marcas, de una manera mas amena al usuario (docentes o educandos), se puede descargar la misma desde (Agregar link),
La actividad se puede instalar sin tener el Plugin o Tortugarte/TortuBots, pero al abrirla avisa al usuario que no se encuentra alguno de estos elementos.
En la primer pestaña se puede ver una lista con los identificadores de las señales que están instaladas.

[[Archivo:NewPattersSegundaPestaña.png]]
 
Si existe un icono asociado se muestra a la derecha al seleccionarlo, si no lo tiene se muestra un icono general.
TODO:Poner imagenes con ambos ejemplos
[[Archivo:NewPatternsListaConSeleccion.png]]

En la segunda pestaña se encuentran los campos para poder agregar una señal, Identificador, tamaño, ruta al archivo .patt y como opcional la ruta al archivo .svg que servirá de icono en la paleta.
[[Archivo:NewPattersSegundaPestaña.png]]

En esta pestaña se encuentra el link a la wiki que dice como generar el .patt
En el caso que se quiera poner una identificador de señal que ya exista, la actividad preguntara si se quiere sobrescribir.

== Trabajos a Futuro ==
* '''Mayor versatilidad para marcas''': El reconocimiento de marcas con ARToolKit facilitó el desarrollo de la solución, ya que al ser utilizado en otras actividades en las terminales XO acortaba el tiempo del proyecto, ya que no se tuvo que hacer un análisis de factibilidad y se tenía la librería ya compilada para los mismos, además que la generación de patrones ya viene resuelta. Sin embargo, al utilizar este API, las marcas están limitadas a una forma cuadrada y que estén contenidas dentro de un recuadro negro. Para poder evitar estas limitantes se sugiere utilizar un API de más bajo nivel como OpenCV para poder reconocer otros tipos de marcas, como por ejemplo, personas, caras, objetos, etc.
* <strike>'''Bloque para obtener distancia a marca''': La librería creada en C actualiza el estado de las marcas cuando detecta la presencia de las mismas. Entre esa información, se encuentra una matriz que tiene la posición de la marca respecto a la cámara. Se sugiere que con esta información se cree un nuevo bloque '''Distancia a la marca''', similar al detectar marca, que reciba como parámetro el id de marca y devuelva la distancia a la marca.</strike>
* <strike> '''Internacionalización''': La paleta desarrollada se realizó en idioma español, pero sería recomendable internacionalizar las etiquetas para que pueda ser localizado a otros idiomas de TurtleArt, por lo menos en inglés.</strike>

Butia reconocimiento marcas

2013-02-05T21:27:07Z

Rsisto: /* Diagrama de componentes */

== Integrantes ==
* Nicolás Fúrquez
* Rafael Sisto

== Objetivos ==
* Utilizando [http://www.hitl.washington.edu/artoolkit/ ARToolKit] construir un plugin para Tortugarte/Tortublocks que permita reconocer las marcas. Esto puede ser utilizado para que el robot se localice y navegue en un entorno.

Ejemplos de marcas: 
[[Archivo:StopMark.png|300px]] [[Archivo:YieldMark.png|300px]]

Una de las cosas que nos permite la librería (ARToolKit) es que las marcas no necesariamente tienen que estar en color, permitiendo así imprimirlas en cualquier impresora siempre y cuando se mantenga el tamaño.

== Documentación de la solución ==
Se desarrolló un api que obtiene la información almacenada de las marcas y mediante la ayuda de ARToolKit se detectan las mismas en las capturas de la cámara.

El código fuente e instrucciones de instalación se pueden encontrar en el repositorio utilizado:
[https://github.com/rsisto/multiPatternRecognition multiPatternRecognition]

=== Diagrama de componentes ===
En el siguiente diagrama pueden visualizarse los componentes y su interacción. pattern_detection funciona como plugin de TurtleBlocks, que a su vez utiliza la librería multiPatternDetection (a través de un binding de python a C). Esta última utiliza funciones de ARToolKit para la detección de marcas.

[[Archivo:Arq_pattern_detection.png|400px|Arquitectura de detección de patrones con ARToolKit]]

=== Paleta reconocimiento de marcas ===
Paleta:
[[Archivo:Paleta_reco_marcas.png]]
La paleta posee botones fijos que son:

'''"Viendo Señal"''':Este icono recibe como parámetro un icono de señal (imagen o texto), y nos dice si la cámara lo esta viendo o no.

'''"Distancia Señal"''':Este icono devuelve la distancia trigonométrica desde la cámara hasta el centro de la señal, la magnitud utilizada son mm.

El resto se autogenera leyendo el archivo pattern_detection/library/multiPatternDetection/Data/object_data, en este archivo están todos las marcas que se pueden ver con la paleta, uno de los datos que se ponen dentro es un identificador (nombre) que al iniciarse se lee y luego se busca en la carpeta pattern_detection/images/ si tiene el icono correspondiente, si está pone la imagen como aparece en la paleta, sino lo encuentra generara el icono pero con el texto del nombre. En la sección [[Butia_reconocimiento_marcas]] se puede ver las características de estos iconos.

En este ejemplo se puede ver como se utiliza, en el código de la izquierda si la cámara ve, la señal de curva, moverá 100 la tortuga hacia adelante y luego girara a la derecha un angulo aleatorio entre -30 y 30.
En el ejemplo de la derecha si ve la señal de ''Contramano'' se movera hacia atras y cambiara la pluma a rojo, sino cambiara a azul y se movera 100 hacia adelante

[[Archivo:reconociendo_seniales_Ejemplo.png]]

==== Ejemplos usando la paleta y Butia ====
Usando la marca de ''Pare'', el Butia detiene la marcha. 
[[Archivo:ButiaSenialesEjemplo1.png|400px|left]] <videoflash>vF9ZhQYIwVg</videoflash> 
Usando la marca de ''Ceda el paso'', el Butia disminuye la velocidad. 
[[Archivo:ButiaSenialesEjemplo2.png|350px|left]]<videoflash>Mbs5GT8vuIM</videoflash> 
Usando la marca de ''Contramano'', el Butia gira hasta no ver la marca y luego sigue adelante. 
[[Archivo:ButiaSenialesEjemplo3.png|300px|left]] <videoflash>m04N9YJ7qd4</videoflash>

=== Desafíos y problemas encontrados ===
* La librería ARToolKit requiere la librería libglut.so.3 para funcionar, sin embargo en las XO no es posible instalar la librería en carpetas del sistema. Esto causa que al intentar cargar la librería con C types en python se devuelva el error ''OSError: libglut.so.3: cannot open shared object file: No such file or directory''. Para evitar este problema, se adjunta la librería en la carpeta del plugin y se carga en python previo a cargar la librería de ARToolkit con el siguiente comando: ''cdll.LoadLibrary("lib/libglut.so.3")''.

== Instalación de plugin ==
===Compilar archivos===
Son necesarias los siguientes paquetes debian para poder compilar:
libglib2.0-dev, freeglut3-dev, libgstreamer0.10-dev, libxi-dev

===Ejecución===
Para la ejecución del plugin es necesario instalar el paquete gst-plugins-good.

Si se ejecuta en una máquina configurada en idioma inglés, es necesario substituir "0,0" por "0.0" en el archivo turtle_art_plugin/pattern_recognition/library/multiPatternRecognition/Data/object_data.

===Correr script de prueba===
Opcionalmente, es posible correr pruebas para asegurarse que la detección de marcas está funcionando correctamente.

En la carpeta turtle_art_plugin/pattern_recognition/doc del código butiá, hay un pdf con la marca NotEnter. Imprimir el pdf.

Luego, ejecutar turtle_art_plugin/pattern_recognition/library/apiTestDetectMarkers.py. Al posicionar la marca impresa frente a la cámara, debería imprimirse un número en consola, que representa la distancia a la marca detectada.

== Generación de nuevas marcas ==
TODO: Generación de pdf con marca para imprimir.

Luego de generados los archivos para imprimir, se deberán generar los archivos de patrones.
Para realizar esto:
# Acceder al [[Generador de patrones para plugin Reconocimento de marcas]]
# Seleccionar el origen de donde se generará el patrón. Si se utiliza la cámara, seleccionar ''Camera Mode''. Si se carga la imagen del patrón (incluyendo el recuadro negro) desde un archivo, seleccionar ''Load marker Image''
# Seleccionar tamaño de patrón, por ejemplo, si el patrón (incluyendo el recuadro negro) mide 16x16 cm, seleccionar ''16x16''
# Seleccionar porcentaje del recuadro que representa el patrón. Por ejemplo, si todo el recuadro mide 16cm y el borde negro mide 2cm, el patrón mide 12x12cm, por lo tanto 75%.
# Una vez que se vea un recuadro rojo alrededor de la marca con el rectángulo negro, presionar el botón ''Get Pattern''. Aparecerá un recuadro con los patrones reconocidos, navegar con el botón ''next'' al deseado y presionar ''Save current''. Darle un nombre al archivo en minúsculas, con la extensión '''.patt''', por ejemplo mimarca.patt

En este punto se tiene el archivo .patt generado y como último paso se debe configurar el plugin para poder comenzar a utilizarlo. Para esto:
# Copiar archivo generado (extensión .patt) a la carpeta ''pattern_detection/library/multiPatternDetection/Data/''
# Editar el archivo '''object_data''' en esa misma carpeta:
## Incrementar en 1 el número que aparece al principio (Cantidad de marcas a ser detectados).
## Agregar a continuación en el mismo archivo las líneas correspondientes al patrón, de la siguiente manera:
### Una línea representando el id de la marca
### Línea con el nombre de archivo .patt generado anteriormente
### Línea conteniendo tamaño en milímetros de la marca
### Línea conteniendo 2 decimales, separados por 1 espacio representando el punto medio de la marca.
## Guardar el archivo y cerrar.
# La marca está lista para ser utilizada y aparecerá en la paleta de Tortugarte luego de reiniciar. Por defecto aparecerá un texto con el id de la marca, pero es posible agregar un ícono, generando 1 imagen en formato svg y colocándola en la carpeta '''images/'''. Por ejemplo, para la marca con id '''Stop''' dentro del archivo '''object_data''', se debe generar 2 imágenes, una nombrándola como '''Stop'''small.svg de 40x40px y creando una copia de la misma con el nombre '''Stop'''off.svg pero de 70x70px.

=== Actividad para agregar marcas ===

Se creo una actividad por la cual se puede agregar o quitar marcas, de una manera mas amena al usuario (docentes o educandos), se puede descargar la misma desde (Agregar link),
La actividad se puede instalar sin tener el Plugin o Tortugarte/TortuBots, pero al abrirla avisa al usuario que no se encuentra alguno de estos elementos.
En la primer pestaña se puede ver una lista con los identificadores de las señales que están instaladas.

[[Archivo:NewPattersSegundaPestaña.png]]
 
Si existe un icono asociado se muestra a la derecha al seleccionarlo, si no lo tiene se muestra un icono general.
TODO:Poner imagenes con ambos ejemplos
[[Archivo:NewPatternsListaConSeleccion.png]]

En la segunda pestaña se encuentran los campos para poder agregar una señal, Identificador, tamaño, ruta al archivo .patt y como opcional la ruta al archivo .svg que servirá de icono en la paleta.
[[Archivo:NewPattersSegundaPestaña.png]]

En esta pestaña se encuentra el link a la wiki que dice como generar el .patt
En el caso que se quiera poner una identificador de señal que ya exista, la actividad preguntara si se quiere sobrescribir.

== Trabajos a Futuro ==
* '''Mayor versatilidad para marcas''': El reconocimiento de marcas con ARToolKit facilitó el desarrollo de la solución, ya que al ser utilizado en otras actividades en las terminales XO acortaba el tiempo del proyecto, ya que no se tuvo que hacer un análisis de factibilidad y se tenía la librería ya compilada para los mismos, además que la generación de patrones ya viene resuelta. Sin embargo, al utilizar este API, las marcas están limitadas a una forma cuadrada y que estén contenidas dentro de un recuadro negro. Para poder evitar estas limitantes se sugiere utilizar un API de más bajo nivel como OpenCV para poder reconocer otros tipos de marcas, como por ejemplo, personas, caras, objetos, etc.
* <strike>'''Bloque para obtener distancia a marca''': La librería creada en C actualiza el estado de las marcas cuando detecta la presencia de las mismas. Entre esa información, se encuentra una matriz que tiene la posición de la marca respecto a la cámara. Se sugiere que con esta información se cree un nuevo bloque '''Distancia a la marca''', similar al detectar marca, que reciba como parámetro el id de marca y devuelva la distancia a la marca.</strike>
* <strike> '''Internacionalización''': La paleta desarrollada se realizó en idioma español, pero sería recomendable internacionalizar las etiquetas para que pueda ser localizado a otros idiomas de TurtleArt, por lo menos en inglés.</strike>