robots robotico robotica programas programar programación programacion para metodos mencionar lenguajes lenguaje kuka fabricantes brazo algunos abb robotics labview graphical-language

robotics - robotico - programas para programar robots



Textual versus lenguajes de programación gráfica (25)

Soy parte de un equipo de robótica de la escuela secundaria, y existe cierto debate sobre qué idioma usar para programar nuestro robot. Estamos eligiendo entre C (o tal vez C ++) y LabVIEW. Hay pros para cada idioma.

C (++):

  • Ampliamente utilizado
  • Buena preparación para el futuro (la mayoría de los puestos de programación requieren programadores basados ​​en texto).
  • Podemos ampliar nuestra base de código C del año pasado
  • Nos permite entender mejor lo que está haciendo nuestro robot.

LabVIEW

  • Más fácil de visualizar el flujo del programa (bloques y cables, en lugar de líneas de código)
  • Más fácil de enseñar (supuestamente ...)
  • "El futuro de la programación es gráfico". (¿Eso creo?)
  • Más cerca del fondo Robolab que algunos miembros nuevos pueden tener.
  • No necesita saber íntimamente lo que está pasando. Simplemente dígale al módulo que busque la bola roja, no necesita saber cómo.

Esta es una decisión muy difícil para nosotros, y hemos estado debatiendo durante un tiempo. En función de esos profesionales para cada idioma y de la experiencia que tenga, ¿cuál cree que es la mejor opción? Tenga en cuenta que no necesariamente vamos por pura eficiencia. También esperamos preparar a nuestros programadores para un futuro en la programación.

También:

  • ¿Crees que los lenguajes gráficos como LabVEIW son el futuro de la programación?
  • ¿Es más fácil aprender un lenguaje gráfico que un lenguaje textual? Creo que deberían ser igualmente difíciles de aprender.
  • Al ver que estamos parcialmente arraigados en ayudar a las personas a aprender, ¿cuánto debemos confiar en los módulos preescritos, y cuánto debemos tratar de escribir por nuestra cuenta? ("Los buenos programadores escriben buen código, los grandes programadores copian código excelente". Pero, ¿no vale la pena ser un buen programador, primero?)

¡Gracias por el consejo!

Editar: Me gustaría enfatizar más esta pregunta: el capitán del equipo piensa que LabVIEW es mejor por su facilidad de aprendizaje y enseñanza. ¿Es eso cierto? Creo que C podría enseñarse con la misma facilidad, y las tareas de nivel principiante todavía estarían con C. Realmente me gustaría escuchar sus opiniones. ¿Hay alguna razón por la que teclear while {} debería ser más difícil que crear una "caja while"? ¿No es tan intuitivo que el programa fluye línea por línea, solo modificado por ifs y loops, ya que es intuitivo que el programa fluya a través del cable, solo modificado por ifs y loops?

¡Gracias de nuevo!

Editar: Me acabo de dar cuenta de que esto se enmarca en el tema del "debate lingüístico". Espero que esté bien, porque se trata de lo que es mejor para una rama específica de la programación, con ciertos objetivos. Si no es ... Lo siento ...

La gente siempre se comparan con LabVIEW C ++ y día "oh LabVIEW es de alto nivel y se ha incorporado tanto en funcionalidad intentar la adquisición de datos haciendo un dfft y la visualización de los datos de su tan fácil en LabVIEW probarlo en C ++".

Mito 1: Es difícil conseguir cualquier cosa hecha con C ++ su ya porque es muy bajo nivel y LabVIEW tiene muchas cosas en marcha. El problema es si está desarrollando un sistema robótico en C ++ Debe utilizar bibliotecas como OpenCV, PCL .. ect y que sería aún más inteligente si se utiliza un marco de software diseñado para la construcción de sistemas robóticos como ROS (sistema operativo del robot). Por lo tanto es necesario utilizar un conjunto completo de herramientas. De hecho, existen herramientas más alto nivel disponibles cuando se utiliza, ROS + Python / C ++ con las bibliotecas como OpenCV y PCL. algoritmos que he utilizado robótica LabVIEW y francamente de uso común como la PIC no están allí y que no es como usted puede utilizar otras bibliotecas fácilmente ahora.

Myth2: ¿Es fácil de entender lenguajes de programación gráfica

Depende de la situación.Cuando se está codificando un algoritmo complicado los elementos gráficos se ocupan valioso espacio en pantalla y será difícil de entender el método. Para entender el código de LabVIEW usted tiene que leer sobre un área que es O (n ^ 2) la complejidad en el código que acaba de leer de arriba a abajo.

¿Qué pasa si usted tiene sistemas paralelos. ROS implementa una arquitectura basada gráfico basado en mensajes subcriber / editor implementadas usando devolución de llamada y es bastante fácil de tener varios programas en ejecución y que se comunican. Tener componentes individuales separados paralelos hace que sea más fácil de depurar. Por ejemplo paso a paso a través de código LabVIEW paralelo es una pesadilla porque el flujo de control salta forma un lugar a otro. En ROS usted no explícitamente ''dibuja a cabo su archietecture como en LabVIEW, sin embargo todavía se puede ver que mi ejecutando los comandos ros rqt_graph ejecutar (que mostrará todos los nodos conectados)

