python - pepper - ¿Por qué C, C++ y LISP son tan frecuentes en dispositivos integrados y robots?

pepper robot (16)

Parece que las habilidades de lenguaje de software más buscadas para dispositivos integrados y robots son C, C ++ y LISP. ¿Por qué no se han introducido idiomas más recientes en estas aplicaciones?

Por ejemplo, Erlang parece particularmente adecuado para aplicaciones robóticas, ya que facilita la programación simultánea y permite el intercambio de código en caliente. Python parece ser útil, aunque solo sea por su compatibilidad con múltiples paradigmas de programación. Incluso estoy sorprendido de que Java no haya incursionado en la programación robótica general.

Estoy seguro de que un argumento sería: "Algunos idiomas más nuevos se interpretan, no se compilan", lo que implica que los lenguajes compilados son más rápidos y usan menos recursos computacionales. ¿Sigue siendo así, en un momento en que podemos poner una Máquina Virtual Java en un teléfono celular o un SunSpot? (y no se interpreta LISP de todos modos?)

Parece que las habilidades de lenguaje de software más buscadas para dispositivos integrados y robots son C, C ++ y LISP. ¿Por qué no se han introducido idiomas más recientes en estas aplicaciones?

Supongo que se trata de requisitos de espacio, rendimiento y confiabilidad.

Por ejemplo, Erlang parece particularmente adecuado para aplicaciones robóticas, ya que facilita la programación simultánea y permite el intercambio de código en caliente. Python parece ser útil, aunque solo sea por su compatibilidad con múltiples paradigmas de programación. Incluso estoy sorprendido de que Java no haya incursionado en la programación robótica general.

Probablemente se podrían usar muchos más lenguajes en esas plataformas si los implementadores se esforzaran por cuidar las restricciones de tiempo de ejecución. Lo cual no es a menudo el caso. Siempre hay una tendencia a absorber los recursos que tiene a mano, si no lucha deliberadamente por menos.

Estoy seguro de que un argumento sería: "Algunos idiomas más nuevos se interpretan, no se compilan", lo que implica que los lenguajes compilados son más rápidos y usan menos recursos computacionales.

Forth tiene una reputación de ser interpretado, pero pequeño y rápido, y por lo tanto, a menudo se utiliza en dispositivos integrados. Los seguimientos como Factor probablemente también serían buenos candidatos, pero no he oído hablar de ningún esfuerzo en esta dirección, ver más arriba.

¿Sigue siendo así, en un momento en que podemos poner una Máquina Virtual Java en un teléfono celular o un SunSpot?

No soy una persona incrustada, pero un teléfono celular es una plataforma bastante lujosa, en comparación con los controladores en automóviles, como por ejemplo. Pero Java siempre tenía en mente los dispositivos integrados, por lo que su implementación integrada podría incluso llegar más lejos en el espectro de potencia.

(y no se interpreta LISP de todos modos?)

No, compilaciones de implementaciones profesionales, AFAIKT.

Debido a que los dispositivos integrados en su mayoría tienen recursos limitados en los que no es bienvenido tener lujo como el recolector de basura automático. C / C ++ le permite trabajar en niveles bastante bajos y programar cerca de la máquina para que pueda obtener el código efectivo que tanto se necesita en esos dispositivos.

Una área más donde los lenguajes de alto nivel como Java y .NET no funcionan bien es la operación en tiempo real. No puede darse el lujo de estancarse repentinamente porque el recolector de basura acaba de dar un puntapié en el peor momento posible.

Habiendo trabajado con robótica, mi respuesta es la eficiencia. Sí, puede ejecutar una Máquina Virtual Java en teléfonos celulares. Pero, ¿qué tan eficiente será? Estaba en un equipo que quería ejecutar una Máquina Virtual Java en una máquina completa de Windows XP en un robot, ejecutando múltiples aplicaciones de monitoreo en tiempo real en Matlab. Huelga decir que estábamos cayendo marcos como si no fuera asunto de nadie. Moraleja de la historia, anule a las personas que no entienden la informática incluso si necesita anular a sus supervisores si esto va a afectar su funcionamiento.

