ELECINF344/381

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

Catégories

RoseWheel: tests preparation

This week we tried to put together our developments and make them interact with each other. It includes sensors communication, kalman filter, control feedback, motors control, CAN communication protocol. We were dogged by bad luck as we realized the heatsink of our mainboard was too big to fit in the Zzaag… A few millimeters required us to order for a new one with a more suitable shape. Fortunately Alexis and Samuel helped us to find a new one. Because of that we were not able to validate the following « feedback control tuning » PSSC for Saturday as planned. Adviced by Samuel we also decided to postpone the « encoders drivers » PSSC as it wasn’t really in our first order priorities.

 

We tried to make profit of this situation and decided to prepare everything for the first tests. Alexis helped us defining our tests procedure to be as safe as possible for both hardware and people. Motors need special attention as they can be broken with unsuitable commands. Because of the wheels and the weight of the chassis they have a really high inertia. Asking them sharply to reverse their direction of rotation when they are rotating fast can seriously damage them and the H-bridges. If we damage them we wouldn’t be able to order new ones before the end of the course, it would be fatal for our project. Therefore we need at first to make some testing at low speed so as to define the maximum acceptable speed at which we can run the motors before they get damaged. To this extent we need an interpreter running on the mainboard and communicating using RS232 to be able to give motors various commands and define this maximum speed. Then we need to limit our commands to this maximum speed using software limitations. Finally the interpreter should be able to change the feedback control values for our testing to be more flexible. We implemented such an interpreter and made a video. The motors commands in the video are given between 0 and 1000 such as:

  • ml0 = 0%:  max negative speed
  • ml500 = 50%: stop
  • ml1000 = 100%: max positive speed

 

Before trying the Zzaag motors we do some testings on other DC motors with less inertia that we cannot damage as easily as the Zzaag’s ones. Putting all the pieces together we were able to shoot a video which shows the motors reacting appropriately to the inclination of the sensorboard. As for the Kalman filter, we implemented a lighter version than the one of RoseWheel as it works best when tested on the real system. This version was only able to track the gyroscope drift and correct it. As far as we could see during the testing, it did it well. Concerning the PID, we tried to test the version that we are going to use in the RoseWheel but it still needs to be improved during the next tests.

 

Tomorrow we will be able to work on the Zzaag motors using our safe procedure and the tools developped. We look forward to it as it is a major step further for our project…

Copterix : first moves

Yesterday we finally observed the first moves of our octocopter. After spending all the day working on the communication with the motors, Samuel and Axel have succeeded in controlling the motors from the STM32, with the help of Jon, passing by. They speak to them in I2C, and they can control the speed of the propellers. The Copter tried to run away, but he was fortunately attached on a table. However, we have to be more careful in the way we will attach it in the future, because it was close to a disaster.

On my side, I tried the RF controller, a Spektrum DX7 transmitter/receiver. I tested it on the STM32 board that we have previously use for the communication challenge, it works as we can expect, thanks to the code of the Heliokter team. We use indeed the code from last year’s project, which seems to fit to our needs. The RF receiver gives us access to different integers, which indicate us the pitch, the roll, the yaw and the thrust, and also some commands. The way the receiver communicates with the PCB is simple : it use the RS232 protocol, with a speed of 115200 kbps. It sends packets of 16 bytes separated by long period with idle line. I have implemented the code for our PCB and for getting the commands on the Gumstix, but I still need to test it.

On his side, Bertrand principally tried to debug some aspect of the STM32 code. When we send data in the both directions and look for the values of the sensors at the same time, some freezes occur. We think it’s maybe because the code needs some optimization, so Bertrand is working on it.