"El futuro de la programación es gráfico." (¿Eso creo?)

Espero que no, la actual aplicación de LabVIEW no permite codificar utilizando métodos basados ​​en texto y métodos gráficos. (No se MathScript, sin embargo, esto es muy lento)

Es difícil de depurar porque usted no puede ocultar el paralelismo con facilidad.

Es difícil de leer el código de LabVIEW, porque no hay que mirar por encima de tanta área.

Labview es grande para aq de datos y procesamiento de la señal, pero la robótica no experimentales, porque la mayoría de los componentes de alto nivel como SLAM (localización simultánea y mapeo), el registro de nube de puntos, el procesamiento de nube de puntos ect están desaparecidos. Incluso si lo hacen añadir estos componentes y son fáciles de integrar al igual que en ROS, porque LabVIEW es propietaria y costoso que nunca mantenerse al día con la comunidad de código abierto.

En resumen, si LabVIEW es el futuro de la mecatrónica estoy cambiando mi carrera a la banca de inversión ... Si no puedo disfrutar de mi trabajo puedo también hacer algo de dinero y retirarse antes de tiempo ...

Estás en la escuela secundaria. ¿Cuánto tiempo tienes para trabajar en este programa? ¿Cuantas personas hay en tu grupo? ¿Ya conocen C ++ o LabView?

De su pregunta, veo que usted conoce C ++ y la mayoría del grupo no. También sospecho que el líder del grupo es lo suficientemente perspicaz como para darse cuenta de que algunos miembros del equipo pueden sentirse intimidados por un lenguaje de programación basado en texto. Esto es aceptable, estás en la escuela secundaria, y estas personas son normales . Siento que los estudiantes normales de secundaria podrán entender LabView más intuitivamente que C ++. Supongo que la mayoría de los estudiantes de secundaria, como la población en general, tienen miedo de una línea de comando. Para ti hay mucha menos diferencia, pero para ellos, es de noche y de día.

Tiene razón en que los mismos conceptos se pueden aplicar a LabView como C ++. Cada uno tiene sus fortalezas y debilidades. La clave es seleccionar la herramienta adecuada para el trabajo. LabView fue diseñado para este tipo de aplicación . C ++ es mucho más genérico y se puede aplicar a muchos otros tipos de problemas.

Voy a recomendar LabView. Dado el hardware correcto, puede estar funcionando casi de fábrica. Su equipo puede dedicar más tiempo a hacer que el robot haga lo que usted desea , que es el objetivo de esta actividad.

Los lenguajes gráficos no son el futuro de la programación; han sido una de las opciones disponibles, creadas para resolver ciertos tipos de problemas, durante muchos años. El futuro de la programación es una capa tras otra de abstracción del código máquina. En el futuro, nos preguntaremos por qué perdimos todo este tiempo programando "semántica" una y otra vez.

¿cuánto debemos confiar en los módulos preescritos, y cuánto debemos tratar de escribir por nuestra cuenta? No debes perder el tiempo reinventando la rueda. Si hay controladores de dispositivo disponibles en Labview, úselos. Puede aprender mucho copiando un código similar en función y adaptándolo a sus necesidades: puede ver cómo otras personas resuelven problemas similares y deben interpretar su solución antes de poder aplicarla correctamente a su problema. Si copia el código a ciegas, las posibilidades de que funcione son mínimas. Tienes que ser bueno, incluso si copias el código.

¡La mejor de las suertes!

Creo que los lenguajes gráficos podrían ser el lenguaje del futuro ... para todos aquellos desarrolladores ad hoc de MS Access. Siempre habrá un lugar para los codificadores puramente textuales.

Personalmente, tengo que preguntar ¿cuál es la verdadera diversión de construir un robot si todo está hecho para ti? ¿Si acabas de soltar un módulo de "encuentra la bola roja" y lo ves ir? ¿Qué sentido de orgullo tendrá para su logro? Personalmente, no tendría mucho. Además, ¿qué le enseñará de la codificación, o del aspecto (muy importante) de la interfaz de software / hardware que es crítico en robótica?

No pretendo ser un experto en el campo, pero pregúntese una cosa: ¿cree que la NASA utilizó LabVIEW para codificar los Mars Rovers? ¿Crees que alguien realmente destacado en robótica está utilizando LabView?

Realmente, si me preguntan, lo único que usarán cosas como cortador de galletas, como LabVIEW, para construir esto, lo prepararán para que sea un generador de robots de patio trasero y nada más. Si desea algo que le brinde algo más parecido a la experiencia de la industria, cree su propio sistema de tipo "LabVIEW". Construya su propio módulo de búsqueda del balón, o su propio módulo ''seguir la línea''. Será mucho más difícil, pero también será mucho más genial. :RE

