Protocole Extension v9.0

Format de fil exact pour votre propre client. Lisez le cycle de vie de la session en premier ; Dispositions des registres définissent les tailles de champ, les décalages et les plages. Une instruction et un sélecteur de bloc sont des champs de paquets distincts même lorsque leurs valeurs numériques coïncident.

Cette section décrit les messages exacts échangés entre l’hôte et le servo. Il est destiné aux lecteurs connectant leur propre logiciel.

Format du message et encodage des numéros

Chaque message est un paquet : une séquence d’octets contenant la destination, la commande, les données et une somme de contrôle utilisée pour détecter les erreurs de transmission. Les commandes Extension utilisent le format de paquet STS standard :

Request:  FF FF ID LENGTH INSTRUCTION PARAMETERS... CHECKSUM
Response: FF FF ID LENGTH LEGACY_ERROR EXT_STATUS DATA... CHECKSUM

• Demande LENGTH = parameter_bytes + 2 .
• Réponse LENGTH = data_bytes + 3 ; l’état de l’extension occupe le premier paramètre de réponse, séparément de l’octet d’erreur hérité normal.
• CHECKSUM = ~(ID + LENGTH + instruction_or_error + all_parameter_bytes) & 0xFF . La somme des réponses inclut EXT_STATUS et toutes les données.
• Un champ occupant plusieurs octets envoie en premier l’octet de poids faible ( little-endian ). Par exemple, le numéro 256 est envoyé sous la forme 00 01 sur deux octets.
• u8 , u16 et u32 sont des nombres entiers non négatifs occupant les octets 1 , 2 et 4 . i16 et i32 occupent les octets 2 et 4 et peuvent également représenter des nombres négatifs. Les valeurs d’extension signées utilisent le complément à deux : par exemple, − 1 est FF FF dans un champ i16. Cela diffère du codage existant des valeurs signées.
• Q8 signifie qu’une valeur est multipliée par 256 avant la transmission afin que les fractions puissent être représentées sous forme de nombres entiers. Divisez par 256 lors de la lecture. Par exemple, le nombre de positions 1000 est envoyé sous la forme 256000 et le gain 4.5 est envoyé sous la forme 1152.
• La position est en nombres d’encodeur et la vitesse est en nombres/s. L’hôte gère toute conversion en angles d’articulation, y compris les changements de direction ou de position zéro.
• Unicast signifie un message adressé à un servo. Broadcast utilise l’ID 0xFE et atteint tous les servos. Les commandes d’extension de diffusion ne génèrent jamais de réponses.

Exemple : lire le bloc de capacités 8 -byte à partir de l’ID de servo 1 :

FF FF 01 04 90 90 08 D2

Un sélecteur identifie un bloc de registre complet, tel qu’une configuration ou un retour d’information. Accédez-y avec l’extension READ/WRITE et la taille exacte du bloc indiquée ci-dessous. La lecture ou l’écriture d’une partie seulement d’un bloc n’est pas prise en charge et les anciennes commandes READ/WRITE ne peuvent pas accéder à ces blocs.

Instructions

Les tailles de paramètres ci-dessous excluent l’en-tête du paquet et la somme de contrôle. Dans une réponse, EXT_STATUS indique si la commande d’extension a réussi, séparément de LEGACY_ERROR , l’octet d’erreur normal du servo. Une lecture réussie ajoute les données demandées après EXT_STATUS ; les écritures, les autres commandes et les lectures échouées n’ont pas de données supplémentaires.

Numéros d’instruction 0x92 , 0x93 , 0x94 , 0x95 , 0x96 , 0x97 et 0x98 , et sélecteurs 0xA1 , 0xA3 , 0xB0 , 0xBA , 0xE0 et 0xF0 , sont réservés et ne doivent pas être utilisés.

Une incompatibilité de session renvoie un échec d’état. Inspectez à la fois l’octet d’erreur hérité et l’état de l’extension.

Sessions et numéros de séquence

