Protocole EthernetWifi V1 » Historique » Révision 6
Révision 5 (Anonyme, 11/12/2012 21:58) → Révision 6/17 (Anonyme, 18/02/2013 18:53)
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 -16000 (valeur minimale théoriquement atteignable) et 32767 16000 (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 = (32000 . (Val_Réelle - Val_Min)/(Val_Max - Val_Min)) - 16000* 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[,...]]>><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 <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 On aura ainsi par exemple 0010!Gx? correspond au dixième message échangé, le contrôleur demande au drone la valeur de son gyroscope en x 0011!Gx:21 serait la réponse du drone ou encore 0101!0B:21,22,58 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 : 11/12/2012 21h50+_ _+Auteurs : Couma Joani -- Faure Axel+_