ELECINF344/381

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

Catégories

Copterix : deuxième présentation

Voici les slides de notre présentation d’aujourd’hui, sur l’état courant du projet et le planning de ce qu’il reste à faire.

 

TSV Safe Express: PCB

Les schémas prêts, nous avons commencé à faire le placement et routage.

En faite, nous finissons ce soir cette partie et il ne reste demain que modifier éventuellement le PCB après sa vérification.

Nous allons poster ce soir un planning plus détaillé et plus réaliste de notre projet.

Copterix : les aventures commencent

Changement de planning :

Suite aux semaines mouvementées que nous avons eu, nous avons refait un planning plus réaliste :

20/03 : Design du PCB (peut dépendre des empreintes disponibles sous Mentor)
21/03 : Lukas & Kanade fonctionnel sur PC
24/03 : Communication Wifi avec la Gumstix pour le streaming video
28/03 : Fin de l’étude physique (Simulation, Kalman)
04/04 : Kalman fonctionnel sur l’IMU
15/04 : Vol stable
22/04 : Déplacement de coptérix

Gumstix :

Nous avons depuis hier deux Gumstix. La première (Tide) n’a pas de flash donc on ne peut pas la briquer…par contre elle n’a pas de Wifi intégré. On utilise donc au début la Tide pour bien prendre en main les Gumstix avant de passer sur la deuxième Gumstix (FE) qui elle supporte le Wifi.

La carte doit booter sur une micro SD. On a donc suivi un tutorial pour pouvoir faire une carte SD bootable à partir d’un noyau précompilé. On a pu aujourd’hui tester la carte et y installer ssh. Par contre, le noyau que nous utilisons ne reconnait pas la caméra. Il faudra soit utiliser un autre noyau pré-compilé soit compiler nous-même le noyau en y rajoutant le driver pour pouvoir utiliser la caméra.

Tracking :

Axel s’est intéressé à l’algorithme de Lucas and Kanade.  Il utilise OpenCV. Voici quelques résultats :
Il a implémenté un petit programme qui montre d’une image à l’autre les déplacements sous forme de traits rouges. L’idée à terme est de faire un filtre médian sur ces vecteurs pour en tirer un vecteur de déplacement fiable.

Rosewheel restructure son planning

Aujourd’hui nous avons pris le temps de réétudier un peu notre planning. Les travaux pratiques de l’UE ont, pour les premières semaines, un peu empiété sur le temps que nous voulions consacrer au projet et quelques modifications s’imposent. Nous pensons néanmoins être toujours dans les temps par rapport à nos objectifs finaux. Notre planning prévisionnel était :

  1. Étude : Kalman, composants, banc de test
  2. Conception PCB : logique, capteurs
  3. Contrôle en vitesse non asservi
  4. Fusion de capteurs & asservissement
  5. Tenir debout, tourner, s’arrêter
  6. Détection d’obstacles
  7. Conception & implémentation contrôle brushless
  8. Conception de l’application Android & video
  9. Soutenance finale

L’étude du filtre de Kalman en première semaine a été concluante. Nous disposons de tous les éléments théoriques pour concevoir le filtre optimal pour notre application. Afin d’assurer un bon équilibre entre robustesse du filtre et complexité des calculs, différentes approches, complémentaires, sont mises en place. Tout d’abord, afin d’assurer la robustesse du filtre aux erreurs numériques susceptibles de se produire du fait de l’utilisation de calculs en virgule fixe, nous comptons utiliser l’algorithme du square root filtering. Ensuite, nous séparerons bien les capteurs entrant dans l’équation d’évolution du système et les capteurs n’ayant un rôle que de « mesure », ceci afin d’alléger la taille des matrices utilisées dans le filtre. Enfin, nous nous placerons dans la situation, fictive, où RoseWheel est toujours immobile. Le mouvement de ce dernier sera vu comme un bruit que nous intégrerons dans les équations et qui, si le choix des différents paramètres est judicieux, nous permettra là aussi d’obtenir des résultats satisfaisant tout en garantissant la simplicité des calculs.

Une étude plus approfondie de la dynamique du système nous a également permis de définir plus précisément nos différentes unités de traitement : filtre Kalman pour supprimer le bruit des capteurs, LQR pour asservissement en inclinaison, LQR pour asservissement en vitesse des moteurs brushless. Il nous manque toujours certaines informations pour pouvoir établir des modèles notamment des informations sur les divers éléments mécaniques et les capteurs. Nous n’avons pas encore finalisé le choix des capteurs et autres composants que nous allons utiliser. Nous avons collecté suffisamment d’informations sur ces derniers mais nous devons maintenant trancher en fonction de plusieurs contraintes : coût, précision, bruit de mesure, disponibilité, délais de livraison, possibilités de collaboration… Par exemple, nous pourrions partager les efforts avec Copterix pour les accéléromètre (MMA7660FCR1), gyroscope (IMU-3000) et capteur sharp (GP2Y0D02YK0F) de façon à factoriser les développements. Mais nous pourrions aussi utiliser des composants plus appropriés comme ce qui a été proposé à la soutenance initiale (nous n’avons par exemple pas besoin de 3 axes pour le gyroscope). Nous allons affiner notre sélection durant les prochains jours pour converger vers un choix final au plus tard samedi prochain (justifications à l’appui) de façon à pouvoir finir les PCB logique et capteurs pour dimanche soir comme prévu..