Creo que los lenguajes gráficos siempre tendrán una expresividad limitada en comparación con los textuales. Compare tratar de comunicarse en símbolos visuales (por ej., REBUS o lenguaje de señas) para comunicarse usando palabras.

Para tareas simples, usar un lenguaje gráfico suele ser más fácil, pero para una lógica más compleja, encuentro que los lenguajes gráficos se interponen en el camino.

Otro debate implícito en este argumento, sin embargo, es la programación declarativa vs. imperativa. Declarativo generalmente es mejor para cualquier cosa en la que realmente no se necesita un control minucioso sobre cómo se hace algo. Puede usar C ++ de forma declarativa, pero necesitaría más trabajo por adelantado para hacerlo, mientras que LABView está diseñado como un lenguaje declarativo.

Una imagen vale más que mil palabras, pero si una imagen representa mil palabras que no necesitas y no puedes cambiar eso, entonces, en ese caso, una imagen no tiene valor. Mientras que puedes crear miles de imágenes usando palabras, especificando cada detalle e incluso dirigiendo el foco del espectador de forma explícita.

Esto no responde su pregunta directamente, pero es posible que desee considerar una tercera opción de mezcla en un lenguaje interpretado. Lua , por ejemplo, ya se usa en el campo de la robótica. Es rápido, liviano y puede configurarse para funcionar con números de punto fijo en lugar de coma flotante, ya que la mayoría de los microcontroladores no tienen una FPU. Forth es otra alternativa con un uso similar.

Sería bastante fácil escribir una capa de interfaz delgada en C y luego dejar que los estudiantes pierdan scripts interpretados. Incluso podría configurarlo para permitir que el código se cargue dinámicamente sin volver a compilar ni flashear un chip. Esto debería reducir el ciclo de iteración y permitir que los estudiantes aprendan mejor al ver los resultados más rápidamente.

Soy parcial en contra del uso de herramientas visuales como LabVIEW. Siempre parece que toco algo que no funciona o no funciona como quiero que haga. Por lo tanto, prefiero el control absoluto que obtienes con el código de texto.

Me he encontrado con una situación similar en el grupo de investigación en el que estoy trabajando actualmente. Es un grupo de biofísica y estamos utilizando LabVIEW para controlar nuestros instrumentos. Eso funciona absolutamente bien: es fácil armar una interfaz de usuario para controlar todos los aspectos de sus instrumentos, ver su estado y guardar sus datos.

Y ahora tengo que dejar de escribir un discurso de 5 páginas, porque para mí LabVIEW ha sido una pesadilla. Permítanme intentar resumir algunos pros y contras:

Descargo de responsabilidad No soy un experto en LabVIEW, podría decir cosas que son parciales, desactualizadas o simplemente incorrectas :)

LabVIEW pros

  • Sí, es fácil de aprender . Muchos doctores en nuestro grupo parecen haber adquirido suficientes habilidades para hackear en unas pocas semanas, o incluso menos.
  • Bibliotecas Este es un punto importante. Tendría que investigar cuidadosamente esto para su propia situación (no sé lo que necesita, si hay buenas bibliotecas de LabVIEW para él, o si hay alternativas en otros idiomas). En mi caso, encontrar, por ejemplo, una buena y rápida biblioteca de gráficos en Python ha sido un problema importante, que me ha impedido reescribir algunos de nuestros programas en Python.
  • Su escuela ya puede tenerlo instalado y funcionando.

Contras de LabVIEW

  • Quizás es demasiado fácil de aprender. En cualquier caso, parece que nadie se molesta en aprender las mejores prácticas, por lo que los programas se convierten rápidamente en un desastre completo e irreparable. Claro, eso también sucederá con los lenguajes basados ​​en texto si no tiene cuidado, pero IMO es mucho más difícil hacer las cosas bien en LabVIEW.
  • Tienden a haber problemas importantes en LabVIEW para encontrar sub-VI (incluso hasta la versión 8.2, creo). LabVIEW tiene su propia forma de saber dónde encontrar bibliotecas y sub-VI, lo que hace que sea muy fácil romper completamente su software. Esto hace que los proyectos grandes sean un dolor si no tienes a alguien alrededor que sepa cómo manejar esto.
  • Hacer que LabVIEW funcione con el control de versiones es un problema . Claro, se puede hacer, pero en cualquier caso me abstendré de usar el VC incorporado. Echa un vistazo a LVDiff para una herramienta de diferencia de LabVIEW, pero ni siquiera pienses en fusionar.

