Club robotique de Sophia-Antipolis

Accueil > L’association > En public > Les compétitions de robotique > Jeux de Sophia > JdS 2006 > Robot Race aux Jeux de Sophia

Robot Race aux Jeux de Sophia

règlement de l’épreuve robotique virtuelle en avant-première

mardi 4 avril 2006, par Julien H., Werner

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

Tours de chauffe Mercredi 7 Juin date limite envoi première version : Mardi 6 à minuit
Manche de qualification Vendredi 9 Juin date limite envoi mise à jour : Jeudi 8 à minuit
Finale Mardi 13 Juin date limite envoi version finale : Lundi à minuit.

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

Vos commentaires

  • Le 23 mai 2006 à 15:35, par ? En réponse à : Robot Race aux Jeux de Sophia

    Bonjour a tous les competiteurs.

    Le reglement actuelle prevoit de faire un moyenne sur trois runs du robot. J’ai propose de prendre plutot le meilleur temps pour eviter de mal noter un robot qui pourrait bien performer en regle general et se cracher de temps en temps a cause d’une dispersion des parametres.

    Toutefois, l’organisateur a besoin d’avoir l’avis de l’ensemble des participants sur l’eventuel modification de la regle.

    Pouvez vous repondre a ce message si vous pensez que le mieux est de prendre la moyenne ou le meilleur temps.

    • Le 7 juin 2006 à 11:47, par ? En réponse à : Robot Race aux Jeux de Sophia

       A l’épreuve JDS de Karting c’est le meilleur temps sur une dizaine de tour qui compte.
       Aux qualifications en F1 c’est le meilleur temps sur une dizaine de tour qui compte.
       Pour la Course elle même en F1, 24h du Mans, Nascar, Rally, etc, c’est toujours le temps total qui compte, et donc la moyenne au tour.

      Voilà pour mon grain de sel.

    • Le 7 juin 2006 à 14:41, par Julien En réponse à : Robot Race aux Jeux de Sophia

      déjà, 3 tours c’est pas assez. et prendre la moyenne, ce serait effectivement plus dans l’esprit "course automobile".

    • Le 7 juin 2006 à 15:17, par ? En réponse à : Robot Race aux Jeux de Sophia

      La limitation en nombre de tours était surtout introduit pour éviter que la finale se termine après minuit...
      Je veux bien faire plus de tours, mais alors avec présence obligatoire de tout le monde dans la salle jusqu’à la fin (disqualification dès qu’on sort 😉.

      J’ai d’ailleurs fini un troisième terrain pour le simulateur, on pourrait donc faire la moyenne entre les trois terrain*N (N restant à négocier).

      Werner
      PS : Attention, depuis le début des Jeux, le site de référence est celui des Jeux de Sophia, je ne mets pas à jour les deux !

    Répondre à ce message

  • Le 22 mai 2006 à 11:13, par ? En réponse à : Compilation DLL avec outils open source

    Suite aux efforts de notre infatigable programmeur du simulateur Robotrace, des instructions pour compiler la DLL du contrôleur avec des outils 100% gratuits est maintenant disponible : voir
    http://www.pobot.org/Utiliser-MinGW-pour-developper-la.html

    Répondre à ce message

  • Le 11 mai 2006 à 18:49, par Werner En réponse à : Microsoft Visual C workspace

    Un workspace pour fabriquer la DLL avec MVC 6.0 a été mise à disposition sur
    ftp://ftp.cstb.fr/pub/evl/robotik/robotrace/

    Il devrait fonctionner avec les versions plus récentes, y compris .NET.

    En cas de problèmes, n’hésitez pas à contacter werner@cstb.fr

    • Le 12 mai 2006 à 14:17, par ? En réponse à : Microsoft Visual C workspace

      Juste une petite note pour ceux qui travaillent avec VisualC++ : j’ai dû déplacer __EXPORT devant char* dans la déclaration de

      __EXPORT char* cdecl GetDescription(void) ;

      sans quoi la partie description ne fonctionnait pas. En revanche, aucun problème pour les autres méthodes de l’API.

      Au fait, tant qu’on y est, avec les options par défaut de VC++ j’obtiens une DLL de 250 kbytes, contrairement à l’exemple fourni qui en fait 5 fois moins. J’espère que cette année on ne sera pas limité dans la taille du code à donner. 😉

      Blaise

    • Le 20 mai 2006 à 01:50, par Eric P. En réponse à : Microsoft Visual C workspace

      Au fait, tant qu’on y est, avec les options par défaut de VC++ j’obtiens une DLL de 250 kbytes, contrairement à l’exemple fourni qui en fait 5 fois moins. J’espère que cette année on ne sera pas limité dans la taille du code à donner. 😉

      C’est probablement parce que l’exemple fourni a été compilé et linké de manière à utiliser les lib partagées sous forme de DLL externes, alors que les options par défaut doivent les linker en static dans le binaire généré.

      Eric

    Répondre à ce message

  • Le 11 mai 2006 à 21:08, par ? En réponse à : Robot Race aux Jeux de Sophia

    Bonjour,

    Je n’ai pas trouve de documentation. J’ai seulement trouve dans les exemples un .h avec les prototypes et quelques commentaires.

    Il manque cependant plusieurs explication :
    angle de braquage maximum
    qu’est ce que le parametre altitude, quel est la fourchette
    etc...
    J’imagine qu’il doit y avoir une spec precise de tous les parametres.

    Je n’ai pas compris egalement deux parametres de la fct principale
    le premier donne le temps en s depuis la derniere invocation
    le deuxieme, le temps ecoules.

    Je ne vois pas comment ces deux valeurs peuvent etre differentes.

    Merci.

    • Le 11 mai 2006 à 23:41, par Eric P. En réponse à : Robot Race aux Jeux de Sophia

      Bonjour,

      Il n’y a pas de doc séparée, car tout ceci est fait à titre bénévole et pris sur mon temps libre (et temps de sommeil), et les explications sont dans le fichier VehicleController.h, sous forme de commentaires. Au moins, on a plus de chance que la doc soit à jour avec les sources 😉

      Comme je suis sympa, je les reproduit ci-dessous, tels qu’ils figurent dans le source :

       delta_time : delta (temporel) entre cette invocation et la précédente (en secondes)
       new_time : temps écoulé (sous entendu depuis le début de la simulation, bien entendu)
       context : pointeur sur les informations de contexte (voir la définition de VEHICLE_CONTEXT pour les détails)
       torque_pct : pointeur sur la variable de retour du couple moteur (en pourcentage du couple maxi, -1.0 <= torque_pct <= +1.0)
       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)
       brakes : pointeur sur la variable de retour de l’utilisation des freins (0 <= brakes <= 1)

      Il semblerait que toutes vos questions aient leur réponse là-dedans 😉

      J’ai seulement trouve dans les exemples un .h avec les prototypes et quelques commentaires.

      Vous auriez dû lire ces quelques commentaires peut-être 😉

      Eric

    Répondre à ce message

  • Le 28 avril 2006 à 12:41, par Julien H. En réponse à : Accès Internet

    Est ce que la connexion Internet est nécessaire au fonctionnement du logiciel ? ou bien est-ce juste un accès mail pour envoyer la DLL ?

    • Le 4 mai 2006 à 10:05, par ? En réponse à : Accès Internet

      Le logiciel fonctionne bien sans connexion Internet. L’accès est uniquement utile pour
       télécharger le logiciel
       communiquer par email
       voir les résultats sous form de vidéos en ligne

    Répondre à ce message

Un message, un commentaire ?

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.