La première semaine devait également faire l’objet d’une étude sur la réalisabilité d’un banc de tests pour nos capteurs. Suite à plusieurs fausses pistes nous avons finalement trouvé où nous procurer des servos et du bois/plexi. L’implémentation, assez triviale, a bien avancé. La réalisation du banc de test reste tout de même moins prioritaire que l’avancée sur les capteurs et le filtre de Kalman : il est inutile de tester quelque chose que l’on a pas encore conçu. Nous avons donc décidé de reporter la semaine 3, soit la semaine prochaine. Nous devrions avoir un prototype viable en fin de semaine.

Enfin nous avons pris un peu de temps pour développer un simulateur simple de la physique de notre système (pour l’instant tel que décrit dans la thèse de Rich Chi Ooi) à l’aide d’Octave. Cela nous permettra de faire des premiers tests sur le filtre de Kalman et le (les) LQR assez rapidement.

RoseWheel prend la route !

Aujourd’hui nous avons commencé à élaborer le planning du projet.

Un bug tracker a été rapidement mis en place (Redmine) et va nous permettre de :

  • Lister nos tâches et en garder des traces
  • Faire du suivi de bugs et d’ajout de fonctionnalité
  • Nous assigner des tâches les uns les autres
  • Générer des diagrammes de Gantt
  • Partager des fichiers non versionnés (pdf, images, …)

Nous avons pu éclaircir quelques points sur lesquels nous nous posions des questions :

- Il est nécessaire de charger le Rosewheel avec des objets ayant un poids inférieur à 90kg et dont le centre de gravité est approximativement le même que celui d’un être humain.

- Il faut utiliser à la fois un gyroscope et un accelerometre pour nous permettre de mesurer l’angle d’inclinaison du manche du RoseWheel car on a :

  • gyro : integrale(biais + theta_point) = derive linéaire + theta
  • accelero : theta + bruit

ces deux mesures sont en fait complémentaires,

  • gyro = theta + composantes basses fréquences
  • accelero = theta + composantes hautes fréquences

donc fusion des capteurs = filtrage passe-bas + filtrage passe haut.

- Peut-être utiliser en plus un Kalman pour rendre le signal issu de la fusion des capteurs d’angle encore plus propre.

-  Pour la gestion de la sécurité de RW (Arret si detection d’obstacle), nous avons pensé à utiliser un système de sonars et/ou détecteurs infrarouges (Sharps). L’idée serait d’en avoir plusieurs  à l’avant du robot : certains pointant horizontalement pour détecter des murs, d’autres pointant vers le sol pour détecter un changement de pente ou un objet au sol. Détecter un changement de pente  pourrait permettre d’adapter l’allure : si descente on ralentit, si montée on accelère. Par ailleurs on pourrait évetuellement détecter un trou et s’arreter pour ne pas tomber dedans. Nous n’avons pas encore poussé plus loin nos investigations en terme de chiffrage et de choix  de composants.

- Il faut utiliser comme processeur principal un processeur capable de traiter à la fois les calculs des différents filtres (Kalman,passe-haut et passe-bas) pour les calculs de l’angle theta, de traiter les calculs issus des capteurs de distance (Sonars, sharps), de traiter les données issus des encodeurs. De calculer les prochains nombre de tours à appliquer aux moteurs.

- Nous allons remplacer les moteurs CC d’origine par des moteurs Brushless, il sera donc nécessaire d’utiliser un processeur sur la carte de puissance afin de gérer la commande de ceux-ci.

 

 

C’est parti pour MB Led

Hier et aujourd’hui, nous sommes partis du projet GLiP et avons pensé à des évolutions.

Nous espérons avoir les nouveaux blocs qu’Alexis a conçu, sinon il nous faudra le faire nous-même. Nous avons étudié la structure de GLiP en cas de conception de blocs. Nous repartirons sur un STM32, cependant nous regardons si nous ne trouvons pas un controleur avec une plus grande mémoire.

Nous voulons que le nouveau projet puisse lire des informations envoyés en Bluetooth par un smartphone de type Android. Ainsi, nous allons créer un module Bluetooth – Infrarouge. Pour cela, nous avons choisi le module Bluetooth F2M03GLA utilisé l’an dernier par le projet Wheely. Ce bloc ne posséderai pas de contrôleur et l’ensemble du traitement des données envoyées et reçus se feront sur la machine externe en soft.

Autre nouveauté : nous aimerions nous passer d’un maître dans les interactions entre blocs. Il faut concevoir des algorithmes d’échanges d’information en système réparti. Nous étudions actuellement les différentes possibilités.

Enfin, nous avons prévu les étapes, le planning et la liste des critères de succès finaux.

 

Copterix : début du projet

Voici une présentation de nos réflexions sur le projet :

Nous avons décidé d’utiliser une carte Gumstix pour la gestion de la caméra. Elle possède un DSP (traitement vidéo), du Wifi (commande du robot et débug),  et un OS libre. Elle est de plus petite et légère (comparé à une Beagleboard).

Ensuite, on designerait une carte centrale qui communiquerait avec la gumstix. Elle intégrerait aussi une centrale inertielle et se chargerait de l’alimentation. On hésite encore entre l’utilisation de la gumstix ou du stm32 de la centrale inertielle pour l’asservissement des moteurs.

Concernant la caméra, on en a deux en vue : la firefly et la e-cam32.
La première a le défaut d’être en USB et d’être grosse, par contre elle est en global shutter.  La deuxième est toute petite, on peut directement la brancher sur le port dédié de la Gumstix, par contre on ne sait pas encore si elle est en global shutter.

Voila, sinon on a établi une liste de PSSC, une répartition des rôles et un planning prévisionnel.