Peut architectures ascendantes être programmées de manière efficace dans les paradigmes de haut vers le bas?

Question

Le architecture subsomption , proposée par Rodney Brooks en 1986, est un "bottom-up" approche, dans lequel les robots sont conçus en utilisant des modèles hiérarchiques simples. Ces modèles se fondent sur les modules et subsument inférieurs pour former un produit final. Par exemple, un robot peut être donné un module « trouver l'ouverture » qui est subsumé par un plus abstrait module « trouver porte », qui est ensuite englobé lui-même par un module « quitter le terrain de jeu ».

Maintenant, évidemment, dans une conception plus « orientée objet », on aurait pu commencer la conception avec la « sortie du module de terrain de jeu », mais pour l'amour de l'argumentation, supposons que certains des éléments les plus primitifs ( « fonctions « ) sera probablement se réutilisés dans d'autres concepts plus élevés.

Se rendant compte que la mise en œuvre de ce robot dans un langage procédural (ou un fonctionnel, d'ailleurs) pourrait être la plus simple, mais est contre-productif d'essayer de concevoir un robot basé sur une architecture subsomption dans un paradigme de programmation orienté objet? (Réalisant aussi qu'il est peut-être difficile de peser un paradigme de génie logiciel contre une robotique one) Pour obtenir une solution, est-il une certaine forme de « adaptateur » qui peut être mis en œuvre pour accroître l'efficacité de l'utilisation de ce qui peut être deux paradigmes contradictoires?

Answer 1

Je voudrais généraliser cela dans un scénario plus commun. Je crois que ce sens puisque les détails de l'architecture de subsomption sont peut-être pas un premier aspect de la question (et les mêmes problèmes se produisent dans des domaines non robotiques ainsi).

Dans le logiciel général archtitecture il y a une approche bidirectionnelle, ou une approche multi-paradigme, comme dans la question. La couche la plus inférieure d'un environnement d'exploitation est inférieure généralement écrit. bits de code très spécifiques sont écrits pilote éléments matériels très spécifiques sur le système. Ceux-ci sont ensuite combinés pour former des composants de niveau supérieur. Je pense que nous pourrions facilement décrire cela comme une approche subsomption si nous décrivons simplement notre robot comme le système lui-même, et les objectifs à des aspects spécifiques de contrôle de ce système. Bien que je ne suis pas sûr qu'il est improtant de le faire.

De la plupart des applications de haut en bas sont rédigés en langues de niveau supérieur, ou décrite en termes d'une machine abstraite. Ceci est assez éloigné de la plupart des bibliothèques de fond qui seront effectivement faire le travail.

À un certain moment ces deux couches doivent répondre - en fait, ils se rencontrent à de nombreux endroits dans divers scénarios. Ce où vous devez « adapter » les couches pour convenir à l'autre couche. Le terme « adaptateur » ici est correct à 100%. Il y a en effet un modèle de logiciel appelé « adaptateur » qui est utilisé à cet effet.

En plus d'adaptateurs spécifiques, nous pouvons effectivement considérer l'ensemble toolchain de toute programmation moderne. Le compilateur lui-même, ainsi que la chemise et une exécution VM, sont la principale interface entre les deux couches. Autrement dit, un langage de haut niveau est écrit dans un domaine, et le compilateur est ce qui lui permet de travailler dans les domaines de niveau inférieur.

Si vous êtes à la recherche spécifiquement pour effectivness paradigme, considèrent que les langages de haut niveau existent pour la programmation impérative (C ++), programmation fonctionnelle (Haskell), et la programmation déclarative (Prolog). Ces paradigmes tout en fin de compte travailler sur les mêmes bibliothèques de bas niveau sous-jacent.

La question est en robotique bien différente? Non, je ne crois pas. En effet, si les mêmes idées ont été formulées aujourd'hui, je ne pense pas qu'ils ont un terme spécifique robotique (architecture subsomption) car il n'y a pas de différence forte de l'architecture logicielle normale. Vous indiquez même dans votre dernier paragraphe à la fois un paradigme fonctionnel et impératif pour commander un robot. Je voudrais cependant utiliser une langue spécifique de domaine à utiliser -. Et encore, la grande variété de langages spécifiques de domaine est une autre preuve que plusieurs paradigmes peuvent être efficacement adaptés les uns aux autres