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

[Andres Aguirre]

Voy a tratar de ser un poco más descriptivo de la idea, me suena de que no
se entendió lo que quería expresar :) . De hecho, creo que no estoy
proponiendo algo tan diferente a lo que jorge tiene en mente, lo que cambia
es algo conceptual, pero no es algo técnico. Va entre líneas:

2013/3/26 Jorge <xxopxe en gmail.com>

> On 25/03/13 21:20, Andres Aguirre wrote:
>
>> el resto?
>>
> La verdad que no le veo un caso de uso... Mejor dicho, los que le veo son
> demasiado "y capaz que". Y seguir moviendo/agregando cosas a esta altura me
> parece medio aventurado. Y encima necesita bastante soporte de firmware
> para funcionar...
>

Como dije antes, no es agregar nada, es una forma de ver las cosas a
futuro.
Hay dos opciones, mantener hackpoint o no.
Supongo que todos estamos de acuerdo que el hbridge para motores de CC se
va a conectar a pines que hoy día son hackpoints, no?
Yo opino que a pesar de utilizar los hackpines para mover los motores de
corriente continua, tienen que seguir existiendo formas para que se
utilicen de forma individual los 8 hackpines desde el alto nivel como hasta
hoy.
Que exista un mecanismo de detección es la manera de implementar esto de
forma clara y segura. Clara porque el software para programar
comportamientos sabe cuando tiene conectado la capa de actuación con
motores CC. Segura a nivel eléctrico porque permite que no se queme un
desarrollo con hackpoints por poner adelante en la tortuga. Programar la
detección del shield es trivial, eso no nos va a mover de nuestro camino
crítico.


Yo prefiero la opción simple, un shield solo de motores CC, con el
> argumento que es solo una manera de no incluir la electrónica de potencia
> en el caso de no usar CC. Es tiempo de cerrar el diseño del butia 2, y me
> parece que asi queda redondo.
>

A nivel práctico es básicamente lo mismo y además igual de práctico,
solamente estoy agregando usar los dos pines que dejamos libre como ID.


> Lo de soportar modulos seriales de comunicación me gustaría incluirlo en
> la lista a resolver en la siguiente iteración de la placa. Y hacerlo serial
> puro, de paso. Y doble capa de arranque :)


Yo lo plantie el serial como algo a futuro, para sensores complejos que
necesiten de un micro o simplemente como una forma de extensión.  No esta
conteplado para la entrega de ANTel. En lo que no estoy de acuerdo es en el
doble capa, para mi es prioritario que la tecnología no sea un impedimento
para trabajar con robótica pedagógica y por eso considero importante usar
shields, es una forma fácil de implementar dos capas. Hasta que no exista
una forma accesible para cualquier profesor de liceo de imprimir algo en
dos capas, tiene que seguir existiendo este diseño. No me parece mal tener
otros diseños multicapa, pero considero fundamental seguir manteniendo este
diseño hasta que el acceso a la tecnología de PCBs cambie radicalmente.
Además me interesa dar soporte a hackpoints y sacando el shield quedan
disponibles pines para hacer otro tipo de experiencias.
Si vamos a pensar un diseño de multicapa ni siquiera pensaría en un
microcontrolador, con los costos de los SOC de hoy día directamente me
inventaría una SBC o usaría el diseño de una ya existente como la beagle y
la modificaría.


>
> Jorge
>
> saludos
andrés
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: https://www.fing.edu.uy/pipermail/butia-devel-l/attachments/20130331/874fe786/attachment.html