Choix de l'implémentation d'un itérateur

Bonjour,

Je suis en train de réaliser un petit hexapod, qui sera piloté en python (via une carte micropython, à priori, si la puissance de calcul suffit).

Le projet avance bien, et je suis en train de me pencher sur la partie déplacement. En gros, il faut calculer une liste de positions des pattes pour générer la démarche choisie. L'idée est de pouvoir générer une position donnée en fonction du pas dans le cycle de marche.

Par exemple, pour la démarche 'tripod', on déplace 3 pattes à la fois : 1 d'un côté, 2 de l'autre. Il y a 2 pas (step). Lors du premier pas, on déplace un groupe, lors du second pas, on déplace le second groupe. Chaque pas est également décomposé en plusieurs temps, pour générer la trajectoire des pattes (montée/avance/descente).

Lors du pilotage, ce serait bien de pouvoir avancer pas à pas dans la séquence de marche. Du coup, les itérateurs me semblent intéressants.

La commande se fera via un gamepad : dans le mode déplacement, la position du joystick analogique donnera à la fois la direction de déplacement et la vitesse.

À haut niveau, je vais donc avoir une boucle qui va interroger cette commande. Tant qu'on voit une valeur non nulle, on va aller interroger l'itérateur qui génère la position des pattes, et on les déplace (je passe sous silence la syncrho des servos et les timings).

Ma question est : quelle solution adopter pour cet itérateur ? Est-ce pertinent d'en implémenter un vrai en python (et si oui, de quelle façon : __iter__/next(), yield, autre) ? Ou est-ce que finalement, un object avec une méthode getNextStep() suffit ?

J'avoue ne pas avoir les idées bien claire sur le sujet. Je précise que le but est autant la finalité du projet que la façon d'y arriver : l'architecture logicielle m'interesse tout autant (sinon plus !) que le déplacement du robot ;)

Merci d'avance pour vos lumières.

Salut,

Avant de coder, il faut définir le (ou les) automate(s) à état fini qui contrôlent les déplacements.
Après il faudra coder/tester... et utiliser un générateur (ou pas) sera un détail d'implémentation.

__iter__, __next__ ont une "class" comme contexte: des variables d'instances pour gérer un état peut être sympa.
Avec yield, on est plutôt dans le contexte d'une fonction: l'état sera géré par des variables "locales" et donc moins facile d'accès.

De toutes façons n'importe quel bidule aura une hiérarchie d'automates et la réalisation de chacun d'entre eux devra être "pragmatique".

- W

Merci pour ce retour.

Je cherche surtout une façon qui ne me bride pas (trop) dans l'utilisation postérieure : j'aimerais pouvoir utiliser tout ça avec des ganularités variées.

Un peu ça comme dans un débugger : on peut faire exécuter tout d'un coup et ne s'arrêter qu'à la fin, ou bien fonction par fonction, ou encore descendre dans les appels de fonctions...

Citation:

---

Envoyé par fma38

Je cherche surtout une façon qui ne me bride pas (trop) dans l'utilisation postérieure : j'aimerais pouvoir utiliser tout ça avec des ganularités variées.

---

Certes mais c'est une question de design et non de codage...
La réponse ne dépend pas du langage.
C'est une discussion qui a plutôt sa place dans le forum architecture de la rubrique ALM.
note: c'est la bas que traînent les "architectes" qui se prenne le chou à organiser le code pour que...

- W

Disons que je veux quand même rester proche du python dans mes reflexions. Ce langage a des atouts que d'autres n'ont pas, et influence un peu sur la façon de faire. Le niveau d'abstraction d'un forum dédié à l'architecture logicielle va passer trop haut au dessus de ma petite tête ;)