[Butia-devel-list] Nueva placa de robotica educativa ICARO

[Andres Aguirre]

> en realidad es un software 100% nuevo, tome la idea de turtleart y el
> minibloq (arduino) y estoy armando un soft nuevo.
> la idea es parecida a turtleart, en el sentido de bloques que se
> pegan... pero genera codigo c++ y lo carga en el pic usando el
> bootloader de pinguino (vasco-puf).
> el tema es que todavia hay que probarlo y seguir desarrollando... pero
> ya funciona y genera codigo para le compilador SDCC.
> y la verdad que los bloques me quedaron muy bonitos.

:) interesante

>
>
> mi idea es tener dos instancias de trabajo:
>
> 1) usando turtleart y un firmware que permita conexion con la placa
> (yo estoy usando CDC, y hago conexiones como un puerto serie virtual)
> y aprovechar la docu de turtleart (las pruebas que hicimos, los chicos
> trabajaban primero con turtlart y despues con ICARO)

estamos por pasarnos a CDC ya que como lo tenemos ahora necesitamos
que nos habiliten los permisos en udev.rules para utilizar le
dispositivo y el ceibal no está dando pelota con el pedido :P
Es una pena ya que se pierden buenas características del usb, como te
ha ido con el serial virtual CDC ?

>
> 2) usando icaro-bloques para generar codigo C++ y armar robotitos mas
> chicos y livianos (y mecanicamente mas sencillos), para no tener que
> armar una estructura que sostenga a la XO

entiendo tu motiviación, es una pena que al usarlo de esa forma se
pierden cosas interesantes como el debugger . pero tiene otras
ventajas ser chiquito ;)

>> Nosotros ese camino no lo hemos explorado, nuestro proyecto trata de
>> aprovecar la XO en todo su potencial y por lo tanto siempre es parte
>> del robot, utilizando la cámara con el plugin follow me o usando el
>> mic y el ecelerómetro de la misma.
>
> claro, el tema es que aca en arg, solo estan usando las Xo en una
> provincia, el estado repartió por todos lados las classmate de intel
> (con win7 y ubuntu).. asi que prefiero no quedar tan pegado a las
> posibilidades fisicas del hard y si al soft (es una lastima que
> nuestro gobierno tomara esa decicion.... pero es lo que hay).

mejor que nada ...

>
>> Sería muy bueno si podemos llegar a unificar los sensores de ambos
>> proyectos. Nosotros ahora usamos un pin analógico para detectar que
>> tipo de dispositivo es.
>> Usamos conectores rj45 por los cuales va la alimentación,
>> identificación y datos, de esta manera + muucho soft es que logramos
>> el plug and play en el plugin tortuga y otras actividades sugar como
>> butialo.
>
> lo ultimo que vi del codigo de butia estaba usando una version medio
> viejita de turtleart (106 creo), las versiones nuevas no hace falta
> modificar el codigo fuente de turtleart, si no que trabaja con plugins
> (es lo que estoy usando yo)... seria bueno aprovechar las nuevas
> funcionalidades de turtleart para no hacer forks todo el tiempo (y
> mantener doble codigo)

hace un tiempo cuando vino walter (desarrollador de tortuga) a una
conferencia en montevideo, lo trajimos al lab a tener un "hacking
time" charlamos de algunos problemas que teníamos en ese momento y el
principal era que tortuga no tenía plugins. El entiendio el problema y
lo que nosotros queríamos y en base a eso es que existen los plugins,
enseguida nos pasamos a plugins cuando estuvo pronto, sino sería
imposible seguirle el ritmo a walter :) jeje

>
>
>> En que parte del git puedo acceder al plugin tortuga? estaría bueno
>> también lograr una API común para que pueda ser utilizado ambos robots
>> por un conjunto grande de programas.
>
> descargalo de aca:
>
> la api que uso:
> https://github.com/valentinbasel/apicaro
>
> el plugin para turtleart:
> https://github.com/valentinbasel/tortucaro
>
>
> el soft que estoy armando para generacion de codigo C++:
> https://github.com/valentinbasel/icaro-bloques
>

vamos a mirarlo

>
>> seguimos peloteando por acá si te parece estas y otras ideas que propongas.
>> saludos
>> andrés
>>
> si, creo que podriamos coordinar el uso de los puertos del pic para
> que estandaricemos los pcbs.
> esta semana voy a subir el pcb que mande a fabricar para que lo
> vean...


+1

> yo decidi no dejarlo tan "abierto" el tema de las entradas y
> salidas, para poder trabajar con chicos que no tengan ningun
> conocimiento de electronica decidi integrar el driver de potencia
> l293d y separar 4 puertos de PORTD para controlarlo (y el software
> preparado para eso). los pibes conectan un motor a la bornera y  ya
> esta todo preparado. lo mismo con los servomotores, separe 5 puertos
> para servos (lo minimo para hacer un brazo sencillo)  ,4 sensores
> digitales, 8 puertos analogicos y todo el PORTB libre para
> expansiones.
>
> el pcb en si mismo te limita a un tipo especifico de robot (dos
> motores, un brazo de 5 grados de libertad), pero como ventaja, solo
> tenes que conectar y usar.
>
> lastima que mande a fabricar los pcbs antes de este mail.... podria
> haberlo adaptado a lo que estan desarrollando ustedes y de una ves por
> todas estandarizar :-p
>

bueno, pasanos el PCB y estudiamos formas de lograr compatibilidad.
Está bueno que podamos generar documentación de posibles sensores
caseros a construir y que esa información sea compartida y aprovechada
por los dos proyectos.

>
> obviamente que debemos unificar esfuerzos (insisto fuertemente en el
> chivito de por medio), yo tengo que volver a montevideo un dia de
> estos, la ves anterior me fui en mi moto (una honda cg 150), ahora que
> me compre una honda falcon 400 deberia tardar menos en llegar :-d
> (odio los colectivos).

sos bienvenido!
abrazo
andrés