[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.

RoseWheel fait des simulations

Cet article a été rédigé hier soir…

Nous avons terminé ce week-end le PCB de notre carte capteurs. Nous avons fait le schéma de notre carte principale mais Alexis va y ajouter la partie puissance et la router pour nous.

Carte Capteurs [avant]

Carte Capteurs [arrière]

Aujourd’hui nous avons travaillé en parallèle sur l’utilisation du banc de tests et sur le simulateur qui intègre le filtre de Kalman et l’asservissement.

Le simulateur commence à fournir des résultats mais nous avons encore des problèmes de valeurs numériques. Notre simulation fait intervenir des tensions de plusieurs milliers de Volts (alors que nos moteurs n’en acceptent que 24) pour réussir à redresser le gyropode. Cela est certainement dû à une mauvaise estimation de nos constantes km (constante de couple en N.m/A) et ke (constante force contre-électromotrice en V.s/rad).

Pour les calculer nous avons récupéré les caractéristiques du moteur sur le site du distributeur :

À charge nominale on a

  • Vitesse angulaire : VA = 3751 rpm
  • Couple : T = 0.88 N.m
  • Intensité : I = 18.36 A
  • Résistance : R = 0.66 Ohm
  • Tension : U = 24.09 V

Or

  • km = T / I = 0.048 N.m / A
  • ke = (U -- R * I) / VA = 0.030 V.s / rad

Mais avec ces valeurs nous rencontrons les problèmes mentionnés plus haut. Ces problèmes viendraient-il d’ailleurs ? Alexis nous a conseillé de faire un simulateur des moteurs seuls pour déterminer vérifier nos constantes. À suivre…

Par ailleurs, comme le montre la figure suivante, le filtre de Kalman se comporte bien. Même avec un rapport signal sur bruit médiocre nous arrivons à reconstituer assez fidèlement l’angle d’inclinaison. Pour l’asservissement nous avons testé deux techniques : PID puis LQR. Le PID s’avère être délicat à régler et ne nous a pas donné de résultat satisfaisant (divergence de l’erreur au bout d’un certain temps). Le LQR se comporte beaucoup mieux et propose un réglage moins empirique. Couplé au filtre de Kalman, et problèmes de valeurs numériques exclus, notre système se comporte vraiment comme nous le souhaitons. Reste donc à vérifier si nous observons le même comportement avec les bonnes valeurs numériques pour les moteurs. Notons que pour l’instant nous incluons le déplacement et la vitesse dans nos variable d’état ce que nous ne pourrons faire que si nous arrivons à monter des encodeurs sur la mécanique du projet zzaag.

Simulateur RoseWheelCliquez sur l’image pour voir l’animation.

Concernant le banc de tests nous avons terminé sa réalisation. Nous avons monté une vidéo tournée vendredi pour le montrer en action :

Cette première version du banc de tests fonctionne ainsi :

  • on communique avec la carte de TP en RS232
  • la carte de TP commande le servo qui incline la carte capteurs du projet Wheely
  • on récupère les données des capteurs via RS232 sur l’ordinateur
  • on affiche conjointement les courbes de la commande et de la mesure

Pour les mouvements lents, nous procédons par rotations successives. La précision du servomoteur étant assez faible, cela entraîne des mouvements saccadés et introduit un bruit non négligeable lors des transitions. Par ailleurs, la calibration du banc s’avère insuffisante ce qui se traduit par un offset sur les valeurs mesurées. Nous aurions aimé présenter des courbes (superposition commande / mesure du banc de test) mais nous avons été chassés d’A405 avant d’avoir pu les exporter… No comment. Nous travaillerons demain à l’amélioration de ces résultats.

RoseWheel : Choix des composants – Architecture matérielle

La réunion de vendredi avec Alexis et Samuel nous a permis d’éclaircir un certain nombre de points. Nous avons ainsi pu établir aujourd’hui un choix quasiment définitif de nos composants ainsi que l’architecture  matérielle de RoseWheel.

Le système est composé de 3 cartes :

  • Une carte mère contenant toute la logique
  • Une carte de puissance permettant de contrôler les moteurs Brushless
  • La carte de puissance permettant de contrôler les moteurs DC du projet ZZAAG

La carte mère qui se trouvera sur le guidon contient :

  • 1 processeur STM32 qui sera en charge de traiter les calculs nécessaires à l’implémentation du filtre de Kalman pour la fusion des capteurs ainsi que les calculs pour l’algorithme d’asservissement des moteurs. Concernant cet asservissement, nous avons choisi dans un premier temps d’implanter un PID. Ensuite nous nous dirigerons vers l’implémentation d’un LQR
  • Les capteurs permettant le contrôle de l’équilibre, soit le gyroscope et l’accéléromètre
  • 3 UARTs, pour une connexion RS232 pour le debug, une connexion Zigbee, une connexion Bluetooth
  • 1 LCD permettant d’afficher des informations pour l’utilisateur
  • Des jumpers ADC pour la connexion d’une partie des Sharps pour la détection des obstacles
  • 1 port CAN bidirectionnel permettant de communiquer avec la carte de puissance de contrôle des moteurs Brushless

La carte de contrôle en puissance des moteurs Brushless qui permettra aussi, dans un premier temps, de faire l’interface entre la carte de contrôle de puissance des moteurs DC du ZZAAG et la carte logique. Cette carte contient :

  • 1 processeur STM32 permettant de générer les PWM nécessaires au fonctionnement, d’une part des moteurs DC sur la carte du ZZAAG, d’autre part les PWM permettant de gérer le contrôle des moteurs Brushless
  • 1 connecteur CAN bidirectionnel fin de communiquer avec la carte mère logique différentes informations. Notamment les données permettant l’asservissement des moteurs
  • 1 jumper pour la connexion des Sharps nécessaires à la détection des obstacles à courte distance
  • 1 jumper pour la connexion des encodeurs
  • 3 ports pour la connexion des données provenant des capteurs à effet Hall du moteur Brushless et permettant de gérer le contrôle de ces moteurs

La carte de contrôle de puissance du ZZAAG qui sera contrôlée par la carte de contrôle de puissance des Brushless et qui ne nécessite en entrée que 2 PWM (1 pour chaque moteur) ainsi que 2 autres entrées permettant de contrôler la direction.

Le choix plus précis des composants est à priori :

Accéléromètre : LIS3LV02DL – 3 axes – port SPI – boitier LGA-16 – fréq échantillonnage 640 Hz – prix : 15,09 €

Gyroscope : IMU-3000 – 3 axes – port I2C – boitier QFN – fréq échantillonnage 8000 Hz – prix : 34,98 €

Encodeurs : HEDS-5500#A06 – Vmax 30000 tour/min ( un peu beaucoup mais moins cher ) – fréq échantillonnage 100 kHz – prix : 50,07 €

Bluetooth: AMB2300 – prix : 29,04 €

Xbee : XBP24-AWI-001 – prix : 30,62 €

LCD : MDLS16265LED043V – prix 39,29 €

Sharps :

  • GP2Y3A003K0F – Min distance : 20cm – Max distance : 150cm  - Angle de vision : 25°  - prix 55,35 €
  • GP2Y0A710K0F - Min distance : 40cm – Max distance : 300cm  - Angle de vision : 25°  - prix 25,57 €

Capteurs ultrason :

  • MSU05 – Angle de détection plus large que les Sharps (55°) : possibilité de fusion de capteurs – Utilisation simple : 1 GPIO – prix 21.5 €

Enfin voici un schéma de notre architecture materielle :

IRL : du nouveau, encore du nouveau !

Après une n ème réflexion le projet IRL évolue et se précise :

Laurent s’est penché sur les datasheets de différents modules Zigbee, notamment ceux employés à Télécom Robotics (nous remercions au passage Samuel pour son lien). Il a étudié comment brancher les modules Zigbee pour pouvoir les utiliser via un lien RS232. Pendant ce temps, Yoann s’est renseigné sur internet sur les DAC et nous avons tous ensemble regardé les cartes d’extensions disponibles pour la Beagleboard.

Yoann et Caroline ont compris grâce à Alexis que Linux ne serait pas bien adapté à l’envoi en temps réel des points au laser. Nous utiliserons donc un micro contrôleur dédié à cette tâche avec un OS temps réel qui sera vraisemblablement FreeRTOS (toutes suggestions serait la bienvenue). Ceci porte à trois ou quatre le nombre d’entités du système qui est désormais formé des éléments suivants :

  • Une carte (appelée « principale » par la suite) hébergeant l’interface web d’administration, dont les fonctions principales sont le stockage des informations et le pilotage du système.
  • Un micro contrôleur traitant le flux DMX à la volée, recevant des informations de la carte principale par Zigbee.
  • Un micro contrôleur en charge des déplacements du laser, recevant des informations par un lien filaire qu’il a avec la carte principale.
  • Un autre micro contrôleur en charge de la sécurité : il coupe le laser s’il reste sur un même point pendant trop longtemps (cette fonction pourrait éventuellement être déportée sur la carte principale).