Bachelorarbeit 2009 Elektronik und Software für den

Transcription

Bachelorarbeit 2009
Elektronik und Software
für den nautical robot
Betreuung:
Studenten:
Ausgabe:
Abgabe:
Prof. Dr. Roland Büchi
Dipl.Ing. ETH Andreas Breitenmoser
Hauri Samuel ME06a
Stalder Christian ME06a
09.02.2009
28.05.2009
Abstract
The Nautical Robot (naro) is a joint project of the Swiss Federal Institute of Technology,
Zürich and the Zurich University of Applied Sciences, Winterthur.
The goal of the overall project was the realization of energy-efficient underwater propulsion.
This was achieved by designing and building a model of a one meter long robot fish that
imitates of natural swimming motion of a tuna.
NARO is divided into six watertight sub-elements, which are enclosed in a flexible hull. The
main drive consists of five electric motors which are position controlled by a microcontroller.
For static and dynamic diving it is necessary to fit pectoral fins and a diving cylinder to naro.
These are driven by servo motors. Furthermore, temperature, pressure, inclination and
moisture sensors are attached to the robot. The movement of naro is controlled by a PC via
a GUI (Graphical User Interface) which sends control commands to the microcontroller.
The main task of the students of Mechatronics was to write a software solution for the
microcontroller that enables the robot to move according to a calculated movement
sequence. The software includes programs for reading of analog and digital data,
communication with the motor controllers via the CAN bus, the calculation of the
movement, the controlling of the servo motors and the communication with the PC.
Elektronik und Software für naro
1
Zusammenfassung
Der nautical robot (naro) ist ein 1 Meter langer Roboterfisch. Er wurde im Rahmen eines
Fokusprojektes der ETH Zürich in Zusammenarbeit mit der ZHAW entwickelt.
Das Ziel des Gesamtprojekts war die Realisierung eines energieeffizienten
Unterwasserantriebs durch die Nachahmung einer natürlichen Fisch-Schwimmbewegung.
Das natürliche Vorbild ist der Thunfisch, mit seinen herausragenden Schwimmeigenschaften.
Naro ist in sechs wasserdichte Elemente aufgeteilt, die mit einer flexiblen Hülle umgeben
sind. Der Hauptantrieb besteht aus fünf Elektromotoren, die von einem Mikrokontroller
positionsgeregelt werden. Um statisch und dynamisch tauchen zu können sind Brustflossen
und Tauchzylinder eingebaut. Diese werden mit Servomotoren angetrieben. Zusätzlich sind
Druck, Neigung und Feuchtigkeitssensoren vorhanden, deren Messdaten verarbeitet werden
müssen.
Gesteuert wird naro mittels PC über eine grafische Benutzeroberfläche, welche
Steuerbefehle an den Mikrokontroller sendet.
Die Hauptaufgabe der Mechatronik- Studenten lag darin, eine Software für den
Mikrokontroller zu schreiben, die es ermöglicht, den Roboter nach den berechneten
Vorgaben bewegen zu lassen. Diese Software umfasst zusätzlich das Einlesen von analogen
und digitalen Daten, die Kommunikation mit den Motorkontrollern über den CAN-Bus, das
Berechnen der Bewegungsform, die Steuerung der Servomotoren und die Kommunikation
mit dem PC.
Abbildung 1 CAD Model von naro
2
Inhaltsverzeichnis
1
Einleitung......................................................................................................................................... 6
2
Anforderungen ................................................................................................................................ 6
3
Hardware ......................................................................................................................................... 7
3.1
Verkabelung ............................................................................................................................ 7
3.2
Antrieb von naro ..................................................................................................................... 8
3.3
Hardware Komponenten......................................................................................................... 9
3.4
Die Mikrokontrollerplatine.................................................................................................... 10
3.4.1
3.5
Die Versorgungsplatine ......................................................................................................... 11
3.5.1
Die Versorgungsspannung............................................................................................. 12
3.6
CAN- Adapter- Platine ........................................................................................................... 13
3.7
Sensoren................................................................................................................................ 13
3.8
Der Mikroprozessor AT90CAN128 ........................................................................................ 14
3.8.1
Reset .............................................................................................................................. 14
3.8.2
Externer Interrupt ......................................................................................................... 15
3.8.3
Display ........................................................................................................................... 15
3.8.4
LED ................................................................................................................................. 16
3.8.5
PWM, Servomotoren - Ansteuerung ............................................................................. 16
3.8.6
Analog-Digital Wandlung............................................................................................... 17
3.8.7
Can–Bus ......................................................................................................................... 18
3.9
RS232 Schnittstelle ................................................................................................................ 19
3.10
EPOS ...................................................................................................................................... 20
3.10.1
Inbetriebnahme............................................................................................................. 20
3.10.2
RS232/CAN .................................................................................................................... 21
3.12
4
Konfigurationen an der Mikrokontrollerplatine............................................................ 11
Computer .............................................................................................................................. 22
Kommunikation ............................................................................................................................. 23
4.1
Fernsteuerung ....................................................................................................................... 23
4.1.1
Kabelkommunikation via RS232 .................................................................................... 24
4.1.2
Kommunikationsprotokoll............................................................................................. 25
4.2
Controller Area Network (CAN) ............................................................................................. 26
4.2.1
Hardware Ebene ............................................................................................................ 26
4.2.2
CAN Kommunikation ..................................................................................................... 27
4.2.3
Kollisionsvermeidung .................................................................................................... 27
3
4.2.4
Bitarbitrierung ............................................................................................................... 28
4.2.5
Frame Aufbau ................................................................................................................ 29
4.2.6
Nachrichtenfilterung ..................................................................................................... 30
4.3
4.3.1
Objektverzeichnis .......................................................................................................... 31
4.3.2
Servicedatenobjekte...................................................................................................... 31
4.3.3
Prozessdatenobjekte ..................................................................................................... 32
4.3.4
Netzwerkverwaltungsobjekt ......................................................................................... 32
4.3.5
CAN Störungssicherheit................................................................................................. 32
4.4
7
Ansteuerung der EPOS über CAN .......................................................................................... 33
4.4.1
Initialisierung des EPOS ................................................................................................. 34
4.4.2
Geschwindigkeiten setzten ........................................................................................... 34
4.4.3
Positionen auslesen....................................................................................................... 34
4.5
5
CANopen ............................................................................................................................... 31
RS232 ..................................................................................................................................... 35
Software ........................................................................................................................................ 36
5.1
Programmierumgebung ........................................................................................................ 36
5.2
Hauptprogramm .................................................................................................................... 37
5.2.1
Initialisierung ................................................................................................................. 37
5.2.2
ADC Messung ................................................................................................................ 38
5.2.3
EPOS reset ..................................................................................................................... 38
5.2.4
Homing .......................................................................................................................... 38
5.2.5
Betriebs-MODE .............................................................................................................. 38
5.2.6
ADC Ausgabe ................................................................................................................. 38
5.2.7
Überwachung ................................................................................................................ 38
5.3
RS232 Interrupt ..................................................................................................................... 39
5.4
Globale Zeitvariablen ............................................................................................................ 40
5.5
Positionsberechnung ............................................................................................................. 41
5.6
Positions- Regelung ............................................................................................................... 41
5.7
Homing .................................................................................................................................. 42
5.8
Positionslimit ......................................................................................................................... 42
5.9
EPOS Bibliothek ..................................................................................................................... 43
5.10
PWM ...................................................................................................................................... 44
6.1
Trockentests .......................................................................................................................... 44
6.2
Nasstests ............................................................................................................................... 44
Schlussfolgerung /Resultate .......................................................................................................... 45
4
8
Ausblick ......................................................................................................................................... 47
8.1
RS232 Kommunikation .......................................................................................................... 47
8.2
Kabellose Kommunikation .................................................................................................... 47
8.3
Software ................................................................................................................................ 47
9
Quellen .......................................................................................................................................... 48
9.1
Abbildungsverzeichniss ......................................................................................................... 48
10
Inhalt DVD ................................................................................................................................. 49
11
Anhang ...................................................................................................................................... 50
5
1 Einleitung
Die Idee zum Bau eines Roboter-Fisches entstammt vom Projektleiter Céderic Siegenthaler.
Er machte in seiner Maturarbeit eine Analyse der Fischbewegung, welche als Grundlage zur
Entwicklung eines Unterwasserroboters dienen sollte.
Das Projekt zur Entwicklung eines Unterwasserroboters wurde 2008 im Rahmen des
Fokusprojektes der Maschinenbau- Studenten der ETH Zürich gestartet. Da dieses Projekt
Unterstützung im Bereich Elektrotechnik benötigte wurde es auch an der ZHAW für
Mechatronik- und Elektronik- Studenten ausgeschrieben.
Mit der Entwicklung des Unterwasserroboters waren 7 Studenten zwei Semester lang
beschäftigt. Es ergaben sich sechs verschiedene Bachelorarbeiten aus dem Gesamtprojekt.
Das Ziel der Arbeit „Software und Elektronik für den nautical robot“ war die Einbindung der
simulierten Bewegungsabläufe, sowie das Überwachen des Systems und die Kommunikation
mit dem Piloten.
2 Anforderungen
Die Elektronik und Software müssen es ermöglichen, naro nach den gewünschten
Bewegungsformen positionsgeregelt über eine Fernsteuerung zu bewegen. Die Vorgaben,
was das System alles umfassen soll, welche Bauteile verwendet werden und wie der Aufbau
aussieht, wurde in der vorhergehenden Arbeit „Antriebskonzept naro“ festgelegt. Folgende
Gesamtübersicht zeigt das geplante System, welches in der Bachelorarbeit zu realisieren
war.
Schema 1 Mikroprozessor mit Peripherie
Bei der Software stehen dabei die Anwenderfreundlichkeit und die Sicherheit im
Vordergrund. Zudem sollte sie einfach erweiterbar sein. Die Software soll auch eine
Überwachung der Zustände und Sensorwerte ermöglichen, damit man sofort auf wichtige
6
Ereignisse reagieren kann. Die zeitabhängigen Winkel aller Gelenke müssen in Echtzeit von
der Software berechnet werden.
Zum jetzigen Zeitpunkt sind keine autonomen Funktionen geplant, naro soll vollständig
ferngesteuert werden.
3 Hardware
Die Hardware von naro setzt sich aus sehr unterschiedlichen Komponenten zusammen.
Dabei müssen diese so gut auf einander abgestimmt sein, dass auch in einem
unvorhergesehenen Extremfall möglichst keine Schäden am System und an der Umwelt
entstehen. Durch den Unterwasserbetrieb der Elektronik besteht immer die Gefahr von
eintretendem Wasser, das Kurzschlüsse verursachen kann.
3.1 Verkabelung
Um das Ein- und Ausbauen der Hardware zu vereinfachen wurden alle Verbindungen mit
Steckern versehen. Dadurch ist der Ein- und Ausbau der Hardware trotz sehr engen
Platzverhältnissen in vernünftiger Zeit möglich. Durch die Steckverbindungen erhöhen sich
jedoch die Verwechslungsgefahren sowie die Fehlerquoten durch schlechte Kontakte.
Abbildung 2 Box Nr.2 randvoll mit Elektronik
Die elektronischen Hardwarekomponenten wurden zum Schutz vor Nässe mit einem
Schutzlack versiegelt.
Um Störeinflüsse abzudämpfen, wurden CAN- Bus Kabel mit Abschirmung verwendet. Diese
Abschirmung wurde zudem mit den Gehäusen der EPOS, der Masse des Akkus und mit den
metallischen Teilen der Konstruktion verbunden.
7
3.2 Antrieb von naro
Der Hauptantrieb von naro besteht aus fünf Bürstenlosen- DC Motoren mit jeweils 50 Watt
Leistung und einem 190: 1 Getriebe, die von fünf Motorkontrollern angesteuert werden.
Zusätzlich sind vier Servomotoren im Einsatz, zwei für die beiden Brustflossen und zwei für
die beiden Tauchzylinder. Mit den Tauchzylindern kann statisch, mit den Brustflossen kann
dynamisch getaucht werden. Alle Motoren, ausser den Tauchzylinder Servomotoren, sind
aus Platzgründen im zweiten Segment untergebracht. Die hinteren Elemente werden durch
Bowdenzüge aus dem zweiten Element bewegt. Die Tauchzylinder befinden sich im ersten
und dritten Segment.
•
•
•
•
•
Motor EC22 50W von Maxon
Motorkontroller EPOS 24/5 von Maxon
Getriebe 190:1 GP 32C von Maxon
Tauchzylinder Servomotor REGATTA von Graupner
Brustflossen Servomotor HS82MG Von HiTech
Abbildung 3 Antriebsübersicht von naro
8
3.3 Hardware Komponenten
Zur Steuerung von naro wird ein Mikrokontroller eingesetzt. Da bereits Erfahrungen mit
Atmega Mikrokontrollern bestanden, welche zudem unseren Anforderungen gerecht
wurden, fiel die Entscheidung bereits in der Konzeptphase auf diesen Mikrokontrollertyp.
Zur Verdeutlichung der verwendeten elektronischen Hardware von naro dient die folgende
Skizze.
Schema 2 Mikroprozessor mit Peripherie
Überblick über die Peripherie des Mikrokontrollers:
A:
Naro wird über einen Computer gesteuert. Die Datenübertragung erfolgt seriell
mittels eines etwa 30m langen Kabels. Es wird die RS232 Schnittstelle verwendet, sie
benötigt auf der Mikrokontrollerplatine ein Treiber- IC, welcher den TTL- Pegel des
Mikrokontrollers auf den 12 Volt Pegel des RS232 Standards anhebt.
Es ist eine bidirektionale Kommunikation möglich.
B:
Um naro in Notfällen kontrolliert auszuschalten, ist ein Notaustaster angeschlossen.
Dieser ist mit einem Interrupt- Eingang gekoppelt und damit immer ansprechbar.
Es kann auch ein Kabelunterbruch detektiert werden. Das Notaus- Kabel wird parallel
mit dem RS232 Kabel geführt.
C:
Für eine schnelle und günstige Betriebsüberwachungsfunktion wurde ein Display in
naro eingebaut. Um jedoch Rechenressourcen zu sparen, wurde es in der endgültigen
Softwareversion wieder entfernt. Die Statusausgabe erfolgt nun über zwei LEDs.
Die Ansteuerung erfolgt direkt mit einem I/O Pin pro LED.
Mit dem gleichen Prinzip wird auch ein Relais gesteuert, welches die
Gesamtversorgung von naro schaltet.
9
D:
Es sind zwei Servomotoren eingebaut, welche die Brustflossen bewegen. Diese
benötigen jeweils ein Steuersignal für die Position und eine 5 Volt Speisung. Das
Steuersignal wird in den meisten Fällen direkt vom Piloten vorgegeben.
E:
Zum Bewegen der beiden Tauchzylinder werden zwei Servomotoren benötigt. Es
werden spezielle Modellbau- Servomotoren eingesetzt, welche mehrere
Umdrehungen fahren können.
Damit werden bis zu 0.4 Liter Volumenunterschied ermöglicht, bei gleichbleibendem
Gewicht von naro.
F:
Die Akkuspannungen werden im Betrieb vom Mikroprozessor überwacht. Dies erfolgt
jeweils mit einem Analogeingang. Sobald die Spannung einen kritischen Wert
unterschreitet, wird dies über die LED- Statusausgabe angezeigt und über RS232
kommuniziert.
G:
Zusätzliche Sensoren nehmen im Betrieb verschiedene Messdaten auf, welche
unterschiedlich verarbeitet werden. Es wurde darauf geachtet, dass die Sensoren
einen analogen Ausgang besitzen, welcher eine Spannung von 0-5V proportional zur
Messgrösse liefert. Dadurch sind die Beschaltung und Auswertung einfacher
geworden.
H:
Den Motorkontrollern (EPOS) sendet der Mikrokontroller die Sollgeschwindigkeit über
den CAN-Bus. Für die Regelung werden die Positionsdaten ausgelesen. Für jeden
Motor wird ein Motorkontroller benötigt. Die Datenrate der Verbindung ist einstellbar
und wurde auf 1 MBit/s festgelegt.
3.4 Die Mikrokontrollerplatine
Die Entwicklung einer eigenen Mikrokontrollerplatine konnte aus Zeitgründen nicht
berücksichtigt werden. Dies wurde jedoch auch nicht angestrebt, da es bereits unzählige
Entwicklungsplatinen zu kaufen gibt, welche exakt unseren Anforderungen an Grösse und
vorhandene Zusatzkomponenten entsprechen.
In naro wird die
Mikrokontrollerplatine D071
vom Hersteller Display3000
eingesetzt.
Abbildung 4 Mikrokontroller- Platine
10
3.4.1 Konfigurationen an der Mikrokontrollerplatine
Dadurch, dass der Mikrokontroller sehr universell einsetzbar ist und auch die Platine
entsprechend aufgebaut ist, war es nötig einige Hardwarekonfigurationen vorzunehmen.
Zur Benutzung des CAN- Busses mussten die Lötbrücken J7 und J8 geschlossen werden.
Dadurch sind die beiden Datenleitungen CAN_H und CAN_L an den zusätzlichen CAN
Treiber-IC angeschlossen. Die gleiche Anpassung musste auch für die RS232 Schnittstelle
vorgenommen werden (Lötbrücke J5 und J6). Die Mikrokontrolleplatine besitzt zwei RS232
Schnittstellen (RS232_0 und RS232_1), wobei für naro nur RS232_1 verwendet wird.
Die Referenzspannung des AD- Wandlers des Mikroprozessors ist standartmässig bereits auf
die Versorgungsspannung (5V) gelegt. Es mussten hier keine Anpassungen vorgenommen
werden.
Das Display wurde vom Mikrokontrollerprint entfernt und mit einem Flachbandkabel
versehen, um es so an den vorgesehenen Ort in der Box Nr. 1 zu platzieren.
Die Mikrokontrollerplatine hängt direkt mit der Versorgungsplatine zusammen. Die
Datenleitungen der Sensoren werden auch über diese Versorgungsplatine geleitet. Dies hat
den Vorteil, dass alle Analogsignale über ein Flachbandkabel an den Mikrokontroller
angeschlossen werden.
3.5 Die Versorgungsplatine
Zur Spannungsversorgung der verschiedenen Komponenten wurde von der ETH eine
Versorgungsplatine nach unseren Wünschen entwickelt. Damit wird die Speisung über einen
zentralen Knotenpunkt geführt. Dies ermöglicht eine einfache und schnelle Fehlersuche,
sowie eine effizientere Ausnutzung der Platzverhältnisse. Die Versorgungsplatine liefert zwei
konstante 5V Spannungen, eine für den Mikrokontroller und die Sensoren, die zweite zur
Versorgung der Servomotoren. Durch die Trennung dieser Speisungen wird sichergestellt,
dass die Servomotoren keine Störsignale auf der Mikrokontrollerspeisung erzeugen. Die
Motorkontroller werden über die Versorgungsplatine direkt mit der Akkuspannung versorgt.
11
3.5.1 Die Versorgungsspannung
Die Versorgungsspannung für naro wird durch zwei Lithium-Polymer Akkus erzeugt, welche
über eine Sicherung an die Versorgungsplatine angeschlossen werden. Sie werden in Serie
geschaltet und erzeugen so eine Spannung von rund 24V. Zur vollständigen Abtrennung der
Speisung wird ein Halbleiterrelais in den Stromkreislauf eingesetzt, welches mit einem Taster
eingeschaltet werden kann. Zusätzlich ist auch der Mikrokontroller mit dem Steuereingang
verbunden.
Mit diesem Schaltaufbau ist es möglich,
die Versorgungsspannung für naro von
aussen, mit Hilfe eines Magneten, über
den Reed-Taster, einzuschalten. Sobald
der Mikroprozessor gespiesen wird,
wird der Pin D1 mittels Software auf 5V
geschaltet. Der Steuereingang des
Halbleiterrelais benötigt eine Spannung
von 3-30V. Durch die Diode wird der
Mikrokontroller vor Überspannung
geschützt.
Schema 3 Versorgungsspannungsbeschaltung
12
3.6 CAN- Adapter- Platine
Durch den Zusatz- IC von Phillips (PCA82C250) wird die CAN- Unterstützung der
Mikrokontrollerplatine vervollständigt. Diese befindet sich, bei der in naro verwendeten
Hardware, auf einem Zusatz- Print. Dieser wurde von der Firma Display3000 mitgeliefert.
Dieser Zusatz- Print benötigt eine stabilisierte 5 Volt Speisung und beinhaltet bereits einen
Abschlusswiderstand für den CAN-Bus (R4).
Schema 4 CAN- Adapter- Board
Mit R3 kann die Baudrate des Busses eingestellt werden. Für die in naro verwendeten
1MBit/s ist R3 = 0Ohm.
3.7 Sensoren
Es sind momentan drei verschiedene Sensortypen eingebaut. Diese dienen zur Überwachung
und Regelung des Systems.
Drucksensor: Honeywell 40PC Series 40PC01562A
Der Drucksensor wird für die Tiefen- Regelung der Tauchzylinder benötigt, er hat einen
Arbeitsbereich von 0 bis 1 bar und eine Auflösung von 7mbar, das analoge Ausgangssignal ist
proportional zum Druck zwischen 0.5 und 4.5V
Neigungssensor: KAS804 54 von Kelag
Der Neigungssensor wird auch zur Regelung der Tauchzylinder benötigt, durch diesen Sensor
kann sich naro in der horizontalen Ebene stabilisieren. Der Neigungssensor hat eine
Auflösung von 0.2° und ein Ausgangssignal zwischen 0 und 5V. Es werden zwei Achsen
gemessen.
Feuchtigkeitssensor: HIH-4000 Honeywell
Der Feuchtigkeitssensor dient zur Sicherheit des Roboters, sobald die Feuchtigkeit einen
Grenzwert überschreitet wird mittels Mikroprozessor die Stromversorgung unterbrochen.
13
3.8 Der Mikroprozessor AT90CAN128
Der verwendete Mirkoprozessor der Firma Atmel ist ein 8Bit- RISC- Prozessor. Er wird mit
einem 16MHz Quarz getacktet und benötigt eine stabilisierte 5 Volt Speisung. Beim
AT90CAN128 handelt sich um einen Prozessor mit zusätzlich integriertem CAN-Controller,
sowie einem128 kByte Flash- Speicher und über 50 programmierbaren IO Anschlüssen.
Zudem stellt dieser Mikroprozessor 8 separate AD- Wandlereingänge zur Verfügung, welche
mit einer Auflösung von 10Bit und einem Eingangsbereich von 0- 5 Volt arbeiten.
Damit können die verwendeten Sensoren mit einer Auflösung von bis zu 1024 Messpunkten
ausgelesen werden. Für den Anwendungsbereich von naro reicht diese Auflösung.
Es werden auch verschiedene Interrupt- Funktionen verwendet. Der Mikroprozessor hat 37
unterschiedliche Interrupt- Quellen. In naro wird ein Timer- Interrupt (SW), ein UARTInterrupt (für die RS232- Schnittstelle, SW) und ein externer Interrupt (HW) benutzt.
3.8.1 Reset
Sobald der Reset- Eingang des Mikrokontrollers auf Masse geschalten wird, wird der
Programmcounter auf die Startadresse 0x00 zurückgesetzt. Dies bewirkt, dass das Programm
von neuem gestartet wird. Alle Ausgänge des Mikrokontrollers werden während diesem
Vorgang zudem auf logisch Null gesetzt, also auf Ground- Potential.
Dies hat zur Folge, dass das Halbleiterrelais am Steuereingang keine Spannung hat, und so
die Versorgung unterbrochen wird. Somit kann die Stromversorgung von naro mit dem
Reset- Eingang ausgeschalten werden.
Durch die Verwendung eines Reed-Tasters erfolgt das Ausschalten wie auch der bereits
beschriebene Einschaltvorgang berührungslos mittels eines Magneten.
Der Reset- Taster ist direkt auf dem
Mikrokontroller- Board aufgelötet und wird nur zu
Testzwecken verwendet, wenn das Board
ausgebaut ist.
Schema 5 Reset Schaltung
14
3.8.2 Externer Interrupt
Der externe Interrupteingang detektiert das Potential am entsprechenden Eingang des
Mikrokontrollers. Dieser Pin wird dazu verwendet, um naro im Notfall oder im Falle einer
Unterbrechung des Kabels sofort in den Notauftauch- Modus zu versetzten. Dazu ist eine
parallele Leitung (Ext_Int) zu den Steuerleitungen (RS232) gelegt. Diese ist am
Mikrokontroller an den Pin PD0 angeschlossen. Sobald das Potential logisch Null entspricht
wird die entsprechende Interruproutine ausgeführt und dadurch das Notauftauch- Szenario
eingeleitet.
Auf der Piloten Seite von naro ist folgende Schaltung angeschlossen:
Dadurch wird die Ext_Int Leitung auf 5V
gehalten, bis der Taster gedrückt wird.
Zusätzlich kann mit dieser Beschaltung
auch ein Kabelbruch detektiert werden,
da in einem solchen Fall Ext_Int nicht
mehr auf 5V Potential ist.
Schema 6 Externer Interrupt
3.8.3 Display
Das Mikrokontroller- Board von Display3000 wurde mit einem 2.1 Zoll Display geliefert. Es ist
ein Farbdisplay mit einer Auflösung von 176 x 132 Pixel.
Das Display wird in erster Linie zur Fehleranalyse während der Software- Entwicklung
verwendet.
Weil das Display viel Rechenleistung des Mikrokontrollers benötigt, wurde es in der
endgültigen Schwimmsoftware nicht mehr verwendet. Zudem ist der Einbauort durch einen
Tauchzylinder versperrt.
Der Displaytreiber zum ansprechen des Displays wurde mit der Mikrokontrollerplatine
mitgeliefert und ist von auf der DVD aufgeführt.
15
3.8.4 LED
Die eingebauten Leuchtdioden werden zur Statusausgabe verwendet.
Eine rote (LED 1) und eine grüne (LED power) sind in naro eingebaut. Sie werden direkt mit
dem Mikrokontroller via Software angesteuert.
Mit der roten Leuchtdiode werden Fehler angezeigt,
die grüne wird für die Betriebsanzeige verwendet.
S
c
S
Schema 7 LEDs
3.8.5 PWM, Servomotoren - Ansteuerung
Es werden vier Servomotoren angesteuert, welche jeweils ein PWM Signal als Sollposition
benötigen. Diese Signale werden mit einem Timer erzeugt. Für eine genügend hohe
Auflösung werden zwei 10 Bit Timer verwendet.
Servomotoren benötigen wie in Abbildung 4 ersichtlich ein 50 Hz PWM Signal das während
1-2 ms auf logisch High ist. Die speziellen Servomotoren der Tauchzylinder können im
Gegensatz zu den Standard Servomotoren bis zu fünf Umdrehungen fahren (1800°)
benötigen aber das gleiche PWM Signal, 2ms entsprechen somit 1800° anstatt 180°.
Abbildung 5 Servomotor- Position und PWM Signal
16
3.8.6 Analog-Digital Wandlung
10
Der 10 Bit Analog Digital Wandler (ADC) hat eine Auflösung von 2 Bit= 1024 Messpunkte,
bei einer Referenzspannung von 5V bedeutet das eine Diskretisierung in 4.9mV Schritten.
Bei dem verwendeten Mikrokontroller stehen 8 ADC Eingänge zur Verfügung.
Mit diesen Eingängen werden die Sensoren und die Akkuspannungen überwacht.
Für das auslesen der beiden Akkuspannungen werden noch Spannungsteiler benötigt. Diese
wurden auf der Versorgungsplatine der ETH nicht korrekt aufgebaut. Die Verbesserung ist
aus dem folgenden Schema ersichtlich.
Schema 8 Analog Digital Wandlung der Akkuspannung
17
3.8.7 Can–Bus
Der AT90CAN128 unterstützt alle vier möglichen CAN - Nachrichten Arten (Data, Remote,
Error und Overload). Ausserdem ist er kompatibel zur CAN- Spezifikationen 2.0A und 2.0B
(extended Identifier) und unterstütz eine CAN Baudrate von bis zu 1 MBit/s (siehe Kapitel Nr
4.2 CAN).
Damit erfüllt er alle Anforderungen an einen CAN-Busteilnehmer. Zusätzlich besitzt der
Mikrokontroller 15 Message Objects mit jeweils einem eigenen 29 Bit Identifier, einer 29 Bit
Identifier Maske und einem 8 Byte Datenpuffer.
Die wichtigsten Register des Mikroprozessors in Bezug auf den CAN- Bus werden im
folgenden kurz erläutert. Die ausführliche Beschreibung aller Register und Funktionen findet
man im Datenblatt des AT90CAN128 auf den Seiten 232-266.
•
•
•
•
•
•
•
•
CAN General Control Register (CANGCON) S.250
Mit diesem Register wird zum Beispiel der CAN Transciever aktiviert, das heisst in den
Enable- oder Standby- Modus gesetzt.
CAN General Status Register (CANGSTA) S.251
Hier kann der Status des Transciever ausgelesen werden.
CAN Page MOb Register (CANPAGE) S.258
Hier wird das aktuelle Message Objekt (MOb) ausgewählt.
CAN Mob Status Register (CANSTMOB) S.259
Mit diesem Register kann anhand der RXOK und TXOK Bits überprüft werden ob der
Transciever erfolgreich eine Nachricht empfangen oder verschickt hat. Die restlichen
Bits enthalten verschiedene Error Flags.
CAN Mob Control and DLC Register (CANCDMOB) S.260
Hier wird der Data Length Code also die länge einer Nchricht für eine Übermittlung
festgelegt und das IDE (Identifier extension Bit) gesetzt, je nach dem ob ein 11 oder
29Bit Identifier gebraucht wird. Zusätzlich wird hier auch die Betriebsart des
aktuellen MObs eingestellt.
CAN Identifier Tag Registers (CANIDT1-4) S.261
Mit den CANIDT Register 1-4 wird der Identifier des ausgewählten MObs gespeichert.
CAN Identifier Mask Registers (CANIDM1-4) S.262
Mit den CANIDM Register 1-4 wird die Identifier Maske des ausgewählten MObs
gespeichert.
CAN Data Message Register (CANMSG) S.263
Hier werden die ein- und ausgehenden Nachrichten gespeichert. Nach einem
Schreib- oder Lesezugriff wird der Zeiger automatisch erhöht. Der Anwender muss
also, um eine Nachricht auszulesen, das CANMSG Register achtmal nacheinander
auslesen.
18
3.9 RS232 Schnittstelle
Der Mikrokontroller unterstützt, wie bereits mehrfach erwähnt, die Kommunikation mit dem
RS232 Standard. Die verwendete Schnittstelle wird auf Seiten des Kontrollers USART
genannt und ist Im Datenblatt ab Seite 177, Kapitel 17, beschrieben.
Die Schnittstelle muss vor der Benützung initialisiert werden. Dazu muss die verwendete
Baudrate, das Sende- Format und der, falls erwünscht, Interrupt konfiguriert werden. Dazu
stehen fünf verschiedene Register zur Verfügung (UBRR1H, UBRR1L, UCSR1A, UCSR1B,
UCSR1C).
In das Register UBRR wird die Baudrate geschrieben, dieser Wert berechnet sich mit
folgender Formel:
–1
16 · Es ist zu beachten, dass das Register UBRR1H vor UBRR1L beschrieben werden muss, da der
Schreibzugriff auf UBRR1L ein neusetzen des Prozessorinternen Vorteilers auslöst.
Die Fehlerrate welche sich durch den Verwendeten Systemtakt und die Baudrate ergibt,
berechnet sich wie folgt:
1
% " 1# · 100
! 1
Bei einer verwendeten Taktfrequenz von 16 MHz und einer Baudrate von 38400 Bit/s ist
UBRR = 25 und die Fehlerrate liegt bei 0.16 %.
Werte unter 1 % sind für die Kommunikation unkritisch.
Durch die starke Verbreitung der Schnittstelle gibt es im Internet eine grosse Anzahl
nützlicher Beispielprogrammen.
19
3.10 EPOS
Der EPOS 24-5 von Maxon ist ein digitaler Positionsregler für bürstenlose sowie normale
Gleichstrom- Elektromotoren mit digitalen Hall Sensoren und Encodern. Die integrierte
Position, Geschwindigkeits- und Strom- Regelung, ermöglicht dem Anwender eine Vielzahl
an Einsatzmöglichkeiten. Die EPOS sind für eine
Ansteuerung über CANopen entwickelt worden. Sie
unterstützen jedoch auch eine Ansteuerung über die
serielle RS232 Schnittstelle, wobei in diesem Fall ein
EPOS als Gateway dient. Es gibt ein Konfigurationstool
von Maxon mit dem alle Parameter mit einem PC
über die RS232 Schnittstelle eingestellt werden
können. Dies ist sehr nützlich, da es einige
Einstellungen gibt, welche nur einmal eingestellt
werden müssen, zum Beispiel, welcher Motor
angeschlossen ist, oder die Baudrate des CAN Busses.
Abbildung 6 EPOS Positionskontroller
3.10.1 Inbetriebnahme
Die Inbetriebnahme des EPOS 24-5 ist mit der Dokumentation
„EPOS 24-5 Getting Started.pdf“ gut beschrieben. Diese Anleitung wird vom EPOS Hersteller
Maxon zur Verfügung gestellt. Damit ist es möglich den EPOS in Betrieb zu nehmen und den
angeschlossenen Motor ein erstes Mal über die EPOS_User Interface Software in Betrieb zu
nehmen.
Über das EPOS_User Interface können alle Einstellungen des EPOS gemacht werden und die
verschiedenen Betriebsarten getestet werden. Mit einem Matlab- Programm von Dario
Schafroth (ETH- Zürich), welches die von Maxon zur Verfügung gestellte Windows DLL lädt,
war es möglich nach kleinen Modifikationen des Programms die Motoren auch mit Matlab
über RS232 anzusteuern.
20
3.10.2 RS232/CAN
Wie bereits erwähnt, können die EPOS über zwei verschiedene Arten angesteuert werden.
Aus Geschwindigkeitsgründen wurde entschieden, die Motoren über den CAN- Bus
anzusteuern. Mit einer maximalen CAN Baudrate von 1 Mbit/s dauert eine Positionsanfrage
260 µs, über die RS232 mit einer maximalen Geschwindigkeit von 115200 Bit/s dauert
dieselbe Anfrage mehr als 2 ms. Dies wäre für unsere Positionsregelung zu langsam.
Tabelle 1 Theoretische Übertragungs- Geschwindigkeiten von CAN und RS232
21
3.12 Computer
Es wurden im Verlauf der Arbeit mehrere Computer benötigt, einerseits um über ein Matlab
GUI naro fernzusteuern, aber auch um die Kommunikation zu testen und zu überwachen.
Die verwendeten Computer und Softwares laufen alle unter Windows XP. Hier eine kurze
Übersicht von den verwendeten Softwares.
• AVR Studio 4 als Programmierumgebung für den Mikrokontroller
• Code Vision AVR wurde als RS232 Terminal verwendet um die RS232 Kommunikation
zu überwachen und zu debuggen.
• EPOS_User Interface für die Konfiguration und Inbetriebnahme der EPOS
• EPOS Studio ist die erweiterte Version des EPOS_User Interface
• CAN232 Software für einen CAN- Adapter um CAN- Nachrichten zu Testzwecken vom
PC aus zu senden und zu empfangen.
Alle verwendeten Softwares sind auf der DVD zu finden.
22
4 Kommunikation
In diesem Kapitel wird beschrieben, wie die Verbindung zwischen einem Piloten und naro
funktioniert, aber auch wie einzelne Komponenten in naro untereinander Daten
austauschen. Dies geschieht auf sehr unterschiedliche Weise, einerseits die serielle RS232
Kommunikation sowie die Benutzung des CANopen Protokolls.
4.1 Fernsteuerung
Das Konzept sieht eine Kommunikation zwischen einem Piloten und naro vor. Dazu ist eine
universelle und stabile Kommunikationsverbindung erforderlich.
Für eine angenehme und „sanfte“ Steuerung wird eine Senderate von mindestens 10
Befehlen pro Sekunde benötigt.
Ein solcher Befehl muss die Schwimmfunktion für die EPOS, die zwei Positionen der
Brustflossen (B1 & B2) und die zwei Tauchzylinder (T1 & T2) beeinflussen können.
Um die Schwimmfunktion vollständig berechnen zu können, werden fünf Variablen benötigt.
Alle diese Daten können mit jeweils einem Byte pro Wert übertragen werden.
Die zu übertragende minimal- Message ist folglich 10 Byte gross. Die Übertragungszeit darf
dafür 0.1 Sekunden nicht überschreiten.
Ein wichtiges Kriterium für die Kommunikation ist neben der Geschwindigkeit die
Übertragungssicherheit. Deshalb werden zusätzlich noch Reserve- und Check- Bytes
zugefügt.
Somit werden für eine vollständige Kommunikation, zwei Messages mit jeweils 7 Bytes
Länge gesendet. Die Unterteilung in zwei einzelne Message- Pakete erhöht die
Übertragungssicherheit.
Abbildung 7 RS232 Messages
In einer ersten Version wird naro einen maximalen Abstand von etwa 30 Meter zum Piloten
haben.
Da bis zum Abschluss des Projekts nicht mit einer drahtlosen Kommunikation gerechnet
werden kann, wird ein Kabel eingesetzt. Dies ermöglicht zudem eine bidirekionale
Kommunikation. Bei der Entwicklung der Übertragungsart wurde darauf geachtet, dass die
drahtlose Kommunikationeinheit einfach adaptierbar ist und nur das momentan verwendete
Kabel ersetzt.
23
4.1.1 Kabelkommunikation via RS232
Aufgrund der folgenden Vorteile und den erwähnten Anforderungen wurde die
Kommunikation zwischen dem Piloten und naro mittels RS232 Standard erarbeitet.
Diese Übertragungsart bietet für unsere Zwecke die besten Voraussetzungen:
• Einfache Ansteuerung, da verbreitet und bewährter Standard
• Schnelle, byteweise Übertragung der Daten
• Einfache Erweiterung
• Stabile Verbindung
Rahmenbedingungen:
Kabellänge:
30 m
Datengrösse:
14 Byte
Prozessortakt:
16 MHz
Die RS232 Kommunikation wurde bei der Entwicklung für eine Kabellänge von 15 m
ausgelegt, dies jedoch bei einer Übertragungsrate von 20 kBit/s. Bei langsameren
Übertragungsraten kann die Kabellänge proportional dazu berechnet werden:
Dies ergibt eine Übertragungsrate von ca. 9600 Bit/s für 30m Kabellänge.
Bei den durchgeführten Tests wurde jeweils mit 38400 Bit/s gearbeitet, es gab keinerlei
Übertragungsprobleme und die theoretische Fehlerrate liegt unter 0.2%.
Da nicht genau vorhersagbar ist, wann der Pilot die Steuerdaten sendet, benötigen wir für
den Datenempfang einen Interrupt. Dieser wird ausgelöst, sobald der Empfangspuffer voll
ist. Da unsere Messages jeweils 7 Bytes lang sind, ist auch der Empfangspuffer 7 Bytes gross.
Die bei diesem Interrupt auszuführende Interrupt- Routine liest die Daten aus dem Puffer,
überprüft diese und löscht anschliessend den Puffer.
24
4.1.2 Kommunikationsprotokoll
Die Interruptroutine bei einem Puffer- Overflow- Interrupt welche bei einem vollen
Empfangspuffer ausgeführt wird enthält das Auslesen und die Überprüfung der Daten. Sind
die Daten korrekt, werden sie in die jeweiligen globalen Variablen zur Weiterverarbeitung
gespeichert. Liegt ein Fehler in den empfangenen Daten vor, werden diese verworfen und
ein Message- Error Zähler um eins erhöht. Dies ermöglicht eine Auswertung von falsch
übertragenen Daten
Das Protokoll der Daten:
Byte-Nr
1
2
3
4
5
6
7
Wert
0-254
0-254
0-254
0-254
0-254
0-254
255
Typ
Reserve 1
EPOS_A
EPOS_F
EPOS_P
EPOS_O
EPOS_5
Message-Check 1
Byte-Nr
1
2
3
4
5
6
7
Wert
0-254
0-254
0-254
0-254
0-254
0-254
255
Typ
Brustflosse L
Brustflosse R
Tauchzylinder 1
Tauchzylinder 2
Reserve 2
MODE
Message-Check 2
Tabelle 2 Das Datenprotokoll der zwei Messages
Die Auswertung der empfangenen Daten erfolgt durch byteweises Auslesen aus dem
Empfangspuffer. Es wird immer dieselbe Empfangsstruktur erwartet. Sollte sich diese
Vorgabe durch einen Fehler verschieben, wird die Message nicht ausgewertet. Die Detektion
einer fehlerhaften Message wird mit dem Message- Check- Byte ermöglicht. Dieses muss
zwingend den Wert 255 enthalten. Zudem müssen alle anderen Daten- Bytes ungleich 255
sein. Wird dies so detektiert, wird die Message als korrekt interpretiert.
Eine Erweiterung der Software ist hier noch nötig, um eine Neusynchronisation zwischen
Sender/Empfänger zu ermöglichen. Dies wird im Kapitel Ausblick beschrieben.
25
4.2 Controller Area Network (CAN)
Controller Area Network (CAN) ist ein asynchrones, serielles Feldbussystem. Grundsätzlich
arbeitet es nach dem Multi – Master - Prinzip bei welchem alle Busteilnehmer
gleichberechtig sind. Normalerweise werden die Daten über Kupferleitungen übertragen, es
gibt aber auch Licht- Wellen – Leiter, oder Funk - Lösungen.
Entwickelt wurde es ab 1983 von der Firma Bosch, um Steuergeräte in Autos zu vernetzen.
Das Hauptziel war es, die kilometerlangen Kabelbäume zu ersetzten. Heutzutage wird CAN
hauptsächlich in den Bereichen Automobil-, Transport-, Automatisierungs-, Roboter- und
Medizintechnik eingesetzt. Die Kommunikation erfüllt hohe Anforderungen an
Echtzeitfähigkeit, Prioritätssteuerung, automatisierte Fehlermeldungen und an die
Sicherheit. Die Anwenderschicht wird durch die auf CAN aufsetzenden Protokolle DeviceNet,
SDS, CAL und CANopen definiert.
4.2.1 Hardware Ebene
In der normalen Ausführung über Kupferdrähte, besteht der Bus aus zwei verdrillten Adern
und einer gemeinsamen Masse. Die Adern werden mit CAN_High und CAN_Low und Ground
bezeichnet. Es werden zudem zwei Abschlusswiderstände mit je 124 Ω benötigt. Ein Betrieb
mit nur zwei Adern (CAN_High und Ground) ist auch möglich und wird verwendet, wenn die
Übertragungsgeschwindigkeit gering bleibt oder als Notlösung, wenn eine Ader ausfällt. Bei
der üblichen Ausführung wird auf der CAN_Low Ader das invertierte CAN_High Signal
übertragen, durch diesen Aufbau werden Gleichtaktstörungen unterdrückt. Die maximale
Länge des Busses wird durch die Übertragungsgeschwindigkeit limitiert.
• 1MBit/s:
20…40m
• 100kBit/s:
bis 500m
• 10kBits/s:
bis 6300m
Schema 9 Hardware des CAN-Busses
26
4.2.2 CAN Kommunikation
Die Kommunikation zwischen zwei Busteilnehmern erfolgt auf dem Producer Consumer
Model. Ein Teilnehmer sendet seine Nachricht nicht wie üblich an eine bestimmte Adresse,
sondern nach dem Rundfunk Prinzip an alle. Jede Nachricht hat einen eigenen Identifier,
somit kann jeder Empfänger entscheiden, ob diese Nachricht für ihn relevant ist. Meistens
erfolgt das Versenden auf Anfrage, also zum Beispiel nur, wenn sich ein bestimmter Wert
ändert. Dies erlaubt eine prinzipiell geringere Busbelastung gegenüber dem zyklischen
Master- Slave Verfahren.
4.2.3 Kollisionsvermeidung
Der CAN-Bus arbeitet nach dem Carrier Sense Multiple Acces and Collison Resolution
(CSMA/CR) Verfahren, was soviel bedeutet wie Mehrfachzugriff mit Trägerprüfung und
Kollisionsvermeidung. Die Kollisionsvermeidung wird durch eine Bitarbitrierung erreicht.
Jede Nachricht auf dem Bus hat eine Priorität. Falls zwei Busteilnehmer gleichzeitig eine
Nachricht senden wollen, wird automatisch nur diejenige mit der höheren Priorität
gesendet, die andere kommt in eine Warteschlange und wird später gesendet. Diese
Priorität wird durch den Nachrichtenidentifier festgelegt. Daraus ergibt sich der grosse
Vorteil, dass besonders wichtige Nachrichten auch bei hoher Busbelastung mit kleiner
Latenzzeit übermittelt werden können. Dies ist mit anderen Bussystemen kaum möglich und
kann bei schwerwiegenden Fehlern sehr wichtig sein. Solange also nicht andauernd
Nachrichten mit hoher Priorität gesendet werden, kann eine Aussage über die maximale
Latenzzeit gemacht werden. Mit zunehmender Busbelastung wird das System aber immer
weniger deterministisch.
27
4.2.4 Bitarbitrierung
Die Arbitrierung ist ein Verfahren zur gerechten Verteilung von Ressourcen auf verschiedene
Geräte. Auf den CAN-Bus bezogen beschreibt es ein Verfahren zur Prioritätssteuerung, falls
mehrere Busteilnehmer gleichzeitig senden wollen.
Der Identifier jeder Nachricht besteht aus dominanten und rezessiven Bits. Falls mehrere
Teilnehmer gleichzeitig senden wollen werden die rezessiven von den dominanten Bits des
Identifiers überschrieben, die CAN- Kontroller erkennen das und wissen ob sie weiter senden
dürfen oder nicht. Die Nachricht mit dem kleinsten Identifier hat also die höchste Priorität
und darf als erstes gesendet werden.
Abbildung 8 Bitarbitrierung
28
4.2.5 Frame Aufbau
Der Aufbau einer CAN Nachricht ist in Abbildung 9 ersichtlich. Es gibt zwei verschiedene
Versionen für den Identifier, CAN 2.0A arbeitet mit einem 11 Bit Identifier, Version 2.0B mit
einem 29 Bit Identifier. Da diese beiden Versionen zueinander kompatibel sein sollen, gibt es
das Identifier Extension Bit (IDE) in welchem steht, ob der Identifier 11 oder 29 Bit hat. In
den vier „Data length Code“ (DLC) Bits steht, wie viele Nutzdaten übertragen werden, wobei
maximal acht Byte Daten pro Nachricht versendet werden können.
Es gibt vier verschieden Nachrichtentypen:
•
•
•
•
Data Frame (Datentelegramm) für die Übertragung von bis zu 8Byte Daten im
Broadcasting- Verfahren (Rundfunk-Verfahren)
RemoteFrame (Datenanforderungstelegramm) für das Anfordern von Nachrichten
Error Frame (Fehlertelegramm) für die Signalisierung eines vom Teilnehmer
erkannten Fehlers (hohe Priorität)
Overload Frame (Überlastungstelegramm)
Data Frame
Das Data Frame ist das am häufigsten verwendete Frame, es besteht aus mehren Feldern.
Auf das Start Bit folgt ein 11 oder 29Bit Identifier, falls ein 29Bit Identifier verwendet wird
muss das IDE Bit gesetzt sein. Das RTR wird nur für Remote Frames benötigt, im DLC Feld
muss die Anzahl folgender Daten Bytes stehen. Durch die Zyklische Redundanzprüfung wird
sichergestellt dass die Daten korrekt empfangen wurden.
Abbildung 9 CAN Data Frame nach Version 2.0A (11Bit Identifier)
•
•
•
•
•
•
•
•
•
•
SOF
ID
RTR
IDE
DLC
Data
CRC
ACK
EOF
IFS
Start of Frame
Identifier (11Bit Version 2.0A, 29Bit Version 2.0B „Extended Identifier“)
Remote Transmission Bit
Identifier Extension Bit (gesetzt bei Version 2.0B)
Data length Code
Nutzdaten
Cyclic Redundancy Check (Prüfsumme)
Acknowledge (Empfangsbestätigung)
End of Frame
Inter Frame spacing
29
Remote Frame
Der Aufbau eines Remote Frames ist grundsätzlich gleich wie der eines Data Frames. Die
Unterschiede sind das fehlende Datenfeld, sowie das gesetzte Remote Transmission Bit
(RTR). Die Datenlänge im DLC Feld muss auf die Anzahl erwarteter Bytes gesetzt werden.
Error Frame
Das Error Frame besteht aus zwei Feldern. Das erste Feld wird bestimmt durch die
Überlagerung von ERROR FLAGS, die von den verschiedenen Teilnehmern erzeugt werden
können. Das folgende Feld ist der ERROR DELIMITER (8 rezessive Bits). (Quelle Wikipedia)
Overload Frame
Das Overload Frame ist für ein zeitweiliges Anhalten der Kommunikation aufgrund einer
Busüberlastung gedacht. Falls der Busteilnehmer noch nicht bereit ist eine neue Nachricht zu
empfangen, kann er mit einem Overload Frame den Bus für kurze Zeit „blockieren“ und so
signalisieren, dass er noch nicht bereit ist.
4.2.6 Nachrichtenfilterung
Damit der Busteilnehmer entscheiden kann welche Nachrichten für ihn relevant sind,
werden die Identifier durch eine Maske gefiltert. Anhand eines Beispiels wird gezeigt wie
man den Bereich richtig einstellt.
Ein Busteilnehmer möchte zum Beispiel nur die Nachrichten mit den Identifier 580 - 587
empfangen. Dazu wird die Identifier Maske auf 111 1111 1000 eingestellt. Das bedeutet, die
drei niederwertigsten Bits der ID sind beliebig, die restlichen Bits müssen mit der
eingestellten ID des Empfängers übereinstimmen.
30
4.3 CANopen
CANopen ist ein Protokoll für den CAN- Bus, welches hauptsächlich für die
Automatisierungstechnik entworfen wurde. Das CANopen Protokoll beschreibt den
Austausch von Daten in einem CAN- basierenden Netzwerk. Dabei werden sowohl die
grundlegenden Kommunikationsmechanismen (Kommunikationsprofil) als auch die
Funktionalität der kommunizierenden Geräte (Geräteprofil) definiert. Das heißt, mit
CANopen wird auch die Interpretation von Prozessdaten, die über den Bus übertragen
werden festgelegt. Obwohl CAN als Multi- Master Bus entwickelt wurde arbeitet das
CANopen Protokoll der Einfachheit halber mit dem Master- Slave verfahren.
4.3.1 Objektverzeichnis
Alle Nutzdaten und Einstellungen eines CANopen Geräts sind in einem Objektverzeichnis
(Object Dictionary OD) abgespeichert.
Das OD ist im CANopen– Gerätemodell, die Schnittstelle zwischen der Anwendung und der
CANopen - Kommunikationseinheit. Jeder Eintrag im Objektverzeichnis steht für ein Objekt
und wird durch einen 16-Bit-Index und
einen 8-Bit Sub- Index gekennzeichnet.
Dadurch können unabhängig vom 11-BitIdentifier bis zu 65536 *254 Elemente
unterschieden werden. In Profilen ist die
Zuordnung von Kommunikations- und
Geräteprofilobjekten zu einem jeweiligen
Index genau definiert; somit wird mit
dem Objektverzeichnis eine eindeutige
Schnittstelle zwischen der Anwendung
und der Kommunikation nach außen
definiert.
Im CANopen Protokoll sind grundsätzlich
Tabelle 3 Indexbereich des Objektverzeichnis
vier verschiedene
Kommunikationsobjekte definiert:
• Servicedatenobjekte (SDO) zum Transport von Servicedaten
• Prozessdatenobjekte (PDO) zum Transport von Echtzeitdaten
• Netzwerkmanagement-Objekte (NMT) zur Steuerung der Zustände des CANopenGeräts und zur Überwachung der Knoten
• Synchronisationsobjekte um Beispiel Zeitstempel und Fehler-Nachrichten
4.3.2 Servicedatenobjekte
Die Servicedatenobjekte (SDO) werden benutzt um auf das Objektverzeichnis zuzugreifen.
Jedes Gerät benötigt mindestens einen SDO-Server welcher SDO-Anforderungen bearbeitet.
Bei einem SDO Transfer werden die 8 Byte Nutzdaten eines CAN Telegramms wie in
Abbildung 10 ersichtlich genutzt. Durch den Index und Sub- Index bleiben für die effektiven
Daten nur noch 4 Bytes übrig. Das Byte 0 setzt sich aus dem „client command specifier“
(CCS) und den Bits n, e und s zusammen.
31
Abbildung 10 SDO Frame
•
•
•
•
•
CCS
Bit 4
n
e
s
client command specifier
unbenutzt (immer 0)
Anzahl Daten bytes(number of Data Bytes)
Einzel Telegramm (expedited transfer)
Längenangabe von n gültig
4.3.3 Prozessdatenobjekte
Die Prozessdatenobjekte ermöglichen eine schnellere Übertragung von Prozessdaten. Bei
der Übertragung von Prozessdaten stehen immer 8 Bytes zu Verfügung, da kein Index
benötigt wird. Der Inhalt der Nachricht wird durch ein sogenanntes Mapping definiert,
welches beim Sender und Empfänger gespeichert ist. Dieses Mapping ist im
Objektverzeichnis abgespeichert und ist nichts anderes als eine Zuordnungstabelle. Die
Übertragung von PDO’s kann zyklisch, ereignisorientiert, oder synchronisiert geschehen.
4.3.4 Netzwerkverwaltungsobjekt
Netzwerkverwaltungsobjekte (NMT) werden zur Verwaltung des Netzes eingesetzt. Mit den
NMT werden zum Beispiel Zustandsänderungen der Geräte veranlasst, oder globale
Fehlermeldungen verbreitet.
4.3.5 CAN Störungssicherheit
Durch die kurze Datenlänge und die Sicherungsmassnahmen (Cyclic Redundancy Check)
eines CAN-Frames, wird eine korrekte Übertragung auch in gestörter Umgebung noch
gewährleistet.
32
4.4 Ansteuerung der EPOS über CAN
Die Kommunikation zwischen dem Atmega und den EPOS erfolgt momentan ausschliesslich
über Servicedatenobjekte (SDO). Diese Methode ist einfacher als über Prozessdatenobjekte,
weil kein PDO mapping gemacht werden muss. Im zeitkritischen Schwimmbetrieb müssen
nur Geschwindigkeiten gesendet- und Positionen ausgelesen werden. Das heisst pro EPOS
müssen theoretisch zwei Bytes gesendet- und eines ausgelesen werden. Es wird also eine
Positionsanfrage gesendet, die aktuelle Position vom EPOS zurück gesendet, die neue
Geschwindigkeit berechnet und wiederum zum EPOS zurück gesendet. Weil SDO’s immer
beantwortet werden, wird vom EPOS eine Bestätigung für den Erhalt der neuen
Sollgeschwindigkeit gesendet, was nicht unbedingt nötig, aber zur Fehlererkennung sehr
nützlich ist. Bei einer PDO Kommunikation würde man also keine Bestätigung der neuen
Sollgeschwindigkeit erhalten, was die Dauer der Kommunikation um 260 µs pro Anfrage
reduzieren würde. Weil aber das Berechnen der neuen Sollgeschwindigkeiten einiges länger
dauert (etwa 4 ms pro EPOS), kommt es auf die allenfalls eingesparten 260 µs nicht an.
Die minimale Dauer um die Position abzufragen und eine neue Geschwindigkeit zu schicken
ist wie in Abbildung 11 ersichtlich ca. 1 ms. Weil die EPOS eine gewisse Zeit zum Bearbeiten
der Nachrichten benötigen, dürfen die Nachrichten vom Atmega nicht zu schnell
nacheinander verschickt werden. Sobald die Nachrichten vom Atmega zu schnell
nacheinander gesendet werden gibt es eine Busüberlastung was dazu führt, dass einzelne
Nachrichten nicht mehr übertragen werden können.
Abbildung 11 Zeitlicher Ablauf der Kommunikation über CAN
33
4.4.1 Initialisierung des EPOS
Die EPOS sind eine Zustandsmaschine, die Zustände sind in folgender Grafik ersichtlich. Die
Zustände können durch das Schicken eines „Controlwords“ verlassen werden und durch das
„Statusword“ ausgelesen werden. Nach dem Starten der EPOS befinden sie sich nicht immer
im gleichen Zustand. Um Fehler zu vermeiden wird im Hauptprogramm jeder EPOS einzeln
geresetet und so in den „Switch on Disabled“ Zustand gebracht. Danach können alle EPOS in
den „Operation Enable“ Zustand gebracht werden.
4.4.2 Geschwindigkeiten setzten
Um die Sollgeschwindigkeit eines EPOS zu setzten, muss folgende Nachricht gesendet
werden:
Abbildung 12 Setzten der Soll- Geschwindigkeit über CAN
•
•
•
Gelb ID: 600+Node ID des gewünschten EPOS
Hellblau: 8 Datenbytes
o Byte0: 22 für das Schreiben von Daten mit unbestimmter länge
o Byte1+2: 6B 20 Hersteller spezifischer Code für Sollgeschwindigkeit
o Byte3: 0 Sub- Index (wird nicht benötigt)
o Byte4-7: 32Bit Integer mit der Sollgeschwindigkeit (hier 0)
Violett: Zeitstempel
4.4.3 Positionen auslesen
Um die Position eines EPOS auszulesen, muss folgende Anfrage geschickt werden:
Abbildung 13 Positionsanfrage über CAN
•
•
•
Gelb ID: 600+Node ID des gewünschten EPOS
o Byte0: 40 für das auslesen von Daten
o Byte1+2: 60 64 Hersteller spezifischer Code für Positionsanfrage
o Byte3: 0 Sub- Index (nicht benötigt)
o Byte4-7: 0 (wird nicht benötigt)
34
Die Antwort des EPOS sieht folgendermassen aus:
Abbildung 14 Antwort auf die Positionsanfrage
•
•
•
Gelb: COB ID 580+Node ID des EPOS
o Byte0: 43 für das senden von 4Byte Nutzdaten
o Byte1+2: 60 64 Code für Positionsanfrage (gleich wie bei der Anfrage)
o Byte3: 0 Subindex (nicht benötigt)
o Byte4-7: 32Bit Integer mit der aktuellen Position (hier dezimal 10002)
4.5 RS232
Obwohl die RS232 Schnittstelle bereits 47 Jahre alt ist, wird sie
immer noch häufig verwendet, die Gründe dafür sind die
geringen Ansprüche an die Hardware und Software. Die RS232
Schnittstelle verwendet für die Datenübertragung ein serielles
asynchrones Verfahren. Da es keine
Synchronisationsnachrichten gibt ist es wichtig, dass der Sender Abbildung 15 RS232-Kabel
und der Empfänger mit der gleichen Baudrate arbeiten. Für eine
minimalistische Bidirektionale Kommunikation reichen also theoretisch 3 Leitungen, um aber
zu vermeiden dass der Sender Daten sendet obwohl der Empfänger nicht bereit ist werden
zusätzlich zwei bis vier Handshake- Leitungen verwendet. Die RS232 Schnittstelle arbeitet
mit Spannungspegeln von +12V für logisch 0 und -12V für logisch 1. Der Empfänger erwartet
eine Spannung von mehr als +3V bzw. von weniger als -3V. Im Ruhezustand liegt der Pegel
auf -12V (logisch 1), eine Datenübertragung wird also durch das senden einer logischen 0
gestartet.
Abbildung 16 Frame Aufbau einer RS232 Nachricht
35
5 Software
In diesem Kapitel wird der Aufbau der geschriebenen Software dargestellt. Es wird der
theoretische Aufbau gezeigt, auf Code Beispiel wurde verzichtet, der gesamte C-Code
befindet sich auf der DVD.
5.1 Programmierumgebung
Als Programmieroberfläche wurde AVR Studio 4 verwendet. Diese Entwicklungsumgebung
wird von Atmel zur Verfügung gestellt und besteht aus einer Projektverwaltung, einem
Editor und einem Debugger.
Um in der Programmiersprache C zu programmieren, muss der GNU C Compiler für AVRs
installiert werden. Die komplette Software ist kostenlos und auch auf unserer DVD zu finden.
Um die aktuellste Version zu erhalten, sollte man jedoch den direkten Herstellerlink
benutzen:
AVR-Studio:
C-Compiler:
http://www.atmel.com/dyn/Products/tools_card.asp?tool_id=2725
http://winavr.sourceforge.net/download.html
Für einen reibungslosen Einstieg in AVR-Studio empfiehlt sich der folgende Link:
http://www.robomodules.de/portal/index.php?id=199&type=1
36
5.2 Hauptprogramm
Das Hauptprogramm initialisiert als erstes alle benötigten Komponenten. Danach muss das
Homing manuell vom Pilot gestartet werden, sobald der Pilot bestätigt hat dass das Homing
korrekt ausgeführt wurde, können über die grafische Benutzeroberfläche die verschiedenen
MODEs gestartet werden.
Das Flussdiagramm zeigt den Ablauf des Hauptprogramms von naro ab dem Zeitpunkt des
Einschaltens.
Initialisierung
EXT_INTERRUPT
UART
PWM
ADC
TIMER0
CAN
ADC Messung 0-7
EPOS 1-5 Reset
HOMING
EPOS 1-5
MODE 1
„halt“
MODE 5
„EPOS
deaktivieren“
MODE 200
„präsentation
mode“
MODE 201
„BV-Test“
MODE 202
„schwimmmode1“
MODE 203
„tauchen“
MODE 204
„tauchen2“
MODE 206
„schwimmmode2“
MODE 230
„reset“
ADC
Ausgabe
Überwachung
Unterspannung
Überwachung
Wassereinbruch
Überwachung
Kommunikation
Abbildung 17 Flussdiagramm des Hauptprogramms
5.2.1 Initialisierung
Die Initialisierung von naro beinhaltet das Starten aller verwendeten Zusatzkomponenten
wie beispielsweise der RS232 Kommunikation (UART) oder das Bereitstellen einer AnalogDigitalwandlung (ADC). Dies muss nur einmal, zu Beginn des Programmablaufs, durchgeführt
werden. Die Servomotoren der Brustflossen und Tauchzylinder befinden sich danach in
Mittelposition.
37
5.2.2 ADC Messung
Die ADC-Messung sendet bei jedem Neustart des Programms die aktuellen
Analogeingangswerte via RS232 an die grafische Benutzeroberfläche. Damit können die
momentanen Sensordaten und die Akkuspannungen sofort ausgelesen werden.
5.2.3 EPOS reset
Die fünf EPOS von naro werden in den „Operation Enable“ Zustand gebracht, von welchem
sie das Homing ausführen können.
5.2.4 Homing
Das Homing wird vom Piloten über RS232 aus für jeden EPOS einzeln gestartet. Es wird
zudem ein Wert für den Current-Treshhold des entsprechenden Gelenks übermittelt. Somit
kann, bei ändernden mechanischen Bedingungen auf diese entsprechend reagiert werden
(beispielsweise Homing im Wasser oder in der Luft).
Zyklische Programmteile
Die folgenden Programmteile werden periodisch bearbeitet. In einer Schwimmfunktion, bei
welcher der Prozessor viel rechnen muss, liegt die Durchlaufrate bei etwa 30Hz.
5.2.5 Betriebs-MODE
Der Betriebsmode wird durch die übertragene Variable MODE ausgewählt. Somit kann der
Betriebsmodus von naro während der Laufzeit geändert werden. Die Beschreibung und
Funktion der einzelnen Modes entnimmt man dem Quellcode von naro.
5.2.6 ADC Ausgabe
Die ADC-Ausgabe ermöglicht es dem Piloten während dem Betrieb von naro die einzelnen
Analogeingänge auszulesen.
5.2.7 Überwachung
In der Überwachung werden die zu überprüfenden Sensordaten direkt mittels Software mit
dem gespeicherten Grenzwert verglichen. Bei einem Überschreiten wird mit einem
entsprechenden Notfallszenario eingegriffen. Dies geschieht ohne den Einfluss des Piloten.
Zusätzlich wird die RS232 Kommunikation auf ihre korrekte Übertragungsfunktion geprüft.
38
5.3 RS232 Interrupt
Die Interrupt- Routine der RS232 Schnittstelle wird immer dann aufgerufen, sobald der
Empfangspuffer voll ist. Die Daten werden auf ihre korrekte Reihenfolge überprüft und für
die Weiterverarbeitung aufbereitet. Die gesamte Routine dauert für eine korrekte Message
etwa 2 µ Sekunden. Wird eine fehlerhafte Message übermittelt, dauert die Routine weniger
lang. Bei der Initialisierung des Hauptprogramms wird die Message Nr. auf 1 gesetzt.
START
1
Message
Nr
2
Nein
Byte 1
<255?
Ja
Ja
Nein
Byte 2
<255?
Byte 2
<255?
Ja
Ja
Byte 3
<255?
Byte 3
<255?
Ja
Ja
Byte 4
<255?
Byte 4
<255?
Ja
Ja
Byte 5
<255?
Byte 5
<255?
Ja
Ja
Byte 6
<255?
Byte 6
<255?
Ja
Ja
Byte 7
=255?
Byte 7
=255?
Nein
Nein
Nein
Nein
Nein
Byte 1
<255?
Nein
Nein
Nein
Nein
Nein
Nein
Nein
Message_Error +1
Message_Error +1
Byte 1-7 in
entsprechende globale
Variablen speichern
Byte 1-7 in
entsprechende globale
Variablen speichern
Message Nr = 2
Message Nr = 1
Puffer leeren
ENDE
Abbildung 18 Flussdiagramm der Puffer Overflow Interrupt Routine
39
5.4 Globale Zeitvariablen
Für die Regler wird eine globale Zeitvariable benötigt. Um eine exakte Systemzeit zu
erhalten, wird diese mit einer Interrupt - Routine erzeugt, die vom 8Bit Timer0 ausgelöst
wird. Dabei ist time die Systemzeit in Sekunden.
Es stehen zwei unterschiedlich exakte Zeitmessungen zur Verfügung:
• Systemzeit in 4ms Schritten = time
• System in 16 µs Schritten = time + (((TCNT0 -5) * 16) / 1000000);
Zusätzlich werden im Sekundentakt zwei Variablen gesetzt, welche für das Senden von
Warnungen an den Piloten sowie für den Regler der Tauchzylinder benötigt werden.
40
5.5 Positionsberechnung
Die Berechnung der Soll- Positionen für die Motoren kann auf unterschiedliche Arten
realisiert werden. Es ist denkbar, dass im Testbetrieb eine Verbindung zwischen
Mikroprozessor und Computer besteht und der leistungsstärkere Computer die
Positionsberechnungen der Aktoren durchführt. Dies hat den Vorteil, dass man sehr schnell
einzelne Parameter ändern kann, und so in der Verbesserung des Antriebs rasch Fortschritte
macht.
Bei einer kabellosen Verbindung unter Wasser ist die Übertragungsrate deutlich kleiner, dies
setzt voraus, dass der Mikroprozessor die Positionsdaten der Antriebsaktoren eigenständig
berechnen kann.
Hierfür haben wir folgende zwei Konzepte betrachtet:
•
•
Stationäre Berechnung; dem Mikroprozessor sind zeitabhängige Funktionen
vorgegeben mit welchen er die Position berechnet. Die Parameter des Piloten haben
direkten Einfluss auf diese Funktionen.
In einer Tabelle sind alle Positionswerte gespeichert, je nach Bewegungsart führt der
Mikroprozessor eine andere Tabelle aus, oder ändert einen Vorfaktor.
Es wurde entschieden die Berechnungen in Echtzeit auf dem Mikroprozessors zu machen.
Dies hat den Vorteil, dass die Parameter der zeitabhängigen Funktionen stufenlos verändert
werden können. Mit Tabellen würde zwar die zeitaufwendige Berechnung wegfallen, dafür
bräuchte man entweder viel Speicherplatz oder man müsste bei jeder Änderung der
Schwimmbewegung eine neue Tabelle vom PC auf den Mikrokontroller laden.
5.6 Positions- Regelung
Um sicherzustellen, dass sich alle Gelenke immer genau nach den berechneten
Bewegungsabläufen bewegen, wurde entschieden für jedes Gelenk eine Positionsregelung
zu machen. Weil das Berechnen der Soll- Positionen für alle fünf Gelenke etwa 20ms dauert,
können die Soll- Positionen nicht direkt an die EPOS gesendet werden, da sonst das
Bewegungsprofil Stufen aufweisen würde (siehe Abbildung 20). Deshalb wurde ein
überlagerter Positions- Regler entworfen der Soll- Geschwindigkeiten an die EPOS sendet.
Abbildung 19 Regelkreis
41
Abbildung 20 Unterschied zwischen eigener Positions- Regelung und der Positions- Regelung über die EPOS
5.7 Homing
Um eine absolute Position nach dem Start zu erhalten wird ein Homing durchgeführt. Die
EPOS unterstützen hierbei viele verschiedene Varianten. Betrachtet wurden die Endschalterund die „Current Treshhold“ - Variante. Die „Current Treshhold“ - Variante hat den Vorteil,
dass keine zusätzlichen Schalter benötigt werden, deshalb wird diese Variante auch
eingesetzt. Der Nachteil ist, dass die Stromgrenzen für die Motoren von den mechanischen
Randbedingungen abhängig sind.
5.8 Positionslimit
Damit naro bei Tests nicht beschädigt werden kann wurde ein Arbeitsbereich definiert, der
die maximalen Positionen der Motoren eingrenzt. Diese Eingrenzung wurde auf den EPOS
und in der Software des Atmega gesetzt. Damit diese Eingrenzung etwas nützt muss das
Homing zuverlässig die korrekte, absolute Position liefern. Durch das 190: 1 - Getriebe haben
die Motoren ein Drehmoment von mehr als 8 Nm und damit genügend Kraft, um die GFK
Box zu beschädigen.
42
5.9 EPOS Bibliothek
Um die EPOS möglichst einfach anzusteuern wurde eine C-Bibliothek mit den wichtigsten
Befehlen erstellt. Die erstellte Bibliothek „EPOS_lib.c“ benötigt selbst auch eine Bibliothek
für den Zugriff auf den CAN-Controller des Mikroprozessors. Dazu wurde die vorhandene
Bibliothek „can.c“ verwendet. Diese CAN Bibliothek musste leicht angepasst werden, um die
Kommunikation nach CAN Version 2.0A (11 Bit Identifier) zu ermöglichen. Beim verwenden
des CAN- Busses mit den EPOS muss unbedingt darauf geachtet werden, dass die
Nachrichten nicht zu schnell nacheinander verschickt werden, da sonst der Bus überladen
wird. Messungen haben gezeigt, dass vom Mikrokontroller die Nachrichten höchstens mit
einer Frequenz von 2500Hz (T = 400 µs) verschickt werden dürfen. Wenn die Nachrichten
schneller versandt werden, kann das zu einer Busüberlastung führen, und die Nachrichten
werden mit hoher Latenzzeit oder gar nicht mehr übermittelt.
Abbildung 21 CAN-Bus Timing
43
5.10 PWM
Zur Erzeugung eines PWM Signals wird ein Timer benötigt der die entsprechenden Ausgänge
in den gewünschten Zeitintervallen High und Low setzt. Um eine ausreichend hohe
Auflösung zu erhalten muss ein 10 Bit Timer verwendet werden.
Der Timer zählt mit einer Frequenz
%&16'(#
&)%*
das Register TCNT1 von Null beginnend nach oben bis der Wert im Register ICR1 erreicht ist
und dann wieder nach unten bis Null. Der Ausgang geht auf High, wenn der Timer beim
Runterzählen den Wert im Register OCR1A erreicht, und auf Low sobald, er beim
Hinaufzählen den Wert im Register OCR1A erreicht.
Es wurde ein prescaler von 8 gewählt, somit ist die Zählfrequenz
16'(
2'(
8
Damit bei einer Frequenz von 2 MHz eine Periodendauer von 20 ms entsteht, muss der
Timer von Null auf ICR1=20000 und wieder zurück zählen.
2 - 20000
20.)
Durch das Laden von Werten zwischen 1000 und 2000 in das Register OCR1A, entstehen am
Ausgang alle 20 ms Pulse zwischen 1ms und 2ms welche von den handelsüblichen
Servomotoren benötigt werden.
Abbildung 22 PWM Signal Entstehung
6 Tests
6.1 Trockentests
Bei den ersten Trockentests Anfang Mai 2009 ging es darum, die Elektronik zusammen mit
der Mechanik zu testen. Man wollte ein erstes Mal alle einzelnen Komponenten Schritt für
Schritt zusammenfügen und ihr Zusammenspiel testen und optimieren. Diese ersten
Trockentests waren mit viel Aufwand verbunden, weil parallel zu den Trockentests auch die
ersten Nasstests ohne Elektronik stattfanden. Dafür musste die ganze Elektronik mehrmals
in den Fisch ein- und ausgebaut werden.
6.2 Nasstests
Nach diversen erfolgreichen Trockentests konnten Mitte Mai 2009 erstmals Nasstests im
Hallenbad Bungertwies durchgeführt werden. Beim ersten Test schlug der eingebaute
Feuchtigkeitssensor schon nach wenigen Sekunden Alarm. Die automatische
Notausschaltung hätte sofort das Relais schalten sollen um die Speisung zu unterbrechen,
aber obwohl das bei allen Trockentests ohne Problem funktionierte, klappte es in diesem
44
Moment nicht, der Stromkreis wurde nicht unterbrochen. Sofort wurde naro an Land
gebracht, und alle 16 Schrauben der Luke wurden gelöst, um den Stromkreis so schnell wie
möglich manuell zu unterbrechen.
Zum Glück war der Wassereinbruch minim, es sind nur 2-3ml Wasser ins Innere der Box Nr. 2
eingedrungen. Diese 2-3ml Wasser haben jedoch ausgereicht um, auf der
Versorgungsplatine einen Kontakt zwischen dem Relais und der Speisung herzustellen,
dadurch konnte der Stromkreis nicht unterbrochen werden. Die Versorgungsplatine, die
EPOS und der Mikroprozessor wurden daraufhin mit einem Lack versiegelt. Alle anderen
Bauteile wurden nicht beschädigt.
Bei den weiteren Nasstests konnten die Schwimmbewegungen mit unterschiedlichen
Bewegungs- Parametern getestet werden.
7 Schlussfolgerung /Resultate
Der nautical robot kann für rund 20 min ferngesteuert in alle Richtungen schwimmen, bzw.
tauchen. Das Hauptziel, einen schwimmfähigen Unterwasser- Roboter, nach einem
natürlichen Vorbild zu bauen, wurde somit erreicht. Naro kann, auch ohne Hülle mit
maximaler Frequenz und Amplitude, deutlich schneller als einen Meter pro Sekunde
schwimmen.
Die Regelung der Gelenke funktioniert wie in Abbildung 23 ersichtlich sehr gut. Der zeitliche
Unterschied zwischen Soll- und Istwert beträgt 40 ms. Diese teilen sich auf den wirklichen
Regelfehler und die Übertragungsdauer der Daten (CAN-Bus und RS232) auf.
Abbildung 23 Messung der Soll- und Ist- Position bei hochfahren der Amplitude
45
Abbildung 24 zeigt den zeitlichen Verlauf aller fünf Gelenke während einer
Schwimmfunktion. Die Schwimmfrequenz lag bei 1 Hz und die Reglerparameter waren
KP = 3.2798 und KD = 0.039958;
Abbildung 24 Messung aller Soll- und Ist- Positionen während dem Betrieb
46
8 Ausblick
In diesem Kapitel werden Verbesserungen, welche hauptsächlich aus zeitlichen Gründen
während der Bachelorarbeit noch nicht realisiert werden konnten aufgeführt. Es sind
Vorschläge, welche meist bei der Resultatbetrachtung aufgetaucht sind.
8.1 RS232 Kommunikation
Das Kommunikationsprotokoll zwischen Pilot und naro sollte erweitert werden.
Damit würde es möglich, nach einer fehlerhaften Datenübertragung die Kommunikation neu
zu synchronisieren, und zudem die empfangenen Daten genauer zu überprüfen.
Dazu erforderlich wären eine eindeutige Identifikation der Message, sowie ein
Synchronisationsbyte und eine Checksumme. Die Identifikation und die Synchronisation
könnten zu einem Byte zusammengefasst werden. Dies würde bedeuten, dass in jeder
Message ein Byte steht, welches nur an diesem Ort auftreten kann. In der Message eins
beispielsweise Byte 7 = 255 und in der Message zwei Byte 7 = 254. Diese beiden Werte
dürften jedoch in keinem anderen Byte vorkommen. Damit nun überprüft werden kann, ob
die gesendeten Daten korrekt sind, wird zusätzlich noch eine zyklische Redundanzprüfung
(CRC) eingebaut (jeweils Byte 8).
Ist nun die Datenübertragung als nicht korrekt erkannt worden, Kann mit dem
Synchronisationsbyte der Empfangspuffer verschoben werden, so dass die nächste
ankommende Message wieder korrekt eingegliedert wird.
Abbildung 25 Optimierte Messages
8.2 Kabellose Kommunikation
Das Kabel sollte durch die Ultraschall Kommunikation von Elias Hagmann ersetzt werden,
damit die Reichweite und die Bewegungsfreiheit von naro erhöht werden.
8.3 Software
Es sollte ein GUI erstellt werden, welches nicht von einem anderen Programm (Matlab)
abhängig ist, da ein Benutzer sonst zur Steuerung eine Matlab-Lizenz benötigt.
Das Hauptprogramm auf dem Mikroprozessor ist, bezüglich Sicherheit, noch nicht optimiert,
es werden noch nicht alle möglichen Ereignisse abgefangen und sinnvoll verarbeitet.
47
9 Quellen
•
•
•
•
•
Die verwendeten PDF-Dateien sind auf der DVD.
Wikipedia: www.wikipedia.org
Maxon AG: www.maxonmotor.ch
Atmel, allgemein: www.atmel.com
Display3000: www.display3000.com
9.1 Abbildungsverzeichniss
Abbildung 1 CAD Model von naro ........................................................................................................... 2
Abbildung 2 Box Nr.2 randvoll mit Elektronik ......................................................................................... 7
Abbildung 3 Antriebsübersicht von naro ................................................................................................ 8
Abbildung 4 Mikrokontroller- Platine ................................................................................................... 10
Abbildung 5 Servomotor- Position und PWM Signal ............................................................................ 16
Abbildung 6 EPOS Positionskontroller .................................................................................................. 20
Abbildung 7 RS232 Messages................................................................................................................ 23
Abbildung 8 Bitarbitrierung................................................................................................................... 28
Abbildung 9 CAN Data Frame nach Version 2.0A (11Bit Identifier) ...................................................... 29
Abbildung 10 SDO Frame ...................................................................................................................... 32
Abbildung 11 Zeitlicher Ablauf der Kommunikation über CAN ............................................................ 33
Abbildung 12 Setzten der Soll- Geschwindigkeit über CAN .................................................................. 34
Abbildung 13 Positionsanfrage über CAN ............................................................................................. 34
Abbildung 14 Antwort auf die Positionsanfrage ................................................................................... 35
Abbildung 16 Frame Aufbau einer RS232 Nachricht............................................................................. 35
Abbildung 15 RS232-Kabel .................................................................................................................... 35
Abbildung 17 Flussdiagramm des Hauptprogramms ............................................................................ 37
Abbildung 18 Flussdiagramm der Puffer Overflow Interrupt Routine .................................................. 39
Abbildung 19 Regelkreis ........................................................................................................................ 41
Abbildung 20 Unterschied zwischen eigener Positions- Regelung und der Positions- Regelung über die
EPOS ...................................................................................................................................................... 42
Abbildung 21 CAN-Bus Timing............................................................................................................... 43
Abbildung 22 PWM Signal Entstehung.................................................................................................. 44
Abbildung 23 Messung der Soll- und Ist- Position bei hochfahren der Amplitude ............................... 45
Abbildung 24 Messung aller Soll- und Ist- Positionen während dem Betrieb ...................................... 46
Abbildung 25 Optimierte Messages ...................................................................................................... 47
48
10 Inhalt DVD
49
11 Anhang
Die folgende Tabelle zeigt die Anschlussbelegung der verwendeten IO-Pins des
Mikrokontrollers:
Pin
Mikrokontroller Bezeichnung
Angeschlossen
5
PE3
Tauchzylinder vorne
6
PE4
Brustflosse links
7
PE5
Brustflosse rechts
11
PB1
Display
12
PB2
Display
14
PB4
Display
15
PB5
Display
16
PB6
Display
17
PB7
Tauchzylinder hinten
20
Reset
Reset
25
PD0
Ext_Int 0
26
PD1
Relais
27
PD2
RS232_1 RX *
28
PD3
RS232_1 TX *
30
PD5
CAN H *
31
PD6
CAN L *
35
PC0
LED power (grün)
36
PC1
LED 1 (rot)
54
PF7
Neigungssensor 1
55
PF6
Neigungssensor 2
56
PF5
Feuchtigkeitssensor H2
57
PF4
58
PF3
Drucksensor
59
PF2
60
PF1
Akku 2
61
PF0
Akku 1
*via Zusatz- IC
Tabelle 4 Anschlussbelegung des Mikrokontrollers
50

Bachelorarbeit 2009 Elektronik und Software für den

Transcription

Similar documents

Overclocking einer AMD Athlon CPU

Farbe (ca. 301KB)

Entwicklung von Ansteuerungs- und Datenerfassungssoftware für

Echtzeitdatenübertragung am Beispiel MPEG-TS/RTP

2008 - PicR.de

English - Universität Koblenz · Landau

Embedded Solutions - Mouser Electronics

MRD11_13 REIFENTEST, Teil 1.indd

Österreichischer Verband für Strahlenschutz

gaula norwegen norwegen gaula

AT89S ISP-Flasher - Mikrocontroller.net

Hörbuchliste - Stadt Waldkraiburg

GEODOG®

CANopen LIFT 2009 - WS

Grundlagen zur SPS-Programmierung mit SIMATIC S7-300

FM-4721 Handbuch - Busse Yachtshop

NLP Masterarbeit-Dann sags doch-Thilo Sauter - NLP

Pottwale und Tiefseeberge

Induktive Wegaufnehmer mit CANopen