Proyecto Butiá - Contribuciones del usuario [es]

Git Butia

2017-04-05T03:25:48Z

AlanJAS: /* Versión estable */

Se explicara la estructura del Git Butia, como esta organizado, bajarse una version estable y compilarlo.

== Empezando con Git ==
Primero que nada es necesario saber como usar git, para ello se recomienda leer algun tutorial por la web ANTES de seguir leyendo esta wiki

== Bajando el Git ==
Para descargar el Git vamos a una terminal y ejecutamos:
git clone git://git.code.sf.net/p/butia/code --recursive

El parámetro "recursive" se encarga de descargar los submódulos necesarios para ejecutar TurtleBots.

Luego de bajar el git, vamos a la carpeta "turtlebots"
cd turtlebots

== Estructura del Git ==

El GIT está compuesto de varias carpetas que mantienen distintas partes vitales del todo:

bobot
butiaXO
docs
firmware código de la actividad Firmware Update
lualibusb: binding para USB en Lua
pybot
serialcomm binding para serial en Lua
turtle_art_plugin todos los plugins
butialo código de la actividad Butialo
dibujos
examples
libs
newPatterns
pythonAPI
Seguidor
usb4all

== Versión estable ==
Es importante utilizar una versión ESTABLE!
Por ejemplo si queremos utilizar la "versión 30":
git checkout v30

== Compilando ==

Si estamos en una versión estable:
cd turtlebots # ir a la carpeta tortubots
make dev # genera en tmp el TurtleBots

Para ejecutarlo:
cd tmp
./turtleblocks.py

También, si tenemos un emulador de Sugar, como el "sugar-emulator" este comando genera
una instalación para poder usarlo desde allí.

Para generar un .XO, estando en la carpeta "turtlebots":
make xo

Eso nos crea en la carpeta el .XO

== Generando .deb ==

Para generar un .deb vamos a la carpeta:
cd turtlebots

y ejecutamos:
dpkg-buildpackage

Luego de finalizado, encontraremos el paquete una carpeta arriba de la actual.

Git Butia

2017-04-05T03:24:14Z

AlanJAS: /* Versión estable */

Se explicara la estructura del Git Butia, como esta organizado, bajarse una version estable y compilarlo.

== Empezando con Git ==
Primero que nada es necesario saber como usar git, para ello se recomienda leer algun tutorial por la web ANTES de seguir leyendo esta wiki

== Bajando el Git ==
Para descargar el Git vamos a una terminal y ejecutamos:
git clone git://git.code.sf.net/p/butia/code --recursive

El parámetro "recursive" se encarga de descargar los submódulos necesarios para ejecutar TurtleBots.

Luego de bajar el git, vamos a la carpeta "turtlebots"
cd turtlebots

== Estructura del Git ==

El GIT está compuesto de varias carpetas que mantienen distintas partes vitales del todo:

bobot
butiaXO
docs
firmware código de la actividad Firmware Update
lualibusb: binding para USB en Lua
pybot
serialcomm binding para serial en Lua
turtle_art_plugin todos los plugins
butialo código de la actividad Butialo
dibujos
examples
libs
newPatterns
pythonAPI
Seguidor
usb4all

== Versión estable ==
Es importante utilizar una versión ESTABLE!
Por ejemplo si queremos utilizar la "versión 30":
git checkout -b v30

== Compilando ==

Si estamos en una versión estable:
cd turtlebots # ir a la carpeta tortubots
make dev # genera en tmp el TurtleBots

Para ejecutarlo:
cd tmp
./turtleblocks.py

También, si tenemos un emulador de Sugar, como el "sugar-emulator" este comando genera
una instalación para poder usarlo desde allí.

Para generar un .XO, estando en la carpeta "turtlebots":
make xo

Eso nos crea en la carpeta el .XO

== Generando .deb ==

Para generar un .deb vamos a la carpeta:
cd turtlebots

y ejecutamos:
dpkg-buildpackage

Luego de finalizado, encontraremos el paquete una carpeta arriba de la actual.

Git Butia

2017-04-05T03:17:47Z

AlanJAS: /* Versión estable */

Se explicara la estructura del Git Butia, como esta organizado, bajarse una version estable y compilarlo.

== Empezando con Git ==
Primero que nada es necesario saber como usar git, para ello se recomienda leer algun tutorial por la web ANTES de seguir leyendo esta wiki

== Bajando el Git ==
Para descargar el Git vamos a una terminal y ejecutamos:
git clone git://git.code.sf.net/p/butia/code --recursive

El parámetro "recursive" se encarga de descargar los submódulos necesarios para ejecutar TurtleBots.

Luego de bajar el git, vamos a la carpeta "turtlebots"
cd turtlebots

== Estructura del Git ==

El GIT está compuesto de varias carpetas que mantienen distintas partes vitales del todo:

bobot
butiaXO
docs
firmware código de la actividad Firmware Update
lualibusb: binding para USB en Lua
pybot
serialcomm binding para serial en Lua
turtle_art_plugin todos los plugins
butialo código de la actividad Butialo
dibujos
examples
libs
newPatterns
pythonAPI
Seguidor
usb4all

== Versión estable ==
Es importante utilizar una versión ESTABLE!
Por ejemplo si queremos utilizar la "versión 23":
git checkout -b v30

== Compilando ==

Si estamos en una versión estable:
cd turtlebots # ir a la carpeta tortubots
make dev # genera en tmp el TurtleBots

Para ejecutarlo:
cd tmp
./turtleblocks.py

También, si tenemos un emulador de Sugar, como el "sugar-emulator" este comando genera
una instalación para poder usarlo desde allí.

Para generar un .XO, estando en la carpeta "turtlebots":
make xo

Eso nos crea en la carpeta el .XO

== Generando .deb ==

Para generar un .deb vamos a la carpeta:
cd turtlebots

y ejecutamos:
dpkg-buildpackage

Luego de finalizado, encontraremos el paquete una carpeta arriba de la actual.

Shield CC

2014-04-11T21:01:13Z

AlanJAS: /* Otros datos */

== Shield para Motores de Corriente Contínua ==

[[Archivo:Shield_2.JPG | 400px]]

Un "Shield" podríamos decir que es una plaqueta secundaria que se anexa o se "enchufa" sobre otra placa principal para agregarle alguna funcionalidad.
En este caso el Shield CC es una placa que se agrega al USB4Butiá para utilizar motores de Corriente Contínua en lugar de los AX12.

'''Principio de funcionamiento:'''
Esta plaqueta utiliza un circuito integrado (L298) que contiene en su interior un conjunto de transistores conectados de tal forma que nos permite controlar, usando algunos pines de la USB4Butiá, el giro de los motores de CC.
Esta placa utiliza los HackPins 5, 6, 7 y 8 de la USB4Butia para controlar los motores de CC que mueven al butiá.

Para que desde TortuBots se pueda controlar a los motores de CC con la misma sencillez que se hace con los AX12, es decir con comandos simples como Adelante, Atras, etc, es necesario tener:
* la versión 20 de TortuBots
* la versión 1.9 o superior de placa USB4Butia
* la versión 7.0 de firmware en la usb4butiá.

== Lista de materiales: ==

Para realizar el shield es necesario adquirir los siguientes componentes:

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Lista de materiales para el USB4Butiá motor shield'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-search/en?vendor=0&keywords=L298HN L298HN]|| 1 ||IC BRIDGE DRIVER PAR 15MULTIWATT||U1 L298
|-
|1A7||8||diode type 1N4001 o 1N4007||D1..D8
|-
|male headers pins ||14||Contact spacing 2.54mm (0.1")||P1..P4
|-
|100nF (10V minimum, 20% tolerance)||2||ceramic capacitor||C1, C2
|-
|}

== Placa PCB: ==

Hay dos versiones de la placa, originalmente pensadas para las versiones vertical y 90º del L298 (L298n, y L928hn respectivamente).

La placa del L298hn es doble faz, lo que dificulta su ejecución a mano: 
[[Archivo:L298hn_doble_faz.PNG|300px]]

Especificaciones de la placa pcb:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/shield_l298hn.zip Archivos gerber para fabricación]

La placa del L298n puede ejcutarse en simple faz agregando unos puentes (en rojo). 
[[Archivo:L298n_simple_faz.PNG|300px]]

