La version originale de cet article de Benjie Holson a été publiée sur Substack ici et comprend Les bandes dessinées originales de Benjie dans le cadre de sa série sur les robots et les startups.
J’ai travaillé sur cette idée pendant des mois avant de décider que c’était une erreur. La deuxième fois que j’ai entendu quelqu’un en parler, j’ai pensé : « C’est étrange, ces deux groupes avaient la même idée. Peut-être que je devrais leur dire que ça n’a pas fonctionné pour nous. La troisième et la quatrième fois, j’ai roulé des yeux et je l’ai ignoré. La cinquième fois que j’ai entendu parler d’un groupe aux prises avec cette erreur, j’ai décidé que cela valait à lui seul un article de blog. J’appelle cette idée « le non-robotique mythique ».
L’erreur
L’idée ressemble à ceci : programmer des robots est difficile. Et il y a des personnes avec des compétences vraiment obscures et des doctorats qui coûtent très cher et semblent nécessaires pour une raison quelconque. Ne serait-il pas bien si nous pouvions faire de la robotique sans eux ?
1 Et si tout le monde pouvait faire de la robotique ? Ce serait génial, non ? Nous devrions créer un cadre logiciel permettant aux non-roboticiens de programmer des robots.
Cette idée est si proche d’une idée correcte qu’il est difficile de dire pourquoi elle ne fonctionne pas. En surface, ce n’est pas le cas
faux: Toutes choses étant égales par ailleurs, ce serait bien si la programmation des robots était plus accessible. Le problème est que nous n’avons pas de bonne recette pour fabriquer des robots fonctionnels. Nous ne savons donc pas comment rendre cette recette plus facile à suivre. Afin de simplifier les choses, les gens finissent par supprimer les éléments dont ils pourraient avoir besoin, car personne ne sait avec certitude ce qui est absolument nécessaire. C’est comme dire que vous voulez inventer une cape d’invisibilité et que vous voulez pouvoir la fabriquer à partir de matériaux que vous pouvez acheter chez Home Depot. Bien sûr, ce serait bien, mais si vous inventiez une cape d’invisibilité dont la fabrication nécessitait du mercure et du néodyme, jetteriez-vous la recette ?
En robotique, cette erreur repose sur un constat bien vrai et bien réel : Programmer des robots
est super difficile. Célèbrement dur. Ce serait super génial si la programmation des robots était plus facile. Le problème est le suivant : la programmation des robots comporte deux types différents de pièces dures.
Les robots sont difficiles parce que le monde est compliqué
Moor Studio/Getty Images
Le premier type de difficulté réside dans le fait que les robots gèrent le monde réel, imparfaitement détecté et imparfaitement actionné. L’état mutable global est un mauvais style de programmation car il est vraiment difficile à gérer, mais pour les logiciels robotisés, le monde physique tout entier est un état mutable global, et vous ne pouvez l’observer que de manière peu fiable et espérer que vos actions se rapprochent de ce que vous vouliez réaliser. Faire fonctionner la robotique est souvent à la limite de ce sur quoi une personne peut raisonner et nécessite la flexibilité nécessaire pour employer n’importe quelle heuristique qui pourrait fonctionner pour votre problème particulier. C’est le
intrinsèque complexité du problème : les robots vivent dans des mondes complexes, et pour chaque solution efficace, il existe des millions de solutions qui ne fonctionnent pas, et trouver la bonne est difficile et souvent très dépendant de la tâche, du robot, des capteurs et de l’environnement.
Les gens examinent ce défi, voient qu’il est extrêmement difficile et décident que, bien sûr, un roboticien sophistiqué pourrait peut-être le résoudre dans un scénario particulier, mais qu’en est-il des personnes « normales » ? « Nous devrions rendre cela possible aux non-roboticiens », disent-ils. J’appelle ces utilisateurs des « non-roboticiens mythiques » car une fois qu’ils programment un robot, j’ai l’impression qu’ils
devenir roboticiens. Quiconque programme un robot dans un but précis n’est-il pas un roboticien ? Arrêtez le contrôle, les gens.
Ne concevez pas pour des groupes amorphes
Je les qualifie également de « mythiques » parce que généralement le « non-roboticien » impliqué est un groupe vague et amorphe. Ne concevez pas pour des groupes amorphes. Si vous ne pouvez pas nommer trois personnes réelles (à qui vous avez parlé) auxquelles votre API est destinée, alors vous concevez pour un groupe amorphe et seules les personnes amorphes aimeront votre API.
Et en pensant à ce groupe flou d’utilisateurs (et en voyant à quel point tout est difficile), les gens pensent : « Nous pourrions sûrement rendre cela plus facile pour tout le monde en dissimulant ces choses avec de simples API ?
Non, non, vous ne pouvez pas. Arrête ça.
Vous ne pouvez pas masquer la complexité intrinsèque avec de simples API, car
si vos API sont simples, elles ne peuvent pas couvrir la complexité du problème. Vous vous retrouverez inévitablement avec une belle API, avec des appels comme « grasp_object » et « approach_person » qui font une belle démonstration lors du lancement d’un hackathon mais durent environ 15 minutes pendant que quelqu’un essaie réellement de faire du travail. Il s’avérera que, pour leur application particulière, « grasp_object() » fait 3 ou 4 hypothèses erronées sur « saisir » et “objet” et ne fonctionne pas du tout pour eux.
Vos utilisateurs sont aussi intelligents que vous
Cette situation est aggravée par l’hypothèse omniprésente selon laquelle ces personnes sont moins avisées (lire : moins intelligentes) que les créateurs de ce cadre magique.
2 Ce sentiment de supériorité amènera les concepteurs à s’accrocher désespérément à leurs beaux et simples « grasp_object() » et à résister à l’ajout des boutons et des arguments nécessaires pour couvrir davantage de cas d’utilisation et permettre aux utilisateurs de personnaliser ce qu’ils obtiennent.
Ironiquement, cela impose une grande complexité aux utilisateurs pauvres de l’API, qui doivent trouver des solutions de contournement intelligentes pour la faire fonctionner.
Moor Studio/Getty Images
La cerise triste, salée et amère sur ce gâteau de frustration est que, même s’il était vraiment bien fait, l’objectif de ce type de cadre serait d’élargir le groupe de personnes capables de faire le travail. Et pour y parvenir, cela sacrifierait certaines performances que vous ne pouvez obtenir qu’en super-spécialisant votre solution à votre problème. Si nous vivions dans un monde où des roboticiens experts pouvaient programmer des robots qui fonctionnaient très bien, mais où la demande de robots était telle qu’ils n’avaient tout simplement pas assez de temps pour faire toute la programmation, ce serait une excellente solution.
3
La vérité évidente est que (en dehors d’environnements vraiment contraints comme les cellules de fabrication), même le meilleur groupe de véritables roboticiens détenteurs de cartes et travaillant au mieux de leurs capacités a du mal à se rapprocher d’un niveau de performance qui rend les robots plus performants. commercialement viable, même avec de longs délais et des montagnes de financement.
4 Nous n’avons pas n’importe lequel marge pour sacrifier la puissance et l’efficacité au profit de la facilité.
Quel problème résolvons-nous ?
Alors faut-il renoncer à rendre les choses plus faciles ? Le développement robotique est-il accessible uniquement à un petit groupe d’élites titulaires de doctorats sophistiqués ?
5 Non aux deux ! J’ai travaillé avec des tonnes de stagiaires de premier cycle qui étaient parfaitement capables de faire de la robotique.6 Je suis moi-même majoritairement autodidacte en programmation robotique.7 Bien qu’il existe une grande complexité intrinsèque dans le fonctionnement des robots, je ne pense pas qu’il y en ait plus que, par exemple, le développement de jeux vidéo.
En robotique, comme dans toutes choses, l’expérience aide, certaines choses peuvent être enseignées et, à mesure que vous maîtrisez de nombreux domaines, vous pouvez voir que les choses commencent à se connecter. Ces compétences ne sont pas magiques ou propres à la robotique. Nous ne sommes pas aussi spéciaux que nous aimons le penser.
Mais qu’en est-il de rendre la programmation des robots plus facile ? Vous vous souvenez au début de l’article quand j’ai dit qu’il y avait deux types différents de parties difficiles ? La première est la complexité intrinsèque du problème, et celle-ci sera difficile quoi qu’il arrive.
8 Mais la seconde est la complexité fortuite, ou comme j’aime l’appeler, la stupide complexité des BS.
Complexité stupide de BS
Les robots sont des systèmes asynchrones, distribués et en temps réel dotés d’un matériel étrange. Tout cela sera difficile à configurer pour des raisons stupides. Ces pilotes doivent fonctionner dans la saveur étrange de Linux que vous souhaitez en temps réel pour vos contrôles et il sera difficile de tout configurer pour des raisons stupides. Vous abusez du Wi-Fi pour pouvoir vous déplacer de manière transparente et sans interruption, mais le Wi-Fi de Linux ne voudra pas le faire. Vos fichiers journaux sont énormes et vous devez les télécharger quelque part pour qu’ils ne remplissent pas votre robot. Vous devrez intégrer quelque chose de cloud ou autre et gérer ses stupides BS.
9
Moor Studio/Getty Images
Il y a une tonne de conneries à gérer avant même d’arriver à la complexité de la gestion de la rotation 3D, du déplacement des cadres de référence, de la synchronisation temporelle, des protocoles de messagerie. Ces choses ont une complexité intrinsèque (vous devez penser au moment où quelque chose a été observé et comment raisonner à ce sujet alors que d’autres choses ont bougé) et une complexité stupide (il y a un bug étrange parce que quelqu’un a multiplié deux matrices de transformation dans le mauvais ordre et maintenant vous’ Vous recevez un message d’erreur indiquant qu’au fond d’un protocole, un quaternion n’est pas normalisé (WTF, cela signifie-t-il ?)
dix
L’un des plus grands défis de la programmation robotique est de patauger dans la mer de stupides bêtises que vous devez affronter pour pouvoir réussir.
commencer travailler sur votre problème de robotique intéressant et stimulant.
Une heuristique simple pour créer de bonnes API est donc :
Concevez vos API pour quelqu’un d’aussi intelligent que vous, mais moins tolérant aux stupides BS.
Cela semble suffisamment universel pour que je sois tenté de l’appeler
Loi de Holson sur la conception d’API tolérable.
Lorsque vous utilisez les outils que vous avez fabriqués, vous les connaissez suffisamment bien pour connaître les aspérités et savoir comment les éviter.
Mais les aspérités sont des choses qui doivent être conservées dans la mémoire d’un programmeur pendant qu’il utilise votre système. Si vous insistez pour créer un cadre robotique
11, vous devriez vous efforcer de le rendre aussi puissant que possible avec le moins de BS stupides. Éliminez la complexité fortuite partout où vous le pouvez. Vous souhaitez créer des API offrant une flexibilité maximale mais de bonnes valeurs par défaut. J’aime la syntaxe des arguments par défaut de Python pour cela, car cela signifie que vous pouvez écrire des API qui peuvent être utilisées comme :
Il est possible que les choses faciles soient simples
et permettre des choses complexes. Et s’il vous plaît, s’il vous plaît, ne créez pas d’API condescendantes. Merci!
1. Ironiquement, ce sont très souvent les coûteux docteurs possédant des connaissances obscures qui proposent cela.
2. Pourquoi est-ce toujours un cadre ?
3. L’exception qui pourrait confirmer la règle concerne des choses comme l’automatisation traditionnelle des cellules de fabrication. C’est un endroit où les solutions existent, mais la limite à l’expansion réside dans le coût d’installation. Je ne suis pas un expert dans ce domaine, mais je crains que l’installation physique et le respect des règles de sécurité n’éclipsent toujours pas le coût de programmation du logiciel.
4. Comme je le sais par expérience personnelle.
5. Ou des doctorats non spécialisés d’ailleurs ?
6. Je soupçonne que de nombreux lycéens brillants seraient également capables de faire ce travail. Cependant, comme Google a tendance à ne pas les embaucher, je n’ai pas de bons exemples.
7. Ma formation était en génie mécanique et je n’ai jamais obtenu de doctorat, même si mes cours de ME incluaient certains principes fondamentaux de programmation.
8. À moins que nous créions une IA à usage général efficace. Cela semble étrange de devoir ajouter cette mise en garde, mais la possibilité que cela arrive réellement pour la robotique de mon vivant semble beaucoup plus possible qu’il y a deux ans.
9. Et si vous n’avez pas de chance, son API a été conçue par quelqu’un qui pensait être plus intelligent que ses clients.
10. Cette saveur particulière de la complexité BS est la raison pour laquelle j’ai écrit posetree.py. Si vous faites de la robotique, vous devriez y jeter un œil.
11. Ce qui, à en juger par la liste des entreprises de robots-frameworks décédées, est une chose difficile à faire.
À partir des articles de votre site
Articles connexes sur le Web