[Butia-devel-list] Futuro y alternativas de motores CC

Lucio Barbieri Martinez barbierimartinezlucio en gmail.com
Lun Mar 25 20:31:50 UYT 2013


Me parece bien.. adelante..


El 25 de marzo de 2013 02:51, Federico Andrade - InCo
<fandrade en fing.edu.uy>escribió:

> me parece excelente idea! El butiá no deja de ofrecer los servicios que
> prestaba hasta ahora, y además se agregan muchas posibilidades a través de
> los hack pines. Me parece que está mejor hacer esto que mantener en
> paralelo dos versiones de placas.
>
> salu2
>
> 2013/3/22 Andres Aguirre <aaguirre en fing.edu.uy>
>
>> ayer hablando con edgardo, llegamos a una idea que creo que va a llevar a
>> una solución Gana-Gana :)
>> La idea va por el lado que menciona john de shield con autodetección.
>> Usar los dos pines que liberamos con el cristal para id.
>>
>> 11 - shield no conectado
>> 10 - shield motores
>> 01 - shield serial y en el hackpin X hablo serial con el shield mediante
>> un micro (pensado para cosas que necesiten micro extra como por ejemplo el
>> módulo de bluetooth) por el mismo serial me auto-detecto también
>> 00 - reservado para uso futuro (el que guarda siempre tiene) a lo mejor
>> sirve para un shield que flasee pics como quería john.. no se
>>
>> Lo que si hay que rutear los pines de vcc y gnd que estan como
>> "hackpines" para usarlos para codificar esto.
>> Si no conecto el shield uso los hackpines como hasta ahora. Sino es un
>> mecanismo para extender la placa.
>>
>> Para mi más allá de que la placa tiene que tener la visión de dar
>> servicio al butiá, creo que la posibilidad de que el estudiente lo pueda
>> hackear hace la difierencia. Es un proceso de aprendizaje muy rico el que
>> genera apropiarse de las cosas.
>>
>> Edgardo se llevo de deberes cambiar el pcb para este esquema, si están
>> todos de acuerdo le damos para adelante.
>> saludos
>> andrés
>>
>>
>>
>>
>> 2013/3/22 John Pereira <jpereira en fing.edu.uy>
>>
>>> Si vamos hacer shield para sensor avanzados o cosas extraordinarias
>>> especificas para el butia, me parece que la idea de guille de hacer un
>>> "sistema pnp" para shilds estaría bueno tenerla en cuenta.
>>> Por lo demas estoy de acuerdo con que el objetivo de la usb4butia es ser
>>> una placa especializada para el robot butia y el tema de que tenga los
>>> hackpines es algo un poco mas alla de ese objetivo, se pusieron por lo que
>>> dice andres en el mail anterior.
>>>
>>> Saludos,
>>> John
>>>
>>> El 21 de marzo de 2013 22:20, Andres Aguirre <aaguirre en fing.edu.uy>escribió:
>>>
>>> Jorge, yo estoy de acuerdo con tu razonamiento y lo entiendo
>>>> perfectamente. Digamos que los hackpines surgieron de casualidad porque
>>>> sobraban pines y la idea era un poco dejar que los gurises más avanzados
>>>> pudieran explorar y cambiar un poco la forma típica de usar la placa (por
>>>> eso hack-pin o hack-point). Por otro lado veo hoy día que hay algunos
>>>> botijas liceales y profesores que están haciendo sus pruebas con la
>>>> USB4butiá y tiene relación lo que hacen con el butiá y también persigue
>>>> algunos de los objetivos del butiá, exploración, apropiación y bajo costo.
>>>> No serán el objetivo principal pero son objetivos al fin.
>>>> El desafío a lo mejor es tratar de dar soporte a los dos "modos" y que
>>>> el objetivo principal de plataforma móvil para programación de
>>>> comportamientos no se vea afectado, al menos no más de lo que estaba antes
>>>> de que arrancaramos a pensar el shield. A lo mejor no es tan difícil y la
>>>> solución es hacer que los hackpines se transformen en el mecanismo de
>>>> shield para motores y posiblemente otros shield y el tipo que quiere usar
>>>> los hackpines no usa la parte móvil de la versión 2.0 o se las arregla para
>>>> usar las dos cosas o hacemos un módulo tipo como los de sensores complejos
>>>> que pensamos hacer un un micro que lo que haga es dar soporte para
>>>> hackpoints. No se... es cuestión de pensarlo. Estoy de acuerdo con jorge,
>>>> hay que buscarle la vuelta para que quede una solución prolija y de alguna
>>>> forma no borremos a los otros usuarios.
>>>> saludos
>>>> andrés
>>>>
>>>>
>>>>
>>>> 2013/3/21 Rodrigo Dearmas <dearmas en fing.edu.uy>
>>>>
>>>>> Estoy de acuerdo con Jorge en la linea del ButiáAntel como la chata
>>>>> con opcion para dos tipos de motores (dynamixel y cc) con sus respectivos
>>>>> conectores y sin hackpines.
>>>>>
>>>>> Y por otro lado una placa USB4ALLGO con hackpines, bus serial y la mar
>>>>> en coche. Hay que mantener dos cosas por separado, para dos tipos de
>>>>> consumidores diferentes.
>>>>>
>>>>>
>>>>> 2013/3/21 Jorge <xxopxe en gmail.com>
>>>>>
>>>>>> Sip, estoy de acuerdo con esta alternativa, por los argumentos además
>>>>>> que resumnió muy bien Andrés en otro mail (si bien a el le atrae mas
>>>>>> otra solución).
>>>>>>
>>>>>> Solo quiero resaltar que hay que pensar el robot como un todo, y no la
>>>>>> placa aisladmente. El "producto" es el robot, no la placa, la placa es
>>>>>> un medio. Es mas, esta versión de la placa, la usb4butia, es parte de
>>>>>> una familia de soluciones, que desciendedn de la usb4all de Andrés&Co.
>>>>>> que se adaptan a un montón de aplicaciones (es una de sus virtudes), y
>>>>>> el Butia es solo una aplcicación más. El alcance de lo que se ponga en
>>>>>> la usb4butia está determinado por lo que querames del robot Butiá, no
>>>>>> lo
>>>>>> que queramos hacer con la placa sola. Si queremos hacer una placa para
>>>>>> otro fin, por ejemplo un banco de prueba para desarrollar con
>>>>>> microcontroladores, lo correcto es hacer otro diseño, que se va a
>>>>>> parecer mucho (tienen un antepasado común) pero va a ser otra cosa.
>>>>>> Tal
>>>>>> vez tenga menos puertos pnp o ninguno, mas pines libres, no tengo el
>>>>>> Ax12, o lo que sea, pero no sobrecarguemos al Butiá con lo que el
>>>>>> Butiá
>>>>>> no es.
>>>>>> La usb4butia tiene que tener lo mínimo indispensable para cumplir lo
>>>>>> que
>>>>>> tiene que cumplir. Y lo que tiene que cumplir es controlar una chata
>>>>>> con
>>>>>> dos ruedas, motorizada en dos alernativas, y tener puertos pnp para
>>>>>> que
>>>>>> el usuario resuelva proyectos de robotica autónoma. Lo mínimo, porque
>>>>>> eso reduce costos y complejidad y por lo tanto aumenta la
>>>>>> confiabilidad.
>>>>>> Y dediquemos el tiempo que no pensemos en hackpines y otras cosas por
>>>>>> el
>>>>>> estilo en lo que realmente hace al Butiá y con los que estamos
>>>>>> atascados
>>>>>> desde hace tiempo: mas sensores y actuadores conectables a los puertos
>>>>>> (un soporte para lapiz? Una placa con relay? El sensor/actuador
>>>>>> c/micro?
>>>>>> El sensor de gas?)
>>>>>>
>>>>>> J.
>>>>>>
>>>>>>
>>>>>> On 03/21/2013 01:33 AM, Enrique Madruga wrote:
>>>>>> > Creo que esto último que decís es correcto, y lo vengo viendo hace
>>>>>> un
>>>>>> > tiempo, TODOS o al menos un 99,5 de nosotros, vemos al Butiá con
>>>>>> ojos
>>>>>> > de desarrolladores, cuanto más cosas tengamos para desarrollar,
>>>>>> > mejorar, crear, inventar, mejor para nosotros, y está bién que sea
>>>>>> > así.
>>>>>> >
>>>>>> > Pero también hay que mirarlo con ojos de Usuario de Kit Butiá, a
>>>>>> quien
>>>>>> > le interesa usarlo así como viene, a esas personas hay que
>>>>>> > facilitarles las cosas, entregarles un kit funcional y ellos se
>>>>>> > encargarán de la programación.
>>>>>> >
>>>>>> > Con el primer Butiá, que tiene los AX12, nadie se pregunta como se
>>>>>> > mueven esos motores, simplemente se conectan a la Usb4Butiá, en el
>>>>>> > tortugarte se ponía adelante y el sale pa'delante.
>>>>>> >
>>>>>> > Porque no hacer algo así, no con serie (o si), sino poner un
>>>>>> conector
>>>>>> > de cuatro pins que se conecte a una placa de potencia (L298) y en el
>>>>>> > TurtleBots hacer un módulo "adelante Butiá" y que el firmware se
>>>>>> > encargue de poner en 1 o 0 los pines necesarios para que los dos
>>>>>> > motores caminen, sin intervención del usuario.
>>>>>> > No es ocultarles cosas, simplemente el facilitarle el uso de Kit
>>>>>> Butiá.
>>>>>> >
>>>>>> > Y si alguien, con un kit, quiere desarrollar algo nuevo... ya sabe
>>>>>> > donde encontrarnos y a toda la información.
>>>>>> >
>>>>>> > Saludos
>>>>>> > Enrique
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > Butia-devel-l site list
>>>>>> > Butia-devel-l en fing.edu.uy
>>>>>> > https://www.fing.edu.uy/mailman/listinfo/butia-devel-l
>>>>>> >
>>>>>>
>>>>>> _______________________________________________
>>>>>> Butia-devel-l site list
>>>>>> Butia-devel-l en fing.edu.uy
>>>>>> https://www.fing.edu.uy/mailman/listinfo/butia-devel-l
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Rodrigo Dearmas*
>>>>> Cel.: 091074641
>>>>> rodearm en gmail.com
>>>>> dearmas en fing.edu.uy
>>>>>
>>>>> _______________________________________________
>>>>> Butia-devel-l site list
>>>>> Butia-devel-l en fing.edu.uy
>>>>> https://www.fing.edu.uy/mailman/listinfo/butia-devel-l
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Butia-devel-l site list
>>>> Butia-devel-l en fing.edu.uy
>>>> https://www.fing.edu.uy/mailman/listinfo/butia-devel-l
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Butia-devel-l site list
>> Butia-devel-l en fing.edu.uy
>> https://www.fing.edu.uy/mailman/listinfo/butia-devel-l
>>
>
>
> _______________________________________________
> Butia-devel-l site list
> Butia-devel-l en fing.edu.uy
> https://www.fing.edu.uy/mailman/listinfo/butia-devel-l
>



-- 
Lucio Barbieri
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: https://www.fing.edu.uy/pipermail/butia-devel-l/attachments/20130325/3122f963/attachment.html


Más información sobre la lista de distribución Butia-devel-l