Especificaciones de la placa pcb:
* Cualquiera simple faz
* [http://sourceforge.net/p/usb4all/code/ci/master/tree/pcb/puenteH/l298/gerber/ Archivos gerber para fabricación]

== Construcción a mano ==

Para el método manual existen 2 pdf con las respectivas versiones (para el L298n y para el L298hn):
* [http://www.fing.edu.uy/inco/proyectos/butia/files/hardware/l298n-copper.pdf L298N]
* [http://www.fing.edu.uy/inco/proyectos/butia/files/hardware/l298hn-copper.pdf L298HN]

Se puede utilizar a modo de ejemplo el instructivo utilizado para la USB4Butiá: [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/USB4buti%C3%A1_tutorial Tutorial USB4Butiá]

Otra alternativa es enviando los archivos gerber a (SeedStudio: [http://www.seeedstudio.com/depot/fusion-pcb-service-p-835.html?cPath=185]).

* Montar los componentes como están en la foto:
[[Archivo:Shield-mejorado.png]]

== Utilizando el shield ==

Para que la placa USB4Butiá reconozca el shield, deberá tener:

* Firmware v7 (o posterior)

* Utilizar TortuBots v20 (o posterior)

== Otros datos ==

Ver Hoja de datos del integrado L293: [http://pdf.datasheetcatalog.com/datasheet/SGSThomsonMicroelectronics/mXrqqxz.pdf]

Ver Archivos fuente (Kicad) para realizar el circuito impreso:[http://sourceforge.net/p/usb4all/code/ci/PCBs/tree/pcb/puenteH/l298/]

Imagen para imprimir y realizar el circuito manualmente (ver Construcción a mano)

Shield CC

2014-04-11T21:00:57Z

AlanJAS: /* Utilizando el shield */

Archivo:Shield-mejorado.png

2014-04-11T20:56:31Z

AlanJAS:

Shield CC

2014-04-11T20:56:13Z

AlanJAS: /* Método de conexión */

== Shield para Motores de Corriente Contínua ==

[[Archivo:Shield_2.JPG | 400px]]

Un "Shield" podríamos decir que es una plaqueta secundaria que se anexa o se "enchufa" sobre otra placa principal para agregarle alguna funcionalidad.
En este caso el Shield CC es una placa que se agrega al USB4Butiá para utilizar motores de Corriente Contínua en lugar de los AX12.

'''Principio de funcionamiento:'''
Esta plaqueta utiliza un circuito integrado (L298) que contiene en su interior un conjunto de transistores conectados de tal forma que nos permite controlar, usando algunos pines de la USB4Butiá, el giro de los motores de CC.
Esta placa utiliza los HackPins 5, 6, 7 y 8 de la USB4Butia para controlar los motores de CC que mueven al butiá.

Para que desde TortuBots se pueda controlar a los motores de CC con la misma sencillez que se hace con los AX12, es decir con comandos simples como Adelante, Atras, etc, es necesario tener:
* la versión 20 de TortuBots
* la versión 1.9 o superior de placa USB4Butia
* la versión 7.0 de firmware en la usb4butiá.

== Lista de materiales: ==

Para realizar el shield es necesario adquirir los siguientes componentes:

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Lista de materiales para el USB4Butiá motor shield'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-search/en?vendor=0&keywords=L298HN L298HN]|| 1 ||IC BRIDGE DRIVER PAR 15MULTIWATT||U1 L298
|-
|1A7||8||diode type 1N4001 o 1N4007||D1..D8
|-
|male headers pins ||14||Contact spacing 2.54mm (0.1")||P1..P4
|-
|100nF (10V minimum, 20% tolerance)||2||ceramic capacitor||C1, C2
|-
|}

== Placa PCB: ==

Hay dos versiones de la placa, originalmente pensadas para las versiones vertical y 90º del L298 (L298n, y L928hn respectivamente).

La placa del L298hn es doble faz, lo que dificulta su ejecución a mano: 
[[Archivo:L298hn_doble_faz.PNG|300px]]

Especificaciones de la placa pcb:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/shield_l298hn.zip Archivos gerber para fabricación]

La placa del L298n puede ejcutarse en simple faz agregando unos puentes (en rojo). 
[[Archivo:L298n_simple_faz.PNG|300px]]

Especificaciones de la placa pcb:
* Cualquiera simple faz
* [http://sourceforge.net/p/usb4all/code/ci/master/tree/pcb/puenteH/l298/gerber/ Archivos gerber para fabricación]

== Construcción a mano ==

Para el método manual existen 2 pdf con las respectivas versiones (para el L298n y para el L298hn):
* [http://www.fing.edu.uy/inco/proyectos/butia/files/hardware/l298n-copper.pdf L298N]
* [http://www.fing.edu.uy/inco/proyectos/butia/files/hardware/l298hn-copper.pdf L298HN]

Se puede utilizar a modo de ejemplo el instructivo utilizado para la USB4Butiá: [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/USB4buti%C3%A1_tutorial Tutorial USB4Butiá]

Otra alternativa es enviando los archivos gerber a (SeedStudio: [http://www.seeedstudio.com/depot/fusion-pcb-service-p-835.html?cPath=185]).

* Montar los componentes como están en la foto:
[[Archivo:Shield-mejorado.png]]

== Utilizando el shield ==

Para que la placa USB4Butiá reconozca el shield, deberá tener:

* Firmware v7 (o posterior)

* Utilizar TortuBots v20 (o posterior)

Ver Hoja de datos del integrado L293: [http://pdf.datasheetcatalog.com/datasheet/SGSThomsonMicroelectronics/mXrqqxz.pdf]
Ver Circuito esquemático del shield:[[Archivo:CircuitoShield.jpg]]
Ver Archivos fuente (Kicad) para realizar el circuito impreso:[http://sourceforge.net/p/usb4all/code/ci/PCBs/tree/pcb/puenteH/l298/]
Imagen para imprimir y realizar el circuito manualmente:[[Archivo:ShieldCu.jpg]]

Ejemplos

2014-03-29T21:01:35Z

AlanJAS: /* Seguidor de líneas a ambos lados */

== Seguidor de líneas a ambos lados ==
<syntaxhighlight lang="python">
#si no estoy en la carpeta
import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

from pybot import usb4butia
import time

robot = usb4butia.USB4Butia()

i = 0
veces = 1
gireDerecha = 0
#inicializacion de variables

while i<200:
#creamos la variable i para que se ejecutara 199 veces y no por siempre
i += 1
linea = robot.getGray()
print linea
#guardamos el valor del sensor en linea y lo imprime en pantalla

if linea > 2000:
veces = 1
robot.set2MotorSpeed(0, 400, 0, 400)
#si el valor del sensor es >2000 los motores avanzan
else:
if gireDerecha == 1:
#si gire a la derecha ahora giro a la izq
robot.set2MotorSpeed(1, 400, 0, 400)
gireDerecha = 0

else:
#si gire a la izquierda ahora giro a la der
robot.set2MotorSpeed(0, 400, 1, 400)
gireDerecha = 1

time.sleep(veces * 0.1)
#procesa la info
robot.set2MotorSpeed(0, 0, 0, 0)

veces += 1
#incrementa el angulo de giro
time.sleep(0.2)

robot.set2MotorSpeed(0, 0, 0, 0)
#se detiene
</syntaxhighlight>

Git Butia

2014-03-26T16:59:45Z

AlanJAS: /* Bajando el Git */

Se explicara la estructura del Git Butia, como esta organizado, bajarse una version estable y compilarlo.

== Empezando con Git ==
Primero que nada es necesario saber como usar git, para ello se recomienda leer algun tutorial por la web ANTES de seguir leyendo esta wiki

== Bajando el Git ==
Para descargar el Git vamos a una terminal y ejecutamos:
git clone git://git.code.sf.net/p/butia/code --recursive

El parámetro "recursive" se encarga de descargar los submódulos necesarios para ejecutar TurtleBots.

Luego de bajar el git, vamos a la carpeta "turtlebots"
cd turtlebots

== Estructura del Git ==

El GIT está compuesto de varias carpetas que mantienen distintas partes vitales del todo:

bobot
butiaXO
docs
firmware código de la actividad Firmware Update
lualibusb: binding para USB en Lua
pybot
serialcomm binding para serial en Lua
turtle_art_plugin todos los plugins
butialo código de la actividad Butialo
dibujos
examples
libs
newPatterns
pythonAPI
Seguidor
usb4all

== Versión estable ==
Es importante utilizar una versión ESTABLE!
Por ejemplo si queremos utilizar la "versión 23":
git checkout -b v23

== Compilando ==

Si estamos en una versión estable:
cd turtlebots # ir a la carpeta tortubots
make dev # genera en tmp el TurtleBots

Para ejecutarlo:
cd tmp
./turtleblocks.py

También, si tenemos un emulador de Sugar, como el "sugar-emulator" este comando genera
una instalación para poder usarlo desde allí.

Para generar un .XO, estando en la carpeta "turtlebots":
make xo

Eso nos crea en la carpeta el .XO

== Generando .deb ==

Para generar un .deb vamos a la carpeta:
cd turtlebots

y ejecutamos:
dpkg-buildpackage

Luego de finalizado, encontraremos el paquete una carpeta arriba de la actual.

Git Butia

2014-03-26T16:58:57Z

AlanJAS: /* Generando .deb */

Se explicara la estructura del Git Butia, como esta organizado, bajarse una version estable y compilarlo.

== Empezando con Git ==
Primero que nada es necesario saber como usar git, para ello se recomienda leer algun tutorial por la web ANTES de seguir leyendo esta wiki

== Bajando el Git ==
Para descargar el Git vamos a una terminal y ejecutamos:
git clone git://git.code.sf.net/p/butia/code --recursive

Luego de bajar el git, vamos a la carpeta "turtlebots"
cd turtlebots

== Estructura del Git ==

El GIT está compuesto de varias carpetas que mantienen distintas partes vitales del todo:

bobot
butiaXO
docs
firmware código de la actividad Firmware Update
lualibusb: binding para USB en Lua
pybot
serialcomm binding para serial en Lua
turtle_art_plugin todos los plugins
butialo código de la actividad Butialo
dibujos
examples
libs
newPatterns
pythonAPI
Seguidor
usb4all

== Versión estable ==
Es importante utilizar una versión ESTABLE!
Por ejemplo si queremos utilizar la "versión 23":
git checkout -b v23

== Compilando ==

Si estamos en una versión estable:
cd turtlebots # ir a la carpeta tortubots
make dev # genera en tmp el TurtleBots

Para ejecutarlo:
cd tmp
./turtleblocks.py

También, si tenemos un emulador de Sugar, como el "sugar-emulator" este comando genera
una instalación para poder usarlo desde allí.

Para generar un .XO, estando en la carpeta "turtlebots":
make xo

Eso nos crea en la carpeta el .XO

== Generando .deb ==

Para generar un .deb vamos a la carpeta:
cd turtlebots

y ejecutamos:
dpkg-buildpackage

Luego de finalizado, encontraremos el paquete una carpeta arriba de la actual.

Git Butia

2014-03-26T16:58:38Z

AlanJAS: /* Versión estable */

Se explicara la estructura del Git Butia, como esta organizado, bajarse una version estable y compilarlo.

== Empezando con Git ==
Primero que nada es necesario saber como usar git, para ello se recomienda leer algun tutorial por la web ANTES de seguir leyendo esta wiki

== Bajando el Git ==
Para descargar el Git vamos a una terminal y ejecutamos:
git clone git://git.code.sf.net/p/butia/code --recursive

Luego de bajar el git, vamos a la carpeta "turtlebots"
cd turtlebots

== Estructura del Git ==

El GIT está compuesto de varias carpetas que mantienen distintas partes vitales del todo:

bobot
butiaXO
docs
firmware código de la actividad Firmware Update
lualibusb: binding para USB en Lua
pybot
serialcomm binding para serial en Lua
turtle_art_plugin todos los plugins
butialo código de la actividad Butialo
dibujos
examples
libs
newPatterns
pythonAPI
Seguidor
usb4all

== Versión estable ==
Es importante utilizar una versión ESTABLE!
Por ejemplo si queremos utilizar la "versión 23":
git checkout -b v23

== Compilando ==

Si estamos en una versión estable:
cd turtlebots # ir a la carpeta tortubots
make dev # genera en tmp el TurtleBots

Para ejecutarlo:
cd tmp
./turtleblocks.py

También, si tenemos un emulador de Sugar, como el "sugar-emulator" este comando genera
una instalación para poder usarlo desde allí.

Para generar un .XO, estando en la carpeta "turtlebots":
make xo

Eso nos crea en la carpeta el .XO

== Generando .deb ==

Para generar un .deb vamos a la carpeta:
cd turtle_art_plugin

y ejecutamos:
dpkg-buildpackage

Luego de finalizado, encontraremos el paquete una carpeta arriba de la acrual.

Git Butia

2014-03-26T16:58:17Z

AlanJAS: /* Bajando el Git */

Se explicara la estructura del Git Butia, como esta organizado, bajarse una version estable y compilarlo.

== Empezando con Git ==
Primero que nada es necesario saber como usar git, para ello se recomienda leer algun tutorial por la web ANTES de seguir leyendo esta wiki

== Bajando el Git ==
Para descargar el Git vamos a una terminal y ejecutamos:
git clone git://git.code.sf.net/p/butia/code --recursive

Luego de bajar el git, vamos a la carpeta "turtlebots"
cd turtlebots

== Estructura del Git ==

El GIT está compuesto de varias carpetas que mantienen distintas partes vitales del todo:

bobot
butiaXO
docs
firmware código de la actividad Firmware Update
lualibusb: binding para USB en Lua
pybot
serialcomm binding para serial en Lua
turtle_art_plugin todos los plugins
butialo código de la actividad Butialo
dibujos
examples
libs
newPatterns
pythonAPI
Seguidor
usb4all

== Versión estable ==
Es importante utilizar una versión ESTABLE!
Por ejemplo si queremos utilizar la "versión 18":
git checkout -b v18

== Compilando ==

Si estamos en una versión estable:
cd turtlebots # ir a la carpeta tortubots
make dev # genera en tmp el TurtleBots

Para ejecutarlo:
cd tmp
./turtleblocks.py

También, si tenemos un emulador de Sugar, como el "sugar-emulator" este comando genera
una instalación para poder usarlo desde allí.

Para generar un .XO, estando en la carpeta "turtlebots":
make xo

Eso nos crea en la carpeta el .XO

== Generando .deb ==

Para generar un .deb vamos a la carpeta:
cd turtle_art_plugin

y ejecutamos:
dpkg-buildpackage

Luego de finalizado, encontraremos el paquete una carpeta arriba de la acrual.

Git Butia

2014-03-26T16:43:49Z

AlanJAS: /* Compilando */

Se explicara la estructura del Git Butia, como esta organizado, bajarse una version estable y compilarlo.

== Empezando con Git ==
Primero que nada es necesario saber como usar git, para ello se recomienda leer algun tutorial por la web ANTES de seguir leyendo esta wiki

== Bajando el Git ==
Para descargar el Git vamos a una terminal y ejecutamos:
git clone git://git.code.sf.net/p/butia/code

Luego de bajar el git, vamos a la carpeta "turtlebots"
cd turtlebots

== Estructura del Git ==

El GIT está compuesto de varias carpetas que mantienen distintas partes vitales del todo:

bobot
butiaXO
docs
firmware código de la actividad Firmware Update
lualibusb: binding para USB en Lua
pybot
serialcomm binding para serial en Lua
turtle_art_plugin todos los plugins
butialo código de la actividad Butialo
dibujos
examples
libs
newPatterns
pythonAPI
Seguidor
usb4all

== Versión estable ==
Es importante utilizar una versión ESTABLE!
Por ejemplo si queremos utilizar la "versión 18":
git checkout -b v18

== Compilando ==

Si estamos en una versión estable:
cd turtlebots # ir a la carpeta tortubots
make dev # genera en tmp el TurtleBots

Para ejecutarlo:
cd tmp
./turtleblocks.py

También, si tenemos un emulador de Sugar, como el "sugar-emulator" este comando genera
una instalación para poder usarlo desde allí.

Para generar un .XO, estando en la carpeta "turtlebots":
make xo

Eso nos crea en la carpeta el .XO

== Generando .deb ==

Para generar un .deb vamos a la carpeta:
cd turtle_art_plugin

y ejecutamos:
dpkg-buildpackage

Luego de finalizado, encontraremos el paquete una carpeta arriba de la acrual.

Git Butia

2014-03-26T16:42:02Z

AlanJAS: /* Bajando el Git */

Se explicara la estructura del Git Butia, como esta organizado, bajarse una version estable y compilarlo.

== Empezando con Git ==
Primero que nada es necesario saber como usar git, para ello se recomienda leer algun tutorial por la web ANTES de seguir leyendo esta wiki

== Bajando el Git ==
Para descargar el Git vamos a una terminal y ejecutamos:
git clone git://git.code.sf.net/p/butia/code

Luego de bajar el git, vamos a la carpeta "turtlebots"
cd turtlebots

== Estructura del Git ==

El GIT está compuesto de varias carpetas que mantienen distintas partes vitales del todo:

bobot
butiaXO
docs
firmware código de la actividad Firmware Update
lualibusb: binding para USB en Lua
pybot
serialcomm binding para serial en Lua
turtle_art_plugin todos los plugins
butialo código de la actividad Butialo
dibujos
examples
libs
newPatterns
pythonAPI
Seguidor
usb4all

== Versión estable ==
Es importante utilizar una versión ESTABLE!
Por ejemplo si queremos utilizar la "versión 18":
git checkout -b v18

== Compilando ==

Si estamos en una versión estable:
cd turtle_art_plugin # ir al plugin tortuga
make dev # genera en tmp el TurtleBots

Para ejecutarlo:
cd tmp
./turtleblocks.py

También, si tenemos un emulador de Sugar, como el "sugar-emulator" este comando genera
una instalación para poder usarlo desde allí.

Para generar un .XO, estando en la carpeta "turtle_art_plugin":
make xo

Eso nos crea en la carpeta el .XO

== Generando .deb ==

Para generar un .deb vamos a la carpeta:
cd turtle_art_plugin

y ejecutamos:
dpkg-buildpackage

Luego de finalizado, encontraremos el paquete una carpeta arriba de la acrual.

PyBot

2013-12-07T11:44:15Z

AlanJAS: /* Agrego HELP */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de pybot server o utilizando directamente la biblioteca usb4butia.

El código puede ser obtenido clonando el repositorio:

git clone git://git.code.sf.net/p/butia/code

''(Al día de hoy 10/11/13 la carpeta pesa 98MB es un poco pesada)'' 
El código se encuentra en "/lugar/de/clonado/turtlebots/pybot"

==Diseño==
Pybot consta de distintos módulos que se encargan de una parte específca:

baseboard.py funciones inerentes a la placa USB4Butia
com_chotox.py simula la conexión con una placa y todas las funciones
com_usb.py implementa la comunicación usb
device.py abstracción de un dispositivo (botón, motores) conectado a la placa
drivers/
hotplug/ drivers de módulos abiertos automáticamente por la placa
button.py driver del sensor botón
light.py driver del sensor de luz
-----
motores.py driver del módulo de motores
butia.py driver del módulo butiá
-----
functions.py funciones comunes entre el cliente y la usb4butia
pybot_client.py aplicación cliente
pybot_server.py aplicación servidor
server_functions.py lista de funciones del servidor
usb/ librería PyUsb
usb4butia.py módulo principal (core) que implementa las funciones

==Usando Pybot localmente==

Cuando se va a ejecutar Pybot y quién lo usa en la misma máquina, no es recomendable tener una arquitectura cliente-servidor. Para ese caso se dispone de una alternativa: usar directamente el módulo usb4butia dentro de Pybot.

Si no estamos en la carpeta donde está la librería PyBot podemos usar este truco para poder importar Pybot sin problemas desde cualquier lado:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

Esa es la ruta por defecto cuando el .XO se instala en Sugar, puede variar en otras computadoras. El paquete .deb instala TurtleBots en '/usr/share/sugar/activities' por lo que la ruta debe ser:

sys.path.insert(0, '/usr/share/sugar/activities/TurtleBots.activity/plugins/butia')

Importando el módulo:

from pybot import usb4butia

Instanciando la clase:

robot = usb4butia.USB4Butia()

A partir de este momento tenemos las mismas llamadas que en pybot_client.
Por ejemplo, para obtener la versión del Firmware:

version = robot.getFirmwareVersion()

El módulo USB4Butia nos provee algunas propiedades "privadas" que pueden resultar útiles:

robot._bb # Lista de placas detectadas
robot._drivers_loaded # Diccionario de drivers
robot._debug # Bandera de debug, por defecto es False
robot._get_all_drivers() # Función para cargar los drivers
robot._get_driver() # Función para obtener un driver específico
robot._hotplug # Lista de módulos hotplug
robot._modules # Lista de módulos
robot._openables # Lista de módoulos "openables"

==Usando Pybot server==

Levantamos el servidor desde una consola (debemos estar dentro de la carpeta pybot):

python pybot_server.py DEBUG

En este caso con la bandera de DEBUG para ver la salida del lado del servidor.

Luego nos encargamos del cliente:

from pybot impoty pybot_client

Instanciamos el cliente:

robot = pybot_client.robot()

A partir de ahora tenemos las mismas funciones que en la versión local, por ejemplo:

version = robot.getFirmwareVersion()

==Usando Pybot server via Telnet==

Cuando se levanta el servidor, se abre un socket en el puerto 2009.
Esto permite conectarnos via red local a un Butiá y poder controlarlo.
Para eso podemos levantar un Telnet así:

telnet localhost 2009

Ponemos "localhost" porque en nuestro caso estamos corriendo en la misma computadora,
de lo contrario, pondríamos la dirección IP.

===Comandos del Server===

Para poder acceder al robot contamos con algunos comandos.
La forma de saber los comandos presentes es mediante otro comando "HELP":

HELP
BUTIA_COUNT, CALL, CLIENTS, CLOSE, DESCRIBE, HELP, LIST, LISTI, OPEN, QUIT, REFRESH

Si queremos saber qué hace cada comando (solo en la versión 23 de PyBot) podemos hacer:

HELP clients
Get a list of current clients in PyBot server

Los comandos y su descripción:

BUTIA_COUNT: Get the number of boards connected
CALL: Call a function of certain module
CLIENTS: Get a list of current clients in PyBot server
CLOSE: Close an 'openable' module such as motors, butia..
DESCRIBE: Get the list of functions and parameters of a module
HELP: Return a list of commands or the use of specific one
LIST: Get a list of open modules in a board
LISTI: Get a list of instanciables modules of the board
OPEN: Open an 'openable' module such as motors, butia..
QUIT: Close PyBot server
REFRESH: Search for new devices

Otro comando útil es el "DESCRIBE": este comando permite describir un módulo (por ejemplo, un botón, un motor) y decirnos sus funciones y argumentos. Por ejemplo, en el caso de "grey" (sensor de grises):

DESCRIBE grey
{'getVersion': [], 'getValue': []}

Ésto nos dice que el sensor de grises (grey) cuenta con 2 funciones: "getVersion" y "getValue".
Para usar el comando, teniendo un sensor conectado en el puerto 2, por ejemplo, haríamos un "CALL":

CALL grey:2 getValue
25789

Eso nos devuelve el valor del sensor de grises conectado en el puerto 2 de la placa Butiá.

==Funciones USB4Butiá - Pybot Client==

Funciones útiles:
robot.close() # cierra todas las placas instanciadas
robot.find_butias() # busca placas conectadas y las instancia
robot.getBatteryCharge() # devuelve el nivel de carga de la batería (si no hay motores-> -1)
robot.getFirmwareVersion() # devuelve la versión del firmware dentro del PIC
robot.getVersion() # devuelve la versión del módulo butiá (arduino: 20, usb4butia:22)
robot.getButiaCount() # devuelve la cantidad de placas conectadas
robot.getModulesList() # devuelve la lista de dispositivos conectados (en todas las placas)
robot.isPresent(device) # chequea si un dispositivo en particular está conectado
robot.loopBack(data) # envía una string 'data' a la placa y devuelve lo mismo
robot.reconnect() # no hace nada en usb4butia / en el cliente hace un reconnect del socket
robot.refresh() # actualiza la lista de placas conectadas
robot.callModule(modulename, board_number, number, function, params) #llamada a un módulo

Sensores
robot.getButton(port) # obtiene el valor del sensor botón conectado en el puerto port
robot.getDistance(port) # obtiene el valor del sensor de distancia conectado en el puerto port
robot.getGray(port) # obtiene el valor del sensor de grises conectado en el puerto port
robot.getLight(port) # obtiene el valor del sensor de luz conectado en el puerto port
robot.getResistance(port) # obtiene el valor del sensor de resistencia conectado en el puerto port
robot.getTemperature(port) # obtiene el valor del sensor temperatura conectado en el puerto port
robot.getVoltage(port) # obtiene el valor del sensor volyaje conectado en el puerto port
robot.setLed(port, on) # si on es 1, prende el LED, si es 0, apaga el LED conectado en el puerto port

Hack pins
robot.modeHack(pin, mode) # establece el modo del pin: si mode es 0 es entrada y 1 salida
robot.setHack(pin, value) # establece el valor del pin: pin en GND si es 0 y en +5v si es 1
robot.getHack(pin) # lee el valor del pin: pin

Motores
robot.set2MotorSpeed(leftSense, leftSpeed, rightSense, rightSpeed) #sense is 0 or 1, speed is between 0 and 1023
robot.setMotorSpeed(idMotor, sense, speed) #idMotor 0 for left motor, 1 for right

== Drivers en PyBot ==

Los drivers de PyBot son escritos en python. Dentro de la carpeta /drivers se encuentran todos aquellos que no son PNP (plug and play). Los módulos que son abiertos automáticamente por la placa, por ejemplo cuando uno conecta un sensor de grises,
van dentro de /drivers/hotplug. 
Cada función en el driver se define como una función Python utilizando el "def" y recibe como primer parámetro el dispositivo ("dev") con el cual se va a comunicar. 
Este es el ejemplo del driver del sensor de grises, el cuál tiene dos funciones: getVersion y getValue 

[[Archivo:pybot_driver_grey.png|Captura del código del driver de grises]]

Esta es una captura parcial del código del driver de los hack points (hackp):

[[Archivo:pybot_driver_hackp_setmode.png|Captura parcial del código del driver de hackp]]

Como se puede observar, la función "setMode" recibe como primer argumento el "dev" y luego el resto de los parámetros: el número de "pin" y el "value" que es el modo.
Se guarda en "msg" la lista con el "código de operación" SET_MODE y se le agregan los otros parámetros.

msg = [SET_MODE, pin, value]

Esto se le envía al módulo con la función "send":

dev.send(msg)

Luego se leen 2 bytes: el primero, como en todas las funciones es el mismo "código de operación" que fue enviado y el segundo
es en este caso, el código de error (si es -1, hubo un error).

raw = dev.read(2)

Y solo se retorna el segundo byte que es el el importante:

return raw[1]

PyBot

2013-11-30T20:01:50Z

AlanJAS: /* Diseño */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de pybot server o utilizando directamente la biblioteca usb4butia.

El código puede ser obtenido clonando el repositorio:

git clone git://git.code.sf.net/p/butia/code

''(Al día de hoy 10/11/13 la carpeta pesa 98MB es un poco pesada)'' 
El código se encuentra en "/lugar/de/clonado/turtlebots/pybot"

==Diseño==
Pybot consta de distintos módulos que se encargan de una parte específca:

baseboard.py funciones inerentes a la placa USB4Butia
com_chotox.py simula la conexión con una placa y todas las funciones
com_usb.py implementa la comunicación usb
device.py abstracción de un dispositivo (botón, motores) conectado a la placa
drivers/
hotplug/ drivers de módulos abiertos automáticamente por la placa
button.py driver del sensor botón
light.py driver del sensor de luz
-----
motores.py driver del módulo de motores
butia.py driver del módulo butiá
-----
functions.py funciones comunes entre el cliente y la usb4butia
pybot_client.py aplicación cliente
pybot_server.py aplicación servidor
server_functions.py lista de funciones del servidor
usb/ librería PyUsb
usb4butia.py módulo principal (core) que implementa las funciones

==Usando Pybot localmente==

Cuando se va a ejecutar Pybot y quién lo usa en la misma máquina, no es recomendable tener una arquitectura cliente-servidor. Para ese caso se dispone de una alternativa: usar directamente el módulo usb4butia dentro de Pybot.

Si no estamos en la carpeta donde está la librería PyBot podemos usar este truco para poder importar Pybot sin problemas desde cualquier lado:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

Esa es la ruta por defecto cuando el .XO se instala en Sugar, puede variar en otras computadoras. El paquete .deb instala TurtleBots en '/usr/share/sugar/activities' por lo que la ruta debe ser:

sys.path.insert(0, '/usr/share/sugar/activities/TurtleBots.activity/plugins/butia')

Importando el módulo:

from pybot import usb4butia

Instanciando la clase:

robot = usb4butia.USB4Butia()

A partir de este momento tenemos las mismas llamadas que en pybot_client.
Por ejemplo, para obtener la versión del Firmware:

version = robot.getFirmwareVersion()

El módulo USB4Butia nos provee algunas propiedades "privadas" que pueden resultar útiles:

robot._bb # Lista de placas detectadas
robot._drivers_loaded # Diccionario de drivers
robot._debug # Bandera de debug, por defecto es False
robot._get_all_drivers() # Función para cargar los drivers
robot._get_driver() # Función para obtener un driver específico
robot._hotplug # Lista de módulos hotplug
robot._modules # Lista de módulos
robot._openables # Lista de módoulos "openables"

==Usando Pybot server==

Levantamos el servidor desde una consola (debemos estar dentro de la carpeta pybot):

python pybot_server.py DEBUG

En este caso con la bandera de DEBUG para ver la salida del lado del servidor.

Luego nos encargamos del cliente:

from pybot impoty pybot_client

Instanciamos el cliente:

robot = pybot_client.robot()

A partir de ahora tenemos las mismas funciones que en la versión local, por ejemplo:

version = robot.getFirmwareVersion()

==Funciones USB4Butiá - Pybot Client==

Funciones útiles:
robot.close() # cierra todas las placas instanciadas
robot.find_butias() # busca placas conectadas y las instancia
robot.getBatteryCharge() # devuelve el nivel de carga de la batería (si no hay motores-> -1)
robot.getFirmwareVersion() # devuelve la versión del firmware dentro del PIC
robot.getVersion() # devuelve la versión del módulo butiá (arduino: 20, usb4butia:22)
robot.getButiaCount() # devuelve la cantidad de placas conectadas
robot.getModulesList() # devuelve la lista de dispositivos conectados (en todas las placas)
robot.isPresent(device) # chequea si un dispositivo en particular está conectado
robot.loopBack(data) # envía una string 'data' a la placa y devuelve lo mismo
robot.reconnect() # no hace nada en usb4butia / en el cliente hace un reconnect del socket
robot.refresh() # actualiza la lista de placas conectadas
robot.callModule(modulename, board_number, number, function, params) #llamada a un módulo

Sensores
robot.getButton(port) # obtiene el valor del sensor botón conectado en el puerto port
robot.getDistance(port) # obtiene el valor del sensor de distancia conectado en el puerto port
robot.getGray(port) # obtiene el valor del sensor de grises conectado en el puerto port
robot.getLight(port) # obtiene el valor del sensor de luz conectado en el puerto port
robot.getResistance(port) # obtiene el valor del sensor de resistencia conectado en el puerto port
robot.getTemperature(port) # obtiene el valor del sensor temperatura conectado en el puerto port
robot.getVoltage(port) # obtiene el valor del sensor volyaje conectado en el puerto port
robot.setLed(port, on) # si on es 1, prende el LED, si es 0, apaga el LED conectado en el puerto port

Hack pins
robot.modeHack(pin, mode) # establece el modo del pin: si mode es 0 es entrada y 1 salida
robot.setHack(pin, value) # establece el valor del pin: pin en GND si es 0 y en +5v si es 1
robot.getHack(pin) # lee el valor del pin: pin

Motores
robot.set2MotorSpeed(leftSense, leftSpeed, rightSense, rightSpeed) #sense is 0 or 1, speed is between 0 and 1023
robot.setMotorSpeed(idMotor, sense, speed) #idMotor 0 for left motor, 1 for right

== Drivers en PyBot ==

Los drivers de PyBot son escritos en python. Dentro de la carpeta /drivers se encuentran todos aquellos que no son PNP (plug and play). Los módulos que son abiertos automáticamente por la placa, por ejemplo cuando uno conecta un sensor de grises,
van dentro de /drivers/hotplug. 
Cada función en el driver se define como una función Python utilizando el "def" y recibe como primer parámetro el dispositivo ("dev") con el cual se va a comunicar. 
Este es el ejemplo del driver del sensor de grises, el cuál tiene dos funciones: getVersion y getValue 

[[Archivo:pybot_driver_grey.png|Captura del código del driver de grises]]

Esta es una captura parcial del código del driver de los hack points (hackp):

[[Archivo:pybot_driver_hackp_setmode.png|Captura parcial del código del driver de hackp]]

Como se puede observar, la función "setMode" recibe como primer argumento el "dev" y luego el resto de los parámetros: el número de "pin" y el "value" que es el modo.
Se guarda en "msg" la lista con el "código de operación" SET_MODE y se le agregan los otros parámetros.

msg = [SET_MODE, pin, value]

Esto se le envía al módulo con la función "send":

dev.send(msg)

Luego se leen 2 bytes: el primero, como en todas las funciones es el mismo "código de operación" que fue enviado y el segundo
es en este caso, el código de error (si es -1, hubo un error).

raw = dev.read(2)

Y solo se retorna el segundo byte que es el el importante:

return raw[1]

Shield CC

2013-07-31T23:22:44Z

AlanJAS: /* Shield para Motores de Corriente Contínua */

Actas Reuniones Butia

2013-05-06T06:16:44Z

AlanJAS: /* Participantes */

== 03/04/13 ==

====Participantes====
Faivel, Lucio, Enrique, Jorge, John, Andrés, Juan Pablo Devone, Guille, Pablo, Alan

====Minuta====
*las reuniones se harán cada 15 días.

====Firmware y Hardware====

*usar 2 pines para detección.
*"desde arriba" es lo mismo: se llama a motors y y el módulo se encarga de resolver si tiene conectado motores de continua o AX-12.
*el shield se detectan al comienzo -> no es hotplug
*si hay ax-12 y el shield: se utilizan los motores del shield para el Butiá y los ax-12 para (en el futuro) usar un brazo u otra cosa.

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

Actas Reuniones Butia

2013-05-06T06:14:31Z

AlanJAS: /* 20/03/2013 */

== 03/04/13 ==

====Participantes====
Faivel, Lucio, Enrique, Jorge, John, Andrés, Juan Pablo Devone, Guille, Pablo, Alan

-las reuniones se harán cada 15 días.
-usar 2 pines para detección.
-"desde arriba" es lo mismo: se llama a motors y y el módulo se encarga de
resolver si tiene conectado motores de continua o AX-12.
-el shield se detectan al comienzo -> no es hotplug
-si hay ax-12 y el shield: se utilizan los motores del shield para el
Butiá y los ax-12 para (en el futuro) usar un brazo u otra cosa.

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

PyBot

2013-04-30T01:39:57Z

AlanJAS: /* Diseño */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de pybot server o utilizando directamente la biblioteca usb4butia.

==Diseño==
Pybot consta de distintos módulos que se encargan de una parte específca:

baseboard.py funciones inerentes a la placa USB4Butia
com_usb.py implementa la comunicación usb
device.py abstracción de un dispositivo (botón, motores) conectado a la placa
drivers/
hotplug/ drivers de módulos abiertos automáticamente por la placa
button.py driver del sensor botón
light.py driver del sensor de luz
-----
motores.py driver del módulo de motores
butia.py driver del módulo butiá
-----
functions.py funciones comunes entre el cliente y la usb4butia
pybot_client.py aplicación cliente
pybot_server.py aplicación servidor
usb/ librería PyUsb
usb4butia.py módulo principal (core) que implementa las funciones

==Usando Pybot localmente==

Cuando se va a ejecutar Pybot y quién lo usa en la misma máquina, no es recomendable tener una arquitectura cliente-servidor. Para ese caso se dispone de una alternativa: usar directamente el módulo usb4butia dentro de Pybot.

Si no estamos en la carpeta donde está la librería PyBot podemos usar este truco para poder importar Pybot sin problemas desde cualquier lado:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

Esa es la ruta por defecto cuando el .XO se instala en Sugar, puede variar en otras computadoras. El paquete .deb instala TurtleBots en '/usr/share/sugar/activities' por lo que la ruta debe ser:

sys.path.insert(0, '/usr/share/sugar/activities/TurtleBots.activity/plugins/butia')

Importando el módulo:

from pybot import usb4butia

Instanciando la clase:

robot = usb4butia.USB4Butia()

A partir de este momento tenemos las mismas llamadas que en pybot_client.
Por ejemplo, para obtener la versión del Firmware:

version = robot.getFirmwareVersion()

El módulo USB4Butia nos provee algunas propiedades "privadas" que pueden resultar útiles:

robot._bb # Lista de placas detectadas
robot._drivers_loaded # Diccionario de drivers
robot._debug # Bandera de debug, por defecto es False
robot._get_all_drivers() # Función para cargar los drivers
robot._get_driver() # Función para obtener un driver específico
robot._hotplug # Lista de módulos hotplug
robot._modules # Lista de módulos
robot._openables # Lista de módoulos "openables"

==Usando Pybot server==

Levantamos el servidor desde una consola (debemos estar dentro de la carpeta pybot):

python pybot_server.py DEBUG

En este caso con la bandera de DEBUG para ver la salida del lado del servidor.

Luego nos encargamos del cliente:

from pybot impoty pybot_client

Instanciamos el cliente:

robot = pybot_client.robot()

A partir de ahora tenemos las mismas funciones que en la versión local, por ejemplo:

version = robot.getFirmwareVersion()

==Funciones USB4Butiá - Pybot Client==

Funciones útiles:
robot.close() # cierra todas las placas instanciadas
robot.find_butias() # busca placas conectadas y las instancia
robot.getBatteryCharge() # devuelve el nivel de carga de la batería (si no hay motores-> -1)
robot.getFirmwareVersion() # devuelve la versión del firmware dentro del PIC
robot.getVersion() # devuelve la versión del módulo butiá (arduino: 20, usb4butia:22)
robot.getButiaCount() # devuelve la cantidad de placas conectadas
robot.getModulesList() # devuelve la lista de dispositivos conectados (en todas las placas)
robot.isPresent(device) # chequea si un dispositivo en particular está conectado
robot.loopBack(data) # envía una string 'data' a la placa y devuelve lo mismo
robot.reconnect() # no hace nada en usb4butia / en el cliente hace un reconnect del socket
robot.refresh() # actualiza la lista de placas conectadas
robot.callModule(modulename, board_number, number, function, params) #llamada a un módulo

Sensores
robot.getButton(port) # obtiene el valor del sensor botón conectado en el puerto port
robot.getDistance(port) # obtiene el valor del sensor de distancia conectado en el puerto port
robot.getGray(port) # obtiene el valor del sensor de grises conectado en el puerto port
robot.getLight(port) # obtiene el valor del sensor de luz conectado en el puerto port
robot.getResistance(port) # obtiene el valor del sensor de resistencia conectado en el puerto port
robot.getTemperature(port) # obtiene el valor del sensor temperatura conectado en el puerto port
robot.getVoltage(port) # obtiene el valor del sensor volyaje conectado en el puerto port
robot.setLed(port, on) # si on es 1, prende el LED, si es 0, apaga el LED conectado en el puerto port

Hack pins
robot.modeHack(pin, mode) # establece el modo del pin: si mode es 0 es entrada y 1 salida
robot.setHack(pin, value) # establece el valor del pin: pin en GND si es 0 y en +5v si es 1
robot.getHack(pin) # lee el valor del pin: pin

Motores
robot.set2MotorSpeed(leftSense, leftSpeed, rightSense, rightSpeed) #sense is 0 or 1, speed is between 0 and 1023
robot.setMotorSpeed(idMotor, sense, speed) #idMotor 0 for left motor, 1 for right

== Drivers en PyBot ==

Los drivers de PyBot son escritos en python. Dentro de la carpeta /drivers se encuentran todos aquellos que no son PNP (plug and play). Los módulos que son abiertos automáticamente por la placa, por ejemplo cuando uno conecta un sensor de grises,
van dentro de /drivers/hotplug. 
Cada función en el driver se define como una función Python utilizando el "def" y recibe como primer parámetro el dispositivo ("dev") con el cual se va a comunicar. 
Este es el ejemplo del driver del sensor de grises, el cuál tiene dos funciones: getVersion y getValue 

[[Archivo:pybot_driver_grey.png|Captura del código del driver de grises]]

Esta es una captura parcial del código del driver de los hack points (hackp):

[[Archivo:pybot_driver_hackp_setmode.png|Captura parcial del código del driver de hackp]]

Como se puede observar, la función "setMode" recibe como primer argumento el "dev" y luego el resto de los parámetros: el número de "pin" y el "value" que es el modo.
Se guarda en "msg" la lista con el "código de operación" SET_MODE y se le agregan los otros parámetros.

msg = [SET_MODE, pin, value]

Esto se le envía al módulo con la función "send":

dev.send(msg)

Luego se leen 2 bytes: el primero, como en todas las funciones es el mismo "código de operación" que fue enviado y el segundo
es en este caso, el código de error (si es -1, hubo un error).

raw = dev.read(2)

Y solo se retorna el segundo byte que es el el importante:

return raw[1]

PyBot

2013-04-30T01:37:56Z

AlanJAS:

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de pybot server o utilizando directamente la biblioteca usb4butia.

==Diseño==
Pybot consta de distintos módulos que se encargan de una parte específca:

baseboard.py funciones inerentes a la placa USB4Butia
com_usb.py implementa la comunicación usb
device.py abstracción de un dispositivo (botón, motores) conectado a la placa
drivers/
hotplug/ drivers de módulos abiertos automáticamente por la placa
button.py driver del sensor botón
light.py driver del sensor de luz
...
motores.py driver del módulo de motores
butia.py driver del módulo butiá
...
functions.py funciones comunes entre el cliente y la usb4butia
pybot_client.py aplicación cliente
pybot_server.py aplicación servidor
usb/ librería PyUsb
usb4butia.py módulo principal (core) que implementa las funciones

==Usando Pybot localmente==

Cuando se va a ejecutar Pybot y quién lo usa en la misma máquina, no es recomendable tener una arquitectura cliente-servidor. Para ese caso se dispone de una alternativa: usar directamente el módulo usb4butia dentro de Pybot.

Si no estamos en la carpeta donde está la librería PyBot podemos usar este truco para poder importar Pybot sin problemas desde cualquier lado:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

Esa es la ruta por defecto cuando el .XO se instala en Sugar, puede variar en otras computadoras. El paquete .deb instala TurtleBots en '/usr/share/sugar/activities' por lo que la ruta debe ser:

sys.path.insert(0, '/usr/share/sugar/activities/TurtleBots.activity/plugins/butia')

Importando el módulo:

from pybot import usb4butia

Instanciando la clase:

robot = usb4butia.USB4Butia()

A partir de este momento tenemos las mismas llamadas que en pybot_client.
Por ejemplo, para obtener la versión del Firmware:

version = robot.getFirmwareVersion()

El módulo USB4Butia nos provee algunas propiedades "privadas" que pueden resultar útiles:

robot._bb # Lista de placas detectadas
robot._drivers_loaded # Diccionario de drivers
robot._debug # Bandera de debug, por defecto es False
robot._get_all_drivers() # Función para cargar los drivers
robot._get_driver() # Función para obtener un driver específico
robot._hotplug # Lista de módulos hotplug
robot._modules # Lista de módulos
robot._openables # Lista de módoulos "openables"

==Usando Pybot server==

Levantamos el servidor desde una consola (debemos estar dentro de la carpeta pybot):

python pybot_server.py DEBUG

En este caso con la bandera de DEBUG para ver la salida del lado del servidor.

Luego nos encargamos del cliente:

from pybot impoty pybot_client

Instanciamos el cliente:

robot = pybot_client.robot()

A partir de ahora tenemos las mismas funciones que en la versión local, por ejemplo:

version = robot.getFirmwareVersion()

==Funciones USB4Butiá - Pybot Client==

Funciones útiles:
robot.close() # cierra todas las placas instanciadas
robot.find_butias() # busca placas conectadas y las instancia
robot.getBatteryCharge() # devuelve el nivel de carga de la batería (si no hay motores-> -1)
robot.getFirmwareVersion() # devuelve la versión del firmware dentro del PIC
robot.getVersion() # devuelve la versión del módulo butiá (arduino: 20, usb4butia:22)
robot.getButiaCount() # devuelve la cantidad de placas conectadas
robot.getModulesList() # devuelve la lista de dispositivos conectados (en todas las placas)
robot.isPresent(device) # chequea si un dispositivo en particular está conectado
robot.loopBack(data) # envía una string 'data' a la placa y devuelve lo mismo
robot.reconnect() # no hace nada en usb4butia / en el cliente hace un reconnect del socket
robot.refresh() # actualiza la lista de placas conectadas
robot.callModule(modulename, board_number, number, function, params) #llamada a un módulo

Sensores
robot.getButton(port) # obtiene el valor del sensor botón conectado en el puerto port
robot.getDistance(port) # obtiene el valor del sensor de distancia conectado en el puerto port
robot.getGray(port) # obtiene el valor del sensor de grises conectado en el puerto port
robot.getLight(port) # obtiene el valor del sensor de luz conectado en el puerto port
robot.getResistance(port) # obtiene el valor del sensor de resistencia conectado en el puerto port
robot.getTemperature(port) # obtiene el valor del sensor temperatura conectado en el puerto port
robot.getVoltage(port) # obtiene el valor del sensor volyaje conectado en el puerto port
robot.setLed(port, on) # si on es 1, prende el LED, si es 0, apaga el LED conectado en el puerto port

Hack pins
robot.modeHack(pin, mode) # establece el modo del pin: si mode es 0 es entrada y 1 salida
robot.setHack(pin, value) # establece el valor del pin: pin en GND si es 0 y en +5v si es 1
robot.getHack(pin) # lee el valor del pin: pin

Motores
robot.set2MotorSpeed(leftSense, leftSpeed, rightSense, rightSpeed) #sense is 0 or 1, speed is between 0 and 1023
robot.setMotorSpeed(idMotor, sense, speed) #idMotor 0 for left motor, 1 for right

== Drivers en PyBot ==

Los drivers de PyBot son escritos en python. Dentro de la carpeta /drivers se encuentran todos aquellos que no son PNP (plug and play). Los módulos que son abiertos automáticamente por la placa, por ejemplo cuando uno conecta un sensor de grises,
van dentro de /drivers/hotplug. 
Cada función en el driver se define como una función Python utilizando el "def" y recibe como primer parámetro el dispositivo ("dev") con el cual se va a comunicar. 
Este es el ejemplo del driver del sensor de grises, el cuál tiene dos funciones: getVersion y getValue 

[[Archivo:pybot_driver_grey.png|Captura del código del driver de grises]]

Esta es una captura parcial del código del driver de los hack points (hackp):

[[Archivo:pybot_driver_hackp_setmode.png|Captura parcial del código del driver de hackp]]

Como se puede observar, la función "setMode" recibe como primer argumento el "dev" y luego el resto de los parámetros: el número de "pin" y el "value" que es el modo.
Se guarda en "msg" la lista con el "código de operación" SET_MODE y se le agregan los otros parámetros.

msg = [SET_MODE, pin, value]

Esto se le envía al módulo con la función "send":

dev.send(msg)

Luego se leen 2 bytes: el primero, como en todas las funciones es el mismo "código de operación" que fue enviado y el segundo
es en este caso, el código de error (si es -1, hubo un error).

raw = dev.read(2)

Y solo se retorna el segundo byte que es el el importante:

return raw[1]

Software

2013-04-08T14:19:30Z

AlanJAS:

[[TortuBots]] 
[[Butialo]] (Lua) 
[[PyBot]] (Python) 
[[Python]]

Software

2013-04-08T14:10:41Z

AlanJAS: Página creada con 'TortuBots Butialo (Lua) PyBot (Python) Python '

[[TortuBots]] 
[[Butialo]] (Lua) 
[[PyBot]] (Python)
[[Python]]

Python

2013-04-08T13:47:44Z

AlanJAS:

Esta disponible para programar el comportamiento del robot butiá una API en el lenguaje de programación Python. 
También puede accederse en ésta sección a diferentes ejemplos de su uso.

* [[API|API Butiá en Python]]
* [[PyBot|Nueva API en Python]]
* [[ejemplos|Ejemplos en python usando la API Python]]

API

2013-04-08T03:27:07Z

AlanJAS:

API

2013-04-08T03:11:53Z

AlanJAS: /* Antes de empezar */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de [[bobot|bobot server]] utilizando directamente la biblioteca [[bobot]] o mediante diferentes APIs de programación como C, Java, Python.

==Antes de empezar==

Para utilizar la API es necesario tener corriendo un servidor. 
En el caso de [[bobot]] se debe ejecutar:

./lua bobot-server.lua

Si se desea ver que dispositivos está detectando y mas, se debe habilitar el DEBUG:

./lua bobot-server.lua DEBUG

En el caso de usar [[pybot]] se debe ejecutar:

python pybot_server.py

Para habilitar el DEBUG:

python pybot_server.py DEBUG

Luego de iniciado el servidor, podemos conectarnos desde el cliente pybot_client.py.

==Uso de la API en Pippy y Python==

Para poder utilizar la librería butiaAPI es necesario que especifiquemos la ruta donde se encuentra.
Para ello, en Pippy agregamos:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

La ruta /home/olpc.. es la ruta donde por defecto se encuentra TurtleBots cuando se instala en una XO.
En otras computadoras puede variar.
Asimismo, este truco permite utilizar la butiaAPI desde cualquier otro lugar en el sistema, directamente desde python.

Luego de tener eso, procedemos a usar la API.

==Importando la API==

Para importar el cliente:

from pybot import pybot_client

No es necesario importar "pybot" ya que solo vamos a utilizar el cliente.

==Pybot Client==

Descripción de las funciones y algunos ejemplos.

'''Instanciar la clase:'''

<syntaxhighlight lang="python">
robot = pybot_client.robot()
</syntaxhighlight>

'''Versión del Firmware:'''
Devuelve la versión del firmware de la placa con el que estamos trabajando

<syntaxhighlight lang="python">
ver = robot.getFirmwareVersion()
print ver
</syntaxhighlight>

'''Cerrar:'''
Cierra la comunicación con el servidor

<syntaxhighlight lang="python">
robot.close()
</syntaxhighlight>

'''Conexión/Desconexión con el servidor:'''
Conecta o Reconecta con el servidor

<syntaxhighlight lang="python">
robot.reconnect()
</syntaxhighlight>

'''Cerrar cliente y servidor:'''
Cierra el servidor y el cliente

<syntaxhighlight lang="python">
robot.closeService()
</syntaxhighlight>

== Módulos ==

'''listarModulos:'''

devuelve la lista de los modulos disponibles en el firmware de la placa

<syntaxhighlight lang="python">
modulos = robot.listarModulos()
print modulos
</syntaxhighlight>

'''llamarModulo:'''

Operacion de llamada de una funcion de un modulo (CALL)

<syntaxhighlight lang="python">
robot.llamarModulo(modulename, function , params = "")
</syntaxhighlight>

Para conocer la lista de funciones de un módulo y sus parametros puede ejecutarse en un terminal: 
 
<syntaxhighlight lang="text">
telnet localhost 2009
DESCRIBE nombre_de_modulo
</syntaxhighlight>
A futuro hay que exportar este servicio en la API 

== Funciones Varias ==

'''isPresent'''

Retorna si esta presente el modulo 

<syntaxhighlight lang="python">
robot.isPresent (moduloname)
</syntaxhighlight>

'''loopBack'''

Módulo loopBack: modulo de ayuda presente en el butiá que
envía un mensaje a la placa y espera recibir exactamente lo que fue enviado

<syntaxhighlight lang="python">
datoRet = butiabot.loopBack("hola")
print datoRet
> hola
</syntaxhighlight>

== Motores ==

Operaciones solicidatas al driver motores.lua

'''setVelocidadMotores'''

robot.set2MotorSpeed(self, sentidoIzq = "0", velIzq = "0", sentidoDer = "0", velDer = "0")

sentido: 0: adelante, 1: atras
velocidad: 0..1023

Detiene los 2 motores:

<syntaxhighlight lang="python">
robot.set2MotorSpeed("0", "0", "0", "0")
</syntaxhighlight>

robot.set2MotorSpeed("0", "500", "1", "500") - gira a la izquierda

robot.set2MotorSpeed("1", "500", "1", "500") - va hacia atrás

robot.set2MotorSpeed("0", "500", "0", "500") - va hacia adelante

robot.set2MotorSpeed("1", "500", "0", "500") - gira a la derecha

'''setVelMotor'''

robot.setMotorSpeed(self, idMotor = "0", sentido = "0", vel = "0")

idMotor: 0: motor derecho, 1: motor izquierdo

Va hacia adelante:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","1","500")
robot.setMotorSpeed("0","1","500")
</syntaxhighlight>

Va hacia atrás:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","0","500")
robot.setMotorSpeed("0","0","500")
</syntaxhighlight>

== Sensores ==

port es el número de puerto donde se encuentra conectado el sensor

getButton(port)

getLight(port)

getDistance(port)

getGray(port)

getTemperature(port)

getResistance(port)

getVoltage(port)

setLed(level)
level is 0: off or 1: on

== Carga de batería ==

Esta operacion nos devuelve la carga aproximada de las pilas del robot con un error de 0.1 volt.
La medición de la carga la realizan los motores, por lo cual, si no se tienen los motores, el
valor devuelto es -1.

'''Carga de la Batería'''

<syntaxhighlight lang="python">
carga = robot.getBatteryCharge()
print carga
</syntaxhighlight>

PyBot

2013-04-08T03:09:39Z

AlanJAS: /* Usando Pybot localmente */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de pybot server o utilizando directamente la biblioteca usb4butia.

==Usando Pybot localmente==

Cuando se va a ejecutar Pybot y quién lo usa en la misma máquina, no es recomendable tener una arquitectura cliente-servidor. Para ese caso se dispone de una alternativa: usar directamente el módulo usb4butia dentro de Pybot.

Si no estamos en la carpeta donde está la librería PyBot podemos usar este truco para poder importar Pybot sin problemas desde cualquier lado:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

Esa es la ruta por defecto cuando el .XO se instala en Sugar, puede variar en otras computadoras. El paquete .deb instala TurtleBots en '/usr/share/sugar/activities' por lo que la ruta debe ser:

sys.path.insert(0, '/usr/share/sugar/activities/TurtleBots.activity/plugins/butia')

Importando el módulo:

from pybot import usb4butia

Instanciando la clase:

robot = usb4butia.USB4Butia()

A partir de este momento tenemos las mismas llamadas que en pybot_client.
Por ejemplo, para obtener la versión del Firmware:

version = robot.getFirmwareVersion()

El módulo USB4Butia nos provee algunas propiedades "privadas" que pueden resultar útiles:

robot._bb # Lista de placas detectadas
robot._drivers_loaded # Diccionario de drivers
robot._debug # Bandera de debug, por defecto es False
robot._get_all_drivers() # Función para cargar los drivers
robot._get_driver() # Función para obtener un driver específico
robot._hotplug # Lista de módulos hotplug
robot._modules # Lista de módulos
robot._openables # Lista de módoulos "openables"

==Usando Pybot server==

Levantamos el servidor desde una consola (debemos estar dentro de la carpeta pybot):

python pybot_server.py DEBUG

En este caso con la bandera de DEBUG para ver la salida del lado del servidor.

Luego nos encargamos del cliente:

from pybot impoty pybot_client

Instanciamos el cliente:

robot = pybot_client.robot()

A partir de ahora tenemos las mismas funciones que en la versión local, por ejemplo:

version = robot.getFirmwareVersion()

==Funciones USB4Butiá - Pybot Client==

Funciones útiles:
robot.close() # cierra todas las placas instanciadas
robot.find_butias() # busca placas conectadas y las instancia
robot.getBatteryCharge() # devuelve el nivel de carga de la batería (si no hay motores-> -1)
robot.getFirmwareVersion() # devuelve la versión del firmware dentro del PIC
robot.getVersion() # devuelve la versión del módulo butiá (arduino: 20, usb4butia:22)
robot.getButiaCount() # devuelve la cantidad de placas conectadas
robot.getModulesList() # devuelve la lista de dispositivos conectados (en todas las placas)
robot.isPresent(device) # chequea si un dispositivo en particular está conectado
robot.loopBack(data) # envía una string 'data' a la placa y devuelve lo mismo
robot.reconnect() # no hace nada en usb4butia / en el cliente hace un reconnect del socket
robot.refresh() # actualiza la lista de placas conectadas
robot.callModule(modulename, board_number, number, function, params) #llamada a un módulo

Sensores
robot.getButton(port) # obtiene el valor del sensor botón conectado en el puerto port
robot.getDistance(port) # obtiene el valor del sensor de distancia conectado en el puerto port
robot.getGray(port) # obtiene el valor del sensor de grises conectado en el puerto port
robot.getLight(port) # obtiene el valor del sensor de luz conectado en el puerto port
robot.getResistance(port) # obtiene el valor del sensor de resistencia conectado en el puerto port
robot.getTemperature(port) # obtiene el valor del sensor temperatura conectado en el puerto port
robot.getVoltage(port) # obtiene el valor del sensor volyaje conectado en el puerto port
robot.setLed(port, on) # si on es 1, prende el LED, si es 0, apaga el LED conectado en el puerto port

Hack pins
robot.modeHack(pin, mode) # establece el modo del pin: si mode es 0 es entrada y 1 salida
robot.setHack(pin, value) # establece el valor del pin: pin en GND si es 0 y en +5v si es 1
robot.getHack(pin) # lee el valor del pin: pin

Motores
robot.set2MotorSpeed(leftSense, leftSpeed, rightSense, rightSpeed) #sense is 0 or 1, speed is between 0 and 1023
robot.setMotorSpeed(idMotor, sense, speed) #idMotor 0 for left motor, 1 for right

== Drivers en PyBot ==

Los drivers de PyBot son escritos en python. Dentro de la carpeta /drivers se encuentran todos aquellos que no son PNP (plug and play). Los módulos que son abiertos automáticamente por la placa, por ejemplo cuando uno conecta un sensor de grises,
van dentro de /drivers/hotplug. 
Cada función en el driver se define como una función Python utilizando el "def" y recibe como primer parámetro el dispositivo ("dev") con el cual se va a comunicar. 
Este es el ejemplo del driver del sensor de grises, el cuál tiene dos funciones: getVersion y getValue 

[[Archivo:pybot_driver_grey.png|Captura del código del driver de grises]]

Esta es una captura parcial del código del driver de los hack points (hackp):

[[Archivo:pybot_driver_hackp_setmode.png|Captura parcial del código del driver de hackp]]

Como se puede observar, la función "setMode" recibe como primer argumento el "dev" y luego el resto de los parámetros: el número de "pin" y el "value" que es el modo.
Se guarda en "msg" la lista con el "código de operación" SET_MODE y se le agregan los otros parámetros.

msg = [SET_MODE, pin, value]

Esto se le envía al módulo con la función "send":

dev.send(msg)

Luego se leen 2 bytes: el primero, como en todas las funciones es el mismo "código de operación" que fue enviado y el segundo
es en este caso, el código de error (si es -1, hubo un error).

raw = dev.read(2)

Y solo se retorna el segundo byte que es el el importante:

return raw[1]

Pybot

2013-04-08T03:03:58Z

AlanJAS: /* Drivers en PyBot */

PyBot

2013-04-08T02:51:51Z

AlanJAS: /* Funciones USB4Butiá - Pybot Client */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de pybot server o utilizando directamente la biblioteca usb4butia.

==Usando Pybot localmente==

Cuando se va a ejecutar Pybot y quién lo usa en la misma máquina, no es recomendable tener una arquitectura cliente-servidor. Para ese caso se dispone de una alternativa: usar directamente el módulo usb4butia dentro de Pybot.

Si no estamos en la carpeta donde está la librería PyBot podemos usar este truco para poder importar Pybot sin problemas desde cualquier lado:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

Esa es la ruta por defecto cuando el .XO se instala en Sugar, puede variar en otras computadoras. El paquete .deb instala TurtleBots en '/usr/share/sugar/activities' por lo que la ruta debe ser:

sys.path.insert(0, '/usr/share/sugar/activities/TurtleBots.activity/plugins/butia')

Importando el módulo:

from pybot import usb4butia

Instanciando la clase:

robot = usb4butia.USB4Butia()

A partir de este momento tenemos las mismas llamadas que en [[Pybot_client | Pybot client]].
Por ejemplo, para obtener la versión del Firmware:

version = robot.getFirmwareVersion()

El módulo USB4Butia nos provee algunas propiedades "privadas" que pueden resultar útiles:

robot._bb # Lista de placas detectadas
robot._drivers_loaded # Diccionario de drivers
robot._debug # Bandera de debug, por defecto es False
robot._get_all_drivers() # Función para cargar los drivers
robot._get_driver() # Función para obtener un driver específico
robot._hotplug # Lista de módulos hotplug
robot._modules # Lista de módulos
robot._openables # Lista de módoulos "openables"

==Usando Pybot server==

Levantamos el servidor desde una consola (debemos estar dentro de la carpeta pybot):

python pybot_server.py DEBUG

En este caso con la bandera de DEBUG para ver la salida del lado del servidor.

Luego nos encargamos del cliente:

from pybot impoty pybot_client

Instanciamos el cliente:

robot = pybot_client.robot()

A partir de ahora tenemos las mismas funciones que en la versión local, por ejemplo:

version = robot.getFirmwareVersion()

==Funciones USB4Butiá - Pybot Client==

Funciones útiles:
robot.close() # cierra todas las placas instanciadas
robot.find_butias() # busca placas conectadas y las instancia
robot.getBatteryCharge() # devuelve el nivel de carga de la batería (si no hay motores-> -1)
robot.getFirmwareVersion() # devuelve la versión del firmware dentro del PIC
robot.getVersion() # devuelve la versión del módulo butiá (arduino: 20, usb4butia:22)
robot.getButiaCount() # devuelve la cantidad de placas conectadas
robot.getModulesList() # devuelve la lista de dispositivos conectados (en todas las placas)
robot.isPresent(device) # chequea si un dispositivo en particular está conectado
robot.loopBack(data) # envía una string 'data' a la placa y devuelve lo mismo
robot.reconnect() # no hace nada en usb4butia / en el cliente hace un reconnect del socket
robot.refresh() # actualiza la lista de placas conectadas
robot.callModule(modulename, board_number, number, function, params) #llamada a un módulo

Sensores
robot.getButton(port) # obtiene el valor del sensor botón conectado en el puerto port
robot.getDistance(port) # obtiene el valor del sensor de distancia conectado en el puerto port
robot.getGray(port) # obtiene el valor del sensor de grises conectado en el puerto port
robot.getLight(port) # obtiene el valor del sensor de luz conectado en el puerto port
robot.getResistance(port) # obtiene el valor del sensor de resistencia conectado en el puerto port
robot.getTemperature(port) # obtiene el valor del sensor temperatura conectado en el puerto port
robot.getVoltage(port) # obtiene el valor del sensor volyaje conectado en el puerto port
robot.setLed(port, on) # si on es 1, prende el LED, si es 0, apaga el LED conectado en el puerto port

Hack pins
robot.modeHack(pin, mode) # establece el modo del pin: si mode es 0 es entrada y 1 salida
robot.setHack(pin, value) # establece el valor del pin: pin en GND si es 0 y en +5v si es 1
robot.getHack(pin) # lee el valor del pin: pin

Motores
robot.set2MotorSpeed(leftSense, leftSpeed, rightSense, rightSpeed) #sense is 0 or 1, speed is between 0 and 1023
robot.setMotorSpeed(idMotor, sense, speed) #idMotor 0 for left motor, 1 for right

== Drivers en PyBot ==

Los drivers de PyBot son escritos en python. Dentro de la carpeta /drivers se encuentran todos aquellos que no son PNP (plug and play). Los módulos que son abiertos automáticamente por la placa, por ejemplo cuando uno conecta un sensor de grises,
van dentro de /drivers/hotplug. 
Cada función en el driver se define como una función Python utilizando el "def" y recibe como primer parámetro el dispositivo ("dev") con el cual se va a comunicar. 
Este es el ejemplo del driver del sensor de grises, el cuál tiene dos funciones: getVersion y getValue 

[[Archivo:pybot_driver_grey.png|Captura del código del driver de grises]]

Esta es una captura parcial del código del driver de los hack points (hackp):

[[Archivo:pybot_driver_hackp_setmode.png|Captura parcial del código del driver de hackp]]

Como se puede observar, la función "setMode" recibe como primer argumento el "dev" y luego el resto de los parámetros: el número de "pin" y el "value" que es el modo.
Se guarda en "msg" la lista con el "código de operación" SET_MODE y se le agregan los otros parámetros.

msg = [SET_MODE, pin, value]

Esto se le envía al módulo con la función "send":

dev.send(msg)

Luego se leen 2 bytes: el primero, como en todas las funciones es el mismo "código de operación" que fue enviado y el segundo
es en este caso, el código de error (si es -1, hubo un error).

raw = dev.read(2)

Y solo se retorna el segundo byte que es el el importante:

return raw[1]

PyBot

2013-04-08T02:37:23Z

AlanJAS: /* Usando Pybot localmente */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de pybot server o utilizando directamente la biblioteca usb4butia.

==Usando Pybot localmente==

Cuando se va a ejecutar Pybot y quién lo usa en la misma máquina, no es recomendable tener una arquitectura cliente-servidor. Para ese caso se dispone de una alternativa: usar directamente el módulo usb4butia dentro de Pybot.

Si no estamos en la carpeta donde está la librería PyBot podemos usar este truco para poder importar Pybot sin problemas desde cualquier lado:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

Esa es la ruta por defecto cuando el .XO se instala en Sugar, puede variar en otras computadoras. El paquete .deb instala TurtleBots en '/usr/share/sugar/activities' por lo que la ruta debe ser:

sys.path.insert(0, '/usr/share/sugar/activities/TurtleBots.activity/plugins/butia')

Importando el módulo:

from pybot import usb4butia

Instanciando la clase:

robot = usb4butia.USB4Butia()

A partir de este momento tenemos las mismas llamadas que en [[Pybot_client | Pybot client]].
Por ejemplo, para obtener la versión del Firmware:

version = robot.getFirmwareVersion()

El módulo USB4Butia nos provee algunas propiedades "privadas" que pueden resultar útiles:

robot._bb # Lista de placas detectadas
robot._drivers_loaded # Diccionario de drivers
robot._debug # Bandera de debug, por defecto es False
robot._get_all_drivers() # Función para cargar los drivers
robot._get_driver() # Función para obtener un driver específico
robot._hotplug # Lista de módulos hotplug
robot._modules # Lista de módulos
robot._openables # Lista de módoulos "openables"

==Usando Pybot server==

Levantamos el servidor desde una consola (debemos estar dentro de la carpeta pybot):

python pybot_server.py DEBUG

En este caso con la bandera de DEBUG para ver la salida del lado del servidor.

Luego nos encargamos del cliente:

from pybot impoty pybot_client

Instanciamos el cliente:

robot = pybot_client.robot()

A partir de ahora tenemos las mismas funciones que en la versión local, por ejemplo:

version = robot.getFirmwareVersion()

==Funciones USB4Butiá - Pybot Client==

Funciones útiles:
robot.close() # cierra todas las placas instanciadas
robot.find_butias() # busca placas conectadas y las instancia
robot.getBatteryCharge() # devuelve el nivel de carga de la batería (si no hay motores-> -1)
robot.getFirmwareVersion() # devuelve la versión del firmware dentro del PIC
robot.getVersion() # devuelve la versión del módulo butiá (arduino: 20, usb4butia:22)
robot.getButiaCount() # devuelve la cantidad de placas conectadas
robot.getModulesList() # devuelve la lista de dispositivos conectados (en todas las placas)
robot.isPresent(device) # chequea si un dispositivo en particular está conectado
robot.loopBack(data) # envía una string 'data' a la placa y devuelve lo mismo
robot.reconnect() # no hace nada en usb4butia / en el cliente hace un reconnect del socket
robot.refresh() # actualiza la lista de placas conectadas
robot.callModule(modulename, board_number, number, function, params) #llamada a un módulo

Sensores
robot.getButton(port) # obtiene el valor del sensor botón conectado en el puerto port
robot.getDistance(port) # obtiene el valor del sensor de distancia conectado en el puerto port
robot.getGray(port) # obtiene el valor del sensor de grises conectado en el puerto port
robot.getLight(port) # obtiene el valor del sensor de luz conectado en el puerto port
robot.getResistance(port) # obtiene el valor del sensor de resistencia conectado en el puerto port
robot.getTemperature(port) # obtiene el valor del sensor temperatura conectado en el puerto port
robot.getVoltage(port) # obtiene el valor del sensor volyaje conectado en el puerto port
robot.setLed(port, on) # si on es 1, prende el LED, si es 0, apaga el LED conectado en el puerto port

Hack pins
robot.modeHack(pin, mode) # establece el modo del pin: si mode es 0 es entrada y 1 salida
robot.setHack(pin, value) # establece el valor del pin: pin en GND si es 0 y en +5v si es 1
robot.getHack(pin) # lee el valor del pin: pin

Motores
robot.set2MotorSpeed(leftSense, leftSpeed, rightSense, rightSpeed) #sense is 0 or 1, speed is between 0 and 1023
robot.setMotorSpeed(idMotor, sense, speed) #idMotor 0 for left motor, 1 for right

API

2013-04-08T02:33:14Z

AlanJAS: /* butiaAPI */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de [[bobot|bobot server]] utilizando directamente la biblioteca [[bobot]] o mediante diferentes APIs de programación como C, Java, Python.

==Antes de empezar==

Para utilizar la API es necesario tener corriendo un servidor. 
En el caso de [[bobot]] se debe ejecutar:

./lua bobot-server.lua

Si se desea ver que dispositivos está detectando y mas, se debe habilitar el DEBUG:

./lua bobot-server.lua DEBUG

En el caso de usar [[pybot]] se debe ejecutar:

python pybot_server.py

Para habilitar el DEBUG:

python pybot_server.py DEBUG

Luego de iniciado el servidor, podemos conectarnos desde el cliente [[PyBot_client]].

==Uso de la API en Pippy y Python==

Para poder utilizar la librería butiaAPI es necesario que especifiquemos la ruta donde se encuentra.
Para ello, en Pippy agregamos:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

La ruta /home/olpc.. es la ruta donde por defecto se encuentra TurtleBots cuando se instala en una XO.
En otras computadoras puede variar.
Asimismo, este truco permite utilizar la butiaAPI desde cualquier otro lugar en el sistema, directamente desde python.

Luego de tener eso, procedemos a usar la API.

==Importando la API==

Para importar el cliente:

from pybot import pybot_client

No es necesario importar "pybot" ya que solo vamos a utilizar el cliente.

==Pybot Client==

Descripción de las funciones y algunos ejemplos.

'''Instanciar la clase:'''

<syntaxhighlight lang="python">
robot = pybot_client.robot()
</syntaxhighlight>

'''Versión del Firmware:'''
Devuelve la versión del firmware de la placa con el que estamos trabajando

<syntaxhighlight lang="python">
ver = robot.getFirmwareVersion()
print ver
</syntaxhighlight>

'''Cerrar:'''
Cierra la comunicación con el servidor

<syntaxhighlight lang="python">
robot.close()
</syntaxhighlight>

'''Conexión/Desconexión con el servidor:'''
Conecta o Reconecta con el servidor

<syntaxhighlight lang="python">
robot.reconnect()
</syntaxhighlight>

'''Cerrar cliente y servidor:'''
Cierra el servidor y el cliente

<syntaxhighlight lang="python">
robot.closeService()
</syntaxhighlight>

== Módulos ==

'''listarModulos:'''

devuelve la lista de los modulos disponibles en el firmware de la placa

<syntaxhighlight lang="python">
modulos = robot.listarModulos()
print modulos
</syntaxhighlight>

'''llamarModulo:'''

Operacion de llamada de una funcion de un modulo (CALL)

<syntaxhighlight lang="python">
robot.llamarModulo(modulename, function , params = "")
</syntaxhighlight>

Para conocer la lista de funciones de un módulo y sus parametros puede ejecutarse en un terminal: 
 
<syntaxhighlight lang="text">
telnet localhost 2009
DESCRIBE nombre_de_modulo
</syntaxhighlight>
A futuro hay que exportar este servicio en la API 

== Funciones Varias ==

'''isPresent'''

Retorna si esta presente el modulo 

<syntaxhighlight lang="python">
robot.isPresent (moduloname)
</syntaxhighlight>

'''loopBack'''

Módulo loopBack: modulo de ayuda presente en el butiá que
envía un mensaje a la placa y espera recibir exactamente lo que fue enviado

<syntaxhighlight lang="python">
datoRet = butiabot.loopBack("hola")
print datoRet
> hola
</syntaxhighlight>

== Motores ==

Operaciones solicidatas al driver motores.lua

'''setVelocidadMotores'''

robot.set2MotorSpeed(self, sentidoIzq = "0", velIzq = "0", sentidoDer = "0", velDer = "0")

sentido: 0: adelante, 1: atras
velocidad: 0..1023

Detiene los 2 motores:

<syntaxhighlight lang="python">
robot.set2MotorSpeed("0", "0", "0", "0")
</syntaxhighlight>

robot.set2MotorSpeed("0", "500", "1", "500") - gira a la izquierda

robot.set2MotorSpeed("1", "500", "1", "500") - va hacia atrás

robot.set2MotorSpeed("0", "500", "0", "500") - va hacia adelante

robot.set2MotorSpeed("1", "500", "0", "500") - gira a la derecha

'''setVelMotor'''

robot.setMotorSpeed(self, idMotor = "0", sentido = "0", vel = "0")

idMotor: 0: motor derecho, 1: motor izquierdo

Va hacia adelante:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","1","500")
robot.setMotorSpeed("0","1","500")
</syntaxhighlight>

Va hacia atrás:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","0","500")
robot.setMotorSpeed("0","0","500")
</syntaxhighlight>

== Sensores ==

port es el número de puerto donde se encuentra conectado el sensor

getButton(port)

getLight(port)

getDistance(port)

getGray(port)

getTemperature(port)

getResistance(port)

getVoltage(port)

setLed(level)
level is 0: off or 1: on

== Carga de batería ==

Esta operacion nos devuelve la carga aproximada de las pilas del robot con un error de 0.1 volt.
La medición de la carga la realizan los motores, por lo cual, si no se tienen los motores, el
valor devuelto es -1.

'''Carga de la Batería'''

<syntaxhighlight lang="python">
carga = robot.getBatteryCharge()
print carga
</syntaxhighlight>

PyBot client

2013-04-08T02:27:21Z

AlanJAS: Página blanqueada

PyBot

2013-04-08T02:26:34Z

AlanJAS: Página creada con 'Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de pybot server o utilizando directamente la biblioteca usb4butia. ==Usand...'

API

2013-04-08T00:14:24Z

AlanJAS: /* Uso de la butiaAPI en Pippy y Python */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de [[bobot|bobot server]] utilizando directamente la biblioteca [[bobot]] o mediante diferentes APIs de programación como C, Java, Python.

==Antes de empezar==

Para utilizar la API es necesario tener corriendo un servidor. 
En el caso de [[bobot]] se debe ejecutar:

./lua bobot-server.lua

Si se desea ver que dispositivos está detectando y mas, se debe habilitar el DEBUG:

./lua bobot-server.lua DEBUG

En el caso de usar [[pybot]] se debe ejecutar:

python pybot_server.py

Para habilitar el DEBUG:

python pybot_server.py DEBUG

Luego de iniciado el servidor, podemos conectarnos desde el cliente [[PyBot_client]].

==Uso de la API en Pippy y Python==

Para poder utilizar la librería butiaAPI es necesario que especifiquemos la ruta donde se encuentra.
Para ello, en Pippy agregamos:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

La ruta /home/olpc.. es la ruta donde por defecto se encuentra TurtleBots cuando se instala en una XO.
En otras computadoras puede variar.
Asimismo, este truco permite utilizar la butiaAPI desde cualquier otro lugar en el sistema, directamente desde python.

Luego de tener eso, procedemos a usar la API.

==butiaAPI==

Descripción de las funciones y algunos ejemplos.

'''Instanciar la clase:'''

<syntaxhighlight lang="python">
robot = butiaAPI.robot()
</syntaxhighlight>

'''Versión del Firmware:'''
Devuelve la versión del firmware de la placa con el que estamos trabajando

<syntaxhighlight lang="python">
ver = robot.getFirmwareVersion()
print ver
</syntaxhighlight>

'''Cerrar:'''
Cierra la comunicación con el servidor

<syntaxhighlight lang="python">
robot.close()
</syntaxhighlight>

'''Conexión/Desconexión con el servidor:'''
Conecta o Reconecta con el servidor

<syntaxhighlight lang="python">
robot.reconnect()
</syntaxhighlight>

'''Cerrar cliente y servidor:'''
Cierra el servidor y el cliente

<syntaxhighlight lang="python">
robot.closeService()
</syntaxhighlight>

== Módulos ==

'''listarModulos:'''

devuelve la lista de los modulos disponibles en el firmware de la placa

<syntaxhighlight lang="python">
modulos = robot.listarModulos()
print modulos
</syntaxhighlight>

'''llamarModulo:'''

Operacion de llamada de una funcion de un modulo (CALL)

<syntaxhighlight lang="python">
robot.llamarModulo(modulename, function , params = "")
</syntaxhighlight>

Para conocer la lista de funciones de un módulo y sus parametros puede ejecutarse en un terminal: 
 
<syntaxhighlight lang="text">
telnet localhost 2009
DESCRIBE nombre_de_modulo
</syntaxhighlight>
A futuro hay que exportar este servicio en la API 

== Funciones Varias ==

'''isPresent'''

Retorna si esta presente el modulo 

<syntaxhighlight lang="python">
robot.isPresent (moduloname)
</syntaxhighlight>

'''loopBack'''

Módulo loopBack: modulo de ayuda presente en el butiá que
envía un mensaje a la placa y espera recibir exactamente lo que fue enviado

<syntaxhighlight lang="python">
datoRet = butiabot.loopBack("hola")
print datoRet
> hola
</syntaxhighlight>

== Motores ==

Operaciones solicidatas al driver motores.lua

'''setVelocidadMotores'''

robot.set2MotorSpeed(self, sentidoIzq = "0", velIzq = "0", sentidoDer = "0", velDer = "0")

sentido: 0: adelante, 1: atras
velocidad: 0..1023

Detiene los 2 motores:

<syntaxhighlight lang="python">
robot.set2MotorSpeed("0", "0", "0", "0")
</syntaxhighlight>

robot.set2MotorSpeed("0", "500", "1", "500") - gira a la izquierda

robot.set2MotorSpeed("1", "500", "1", "500") - va hacia atrás

robot.set2MotorSpeed("0", "500", "0", "500") - va hacia adelante

robot.set2MotorSpeed("1", "500", "0", "500") - gira a la derecha

'''setVelMotor'''

robot.setMotorSpeed(self, idMotor = "0", sentido = "0", vel = "0")

idMotor: 0: motor derecho, 1: motor izquierdo

Va hacia adelante:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","1","500")
robot.setMotorSpeed("0","1","500")
</syntaxhighlight>

Va hacia atrás:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","0","500")
robot.setMotorSpeed("0","0","500")
</syntaxhighlight>

== Sensores ==

port es el número de puerto donde se encuentra conectado el sensor

getButton(port)

getLight(port)

getDistance(port)

getGray(port)

getTemperature(port)

getResistance(port)

getVoltage(port)

setLed(level)
level is 0: off or 1: on

== Carga de batería ==

Esta operacion nos devuelve la carga aproximada de las pilas del robot con un error de 0.1 volt.
La medición de la carga la realizan los motores, por lo cual, si no se tienen los motores, el
valor devuelto es -1.

'''Carga de la Batería'''

<syntaxhighlight lang="python">
carga = robot.getBatteryCharge()
print carga
</syntaxhighlight>

Pybot

2013-04-08T00:08:06Z

AlanJAS: /* Drivers en PyBot */

== Drivers en PyBot ==

Los drivers de PyBot son escritos en python. Dentro de la carpeta /drivers se encuentran todos aquellos que no son PNP (plug and play). Los módulos que son abiertos automáticamente por la placa, por ejemplo cuando uno conecta un sensor de grises,
van dentro de /drivers/hotplug. 
Cada función en el driver se define como una función Python utilizando el "def" y recibe como primer parámetro el dispositivo ("dev") con el cual se va a comunicar. 
Este es el ejemplo del driver del sensor de grises, el cuál tiene dos funciones: getVersion y getValue 

[[Archivo:pybot_driver_grey.png|Captura del código del driver de grises]]

Esta es una captura parcial del código del driver de los hack points (hackp):

[[Archivo:pybot_driver_hackp_setmode.png|Captura parcial del código del driver de hackp]]

Como se puede observar, la función "setMode" recibe como primer argumento el "dev" y luego el resto de los parámetros: el número de "pin" y el "value" que es el modo.
Se guarda en "msg" la lista con el "código de operación" SET_MODE y se le agregan los otros parámetros.

msg = [SET_MODE, pin, value]

Esto se le envía al módulo con la función "send":

dev.send(msg)

Luego se leen 2 bytes: el primero, como en todas las funciones es el mismo "código de operación" que fue enviado y el segundo
es en este caso, el código de error (si es -1, hubo un error).

raw = dev.read(2)

Y solo se retorna el segundo byte que es el el importante:

return raw[1]

Pybot

2013-04-08T00:05:53Z

AlanJAS: /* Drivers en PyBot */

== Drivers en PyBot ==

Los drivers de PyBot son escritos en python. Dentro de la carpeta /drivers se encuentran todos aquellos que no son PNP (plug and play). Los módulos que son abiertos automáticamente por la placa, por ejemplo cuando uno conecta un sensor de grises,
van dentro de /drivers/hotplug. 
Cada función en el driver se define como una función Python utilizando el "def" y recibe como primer parámetro el dispositivo ("dev") con el cual se va a comunicar. 
Este es el ejemplo del driver del sensor de grises, el cuál tiene dos funciones: getVersion y getValue 

[[Archivo:pybot_driver_grey.png|Captura del código del driver de grises]]

Esta es una captura del código del driver de los hack points (hackp):

[[Archivo:pybot_driver_hackp_setmode.png|Captura parcial del código del driver de hackp]]

Como se puede observar, la función "setMode" recibe como primer argumento el "dev" y luego el resto de los parámetros: el número de "pin" y el "value" que es el modo.
Se guarda en "msg" la lista con el "código de operación" SET_MODE y se le agregan los otros parámetros.

msg = [SET_MODE, pin, value]

Esto se le envía al módulo con la función "send":

dev.send(msg)

Luego se leen 2 bytes: el primero, como en todas las funciones es el mismo "código de operación" que fue enviado y el segundo
es en este caso, el código de error (si es -1, hubo un error).

raw = dev.read(2)

Y solo se retorna el segundo byte que es el el importante:

return raw[1]

Pybot

2013-04-08T00:02:44Z

AlanJAS: /* Drivers en PyBot */

== Drivers en PyBot ==

Los drivers de PyBot son escritos en python. Dentro de la carpeta /drivers se encuentran todos aquellos que no son PNP (plug and play). Los módulos que son abiertos automáticamente por la placa, por ejemplo cuando uno conecta un sensor de grises,
van dentro de /drivers/hotplug. 
Cada función en el driver se define como una función Python utilizando el "def" y recibe como primer parámetro el dispositivo ("dev") con el cual se va a comunicar. 
Este es el ejemplo del driver del sensor de grises: 

[[Archivo:pybot_driver_grey.png|Captura del código del driver de grises]]

Esta es una captura del código del driver de los hack points (hackp):

[[Archivo:pybot_driver_hackp_setmode.png|Captura parcial del código del driver de hackp]]

Como se puede observar, la función setMode recibe como primer argumento el "dev" y luego el resto de los parámetros: el número de "pin" y el "value" que es el modo.
Se guarda en "msg" la lista con el "código de operación" SET_MODE y se le agregan los otros parámetros.

msg = [SET_MODE, pin, value]

Esto se le envía al módulo con la función "send":

dev.send(msg)

Luego se leen 2 bytes: el primero, como en todas las funciones es el mismo "código de operación" que fue enviado y el segundo
es en este caso, el código de error (si es -1, hubo un error).

raw = dev.read(2)

Y solo se retorna el segundo byte que es el el importante:

return raw[1]

Archivo:Pybot driver hackp setmode.png

2013-04-07T23:54:27Z

AlanJAS:

Pybot

2013-04-07T23:53:43Z

AlanJAS: /* Drivers en PyBot */

Archivo:Pybot driver grey.png

2013-04-07T23:39:02Z

AlanJAS: Captura del código del driver de grises

Captura del código del driver de grises

Pybot

2013-04-07T23:35:03Z

AlanJAS: /* Drivers en PyBot */

PyBot client

2013-04-07T23:14:44Z

AlanJAS: Página creada con ' Esta es la nueva versión de la ButiaAPI. Ya que todo el código de PyBot es python, se incluyó el cliente dentro de la librería sin prejuicio de que se use por separado.'

Esta es la nueva versión de la ButiaAPI. Ya que todo el código de PyBot es python, se incluyó el cliente dentro de la librería sin prejuicio de que se use por separado.

API

2013-04-07T23:13:04Z

AlanJAS: /* Antes de empezar */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de [[bobot|bobot server]] utilizando directamente la biblioteca [[bobot]] o mediante diferentes APIs de programación como C, Java, Python.

==Antes de empezar==

Para utilizar la API es necesario tener corriendo un servidor. 
En el caso de [[bobot]] se debe ejecutar:

./lua bobot-server.lua

Si se desea ver que dispositivos está detectando y mas, se debe habilitar el DEBUG:

./lua bobot-server.lua DEBUG

En el caso de usar [[pybot]] se debe ejecutar:

python pybot_server.py

Para habilitar el DEBUG:

python pybot_server.py DEBUG

Luego de iniciado el servidor, podemos conectarnos desde el cliente [[PyBot_client]].

==Uso de la butiaAPI en Pippy y Python==

Para poder utilizar la librería butiaAPI es necesario que especifiquemos la ruta donde se encuentra.
Para ello, en Pippy agregamos:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

La ruta /home/olpc.. es la ruta donde por defecto se encuentra TurtleBots cuando se instala en una XO.
En otras computadoras puede variar.
Asimismo, este truco permite utilizar la butiaAPI desde cualquier otro lugar en el sistema, directamente desde python.

Luego de tener eso, procedemos a usar la API.

==butiaAPI==

Descripción de las funciones y algunos ejemplos.

'''Instanciar la clase:'''

<syntaxhighlight lang="python">
robot = butiaAPI.robot()
</syntaxhighlight>

'''Versión del Firmware:'''
Devuelve la versión del firmware de la placa con el que estamos trabajando

<syntaxhighlight lang="python">
ver = robot.getFirmwareVersion()
print ver
</syntaxhighlight>

'''Cerrar:'''
Cierra la comunicación con el servidor

<syntaxhighlight lang="python">
robot.close()
</syntaxhighlight>

'''Conexión/Desconexión con el servidor:'''
Conecta o Reconecta con el servidor

<syntaxhighlight lang="python">
robot.reconnect()
</syntaxhighlight>

'''Cerrar cliente y servidor:'''
Cierra el servidor y el cliente

<syntaxhighlight lang="python">
robot.closeService()
</syntaxhighlight>

== Módulos ==

'''listarModulos:'''

devuelve la lista de los modulos disponibles en el firmware de la placa

<syntaxhighlight lang="python">
modulos = robot.listarModulos()
print modulos
</syntaxhighlight>

'''llamarModulo:'''

Operacion de llamada de una funcion de un modulo (CALL)

<syntaxhighlight lang="python">
robot.llamarModulo(modulename, function , params = "")
</syntaxhighlight>

Para conocer la lista de funciones de un módulo y sus parametros puede ejecutarse en un terminal: 
 
<syntaxhighlight lang="text">
telnet localhost 2009
DESCRIBE nombre_de_modulo
</syntaxhighlight>
A futuro hay que exportar este servicio en la API 

== Funciones Varias ==

'''isPresent'''

Retorna si esta presente el modulo 

<syntaxhighlight lang="python">
robot.isPresent (moduloname)
</syntaxhighlight>

'''loopBack'''

Módulo loopBack: modulo de ayuda presente en el butiá que
envía un mensaje a la placa y espera recibir exactamente lo que fue enviado

<syntaxhighlight lang="python">
datoRet = butiabot.loopBack("hola")
print datoRet
> hola
</syntaxhighlight>

== Motores ==

Operaciones solicidatas al driver motores.lua

'''setVelocidadMotores'''

robot.set2MotorSpeed(self, sentidoIzq = "0", velIzq = "0", sentidoDer = "0", velDer = "0")

sentido: 0: adelante, 1: atras
velocidad: 0..1023

Detiene los 2 motores:

<syntaxhighlight lang="python">
robot.set2MotorSpeed("0", "0", "0", "0")
</syntaxhighlight>

robot.set2MotorSpeed("0", "500", "1", "500") - gira a la izquierda

robot.set2MotorSpeed("1", "500", "1", "500") - va hacia atrás

robot.set2MotorSpeed("0", "500", "0", "500") - va hacia adelante

robot.set2MotorSpeed("1", "500", "0", "500") - gira a la derecha

'''setVelMotor'''

robot.setMotorSpeed(self, idMotor = "0", sentido = "0", vel = "0")

idMotor: 0: motor derecho, 1: motor izquierdo

Va hacia adelante:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","1","500")
robot.setMotorSpeed("0","1","500")
</syntaxhighlight>

Va hacia atrás:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","0","500")
robot.setMotorSpeed("0","0","500")
</syntaxhighlight>

== Sensores ==

port es el número de puerto donde se encuentra conectado el sensor

getButton(port)

getLight(port)

getDistance(port)

getGray(port)

getTemperature(port)

getResistance(port)

getVoltage(port)

setLed(level)
level is 0: off or 1: on

== Carga de batería ==

Esta operacion nos devuelve la carga aproximada de las pilas del robot con un error de 0.1 volt.
La medición de la carga la realizan los motores, por lo cual, si no se tienen los motores, el
valor devuelto es -1.

'''Carga de la Batería'''

<syntaxhighlight lang="python">
carga = robot.getBatteryCharge()
print carga
</syntaxhighlight>

Pybot

2013-04-07T23:06:16Z

AlanJAS: /* Drivers en PyBot */

Pybot

2013-04-07T23:03:46Z

AlanJAS: Página creada con ' == Drivers en PyBot == Los drivers de PyBot son escritos en python. Dentro de la carpeta /drivers se encuentran todos aquellos que no son PNP (plug and play). Los módulos qu...'

API

2013-04-07T22:59:45Z

AlanJAS: /* Antes de empezar */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de [[bobot|bobot server]] utilizando directamente la biblioteca [[bobot]] o mediante diferentes APIs de programación como C, Java, Python.

==Antes de empezar==

Para utilizar la API es necesario tener corriendo un servidor.
En el caso de [[bobot]] se debe ejecutar:

./lua bobot-server.lua

Si se desea ver que dispositivos está detectando y mas, se debe habilitar el DEBUG:

./lua bobot-server.lua DEBUG

En el caso de usar [[pybot]] se debe ejecutar:

python pybot_server.py

Para habilitar el DEBUG:

python pybot_server.py DEBUG

Luego de iniciado el servidor, podemos conectarnos desde el cliente [[PyBot_client]].

==Uso de la butiaAPI en Pippy y Python==

Para poder utilizar la librería butiaAPI es necesario que especifiquemos la ruta donde se encuentra.
Para ello, en Pippy agregamos:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

La ruta /home/olpc.. es la ruta donde por defecto se encuentra TurtleBots cuando se instala en una XO.
En otras computadoras puede variar.
Asimismo, este truco permite utilizar la butiaAPI desde cualquier otro lugar en el sistema, directamente desde python.

Luego de tener eso, procedemos a usar la API.

==butiaAPI==

Descripción de las funciones y algunos ejemplos.

'''Instanciar la clase:'''

<syntaxhighlight lang="python">
robot = butiaAPI.robot()
</syntaxhighlight>

'''Versión del Firmware:'''
Devuelve la versión del firmware de la placa con el que estamos trabajando

<syntaxhighlight lang="python">
ver = robot.getFirmwareVersion()
print ver
</syntaxhighlight>

'''Cerrar:'''
Cierra la comunicación con el servidor

<syntaxhighlight lang="python">
robot.close()
</syntaxhighlight>

'''Conexión/Desconexión con el servidor:'''
Conecta o Reconecta con el servidor

<syntaxhighlight lang="python">
robot.reconnect()
</syntaxhighlight>

'''Cerrar cliente y servidor:'''
Cierra el servidor y el cliente

<syntaxhighlight lang="python">
robot.closeService()
</syntaxhighlight>

== Módulos ==

'''listarModulos:'''

devuelve la lista de los modulos disponibles en el firmware de la placa

<syntaxhighlight lang="python">
modulos = robot.listarModulos()
print modulos
</syntaxhighlight>

'''llamarModulo:'''

Operacion de llamada de una funcion de un modulo (CALL)

<syntaxhighlight lang="python">
robot.llamarModulo(modulename, function , params = "")
</syntaxhighlight>

Para conocer la lista de funciones de un módulo y sus parametros puede ejecutarse en un terminal: 
 
<syntaxhighlight lang="text">
telnet localhost 2009
DESCRIBE nombre_de_modulo
</syntaxhighlight>
A futuro hay que exportar este servicio en la API 

== Funciones Varias ==

'''isPresent'''

Retorna si esta presente el modulo 

<syntaxhighlight lang="python">
robot.isPresent (moduloname)
</syntaxhighlight>

'''loopBack'''

Módulo loopBack: modulo de ayuda presente en el butiá que
envía un mensaje a la placa y espera recibir exactamente lo que fue enviado

<syntaxhighlight lang="python">
datoRet = butiabot.loopBack("hola")
print datoRet
> hola
</syntaxhighlight>

== Motores ==

Operaciones solicidatas al driver motores.lua

'''setVelocidadMotores'''

robot.set2MotorSpeed(self, sentidoIzq = "0", velIzq = "0", sentidoDer = "0", velDer = "0")

sentido: 0: adelante, 1: atras
velocidad: 0..1023

Detiene los 2 motores:

<syntaxhighlight lang="python">
robot.set2MotorSpeed("0", "0", "0", "0")
</syntaxhighlight>

robot.set2MotorSpeed("0", "500", "1", "500") - gira a la izquierda

robot.set2MotorSpeed("1", "500", "1", "500") - va hacia atrás

robot.set2MotorSpeed("0", "500", "0", "500") - va hacia adelante

robot.set2MotorSpeed("1", "500", "0", "500") - gira a la derecha

'''setVelMotor'''

robot.setMotorSpeed(self, idMotor = "0", sentido = "0", vel = "0")

idMotor: 0: motor derecho, 1: motor izquierdo

Va hacia adelante:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","1","500")
robot.setMotorSpeed("0","1","500")
</syntaxhighlight>

Va hacia atrás:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","0","500")
robot.setMotorSpeed("0","0","500")
</syntaxhighlight>

== Sensores ==

port es el número de puerto donde se encuentra conectado el sensor

getButton(port)

getLight(port)

getDistance(port)

getGray(port)

getTemperature(port)

getResistance(port)

getVoltage(port)

setLed(level)
level is 0: off or 1: on

== Carga de batería ==

Esta operacion nos devuelve la carga aproximada de las pilas del robot con un error de 0.1 volt.
La medición de la carga la realizan los motores, por lo cual, si no se tienen los motores, el
valor devuelto es -1.

'''Carga de la Batería'''

<syntaxhighlight lang="python">
carga = robot.getBatteryCharge()
print carga
</syntaxhighlight>

API

2013-04-07T22:58:46Z

AlanJAS: /* Antes de empezar */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de [[bobot|bobot server]] utilizando directamente la biblioteca [[bobot]] o mediante diferentes APIs de programación como C, Java, Python.

==Antes de empezar==

Para utilizar la API es necesario tener corriendo un servidor.
En el caso de [[bobot]] se debe ejecutar:

./lua bobot-server.lua

Si se desea ver que dispositivos está detectando y mas, se debe habilitar el DEBUG:

./lua bobot-server.lua DEBUG

En el caso de usar [[pybot]] se debe ejecutar:

python pybot_server.py

Para habilitar el DEBUG:

python pybot_server.py DEBUG

Luego de iniciado el servidor, podemos conectarnos desde el cliente [PyBot_client].

==Uso de la butiaAPI en Pippy y Python==

Para poder utilizar la librería butiaAPI es necesario que especifiquemos la ruta donde se encuentra.
Para ello, en Pippy agregamos:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

La ruta /home/olpc.. es la ruta donde por defecto se encuentra TurtleBots cuando se instala en una XO.
En otras computadoras puede variar.
Asimismo, este truco permite utilizar la butiaAPI desde cualquier otro lugar en el sistema, directamente desde python.

Luego de tener eso, procedemos a usar la API.

==butiaAPI==

Descripción de las funciones y algunos ejemplos.

'''Instanciar la clase:'''

<syntaxhighlight lang="python">
robot = butiaAPI.robot()
</syntaxhighlight>

'''Versión del Firmware:'''
Devuelve la versión del firmware de la placa con el que estamos trabajando

<syntaxhighlight lang="python">
ver = robot.getFirmwareVersion()
print ver
</syntaxhighlight>

'''Cerrar:'''
Cierra la comunicación con el servidor

<syntaxhighlight lang="python">
robot.close()
</syntaxhighlight>

'''Conexión/Desconexión con el servidor:'''
Conecta o Reconecta con el servidor

<syntaxhighlight lang="python">
robot.reconnect()
</syntaxhighlight>

'''Cerrar cliente y servidor:'''
Cierra el servidor y el cliente

<syntaxhighlight lang="python">
robot.closeService()
</syntaxhighlight>

== Módulos ==

'''listarModulos:'''

devuelve la lista de los modulos disponibles en el firmware de la placa

<syntaxhighlight lang="python">
modulos = robot.listarModulos()
print modulos
</syntaxhighlight>

'''llamarModulo:'''

Operacion de llamada de una funcion de un modulo (CALL)

<syntaxhighlight lang="python">
robot.llamarModulo(modulename, function , params = "")
</syntaxhighlight>

Para conocer la lista de funciones de un módulo y sus parametros puede ejecutarse en un terminal: 
 
<syntaxhighlight lang="text">
telnet localhost 2009
DESCRIBE nombre_de_modulo
</syntaxhighlight>
A futuro hay que exportar este servicio en la API 

== Funciones Varias ==

'''isPresent'''

Retorna si esta presente el modulo 

<syntaxhighlight lang="python">
robot.isPresent (moduloname)
</syntaxhighlight>

'''loopBack'''

Módulo loopBack: modulo de ayuda presente en el butiá que
envía un mensaje a la placa y espera recibir exactamente lo que fue enviado

<syntaxhighlight lang="python">
datoRet = butiabot.loopBack("hola")
print datoRet
> hola
</syntaxhighlight>

== Motores ==

Operaciones solicidatas al driver motores.lua

'''setVelocidadMotores'''

robot.set2MotorSpeed(self, sentidoIzq = "0", velIzq = "0", sentidoDer = "0", velDer = "0")

sentido: 0: adelante, 1: atras
velocidad: 0..1023

Detiene los 2 motores:

<syntaxhighlight lang="python">
robot.set2MotorSpeed("0", "0", "0", "0")
</syntaxhighlight>

robot.set2MotorSpeed("0", "500", "1", "500") - gira a la izquierda

robot.set2MotorSpeed("1", "500", "1", "500") - va hacia atrás

robot.set2MotorSpeed("0", "500", "0", "500") - va hacia adelante

robot.set2MotorSpeed("1", "500", "0", "500") - gira a la derecha

'''setVelMotor'''

robot.setMotorSpeed(self, idMotor = "0", sentido = "0", vel = "0")

idMotor: 0: motor derecho, 1: motor izquierdo

Va hacia adelante:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","1","500")
robot.setMotorSpeed("0","1","500")
</syntaxhighlight>

Va hacia atrás:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","0","500")
robot.setMotorSpeed("0","0","500")
</syntaxhighlight>

== Sensores ==

port es el número de puerto donde se encuentra conectado el sensor

getButton(port)

getLight(port)

getDistance(port)

getGray(port)

getTemperature(port)

getResistance(port)

getVoltage(port)

setLed(level)
level is 0: off or 1: on

== Carga de batería ==

Esta operacion nos devuelve la carga aproximada de las pilas del robot con un error de 0.1 volt.
La medición de la carga la realizan los motores, por lo cual, si no se tienen los motores, el
valor devuelto es -1.

'''Carga de la Batería'''

<syntaxhighlight lang="python">
carga = robot.getBatteryCharge()
print carga
</syntaxhighlight>

API

2013-04-07T22:52:03Z

AlanJAS: /* Motores */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de [[bobot|bobot server]] utilizando directamente la biblioteca [[bobot]] o mediante diferentes APIs de programación como C, Java, Python.

==Antes de empezar==

Para utilizar la API es necesario tener corriendo el servidor.
En el caso de [bobot] se debe ejecutar:

./lua bobot-server.lua

Si se desea ver que dispositivos está detectando y mas, se debe habilitar el DEBUG:

./lua bobot-server.lua DEBUG

En el caso de usar [pybot| pybot server] se debe ejecutar:

python pybot_server.py

Para habilitar el DEBUG:

python pybot_server.py DEBUG

Luego de iniciado el servidor, podemos conectarnos desde la butiaAPI.

==Uso de la butiaAPI en Pippy y Python==

Para poder utilizar la librería butiaAPI es necesario que especifiquemos la ruta donde se encuentra.
Para ello, en Pippy agregamos:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

La ruta /home/olpc.. es la ruta donde por defecto se encuentra TurtleBots cuando se instala en una XO.
En otras computadoras puede variar.
Asimismo, este truco permite utilizar la butiaAPI desde cualquier otro lugar en el sistema, directamente desde python.

Luego de tener eso, procedemos a usar la API.

==butiaAPI==

Descripción de las funciones y algunos ejemplos.

'''Instanciar la clase:'''

<syntaxhighlight lang="python">
robot = butiaAPI.robot()
</syntaxhighlight>

'''Versión del Firmware:'''
Devuelve la versión del firmware de la placa con el que estamos trabajando

<syntaxhighlight lang="python">
ver = robot.getFirmwareVersion()
print ver
</syntaxhighlight>

'''Cerrar:'''
Cierra la comunicación con el servidor

<syntaxhighlight lang="python">
robot.close()
</syntaxhighlight>

'''Conexión/Desconexión con el servidor:'''
Conecta o Reconecta con el servidor

<syntaxhighlight lang="python">
robot.reconnect()
</syntaxhighlight>

'''Cerrar cliente y servidor:'''
Cierra el servidor y el cliente

<syntaxhighlight lang="python">
robot.closeService()
</syntaxhighlight>

== Módulos ==

'''listarModulos:'''

devuelve la lista de los modulos disponibles en el firmware de la placa

<syntaxhighlight lang="python">
modulos = robot.listarModulos()
print modulos
</syntaxhighlight>

'''llamarModulo:'''

Operacion de llamada de una funcion de un modulo (CALL)

<syntaxhighlight lang="python">
robot.llamarModulo(modulename, function , params = "")
</syntaxhighlight>

Para conocer la lista de funciones de un módulo y sus parametros puede ejecutarse en un terminal: 
 
<syntaxhighlight lang="text">
telnet localhost 2009
DESCRIBE nombre_de_modulo
</syntaxhighlight>
A futuro hay que exportar este servicio en la API 

== Funciones Varias ==

'''isPresent'''

Retorna si esta presente el modulo 

<syntaxhighlight lang="python">
robot.isPresent (moduloname)
</syntaxhighlight>

'''loopBack'''

Módulo loopBack: modulo de ayuda presente en el butiá que
envía un mensaje a la placa y espera recibir exactamente lo que fue enviado

<syntaxhighlight lang="python">
datoRet = butiabot.loopBack("hola")
print datoRet
> hola
</syntaxhighlight>

== Motores ==

Operaciones solicidatas al driver motores.lua

'''setVelocidadMotores'''

robot.set2MotorSpeed(self, sentidoIzq = "0", velIzq = "0", sentidoDer = "0", velDer = "0")

sentido: 0: adelante, 1: atras
velocidad: 0..1023

Detiene los 2 motores:

<syntaxhighlight lang="python">
robot.set2MotorSpeed("0", "0", "0", "0")
</syntaxhighlight>

robot.set2MotorSpeed("0", "500", "1", "500") - gira a la izquierda

robot.set2MotorSpeed("1", "500", "1", "500") - va hacia atrás

robot.set2MotorSpeed("0", "500", "0", "500") - va hacia adelante

robot.set2MotorSpeed("1", "500", "0", "500") - gira a la derecha

'''setVelMotor'''

robot.setMotorSpeed(self, idMotor = "0", sentido = "0", vel = "0")

idMotor: 0: motor derecho, 1: motor izquierdo

Va hacia adelante:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","1","500")
robot.setMotorSpeed("0","1","500")
</syntaxhighlight>

Va hacia atrás:
<syntaxhighlight lang="python">
robot.setMotorSpeed("1","0","500")
robot.setMotorSpeed("0","0","500")
</syntaxhighlight>

== Sensores ==

port es el número de puerto donde se encuentra conectado el sensor

getButton(port)

getLight(port)

getDistance(port)

getGray(port)

getTemperature(port)

getResistance(port)

getVoltage(port)

setLed(level)
level is 0: off or 1: on

== Carga de batería ==

Esta operacion nos devuelve la carga aproximada de las pilas del robot con un error de 0.1 volt.
La medición de la carga la realizan los motores, por lo cual, si no se tienen los motores, el
valor devuelto es -1.

'''Carga de la Batería'''

<syntaxhighlight lang="python">
carga = robot.getBatteryCharge()
print carga
</syntaxhighlight>

API

2013-04-07T22:50:25Z

AlanJAS: /* Funciones Varias */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de [[bobot|bobot server]] utilizando directamente la biblioteca [[bobot]] o mediante diferentes APIs de programación como C, Java, Python.

==Antes de empezar==

Para utilizar la API es necesario tener corriendo el servidor.
En el caso de [bobot] se debe ejecutar:

./lua bobot-server.lua

Si se desea ver que dispositivos está detectando y mas, se debe habilitar el DEBUG:

./lua bobot-server.lua DEBUG

En el caso de usar [pybot| pybot server] se debe ejecutar:

python pybot_server.py

Para habilitar el DEBUG:

python pybot_server.py DEBUG

Luego de iniciado el servidor, podemos conectarnos desde la butiaAPI.

==Uso de la butiaAPI en Pippy y Python==

Para poder utilizar la librería butiaAPI es necesario que especifiquemos la ruta donde se encuentra.
Para ello, en Pippy agregamos:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

La ruta /home/olpc.. es la ruta donde por defecto se encuentra TurtleBots cuando se instala en una XO.
En otras computadoras puede variar.
Asimismo, este truco permite utilizar la butiaAPI desde cualquier otro lugar en el sistema, directamente desde python.

Luego de tener eso, procedemos a usar la API.

==butiaAPI==

Descripción de las funciones y algunos ejemplos.

'''Instanciar la clase:'''

<syntaxhighlight lang="python">
robot = butiaAPI.robot()
</syntaxhighlight>

'''Versión del Firmware:'''
Devuelve la versión del firmware de la placa con el que estamos trabajando

<syntaxhighlight lang="python">
ver = robot.getFirmwareVersion()
print ver
</syntaxhighlight>

'''Cerrar:'''
Cierra la comunicación con el servidor

<syntaxhighlight lang="python">
robot.close()
</syntaxhighlight>

'''Conexión/Desconexión con el servidor:'''
Conecta o Reconecta con el servidor

<syntaxhighlight lang="python">
robot.reconnect()
</syntaxhighlight>

'''Cerrar cliente y servidor:'''
Cierra el servidor y el cliente

<syntaxhighlight lang="python">
robot.closeService()
</syntaxhighlight>

== Módulos ==

'''listarModulos:'''

devuelve la lista de los modulos disponibles en el firmware de la placa

<syntaxhighlight lang="python">
modulos = robot.listarModulos()
print modulos
</syntaxhighlight>

'''llamarModulo:'''

Operacion de llamada de una funcion de un modulo (CALL)

<syntaxhighlight lang="python">
robot.llamarModulo(modulename, function , params = "")
</syntaxhighlight>

Para conocer la lista de funciones de un módulo y sus parametros puede ejecutarse en un terminal: 
 
<syntaxhighlight lang="text">
telnet localhost 2009
DESCRIBE nombre_de_modulo
</syntaxhighlight>
A futuro hay que exportar este servicio en la API 

== Funciones Varias ==

'''isPresent'''

Retorna si esta presente el modulo 

<syntaxhighlight lang="python">
robot.isPresent (moduloname)
</syntaxhighlight>

'''loopBack'''

Módulo loopBack: modulo de ayuda presente en el butiá que
envía un mensaje a la placa y espera recibir exactamente lo que fue enviado

<syntaxhighlight lang="python">
datoRet = butiabot.loopBack("hola")
print datoRet
> hola
</syntaxhighlight>

== Motores ==

Operaciones solicidatas al driver motores.lua

'''abrirMotores:'''

<syntaxhighlight lang="python">
robot.abrirMotores()
</syntaxhighlight>

'''setVelocidadMotores'''

robot.setVelocidadMotores(self, sentidoIzq = "0", velIzq = "0", sentidoDer = "0", velDer = "0")

sentido: 0: adelante, 1: atras
velocidad: 0..1023

Detiene los 2 motores:

<syntaxhighlight lang="python">
robot.setVelocidadMotores("0", "0", "0", "0")
</syntaxhighlight>

robot.setVelocidadMotores("0", "500", "1", "500") - gira a la izquierda

robot.setVelocidadMotores("1", "500", "1", "500") - va hacia atrás

robot.setVelocidadMotores("0", "500", "0", "500") - va hacia adelante

robot.setVelocidadMotores("1", "500", "0", "500") - gira a la derecha

'''setVelMotor'''

robot.setVelMotor(self, idMotor = "0", sentido = "0", vel = "0")

idMotor: 0: motor derecho, 1: motor izquierdo

Va hacia adelante:
<syntaxhighlight lang="python">
robot.setVelMotor("1","1","500")
robot.setVelMotor("0","1","500")
</syntaxhighlight>

Va hacia atrás:
<syntaxhighlight lang="python">
robot.setVelMotor("1","0","500")
robot.setVelMotor("0","0","500")
</syntaxhighlight>

== Sensores ==

port es el número de puerto donde se encuentra conectado el sensor

getButton(port)

getLight(port)

getDistance(port)

getGray(port)

getTemperature(port)

getResistance(port)

getVoltage(port)

setLed(level)
level is 0: off or 1: on

== Carga de batería ==

Esta operacion nos devuelve la carga aproximada de las pilas del robot con un error de 0.1 volt.
La medición de la carga la realizan los motores, por lo cual, si no se tienen los motores, el
valor devuelto es -1.

'''Carga de la Batería'''

<syntaxhighlight lang="python">
carga = robot.getBatteryCharge()
print carga
</syntaxhighlight>

API

2013-04-07T22:44:05Z

AlanJAS: /* Módulos */

Butiá puede utilizarse de muchas formas, como un servicio consumible mediante la red como es el caso de [[bobot|bobot server]] utilizando directamente la biblioteca [[bobot]] o mediante diferentes APIs de programación como C, Java, Python.

==Antes de empezar==

Para utilizar la API es necesario tener corriendo el servidor.
En el caso de [bobot] se debe ejecutar:

./lua bobot-server.lua

Si se desea ver que dispositivos está detectando y mas, se debe habilitar el DEBUG:

./lua bobot-server.lua DEBUG

En el caso de usar [pybot| pybot server] se debe ejecutar:

python pybot_server.py

Para habilitar el DEBUG:

python pybot_server.py DEBUG

Luego de iniciado el servidor, podemos conectarnos desde la butiaAPI.

==Uso de la butiaAPI en Pippy y Python==

Para poder utilizar la librería butiaAPI es necesario que especifiquemos la ruta donde se encuentra.
Para ello, en Pippy agregamos:

import sys
sys.path.insert(0, '/home/olpc/Activities/TurtleBots.activity/plugins/butia')

La ruta /home/olpc.. es la ruta donde por defecto se encuentra TurtleBots cuando se instala en una XO.
En otras computadoras puede variar.
Asimismo, este truco permite utilizar la butiaAPI desde cualquier otro lugar en el sistema, directamente desde python.

Luego de tener eso, procedemos a usar la API.

==butiaAPI==

Descripción de las funciones y algunos ejemplos.

'''Instanciar la clase:'''

<syntaxhighlight lang="python">
robot = butiaAPI.robot()
</syntaxhighlight>

'''Versión del Firmware:'''
Devuelve la versión del firmware de la placa con el que estamos trabajando

<syntaxhighlight lang="python">
ver = robot.getFirmwareVersion()
print ver
</syntaxhighlight>

'''Cerrar:'''
Cierra la comunicación con el servidor

<syntaxhighlight lang="python">
robot.close()
</syntaxhighlight>

'''Conexión/Desconexión con el servidor:'''
Conecta o Reconecta con el servidor

<syntaxhighlight lang="python">
robot.reconnect()
</syntaxhighlight>

'''Cerrar cliente y servidor:'''
Cierra el servidor y el cliente

<syntaxhighlight lang="python">
robot.closeService()
</syntaxhighlight>

== Módulos ==

'''listarModulos:'''

devuelve la lista de los modulos disponibles en el firmware de la placa

<syntaxhighlight lang="python">
modulos = robot.listarModulos()
print modulos
</syntaxhighlight>

'''llamarModulo:'''

Operacion de llamada de una funcion de un modulo (CALL)

<syntaxhighlight lang="python">
robot.llamarModulo(modulename, function , params = "")
</syntaxhighlight>

Para conocer la lista de funciones de un módulo y sus parametros puede ejecutarse en un terminal: 
 
<syntaxhighlight lang="text">
telnet localhost 2009
DESCRIBE nombre_de_modulo
</syntaxhighlight>
A futuro hay que exportar este servicio en la API 

== Funciones Varias ==

'''isPresent'''

Retorna si esta presente el modulo 

<syntaxhighlight lang="python">
robot.isPresent (moduloname)
</syntaxhighlight>

'''abrirLback'''

Abrir módulo loopBack: modulo de ayuda presente en el butia (open)

<syntaxhighlight lang="python">
robot.abrirLback()
datoRet = butiabot.loopBack("hola")
</syntaxhighlight>

'''loopBack:'''

envia un mensaje a la placa y espera recibir exactamente lo que fue enviado

<syntaxhighlight lang="python">
robot.loopBack(data)
</syntaxhighlight>

== Motores ==

Operaciones solicidatas al driver motores.lua

'''abrirMotores:'''

<syntaxhighlight lang="python">
robot.abrirMotores()
</syntaxhighlight>

'''setVelocidadMotores'''

robot.setVelocidadMotores(self, sentidoIzq = "0", velIzq = "0", sentidoDer = "0", velDer = "0")

sentido: 0: adelante, 1: atras
velocidad: 0..1023

Detiene los 2 motores:

<syntaxhighlight lang="python">
robot.setVelocidadMotores("0", "0", "0", "0")
</syntaxhighlight>

robot.setVelocidadMotores("0", "500", "1", "500") - gira a la izquierda

robot.setVelocidadMotores("1", "500", "1", "500") - va hacia atrás

robot.setVelocidadMotores("0", "500", "0", "500") - va hacia adelante

robot.setVelocidadMotores("1", "500", "0", "500") - gira a la derecha

'''setVelMotor'''

robot.setVelMotor(self, idMotor = "0", sentido = "0", vel = "0")

idMotor: 0: motor derecho, 1: motor izquierdo

Va hacia adelante:
<syntaxhighlight lang="python">
robot.setVelMotor("1","1","500")
robot.setVelMotor("0","1","500")
</syntaxhighlight>

Va hacia atrás:
<syntaxhighlight lang="python">
robot.setVelMotor("1","0","500")
robot.setVelMotor("0","0","500")
</syntaxhighlight>

== Sensores ==

port es el número de puerto donde se encuentra conectado el sensor

getButton(port)

getLight(port)

getDistance(port)

getGray(port)

getTemperature(port)

getResistance(port)

getVoltage(port)

setLed(level)
level is 0: off or 1: on

== Carga de batería ==

Esta operacion nos devuelve la carga aproximada de las pilas del robot con un error de 0.1 volt.
La medición de la carga la realizan los motores, por lo cual, si no se tienen los motores, el
valor devuelto es -1.

'''Carga de la Batería'''

<syntaxhighlight lang="python">
carga = robot.getBatteryCharge()
print carga
</syntaxhighlight>