III. ARCOS
1) Qu'est-ce qu'ARCOS ?
A) Une Architecture
Client/Serveur
Le robot repose sur une architecture client/serveur. En outre, il dispose d'un contrôleur embarqué, fonctionnant en tant que serveur et dédié à la manipulation des informations de bas niveau
(capteurs et actionneurs).
B) Interface
ARCOS (ActivMedia Robot Control et
Operation Software) est une interface client/serveur, initialisée au démarrage du robot, au travers de laquelle il est possible de contrôler le robot et de collecter des informations, ce qui comprend les mouvements des roues, les valeurs retournées par les sonars, etc...
On peut accéder directement à ARCOS à partir de l'OS embarqué grâce à l'application ARCOScf : cette application en ligne de commande permet d'effectuer des réglages et de contrôler le robot.
Les paramètres d'ARCOS (temps de cycle, durée du watchdog, paramètres du PID...) sont contenues dans la mémoire Flash du robot et peuvent être modifiés par l'envoi d'une commande.
(par ARCOScf ou toute autre application cliente.)
2) Protocole de communication
Afin de transmettre les informations nécessaires au contrôle du robot, il a été développé un protocole de communication propriétaire. Ce protocole se compose de 2 types de paquet :
–
– les paquets de commandes de l'application cliente vers le robot, les informations serveurs (ou SIP) du robot vers l'application cliente.
A) Paquet de Commande
Entête (2octets) : Il s'agit invariablement des caractères 0xFA et 0xFB.
Longueur (1octet) : Nombre d'octets du paquet, checksum compris, sans compter l'entête ni le champ longueur.
Commande (1octet) : Code de la commande de 0 à 255 (Cf Annexe 1)
Type (1octet) : Il s'agit du type de l'argument de la commande :
–
–
Entier positif : 0x3B
Entier négatif ou absolu : 0x1B
–
String : 0x2B
Argument (n octets) : Argument de la commande. (Si la taille de l'argument est supérieur à 1 octet, l'argument est alors précédé de sa taille.)
CheckSum (2 octets) : Champ de vérification de l'intégrité du paquet. Il est à remarquer que l'octet de poids faible précède ici l'octet de poids fort.
Exemples :
•
Paquet qui permet de l'ouverture des serveurs du robot :
•
Paquet qui fixe la vitesse du robot à 50 mm/s :
B) SIP (Server Information Packet)
Une fois la connexion établie (Cf Chapitre suivant), ARCOS transmet automatiquement et régulièrement un SIP standard au travers du médium de transmission.
Le format des ces paquets est similaire à celui des paquets de commandes.
C) Déroulement d'une Connexion
Connexion au robot.
Comme nous l'avons déjà vu, le robot repose sur une architecture client/serveur : une application cliente doit par conséquent se connecter au robot serveur. Pour se faire, l'application doit transmettre dans l'ordre trois paquets de synchronisation (référencés par SYNC0, SYNC1,
SYNC2) au robot : si elle reçoit en retour des paquets en écho, alors la connexion est établie.
Bien que la connexion soit établie, il reste indispensable de commander l'ouverture des serveurs du robot (sonars, moteurs...) par la transmission de la commande OPEN.
Pulsation.
Comme indiqué précédemment, le robot transmet à l'application cliente un paquet SIP tous les 100ms. En retour, côté robot, un "watchdog"(en français, "chien de garde") s'attend à recevoir de façon régulière un paquet de commande de la part de l'application. S'il ne reçoit pas de paquet durant un laps de temps prédéfini, alors la connexion client/serveur s'interrompt et le robot s'arrête.
De ce fait, quand aucune commande ne doit être envoyée au robot, l'application cliente doit envoyer des paquets de pulsation, qui ne contient aucune commande autre que la commande dédiée
PULSE, à seule fin de réinitialiser le "watchdog".
Déconnexion
L'envoi par le client d'un paquet avec la commande CLOSE permet à la fois d'arrêter le robot et de clôturer la communication. Le robot se met alors en attente d'un nouveau client.
D) QoS : Qualités de service.
Il se peut que lors de la transmission d'un paquet (qu'il s'agisse d'un SIP ou d'un paquet de commande) on trouve une erreur au niveau du checksum : dans tous les cas, le paquet est ignoré et non redemandé.
En effet, pour des raisons de temps réel, cela demande moins de temps de rejeter complètement un paquet et d'attendre le suivant, plutôt que de redemander à l'expéditeur un paquet mal transmis. On ne travaille alors qu'avec les informations les plus récentes. Un système avec ce comportement est qualifié d'application temps réel "soft".
De la même manière, aucun accusé de réception (mise à part l'écho pour la connexion) n'est envoyé. Cette absence de QoS a comme autre avantage d'éviter la surcharge du médium de communication.
Ainsi, Si un paquet de commande est perdu ou rejeté, alors c'est au client qui a émis cette commande de s'apercevoir grâce aux SIP suivants que sa commande n'a pas été prise en compte et qu'il doit donc la retransmettre.