(Los dos últimos puntos dificultan el trabajo en equipo en un proyecto. Probablemente sea importante en su caso)

  • Esto es personal, pero me parece que muchos algoritmos simplemente no funcionan cuando se programan visualmente. Es un desastre .
    • Un ejemplo es material estrictamente secuencial; eso se torna bastante rápido.
    • Es difícil tener una visión general del código.
    • Si usa sub-VI para tareas pequeñas (al igual que una buena práctica para realizar funciones que realizan una tarea pequeña y que se ajustan en una pantalla), no puede simplemente asignarles nombres, sino que debe dibujar íconos para cada uno. de ellos. Eso se pone muy molesto y engorroso en tan solo unos minutos, por lo que te sientes muy tentado de no poner cosas en un sub-VI. Es demasiada molestia. Por cierto: hacer un icono realmente bueno puede tomar horas profesionales. Intenta crear un ícono único, reconocible e identificable para cada sub-VI que escribas :)
  • Tendrás túnel carpiano dentro de una semana. Garantizado
  • @Brendan: ¡escucha, escucha!

Observaciones finales

En cuanto a su pregunta "¿Debería escribir mis propios módulos?": No estoy seguro. Depende de tus limitaciones de tiempo. No pierdas tiempo reinventando la rueda si no tienes que hacerlo. Es muy fácil pasar días escribiendo código de bajo nivel y luego darse cuenta de que se ha quedado sin tiempo. Si eso significa que eliges LabVIEW, ve por ello.

Si hubiera formas fáciles de combinar LabVIEW y, por ejemplo, C ++, me encantaría saberlo: eso puede darte lo mejor de ambos mundos, pero lo dudo que exista.

Pero asegúrese de que usted y su equipo dediquen tiempo a aprender las mejores prácticas. Mirando el código de cada uno. Aprendiendo el uno del otro. Escribir código comprensible y utilizable. ¡Y divirtiendome!

Y por favor, perdóname por sonar nervioso y tal vez algo pedante. Es solo que LabVIEW ha sido una verdadera pesadilla para mí :)

Parece que si estás tratando de preparar a nuestro equipo para un futuro en la programación, C (++) será la mejor ruta. La promesa de los lenguajes de programación generales que se construyen con bloques de construcción visuales nunca pareció materializarse y estoy empezando a preguntarme si alguna vez lo harán. Parece que si bien se puede hacer para dominios de problemas específicos, una vez que intentas resolver muchos problemas generales, un lenguaje de programación basado en texto es difícil de superar.

En un momento, me había gustado la idea de UML ejecutable, pero parece que una vez que superas las relaciones entre objetos y algunos de los flujos de proceso, UML sería una forma bastante miserable de crear una aplicación. Imagine tratar de conectarlo todo a una GUI. No me importaría que se demuestre que estoy equivocado, pero hasta ahora parece poco probable que apuntemos y hagamos clic en programar pronto.

Comencé con LabVIEW hace aproximadamente 2 años y ahora lo uso todo el tiempo, por lo que puede ser parcial, pero lo encuentro ideal para aplicaciones donde la adquisición de datos y el control están involucrados.

Usamos LabVIEW principalmente para realizar pruebas donde tomamos mediciones continuas y controlamos las válvulas de gas y los gabinetes ATE. Esto involucra entradas y salidas digitales y análogas con rutinas de análisis de señales y control de procesos, todo desde una GUI. Al dividir cada parte en subVIs, podemos reconfigurar las pruebas haciendo clic y arrastrando el mouse.

No es exactamente lo mismo que C / C ++, pero una implementación similar de medición, control y análisis con Visual BASIC parece compleja y difícil de mantener por comparación.

Creo que el proceso de programación es más importante que el lenguaje de codificación real y debe seguir las pautas de estilo para un lenguaje de programación gráfica. Los diagramas de bloques de LabVIEW muestran el flujo de datos ( programación de Dataflow ) por lo que debería ser fácil ver las posibles condiciones de carrera, aunque nunca he tenido ningún problema. Si tiene una base de código C, compilarla en una dll permitirá que LabVIEW la llame directamente.

Dios mío, la respuesta es muy simple. Use LabView .

He programado sistemas embebidos durante 10 años, y puedo decir que sin al menos un par de meses de infraestructura (¡infraestructura muy cuidadosa!), Usted no será tan productivo como lo es el día 1 con LabView .

Si está diseñando un robot para vender y usar para el ejército, continúe y comience con C: es una buena decisión.

De lo contrario, use el sistema que le permite probar la mayor variedad en el menor tiempo posible. Eso es LabView .

Me encanta LabVIEW. Lo recomendaría especialmente si el otro recuerda haber usado algo similar. Los programadores normales tardan un tiempo en acostumbrarse, pero los resultados son mucho mejores si ya sabes cómo programar.

C / C ++ es igual a administrar tu propia memoria. Estarás nadando en enlaces de memoria y preocupándote por ellos. Vaya con LabVIEW y asegúrese de leer la documentación que viene con LabVIEW y tener cuidado con las condiciones de carrera.

Aprender un idioma es fácil. Aprender a programar no lo es. Esto no cambia aunque sea un lenguaje gráfico. La ventaja de los lenguajes gráficos es que es más fácil visualizar qué hará el código en lugar de sentarse allí y descifrar un montón de texto.

