PoBot
Simulations Coupe 2006Cet article contiendra un historique des simulations.
Test 1
On commence avec le test du simulateur, qui a donné lieu à une implémentation de la machine à état et d’un premier déplacement "par la gauche".
Test 2
Un nouveau programme qui correspond à l’homologation : parcourir 2 positions fixes de balles (extérieur gauche) et aller au premier trou de notre couleur.
Il reste :
– à isoler le code "simulateur" du code "algorithmique" pour pouvoir utiliser plus ou moins le même code depuis le simu ou depuis la CNP
– à gérer des pentes d’accélération/décélération (en calculant la vitesse en fonction de la vitesse actuelle, de la vitesse max souhaitée et de la distance restante pour ce mouvement)
– à tester la place que ça prend sur une CNP, voire à utiliser des inline pour économiser le code
Vos commentaires
# Le 14 mars 2006 à 15:55, par Julien H.
En réponse à : Simulations Coupe 2006
pour l’instant le robot bute dans le totem.
je vais coder un timeout : je chronomètre chaque étape et je prend un autre chemin si j’ai dépassé mon chronomax.
comme il s’agit du premier déplacement, je le fais très "scripté", étape par étape,
mais ensuite, le code sera plus "réactif" et utilisera la caméra et les capteurs, donc prendra moins de place.
on continuera à utiliser l’odométrie pour calculer les directions et les déplacements à faire, sachant qu’on n’utilisera peut être plus de distance, mais des timeouts, des capteurs ou des limites.
# Le 27 mars 2006 à 12:57, par Julien H.
En réponse à : Simulations Coupe 2006
J’ai codé la seconde partie du déplacement "scripté" qui pourra servir à l’homologation : on attrape 2 balles blanches (on laisse de côté le totem) et on file au trou de notre couleur. Finalement c’est mieux à gauche qu’à droite car même si le trou est plus loin, ça laisse plus de temps pour s’aligner dessus (bon, c’est l’expérience sur terrain qui jugera bien sûr).
Répondre à ce message
# Le 21 mars 2006 à 10:32, par Eric P.
En réponse à : Simulations Coupe 2006
Non, un inline ne va pas te faire gagner de la place, au contraire, puisque tu vas développer le code à chaque endroit où il est appelé. Le seul cas de figure où tu gagnes de la place en "inlinant" est si le code de la fonction est plus court que le call assembleur pour l’appeler, et la transmission des paramètres et la récupération des résultats. Mais en général, comme on utilise le moins possible ce mécanisme de communication dans du code µC et qu’on travaille plutôt par variables globales (cf ce que nous a dit Gilles il y a quelques réunions), le gain va donc être quasi nul, voire négatif.
L’inline ne fait gagner qu’une seule chose à coup sûr : du temps d’exécution. En effet, il supprime l’overhead du call, du prologue et de l’épilogue.
2 conclusions donc :
– il faut contrôler cela sur le listing assembleur généré par le compilo avant de décider.
– il faut oublier les principes méthodologiques utilisés habituellement en développement sur machine "confortable" 🙂
# Le 21 mars 2006 à 13:22, par Julien H.
En réponse à : Simulations Coupe 2006
Tout à fait. On peut ainsi découper une fonction en plusieurs petites pour gagner en lisibilité sans perdre en temps d’exécution. Je corrigerai.
Répondre à ce message