Projets_Etudiants » Projets IUT SI » Iut Si Polytech QuadriCoptère

h1. Protocole EthernetWifi V1

h2. Généralités

Le protocole de communication privilégié est l'UDP.

Le respect de l'endianness (et donc si nécessaire la conversion) doit être si nécessaire assurée au l'envoi comme à la réception.

h2. Valeurs numériques

Toutes les valeurs numériques (récupérées depuis un capteur ou transmises comme consigne) doivent être converties de sorte que leurs valeurs varient entre -32767(valeur minimale théoriquement atteignable) et 32767 (valeur maximale théoriquement atteignable). 

Un champ de valeur aussi important garantissant une précision en principe suffisante pour les calculs à effectuer par la suite.

L'usage de int16_t définis dans stdint.h peut donc être pertinent dans le cadre des manipulations de ces valeurs.

Une formule permettant d'obtenir un formatage efficace est : *Val_formatée = (32766 . (Val_Réelle - Val_Min)/(Val_Max - Val_Min)) - 16383*

Attention : les calculs doivent être réalisés en float afin d'éviter des pertes importantes au cours de la division.

Si ce choix semble non pertinent merci de nous contacter.

*Attention : à l'issue de ce formatage, le 0 ne désigne pas nécessairement la position neutre ou le 0 conventionnel. Cela ne sera vrai que si l'intervalle des valeurs d'origine est centré en 0 (val_min = -val_max).*

h2. Format général de la trame

Le format de trame sera le suivant :

*

<NUM_PAQUET><!><TYPE_TRAME><< ?>|<<:><VAL>[,VAL[,...]]>><!><CTRL_SUM><CRLF>*

Avec :

<NUM_PAQUET> : numéro du paquet, auto-incrémental, sur 4 chiffres, non signé, en décimal. 

<!> : caractère "!" utilisé comme séparateur

<TYPE_TRAME> : suite de 2 caractères en ASCII indiquant les informations portées par la trame (voir plus bas)

<< ?>|<<:><VAL>[,VAL[,...]]>> valant soit :

       -- "?" dans le cadre de la demande d'une (série de) valeurs

       -- ":" suivi d'une série de valeurs séparés par des virgules

<CTRL_SUM> consiste en la somme des valeur ASCII de toute la trame jusqu'au caractère "!" précédant cette somme ("!" inclus)

<CRLF> : caractères "\r\n"

h2. Liste des TYPE_TRAME

les TYPES_TRAME sont des suites de 2 caractères ASCII

h3. TYPE_TRAME commençant par un 0

Ces types sont réservés à des fins de test et ne doivent pas être utilisé dans le cadre d'une implémentation finale.

h3. TYPE_TRAME commençant par un 1

Ces types sont réservés à la transmission des erreurs.

h3. Capteurs

"Ca" suivi d'une série de 11 valeurs est utilisé pour envoyer l'ensemble des valeurs des capteurs dans l'ordre suivant :

accéléro_x, accéléro_y,accéléro_z,gyro_x,gyro_y,gyro_z,magnéto_x,magnéto_y,magnéto_z,baromètre,thermomètre

h4. Accéléromètres

"Ax" suivi d'une valeur correspond à l'accéléromètre x

"Ay" suivi d'une valeur correspond à l'accéléromètre y

"Az" suivi d'une valeur correspond à l'accéléromètre z

"Aa" suivi de trois valeurs correspond aux valeurs des trois accéléromètres dans l'ordre x,y,z

h4. Gyroscopes

"Gx" suivi d'une valeur correspond au gyroscope x

"Gy" suivi d'une valeur correspond au gyroscope y

"Gz" suivi d'une valeur correspond au gyroscope z

"Ga" suivi de trois valeurs correspond aux valeurs des trois gyroscopes dans l'ordre x,y,z

h4. Magnétomètre

"Ax" suivi d'une valeur correspond au magnétomètre x

"Ay" suivi d'une valeur correspond au magnétomètre y

"Az" suivi d'une valeur correspond au magnétomètre z