Lo importante no es el lenguaje, sino los conceptos de programación. No debería importar en qué idioma aprenda a programar, porque con un poco de esfuerzo debería poder programar bien en cualquier idioma. Los idiomas van y vienen.

Le sugiero que use LabVIEW ya que puede hacer que el robot sea lo que quiere hacer más rápido y más fácil. LabVIEW ha sido diseñado con esta mente. OfCourse C (++) son excelentes idiomas, pero LabVIEW hace lo que se supone que debe hacer mejor que cualquier otra cosa. La gente puede escribir un software realmente bueno en LabVIEW ya que proporciona un amplio alcance y soporte para eso.

El capitán del equipo piensa que LabVIEW es mejor por su facilidad de aprendizaje y enseñanza. ¿Es eso cierto?

Dudo que eso sea cierto para cualquier idioma o paradigma. LabView seguramente podría ser más fácil para personas con experiencia en ingeniería electrónica; hacer programas en él es "simplemente" dibujar cables. Por otra parte, esas personas ya podrían estar expuestas a la programación, también.

Una diferencia esencial, aparte de la gráfica, es que el VI es una programación basada en la demanda (flujo). Comienzas desde el resultado y dices, qué se necesita para llegar a eso. La programación tradicional tiende a ser imperativa (yendo al revés).

Algunos idiomas pueden proporcionar los dos. Diseñé una biblioteca de subprocesos múltiples para Lua recientemente (Lanes) y puede usarse para programación basada en la demanda en un entorno que de otro modo sería imperativo. Sé que hay robots exitosos que se ejecutan principalmente en Lua ( Iván loco en Lua Oh Six).

Definitivamente hay méritos para ambas opciones; sin embargo, dado que su dominio es una experiencia educativa, creo que una solución C / C ++ sería la que más beneficiaría a los estudiantes. La programación gráfica siempre será una opción, pero simplemente no proporciona la funcionalidad de una manera elegante que lo haría más eficiente de usar que la programación de texto para la programación de bajo nivel. Esto no es algo malo: el objetivo de la abstracción es permitir una nueva comprensión y visión de un dominio problemático. La razón por la que creo que muchos pueden estar decepcionados con la programación gráfica es que, para cualquier programa en particular, la ganancia incremental al pasar de la programación en C a la gráfica no es casi lo mismo que pasar del ensamble a C.

El conocimiento de la programación gráfica beneficiaría a cualquier programador futuro con seguridad. Probablemente habrá oportunidades en el futuro que solo requieran conocimiento de programación gráfica y tal vez algunos de sus estudiantes se puedan beneficiar de alguna experiencia temprana con este. Por otro lado, una base sólida en los conceptos fundamentales de programación que ofrece un enfoque textual beneficiará a todos sus estudiantes y seguramente debe ser la mejor respuesta.

Creo que la elección de LabVIEW o no se reduce a si desea aprender a programar en un lenguaje de uso común como una habilidad comercializable, o simplemente quiere hacer las cosas. LabVIEW le permite obtener material de forma rápida y productiva. Como otros han observado, no te libera mágicamente de tener que entender lo que estás haciendo, y es bastante posible crear un lío impío si no lo haces - aunque anecdóticamente, los peores ejemplos de mal estilo de codificación en LabVIEW son generalmente perpetrado por personas que tienen experiencia en un lenguaje de texto y se niegan a adaptarse a cómo funciona LabVIEW porque "ya saben cómo programar, maldita sea".

Eso no implica que la programación de LabVIEW no sea una habilidad comercializable, por supuesto; solo que no es tan masivo como C ++.

LabVIEW hace que sea extremadamente fácil administrar diferentes cosas en paralelo, lo que bien puede tener en una situación de control de robot. Las condiciones de carrera en el código que deberían ser secuenciales tampoco deberían ser un problema (es decir, si lo son, lo estás haciendo mal): hay técnicas simples para asegurarte de que las cosas suceden en el orden correcto cuando sea necesario, encadenando subVI usando el cable de error u otros datos, usando notificadores o colas, construyendo una estructura de máquina de estado, incluso usando la estructura de secuencia de LabVIEW si es necesario. De nuevo, esto es simplemente un caso de tomarse el tiempo para comprender las herramientas disponibles en LabVIEW y cómo funcionan. No creo que la queja sobre tener que hacer iconos subVI esté muy bien dirigida; puede crear muy rápidamente una que contenga algunas palabras de texto, tal vez con un color de fondo, y eso estará bien para la mayoría de los propósitos.

"Son los lenguajes gráficos el camino del futuro" es una pista falsa basada en una falsa dicotomía. Algunas cosas se adaptan bien a los lenguajes gráficos (código paralelo, por ejemplo); otras cosas se adaptan mucho mejor a los idiomas de texto. No espero que LabVIEW y la programación gráfica desaparezcan o se hagan cargo del mundo.

