Voici les specs établies en vue d’une utilisation dans le simulateur. On gardera le même principe dans le microcontrôleur.
Fonction obligatoire
void progress(
double deltaTime, // délai depuis l'appel précédent
double newTime, // instant courant
ContextPtr context, // passage des données de contexte
SetPointsPtr setpoints // retour des consignes
) ;
Définitions
typedef struct {
single x, // position X
single y, // position X
single heading // cap
} Context, *ContextPtr ;
Conventions
origine au centre du terrain
coordonnées exprimées en mm
nord en direction du camp adverse
axe des Y aligné sur le nord
cap exprimé en degrés, par rapport au Nord, orientés trigo
délais et temps exprimés en secondes
origine du temps absolu au moment du démarrage du contrôleur
typedef struct {
single motor_left, // consigne de vitesse moteur gauche
single motor_right // consigne de vitesse moteur droit
} SetPoints, *SetPointsPtr ;
Conventions
consignes exprimés en % de la vitesse maxi
vitesse maxi définie par configuration, ou bien retournée par
la fonction facultative getConfigParms
plage de variation : [-1.0, +1.0]
1 fonction facultative retournant des paramètres de config du robot
void getConfigParms(
ConfigParmsPtr parms // retour des paramètres de config
) ;
avec les définitions suivantes :
typedef struct {
single maxSpeed ; // vitesse maxi des moteur en deg/s
} ConfigParms, *ConfigParmsPtr ;
J’ai volontairement utilisé des structures pour les raisons suivantes :
plus grande efficacité de transmission et récupération de données (passage par pointeurs)
immunité aux évolutions d’interface : si on ajoute des champs dans les structures, les anciennes versions du code continuent à fonctionner puisqu’elles n’utilisent pas ces nouveaux champs. Seule contrainte : ne pas modifier les parties existantes d’une version sur l’autre.
Vos commentaires
# Le 20 février 2006 à 13:22, par Julien H.
En réponse à : Spécifications
pour l’instant, j’ai écrit du code "hors simulateur".
je vais faire une version qui utilise ces spécifications.
(mise à jour du contexte puis appel de la machine à état depuis le process)
par contre j’imagine que le contexte sera complété pour prendre en compte différents événements
(capteurs du simulateur, touches pour faire la jack)
l’un des intérêts du simulateur sera de "stresser" le robot pour faire apparaitre des événements "non réalistes" (ou plutôt non simulables) comme la détection d’une tache bleue là où il n’y en a pas, etc..
le plus simple serait d’assigner des touches clavier et envoyer la lettre de la touche au code du contrôleur (dans le context) qui se charge de l’interpréter (plus simple)
Répondre à ce message