Sí, podría ejecutar Python, y lo he visto hacer para administrar múltiples procesos en C. Pero al final del día, ejecutar C le permite hacer una manipulación directa de las conexiones mucho más fácil y confiable que algunos de los códigos de nivel superior, y por lo tanto es preferible.

La mayoría de los robots comerciales e industriales están programados en C o C ++. Quizás haya otro idioma con el que el usuario interactúa. Por ejemplo, la empresa de robots industriales para la que trabajo utiliza C que se ejecuta en un sistema operativo VxWork, pero los programadores de aplicaciones como yo trabajamos con un lenguaje propio para comandar el robot. Tanto C como C ++ le brindan una gran cantidad de acceso y control sobre el hardware. No encontrará demasiados controladores comerciales para motores de servocontrol de alta potencia. Aunque complejos, estos robots simplemente siguen rutinas básicas.

LISP se usa principalmente en robots de investigación como los que compitieron en el desafío DARPA. Estos tipos de robots necesitan más "inteligencia" que los robots industriales o comerciales.

La razón principal de la prevalencia de C y C ++ es que el tiempo de ejecución es determinista para ambos debido a la falta de requisitos de recolección de basura. Esto lo convierte en una buena opción cuando debe proporcionar garantías de tiempo de ejecución. No menciono demasiado que C ha sido considerado el "lenguaje de ensamblaje de alto nivel" elegido durante muchos años.

Otra observación interesante es que la mayoría de los dispositivos integrados no necesitan ni siquiera tienen acceso a una capa de GUI compleja: los teléfonos celulares son una excepción obvia. La mayor parte del trabajo incorporado que he hecho profesionalmente ha estado en la arena del decodificador de cable, así que puedo tener una visión sesgada de las cosas. Y "No" , no considero que el decodificador sea un entorno incrustado. Crecimos de tener nada más que un mapa en bruto de memoria de lo que está "en pantalla" y muy poco en términos de recursos. Para abreviar, los gráficos en pantalla son un ejercicio en el que se mezclan bits con anchos de bits fijos; este es otro lugar en el que los punteros en C realmente brillan.

Realmente no estoy demasiado sorprendido de que Java aún no haya avanzado en el mercado más "puro". El intérprete es demasiado pesado a pesar de que se suponía que Java ME resolvería esto. Es bastante frecuente en los teléfonos celulares (por ejemplo, BREW ) y poco a poco se está abriendo camino en los mercados de televisores y decodificadores (por ejemplo, <tru2way> y GEM ) pero aún no está allí y realmente no estoy seguro de que lo será alguna vez

Como han mencionado otros, FORTH es un lenguaje "interpretado" que se ha utilizado en una serie de entornos integrados, así como en bastantes bootloaders . Los lenguajes interpretados definitivamente se pueden usar en entornos en tiempo real. No obstante, no se interpretan todas las implementaciones de FORTH. LISP también ha sido incluido.

Creo que los principales criterios para un lenguaje embebible son:

gestión de la memoria determinista
acceso a tamaños de bits bien definidos (todavía no estoy seguro de cómo se ajusta LISP aquí)
entorno de ejecución simple
completamente funcional o general
modelo de memoria plana

El último punto es el más interesante en mi opinión: esta es también la razón por la que creo que muchos idiomas tendrán problemas en el mercado integrado. Los lenguajes funcionales puros son un complemento natural para la concurrencia y generalmente funcionan en un modelo de memoria plana. Los lenguajes de uso general funcionan bien porque, por lo general, no proscriben ningún modelo de subprocesamiento específico, lo que brinda mucha flexibilidad a los ejecutores de tiempo de ejecución de RTOS. Los entornos de memoria virtual son casi imposibles de implementar, por lo que son deterministas y rápidos. Esto hace que sea muy difícil para los idiomas que requieren soporte de memoria virtual realmente funcionar correctamente.

