ELECINF344/381

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

Catégories

Copterix has had a harsh day

Today, we added the yaw servomechanism on the Copterix and it responded pretty well, it is now able to fall slowly like a fall leaf. Sorry we don’t have any video this time, but you will soon understand why…

Our octocopter went through a lot of trouble:

  • When we passed on battery, motors were twice as powerful as on sector, and even though we lowed them a lot, it finally crashed on the ceiling. That was of course not a real test environment (indoor flights are not the exact purpose of a copter), and that is exactly the reason why this accident occurred. It turned out that we just had to change a propeller and our copter was back on tracks.
  • Since yesterday evening, Copterix tends not to start properly. We thought first it was because of the motors card security, which turns off every motors in case of a brutal startup, but it was late tonight we finally discovered with our teacher that it was just a bad contact between a part of this card and the rest of it on the i2c bus, and we finally fixed it.

Afterwards, we performed a Radio Frequency test and it went really well: we think we will be able to control the thrust, roll and pitch by remote control after a few callibration.

Finally, we started our web site ! We plan to add a lot of content about our project during next week, keep on checking !

RoseWheel: gyroscope and communication protocol

Yesterday, after several days of debugging, we finally managed to gather data from the gyroscope. We ultimately found out that the freezes we were experiencing were caused by a reset interrupting an I2C cycle in the exact moment a slave was about to write a ’0′ on the SDA line (as an acknowledgement or during a read cycle); when the STM32 woke up and tried to generate a START condition, the slave would immediately force SDA to a low state, thus preventing the microcontroller from reclaiming the bus. We fixed this problem by sending several clock pulses on the SCL line until the IMU-3000 releases SDA; then, we can force a STOP condition and abort the incomplete cycle.

We have also completed a first version of our communication protocol. Under normal operating conditions, the following messages are exchanged on the bus:

ID Name Description Vital MAIN SENSOR HI
0×08 STOP Emergency Stop !!! Tx/Rx Tx/Rx Tx/Rx
0×09 RESET Reset !!! Tx/Rx Tx/Rx Tx/Rx
0x0A ANGLE_ANGVEL Angle from accelerometer, angular velocity from gyroscope !!! Rx Tx
0x0B SPEED Speed of RoseWheel !!! Tx Rx Rx
0x0C DANGER Danger (detected by distance sensor) !!! Tx/Rx Tx Rx
0x0D MOTORCOMMAND Command sent to the motor
0×10 REMOTECONTROL Remote control (from Bluetooth/UART) Rx Tx Rx
0×11 BATTERYLEVEL Battery level Tx Rx Rx
0×12 USERCOMAND User command Rx Rx Tx

In debug mode, the sensor board sniffs the bus so that it can send it by Bluetooth or serial port. The HI board monitors the exchanges as well to display relevant information on the LCD:

ID Name Description Vital MAIN SENSOR HI
0×08 STOP Emergency Stop !!! Tx/Rx Tx/Rx Tx/Rx
0×09 RESET Reset !!! Tx/Rx Tx/Rx Tx/Rx
0x0A ANGLE_ANGVEL Angle from accelerometer, angular velocity from gyroscope !!! Rx Tx Rx
0x0B SPEED Speed of RoseWheel !!! Tx Rx Rx
0x0C DANGER Danger (detected by distance sensor) !!! Tx/Rx Tx/Rx Rx
0x0D MOTORCOMMAND Command sent to the motor Tx Rx Rx
0×10 REMOTECONTROL Remote control (from Bluetooth/UART) Rx Tx Rx
0×11 BATTERYLEVEL Battery level Tx Rx Rx
0×12 USERCOMAND User command Rx Rx Tx

 

 

RoseWheel : à pleine vitesse

Voici un compte rendu des avancées que nous avons fait pour la démonstration de vendredi et pendant le weekend :

Carte capteurs

Côté accéléromètre, nous avons réussi à communiquer proprement avec accéléromètre en utilisant une interruption externe liée au signal RDY ; cela nous a permis plusieurs démonstrations intéressantes : contrôle d’une LED suivant l’angle, envoi des valeurs mesurées par le port série, affichage de l’angle mesurée avec Matlab.

Pour le gyroscope, nous avons eu plus de difficultés, notamment pour bien gérer l’implémentation du protocole I2C dans le STM32. Après quelques heures de debug, nous sommes arrivés à une implémentation minimale du driver pour la démonstration, les données lues étant transmises par le port série et affichées dans le même graphique que celles en provenance de l’accéléromètre ; cependant, le capteur parfois s’arrêtait sans explication.

Dans un premier temps, nous avions attribué ce problème à des micro-coupures d’alimentation. Néanmoins, nous ne sommes toujours pas satisfaits de cette explication, puisque une telle fragilité n’est pas désirable pour une partie si vitale de notre projet ; alors, nous avons travaillé sur le code pendant le weekend pour essayer de trouver la source des instabilités, mais nous n’avons pas encore trouvé la réponse. À suivre donc…

Filtre de Kalman