Incidentalmente, me sorprendería mucho que la NASA no usara LabVIEW en el programa espacial. Alguien describió recientemente en la lista de correo de Info-LabVIEW cómo usaron LabVIEW para desarrollar y probar el control de circuito cerrado de las superficies de vuelo accionadas por motores eléctricos en el Boeing 787, y dio la impresión de que LabVIEW se usó ampliamente en el desarrollo del avión. ¡También se usa para control en tiempo real en el Gran Colisionador de Hadrones!

El lugar más activo actualmente para obtener más información y ayuda con LabVIEW, además del propio sitio y foros de National Instruments, parece ser LAVA .

Hay una gran cosa que encontré negativo al usar LabVIEW para mis aplicaciones: Organizar la complejidad del diseño. Como un physisist, considero que Labview es ideal para la creación de prototipos, el control de instrumentos y el análisis matemático. No hay un idioma en el cual obtenga un resultado más rápido y mejor que en LabVIEW. Utilicé LabView desde 1997. Desde 2005 cambié por completo al .NET framework, ya que es más fácil de diseñar y mantener.

En LabVIEW se debe dibujar una estructura simple ''si'' y usa mucho espacio en su diseño gráfico. Descubrí que muchas de nuestras aplicaciones comerciales eran difíciles de mantener. Cuanto más compleja se hacía la aplicación, más difícil era leerla.

Ahora uso laugurios de texto y soy mucho mejor en mantener todo. Si comparas C ++ con LabVIEW usaría LabVIEW, pero comparado con C # no gana

Descargo de responsabilidad: No he sido testigo de LabVIEW, pero he usado algunos otros lenguajes gráficos, incluyendo WebMethods Flow y Modeller, lenguajes de simulación dinámica en la universidad y, er, MIT''s Scratch :).

Mi experiencia es que los lenguajes gráficos pueden hacer un buen trabajo en la parte de "fontanería" de la programación, pero los que he usado activamente obstaculizan la algorítmica. Si sus algoritmos son muy simples, eso podría estar bien.

Por otro lado, tampoco creo que C ++ sea excelente para su situación. Pasará más tiempo rastreando problemas de administración de memoria y punteros que con un trabajo útil.

Si tu robot se puede controlar usando un lenguaje de scripting (Python, Ruby, Perl, lo que sea), entonces creo que sería una opción mucho mejor.

Luego hay opciones híbridas:

Si no hay una opción de scripting para su robot, y usted tiene un geek de C ++ en su equipo, entonces considere tener esos enlaces de escritura geek para asignar su biblioteca de C ++ a un lenguaje de scripting. Esto permitiría a las personas con otras especialidades programar el robot más fácilmente. Las fijaciones serían un buen regalo para la comunidad.

Si LabVIEW lo permite, use su lenguaje gráfico para unir los módulos escritos en un lenguaje textual.

La otra fortaleza de LabVIEW (además de las bibliotecas) es la concurrencia . Es un lenguaje de flujo de datos , lo que significa que el tiempo de ejecución puede manejar la concurrencia por usted. Entonces, si está haciendo algo altamente concurrente y no quiere tener que hacer la sincronización tradicional, LabVIEW puede ayudarlo allí.

El futuro no pertenece a los lenguajes gráficos tal como están en la actualidad. Pertenece a quien pueda encontrar una representación de flujo de datos (u otro tipo de programación compatible con la simultaneidad) que sea tan sencillo como lo es el enfoque gráfico, pero también es analizable por las herramientas del programador.

LabVIEW le permite comenzar rápidamente, y (como otros ya lo han dicho) tiene una enorme biblioteca de código para hacer varias cosas relacionadas con la prueba, la medición y el control.

Sin embargo, la mayor caída de LabVIEW es que pierdes todas las herramientas que los programadores escriben por sí mismos.

Tu código está almacenado como VIs. Estos son archivos binarios opacos. Esto significa que tu código realmente no es tuyo, es LabVIEW. No puede escribir su propio analizador, no puede escribir un generador de código, no puede hacer cambios automáticos a través de macros o scripts.

Esto apesta cuando tienes una aplicación 5000 VI que necesita algún ajuste menor aplicado universalmente. Su única opción es ir a través de cada VI de forma manual, y que Dios te ayude si pierdes un cambio en un VI en algún rincón.

Y sí, dado que es binario, no se puede hacer diff / merge / patch como se puede con los lenguajes textuales. De hecho, esto hace que trabajar con más de una versión del código sea una horrible pesadilla de mantenibilidad.

Por supuesto, use LabVIEW si está haciendo algo simple, o necesita hacer un prototipo, o no planea mantener su código.

Si desea realizar una programación real y sostenible, use un lenguaje de texto. Puede ser más lento para comenzar, pero a la larga será más rápido.

(Ah, y si necesita bibliotecas DAQ, NI también tiene versiones C ++ y .Net).

Como siempre, depende.