"Aa" suivi de trois valeurs correspond aux valeurs des trois magnétomètres dans l'ordre x,y,z

h4. Sonars

"Sf" suivi d'une valeur correspond au sonar avant (front)

"Sb" suivi d'une valeur correspond au sonar arrière (back)

"Sl" suivi d'une valeur correspond au sonar gauche (left)

"Sr" suivi d'une valeur correspond au sonar droit (right)

"Su" suivi d'une valeur correspond au sonar haut (up)

"Sd" suivi d'une valeur correspond au sonar bas (down)

"S6" suivi de 6 valeurs correspond à la valeur des 6 sonars (ordre : avant, arrière, gauche, droite, bas, haut)

h4. Autres capteurs

"B0" suivi d'une valeur correspond au baromètre

"TH" suivi d'une valeur correspond au thermomètre

"GP" suivi de 8 valeurs correspond aux valeurs du GPS (ordre à définir)

h3. Moteurs

h4. Du drone vers le contrôleur

"M1" suivi d'une valeur correspond à la valeur actuelle du moteur 1

"M2" suivi d'une valeur correspond à la valeur actuelle du moteur 2

"M3" suivi d'une valeur correspond à la valeur actuelle du moteur 3

"M4" suivi d'une valeur correspond à la valeur actuelle du moteur 4

"Me" suivi de 4 valeurs correspond à la valeur actuelle des 4 moteurs (1,2,3,4)

"Mc" suivi d'une valeur correspond à la valeur actuelle de la consigne moteur

"M+" suivi de 5 valeurs correspond à la valeur actuelle des 4 moteurs suivi de la consigne moteur

h4. Du contrôleur vers le drône

"M1" suivi d'une valeur correspond à la valeur à atteindre pour le moteur 1

"M2" suivi d'une valeur correspond à la valeur à atteindre pour le moteur 2

"M3" suivi d'une valeur correspond à la valeur à atteindre pour le moteur 3

"M4" suivi d'une valeur correspond à la valeur à atteindre pour le moteur 4

"Me" suivi de 4 valeurs correspond à la valeur à atteindre pour les 4 moteurs (1,2,3,4)

"Mc" suivi d'une valeur correspond à la valeur à atteindre pour la consigne moteur

"M+" suivi de 5 valeurs correspond à la valeur à atteindre pour les 4 moteurs suivi de la consigne moteur

h2. Exemples (sommes de controles non encore intégrées)

On aura ainsi par exemple 

0010!Gx?!<SOMME>

correspond au dixième message échangé, le contrôleur demande au drone la valeur de son gyroscope en x

0011!Gx:21!<SOMME>

serait la réponse du drone

ou encore 

0101!0B:21,22,58!<SOMME>

Qui serait le 101e message d'une série, utilisant un protocole de test (commençant par 0) et renvoyant 3 valeurs

h2. Informations complémentaires

*_Notes :_*

_1) La présence de bits de bourrage en fin de trames peut être envisagée et pourrait être décidée dans le cadre d'une révision ultérieure de ce document_

_2) Ce protocole est encore une ébauche, il est susceptible d'être modifié par la suite_

_3) Ce protocole constitue un premier jet destiné à la phase de conception initiale du système, l'optimisation de la vitesse n'est pas privilégiée ici_

_4) Ce protocole sera probablement fortement étendu voire totalement abandonné lors de développement ultérieurs du projet, les implémentations de divers protocoles doivent donc pouvoir être interverties aisément au sein du code réalisé (au besoin à l'aide de pattern adéquats). Les révisions cités son suceptibles d'affecter profondément la forme des trames mais aussi de manière non négligeable les informations transmises_

_5)Par ailleurs, de manière plus générale, l'usage des variables définies dans stdint.h pourrait être un gage de portabilité, il me semble donc pertinent d'envisager de les préférer aux variables par défaut._

-----------------------------------------------------------------------------

_+Dernière révision : 27/02/2013 18h25+_

_+Auteurs : Couma Joani -- Faure Axel+_