Zum Artikel

Extension-Protokoll v9.0

Geprüft 2026-11-01

Genaues Überweisungsformat für Ihren eigenen Kunden. Lesen Sie zunächst den Sitzungslebenszyklus . -Registerlayouts definieren Feldgrößen, Offsets und Bereiche. Eine Anweisung und ein Blockselektor sind separate Paketfelder, auch wenn ihre numerischen Werte übereinstimmen.

Unicast-Anfrage und -Antwort des Erweiterungsprotokolls

In diesem Abschnitt werden die genauen Nachrichten beschrieben, die zwischen Host und Servo ausgetauscht werden. Es richtet sich an Leser, die ihre eigene Software anschließen.

Nachrichtenformat und Zahlenkodierung

Jede Nachricht ist ein Paket: eine Folge von Bytes, die das Ziel, den Befehl, die Daten und eine Prüfsumme zur Erkennung von Übertragungsfehlern enthält. Extension-Befehle verwenden das Standard-STS-Paketformat:

Request:  FF FF ID LENGTH INSTRUCTION PARAMETERS... CHECKSUM
Response: FF FF ID LENGTH LEGACY_ERROR EXT_STATUS DATA... CHECKSUM
  • Anfrage LENGTH = parameter_bytes + 2 .
  • Antwort LENGTH = data_bytes + 3 ; Der Erweiterungsstatus belegt den ersten Antwortparameter, getrennt vom normalen Legacy-Fehlerbyte.
  • CHECKSUM = ~(ID + LENGTH + instruction_or_error + all_parameter_bytes) & 0xFF . Die Antwortsumme umfasst EXT_STATUS und alle Daten.
  • Ein Feld, das mehrere Bytes belegt, sendet das niedrigstwertige Byte zuerst ( Little-Endian ). Beispielsweise wird die Nummer 256 als 00 01 in zwei Bytes gesendet.
  • u8 , u16 und u32 sind nichtnegative ganze Zahlen, die die Bytes 1 , 2 und 4 belegen. i16 und i32 belegen die Bytes 2 und 4 und können auch negative Zahlen darstellen. Vorzeichenbehaftete Erweiterungswerte verwenden das Zweierkomplement : Beispiel: − 1 ist FF FF in einem i16-Feld. Dies unterscheidet sich von der alten Kodierung vorzeichenbehafteter Werte.
  • Q8 bedeutet, dass ein Wert vor der Übertragung mit 256 multipliziert wird, sodass Brüche als ganze Zahlen dargestellt werden können. Teilen Sie beim Lesen durch 256. Beispielsweise wird die Anzahl der Positionen 1000 als 256000 und die Verstärkung 4.5 als 1152 gesendet.
  • Die Position wird in Encoder-Zählungen und die Geschwindigkeit in Zählungen/s angegeben. Der Host übernimmt die Konvertierung in Gelenkwinkel, einschließlich Richtungs- oder Nullpositionsänderungen.
  • Unicast bedeutet eine an ein Servo gerichtete Nachricht. Broadcast verwendet die ID 0xFE und erreicht alle Servos. Broadcast-Erweiterungsbefehle generieren niemals Antworten.

Beispiel: Den 8-Byte-Fähigkeitsblock von der Servo-ID 1 lesen:

FF FF 01 04 90 90 08 D2

Ein -Selektor identifiziert einen vollständigen Registerblock, beispielsweise Konfiguration oder Rückmeldung. Greifen Sie mit der Erweiterung READ/WRITE und der unten aufgeführten genauen Blockgröße darauf zu. Das Lesen oder Schreiben nur eines Teils eines Blocks wird nicht unterstützt und die alten READ/WRITE-Befehle können nicht auf diese Blöcke zugreifen.

Anweisungen

Die folgenden Parametergrößen schließen den Paket-Header und die Prüfsumme aus. Als Antwort meldet EXT_STATUS, ob der Erweiterungsbefehl erfolgreich war, getrennt vom normalen Fehlerbyte LEGACY_ERROR des Servos. Bei einem erfolgreichen Lesevorgang werden die angeforderten Daten nach EXT_STATUS hinzugefügt. Schreibvorgänge, andere Befehle und fehlgeschlagene Lesevorgänge enthalten keine zusätzlichen Daten.

Anleitung Name Parameter Ausstrahlung
0x90 READ selector:u8, count:u8 Keine nützliche Antwort
0x91 WRITE selector:u8, block... Nicht akzeptiert
0x99 GRAVITY 6 Bytes, unten Nicht akzeptiert
0x9A TARGETS session:u16 + 1 – 6 Einträge von 9 Bytes Akzeptiert

Befehlsnummern 0x92, 0x93, 0x94, 0x95, 0x96, 0x97 und 0x98 sowie Selektoren 0xA1, 0xA3, 0xB0 , 0xBA , 0xE0 und 0xF0 sind reserviert und dürfen nicht verwendet werden.

Extension-Status Bedeutung
0 Okay
1 Ungültige Länge, ungültiger Selektor oder Feldwert
2 Befehl kann im aktuellen Zustand nicht angenommen werden
3 Reserviert
4 Reserviert
5 Nicht unterstützte Anweisung

Eine Sitzungsinkongruenz führt zu einem Statusfehler. Überprüfen Sie sowohl das Legacy-Fehlerbyte als auch den Erweiterungsstatus.

Sitzungen und Sequenznummern