Nous avons implémenté en C notre filtre de Kalman dans la journée du vendredi. Afin de procéder aux tests « définitifs », nous attendons d’avoir des drivers plus fiables pour le gyroscope et la partie mécanique monté, étant donné qu’il est indispensable de tester le filtre dans les conditions prévues sur le système pour lequel il a été conçu.

Entre-temps, nous envisageons d’utiliser une version un peu modifié qui ne traquerait que la dérive du gyroscope sur notre banc de test. Pendant la démonstration, nous avons montré nos performances en simulation, dont nous avions parlé dans notre dernier post.

Banc de test

Nous avons également montré au jury le fonctionnement de notre banc de test, notamment le graphique de variation d’angle et de vitesse angulaire, que nous avons détaillé dans des posts précédents.

CAN

Nous avons aussi avancé sur le bus CAN, et nous pensons à le tester demain avec les drivers que nous avons écrit ce week-end.

Moteurs

Nous commençons à implémenter les des moteurs et l’utilisation de PWM pour contrôler les ponts en H.
Sur notre PCB, nous utilisons des « pilotes de demi ponts en H » (IRS2184SPBF) qui permettent (entre autres) d’éviter les court circuits.
Dans le schéma suivant, ces composants se brancheraient à droite et à gauche de façon à ne jamais avoir A et B à la même valeur :


Pour pouvoir changer le sens de rotation, on pense utiliser la broche enable disponible sur le « pilote » (IRS2184SPBF).
Le chronogramme suivant illustre ce que l’on croit nécessaire au moment de la transition d’un sens de rotation à l’autre :

 

De façon à éviter d’entendre le signal de contrôle, on pense utiliser une fréquence de l’ordre de 20KHz mais on ne sait pas encore si cela ne sera pas trop élevé pour « limiter les pertes lors de la commutation des transistors du pont en H ».
Un certain nombre d’incertitudes persistent donc toute suggestion serait la bienvenue !

Planning pour la semaine – « micro-tâches »

Envisageant pouvoir asservir correctement le segway avant dimanche prochain, nous nous sommes attribués les « micro-tâches » suivantes pour la suite :

Drivers carte capteurs

- I2C / Gyroscope -> João 12/04
- SPI / Accéléromètre -> Clément 11/04

Drivers carte principale

- Drivers Ponts en H -> Cédric 13/04
- Contrôle moteurs -> Cédric 14/04
- Drivers CAN -> Florian 11/04
- Tests Drivers CAN -> Florian 11/04
- Protocole CAN -> João 13/04
- Tests protocole CAN -> João 14/04
- Drivers encodeurs -> Clément 14/04

Tests filtre de Kalman

- Intégration filtre TestBench -> Florian 13/04
- Réglage filtre -> Florian 17/04

Intégration logicielle carte capteurs

- Implémentation asservissement en C -> Clément 12/04
- Réglage de l’asservissement -> Clément 17/04
- Réglage direction -> João 17/04

Divers

- Montage RoseWheel -> Cédric 12/04
- Montage encodeurs RoseWheel -> Cédric 13/04

Copterix : PSSC

Voici nos PSSC avec la date et le responsable :

  • Récupération des données des capteurs du STM32 – Date : 13/04Responsable : Samuel
  • Filtrage de Kalman fonctionnel sur la Gumstix – Date : 13/04 – Responsable : Axel
  • Communication entre la Gumstix et le stm32 avec un protocole permettant de récupérer l’ensemble des valeurs des capteurs et d’envoyer les consignes moteurs – Date : 13/04 – Responsable : Loïc
  • Piloter chaque moteur à la vitesse voulue (i2c) – Date : 15/04 – Responsable : Bertrand
  • Lucas et Kanade opérationnel sur la Gumstix – Date : 20/04 – Responsable : Samuel
  • Contrôler les moteurs en fonction des données des capteurs pour atteindre un vol stationnaire – Date : 20/04 – Responsable : Loïc
  • Gestion des déplacements – Date : 25/04 – Responsable : Bertrand
  • Contrôle avec une télécommande – Date : 25/04 – Responsable : Axel

Copterix : la soirée s’annonçait pourtant si bien…

Pendant nos avancées sur l’I2C en communiquant avec l’IMU3000 (gyroscopes), nous sommes parvenus à lui faire acknowledger son adresse et même à la lui demander puis à être capable de la récupérer. C’est à cette apogée que le drame est survenu : d’un instant à l’autre, sans modification du code ni événement particulier, la led rouge du ‘non aknowledge’ s’est allumée. Après vérification à l’oscilloscope, l’IMU3000 ne répond plus d’aknowledge à sa propre adresse, chose qu’elle faisait si bien jusqu’alors…

Programme de demain : déterminer si l’IMU3000 est décédée ou bien si elle traversait ce soir un moment difficile…

Copterix : Premiers résultats avec notre PCB !!

En utilisant le code généreusement fourni par Loïc pour la communication en UART avec le PC, nous avons pu débugger puis parler en SPI avec l’accéléromètre, et ainsi lire ses données qui se sont révélées pertinentes. Nous avons ensuite pu récupérer les données des magnétomètres, qui ont l’air cohérentes modulo un offset qu’il nous reste à régler. Il faudra aussi attendre d’avoir connecté l’axe Z du magnétomètre pour le paramétrer complètement.