Mi suposición es que C / C ++ se utilizan porque están más cerca del hardware y permiten una programación que tenga en cuenta los recursos. Esto es generalmente cierto para todos los proyectos integrados, no solo para la robótica.

Entonces creo que a menudo se elige LISP, porque todavía parece ser el idioma predominante en la investigación de inteligencia artificial. LISP probablemente se use para el funcionamiento de mayor nivel del robot, supongo.

Puede hacer robótica con Java en los robots Mindstorm y MS tiene un impulso para hacer robótica, pero en gran medida C / C ++ se utiliza debido a recursos limitados, y LISP se utiliza para AI porque durante mucho tiempo fue un área de la investigación y los investigadores fueron los principales usuarios de LISP, por lo que utilizaron el lenguaje que conocían.

Esta es la misma razón por la que FORTRAN es tan frecuente en la física, por ejemplo, las personas usan el idioma que conocen y cuando el proyecto se convierte en comercial, a menos que desee volver a escribir desde cero, conserva el código original.

Una vez construí un robot basado en Java. Es basura recogida directamente en una pared.

Si vas a tener procesos en ejecución que no puedes microadministrar (p. Ej., Un sistema basado en Linux), entonces deben saber ceder a ciertos procesos de alta prioridad como el control de movimiento. Entonces, o lo haces tú mismo en un lenguaje de bajo nivel como C, o usas un RTOS.

Como ya han señalado otros, C y C ++ se usan porque son de bajo nivel. Otra razón para la popularidad de C es que casi todas las arquitecturas obtienen un compilador de C destinado a ello. Esto es lo suficientemente bueno para mucha gente, por lo que el esfuerzo adicional no se realiza a menudo en otros idiomas. Esto es como decir que C es popular porque C es popular, pero bueno, así es como funcionan las cosas.
Las variantes de LISP son populares en robótica en parte porque las variantes de LISP han sido históricamente populares en la investigación de IA. AI es un foco importante en robótica, por lo que muchas cosas se transfieren de ese campo.
LISP ha existido por mucho tiempo - 1958 según Wikipedia. Tiene más historia que la mayoría de los otros lenguajes de alto nivel, y esto tiene dos implicaciones importantes: 1) LISP está más firmemente establecido (en las áreas que se usa comúnmente) que otros lenguajes de alto nivel y 2) los intérpretes de LISP ya se han hecho ejecutar en todo tipo de hardware de recursos limitados (ver el siguiente punto).
Los intérpretes son más fáciles de implementar para las variantes de LISP que para muchos otros lenguajes de alto nivel, y pueden hacerse razonablemente eficientes. Scheme, por ejemplo, es un lenguaje realmente fácil de analizar, tanto conceptualmente como en el esfuerzo de la CPU.

Para ver por qué otros idiomas no tienen un fuerte punto de apoyo en la programación integrada, simplemente tome la inversa de las razones por las que C, C ++ y LISP tienen un fuerte punto de apoyo.

Ya no son populares en este campo, por lo que no se esfuerza por apoyarlos.
No fueron utilizados por generaciones anteriores, por lo que no se les enseña a los novatos a usarlos.
No tienen mucha historia (en este campo). Ellos representan lo desconocido. Lo desconocido da miedo (y es difícil).
Están imponiendo impuestos al hardware limitado.

NOTA: Cuando hablo de hardware limitado, esto es lo que quiero decir: una gran cantidad de trabajo incorporado todavía implica sistemas con entre 256 bytes y 32 kB de RAM. Un teléfono inteligente que tiene 128 MiB de RAM no es un sistema limitado.

En 20 años en sistemas embebidos (incluyendo 8 años en un proyecto de robótica comercial), nunca he visto a Lisp usar en ninguna parte y no lo consideraría ''predominante''. Vi mucho más a Ada, por ejemplo. Diría que es un nicho, pero si trabajas en ese nicho, puede parecer predominante para ti.

