ELECINF344/381

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

Catégories

[CASPER] API update and software architecture

During these past weeks, we implemented several features in separate demonstration programs.

The time as now come to merge these features in a common architecture. For this purpose we revised the API we previously defined, in order to better fit our prototype and libraries.

Then we drew a schematic representation of casper’s software architecture, which should have a LUA script interpreter as the central element. This script interpreter will communicate with the other libraries by posting/retrieving data in a producer/consumer scheme, an exception being the configuration transactions.

The new version 0.2 of the API can be downloaded here: Casper API.

The software architecture is available in pdf file format here: architecture.

[CASPER] Http setup interface

Today, we have been looking for the simplest way of giving a http control interface to our project. We found that the C library Microhttpd was matching our needs.

It’s a library which will allow us to create a very simple http server on the BeagleBoard. This way a user will be able to get registered into Casper’s « Database ». Eventually, through this interface, he will be able to give his name, a new Lua script or his various logins/passwords to access his mails and so on…

Besides, we made some changes in Casper’s prototype. We made a « box » in wood which contains the motors and supports Casper itself, so it’s easier to move it.

 

[CASPER] Prototype fonctionnel

Hier, nous avons finalisé le prototype mécanique.

Nous avons installé les trois servomoteurs sous le plan du socle. Nous les contrôlons grâce à un signal PWM de la carte de TP STM32.

Nous avons changé nos anciens câbles de carbone par des câbles en plastique. Il est apparu que bien que leurs propriétés mécaniques en poussée/traction étaient bonnes, celles-ci ne sont pas assez flexible pour supporter les mouvements au niveau des bras motorisés.

Nous avons implémenté un programme de commandes qui fait effectuer un 360° à Casper que nous contrôlons par le potentiomètre (relié à l’ADC) de la carte de TP.

Nous allons maintenant travailler sur des fonctions qui permettent un contrôle précis de la direction et de l’inclinaison de Casper et en parallèle peaufiner le prototype afin qu’il soit plus robuste.

Voilà la vidéo du programme de démonstration (360° contrôlé par ADC) :

 

Parallèlement, l’UART sur le PCB est fonctionnel et on peut pour l’instant afficher les chaînes de caractères reçues sur l’écran LCD.

[CASPER] Demo de vendredi et API RS232

Voici dans ce post un bilan de la démonstration de Vendredi, ainsi qu’un bref état des lieux des avancées d’aujourd’hui concernant la programmation série en C sous linux.

 

Démonstration de vendredi

Nous avons Vendredi fait état de nos dernières avancées.

Nous avons débuté la démonstration par la présentation du PCB que nous avions réalisé et qu’Alexis nous avait remis il y a peu. Alain a, comme il l’a montré dans un post précédent, réussi à piloter l’écran LCD et afficher une animation simple comportant des rectangles de couleur et du texte.
Reste maintenant à réaliser l’interface série entre la carte et un ordinateur, puis programmer la mémoire flash embarquée.

Nous avons poursuivi par la démonstration de Thomas qui a piloté par l’intermédiaire de la carte de TP STM32 l’un des servomoteurs que nous allons utiliser. Grâce à son programme, nous sommes capables de piloter ces moteurs en leur fournissant une consigne angulaire.
Reste désormais à piloter le prototype en installant trois servomoteurs dans sa base.

Nous avons ensuite effectué une démonstration logicielle qui rassemblait les « helloworlds » que nous avions réalisés avec les différentes bibliothèques. Nous avons ainsi pu piloter à la voix l’ordinateur, lui demander de faire l’apprentissage de deux visages, puis de passer en mode reconnaissance. Une fois en mode reconnaissance, le moteur de synthèse vocale interfacé pour le moment avec pulseaudio a salué les visages connus en les nommant par leurs prénoms.

 

Comme Thomas l’a signalé dans son billet, nous avons pour le moment mis de côté le développement de drivers, pour nous concentrer essentiellement sur la mécanique, la programmation du PCB, et le port de nos applications sur la beagleboard.

Afin de préciser notre démarche, nous publierons bientôt sur ce site une liste actualisée de nos PSCC et des responsables associés.

 

Avancées de la journée : API RS232

De mon côté, je me suis penché sur la programmation du port série en C sous linux. J’ai trouvé à ce sujet une excellente source de documentation, qui m’a permis de comprendre rapidement l’interface posix permettant d’en effectuer la configuration. Vous retrouverez ce guide ici.

J’ai créé une interface de plus haut niveau permettant de lire et d’écrire sur un nombre indéfini de ports série, et de rentre transparente la gestion des lectures et écritures avec tampon.

Il suffit en effet pour utiliser un port série d’en demander l’ouverture en précisant le fichier /dev/tty* associé, et de donner en argument la fonction que l’on souhaite être appelée pour traiter les données.

L’API se charge ensuite d’appeler cette fonction lorsque de nouvelles données sont disponibles, ainsi que d’écrire les données stockées dans des tampons chainés lorsque le matériel est prêt.

L’utilisateur peut donc utiliser des fonctions non bloquantes pour écrire, et utiliser ses propres fonctions pour lire.