L’hôte attribue à chaque session un numéro allant de 1 à 65535 et l’inclut dans les commandes de contrôle. Cela permet au servo de vérifier qu’une commande appartient à la session en cours. Choisissez un nouveau numéro pour chaque startup ; les numéros de configuration ne sont pas stockés de manière permanente.

Un numéro de séquence compte les commandes acceptées dans l’ordre, permettant à l’hôte et au servo d’identifier les commandes manquantes, répétées ou dans le désordre.

TARGETS dispose d’un compteur de séquences de mouvements par servo. GRAVITY a un compteur séparé. Les deux démarrent à zéro lorsque l’activation du couple démarre le contrôle ; Envoyez normalement 1 en premier. Les nombres augmentent jusqu’à 65535, puis reviennent à 0 , sans mettre fin à la session. Des écarts sont autorisés : après 10, le servo peut accepter 12 même si 11 a été perdu ou rejeté. Les nombres égaux ou plus anciens sont rejetés sans modifier la commande actuelle.

Pour une comparaison exacte, calculez distance = (incoming − accepted) & 0xFFFF . Une commande est plus récente uniquement lorsque 1 ≤ distance ≤ 32767 . Un saut exactement 32768 est ambigu et rejeté. Conservez l’écart par rapport à la dernière commande acceptée en dessous de 32768 ; si l’historique des commandes est incertain, désactivez le couple, préparez un nouvel ID de session et réactivez le couple. Ne réutilisez pas les paquets mis en file d’attente d’une session ou d’un cycle de compteur antérieur.

L’acceptation nécessite toujours des champs valides, des lectures actuelles du capteur et un mouvement réalisable. Une commande rejetée ne fait pas avancer son compteur. Ces commandes remplacent les cibles absolues ; il ne s’agit pas d’une file d’attente de points de cheminement. Pour visiter chaque point de cheminement, attendez chaque arrivée avant d’envoyer la destination suivante.

Lors de l’envoi d’une cible de groupe, lisez les commentaires de chaque servo pour vérifier sa séquence acceptée. Chaque servo décide indépendamment s’il peut accepter sa cible ; l’un peut le rejeter pendant que les autres se mettent en mouvement.

TARGETS — 0x9A

Les deux premiers octets de paramètres contiennent la session partagée. Chaque entrée suivante a cette disposition ; les décalages sont relatifs au début de cette entrée :

La longueur du paramètre est 2 + 9 × entry_count , au maximum 56 octets. Les identifiants doivent être uniques. Chaque servo vérifie le format et les champs obligatoires de toutes les entrées avant de gérer les siennes. Un servo qui n’est pas répertorié ne fait rien. Un servo répertorié vérifie sa session, sa séquence, son état de préparation et si le mouvement peut rester dans ses limites. Une cible acceptée démarre immédiatement et reste active jusqu’à ce qu’elle soit remplacée ou désarmée. Les valeurs sont plafonnées aux limites configurées comme décrit sous Mouvement en courbe en S.

GRAVITÉ — 0x99

La longueur du paramètre est exactement de 6 octets. Nécessite une session armée avec le moteur sous tension, le matériel prêt, aucun défaut signalé et des lectures récentes du capteur. Cela ne fait pas avancer la séquence de mouvements. La valeur demandée reste active jusqu’à ce qu’elle soit remplacée ou désarmée.

Vérifier une implémentation client

Vérifiez séparément la longueur, la somme de contrôle, l’erreur héritée et l’état Extension. Confirmez les TARGETS du groupe via les commentaires de chaque servo répertorié : une transmission de diffusion réussie ne constitue pas une acceptation. Si l’historique des séquences est incertain, relâchez le couple et préparez une nouvelle session plutôt que de poursuivre aveuglément une ancienne file d’attente de paquets.

Le pilote existant code et décode via host/servo-driver/registers/ArmCodec.js et host/servo-driver/bus/ArmExtension.js. Le micrologiciel implémente le format filaire dans firmware/app/arm_extension.c .

Accueil de la documentation · Révision source : a995f77 . Extension 9.0 .