Estoy usando LabVIEW desde hace 20 años y realicé trabajos bastante grandes, desde un simple DAQ hasta una visualización muy compleja, desde controles de dispositivos hasta secuenciadores de prueba. Si no fuera lo suficientemente bueno, seguramente habría cambiado. Dicho esto, comencé a codificar Fortran con tarjetas perforadas y usé una gran cantidad de lenguajes de programación en ''máquinas'' de 8 bits, comenzando con las basadas en Z80. Los idiomas van desde Assembler a BASIC, desde Turbo-Pascal a C.

LabVIEW fue una mejora importante debido a sus extensas bibliotecas para adquisición y análisis de datos. Uno tiene, sin embargo, para aprender un paradigma diferente. Y definitivamente necesitas un trackball ;-))

No hago nada acerca de LabView (o mucho sobre C / C ++), pero ...

¿Crees que los lenguajes gráficos como LabVEIW son el futuro de la programación?

No...

¿Es más fácil aprender un lenguaje gráfico que un lenguaje textual? Creo que deberían ser igualmente difíciles de aprender.

Más fácil de aprender? No, pero son más fáciles de explicar y entender.

Para explicar un lenguaje de programación, debes explicar qué es una variable (lo que es sorprendentemente difícil). Esto no es un problema con las herramientas de codificación de flujo / nodal, como la interfaz de programación LEGO Mindstroms o Quartz Composer.

Por ejemplo, en este es un programa LEGO Mindstroms bastante complicado : es muy fácil entender lo que está pasando ... pero ¿y si quieres que el robot ejecute el bloque INCREASEJITTER 5 veces, luego conduzca hacia delante durante 10 segundos y luego intente INCREASEJITTER loop nuevamente? Las cosas empiezan a desordenarse muy rápido ...

Quartz Composer es un gran ejemplo de esto, y por qué no creo que los lenguajes gráficos sean "el futuro".

Hace que sea muy fácil hacer cosas geniales (efectos de partículas 3D, con una cámara controlada por el brillo promedio de los píxeles de una cámara web) ... pero es increíblemente difícil hacer cosas fáciles, como iterar sobre los elementos de un archivo XML, o almacenar ese valor de píxel promedio en un archivo.

Al ver que estamos parcialmente arraigados en ayudar a las personas a aprender, ¿cuánto debemos confiar en los módulos preescritos, y cuánto debemos tratar de escribir por nuestra cuenta? ("Los buenos programadores escriben buen código, los grandes programadores copian código excelente". Pero, ¿no vale la pena ser un buen programador, primero?)

Para el aprendizaje, es mucho más fácil explicar y comprender un lenguaje gráfico.

Dicho esto, recomendaría un lenguaje de lenguaje basado en texto especializado como una progresión. Por ejemplo, para gráficos algo como Processing o NodeBox . Son lenguajes "normales" (Processing es Java, NodeBox es Python) con frameworks muy especializados, fáciles de usar (pero absurdamente poderosos) integrados en ellos.

Es importante destacar que son lenguajes muy interactivos, no tiene que escribir cientos de líneas solo para obtener un círculo en la pantalla. Simplemente escriba oval(100, 200, 10, 10) y presione el botón de ejecución, ¡y aparecerá! Esto también los hace muy fáciles de demostrar y explicar.

Más relacionado con la robótica, incluso algo como LOGO sería una buena introducción: escribes "ADELANTE 1" y la tortuga conduce una caja hacia adelante. Escribe "IZQUIERDA 90" y gira 90 grados ... Esto se relaciona con la realidad de manera muy simple. Puede visualizar lo que hará cada instrucción, luego pruébelo y confirme que realmente funciona de esa manera.

Muéstrales brillosas, buscarán las cosas útiles que aprenderían de C en el camino, si están interesadas o progresan al punto en que necesitan un lenguaje "real", tendrán todo ese conocimiento, en lugar de toparse con el error de sintaxis y compilar una pared de ladrillos.

Mi queja contra Labview (y Matlab en este aspecto) es que si usted planea en incrustar el código en que no sea nada x86 (y LabVIEW cuenta con herramientas para poner VIs de LabVIEW en ARM), entonces usted tendrá que tirar lo más caballos de fuerza en el problema como pueda porque es ineficiente.

LabVIEW es una gran herramienta de creación de prototipos: un montón de bibliotecas, fácil de hilvanar bloques, tal vez un poco difícil de hacer algoritmos avanzados, pero es probable que haya un bloque de lo que quiere hacer. Usted puede conseguir la funcionalidad hecho rápidamente. Pero si cree que puede tomar VI y que sólo hay que poner en un dispositivo que estás equivocado. Por ejemplo, si haces un bloque sumador en LabVIEW tiene dos entradas y una salida. ¿Cuál es el uso de la memoria para eso? Tres variables por valor de los datos? ¿Dos?En C o C ++ ya sabes, ya sea porque se puede escribir z=x+yo x+=yy usted sabe exactamente lo que su código está haciendo y lo que la situación es la memoria. El uso de memoria puede pico rápidamente, especialmente porque (como otros han señalado) Labview es altamente paralelo. Así que esté preparado para lanzar más memoria RAM de lo que pensaba en el problema. Y más potencia de procesamiento.

