Robot Race aux Jeux de Sophia

L’épreuve de robotique virtuelle des Jeux de Sophia 2006 reposera sur Robot Race, le simulateur ludique développé cette année.

Plus d’infos sur RobotRace

Site officiel des Jeux de Sophia

ATTENTION, CHANGEMENT DE LIEU !!!!!!!

La finale sera finalement à l’ESSI suite à un problème de dernière minute dans la salle RV du CSTB.

Règlement

Il s’agit d’un concours de course de voitures virtuelles, basé sur le simulateur RobotRace, développé par PoBOT, le club de robotique de Sophia Antipolis. Robot Race permet de s’essayer au développement de contrôleurs de véhicules autonomes. Le simulateur peut être téléchargé gratuitement sur le site Web de PoBOT : http://www.pobot.org/-Robot-Race-.html

L’environnement disponible sur ce site permet d’organiser des courses de voitures, en mode pilotage manuel (touches du clavier ...) ou piloté par un programme (c’est bien évidemment ce deuxième mode qui nous intéresse ici). Le joueur doit donc fournir un code exécutable (le contrôleur), qui calcule l’accélération (pression sur le champignon), la direction (le volant) et le freinage (à doser finement si on veut gagner). Ce code reçoit en entrée les données suivantes :
– position du véhicule (X, Y, altitude)
– cap
– liste des n prochains points de passage ou waypoints (n est variable et permet de simuler la visibilité que le conducteur a sur la piste (on voit en effet rarement la totalité de la route sur 200 km !!)

Pratiquement, ce code est une DLL qui doit respecter une interface prédéfinie (fournie dans le package téléchargeable sur notre site, ainsi que des exemples), comportant plusieurs points d’entrée. Certains sont obligatoires, comme le calcul des consignes de pilotage, d’autres sont facultatifs comme le réglage de la répartition de freinage ou de motricité entre les 2 essieux.

Le but de l’épreuve est de faire un tour du parcours en un minimum de temps, en évidant au mieux les accidents (on simule de manière assez réaliste les dérapages, sorties de route, etc.). C’est donc un contre la montre.

Pré-requis

Pour participer à ce concours vous devez :
– avoir un accès Internet (mais si vous n’en avez pas, comment avez-vous fait pour lire ce texte ?)
– savoir programmer (sans blague ?)
– être en mesure de générer une DLL avec interface de type C. Ceci ne veut pas dire que cette DLL doit obligatoirement être développée en C : le contrôleur au clavier par exemple a été écrit en Delphi, de même que le simulateur lui-même.

Nous avons fait des essais avec les environnements de développement suivants :
– Delphi
– Visual Studio
– Borland C++
– gcc (Mingw)

Déroulement du concours

• Le concours se déroule en plusieurs phases :
  1. Inscription et téléchargement du simulateur
  2. Programmation du véhicule
  3. Tours de chauffe : chaque véhicule est testé, un classement provisoire avec les temps d’essai est publié
  4. Manche de qualification : permet d’établir l’ordre de départ lors de la finale
  5. Possibilité de mettre à jour son véhicule
  6. Course à l’ESSI sur la piste du simulateur
  7. Course à l’ESSI sur une nouvelle piste (inconnue à l’avance des participants, de manière à éviter les triches du genre "parcours pré-programmé" 😉)

• Le téléchargement du simulateur se fait directement à partir du site PoBOT : http://www.pobot.org/-Robot-Race-.html. On utilisera la dernière version (la plus récente) du simulateur publiée sur ce site au moment de la clôture des inscriptions.

• La performance d’un véhicule dans le simulateur sur votre poste est seulement un indicateur pour la performance du même véhicule sur la machine effectivement utilisée pour la course. (La performance absolue - temps en secondes - peut dépendre du matériel utilisé).

• Le véhicule (la DLL) doit être testé, puis envoyé à l’adresse robotsophia@free.fr.

• Le vainqueur est le participant qui réalise le meilleur temps le jour de la course finale sur la somme des deux courses dans la salle immersive. Les résultats des temps de chauffe ne sont pas utilisés pour déterminer le vainqueur. La manche de qualification permet de déterminer l’ordre de départ lors de la finale. Pour neutraliser une éventuelle dispersion des résultats (effet papillon), nous essaierons de faire exécuter plusieurs courses par le même véhicule, et d’en prendre la moyenne pour déterminer le temps retenu. Tout dépend du nombre de participants qui se présenteront.

• Des vidéos montrant les tours de chauffe de chaque véhicule et les manches de qualification seront publiées sur Internet.

Dates

La finale se déroulera à l’ESSI.

Les détails seront communiqués à tous les inscrits en fonction du nombre de participants et des contraintes d’organisation.

FAQ

• Sous quelle forme faut-il envoyer le véhicule ?

Une DLL contenant le contrôleur. Contactez-nous si vous n’avez jamais fait une DLL !

• Le téléchargement des vidéos est trop long. Comment faire ?

Les organisateurs ne sont pas des pros de la vidéo et du streaming, mais ouvert à tout suggestions et sponsoring... L’expérience nous a permis de réduire considérablement la taille d’une vidéo, mais on est ouvert à de nouvelles technologies (surtout gratuites).

• Est ce que le paramètre altitude sera pris en compte pour les jeux ??

On ne proposera pas de pistes « montagneuses » (genre montagne russe) dans cette première édition. Les altitudes des waypoints seront donc tous à peu près les mêmes - le paramètre n’est pas utile dans ce contexte.

• Est ce que la route a la même largeur partout est quelle est elle ( min/max) ??

Comme dans la vraie vie, la route a à peu près la même largeur partout et à peu près assez large pour que 2 véhicules puissent rouler côte à côte.
Environ 20 unités de distance.

• Est ce que les waypoint sont toujours sur la trajectoire optimale ?

Dans le modèle de terrain actuel, oui, mais s’il y a un circuit surprise, ce sera la surprise 🙂

• Quelle est l’angle de braquage maximum

1 (i.e. 100 %). Cf. les commentaires dans vehicle_controler.h :
float *steer_pct,// pointeur sur la variable de retour du braquage des roues directrices (en pourcentage de l’angle maxi, -1.0 <= steer_pct <= +1.0)
Cela correspond à un intervalle de braquage en degrés de [-40, +40].

• Quelle peut être l’intérêt de new_time ??

C’est le temps écoulé depuis le début de la course. Sa valeur n’est pas forcément utile. (Sinon, le programme peut décider d’abandonner passer un certain délais ... 😉 )

• Combien de fois l’API principale est appelé ? Toutes les secondes ?

Le plus rapidement possible selon la machine, de manière à ce que le pas de temps (le fameux delta_time qui a soulevé quelques questions) soit le plus petit possible. La raison est tout simplement d’éviter que le modèle physique ne se mette à diverger si l’intervalle est trop long. Pour être plus précis, le simulateur cycle en permanence sur la séquence "mise à jour du modèle", "rafraîchissement de l’affichage" et ce le plus vite que la machine lui permet.

Sur un P4 2.4 GHz, avec ATI Radeon 9600XT, c’est de l’ordre de 60 fois par seconde et plus. Tout dépend aussi de la carte graphique et de la taille à laquelle vous avez dimensionné la fenêtre (plus elle est grande et plus la fréquence de rafraîchissement va diminuer.

• A-t-on besoin d’un PC surpuissant ?

Non, PC recent avec une carte graphique pas trop poussiéreuse convient. Essayez simplement le simulateur avec le controleur par défaut sur le votre !

• Quand on modifie les paramètres du véhicule, couple, freinage,
  direction - est-ce que les paramètres sont pris en compte de suite par
  le simulateur ou seulement tous ensemble une fois l’API fini ??

Non : ce n’est pris en compte qu’au départ. Vous avez déjà essayé de régler vos freins en roulant ? Imaginez que cette fonction joue le même rôle que les mécanos au stand, avant le départ de l’épreuve.

Poser une question

N’hésitez pas à poser des questions ou à nous faire part de vos suggestions !

werner.keilholz@cstb.fr