I/2005
Bei diesem Fahrzeug handelt es sich um ein großes Projekt der Schüler des TGM in Wien.
Mr400Watt
Flocky
Daveler
Es gibt zwei Boards auf dem Rover, ein Unix-Board, das mit WLAN die Verbindung mit der Server-Station hält, die Bilder der Kamaras und Meßwerte übermittelt, die dann über Internet zugänglich sind. Andererseits empfängt es ebenso die Fahrkommandos, Kameraführung und Betriebsparameter. Auf dem Bild rechts sieht man die Halterungen für die großen Solar-panels, mit denen ein mehrtägiger OFF-Road Betrieb möglich ist. Diese "Mainboard" ist auch für die gesamt Energieverwaltung zuständig. (Power on/off etc.)
Das Chassis
mit den Extraaufbauten für die Elektronik-Box
Hier beginnt
der Aufbau der Halterungen für die Solar-Zellen
Detail-Ansicht
der montierten Solarzellen
Die isolierte
Box für die Elektronik
Die isolierte
Zelle für die Elektronic. Gut zu erkennen dir RNBFRA 1.2-Karte In der Mitte
der Schrittmotor, der die Kamera dreht
Die Stereo-Kamera.
An der Seite das Servo für Tilt.
Wieder die
RNBFRA 1.2 Karte. Die Kühlkörper natürlich an der Außenseite
des Gehäuses.
Gesamtansicht
der Elektronik, das "Mainboard" ist jetzt über der RNBFRA
Die Solar-Panel
beim Aufbau. Zweimal 80 x 45.
Das ganze
Fahrzeug, Leider ist jetzt alles von den Solarzellen verdeckt. Muß wohl
so sein, aber der urige Off-Road Look ist weg..
Die eigentliche Bedienung der Sensoren und Aktoren obliegt einer RNBFRA 1.2 Karte mit Mega32 (8 MHZ), erweitert mit SD21 Servo-kontroller (dazu später mehr).
6 x SF08 Us-Sensoren
3 x LM75 Temperatur -Sensoren
1 x Inclination Sensor X/Y
2 x CNY70 für die rotation control der Kameras
2 x Stepper für das panning der Kameras (1 x stereo cam, 1 x panorama cam)
1 x Servo für das tilt der stereo cam
1 x Servo für die Lenkung
1 x ServoRegler f. den Hauptantrieb
1 x Servo für das Getrieb (2 gears)
Powercontrol f. die Kameras
Powercontrol f. die Servos u. Motoren
Schwellwertkontrolle der Sensoren (individuell), Alerting, mit an- und abschaltbarer EMERGENCY-HALT Funktion.
Protokoll-gesteuerte Kommunikation mit dem "Main-board" Sensorwerte, Alerting ON/OFF Messages, Device-registering, Command-reception, acking, etc.
Das alles sollte (natürlich) simultan (pseudo-parallel) ablaufen.
Als Sprache wurde aus praktischen Gründen BasCom gewählt.
KERNEL
Für einen kontrollierten Ablauf ist offensichtlich sowas wie ein "KERNEL" erforderlich. Der basiert auf mehreren Haupt-Komponenten
UNITS (devices)
DIM UnitFlags(nn) as BYTE-------------------- definierte Bits
DIM Unitclass(nn) as BYTE--------------------- Code für die Device-Class
DIM Unitident(nn) as BYTE--------------------- Code für die Device-Class-Sub-Id
DIM Untireference(nn) as BYTE---------------- Index-# für private Device-Daten
Durch den Index sind die Attribute einer konkreten Unit adressiert. Die Einträge werden in der Startup-Phase aufgebaut. Global sind die Funktionen (Methoden) jeder Unit über eine einheitliche Funktion ansprechbar.
Unitfunction ( byval Index as byte, byval command as byte, byval param as word)
Leider war mit Call-Vectoren nix zu machen, daher wird eine konkrete Funktion durch SELECT aus Unitclass u.-Ident ausgewählt
MESSAGES
DIM MsgFlags(nn) as BYTE
DIM MsgIdx(nn) as BYTE--------------------- der Unit-Index der Zielfunktion
DIM MsgCommand(nn) as BYTE-------------- das Command
DIM MsgParam(nn) as WORD---------------- ggf. zusätzlicher Wert
Messages sind Nachrichten od. Kommandos an Units, die in einer Queue First In-First Out geführt werden. Sie können jederzeit von jedem an jeden aufgesetzt werden.
TIMERQUEUE
DIM TimFlags(nn) as BYTE
DIM TimIdx(nn) as BYTE--------------------- der Unit-Index der Zielfunktion
DIM TimCommand(nn) as BYTE-------------- das Command
DIM TimCount(nn) as WORD----------------- Anzahl Timer-Ticks, nach denen die
Funktion aufgerufen werden soll
Die Timer-Entries sind im Grunde nix als verzögerte Messages,
allerdings ohne Param, diese wären zwar möglich, waren für
das konkrete Projekt aber nicht notwendig. Im allgemeinen erzeugen die Units
nur timer-entries an sich selbst.
TIMERTICKS
Ganz klar, das mehr verschiedene Timer für den Marsrover
notwendig sind, als irgendein MegaXX eingebaut hat. Also wird gleich nur ein
einziger HW-Timer verwendet, TIMER-0. Der ist auf genau 10 mS eingestellt, und
macht in seiner Interrupt-Routine nichts, außer ein spezielles globales
Bit zu setzen (und Preload zu laden, klaro)
UART
Für die UART wurde ein serialin-buffer mit 64 aufgesetzt. Das reichte, um einlangende Bytes rechtzeitig durch "ISCHARWAIT" zu erkennen. "INKEY" konnte dazu nicht verwendet werden, da die definierten UART-Messages mit transparenten Daten arbeiteten, d.h. das Ergebnis = 0 (no data) könnte genausogut ein gültiges Zeichen sein.
DO...LOOP
Ist das Timerbit gesetzt (10 mS sind 'rum),
werden in der TimerQueueFunction alle aktiven Counter dekrementiert, Wird einer
NULL, wird eine Message in der MessageQueue erzeugt.
Dann wirden die Messages in der entsprechenden Queue abgeräumt und die
jeweiligen Funktionen aufgerufen.
Auf jeden Fall
wird bei erfolgreichem ISCHARWAIT() die UART-Receive-Function aufgerufen
Kommentar:
Das Konzept funktioniert natürlich nur, wenn alle anstehenden Funktionen auch in etwa 10 mS durchführbar sind. Das passen aber immerhin 80 000 Instruction-Cycles rein. Was NICHT erlaubt ist, sind natürlich elegante Wait-Statements und andere Zeitfresser. Es wird von den Funktionen verlangt, daß sie derlei mit Timer-Entries und Messages abhandeln.
Kommunikation
Das "Mainboard" tauscht mit dem RNBFRA ebenfalls "Messages" aus. Grundsätzliches Format:
HEADER / SOURCE-ID / DESTINATION-ID / MsgNR / DataLen / Data (optional).......
Es war Vorgabe, keinen Message-Typ zu verwenden, daher implizieren SOURCE u. DESTINATION leider auch die Zusammensetzung der Daten. Die Datenüberträgung erfolgt transparent, d.h. jedes Byte 0-255. Üblicherweise bestehen bei Befehlen vom "Mainboard" die Daten aus einem Integer (2-Byte Intel), die Sensorwerte werden als SINGLE Float (4 Byte Intel) geschickt. Der HEADER (ein reserviertes Zeichen) dient dazu, den Beginn einer Nachricht immer erkennen zu können, auch wenn mal was davor verloren geht. Das wiederum erforderte ein weiteres reserviertes Zeichen, den PREFIX, der immer eingefügt wird (Byte-stuffing), wenn danach ein reserviertes Zeichen als Datum kommen soll. Klingt kompliziert, ist es aber nicht. Kontrollsummen wären natürlich auch möglich, schienen aber nicht notwendig.
Sensor-Alerts
Die meisten Sensoren hatten zwei individuelle Thresholds (Schwellwerte), wo folgendes geschieht: Wird der kritischere Wert überschritten, wird eine Alertnachricht an das "Mainboard" geschickt. Zusätzlich wird, je nach Sensortyp, durch die (abschaltbare) AUTO-HALT Funktion der Hauptantrieb gestoppt und das Fahrzeug angehalten. Jetzt konnte nur durch eine "over-ride" Nachricht das Fahrzeug wieder aus der Gefahrenzone gesteuert werden. Wird daraufhin der zweite, weniger kritische Werte wieder unterschritten, geht wieder alles normal. Diese HALT-Funktion ist für den Neigungs-Senor und die SF08 vorgesehen.
SD21
Die verfügbare RNS1-CoProcessor Software wäre perfekt gewesen, hatte aber einen Nachteil: Wenn das TX-Signal des MainProcessors sowohl zum MAX232 als auch zur RNS1 gesplittet wurde, müßte das "Mainboard" auch mit diesen Zeichenfolgen was anfangen oder wenigstens ignorieren können, Umgekehrt ist es ja jederzeit möglich, das eine Zeichenfolge "#s .. .." als Teil der Daten vorkommt, und das hätte Chaos verursachen können. Andererseits war es nicht zu schaffen, die I2C-Version vernünftig in Betrieb zu nehmen, also wurde die SD21 bestellt, um die Sache insgesamt einfacher zu machen. Es fehlte einfach die Zeit, eine geeignete RNS1-Version selbst zu schreiben.