Mon contenu
Homme
La prochaine étape est un multi copter!
Je suis entrain de porter la lib MultiWII sur CHIPKIT et je compte me lancer dans la construction d'un Quadri copter contrôlé par la centrale inertielle MPU6050.
Du boulot en vu....
/>
- Melmet aime ceci
#57309 Mon premier robot contrôlé par un MAX32 chipKIT Microchip PIC32
Posté par
- 02 août 2013 - 03:42
Merci beaucoup pour les commentaires.
La prochaine étape est un multi copter!
Je suis entrain de porter la lib MultiWII sur CHIPKIT et je compte me lancer dans la construction d'un Quadri copter contrôlé par la centrale inertielle MPU6050.
Du boulot en vu..../>
La prochaine étape est un multi copter!
Je suis entrain de porter la lib MultiWII sur CHIPKIT et je compte me lancer dans la construction d'un Quadri copter contrôlé par la centrale inertielle MPU6050.
Du boulot en vu....
/>
#49533 Mon premier robot contrôlé par un MAX32 chipKIT Microchip PIC32
Posté par
- 15 octobre 2012 - 10:57
Mon Robot est basé sur le 4WD DFRobot Arduino compatible et il est contrôlé par le chipKIT Max32.
Max32
Le chipKIT ™ Max32 ™ est basé sur la plate-forme Arduino ™ mais il ajoute la performance du PIC32 Microchip. Le Max32 est compatible avec de nombreux Arduino ™ shields. Il dispose d'une interface série USB pour la connexion à l'IDE et peut être alimenté via USB ou une alimentation externe.
Le Max32 tire parti de la puissance du microcontrôleur PIC32MX795F512. Ce microcontrôleur dispose d'un noyau 32 bits MIPS cadencé à 80Mhz, 512K de mémoire Flash et 128K de mémoire de données SRAM. En outre, le processeur fournit un contrôleur USB 2, un contrôleur 10/100 Ethernet MAC et CAN qui peuvent être accessibles via des shields I/O.
Le Max32 peut être programmé à l'aide d'un environnement basé sur l'original IDE Arduino modifié pour supporter PIC32. En outre, le Max32 est entièrement compatible avec Microchip MPLAB IDE et le système de PICKit3 programmateur / débogueur
A noter qu’au départ j’ai utilisé le chipKIT ™ Uno32 ™ mais je suis arrivé à la limite de la mémoire flash de programme (128K) lorsque j'ai ajouté les libs TCP et WIFI, j'ai alors du migrer vers le chipKIT ™ Max32 ™ qui possède 512K de mémoire flash de programme.
Plus d'infos sur chipKIT ™ Max32 ™ dans la doc
chipKIT Max32_rm.pdf 732,4 Ko
293 téléchargement(s)
Quatre roues motrices
J'utilise l'engin quatre roues motrices de DFRobot avec 2 capteurs encodeur afin de récupérer la vitesse des deux moteurs avant droite et gauche. Ceci est utile pour contrôler la direction et la mise en œuvre d'un Processus PID. Le montage des capteurs est décrit dans la doc
installation-method-fit0029.pdf 187,26 Ko
311 téléchargement(s).
Attention, il y a un défaut de conception dans le montage des encodeurs car ils frottent
Par conséquent, on est obligé de rajouter un écrou sur la visse qui fixe l'encodeur afin que le disque ne frotte pas dessus lors de sa rotation.
Ci-dessous un gros plan sur les 2 roues avant équipées chacune d'un encodeur
Les spécifications sont les suivantes:
Caractéristiques du moteur:
Power
J'utilise un bloc de 5 piles AA 1,5 V pour un total de 7,5 V pour alimenter le chipKIT Max32 via le connecteur d'alimentation externe.
Le chipKIT Max32 délivre en sortie une tension régulée de 3V et 5V qui permettent d’alimenter les autres composants : servos, capteur IR, boussole ... à l'exception des moteurs qui sont alimentés par une batterie Lipo 2S 7.4V 350mAh
Déparasitage des moteurs
Les moteurs utilisés ne sont pas brushless, c'est a dire qu'ils sont constitués de charbons qui transmettent le courant au rotor (partie tournante du moteur) et qui frottent sur un induit. Ce frottement produit des étincelles qui engendrent des courants parasites.
Pour supprimer ces courants, j'ai ajouté un condensateur de 100 nF non polarisé (type céramique) entre les 2 bornes du moteur afin d'intercepter ces courants parasites. On peut également ajouter 2 autres condensateurs de plus faible capacité (10 nF) entre chacune des bornes et la carcasse métallique.
Dans tous les cas, les condensateurs doivent être soudés au plus prêt des bornes pour des raisons d'efficacité
H-Bridge
Un micro contrôleur est incapable de fournir le courant nécessaire à un moteur, s'est pourquoi il faut toujours un étage de puissance avant les moteurs.
La vitesse d'un moteur électrique n'est pas proportionnelle à la tension électrique à ses bornes. Le moteur demande une tension minimale assez importante pour démarrer. Si cette dernière est trop basse, les forces électromagnétiques ne sont pas suffisantes pour combattre le frottement. Il devient donc difficile d'ajuster la vitesse de façon précise.
La solution à ce problème est astucieuse. Il suffit de fournir au moteur une tension qui est toujours la même soit la tension maximale! Par contre, cette tension ne sera appliquée que par très courtes périodes de temps. En ajustant la longueur de ces périodes de temps, on arrive à faire avancer plus ou moins vite les moteurs. Mieux, on remarque que la vitesse des moteurs devient proportionnelle à la longueur des périodes de temps. Contrôler la longueur des périodes passées à la tension maximale par rapport au temps passé sans application de tension (tension nulle) est donc le cœur de la solution. En réalité, cette solution est fort connue en contrôle des systèmes et en électronique et elle porte le nom de PWM (Pulse Width Modulation).
Un signal PWM n'est pas généré par un pont en H. Par contre, le fait qu'un pont en H soit constitué de transistors le rend particulièrement apte à être contrôlé par un signal PWM. On doit donc voir le couple PWM et pont en H comme un outil particulièrement efficace pour contrôler des moteurs électriques
Il existe plusieurs modèles de ponts en H, j'ai choisi le L298N, car il permet jusqu'à 4A et aussi parce que DF Robot propose un module prêt à l'utilisation de ce circuit, nommé 2A Dual Motor Controller. J'ai d'abord utilisé le L293D qui est aussi un bon choix, mais limité à 1A. Comme j'ai eu beaucoup de problèmes avec mes soudures, j’ai préféré un circuit déjà monté.
Plus d'infos sur le L298N dans la doc
l298n-motor-driver-datasheet.pdf 449,63 Ko
229 téléchargement(s)
et sur 2A Dual Motor Controller dans la doc
DFROBOT Motor Controller.doc 170,5 Ko
299 téléchargement(s)
Un L298N est utilisé pour contrôler 2 moteurs, donc j'utilise 2 L298 pour contrôler le robot.Ils sont alimentés par une batterie Lipo 2S 7.4V 350mAh pour les 2 types de tensions, logique et moteur.
La façon de contrôler le moteur est la suivante:
Les pins IN sont connectés aux digital pins standard de chipKIT tandis les Enable pins sont connectées aux pins PWM de chipKIT qui utilisent les fonctions analogWrite () qui s'appuient sur les timers Oci:
#define InMotorRight1Pin 30 // In pin of Motor controller #1 for motor right #1
connected to digital pin J9-08(PMD7/RE7)
#define EnableMotorRight1Pin 3 // Enable pin of Motor controller #1 for motor right #1
connected to PWM pin J14-07(SDO1/OC1/INT0/RD0) Use TIMER_OC1
#define InMotorRight2Pin 31 // In pin of Motor controller #1 for motor right #2
connected to digital pin J9-07(PMD6/RE6)
#define EnableMotorRight2Pin 5 // Enable pin of Motor controller #1 for motor right #2
connected to PWM pin J14-11(OC2/RD1) Use TIMER_OC2
#define InMotorLeft1Pin 32 // In pin of Motor controller #2 for motor left #1
connected to digital pin J9-06(PMD5/RE5)
#define EnableMotorLeft1Pin 6 // Enable pin of Motor controller #2 for motor left #1
connected to PWM pin J14-13(OC3/RD2) Use TIMER_OC3
#define InMotorLeft2Pin 33 // In pin of Motor controller #2 for motor left #2
connected to digital pin J9-05(PMD4/RE4)
#define EnableMotorLeft2Pin 9 // Enable pin of Motor controller #2 for motor left #2
connected to PWM pin J3-03(OC4/RD3) Use TIMER_OC4
Encodeurs
Les 2 capteurs encodeur montés sur les deux moteurs avant droite et gauche permettent de calculer la vitesse des moteurs.
Ils sont connectés aux pins d’interruptions INT3 et INT4 du Chipkit ce qui permet de connaitre à tout instant le nombre de ticks réalisé par chaque moteur. Un encodeur génère 20 changements de tension par tour lesquels déclenchent par conséquent 20 interruptions par tour. J’utilise les pins INT3 et INT4 du PIC pour gérer les interruptions de manière hardware afin de ne pas pénaliser la cpu. Attention de bien définir les pins en input avant d’appeler la fonction attachInterrupt() pour configurer l’interruption.
Vous pouvez consulter une description plus détaillée du fonctionnement des encodeurs dans ce document (en anglais)
Wheel Encoders for DFRobot 3PA and 4WD Rovers.doc 178,5 Ko
292 téléchargement(s)
La connexion entre les deux Encodeurs et la chipKIT est la suivante:
#define EncoderTickRightINT 4 // INT used by the encoder for motor right
connected to interrupt pin INT4 J4-02(AETXEN/SDA1/INT4/RA15) Use INT4
#define EncoderTickLeftINT 3 // INT used by the encoder for motor left
connected to interrupt pin INT3 J4-01(AETXCLK/SCL1/INT3/RA14) Use INT3
Détecteur Infra-rouge
Un détecteur Infra-Rouge GP2Y0A21YK permet de détecter les obstacles. Il est connecté sur un des pins analogic du Chipkit afin d’utiliser la fonction analogread() qui permet de convertir une tension en une valeur entre 0 et 255 grâce au module ADC du PIC.
Ce nombre est ensuite converti en cm en se basant sur l’abaque fournie pour une tension de 3V dans le datasheet du GP2Y0A21YK
GP2Y0A21YK-DATA-SHEET.PDF 277,83 Ko
218 téléchargement(s)
Notez que vous pouvez également utiliser une tension de 5V mais vous perdez en précision.
Vous pouvez consulter une description plus détaillée du fonctionnement des détecteurs Sharp dans ce document (en anglais)
IR SHARP.doc 322 Ko
239 téléchargement(s)
La connexion entre le capteur infrarouge et le chipKIT est la suivante:
#define GP2Y0A21YK_Pin 54 // IR sensor GP2Y0A21YK analogic pin J5-01 A0
(PGED1/AN0/CN2/RB0) Use ADC module channel 2
/* Analogic interface is provided on pin V0 */
/* Power +3V is set on pin VCC */
/* Ground is set on pin GND */
Servo IR
Le détecteur Infra-Rouge GP2Y0A21YK est monté sur un Servo afin de pouvoir déterminer les obstacles dans différentes directions, en particulier droit devant, à droite et à gauche.
Le servo est commandé par des impulsions de période 20 ms et de largeur comprises entre 1 et 2 ms. Ces impulsions sont gérées par la lib software PWM ce qui permet de gérer plusieurs servo en monopolisant seulement un des timers du PIC.
Vous pouvez consulter une description plus détaillée du fonctionnement des servos dans ce document
Servomoteurs.doc 50 Ko
238 téléchargement(s)
La connectivité entre le servo IR et la chipKIT est la suivante:
#define IRSERVO_Pin 36 // IR Servo pin connected to digital pin J9-02 (PMD1/RE1)
/* Power +5V */
/* Ground */
Compas
Un compas CMPS03 est connecté afin d’indiquer la direction.
Ce compas communique avec le PIC via l'interface I2C en utilisant la librairie standard Wire. On peut connaitre la direction en interrogeant via le protocole I2C les registres du Compas.
L’adresse I2C est définie de la façon suivante :
#define CMPS03_ADDRESS 0x60 //1100000: compass address 0XC0 on 7 bits for I2c protocol
Après plusieurs essais, j’ai disposé le compas loin du socle métallique du robot, des moteurs et des servos car il fournissait des résultats complètement erronés. Attention également à le mettre horizontalement pour une meilleure précision.
Vous pouvez consulter une description plus détaillée du fonctionnement du Compas dans ce document (en anglais)
CMPS03.doc 148,5 Ko
224 téléchargement(s)
Le chipKIT Max32 gère 5 Interfaces I2C maximum mais la librairie standard Wire n’en gère qu’une. Par défaut, cette lib utilise le I2C1 mais je ne peux pas utiliser cette interface parce que les pins correspondants sont partagés avec INT3 et INT4 qui sont requis par les encodeurs. Alors, j'ai mis à jour le fichier Board_Defs.h afin d’utiliser l'interface I2C5 au lieu de I2C1.
#define _TWI_BASE _I2C2_BASE_ADDRESS
#define _TWI_BUS_IRQ _I2C2_BUS_IRQ
#define _TWI_SLV_IRQ _I2C2_SLAVE_IRQ
#define _TWI_MST_IRQ _I2C2_MASTER_IRQ
#define _TWI_VECTOR I2C_2_VECTOR
#define _TWI_IPL_ISR _I2C2_IPL_ISR
#define _TWI_IPL _I2C2_IPL_IPC
#define _TWI_SPL _I2C2_SPL_IPC
En outre, j'ai relié les pins SDA et SCL à +5 V via une résistance de pull-up de 1K indispensable pour gérer le bus avec le protocole I2C.
La connexion entre le compas et le chipKIT est la suivante:
/* Compass */
/* I2C interface is provided on pins: */
/* 1 = Power +5V */
/* 2 = SCL connected to J3-09 (SCL2/RA2) */
/* 3 = SDA connected to J3-11 (SDA2/RA3) */
/* 9 = Ground */
Capteur de température
Un capteur de température TMP102 est connecté afin d’indiquer la température.
Ce capteur de température communique avec le PIC via l'interface I2C en utilisant la librairie standard Wire. On peut connaitre la température en interrogeant via le protocole I2C les registres du capteur.
L’adresse I2C est définie de la façon suivante :
#define TMP102_ADDRESS 0x48 //1001000: temperature sensor address 0X90 on 7 bits for I2c protocol
La communication I2C est identique à celle décrite précédemment pour le Compas.
Vous pouvez consulter une description plus détaillée du fonctionnement du capteur de température dans ce document (en anglais)
tmp102.pdf 459,52 Ko
207 téléchargement(s)
Capteur photo
Un capteur photo JPEG Serial LS-Y201 est embarqué sur le robot.
Ce capteur communique avec le PIC via l'interface UART2 à 38400 bauds à l'aide de la standard Serial library. J’ai dédié UART2 à ce composant afin d'éviter tout conflit avec d'autres interfaces série (log, XBee ...).
Le capteur nécessite une procédure d'initialisation spécifique:
La façon de faire une image est la suivante:
Une fois que l'image est stockée sur la carte SD, il est possible de la transmettre plus tard à n'importe quel client via XBee ou Wifi. Il est possible de ne pas utiliser une SD-Card et de publier directement l'image en temps réel mais c’est plus complexe a cause de la synchronisation de la communication entre le capteur photo et le client XBee / Wifi.
Par ailleurs, ce capteur est monté sur un Tilt & Pan dirigé par 2 servos afin de permettre des mouvements horizontaux et verticaux pour pouvoir prendre des photos sous différents angles.
Plus d'infos sur le capteur photo dans la doc
LinkSprite JPEG Color Camera Serial LS-Y201 User manualv1.1.pdf 398,26 Ko
197 téléchargement(s)
La connexion entre la caméra et la chipKIT est la suivante:
/* Camera */
/* UART2 interface is provided on pins: */
/* 1 = Power +5V */
/* 2 = TX connected to J4-04 (AETXD1/SCK1A/U1BTX/U1ARTS/CN21/RD15)*/
/* 3 = RX connected to J4-03 (AETXD0/SS1A/U1BRX/U1ACTS/CN20/RD14) */
/* 4 = Ground */
Tilt&Pan servos
Le capteur photo est monté sur un Tilt & Pan dirigé par 2 servos afin de permettre des mouvements horizontaux et verticaux.
Ces servos sont gérés comme le Servo IR.
Plus d'infos sur le montage du Tilt&Pan dans la doc
Pan&Tilt assembly instructions.doc 86 Ko
212 téléchargement(s)
La connectivité entre Tilt & Pan servos et le chipKIT est la suivante:
#define HSERVO_Pin 34 // Horizontal Servo pin connected to digital pin J9-04 (PMD3/RE3)
/* Power +5V */
/* Ground */
#define VSERVO_Pin 35 // Vertical Servo pin connected to digital pin J9-03 (PMD2/RE2)
/* Power +5V */
/* Ground */
Ci-dessous vous pouvez voir la Camera montée sur Tilt & Pan et en dessous le IR sensor monté sur un servo
SD-Card
La SD-Card est utilisée pour stocker les images prises par l’capteur photo.
La SD-Card communique avec le PIC via l'interface SPI.
ATTENTION: il y a un conflit entre la SD-Card et WIFI comme l’a indiqué KeithV de Diligent. Le problème est que le Wifi et la SD-Card partagent le même port SPI et le module Wifi est également connecté à INT1 sur le WiFiShield. Si vous lisez la SD-Card lorsque le Wifi génère une interruption, le PIC va activer le CS du module Wifi et les deux dispositifs SPI Wifi et SD seront donc actifs simultanément. Suite à la proposition de KeithV, j'ai modifié la lib SD-Card standard afin de désactiver INT1 lors de la lecture / écriture de la SD-Card.
Communication
Le robot peut communiquer en utilisant XBee ou WIFI.
J'ai écrit une petite interface Java pour communiquer avec le robot avec ces deux protocoles, mais un seul mode est disponible à un moment donné parce que cela dépend du shield utilisé.
XBee Communication
WIFI Communication
J'utilise le chipKIT Wifi Shield ™ qui est basé sur le module Wifi Microchip MRF24WB0MA.
Il communique avec le PIC via SPI et il utilise également INT1 (attention voir les conflits dans la section SD-Card.).
Il est conçu pour être utilisé avec les bibliothèques réseau Digilent, DNETcK et DWIFIcK. Attention ces lib sont conséquentes (60K), c'est la raison pour laquelle j'ai migré de Uno à Max.
J'ai utilisé ces bibliothèques pour construire un mini serveur HTTP qui écoute sur un port et établit une connexion si un client tente de se connecter. Ensuite, le message reçu est analysé afin de déterminer la commande et les paramètres optionnels. J’ai défini le format suivant pour le message:
Cmd = & param = param1, param2;
où est la commande requise et param1, param 2 .. sont les paramètres optionnels avec ";" comme séparateur. CMD et PARAM sont les deux mots-clés.
Une fois que la commande est traitée par le robot, il répond avec le format suivant (Content-Type: text / html):
Champ 0: value0; Champ 1: valeur1;
où value0, valeur1 sont les réponses optionnelles avec ";" comme séparateur. Champ est un mot clé.
En cas de commande qui déclenche une image, la réponse se compose du flux d'octets (Content-Type: application / flux d'octets) qui représentent le contenu du fichier JPEG.
Plus d'infos sur le shield WIFI dans la doc
chipKIT WiFi Shield.pdf 194,34 Ko
235 téléchargement(s)
Contacteurs
Les premiers essais avec le IR sensor comme seul détecteur d’obstacle ont montrés des limites, comme par exemple dans le cas d’obstacles au ras du sol qui ne sont pas détectés.
C’est pourquoi j’ai ajouté 2 contacteurs équipés de « moustache » qle.ui indiquent le contact avec un obstacle.
Le principe est simple, dès que le contacteur rencontre un obstacle, son pin Signal pase de l’état haut à l’état bas.
J’ai donc ajouté le contrôle de l’état du pin de chaque contacteur placé à l’avant gauche et droit dans la fonction qui détecte les obstacles via infra-rouge. Mais à la différence de IR sensor qui peut détecter l’obstacle dès une certain distance, le contacteur ne le détecte qu’au dernier moment.
Cette double détection diminue fortement le risque de ne pas détecter l’obstacle.
La connectivité entre les contacteurs et le chipKIT est la suivante:
#define ContactRightPin 37 // Contact sensor Right pin connected to digital pin J9-01 (PMD0/RE0)
#define ContactLeftPin 38 // Contact sensor Left pin connected to digital pin J8-18 (SCK1/IC3/PMCS2/PMA15/RD10)
Ecran LCD
Afin de mieux comprendre ce qui se passe quand le robot n’est plus relié au PC, j’ai ajouté un écran LCD qui affiche les infos importantes.
Cet écran LCD communique avec le PIC via l'interface I2C en utilisant la librairie standard Wire. On peut contrôler l’affichage en modifiant via le protocole I2C les registres de l’écran LCD.
L’adresse I2C est définie de la façon suivante :
LiquidCrystal_I2C lcd(0x20,16,2); // set the LCD address to 0x20 for a 16 chars and 2 line display
Vous pouvez consulter une description plus détaillée du fonctionnement de l’écran LCD dans ce document (en anglais)
DFR0063.doc 293 Ko
452 téléchargement(s)
La communication I2Cest identique à celle décrite précédemment pour le Compas.
Ci-dessous vous pouvez voir le LCD
Buzzer
J’ai également ajouté un buzzer que je fais « buzzer » dans certaines situations : Fin d’initialisation, détection d’obstacle, erreur.
Son fonctionnement est simple, il suffit d’activer pendant un certain temps une sortie de type digitale.
La connectivité entre le buzzer et le chipKIT est la suivante:
#define buzzPin 39 // Buzzer connected to digital pin J8-15(PMRD/CN14/RD5)
Vous pouvez consulter une description plus détaillée du fonctionnement du buzzer dans ce document (en anglais)
Digital Buzzer Module.doc 123 Ko
282 téléchargement(s)
Contrôle des moteurs
J'ai écrit une librairie qui gère la vitesse des 4 moteurs grâce aux encodeurs, la direction grâce au compas et la détection d'obstacles grâce au détecteur infra-rouge monté sur le servo.
Les fonctions de la lib sont les suivantes :
void IntrTickRight(); interrupt handler encoder right
void IntrTickLeft(); interrupt handler encoder right
int motor_begin(); initialize everything, must be called during setup
int get_TickRight(); get Tick Right
int get_TickLeft(); get Tick Left
int get_SpeedMotorRight(); get Speed Motor Right
int get_SpeedMotorLeft(); get Speed Motor Left
void forward(); set IN of the 4 motors in order to run clockwise
void forward_test(int num); set IN of the motor num in order to run clockwise
void start_forward(); call forward + set enable pin of the 4 motors to SPEEDNOMINAL
void start_forward_test(int num); call forward + set enable pin of the motor num to SPEEDNOMINAL
void backward(); set IN of the 4 motors in order to run anti-clockwise
void start_backward(); call backward +set enable pin of the 4 motors to SPEEDNOMINAL
void stop(); set IN of the 4 motors in order to stop
int accelerate (int motor); set enable pin of the corresponding motors to an higher value (1 increment)
int accelerate_n (int motor, int n); set enable pin of the corresponding motors to an higher value (n increments)
int deccelerate(int motor); set enable pin of the corresponding motors to a lower value
(1 decrement)
int deccelerate_n(int motor, int n); set enable pin of the corresponding motors to a lower value (n decrements)
int adjustMotor (int motor, int pid); Adjust the speed of the motor according the PID value
int go(int d, int pid_ind); go during d encoder ticks or before in case of obstacle detected by IR sensor. if pid_ind = 1 then use a PID method (calling adjustMotor) to control motors speed between left and right
int check_around(); move the servo used by the IR sensor in order to determine the direction without obstacle
int turn(double alpha, unsigned long timeout); turns with an angle before a delay (timeout) using a compass to get the direction
Robot contrôle
J’ai développé une application Java sous Eclipse qui peut envoyer des commandes au robot et afficher les informations retournées par le robot.
Comme décrit précédemment, elle peut utiliser la communication WIFI ou XBee.
Les commandes disponibles sont les suivantes :
START: Demande au robot de démarrer en avant à une vitesse de croisière.
STOP: Demande au robot de s’arrêter.
INFO: Affiche des infos en provenance du robot : status Start / Stop, vitesse théorique, vitesse réelle, , température, distance obstacle, direction.
PICTURE: Demande au robot de prendre une photo, de la sauvegarder sur la carte SD puis de la transmettre pour affichage via XBee ou WIFI.
TURN_RIGHT + angle: Demande au robot de tourner à droite d’un certain angle. Si l’angle = 180°, le robot fait marche arrière.
TURN_LEFT+ angle: Demande au robot de tourner à gaucke d’un certain angle. Si l’angle = 180°, le robot fait marche arrière.
CHECK_AROUND: Demande au robot de détermine la direction sans obstacle (devant, gauche ou droite)
MOVE_TILT_PAN + angle1 + angle2: Demande au robot de bouger le Tilt&Pan du capteur photo d’un certain angle horizontalement et verticalement.
GO + time: Demande au robot de démarrer en avant à une vitesse de croisière et le laisse autonome pour un certain temps.
Sources
Tous les sources sont dans Git:
les sources du Robot
les sources de la lib standard SD Card modifiée
les sources de l'application Java utilisée pour communiquer avec le Robot
Core ressources
Dans le but d’éviter tout conflit entre les différents composants du robot, il est important de connaitre en détail les ressources de base utilisées par chaque composant.
Voici un résumé avec quelques précisions sur l’utilisation de la ressource.
Enable 4 motors (analogwrite)
***********************************
use TMR2 and TIMER_OC1,TIMER_OC2, TIMER_OC3, TIMER_OC4, TIMER_OC5 to generate PWM
// If no PWM are currently active, then init Timer2
if (pwm_active == 0)
{
T2CON = T2_PS_1_256;
TMR2 = 0;
PR2 = PWM_TIMER_PERIOD;
T2CONSET = T2_ON;
}
//generate bit mask for this output compare
//should assert(timer < 8) here, but assertions aren't being used
pwm_mask = (1 << (timer - _TIMER_OC1));
//Obtain a pointer to the output compare being being used
//NOTE: as of 11/15/2011 All existing PIC32 devices
// (PIC32MX1XX/2XX/3XX/4XX/5XX/6XX/7XX) have the output compares
// at the same addresses. The base address is _OCMP1_BASE_ADDRESS
// and the distance between their addresses is 0x200.
ocp = (p32_oc *)(_OCMP1_BASE_ADDRESS + (0x200 * (timer - _TIMER_OC1)));
// If the requested PWM isn't active, init its output compare
if ((pwm_active & pwm_mask) == 0)
{
ocp->ocxR.reg = ((PWM_TIMER_PERIOD*val)/256);
ocp->ocxCon.reg = OC_TIMER2_SRC | OC_PWM_FAULT_PIN_DISABLE;
ocp->ocxCon.set = OC_ON;
pwm_active |= pwm_mask;
}
// Set the duty cycle register for the requested output compare
ocp->ocxRs.reg = ((PWM_TIMER_PERIOD*val)/256);
Encoders 2 motors
**********************
use interrupts INT3 and INT4
IEC0bits.INT3IE = 0;
IFS0bits.INT3IF = 0;
INTCONbits.INT3EP = edge;
IPC3bits.INT3IP = _INT3_IPL_IPC;
IPC3bits.INT3IS = _INT3_SPL_IPC;
IEC0bits.INT3IE = 1;
IEC0bits.INT4IE = 0;
IFS0bits.INT4IF = 0;
INTCONbits.INT4EP = edge;
IPC4bits.INT4IP = _INT4_IPL_IPC;
IPC4bits.INT4IS = _INT4_SPL_IPC;
IEC0bits.INT4IE = 1;
IR sensor
*************
use ADC module channel 2
/* Ensure that the pin associated with the analog channel is in analog
** input mode, and select the channel in the input mux.
*/
AD1PCFG = ~(1 << channelNumber);
AD1CHS = (channelNumber & 0xFFFF) << 16;
AD1CON1 = 0; //Ends sampling, and starts converting
//Set up for manual sampling
AD1CSSL = 0;
AD1CON3 = 0x0002; //Tad = internal 6 Tpb
AD1CON2 = analog_reference;
//Turn on ADC
AD1CON1SET = 0x8000;
//Start sampling
AD1CON1SET = 0x0002;
//Delay for a bit
delayMicroseconds(2);
//Start conversion
AD1CON1CLR = 0x0002;
//Wait for conversion to finish
while (!(AD1CON1 & 0x0001));
//Read the ADC Value
analogValue = ADC1BUF0
Compas
**********
use I2C module #5
Servos
********
use TIMER4 to create pulse
//timer 4 set clock period 20ms
T4CON = 0x0060; // set prescalar 1:64
TMR4 = 0;
PR4 = 0x61A8;
IFS0CLR = 0x10000;// Clear the T4 interrupt flag
IEC0SET = 0x10000;// Enable T4 interrupt
IPC4CLR = 0x0000001F;
IPC4SET = (_T4_IPL_IPC << 2) | _T4_SPL_IPC;
T4CONSET = 0x8000;// Enable Timer4
Xbee
******
use UART1 as the USB-PC connection
p32_regset * ipc; //interrupt priority control register set
int irq_shift;
/* Initialize the receive buffer.
*/
flush();
/* Compute the address of the interrupt priority control
** registers used by this UART
*/
ipc = ((p32_regset *)&IPC0) + (vec / 4); //interrupt priority control reg set
/* Compute the number of bit positions to shift to get to the
** correct position for the priority bits for this IRQ.
*/
irq_shift = 8 * (vec % 4);
/* Set the interrupt privilege level and sub-privilege level
*/
ipc->clr = (0x1F << irq_shift);
ipc->set = ((ipl << 2) + spl) << irq_shift;
/* Clear the interrupt flags, and set the interrupt enables for the
** interrupts used by this UART.
*/
ifs->clr = bit_rx + bit_tx + bit_err; //clear all interrupt flags
iec->clr = bit_rx + bit_tx + bit_err; //disable all interrupts
iec->set = bit_rx; //enable rx interrupts
/* Initialize the UART itself.
*/
// http://www.chipkit.org/forum/viewtopic.php?f=7&t=213&p=948#p948
uart->uxBrg.reg = ((__PIC32_pbClk / 16 / baudRate) - 1); // calculate actual BAUD generate value.
uart->uxSta.reg = 0;
uart->uxMode.reg = (1 << _UARTMODE_ON); //enable UART module
uart->uxSta.reg = (1 << _UARTSTA_UTXEN) + (1 << _UARTSTA_URXEN); //enable transmitter and receiver
Camera
*********
use UART2
p32_regset * ipc; //interrupt priority control register set
int irq_shift;
/* Initialize the receive buffer.
*/
flush();
/* Compute the address of the interrupt priority control
** registers used by this UART
*/
ipc = ((p32_regset *)&IPC0) + (vec / 4); //interrupt priority control reg set
/* Compute the number of bit positions to shift to get to the
** correct position for the priority bits for this IRQ.
*/
irq_shift = 8 * (vec % 4);
/* Set the interrupt privilege level and sub-privilege level
*/
ipc->clr = (0x1F << irq_shift);
ipc->set = ((ipl << 2) + spl) << irq_shift;
/* Clear the interrupt flags, and set the interrupt enables for the
** interrupts used by this UART.
*/
ifs->clr = bit_rx + bit_tx + bit_err; //clear all interrupt flags
iec->clr = bit_rx + bit_tx + bit_err; //disable all interrupts
iec->set = bit_rx; //enable rx interrupts
/* Initialize the UART itself.
*/
// http://www.chipkit.org/forum/viewtopic.php?f=7&t=213&p=948#p948
uart->uxBrg.reg = ((__PIC32_pbClk / 16 / baudRate) - 1); // calculate actual BAUD generate value.
uart->uxSta.reg = 0;
uart->uxMode.reg = (1 << _UARTMODE_ON); //enable UART module
uart->uxSta.reg = (1 << _UARTSTA_UTXEN) + (1 << _UARTSTA_URXEN); //enable transmitter and receiver
SD-Card
**********
use SPI module and pin 4 for SS/CS
SPI2CON = 0;
DDPCONbits.JTAGEN = 0;
AD1PCFG = 0xFFFF;
chipSelectPin_ = chipSelectPin;
pinMode(chipSelectPin_, OUTPUT);
PORTSetPinsDigitalOut(prtSCK, bnSCK);
PORTSetPinsDigitalOut(prtSDO, bnSDO);
PORTSetPinsDigitalIn(prtSDI, bnSDI);
// set pin modes
chipSelectHigh();
// must supply min of 74 clock cycles with CS high.
for (uint8_t i = 0; i < 10; i++) spiSend(0XFF);
chipSelectLow();
// command to go idle in SPI mode
while ((status_ = cardCommand(CMD0, 0)) != R1_IDLE_STATE) {
if (((uint16_t)millis() - t0) > SD_INIT_TIMEOUT) {
error(SD_CARD_ERROR_CMD0);
goto fail;
}
}
// check SD version
if ((cardCommand(CMD8, 0x1AA) & R1_ILLEGAL_COMMAND)) {
type(SD_CARD_TYPE_SD1);
} else {
// only need last byte of r7 response
for (uint8_t i = 0; i < 4; i++) {
status_ = spiRec();
}
if (status_ != 0XAA) {
error(SD_CARD_ERROR_CMD8);
goto fail;
}
type(SD_CARD_TYPE_SD2);
}
// initialize card and send host supports SDHC if SD2
arg = type() == SD_CARD_TYPE_SD2 ? 0X40000000 : 0;
while ((status_ = cardAcmd(ACMD41, arg)) != R1_READY_STATE) {
// check for timeout
if (((uint16_t)millis() - t0) > SD_INIT_TIMEOUT) {
error(SD_CARD_ERROR_ACMD41);
goto fail;
}
}
// if SD2 read OCR register to check for SDHC card
if (type() == SD_CARD_TYPE_SD2) {
if (cardCommand(CMD58, 0)) {
error(SD_CARD_ERROR_CMD58);
goto fail;
}
if ((spiRec() & 0XC0) == 0XC0) {
type(SD_CARD_TYPE_SDHC);
}
// discard rest of ocr - contains allowed voltage range
for (uint8_t i = 0; i < 3; i++) spiRec();
}
chipSelectHigh();
WIFI
******
use SPI module and pin 10 for SS/CS + INT1
Max32
Le chipKIT ™ Max32 ™ est basé sur la plate-forme Arduino ™ mais il ajoute la performance du PIC32 Microchip. Le Max32 est compatible avec de nombreux Arduino ™ shields. Il dispose d'une interface série USB pour la connexion à l'IDE et peut être alimenté via USB ou une alimentation externe.
Le Max32 tire parti de la puissance du microcontrôleur PIC32MX795F512. Ce microcontrôleur dispose d'un noyau 32 bits MIPS cadencé à 80Mhz, 512K de mémoire Flash et 128K de mémoire de données SRAM. En outre, le processeur fournit un contrôleur USB 2, un contrôleur 10/100 Ethernet MAC et CAN qui peuvent être accessibles via des shields I/O.
Le Max32 peut être programmé à l'aide d'un environnement basé sur l'original IDE Arduino modifié pour supporter PIC32. En outre, le Max32 est entièrement compatible avec Microchip MPLAB IDE et le système de PICKit3 programmateur / débogueur
A noter qu’au départ j’ai utilisé le chipKIT ™ Uno32 ™ mais je suis arrivé à la limite de la mémoire flash de programme (128K) lorsque j'ai ajouté les libs TCP et WIFI, j'ai alors du migrer vers le chipKIT ™ Max32 ™ qui possède 512K de mémoire flash de programme.
Plus d'infos sur chipKIT ™ Max32 ™ dans la doc
chipKIT Max32_rm.pdf 732,4 Ko
293 téléchargement(s) Quatre roues motrices
J'utilise l'engin quatre roues motrices de DFRobot avec 2 capteurs encodeur afin de récupérer la vitesse des deux moteurs avant droite et gauche. Ceci est utile pour contrôler la direction et la mise en œuvre d'un Processus PID. Le montage des capteurs est décrit dans la doc
installation-method-fit0029.pdf 187,26 Ko
311 téléchargement(s).Attention, il y a un défaut de conception dans le montage des encodeurs car ils frottent
Par conséquent, on est obligé de rajouter un écrou sur la visse qui fixe l'encodeur afin que le disque ne frotte pas dessus lors de sa rotation.
Ci-dessous un gros plan sur les 2 roues avant équipées chacune d'un encodeur
Les spécifications sont les suivantes:
- Poids de la machine complète: 614g
- Diamètre de roue: 65mm
- Plus grande vitesse: 61cm / s
Caractéristiques du moteur:
- Rapport d'engrenage: 1:120
- Vitesse à vide (3V): 100t/min
- Vitesse à vide (6V): 200rpm
- Courant à vide (3V): 60mA
- Courant à vide (6V): 71mA
- Courant de décrochage (3V): 260mA
- Courant à l'arrêt (6V): 470mA
- Couple(3V): 1.2Kgcm
- Couple (6V): 1.92Kgcm
- Poids: 45g
Power
J'utilise un bloc de 5 piles AA 1,5 V pour un total de 7,5 V pour alimenter le chipKIT Max32 via le connecteur d'alimentation externe.
Le chipKIT Max32 délivre en sortie une tension régulée de 3V et 5V qui permettent d’alimenter les autres composants : servos, capteur IR, boussole ... à l'exception des moteurs qui sont alimentés par une batterie Lipo 2S 7.4V 350mAh
Déparasitage des moteurs
Les moteurs utilisés ne sont pas brushless, c'est a dire qu'ils sont constitués de charbons qui transmettent le courant au rotor (partie tournante du moteur) et qui frottent sur un induit. Ce frottement produit des étincelles qui engendrent des courants parasites.
Pour supprimer ces courants, j'ai ajouté un condensateur de 100 nF non polarisé (type céramique) entre les 2 bornes du moteur afin d'intercepter ces courants parasites. On peut également ajouter 2 autres condensateurs de plus faible capacité (10 nF) entre chacune des bornes et la carcasse métallique.
Dans tous les cas, les condensateurs doivent être soudés au plus prêt des bornes pour des raisons d'efficacité
H-Bridge
Un micro contrôleur est incapable de fournir le courant nécessaire à un moteur, s'est pourquoi il faut toujours un étage de puissance avant les moteurs.
La vitesse d'un moteur électrique n'est pas proportionnelle à la tension électrique à ses bornes. Le moteur demande une tension minimale assez importante pour démarrer. Si cette dernière est trop basse, les forces électromagnétiques ne sont pas suffisantes pour combattre le frottement. Il devient donc difficile d'ajuster la vitesse de façon précise.
La solution à ce problème est astucieuse. Il suffit de fournir au moteur une tension qui est toujours la même soit la tension maximale! Par contre, cette tension ne sera appliquée que par très courtes périodes de temps. En ajustant la longueur de ces périodes de temps, on arrive à faire avancer plus ou moins vite les moteurs. Mieux, on remarque que la vitesse des moteurs devient proportionnelle à la longueur des périodes de temps. Contrôler la longueur des périodes passées à la tension maximale par rapport au temps passé sans application de tension (tension nulle) est donc le cœur de la solution. En réalité, cette solution est fort connue en contrôle des systèmes et en électronique et elle porte le nom de PWM (Pulse Width Modulation).
Un signal PWM n'est pas généré par un pont en H. Par contre, le fait qu'un pont en H soit constitué de transistors le rend particulièrement apte à être contrôlé par un signal PWM. On doit donc voir le couple PWM et pont en H comme un outil particulièrement efficace pour contrôler des moteurs électriques
Il existe plusieurs modèles de ponts en H, j'ai choisi le L298N, car il permet jusqu'à 4A et aussi parce que DF Robot propose un module prêt à l'utilisation de ce circuit, nommé 2A Dual Motor Controller. J'ai d'abord utilisé le L293D qui est aussi un bon choix, mais limité à 1A. Comme j'ai eu beaucoup de problèmes avec mes soudures, j’ai préféré un circuit déjà monté.
Plus d'infos sur le L298N dans la doc
l298n-motor-driver-datasheet.pdf 449,63 Ko
229 téléchargement(s)et sur 2A Dual Motor Controller dans la doc
DFROBOT Motor Controller.doc 170,5 Ko
299 téléchargement(s)Un L298N est utilisé pour contrôler 2 moteurs, donc j'utilise 2 L298 pour contrôler le robot.Ils sont alimentés par une batterie Lipo 2S 7.4V 350mAh pour les 2 types de tensions, logique et moteur.
La façon de contrôler le moteur est la suivante:
- Enable pin permet de gérer la puissance du moteur. Comme expliqué précédemment, il reçoit un signal PWM.
- IN1 et IN2 pins du L298 sont utilisés pour gérer la direction du moteur. Le 2A Dual Motor Controller intègre plusieurs portes NAND afin de combiner IN1 et IN2. Donc à la fin, un sel pin IN est nécessaire pour contrôler la direction.
Les pins IN sont connectés aux digital pins standard de chipKIT tandis les Enable pins sont connectées aux pins PWM de chipKIT qui utilisent les fonctions analogWrite () qui s'appuient sur les timers Oci:
#define InMotorRight1Pin 30 // In pin of Motor controller #1 for motor right #1
connected to digital pin J9-08(PMD7/RE7)
#define EnableMotorRight1Pin 3 // Enable pin of Motor controller #1 for motor right #1
connected to PWM pin J14-07(SDO1/OC1/INT0/RD0) Use TIMER_OC1
#define InMotorRight2Pin 31 // In pin of Motor controller #1 for motor right #2
connected to digital pin J9-07(PMD6/RE6)
#define EnableMotorRight2Pin 5 // Enable pin of Motor controller #1 for motor right #2
connected to PWM pin J14-11(OC2/RD1) Use TIMER_OC2
#define InMotorLeft1Pin 32 // In pin of Motor controller #2 for motor left #1
connected to digital pin J9-06(PMD5/RE5)
#define EnableMotorLeft1Pin 6 // Enable pin of Motor controller #2 for motor left #1
connected to PWM pin J14-13(OC3/RD2) Use TIMER_OC3
#define InMotorLeft2Pin 33 // In pin of Motor controller #2 for motor left #2
connected to digital pin J9-05(PMD4/RE4)
#define EnableMotorLeft2Pin 9 // Enable pin of Motor controller #2 for motor left #2
connected to PWM pin J3-03(OC4/RD3) Use TIMER_OC4
Encodeurs
Les 2 capteurs encodeur montés sur les deux moteurs avant droite et gauche permettent de calculer la vitesse des moteurs.
Ils sont connectés aux pins d’interruptions INT3 et INT4 du Chipkit ce qui permet de connaitre à tout instant le nombre de ticks réalisé par chaque moteur. Un encodeur génère 20 changements de tension par tour lesquels déclenchent par conséquent 20 interruptions par tour. J’utilise les pins INT3 et INT4 du PIC pour gérer les interruptions de manière hardware afin de ne pas pénaliser la cpu. Attention de bien définir les pins en input avant d’appeler la fonction attachInterrupt() pour configurer l’interruption.
Vous pouvez consulter une description plus détaillée du fonctionnement des encodeurs dans ce document (en anglais)
Wheel Encoders for DFRobot 3PA and 4WD Rovers.doc 178,5 Ko
292 téléchargement(s)La connexion entre les deux Encodeurs et la chipKIT est la suivante:
#define EncoderTickRightINT 4 // INT used by the encoder for motor right
connected to interrupt pin INT4 J4-02(AETXEN/SDA1/INT4/RA15) Use INT4
#define EncoderTickLeftINT 3 // INT used by the encoder for motor left
connected to interrupt pin INT3 J4-01(AETXCLK/SCL1/INT3/RA14) Use INT3
Détecteur Infra-rouge
Un détecteur Infra-Rouge GP2Y0A21YK permet de détecter les obstacles. Il est connecté sur un des pins analogic du Chipkit afin d’utiliser la fonction analogread() qui permet de convertir une tension en une valeur entre 0 et 255 grâce au module ADC du PIC.
Ce nombre est ensuite converti en cm en se basant sur l’abaque fournie pour une tension de 3V dans le datasheet du GP2Y0A21YK
GP2Y0A21YK-DATA-SHEET.PDF 277,83 Ko
218 téléchargement(s)Notez que vous pouvez également utiliser une tension de 5V mais vous perdez en précision.
Vous pouvez consulter une description plus détaillée du fonctionnement des détecteurs Sharp dans ce document (en anglais)
IR SHARP.doc 322 Ko
239 téléchargement(s)La connexion entre le capteur infrarouge et le chipKIT est la suivante:
#define GP2Y0A21YK_Pin 54 // IR sensor GP2Y0A21YK analogic pin J5-01 A0
(PGED1/AN0/CN2/RB0) Use ADC module channel 2
/* Analogic interface is provided on pin V0 */
/* Power +3V is set on pin VCC */
/* Ground is set on pin GND */
Servo IR
Le détecteur Infra-Rouge GP2Y0A21YK est monté sur un Servo afin de pouvoir déterminer les obstacles dans différentes directions, en particulier droit devant, à droite et à gauche.
Le servo est commandé par des impulsions de période 20 ms et de largeur comprises entre 1 et 2 ms. Ces impulsions sont gérées par la lib software PWM ce qui permet de gérer plusieurs servo en monopolisant seulement un des timers du PIC.
Vous pouvez consulter une description plus détaillée du fonctionnement des servos dans ce document
Servomoteurs.doc 50 Ko
238 téléchargement(s)La connectivité entre le servo IR et la chipKIT est la suivante:
#define IRSERVO_Pin 36 // IR Servo pin connected to digital pin J9-02 (PMD1/RE1)
/* Power +5V */
/* Ground */
Compas
Un compas CMPS03 est connecté afin d’indiquer la direction.
Ce compas communique avec le PIC via l'interface I2C en utilisant la librairie standard Wire. On peut connaitre la direction en interrogeant via le protocole I2C les registres du Compas.
L’adresse I2C est définie de la façon suivante :
#define CMPS03_ADDRESS 0x60 //1100000: compass address 0XC0 on 7 bits for I2c protocol
Après plusieurs essais, j’ai disposé le compas loin du socle métallique du robot, des moteurs et des servos car il fournissait des résultats complètement erronés. Attention également à le mettre horizontalement pour une meilleure précision.
Vous pouvez consulter une description plus détaillée du fonctionnement du Compas dans ce document (en anglais)
CMPS03.doc 148,5 Ko
224 téléchargement(s) Le chipKIT Max32 gère 5 Interfaces I2C maximum mais la librairie standard Wire n’en gère qu’une. Par défaut, cette lib utilise le I2C1 mais je ne peux pas utiliser cette interface parce que les pins correspondants sont partagés avec INT3 et INT4 qui sont requis par les encodeurs. Alors, j'ai mis à jour le fichier Board_Defs.h afin d’utiliser l'interface I2C5 au lieu de I2C1.
#define _TWI_BASE _I2C2_BASE_ADDRESS
#define _TWI_BUS_IRQ _I2C2_BUS_IRQ
#define _TWI_SLV_IRQ _I2C2_SLAVE_IRQ
#define _TWI_MST_IRQ _I2C2_MASTER_IRQ
#define _TWI_VECTOR I2C_2_VECTOR
#define _TWI_IPL_ISR _I2C2_IPL_ISR
#define _TWI_IPL _I2C2_IPL_IPC
#define _TWI_SPL _I2C2_SPL_IPC
En outre, j'ai relié les pins SDA et SCL à +5 V via une résistance de pull-up de 1K indispensable pour gérer le bus avec le protocole I2C.
La connexion entre le compas et le chipKIT est la suivante:
/* Compass */
/* I2C interface is provided on pins: */
/* 1 = Power +5V */
/* 2 = SCL connected to J3-09 (SCL2/RA2) */
/* 3 = SDA connected to J3-11 (SDA2/RA3) */
/* 9 = Ground */
Capteur de température
Un capteur de température TMP102 est connecté afin d’indiquer la température.
Ce capteur de température communique avec le PIC via l'interface I2C en utilisant la librairie standard Wire. On peut connaitre la température en interrogeant via le protocole I2C les registres du capteur.
L’adresse I2C est définie de la façon suivante :
#define TMP102_ADDRESS 0x48 //1001000: temperature sensor address 0X90 on 7 bits for I2c protocol
La communication I2C est identique à celle décrite précédemment pour le Compas.
Vous pouvez consulter une description plus détaillée du fonctionnement du capteur de température dans ce document (en anglais)
tmp102.pdf 459,52 Ko
207 téléchargement(s)Capteur photo
Un capteur photo JPEG Serial LS-Y201 est embarqué sur le robot.
Ce capteur communique avec le PIC via l'interface UART2 à 38400 bauds à l'aide de la standard Serial library. J’ai dédié UART2 à ce composant afin d'éviter tout conflit avec d'autres interfaces série (log, XBee ...).
Le capteur nécessite une procédure d'initialisation spécifique:
- Suppression de toutes les données actuellement dans la mémoire tampon du bus série
- Envoyer la commande RESET_CAMERA
- Attendre la réponse de la caméra qui contient plusieurs données telles que le numéro de révision et se termine par “Init end\x0d\x0a”"
- Attendre 3 secondes
La façon de faire une image est la suivante:
- Envoyer la commande TAKE_PICTURE afin de demander au capteur de prendre l'image et de la stocker au format JPEG dans sa mémoire.
- Envoyer la commande GET_SIZE afin d'obtenir la taille de l'image actuellement stockée dans la mémoire du capteur.
- Envoyer la commande GET_DATA afin de lire les données de la mémoire du capteur. Elles sont lues par blocs de 32 octets, puis stockées dans un fichier sur une carte SD. La fin du fichier est détectée à la réception des octets 0xFF et 0xD9 (standard JPEG fichier EOF).
Une fois que l'image est stockée sur la carte SD, il est possible de la transmettre plus tard à n'importe quel client via XBee ou Wifi. Il est possible de ne pas utiliser une SD-Card et de publier directement l'image en temps réel mais c’est plus complexe a cause de la synchronisation de la communication entre le capteur photo et le client XBee / Wifi.
Par ailleurs, ce capteur est monté sur un Tilt & Pan dirigé par 2 servos afin de permettre des mouvements horizontaux et verticaux pour pouvoir prendre des photos sous différents angles.
Plus d'infos sur le capteur photo dans la doc
LinkSprite JPEG Color Camera Serial LS-Y201 User manualv1.1.pdf 398,26 Ko
197 téléchargement(s)La connexion entre la caméra et la chipKIT est la suivante:
/* Camera */
/* UART2 interface is provided on pins: */
/* 1 = Power +5V */
/* 2 = TX connected to J4-04 (AETXD1/SCK1A/U1BTX/U1ARTS/CN21/RD15)*/
/* 3 = RX connected to J4-03 (AETXD0/SS1A/U1BRX/U1ACTS/CN20/RD14) */
/* 4 = Ground */
Tilt&Pan servos
Le capteur photo est monté sur un Tilt & Pan dirigé par 2 servos afin de permettre des mouvements horizontaux et verticaux.
Ces servos sont gérés comme le Servo IR.
Plus d'infos sur le montage du Tilt&Pan dans la doc
Pan&Tilt assembly instructions.doc 86 Ko
212 téléchargement(s)La connectivité entre Tilt & Pan servos et le chipKIT est la suivante:
#define HSERVO_Pin 34 // Horizontal Servo pin connected to digital pin J9-04 (PMD3/RE3)
/* Power +5V */
/* Ground */
#define VSERVO_Pin 35 // Vertical Servo pin connected to digital pin J9-03 (PMD2/RE2)
/* Power +5V */
/* Ground */
Ci-dessous vous pouvez voir la Camera montée sur Tilt & Pan et en dessous le IR sensor monté sur un servo
SD-Card
La SD-Card est utilisée pour stocker les images prises par l’capteur photo.
La SD-Card communique avec le PIC via l'interface SPI.
ATTENTION: il y a un conflit entre la SD-Card et WIFI comme l’a indiqué KeithV de Diligent. Le problème est que le Wifi et la SD-Card partagent le même port SPI et le module Wifi est également connecté à INT1 sur le WiFiShield. Si vous lisez la SD-Card lorsque le Wifi génère une interruption, le PIC va activer le CS du module Wifi et les deux dispositifs SPI Wifi et SD seront donc actifs simultanément. Suite à la proposition de KeithV, j'ai modifié la lib SD-Card standard afin de désactiver INT1 lors de la lecture / écriture de la SD-Card.
Communication
Le robot peut communiquer en utilisant XBee ou WIFI.
J'ai écrit une petite interface Java pour communiquer avec le robot avec ces deux protocoles, mais un seul mode est disponible à un moment donné parce que cela dépend du shield utilisé.
XBee Communication
WIFI Communication
J'utilise le chipKIT Wifi Shield ™ qui est basé sur le module Wifi Microchip MRF24WB0MA.
Il communique avec le PIC via SPI et il utilise également INT1 (attention voir les conflits dans la section SD-Card.).
Il est conçu pour être utilisé avec les bibliothèques réseau Digilent, DNETcK et DWIFIcK. Attention ces lib sont conséquentes (60K), c'est la raison pour laquelle j'ai migré de Uno à Max.
J'ai utilisé ces bibliothèques pour construire un mini serveur HTTP qui écoute sur un port et établit une connexion si un client tente de se connecter. Ensuite, le message reçu est analysé afin de déterminer la commande et les paramètres optionnels. J’ai défini le format suivant pour le message:
Cmd = & param = param1, param2;
où est la commande requise et param1, param 2 .. sont les paramètres optionnels avec ";" comme séparateur. CMD et PARAM sont les deux mots-clés.
Une fois que la commande est traitée par le robot, il répond avec le format suivant (Content-Type: text / html):
Champ 0: value0; Champ 1: valeur1;
où value0, valeur1 sont les réponses optionnelles avec ";" comme séparateur. Champ est un mot clé.
En cas de commande qui déclenche une image, la réponse se compose du flux d'octets (Content-Type: application / flux d'octets) qui représentent le contenu du fichier JPEG.
Plus d'infos sur le shield WIFI dans la doc
chipKIT WiFi Shield.pdf 194,34 Ko
235 téléchargement(s)Contacteurs
Les premiers essais avec le IR sensor comme seul détecteur d’obstacle ont montrés des limites, comme par exemple dans le cas d’obstacles au ras du sol qui ne sont pas détectés.
C’est pourquoi j’ai ajouté 2 contacteurs équipés de « moustache » qle.ui indiquent le contact avec un obstacle.
Le principe est simple, dès que le contacteur rencontre un obstacle, son pin Signal pase de l’état haut à l’état bas.
J’ai donc ajouté le contrôle de l’état du pin de chaque contacteur placé à l’avant gauche et droit dans la fonction qui détecte les obstacles via infra-rouge. Mais à la différence de IR sensor qui peut détecter l’obstacle dès une certain distance, le contacteur ne le détecte qu’au dernier moment.
Cette double détection diminue fortement le risque de ne pas détecter l’obstacle.
La connectivité entre les contacteurs et le chipKIT est la suivante:
#define ContactRightPin 37 // Contact sensor Right pin connected to digital pin J9-01 (PMD0/RE0)
#define ContactLeftPin 38 // Contact sensor Left pin connected to digital pin J8-18 (SCK1/IC3/PMCS2/PMA15/RD10)
Ecran LCD
Afin de mieux comprendre ce qui se passe quand le robot n’est plus relié au PC, j’ai ajouté un écran LCD qui affiche les infos importantes.
Cet écran LCD communique avec le PIC via l'interface I2C en utilisant la librairie standard Wire. On peut contrôler l’affichage en modifiant via le protocole I2C les registres de l’écran LCD.
L’adresse I2C est définie de la façon suivante :
LiquidCrystal_I2C lcd(0x20,16,2); // set the LCD address to 0x20 for a 16 chars and 2 line display
Vous pouvez consulter une description plus détaillée du fonctionnement de l’écran LCD dans ce document (en anglais)
DFR0063.doc 293 Ko
452 téléchargement(s) La communication I2Cest identique à celle décrite précédemment pour le Compas.
Ci-dessous vous pouvez voir le LCD
Buzzer
J’ai également ajouté un buzzer que je fais « buzzer » dans certaines situations : Fin d’initialisation, détection d’obstacle, erreur.
Son fonctionnement est simple, il suffit d’activer pendant un certain temps une sortie de type digitale.
La connectivité entre le buzzer et le chipKIT est la suivante:
#define buzzPin 39 // Buzzer connected to digital pin J8-15(PMRD/CN14/RD5)
Vous pouvez consulter une description plus détaillée du fonctionnement du buzzer dans ce document (en anglais)
Digital Buzzer Module.doc 123 Ko
282 téléchargement(s)Contrôle des moteurs
J'ai écrit une librairie qui gère la vitesse des 4 moteurs grâce aux encodeurs, la direction grâce au compas et la détection d'obstacles grâce au détecteur infra-rouge monté sur le servo.
Les fonctions de la lib sont les suivantes :
void IntrTickRight(); interrupt handler encoder right
void IntrTickLeft(); interrupt handler encoder right
int motor_begin(); initialize everything, must be called during setup
int get_TickRight(); get Tick Right
int get_TickLeft(); get Tick Left
int get_SpeedMotorRight(); get Speed Motor Right
int get_SpeedMotorLeft(); get Speed Motor Left
void forward(); set IN of the 4 motors in order to run clockwise
void forward_test(int num); set IN of the motor num in order to run clockwise
void start_forward(); call forward + set enable pin of the 4 motors to SPEEDNOMINAL
void start_forward_test(int num); call forward + set enable pin of the motor num to SPEEDNOMINAL
void backward(); set IN of the 4 motors in order to run anti-clockwise
void start_backward(); call backward +set enable pin of the 4 motors to SPEEDNOMINAL
void stop(); set IN of the 4 motors in order to stop
int accelerate (int motor); set enable pin of the corresponding motors to an higher value (1 increment)
int accelerate_n (int motor, int n); set enable pin of the corresponding motors to an higher value (n increments)
int deccelerate(int motor); set enable pin of the corresponding motors to a lower value
(1 decrement)
int deccelerate_n(int motor, int n); set enable pin of the corresponding motors to a lower value (n decrements)
int adjustMotor (int motor, int pid); Adjust the speed of the motor according the PID value
int go(int d, int pid_ind); go during d encoder ticks or before in case of obstacle detected by IR sensor. if pid_ind = 1 then use a PID method (calling adjustMotor) to control motors speed between left and right
int check_around(); move the servo used by the IR sensor in order to determine the direction without obstacle
int turn(double alpha, unsigned long timeout); turns with an angle before a delay (timeout) using a compass to get the direction
Robot contrôle
J’ai développé une application Java sous Eclipse qui peut envoyer des commandes au robot et afficher les informations retournées par le robot.
Comme décrit précédemment, elle peut utiliser la communication WIFI ou XBee.
Les commandes disponibles sont les suivantes :
START: Demande au robot de démarrer en avant à une vitesse de croisière.
STOP: Demande au robot de s’arrêter.
INFO: Affiche des infos en provenance du robot : status Start / Stop, vitesse théorique, vitesse réelle, , température, distance obstacle, direction.
PICTURE: Demande au robot de prendre une photo, de la sauvegarder sur la carte SD puis de la transmettre pour affichage via XBee ou WIFI.
TURN_RIGHT + angle: Demande au robot de tourner à droite d’un certain angle. Si l’angle = 180°, le robot fait marche arrière.
TURN_LEFT+ angle: Demande au robot de tourner à gaucke d’un certain angle. Si l’angle = 180°, le robot fait marche arrière.
CHECK_AROUND: Demande au robot de détermine la direction sans obstacle (devant, gauche ou droite)
MOVE_TILT_PAN + angle1 + angle2: Demande au robot de bouger le Tilt&Pan du capteur photo d’un certain angle horizontalement et verticalement.
GO + time: Demande au robot de démarrer en avant à une vitesse de croisière et le laisse autonome pour un certain temps.
Sources
Tous les sources sont dans Git:
les sources du Robot
les sources de la lib standard SD Card modifiée
les sources de l'application Java utilisée pour communiquer avec le Robot
Core ressources
Dans le but d’éviter tout conflit entre les différents composants du robot, il est important de connaitre en détail les ressources de base utilisées par chaque composant.
Voici un résumé avec quelques précisions sur l’utilisation de la ressource.
Enable 4 motors (analogwrite)
***********************************
use TMR2 and TIMER_OC1,TIMER_OC2, TIMER_OC3, TIMER_OC4, TIMER_OC5 to generate PWM
// If no PWM are currently active, then init Timer2
if (pwm_active == 0)
{
T2CON = T2_PS_1_256;
TMR2 = 0;
PR2 = PWM_TIMER_PERIOD;
T2CONSET = T2_ON;
}
//generate bit mask for this output compare
//should assert(timer < 8) here, but assertions aren't being used
pwm_mask = (1 << (timer - _TIMER_OC1));
//Obtain a pointer to the output compare being being used
//NOTE: as of 11/15/2011 All existing PIC32 devices
// (PIC32MX1XX/2XX/3XX/4XX/5XX/6XX/7XX) have the output compares
// at the same addresses. The base address is _OCMP1_BASE_ADDRESS
// and the distance between their addresses is 0x200.
ocp = (p32_oc *)(_OCMP1_BASE_ADDRESS + (0x200 * (timer - _TIMER_OC1)));
// If the requested PWM isn't active, init its output compare
if ((pwm_active & pwm_mask) == 0)
{
ocp->ocxR.reg = ((PWM_TIMER_PERIOD*val)/256);
ocp->ocxCon.reg = OC_TIMER2_SRC | OC_PWM_FAULT_PIN_DISABLE;
ocp->ocxCon.set = OC_ON;
pwm_active |= pwm_mask;
}
// Set the duty cycle register for the requested output compare
ocp->ocxRs.reg = ((PWM_TIMER_PERIOD*val)/256);
Encoders 2 motors
**********************
use interrupts INT3 and INT4
IEC0bits.INT3IE = 0;
IFS0bits.INT3IF = 0;
INTCONbits.INT3EP = edge;
IPC3bits.INT3IP = _INT3_IPL_IPC;
IPC3bits.INT3IS = _INT3_SPL_IPC;
IEC0bits.INT3IE = 1;
IEC0bits.INT4IE = 0;
IFS0bits.INT4IF = 0;
INTCONbits.INT4EP = edge;
IPC4bits.INT4IP = _INT4_IPL_IPC;
IPC4bits.INT4IS = _INT4_SPL_IPC;
IEC0bits.INT4IE = 1;
IR sensor
*************
use ADC module channel 2
/* Ensure that the pin associated with the analog channel is in analog
** input mode, and select the channel in the input mux.
*/
AD1PCFG = ~(1 << channelNumber);
AD1CHS = (channelNumber & 0xFFFF) << 16;
AD1CON1 = 0; //Ends sampling, and starts converting
//Set up for manual sampling
AD1CSSL = 0;
AD1CON3 = 0x0002; //Tad = internal 6 Tpb
AD1CON2 = analog_reference;
//Turn on ADC
AD1CON1SET = 0x8000;
//Start sampling
AD1CON1SET = 0x0002;
//Delay for a bit
delayMicroseconds(2);
//Start conversion
AD1CON1CLR = 0x0002;
//Wait for conversion to finish
while (!(AD1CON1 & 0x0001));
//Read the ADC Value
analogValue = ADC1BUF0
Compas
**********
use I2C module #5
Servos
********
use TIMER4 to create pulse
//timer 4 set clock period 20ms
T4CON = 0x0060; // set prescalar 1:64
TMR4 = 0;
PR4 = 0x61A8;
IFS0CLR = 0x10000;// Clear the T4 interrupt flag
IEC0SET = 0x10000;// Enable T4 interrupt
IPC4CLR = 0x0000001F;
IPC4SET = (_T4_IPL_IPC << 2) | _T4_SPL_IPC;
T4CONSET = 0x8000;// Enable Timer4
Xbee
******
use UART1 as the USB-PC connection
p32_regset * ipc; //interrupt priority control register set
int irq_shift;
/* Initialize the receive buffer.
*/
flush();
/* Compute the address of the interrupt priority control
** registers used by this UART
*/
ipc = ((p32_regset *)&IPC0) + (vec / 4); //interrupt priority control reg set
/* Compute the number of bit positions to shift to get to the
** correct position for the priority bits for this IRQ.
*/
irq_shift = 8 * (vec % 4);
/* Set the interrupt privilege level and sub-privilege level
*/
ipc->clr = (0x1F << irq_shift);
ipc->set = ((ipl << 2) + spl) << irq_shift;
/* Clear the interrupt flags, and set the interrupt enables for the
** interrupts used by this UART.
*/
ifs->clr = bit_rx + bit_tx + bit_err; //clear all interrupt flags
iec->clr = bit_rx + bit_tx + bit_err; //disable all interrupts
iec->set = bit_rx; //enable rx interrupts
/* Initialize the UART itself.
*/
// http://www.chipkit.org/forum/viewtopic.php?f=7&t=213&p=948#p948
uart->uxBrg.reg = ((__PIC32_pbClk / 16 / baudRate) - 1); // calculate actual BAUD generate value.
uart->uxSta.reg = 0;
uart->uxMode.reg = (1 << _UARTMODE_ON); //enable UART module
uart->uxSta.reg = (1 << _UARTSTA_UTXEN) + (1 << _UARTSTA_URXEN); //enable transmitter and receiver
Camera
*********
use UART2
p32_regset * ipc; //interrupt priority control register set
int irq_shift;
/* Initialize the receive buffer.
*/
flush();
/* Compute the address of the interrupt priority control
** registers used by this UART
*/
ipc = ((p32_regset *)&IPC0) + (vec / 4); //interrupt priority control reg set
/* Compute the number of bit positions to shift to get to the
** correct position for the priority bits for this IRQ.
*/
irq_shift = 8 * (vec % 4);
/* Set the interrupt privilege level and sub-privilege level
*/
ipc->clr = (0x1F << irq_shift);
ipc->set = ((ipl << 2) + spl) << irq_shift;
/* Clear the interrupt flags, and set the interrupt enables for the
** interrupts used by this UART.
*/
ifs->clr = bit_rx + bit_tx + bit_err; //clear all interrupt flags
iec->clr = bit_rx + bit_tx + bit_err; //disable all interrupts
iec->set = bit_rx; //enable rx interrupts
/* Initialize the UART itself.
*/
// http://www.chipkit.org/forum/viewtopic.php?f=7&t=213&p=948#p948
uart->uxBrg.reg = ((__PIC32_pbClk / 16 / baudRate) - 1); // calculate actual BAUD generate value.
uart->uxSta.reg = 0;
uart->uxMode.reg = (1 << _UARTMODE_ON); //enable UART module
uart->uxSta.reg = (1 << _UARTSTA_UTXEN) + (1 << _UARTSTA_URXEN); //enable transmitter and receiver
SD-Card
**********
use SPI module and pin 4 for SS/CS
SPI2CON = 0;
DDPCONbits.JTAGEN = 0;
AD1PCFG = 0xFFFF;
chipSelectPin_ = chipSelectPin;
pinMode(chipSelectPin_, OUTPUT);
PORTSetPinsDigitalOut(prtSCK, bnSCK);
PORTSetPinsDigitalOut(prtSDO, bnSDO);
PORTSetPinsDigitalIn(prtSDI, bnSDI);
// set pin modes
chipSelectHigh();
// must supply min of 74 clock cycles with CS high.
for (uint8_t i = 0; i < 10; i++) spiSend(0XFF);
chipSelectLow();
// command to go idle in SPI mode
while ((status_ = cardCommand(CMD0, 0)) != R1_IDLE_STATE) {
if (((uint16_t)millis() - t0) > SD_INIT_TIMEOUT) {
error(SD_CARD_ERROR_CMD0);
goto fail;
}
}
// check SD version
if ((cardCommand(CMD8, 0x1AA) & R1_ILLEGAL_COMMAND)) {
type(SD_CARD_TYPE_SD1);
} else {
// only need last byte of r7 response
for (uint8_t i = 0; i < 4; i++) {
status_ = spiRec();
}
if (status_ != 0XAA) {
error(SD_CARD_ERROR_CMD8);
goto fail;
}
type(SD_CARD_TYPE_SD2);
}
// initialize card and send host supports SDHC if SD2
arg = type() == SD_CARD_TYPE_SD2 ? 0X40000000 : 0;
while ((status_ = cardAcmd(ACMD41, arg)) != R1_READY_STATE) {
// check for timeout
if (((uint16_t)millis() - t0) > SD_INIT_TIMEOUT) {
error(SD_CARD_ERROR_ACMD41);
goto fail;
}
}
// if SD2 read OCR register to check for SDHC card
if (type() == SD_CARD_TYPE_SD2) {
if (cardCommand(CMD58, 0)) {
error(SD_CARD_ERROR_CMD58);
goto fail;
}
if ((spiRec() & 0XC0) == 0XC0) {
type(SD_CARD_TYPE_SDHC);
}
// discard rest of ocr - contains allowed voltage range
for (uint8_t i = 0; i < 3; i++) spiRec();
}
chipSelectHigh();
WIFI
******
use SPI module and pin 10 for SS/CS + INT1