En resumen, LabVIEW es ideal para la creación rápida de prototipos, pero se pierde demasiado control en otras situaciones. Si se trabaja con grandes cantidades de datos o la capacidad de memoria / procesamiento limitada a continuación, utilizar un lenguaje de programación basado en texto para que pueda controlar lo que pasa.

Mi primera publicación aquí :) sea amable ...

Vengo de un fondo incrustado en la industria automotriz y ahora estoy en la industria de la defensa. Puedo decir por experiencia que C / C ++ y LabVIEW son bestias realmente diferentes con diferentes propósitos en mente. C / C ++ siempre se usó para el trabajo integrado en microcontroladores porque era compacto y los compiladores / herramientas eran fáciles de obtener. Por otro lado, LabVIEW se utilizó para conducir el sistema de prueba (junto con el banco de pruebas como secuenciador). La mayoría de los equipos de prueba que utilizamos eran de NI, por lo que LabVIEW proporcionó un entorno donde teníamos las herramientas y los controladores necesarios para el trabajo, junto con el soporte que queríamos.

En términos de facilidad de aprendizaje, hay muchos recursos disponibles para C / C ++ y muchos sitios web que ofrecen consideraciones de diseño y algoritmos de ejemplo en prácticamente cualquier cosa que esté disponible libremente. Para LabVIEW, la comunidad de usuarios probablemente no sea tan diversa como C / C ++, y toma un poco más de esfuerzo inspeccionar y comparar código de ejemplo (tiene que tener la versión correcta de LabVIEW, etc.) ... Encontré LabVIEW bastante fácil de elegir aprende y aprende, pero hay algunas molestias que algunos han mencionado aquí que tienen que ver con el paralelismo y varias otras cosas que requieren un poco de experiencia antes de que te des cuenta de ellas.

Entonces la conclusión después de todo eso? Yo diría que AMBOS idiomas son valiosos para el aprendizaje porque realmente representan dos estilos diferentes de programación y sin duda vale la pena ser consciente y competente en ambos.

Antes de llegar, nuestro grupo (científicos de doctorado, con poca experiencia en programación) había estado intentando implementar una aplicación de LabVIEW de manera intermitente durante casi un año. El código era desordenado, demasiado complejo (front y back-end) y lo más importante, no funcionó. Soy un programador entusiasta pero nunca había usado LabVIEW. Con la ayuda de un gurú de LabVIEW que podría ayudar a traducir los paradigmas de programación textual que conozco a los conceptos de LabVIEW, fue posible codificar la aplicación en una semana. El punto aquí es que los conceptos básicos de codificación todavía tienen que ser aprendidos, el lenguaje, incluso uno como LabVIEW, es solo una forma diferente de expresarlos .

LabVIEW es ideal para usar para lo que fue diseñado originalmente. es decir, para tomar datos de las tarjetas DAQ y mostrarlas en la pantalla, quizás con algunas manipulaciones menores en el medio. Sin embargo, los algoritmos de programación no son más fáciles e incluso sugeriría que es más difícil. Por ejemplo, en la mayoría de los lenguajes de procedimiento, el orden de ejecución generalmente se sigue línea por línea, usando notación pseudo matemática (es decir, y = x*x + x + 1 ) mientras que LabVIEW implementaría esto usando una serie de VI que no necesariamente se derivan de cada otro (es decir, de izquierda a derecha) en el lienzo.

Además, la programación como carrera es más que conocer los tecnicismos de la codificación. Ser capaz de pedir ayuda de manera efectiva / buscar respuestas, escribir código legible y trabajar con código heredado son todas habilidades clave que son innegablemente más difíciles en un lenguaje gráfico como LabVIEW.

Creo que algunos aspectos de la programación gráfica pueden volverse habituales: el uso de sub-VI incorpora perfectamente el principio de la "caja negra" de la programación y también se usa en otras abstracciones de lenguaje como Yahoo Pipes y el Automator de Apple, y tal vez algún futuro gráfico el lenguaje revolucionará la forma en que programamos, pero LabVIEW no es un cambio de paradigma masivo en el diseño del lenguaje, todavía tenemos while, for, if control de flujo, encasillado, programación impulsada por eventos, incluso objetos. Si el futuro realmente se escribirá en LabVIEW, el programador de C ++ no tendrá muchos problemas para cruzar.

Como postcript diría que C / C ++ es más adecuado para la robótica ya que los estudiantes sin duda tendrán que lidiar con sistemas embebidos y FPGA en algún momento. El conocimiento de programación de bajo nivel (bits, registros, etc.) sería invaluable para este tipo de cosas.

@mendicant En realidad, LabVIEW se usa mucho en la industria, especialmente para sistemas de control. Es probable que la NASA lo use para sistemas satelitales a bordo, pero luego el desarrollo de software para sistemas espaciales es un juego de pelota completamente diferente ...