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

[Andres Aguirre]

entre líneas:


2013/4/1 Jorge <xxopxe en gmail.com>

> Comento entre lineas.
>
>
> On 31/03/13 22:14, Andres Aguirre wrote:
>
>> Como dije antes, no es agregar nada, es una forma de ver las cosas a
>> futuro.
>>
> Según entendí hay que volver a cambiar el enrutamiento. Otra vez. En
> cuanto a la visión de futuro, comento más adelante.


Supongo que te referís al enrutamiento del shield, de hecho ya hay que
cambiarlo porque el que tenemos no camina, así que eso no es un problema.


>
>
>  Hay dos opciones, mantener hackpoint o no.
>>
> Por mi, no si complican lo mas mínimo al Butia 2. O sea, no. Hackpines no
> es Butia 2.0, y nunca lo fue. En un momento se agregaron para hacer cosas
> que no eran Butia, porque no jodían. Ahora resulta que joden.


A mi modo de verlo ya está resuelto el problema, por lo tanto yo no diría
que jode.


>
>
>  Programar la detección del shield es trivial, eso no nos va a mover de
>> nuestro camino crítico.
>>
> Lo que está en el camino es toda la idea de hackpines. Este tiempo debería
> usarse en hacer sensores y actuadores. Todo el tiempo que estamos gastando
> en esto es tiempo perdido. La usb4all ya existe y es compatible, ahí estan
> todos los hackpines que puedan hacer falta.


Yo no creo que se pierda el tiempo pensando y buscando una solución de
consenso. Si hay un feature como los hackpines que puede ser interesante
mantener en la usb4butia me parece bien discutirlo.
También estamos carburando cosas con nuevos sensores, vamos avanzando en
medida de lo posible.


>
>
>  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.
>>
> Butia 2.0 se acaba en Butia 2.0. Por algunos de los argumentos que
> mencionas, al diseño actual no le queda mucho futuro, porque dentro de dos
> años la tecnología va a ser otra. Deberíamos estar aprovechando el
> presente, y eso es sacando lo antes posible Butia 2.0, y que sea lo más
> accesible posible (minimizar costo, producción viable) y usable posible
> (software testeado, documentación, sensores suficientes). Y proyectos de
> ejemplo que muestren todo, y la lista sigue.


Nadie dice de no hacerlo


>
>
>  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.
>>
> Esto es independiente de la discusión actual de los hackpines, por eso no
> voy a argumentar demasiado. Solo diré: deberíamos regalar las placas.


Bueno, avisa de donde estas sacando plata porque realmente la necesitamos.
No estamos en condiciones de regalar nada actualmente y de hecho
si tuviéramos la plata me parece que tiene mucho más valor hacer que la
gente se apropie de las cosas y aprenda a construirlas que regalárselas. :)


>
>
>  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.
>>
> Yo estoy a favor :)
>
> :) Necesitamos voluntarios para escribir ese proyecto.

> Jorge
>
> PS: estoy con fiebre, por las dudas.
>
> Espero estés mejor


> PS2: Probando la herramienta splint la apunté a los .c del firmware... y
> detonó. Encontró una torta de asignaciones de int a byte, shifts con
> números negativos, y cosas por el estilo. Alguien que sepa podría pegar una
> revisada...
>

Te animas de subir esa salida a una entrada en la wiki? así podemos ir
atacando esos problemas. También especifica el checkout que estas usando.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: https://www.fing.edu.uy/pipermail/butia-devel-l/attachments/20130403/f20781df/attachment.html