ELECINF344/381

Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).

Catégories

RoseWheel : avancées post-soutenance

Depuis la soutenance de mercredi matin, nous avons essayé d’avancer sur trois aspects de notre projet :
- Simulateur : nous avons commencé à écrire un nouveau module pour tester seulement la modélisation des moteurs, étant donné que nous avons toujours des résultats inacceptables au niveau de la tension requise pour l’équilibre. En parallèle, nous vérifions les équations du modèle physique général, pour essayer de trouver les erreurs « cachées » ;
- Banc de test : après avoir mis une référence plus visible pour lire le rapporteur, nous avons calibré à nouveau le moteur. Désormais, il reste intégrer ce nouveau calibrage au potentiomètre pour pouvoir savoir exactement la position où se trouve le moteur, et ainsi reprendre nos tests avec une meilleure précision. Voici l’état actuel de notre dispositif :
- Cartes : nous avons commencé à réflechir à la l’implémentation des drivers pour les divers périphériques. Nous voudrions utiliser une architecture plus générique que celle que nous utilisions pour le TP STM32. Suite à quelques essais il semble difficile de faire des fonctions génériques de configuration de périphériques sans faire trop compliqué (fonctions longues, bricolage sur les masques et les offsets…) ; peut-être que des macros préprocesseur seraient plus adaptées… nous explorerons d’autres pistes demain. Nous allons tout de même essayer de faire simple et ne pas implémenter plus de généricité que nécéssaire pour nos deux cartes.

Sur le même sujet :

  1. RoseWheel : le retour !
  2. MB Led: Article post communication challenge.
  3. RoseWheel : banc de tests et filtre de Kalman
  4. [CASPER] Dernières avancées…
  5. Rosewheel restructure son planning

5 comments to RoseWheel : avancées post-soutenance

  • Il y a aussi la possibilité d’utiliser les templates du C++ pour les modules qui ont besoin de paramètres. Y avez-vous réfléchi ? Serait-ce utile dans votre cas ?

  • Fabien

    Vous avez pensé à tester les mouvements transversaux ? Je me souviens que l’an dernier, notre première version du filtre était très fidèle à l’angle de la carte mais les résultats se dégradaient au moindre mouvement de translation…

    • drix

      Intéressant…
      On a pensé mettre un accéléromètre au niveau des roues (il ne mesurerait que les déplacements) pour pouvoir débruiter l’accélérometre au niveau du guidon (il ne mesurerait que l’inclinaison).

      Mais si ça ne va pas, on s’est dit qu’on pourrait tout simplement déscendre la carte capteurs (depuis le guidon vers les roues).
      => Comment tu ferais pour tester/améliorer le système sinon ?

      Merci pour le conseil en tout cas ;)

  • Clément

    Merci du conseil ! Nous n’y avions pas pensé effectivement. Nous nous restreignions jusqu’ici au C99 sans vraiment chercher plus loin. Peut-on aussi faire de l’orienté objet ou est-ce trop lourd pour l’architecture que nous avons ? On pourrait se limiter à du C++ « rapide » sans polymorphisme, juste pour l’encapsulation…

    Pour les templates je ne vois pas très bien où tu veux en venir. De tête j’ai l’impression que ça économiserait quelques switchs, mais pas beaucoup plus. Tu aurais un exemple ?

    • Non. C’était juste une suggestion, je ne comptais pas faire le travail d’exploration à votre place pour autant :)

      Mais l’idée est de pouvoir écrire un code paramétré, instancié une fois par carte, qui fera qu’à la compilation le compilateur choisira l’alternative appropriée, donc sans surcoût à l’exécution ou statiquement.