Der Host weist jeder Sitzung eine Nummer von 1 bis 65535 zu und bezieht diese in Steuerbefehle ein. Dadurch kann der Servo prüfen, ob ein Befehl zur aktuellen Sitzung gehört. Wählen Sie für jeden Start eine neue Nummer. Setup-Nummern werden nicht dauerhaft gespeichert.

Eine -Sequenznummer zählt akzeptierte Befehle der Reihe nach und ermöglicht es dem Host und dem Servo, fehlende, wiederholte oder nicht in der Reihenfolge liegende Befehle zu identifizieren.

TARGETS verfügt über einen Bewegungssequenzzähler pro Servo. GRAVITY verfügt über einen separaten Zähler. Beide beginnen bei Null, wenn die Drehmomentfreigabe mit der Steuerung beginnt; Normalerweise senden Sie zuerst 1 . Die Zahlen steigen bis 65535 und wechseln dann zu 0 , ohne die Sitzung zu beenden. Lücken sind zulässig: Nach 10 akzeptiert das Servo möglicherweise 12, auch wenn 11 verloren ging oder abgelehnt wurde. Gleiche oder ältere Nummern werden abgewiesen, ohne den aktuellen Befehl zu ändern.

Für einen genauen Vergleich berechnen Sie distance = (incoming − accepted) & 0xFFFF . Ein Befehl ist nur neuer, wenn 1 ≤ distance ≤ 32767 . Ein Sprung von genau 32768 ist mehrdeutig und wird abgelehnt. Halten Sie den Abstand zum letzten akzeptierten Befehl unter 32768 ein. Wenn der Befehlsverlauf unsicher ist, schalten Sie das Drehmoment aus, bereiten Sie eine neue Sitzungs-ID vor und aktivieren Sie das Drehmoment erneut. Verwenden Sie in der Warteschlange befindliche Pakete aus einer früheren Sitzung oder einem früheren Zählerzyklus nicht wieder.

Für die Akzeptanz sind weiterhin gültige Felder, aktuelle Sensorwerte und eine durchführbare Bewegung erforderlich. Ein abgelehnter Befehl erhöht seinen Zähler nicht. Diese Befehle ersetzen absolute Ziele; Sie sind keine Wegpunktwarteschlange. Um jeden Wegpunkt zu besuchen, warten Sie auf jede Ankunft, bevor Sie das nächste Ziel senden.

Wenn Sie ein Gruppenziel senden, lesen Sie die Rückmeldung jedes Servos, um die akzeptierte Sequenz zu überprüfen. Jedes Servo entscheidet selbstständig, ob es sein Ziel annehmen kann; Einer kann es ablehnen, während die anderen anfangen, sich zu bewegen.

ZIELE – 0x9A

Die ersten beiden Parameterbytes enthalten die gemeinsame Sitzung. Jeder folgende Eintrag hat dieses Layout; Offsets sind relativ zum Anfang dieses Eintrags:

Versatz Typ Feld
0 u8 Servo-ID, 1 – 253
1 u16 Neuerer Bewegungsablauf für dieses Servo
3 i32 Zielposition, Q8 zählt
7 u16 Maximale Geschwindigkeit, Anzahl/s, ungleich Null

Die Parameterlänge ist2 + 9 × entry_count, höchstens 56 Byte. Ausweise müssen vorhanden sein einzigartig. Jeder Servo überprüft das Format und die erforderlichen Felder vonalleEinträge bevor Sie es selbst in die Hand nehmen. Ein Servo, das nicht aufgeführt ist, bewirkt nichts. Ein gelistetes Servo prüft seine Sitzung, Reihenfolge, Bereitschaft und ob die Bewegung innerhalb bleiben kann seine Grenzen. Ein akzeptiertes Ziel startet sofort und bleibt aktiv, bis es ersetzt wird oder entwaffnet. Die Werte werden auf die konfigurierten Grenzwerte begrenzt, wie unten beschrieben S-Kurven-Bewegung.

SCHWERKRAFT – 0x99

Versatz Typ Feld / Einschränkung
0 u16 Aktuelle Sitzung
2 u16 Neuere Schwerkraftsequenz
4 i16 Gewünschte Schwerkraft-Stellgröße; Betrag ≤ konfigurierte Ausgangsgrenze

Die Parameterlänge beträgt genau 6 Bytes. Erfordert eine aktivierte Sitzung mit eingeschaltetem Motor, betriebsbereiter Hardware, keinem gemeldeten Fehler und aktuellen Sensormesswerten. Der Bewegungsablauf wird dadurch nicht vorangetrieben. Der angeforderte Wert bleibt aktiv, bis er ersetzt oder deaktiviert wird.

Überprüfen Sie eine Client-Implementierung

Überprüfen Sie Länge, Prüfsumme, Legacy-Fehler und Extension-Status separat. Bestätigen Sie die Gruppenbefehle TARGETS durch die Rückmeldung jedes aufgelisteten Servos: Eine erfolgreiche Broadcast-Übertragung ist keine Akzeptanz. Wenn der Sequenzverlauf unsicher ist, lassen Sie das Drehmoment los und bereiten Sie eine neue Sitzung vor, anstatt blind eine alte Paketwarteschlange fortzusetzen.

Der vorhandene Treiber kodiert und dekodiert über host/servo-driver/registers/ArmCodec.js und host/servo-driver/bus/ArmExtension.js. Die Firmware implementiert das Wire-Format in firmware/app/arm_extension.c.


Startseite der Dokumentation · Quellrevision: a995f77 . Extension 9.0 .