La versión original de esta publicación de Benjie Holson se publicó en Substack aquí e incluye los cómics originales de Benjie como parte de su serie sobre robots y nuevas empresas. Trabajé en esta idea durante meses antes de decidir que era un error. La segunda vez que escuché a alguien mencionarlo pensé: “Eso es extraño, estos dos grupos tuvieron la misma idea. Tal vez debería decirles que no funcionó para nosotros”. La tercera y cuarta vez puse los ojos en blanco y lo ignoré. La quinta vez que escuché acerca de un grupo que luchaba con este error, decidí que valía la pena publicar una publicación en el blog por sí solo. A esta idea la llamo “El mítico no robotista”. El error La idea es más o menos así: programar robots es difícil. Y hay algunas personas con habilidades realmente misteriosas y doctorados que son realmente costosos y parecen necesarios por alguna razón. ¿No sería bueno si pudiéramos hacer robótica sin ellos? 1 ¿Y si todo el mundo pudiera hacer robótica? Eso sería genial, ¿verdad? Deberíamos crear un marco de software para que los no expertos en robótica puedan programar robots. Esta idea se acerca tanto a una idea correcta que es difícil saber por qué no funciona. A primera vista, no está mal: en igualdad de condiciones, sería bueno si la programación de robots fuera más accesible. El problema es que no tenemos una buena receta para fabricar robots que funcionen. Entonces no sabemos cómo hacer que esa receta sea más fácil de seguir. Para simplificar las cosas, la gente termina eliminando cosas que podrían necesitar, porque nadie sabe con certeza qué es absolutamente necesario. Es como decir que quieres inventar una capa de invisibilidad y poder fabricarla con materiales que puedas comprar en Home Depot. Claro, eso sería bueno, pero si inventaras una capa de invisibilidad que requiriera algo de mercurio y neodimio para su fabricación, ¿desecharias la receta? En robótica, este error se basa en una observación muy cierta y muy real: programar robots es muy difícil. Famosamente duro. Sería genial si programar robots fuera más fácil. El problema es el siguiente: la programación de robots tiene dos tipos diferentes de partes difíciles. Los robots son difíciles porque el mundo es complicado. Moor Studio/Getty Images El primer tipo de parte difícil es que los robots se enfrentan al mundo real, imperfectamente percibidos y imperfectamente accionados. El estado mutable global es un mal estilo de programación porque es muy difícil de manejar, pero para el software de robot, todo el mundo físico es un estado mutable global, y solo puedes observarlo de manera poco confiable y esperar que tus acciones se acerquen a lo que querías lograr. Conseguir que la robótica funcione está a menudo en el límite de lo que una persona puede razonar y requiere flexibilidad para emplear cualquier heurística que pueda funcionar para su problema especial. Ésta es la complejidad intrínseca del problema: los robots viven en mundos complejos, y por cada solución que funciona hay millones de soluciones que no funcionan, y encontrar la correcta es difícil y, a menudo, depende mucho de la tarea, el robot y los sensores. y medio ambiente. La gente mira ese desafío, ve que es muy difícil y decide que, claro, tal vez algún experto en robótica podría resolverlo en un escenario particular, pero ¿qué pasa con la gente “normal”? «Deberíamos hacer esto posible para los no expertos en robótica», dicen. Llamo a estos usuarios “no robóticos míticos” porque una vez que programan un robot, siento que se convierten en robóticos. ¿Alguien que programa un robot para un propósito no es un roboticista? Dejen de vigilar, gente. No diseñes para grupos amorfos. También los llamo «míticos» porque normalmente el «no robótico» implicado es un grupo vago y amorfo. No diseñes para grupos amorfos. Si no puede nombrar a tres personas reales (con las que ha hablado) para las que es su API, entonces está diseñando para un grupo amorfo y solo a las personas amorfas les gustará su API. Y con este confuso grupo de usuarios en mente (y viendo lo difícil que es todo), la gente piensa: «¿Seguramente podríamos hacer esto más fácil para todos los demás ocultando estas cosas con API simples?» No, no, no puedes. Para. No se puede ocultar la complejidad intrínseca con API simples porque si sus API son simples no pueden cubrir la complejidad del problema. Inevitablemente terminarás con una API de apariencia hermosa, con llamadas como “grasp_object” y “approach_person” que se muestran muy bien en el inicio de un hackathon pero que duran unos 15 minutos cuando alguien realmente intenta hacer un trabajo. Resultará que, para su aplicación particular, “grasp_object()” hace 3 o 4 suposiciones erróneas sobre “captura” y “objeto” y no funciona en absoluto. Tus usuarios son tan inteligentes como tú. Esto se ve agravado por la suposición generalizada de que estas personas son menos inteligentes (léase: menos inteligentes) que los creadores de este marco mágico. 2 Ese sentimiento de superioridad hará que los diseñadores se aferren desesperadamente a sus hermosos y simples “grasp_object()” y se resistan a agregar las perillas y argumentos necesarios para cubrir más casos de uso y permitir a los usuarios personalizar lo que obtienen. Irónicamente, esto impone mucha complejidad a los usuarios pobres de la API, quienes tienen que idear soluciones inteligentes para que funcione. Moor Studio/Getty Images La guinda triste, salada y amarga de este pastel de frustración es que, incluso si se hiciera realmente bien, el objetivo de este tipo de marco sería ampliar el grupo de personas que pueden hacer el trabajo. Y para lograrlo, sacrificaría algo de rendimiento que sólo puede obtener superespecializando su solución a su problema. Si viviéramos en un mundo donde los expertos en robótica pudieran programar robots que funcionaran muy bien, pero hubiera tanta demanda de robots que simplemente no hubiera suficiente tiempo para que esas personas hicieran toda la programación, esta sería una gran solución. 3 La verdad obvia es que (fuera de entornos realmente restringidos como las células de fabricación) incluso el mejor grupo de robóticos auténticos y portadores de tarjetas que trabajan lo mejor que pueden luchan por acercarse a un nivel de rendimiento que haga que el robots comercialmente viables, incluso con plazos prolongados y montañas de financiación. 4 No tenemos margen para sacrificar potencia y eficacia en aras de la facilidad. ¿Qué problema estamos resolviendo? Entonces, ¿deberíamos dejar de hacerlo más fácil? ¿El desarrollo robótico está disponible sólo para un pequeño grupo de élites con doctorados sofisticados? 5 ¡No a ambos! He trabajado con toneladas de pasantes universitarios que han sido completamente capaces de hacer robótica.6 Yo mismo soy en su mayor parte autodidacta en programación de robots.7 Si bien hay mucha complejidad intrínseca en hacer que los robots funcionen, no creo que haya más que, digamos, el desarrollo de videojuegos. En robótica, como en todo, la experiencia ayuda, algunas cosas se pueden enseñar y, a medida que dominas muchas áreas, puedes ver que las cosas comienzan a conectarse entre sí. Estas habilidades no son mágicas ni exclusivas de la robótica. No somos tan especiales como nos gusta pensar. Pero ¿qué pasa con facilitar la programación de robots? ¿Recuerdas al principio de la publicación cuando dije que había dos tipos diferentes de partes difíciles? Uno es la complejidad intrínseca del problema, y ese será difícil pase lo que pase. 8 Pero la segunda es la complejidad incidental, o como me gusta llamarla, la estúpida complejidad de tonterías. Los Stupid BS Complexity Robots son sistemas asincrónicos, distribuidos y en tiempo real con hardware extraño. Todo eso será difícil de configurar por estúpidas razones. Esos controladores deben funcionar en el extraño sabor de Linux que desea en tiempo real para sus controles y configurarlo todo será difícil por estúpidas razones. Estás abusando del Wi-Fi para poder desplazarte sin problemas y sin interrupciones, pero el Wi-Fi de Linux no querrá hacer eso. Tus archivos de registro son enormes y tienes que subirlos a algún lugar para que no llenen tu robot. Necesitará integrarse con alguna nube u otra y lidiar con su estúpida tontería. 9Moor Studio/Getty Images Hay un montón de basura con la que lidiar incluso antes de llegar a la complejidad de lidiar con la rotación 3D, los marcos de referencia en movimiento, la sincronización del tiempo y los protocolos de mensajería. Esas cosas tienen complejidad intrínseca (tienes que pensar en cuándo se observó algo y cómo razonar sobre ello cuando otras cosas se han movido) y una estúpida complejidad de tontería (hay un error extraño porque alguien multiplicó dos matrices de transformación en el orden incorrecto y ahora Recibes un mensaje de error que indica que en algún protocolo un cuaternión no está normalizado (¿qué significa eso?) 10 Uno de los mayores desafíos de la programación de robots es atravesar el mar de tonterías estúpidas que necesitas discutir para comenzar a trabajar en tu. Interesante y desafiante problema de robótica. Entonces, una heurística simple para crear buenas API es: Diseñe sus API para alguien tan inteligente como usted, pero menos tolerante con las estúpidas tonterías. Esto parece lo suficientemente universal como para estar tentado a llamarlo Ley de Holson del diseño de API tolerable. Cuando utiliza herramientas que ha fabricado, las conoce lo suficientemente bien como para conocer las asperezas y cómo evitarlas. Pero las asperezas son cosas que deben mantenerse en la memoria de un programador mientras usa su sistema. Si insistes en crear un marco robótico 11, debes esforzarte por hacerlo lo más poderoso posible con la menor cantidad de tonterías estúpidas. Erradica la complejidad incidental dondequiera que puedas. Quiere crear API que tengan la máxima flexibilidad pero buenos valores predeterminados. Me gusta la sintaxis de argumentos predeterminados de Python para esto porque significa que puedes escribir API que se pueden usar como: Es posible que las cosas fáciles sean simples y permitan cosas complejas. Y por favor, por favor, no hagas API condescendientes. ¡Gracias! 1. Irónicamente, muy a menudo son los costosos doctores con conocimientos arcanos quienes proponen esto. 2. ¿Por qué es siempre un marco? 3. La excepción que podría confirmar la regla son cosas como la automatización tradicional de las células de fabricación. Ése es un lugar donde existen soluciones, pero el límite para la expansión es el costo establecido. No soy un experto en este campo, pero me preocuparía que la instalación física y el cumplimiento de la seguridad aún eclipsaran el costo de programación del software. 4. Como bien sé por experiencia personal. 5. ¿O doctorados no sofisticados? 6. Sospecho que muchos estudiantes de secundaria brillantes también podrían hacer el trabajo. Sin embargo, como Google tiende a no contratarlos, no tengo buenos ejemplos. 7. Mis estudios fueron en Ingeniería Mecánica y nunca obtuve un doctorado, aunque mi trabajo de clase de ME incluyó algunos fundamentos de programación. 8. A menos que creemos una IA eficaz de propósito general. Se siente extraño tener que agregar esa advertencia, pero la posibilidad de que realmente llegue a la robótica en mi vida parece mucho más posible que hace dos años. 9. Y si no tiene suerte, su API fue diseñada por alguien que pensaba que era más inteligente que sus clientes. 10. Este tipo particular de complejidad de BS es la razón por la que escribí posetree.py. Si te dedicas a la robótica, deberías comprobarlo. 11. Lo cual, a juzgar por el rastro de empresas de estructuras de robots muertas, es algo complicado. Artículos de su sitioArtículos relacionados en la Web
Etiqueta: software para robots
![Programación de robots: deje de diseñar software para no robóticos Programación de robots: deje de diseñar software para no robóticos](https://i0.wp.com/spectrum.ieee.org/media-library/illustration-of-three-people-with-unicorn-heads-working-on-a-giant-robot.jpg?id=52208531&width=1200&height=600&coordinates=0,125,0,125&w=900&resize=900&ssl=1)