C y C ++ se utilizan porque son lenguajes con capacidad de nivel de sistemas que requieren un soporte de tiempo de ejecución mínimo. Por ejemplo, pueden ejecutarse sin un sistema operativo y, de hecho, se usan comúnmente para implementar sistemas operativos.

Cuando se desarrolla una nueva arquitectura o dispositivo de procesador, C y C ++ son típicamente las primeras herramientas de lenguaje de "alto nivel" disponibles para la plataforma (y suelen ser las únicas disponibles), generalmente desde el primer día, y cada vez más a menudo GNU GCC. La disponibilidad de otros idiomas es desigual o inexistente. Las habilidades C y C ++ son las que prácticamente se garantiza que serán reutilizables en proyectos y arquitecturas.

Lisp es / fue utilizado en algunas investigaciones y algunos robots comerciales. iRobot por ejemplo lo usa. Aquí hay un artículo más antiguo sobre su variante Common Lisp llamada L (<- Link).

Lisp se utiliza cuando hay necesidad de bibliotecas especiales de nivel superior, por ejemplo, para operaciones de planificación complejas. Hay muchas bibliotecas escritas a lo largo del tiempo para varias operaciones de planificación, incluida la planificación de acciones y movimientos de sistemas autónomos.

El sistema integrado necesita un SO mínimo simple y una aplicación simple (no siempre), ya que la mayoría de los OS-es son "C", es una elección natural
Escasez de procesamiento / memoria optimización de la fuerza de recursos desde muy bajo nivel. C (edge over C ++) tiene un gran alcance de optimización

Acabo de leer algunos materiales introductorios de Erlang y una de las primeras cosas que dijeron fue que Erlang era adecuado para el control "en tiempo real". Esto no es algo que quisiera en ningún robot cerca de mí.

Además, diría que los robots (como en el industrial) actualmente no tienen una necesidad real de código intercambiado en caliente. Están trabajando por pieza y siempre habrá un tiempo de inactividad programado para volver a cargar el código en el momento adecuado, lo cual, por supuesto, está bien probado en una unidad fuera de línea.

Una vez me encontré con este fragmento interesante sobre el uso de Lisp en la NASA: http://www.flownet.com/gat/jpl-lisp.html

En 1994 JPL comenzó a trabajar en Remote Agent (RA), un sistema autónomo de control de naves espaciales. RA fue escrito completamente en Common Lisp a pesar de la presión política implacable para pasar a C ++. En un momento dado, se intentó transferir una parte del sistema (el planificador) a C ++. Este intento tuvo que ser abandonado después de un año. Basado en esta experiencia, creo que es seguro decir que si no fuera por Lisp, el Remote Agent habría fallado.

Java hizo otro hito este año cuando se convirtió en una opción de programación para FIRST Robotics Competition . FRC es una competencia impresionante que involucra a más de 77,000 estudiantes de secundaria, mentores y voluntarios de todo el mundo que construyen robots de 120 libras en seis semanas. Acabo de publicar algunos resultados sobre esto en mi blog.

Por una extraña coincidencia (o no), utiliza la misma VM Java que los Sun SPOT mencionados en la pregunta original.

C y C ++ son lenguajes con compiladores muy efectivos (lo que conduce a la eficiencia es muy importante en los sistemas embebidos con bajos recursos).

En cuanto a Lisp, se han generado algunos malentendidos. Common Lisp (algo que se usa en este momento - descendiente de LISP 1.5) es compilado (no interpretado) y muy eficiente con una amplia gama de implementaciones y FFI (es decir, su aplicación Common Lisp puede interoperar con bibliotecas C) y algunas muy buenas construcciones de nivel. La codificación en vivo a través de REPL lo hace aún más conveniente para verificar cosas en el robot en funcionamiento.

Además, está Embeddable Common-Lisp, que permite incrustar la aplicación Common Lisp en C binario; se trata de una implementación compilada en una biblioteca compartida.