Datum: 7.11.95
Can-Bus Gruppe
Autoren:
Stichworte:
In diesem Dokument werden die relevanten CAN-Bus Nachrichten für die Kommunikation zwischen den Can-Bus Knoten beschrieben.
Im Rahmen des SAUS-Projektes haben wir von der CAN-Bus-Gruppe eine Schnittstelle programmiert, welche es erlaubt, mittels des CAN-Busses vom Hauptrechner auf die verschiedenen Knoten des Gesamtsystems zuzugreifen, also zu diesen Daten zu senden und auch Daten zu empfangen. Die Knoten, in unserem Falle drei, sind vollkommen selbständige Einplatinenrechner, hier Mikrocontroller genannt, welche die ihnen zugewiesenen Rollstuhlfunktionen ansteuern bzw. überwachen. Hierzu werden vom Hauptrechner aus spezielle Knotenprogramme in sie geladen, die von den jeweiligen Mikrocontrollern abgearbeitet werden. Ansteuern heißt, der Mikrocontroller gibt, auf Befehl vom Hauptrechner aus, über seine Ausgänge entsprechende Werte an die Sensoren und Aktuatoren. Úberwachen bedeutet, er empfängt Werte von den Sensoren und hält diese zur Auswertung im Hauptrechner bereit.Wie eingangs schon erwähnt, bedienen wir uns bei der Kommunikation zwischen den Mikrocontrollern und dem Hauptrechner des CAN-Busses. CAN (Controller-Area-Network) ist ein von der Firma Bosch anfang der 80er Jahre für den Einsatz in Kraftfahrzeugen entwickeltes Feldbussystem, welches heute einen vielfältigen Einsatz im gesamten Bereich mobiler Systeme, vom Aufzug über den Kran bis zu unserem Rollstuhl, erfährt.
Der Buszugriff erfolgt bei CAN völlig unkoordiniert, so daß die Möglichkeit besteht, daß mehrere Busteilnehmer gleichzeitig mit dem Senden einer Nachricht beginnen. Ein Teilnehmer darf allerdings erst dann auf den Bus zugreifen, wenn der Bus mindestens elf Bitzeiten lang nicht belegt war. Wollen durch Zufall mehrere Busteilnehmer gleichzeitig den Bus benutzen, muß ein Teilnehmer ausgewählt werden, der zugreifen darf. Diese Auswahl erfolgt in der sogenannten Arbitrierungsphase. Für die Arbitrierung wird das sogenannte Arbitrierungsfeld der CAN-Nachricht benutzt, welche aus dem elf Bit langem Identifier sowie dem Remote Transmission Request Bit (RTR)-Bit besteht.
Begonnen wird mit der Auswahl, indem alle zugreifenden Teilnehmer das höchstsignifikante Bit übertragen und dann die folgenden Bits des Identifierts folgen lassen. Beobachtet ein Teilnehmer, der eine 0 gesendet und somit den Bus auf den High-Pegel gesetzt hat, daß der Bus-Pegel Low bleibt, stellt er seinen Zugriff ein. Wird eine Nachricht von einem Sender als Datentelegramm und von einem Empfänger als Datenanforderungstelegramm initiiert, kommt es wegen gleicher Identifiers zum Konflikt, der dadurch gelöst wird, daß beim Datenanforderungstelegramm das RTR-Bit gesetzt ist. Dadurch zieht der das Anforderungstelegramm abschickende Empfänger seinen Zugriffswunsch zurück, da daß angeforderte Telegramm sowieso schon kommt.
Aus dem eben dargestelltem folgt, daß sehr wichtige Nachrichten einen Identifier erhalten sollten, der sie bei der Auswahl bevorzugt, was insbesondere für CAN-Netze mit sehr vielen Teilnehmern gilt. In unserem Falle gibt es nur drei Teilnehmer, was eine überlegte Auswahl der Identifiers nicht so notwendig macht, weshalb wir unsere Identifiers doch recht willkürlich ausgewählt haben.
Bei CAN gibt es vier Arten von Telegramm, von denen wir bisher zwei eingesetzt haben:
1. das Datentelegramm
2. das Datenanforderungstelegramm
Das Datentelegramm sendet eine Nachricht von einem Sender zu einem oder mehreren Empfängern auf Initiative des Senders. Auch das Datenanforderungstelegramm wird auf Initiative des Senders vom Sender zu den Empfängern gesendet. Es enthält keine Daten, sorgt aber dafür, daß vom Empfänger ein Datentelegramm mit Daten und gleichem Identifier zum Sender geschickt wird. Im gegensatz Datentelegramm wird beim Datenanforderungstelegramm das RTR-Bit gesetzt, das Datenfeld entfällt.
Diese Telegramme beginnen immer mit dem Start-of-Frame (SOF)-Bit. Dieses dient, falls andere Teilnehmer ebenfalls auf den Bus zugreifen wollen, der Synchronisation vor der Arbitrierung. Die folgende Tabelle zeigt, was der Programmierer der Teilnehmer zu berücksichtigen hat:
| Bedeutung | Byte | Bit7 | Bit6 | Bit5 | Bit4 | Bit3 | Bit2 | Bit1 | Bit0 |
| Identifier | 0 | Id.7 | Id.6 | Id.5 | Id.4 | Id.3 | Id.2 | Id.1 | Id.0 |
| SubId, RTR, Datalength | 1 | SId.2 | SId.1 | SId.0 | RTR | Dl.3 | Dl.2 | Dl.1 | Dl.0 |
| Data 1...8 | 2...10 | Data | Data | Data | Data | Data | Data | Data | Data |
| Konstante: | BUMPVAL |
| MsgId: | 0x01 |
| SubId: | nicht benutzt |
| RTR | gesetzt |
| Datenlänge | Es werden keine Daten übertragen |
| Bemerkung | Vom Knoten werden alle aktuellen Bumperdaten angefordert. |
| Konstante: | BUMPVAL |
| MsgId: | 0x01 |
| SubId: | nicht benutzt |
| RTR | nicht gesetzt |
| Datenlänge | 2 Byte |
| Data 0...7 | D[0] = Werte von acht Bumpern
D[1] = Werte von vier Bumpern |
| Bemerkung | Der Knoten sendet die Werte aller 12 vorhandenen Bumper zum PC. Pro Bit werden in den benutzten Datenbytes der Wert jeweils eines Bumpers ( Bumper gedrückt=1/ nicht gedrückt=0 ) übergeben. Dabei bedeuten:
x1=VL x2=VR x3=HL x4=HR x5=SL1 x6=SR1 x7=SL2 x8=SR2 x9=SL3 x10=SR3 x11=SL4 x12=SR4 x13..x16 werden nicht genutzt. x1..x8 stehen in D[0], x9..x12 stehen in D[1]. |
| Konstante: | BUMPSET |
| MsgId: | 0x02 |
| SubId: | nicht benutzt |
| RTR | nicht gesetzt |
| Datenlänge | 1 Byte |
| Data 0...7 | D[0] = Es wird x1 für Stoppen gesetzt
D[1]..D[7] werden nicht genutzt. |
| Bemerkung | Setzen der Reaktion des Bumpers auf einen Zusammenstoß (Stoppen = 1, nicht stoppen = 0 ). |
| Konstante: | SETSPEED |
| MsgId: | 0x04 |
| SubId: | nicht benutzt |
| RTR | nicht gesetzt |
| Datenlänge | 1 Byte |
| Data 0...7 | 0<=D[0]<256
D[1..7] unbenutzt |
| Bemerkung | Die Nachricht SETSPEED übermittelt dem Knoten die einzustellende Geschwindigkeit. D[0] = 0 bedeutet Stop und D[0] = 256 bedeutet Höchstgeschwindigkeit |
| Konstante: | SETDIREC |
| MsgId: | 0x05 |
| SubId: | nicht benutzt |
| RTR | nicht gesetzt |
| Datenlänge | 1 Byte |
| Data 0...7 | D[0] = 0 oder 1
D[1..7] unbenutzt |
| Bemerkung | Hiermit wird dem Knoten die Richtung, in welche der Motor drehen soll, zugesandt. D[0] = 0 bedeutet dabei vorwärts und D[0] = 1 rückwärts. |
| Konstante: | SONARDAT |
| MsgId: | 0x0f |
| SubId: | Sensornummer 0 - 7 |
| RTR | 0 |
| Datenlänge | 4 |
| Data 0...7 | D[0] Sendemaske, in welcher 1 Bit für einen Sensor steht.
D[1] Bit 2..9, D[2] Bit 0..1 des 10 Bit Ultraschallwertes D[3] = 1, wenn letzte Nachricht, sonst 0 D[4]..D[7] werden nicht genutzt. |
| Bemerkung | Diese Nachricht steht für insgesamt acht Nachrichten, die sich nur in der SubId, hinter welcher sich die Sensornummern verbergen, unterscheiden. Damit bekannt ist, für wlche Feuerstrategie die in dieser Nachricht übermittelten Sensormeßwerte gelten, wird in D[0] die Sendemaske, für die gefeuert wurde, mitgesendet. In D[1] und D[2] werden dann die Meßwerte eines Sensors, die 10 Bit beanspruchen, übertragen. In D[3] schließlich wird der Empfangsroutine im PC mit einer 0 mitgeteilt, ob noch die Meßwerte anderer Sensore für die gleiche Meßung sowie die gleiche Sendemaske folgen. Kommt die letzte Nachricht, wird D[3] = 1 gesetzt. |
| Konstante: | SONARREQ |
| MsgId: | 0x0e |
| SubId: | nicht benutzt |
| RTR | nicht gesetzt |
| Datenlänge | 2 |
| Data 0...7 | D[0] 0 - 256 Sendemaske
D[1] 0 - 256 Lesemaske D[2] bis D[7] nicht benutzt |
| Bemerkung | Die Nachricht SONARREQUEST enthält im Byte D[0] eine Sendemaske, in welcher jedes gesetzte Bit einen feuernden US-Sensor angibt, während mit D[1] eine Lesemaske weitergegeben wird, in welcher wiederum jedes gesetzte Bit angibt, welcher US-Sensor messen soll. Die Meßwerte werden sofort nach Meßung an den PC zurückgeschickt. |
| Konstante: | SONARADD |
| MsgId: | 0x0a |
| SubId: | 4 |
| RTR | nicht gesetzt |
| Datenlänge | 8 Byte |
| Data 0...7 | D[0] = Sendemaske 1, D[1] = Lesemaske 1
D[2] = Sendemaske 2, D[3] = Lesemaske 2 D[4] = Sendemaske 3, D[5] = Lesemaske 3 D[6] = Sendemaske 4, D[7] = Lesemaske 4 |
| Bemerkung | Hier werden vier Feuerstrategien für das automatische Senden an den Knoten weitergegeben. Die SubId entspricht dabei der Anzahl der Maskenpaare, die für die Feuerstrategien stehen. Sind schon Feuerstrategien im Knoten gespeichert, werden diese noch hinzuaddiert. Löschbar sind die Feuerstrategien mit SONARDEL, dann aber in ihrer Gesamtheit. |
| Konstante: | SONARDEL |
| MsgId: | 0x09 |
| SubId: | nicht benutzt |
| RTR | nicht gesetzt |
| Datenlänge | Es werden keine Daten übertragen |
| Bemerkung | SONARDEL löscht die mit SONARADD zum Knoten gesendeten Ultraschall-Feuerstrategien (US-Sende- bzw. Lesemasken). |
| Konstante: | SONARAUTO |
| MsgId: | 0x08 |
| SubId: | nicht benutzt |
| RTR | nicht gesetzt |
| Datenlänge | 1 Byte |
| Data 0...7 | 0<=D[0]<256
D[1] bis D[7] werden nicht benutzt. |
| Bemerkung | Schaltet das automatische Senden des Knotens ein oder aus, enthält Wert, wie oft gesendet wird. D[0]=0 bedeutet kein Senden, D[0]=256 bedeutet größte Sendefrequenz. |
| Konstante: | RESET_ODO |
| MsgId: | 32 |
| SubId: | 0 |
| RTR | nicht gesetzt |
| Datenlänge | Es werden keine Daten übertragen |
| Bemerkung | Diese Nachricht dient dazu, den Streckenzähler sowie den Fehlerzähler zurückzusetzen. Daten brauchen hierzu nicht übertragen werden, es genügt allein das Eintreffen des Programmes. |
| Konstante: | ODO_MODE |
| MsgId: | 32 |
| SubId: | 1 |
| RTR | nicht gesetzt |
| Datenlänge | 1 Byte |
| Data 0...7 | 0<=D[0]<256
D[1] bis D[7] nicht genutzt |
| Bemerkung | Mit dieser Nachricht wird der Odometriemodus gesetzt. Das bedeutet, mit den Werten zwischen 0 und 256 wird die Frequenz, mit welcher der BETA-Knoten Odometriedaten zum PC senden soll, dem BETA-Knoten bekannt gegeben. |
| Konstante: | OVERFLW |
| MsgId: | 32 |
| SubId: | 3 |
| RTR | nicht gesetzt |
| Datenlänge | 1 Byte |
| Data 0...7 | 0<=D[0]<3
D[1] bis D[7] nicht genutzt |
| Bemerkung | Hier wird vom Knoten dem PC gemeldet, ob ein Streckenzähler übergelaufen ist. Zwei Bit des genutzten Datenbytes werden hierzu als ein Flag mit vier Zuständen benutzt.
0 = Overflow des rechten Streckenzählers vorwärts 1 = Overflow des rechten Streckenzählers rückwärts 2 = Overflow des linken Streckenzählers vorwärts 3 = Overflow des linken Streckenzählers rückwärts |
| Konstante: | ODO_DATA |
| MsgId: | 32 |
| SubId: | 4 |
| RTR | nicht gesetzt |
| Datenlänge | 8 Byte |
| Data 0...7 | D[0] = Geschwindigkeit links
D[1] = Geschwindigkeit rechts D[2] = High-Byte links D[3] = High-Byte rechts D[4] = Low-Byte links D[5] = Low-Byte rechts D[6] = Fehler links D[7] = Fehler rechts |
| Bemerkung | Während mit ODO_MODE dem Knoten mitgeteilt wird, daß er automatisch die Odometriedaten an den PC sendet, ist dieses die Nachricht, die vom Knoten mit allen Odometriedaten zum PC gesendet wird. Diese Nachricht wird auch auf Anforderung durch ODO_DATA mit gesetztem RTR-Bit an den PC gesendet.. Die Werte der Streckenzähler bestehen in dieser Nachricht jeweils aus einem High- und einem Lowbyte, da sie Integer sind. |
| Konstante: | ODO_DATA |
| MsgId: | 32 |
| SubId: | 4 |
| RTR | gesetzt |
| Datenlänge | Es werden keine Daten übertragen |
| Bemerkung | Vom Knoten wird ein Telagramm mit allen aktuellen Odometriedaten angefordert |
| Konstante: | ANGLE_SET |
| MsgId: | 96 |
| SubId: | 5 |
| RTR | nicht gesetzt |
| Datenlänge | Es werden keine Daten übertragen |
| Bemerkung | Wie bei RESET_ODO werden in diesem Fall keine Daten übertragen. Sie wird automatisch vom Knoten zum PC übertragen und teilt nur durch ihr vorhandensein mit, daß ein vorher mit STR_ANGLE an den Knoten gesendeter Lenkwinkel eingestellt ist. |
| Konstante: | STR_ANGLE |
| MsgId: | 96 |
| SubId: | 7 |
| RTR | nicht gesetzt |
| Datenlänge | 1 Byte |
| Data 0...7 | -128<=D[o]<=127 |
| Bemerkung | Mit dieser Nachricht wird dem Knoten Gamma der einzustellende Lenkwinkel mitgeteilt Die Minus-Werte stehen hierbei für Linkseinschlag, die Plus-Werte für Rechtseinschlag und die Null für die Mittelstellung, also geradeaus. |