Pour finir, bien que cela ne soit pas encore implémenté, il est possible d’ajouter à cette API les sockets en plus des ports série. Cela permettrait de gérer par le biais d’une interface unique toutes les transmissions de la beagleboard, que ce soit par réseau ou avec le PCB.

[CASPER] Un peu de mécanique

Schéma du prototype

Tout d’abord, pour compléter les vidéos postées sur un précédent billet, voici un schéma de notre prototype pour une vue plus claire du système.

 

Contrôle du système

Deuxième partie de ce billet, une description du comportement du robot. Nous considérons tout d’abord le cas d’un robot à un seul « étage » (une seule plateforme). Nous faisons de plus l’hypothèse que les fils latéraux sont assez souples pour prendre la forme de segments (et non d’arcs de cercle comme la tige centrale), et ne peuvent pas exercer de force de poussée (hypothèse expérimentalement réaliste).

Cas où un seul fil est tiré (les autres étant laissés libres)

Le schéma suivant donne la relation entre la longueur d’un fil latéral et l’angle d’inclinaison du système.

Les plus perspicaces remarqueront qu’un développement limité de cosinus en pi/2 permet de prolonger la fonction par continuité et d’éviter les problèmes…

On remarque de même que la longueur des autres fils laissés libres se calcule facilement avec le théorème de Thalès (en n’oubliant pas de projeter les fils dans le bon plan).

La formule précédente donne la longueur a en fonction de l’angle r. Nous l’avons tracée sur la figure suivante :

On remarque qu’au final, la courbe s’approxime plutôt bien par une droite, ce qui a l’avantage de donner sa fonction inverse beaucoup plus facilement que la formule initiale…

Cas où deux fils sont tirés (le troisième étant laissé libre)

Dans le cas où deux fils sont tirés, on peut se ramener à la figure précédente : en supposant que les fils mesurent a et b respectivement, on peut les remplacer par un unique fil de longueur ((L-a)b+a(L’-b))/(L-a+L’-b) et situé entre les deux fils à une distance d*(L-a)/(L-a+L’-b) du fil b, où L’ serait la longueur du fil b si seul le fil a était tiré.

Une fois de plus, le théorème de Thalès permet ensuite d’accéder à la longueur du troisième fil.

Passage à plusieurs étages

Pour passer à un robot à plusieurs étages, il suffit de changer de référentiel en considérant successivement chaque étage. Il faut alors considérer que chaque fil est tiré au niveau de chaque étage proportionnellement à la hauteur de l’étage au repos par rapport à la hauteur totale.

 

Tout ceci permet d’y voir plus clair dans le contrôle moteur (et surtout sur les contraintes que doivent respecter les longueurs de chaque fil). Il reste encore à exprimer toutes les formules suggérées ci-dessus, ce qui ne devrait pas poser de difficulté théorique…

[CASPER] Prototype mécanique du robot.

Cette semaine, nous avons réalisé un prototype de la partie mécanique du projet.

Nous avons une tige centrale renforcée pour soutenir le dispositif de la tête, celle-ci est fixée à des plaques intermédiaires qui guident les fils de contrôle (tiges en carbone).

Cette architecture nous conduira à utiliser des actionneurs linéaires pour tirer sur ces fils de contrôle.

Vidéos du prototype en action :

IRL avance sur deux fronts, ILDA et DMX

DMX

Notre équipe a rencontré hier et ce soir l’équipe de TSM qui rappelons le est en charge des soirées à Télécom ParisTech.
Nous avons discutés longuement de notre projet avec TSM, en particulier Hervé qui a pris beaucoup sur son temps et que nous remercions grandement pour son aide. Il nous a expliqué en pratique le fonctionnement des éclairages de soirée pilotés par DMX.
Nous avons pu à notre tour manier un contrôleur DMX et faire fonctionner deux lampes de manières indépendantes.
Nous avons éclaircis tous les points d’ombres que nous avions sur la mise en pratique du protocole et sommes assurés de pouvoir bénéficier d’éclairages et d’un contrôleur au moment opportun pour pouvoir tester notre système dans les prochaines semaines.

ILDA

Laurent a exploré les possibilités de prototypage du système laser en python.
Il a réalisé un petit programme de test basé sur :
- le code de Micah Dowty pour traiter les fichiers ILDA (http://svn.navi.cx/misc/trunk/laserprop/client/ILDA.py)
que nous décortiquerons pour créer un programme beaucoup plus léger et adapté à notre problématique.
- le module turtle de python pour simuler les déplacements du laser.

Au final, à partir d’une image ILDA on obtient dans une fenêtre la liste des points sous la forme des voltages à envoyer en sortie des DAC (entre 0 et 10V donc) et dans une autre fenêtre une représentation de ce qui sera affiché par le laser.
Il reste encore des pistes à exploiter pour ce prototype comme l’étude des effets des changements de résolution des DAC.


Perspectives

Nous comptons par ailleurs commencer le PCB à la fin de la semaine et éventuellement faire une simulation de la carte laser en Verilog.

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.