[Butia-devel-list] El futuro de PyBot, Python 3

Guillermo Rodriguez guillermor en fing.edu.uy
Sab Mayo 2 19:13:00 -03 2020 

Gracias por la respuesta!

El tema del rendimiento lo digo porque cuando arme butia-c cree este pequeño test: 

https://gist.github.com/guilledk/4f44322d097c9d5fc122fd41d0e21f35

Obtener el valor el sensor de distancia 1000 veces.

Los resultados fueron:

PyBot (2.7 CPython): 0.528 seg https://i.imgur.com/uOO6kgR.png
ButiaC (gcc): 0.273 seg https://i.imgur.com/GJ39jtv.png

Por favor comprobar metodología!
Pero tiene sentido, Python no es conocido por su buen rendimiento.

En un escenario ideal podríamos incluso mantener PyBot 2 vivo creando bindings de la API actual a el core nuevo que se arme.

Salud!

> On 2 May 2020, at 19:02, Alan Jhonn Aguiar Schwyn <alanjas at hotmail.com> wrote:
> 
> Buenas,
> 
> 1) Si, no es complicado sacar "functions" y bajar eso al driver.
> 
> 2) Si, el sistema cliente-servidor se usa muy poco. De ahí mi interés de que PyBot funcionara como cliente-servidor y de forma autónoma. El bloque "butiá IP" de TurtleBots está bueno, pero poca gente ha llegado a usarlo.
> 
> La librería libgstreamer era para el plugin de marcas que es lo único que teníamos que compilar dentro de TurtleBots. En la última versión saqué el plugin de marcas (que necesita ser portado a gstreamer 1.0) y con eso tenemos un único .deb para todas las plataformas.
> 
> Sigo pensando que el que necesita un mejor rendimiento no usa TurtleBots, va directo a Python o algún lenguaje que le guste más. 
> 
> "La API pybot actual usa pyusb, que usa libusb como backend."
> Exacto. Por eso no creo haya tanta diferencia de rendimiento entre PyBot y una API en C. PyBot (salvo algunos detalles) solo pasa mensajes a través de la libusb (que está escrita en C) con ayuda de PyUSB. Habría que hacer pruebas. Las que hice entre Bobot (en Lua) y PyBot eran casi idénticas.
> 
> Saludos
> 
> De: Guillermo Rodriguez <guillermor at fing.edu.uy>
> Enviado: viernes, 1 de mayo de 2020 8:25
> Para: Alan Jhonn Aguiar Schwyn <alanjas at hotmail.com>
> Cc: butia-devel-l at fing.edu.uy <butia-devel-l at fing.edu.uy>
> Asunto: Re: [Butia-devel-list] El futuro de PyBot, Python 3
>  
> Buenas!
> 
> 1) Desde mi punto de vista agregar una archivo mas que simplificar complica la estructura del proyecto innecesariamente, ahora al leer el Driver tengo que tener en cuenta dos (o tres mirando el diagrama) archivos para poder entender todo. Otra realidad es que los que usan las apis directo son PowerUsers, el resto usan TurtleBots, ósea leer una linea más de código no seria un problema, agregar otro archivo sí.
> 
> 2) El tema cliente - servidor, en mi opinión eso tiene que ser aparte es decir, la idea es brindar una api idiomática y con buenas abstracciones y arriba de eso construir si es necesario un cliente-servidor, es algo totalmente aparte de los drivers. El tema cliente servidor debe ser algo aparte, cuanta gente lo usa? La mayoría quieren hablar con un USB4All conectado a un puerto usb local.
> 
> “Me parece bueno actualizar otras APIs, sobre todo en C que le gusta a muchos. La idea de hacer PyBot fue no tener binarios que dependan de la máquina que estuviéramos usando. Con Python no hay que compilar nada y el código anda en XO con arquitectura 386, XO con arquitectura ARM, Magallanes y Positivos con 32 y 64 bits, etc.”
> 
> Pero igual terminamos esclavos de hacer .debs para todas las plataformas y las benditas imágenes desactualizadas de ceibal que requirieren libgstreamer0.1 que no esta ni ahi en los repos…. De esfuerzo es lo mismo, “make”. Tan difícil es compilar para 4 plataformas de las mas usadas? La API pybot actual usa pyusb, que usa libusb como backend.
> 
> Literalmente tenemos tres proyectos separados que son lo mismo Bobot, PyBot 2, Butia-C y ahora PyBot 3 lo mas lógico es unificar todo, proveer un buen backend y después bindings.
> 
> La realidad es que todos necesitamos mejor rendimiento, es algo que mejora el Quality of Life de todos los que usan butia no solo los power users.
> 
> Saludos!
> 
> 
> > On 1 May 2020, at 03:10, Alan Jhonn Aguiar Schwyn <alanjas at hotmail.com> wrote:
> > 
> > Buenas
> > 
> > Si, es hora de actualizar a Python 3.
> > 
> > En cuanto al archivo "functions" su existencia se debe a 2 razones:
> > 
> > 1) Que los archivos de drivers sean lo más simple posible. La idea era que la gente tirara un archivo ahí dentro, con casi nada de código y funcionara.
> > 2) En algún momento, preocupado por la performance de hacer ciertas conversiones de datos y pasar a través del socket, pensé en unificar el código para que se pudiera usar como "cliente-servidor" y directo por otro. Adjunto imagen con un diagrama que hice en su momento. La flecha de la izquierda es el flujo que se tiene cuando se usa sin pasar por el cliente-servidor y la flecha central es el flujo habitual con cliente-servidor. El principal problema que veía era que todo se unía para pasar a ser una string por el socket y después se volvía a separar para obtener los datos. Hay muchas conversiones que hay que simplificar. Nunca le di tiempo a esa parte.
> > 
> > Me parece bueno actualizar otras APIs, sobre todo en C que le gusta a muchos. La idea de hacer PyBot fue no tener binarios que dependan de la máquina que estuviéramos usando. Con Python no hay que compilar nada y el código anda en XO con arquitectura 386, XO con arquitectura ARM, Magallanes y Positivos con 32 y 64 bits, etc.
> > 
> > La API en Lua se llama Bobot y funciona bien. El único problema era tener que compilar el libusb para diferentes máquinas, cuando Ceibal empezó a incorporar otros equipos.
> > 
> > Me parece un retroceso volver a tener que compilar código. El que usa TurtleBots no precisa un rendimiento excepcional, ya que el cuello de botella no es PyBot, está en el propio TurtleBots y su forma de ejecutar código.
> > Quien necesite mejor rendimiento, va a usar la API en C y su código también.
> > 
> > Saludos
> > 
> > De: butia-devel-l-bounces at fing.edu.uy <butia-devel-l-bounces at fing.edu.uy> en nombre de Guillermo Rodriguez <guillermor at fing.edu.uy>
> > Enviado: jueves, 30 de abril de 2020 9:59
> > Para: butia-devel-l at fing.edu.uy <butia-devel-l at fing.edu.uy>
> > Asunto: [Butia-devel-list] El futuro de PyBot, Python 3
> >  
> > Buenas!
> > 
> > Considerando el “End Of Life” de Python 2 (https://www.bleepingcomputer.com/news/software/python-27-reaches-end-of-life-after-20-years-of-development/), estamos viendo de actualizar la API PyBot a Python 3.
> > 
> > La idea es tener una discusión sobre cual es la mejor arquitectura a implementar, para los que no conocen la API acá una breve descripción de su estructura:
> > 
> > REPO: https://github.com/guilledk/pybot
> > 
> > com_usb.py: provee abstracción sobre modulo “pyusb”.
> > 
> > device.py: provee abstracción que representa cada modulo sensor / actuador.
> > 
> > baseboard.py: provee abstracción que representa cada placa usb4butia conectada.
> > 
> > usb4butia.py: métodos para inicializar y controlar una o más placas conectadas.
> > 
> > functions.py: baseboard nos da una función genérica “callModule”, en este archivo se definen todos los calls para los diferentes “drivers” (distancia, grises etc), pero la implementación final de dichas calls se encuentra separadas en varios submodulos en la carpeta “drivers”.
> > 
> > La idea que rescato de esta API es exponer abstracciones para representar la comunicación usb, la placa y los módulos, una cosa que cambiaria seria la implementación del sistema de llamadas a drivers, no tiene mucho sentido separarlo de esa forma, los drivers pueden vivir cada uno en su modulo y desde ahi también exponer llamadas de la API, no hace falta tener un archivo adicional “functions.py” para declarar dichos calls.
> > 
> > En 2016 intente hacer una API de butia en C (https://github.com/guilledk/butiac, ojo esto es code viejo y es medio ewww), y logre implementar todos los sensores comunes, me quede en testear la implementación de los motores. Lo interesante fue que en benchmarks la API en C fue como un 80% mas rápida.
> > 
> > Mi planteo seria implementar la API en un lenguaje compilado (C, Rust) y luego producir bindings (esto es super fácil) a cualquier lenguaje que se desee usar, Lua, Python y lo que venga.
> > _______________________________________________
> > Butia-devel-l site list
> > Butia-devel-l at fing.edu.uy
> > https://www.fing.edu.uy/mailman/listinfo/butia-devel-l
> > <pybot structure_recorted.png>_______________________________________________
> > Butia-devel-l site list
> > Butia-devel-l at fing.edu.uy
> > https://www.fing.edu.uy/mailman/listinfo/butia-devel-l
> 
> _______________________________________________
> Butia-devel-l site list
> Butia-devel-l at fing.edu.uy
> https://www.fing.edu.uy/mailman/listinfo/butia-devel-l

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