Programme de demain : discuter en I2C avec les gyroscopes puis avec les moteurs

Copterix : avancées du lundi

Samuel a fini d’implémenter les magnétomètres et accéléromètres en SPI alors que je faisais le sharp.

Ensuite, Samuel et moi-même avons fini de bricoler Kalman en C++, avant de commencer à implémenter la communication en I2c avec les gyroscopes.

L’arrivée de Samuel Tardieu avec son IMU qui renvoie des données brutes par port série a chamboulé nos plans et fera que notre journée de demain sera consacrée à des tests sur notre Kalman en conditions « réelles »…

Rosewheel : conception des cartes

Conformément à nos objectifs, nous avons passé la journée à établir les schémas électriques de notre carte logique et capteurs.

Vu la diversité des bus de communication de nos capteurs et le nombre d’entrées/sorties nécessaires, nous sommes d’abord partis sur un processeur de type STM32 possédant 64 broches contre 48 pour celui utilisé sur la carte de TP (le processeur reste le même). Après avoir fait l’assignement des broches nous nous sommes dit qu’il serait peut être plus simple d’essayer de brocher le STM32 sur un boitier de 48 broches. Nous avons donc fait deux modifications majeures vis-à-vis de notre modèle initial :

  • Au lieu d’utiliser un port SPI pour l’accéléromètre et un port I2C pour le gyroscope, nous avons choisi de tout multiplexer sur l’I2C. D’aprés nos calculs ça devrait pouvoir tenir le débit.
  • Au lieu d’utiliser 3 UARTs, nous n’utilisons que 2 UARTs et branchons sur la même UART le module Zigbee et l’UART de debug.

Nous nous sommes aussi rendu compte que le module Bluetooth que nous avions initialement choisi était maintenant déconseillé par le constructeur pour des applications Bluetooth récentes. Nous nous sommes donc rabattu sur le même module que celui utilisé l’année dernière par l’équipe Wheely.

La majeure partie étant faite (schéma électrique), nous ferons le placement et le routage dans le courant de la semaine prochaine afin de pouvoir bénéficier de conseils sur l’intégrité du signal notamment. Cela nous a laissé le temps de commencer notre carte de puissance. Nous n’avons néanmoins pas pu terminer le schéma électrique du fait de notre manque de connaissance en électronique de puissance (une petite aide serait la bienvenue). Globalement, la commande des moteurs brushless serait réalisé par 6 transistors MOSFET commandé par 6 PWM en sortie du processeur STM32. 3 capteurs à effet hall sont aussi présents afin de permettre au STM32 de connaitre à chaque instant la position du rotor par rapport aux stators du moteur.

Pour les schémas électriques de la carte de puissance nous nous sommes basés sur ce document : Contrôle Brushless.

Nous avons assigné plus de broches que nécessaire sur les cartes logiques et de puissance pour les sharps et les sonars afin de nous laisser la liberté de choisir ensuite plus précisément la meilleure configuration possible.

Le schéma de la carte logique et capteurs est disponible ici. Toute remarque est bienvenue.

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 :

Copterix : choix des composants

Nous nous sommes fixés sur l’électronique embarquée de notre drone. Nous restons sur une gumstix. Pour l’IMU, nous aurions voulu un chip ST  LSM303DLH avec magnétomètre et accéléromètre trois axes intégrés (5,25€), mais malheureusement il est devenu indisponible récemment. Nous prendrons finalement :

  • un accéléromètre 3 axes LIS302DLH – I2C, SPI – (4,74€)
  • 3 magnétomètres (un SEN-Z et deux Sen-XY)  – SPI – (32,50€)
  • un capteur de pression MPL115A1 numérique – SPI – (10€)
  • un gyroscope 3 axes IMU-3000 – I2C , série – (24€)

On mettrait aussi :

  • une caméra e-CAM32_OMAP_GSTIX qui sera branchée sur le port dédié de la Gumstix (70€)
  • un capteur Sharp  GP2Y0D02YK0F (15,16€) pour connaître notre altitude de manière plus précise lorsque le copter sera près du sol.

Coût des composants ~ 156€.

Coût total (avec la gumstix et une estimation du coût de fabrication de la carte) : 156+219+66.30=441€.

En parallèle, Axel et Samuel sont allés au département TSI pour des conseils sur un algorithme de tracking pour la caméra et il leur a été conseillé d’utiliser une méthode de flux optique. Il y a plusieurs implémentations possibles, mais la plus simple et la moins gourmande en ressources est l’algorithme de Lucas & Kanade. Nous nous renseignons plus en détails sur l’implémentation de cet algorithme.

Ce soir, sachant que l’on aura probablement une gumstix sur hélicoptère, Samuel a regardé de quelle façon on pouvait communiquer entre un pc et la carte pour flasher celle-ci. Il y a pas mal de tutoriel expliquant la communication.