pg 420 rock - ls12- · pc rs232 icd2. 22.09.2003 folie 13 pg 420 rock: robot construction kit ......

22.09.2003

PG 420 RoCK:Abschlussvortrag

Betreuer: Jens Wagner, Lars Wehmeyer

Lehrstuhl Informatik XII – Eingebettete Systeme –Prof. Dr. Peter Marwedel

Folie 222.09.2003PG 420 RoCK: Robot Construction Kit

Lehrstuhl Informatik XII – Eingebettete Systeme – Prof. Dr. Peter Marwedel

PG 420 RoCK - Abschlussvortrag

Gliederung

1. Einleitung

2. Problembeschreibung

3. Hardware

4. Software

5. Benchmark

6. Fazit

7. Ausblick

8. Live-Demonstration



1. Einleitung

12 Studenten – 1 JahrDetlev Bartsch

Torsten Denno

Pedram Hadjian

Nico Karnatz

André Kernchen

Andreas Klapschus

Marcus Ladwig

Michael Patzer

Matthias Reck

Christoph Schlagbaum

Daniel Smolinski

Thorsten Wilmer



1. Einleitung

Die Teilnehmer- Zwölf Studenten

- Informatik und Ingenieurinformatik

- Interesse an praktischer Anwendung erworbenen Wissens

- Interesse an neuem Wissen aus dem Bereich „Embedded Systems“

und Compilerbau

- Heterogenes Teilnehmerfeld

- Unterschiedliche Vorkenntnisse

- Unterschiedliche Erwartungshaltungen

- Faszination für den Bau von Robotern



PG 420 RoCK - Abschlußvortrag

Gliederung

1. Einleitung


3. Hardware

4. Software

5. Benchmark

6. Fazit

7. Ausblick





LEGO Mindstorms als Ist-Zustand• Plattform, um schnell verschiedenartige Roboter zu bauen

(Zielgruppe: Kinder ab acht Jahren)

• Basierend auf Hitachi 16-Bit-Prozessor in einer geschlossenen

Einheit

• Einfaches Display; drei Sensor- und drei Aktoranschlüsse

SensorenAktorenRCX-Einheit




Motivation• Bessere Hochsprachenunterstützung

• Modularität

• Bessere Anzeige

• Mehr und andere Sensoren ermöglichen




Komponenten unserer Lösung:

Zentraleinheit

Sensor/Aktorhub

RoCKWire

Firmware

Applikation

Betriebs-system

Compiler

RoCK

Hardware Software




Zur Verfügung stehende Hilfsmittel• Eagle zum Platinendesign

• Lance, Olive ++ und LLIR zur Compilererstellung• MP-Lab, Demoboard

• MOSFET-Bausteine




Konsequenzen für das weitere Vorgehen:- Grobstrukturierung des Hauptproblems in Hardware- und

Softwareprobleme

- Festlegung von Verantwortlichkeitsbereichen

- Bildung von Teilaufgaben

- Erstellung von Zeitplänen

- Festlegung und Einhaltung von Deadlines




Gliederung

1. Einleitung


3. Hardware

4. Software

5. Benchmark

6. Fazit

7. Ausblick




3. Hardware

Das Zielsystem

Batterie

RoCK-Einheit2 Motoren3 Sensoren 2x RoCKWire-Master

Sensorhub3 Sensoren

Motorhub2 Motoren

LC-Display

RoCKWire-Bus

Sonar

I²CPC

RS232

ICD2



3. Hardware

Teilaufgaben

• Einarbeitung in neue Hardware

• Schaltungsdesign

• Entwurf und Aufbau einer 1-Wire-Technologie (RoCKWire)

• Entwurf eines Prototyp-Boards

• Platinendesign

• Bestücken der SMD-Platinen

• Konstruktion der Roboter

• Funktionstest



3. Hardware

Eigenschaften der Zentralen Steuereinheit• Kommunikation mit dem PC über RS232 oder ICD2

• ISP (In-System-Programmierbarkeit)

• führt Applikation aus

• I2C Bus

• schnelle Sensorabfrage

• Steuerung der RoCKWire Clients

• genügend Anschlüsse für Sensoren, Aktoren und RoCKWire

• kleine Abmessungen als LEGO RCX-Einheit



3. Hardware – RoCKWire-Slaves

Eigenschaften• Verwendung des PIC12 in Hubs

• Master-Slave-Bus

• Parasitäre Energieversorgung der Slaves

• Verwendung von LEGO-Steckern

• Firmware bearbeitet Befehle des Masters

• One-Wire-Technologie

Der PIC12-Prozessor

AktorhubSensorhub



3. Hardware

Wie stellen wir LEGO-Kompatibilität sicher?- LEGO-Gehäuse und -Stecker (Verpolungsschutz)

- 9 V Systemspannung

- Analoge Sensorschnittstelle



3. Hardware - RoCKWire

Eigenschaften des RoCKWire-Protokolls

Startbit Paritybit

Stromversorgungüber den Bus

Byte desMaster

Antwortdes Slave

Pollbit



3. Hardware - RoCKWire

Eigenschaften des RoCKWire-Protokolls

Startbit Takt 1 0



3. Hardware

Die Bestandteile des Roboter-Systems- Zentraleinheit

- Sensor-/Aktorhubs

- RoCKWire

Inkrementelle Vorgehensweise- Auswahl und Beschaffung der Komponenten

- Aufbau und Tests am Evaluation Board

- SMD-Platinenentwurf und -aufbau

- Funktionstests

- Inbetriebnahme



3. Hardware




Gliederung

1. Einleitung


3. Hardware

4. Software

5. Benchmark

6. Fazit

7. Ausblick




4. Software

Teilaufgaben

• Betriebssystem (SOUL)

• Treiber und APIs (z.B. RoCKWire, LCD, Motoren, Sensoren ...)

• ANSI-C-Compiler

• Benchmark: Die Drop-Zone-Applikation in C



4. Software - Betriebssystem

Aufbau von SOUL

Soul is an Operating System for Use with Lego




Zwei mögliche Stack-Verwaltungsstrategien

Task10-31

Task20-31 Task3

16-23

Task10-7

Task28-15

Task424-31

a) Tauschen

Nachteil: Gesamter Stack muss im PCB gesichert werden! Interrupts sind auszuschalten

b) Teilen

Nachteil: Nur wenig Stack pro Taskzur Verfügung

Nur 1536 Byte RAM vorhanden!




SOUL-Stack-Verwaltungsstrategie

Insgesamt stehen 31 x 21 Bit Speicher für Returnadressen zur Verfügung!

Adresse 0 = Resetvektor

Task221-31

Task110-20

System-Task6-9

Idle-Task1-5

0

Task321-31




Die Toolchain



4. Software - Compilerbau

Compilerbau- Bislang kein kostengünstiger Compiler für PIC18F452

- Übersetzung und Ausführung eines Programms

- Sensorwerte abfragen, Aktoren ansteuern

Compiler-Hilfsmittel (bereitgestellt vom LS XII

und dem ICD)

- Compiler-Frontend LANCE

- Code-Generator-Generator OLIVE ++

- Backend-Datenstruktur LLIR




Besonderheiten im Backend• Durch Codeselektion entsteht LLIR-Datenstruktur

• Implementierung eines Softwarestacks für Funktionsparameter

(unterstützt auch Rekursion)

• Initialisierung von globalen Variablen in Funktion c_0

• Unterstützt Codeerzeugung für Accessbank oder beliebige Bank

• Datentypen: Integer, Char, Pointer, Arrays

• Interface zum OS durch C-Headerdatei

C-Code

IR3-Adress-

CodeLLIR

LANCE2 OLIVE++




Besonderheiten der

Registerallokation- Implementierung nach Appel

- Sichtweise: jede Bank (1+7)

beinhaltet 256 Register

- Grenzwert für Allokation entspricht

der Bankgröße

- Ausgabe des Interferenzgraphen

als VCG-File




Backend-Optimierung Teil 1– Peephole-Tree: wird dynamisch aus picpeep.dat aufgebaut – Parameter: Instruction Code, Fileregister, Literal, Destination, Bank, Depth

……

37,1,37,1,--1,0,0,1,1,0,0,1,

41,1,41,1,--1,1,--1,0,2,1,0,2,

>,>,

37,1,37,1,--1,0,0,1,1,0,0,1,

--,,

37,1,37,1,--1,0,1,1,1,0,1,1,

60,60,--1,0,1,0,--1,1,--1,0,1,0,

60,60,--1,0,1,0,--1,1,--1,3,1,3,

>,>,

40,40,--1,2,1,2,--1,1,--1,0,1,0,

61,1,61,1,--1,0,1,2,1,0,1,2,

…

[…]




Backend-Optimierung Teil 2– Sukzessives Instruktions-Matching im

PHTree durch Traversieren der LLIR und Ersetzen gefundener Peepholes

MOVF v_2,0,0SUBLW 21SUBLW 0

MOVLW 21SUBWF v_2,0,0

37,1,-1,0,0,1,60,-1,0,-1,-1,0,60,-1,0,-1,-1,3,>,40,-1,2,-1,-1,0,61,1,-1,0,0,2,

ASM-File picpeep.dat

…




Gliederung

1. Einleitung


3. Hardware

4. Software

5. Benchmark

6. Fazit

7. Ausblick




5. Benchmark

Drop-Zone-MissionRandbedingungen

• Zwei DIN A0-Blätter

• Drei Hindernisse

• Drei Coladosen (Payload)

• Grüne Drop-Zone

• Roboter

• schwarze Umrandung

Ziel: Alle Dosen in der Drop Zone abstellen

Die Drop-Zone-Mission wurde von der LEGO-RCX-Einheit bisher

nicht zufriedenstellend gelöst !



5. Benchmark

Drop-Zone-MissionDer Roboter

• Zwei Lichtsensoren

• Differentialgetriebe

• Eine Sonareinheit, 90° schwenkbar

• Magnetsystem zum Dosen „fangen“

• Abstoßvorrichtung

• Vier „Bumper“

Hohe Zahl an Sensoren und Aktoren

und sogar ein Sonar ansteuerbar!



5. Benchmark – Sonarmessung

Beispiel für ein Sonar-Meßfeldbeim „Scannen“ des Spielfelds.

2 Objekte direkt nebeneinander werden erkannt!

0

20

40

60

80

100

120

1 18 35 52 69 86 103

120

137

154

171

188

205

222

239

256Meßstrecke



5. Benchmark – Algorithmus

Erkennung eines Objekts (z.B. Coladose)- Abtasten der Umgebung

- Sonarsignal (blau) verarbeiten

- Glättung durch Software (rosa)

- Dosenerkennung durch Minimumlokalisierung

- Roboter um 90° drehen

- Hindernis anfahren

- prüfen, ob magnetisch

- ggf. zurückfahren und weitersuchen ODERDrop Zone suchen

0

20

40

60

80

100

120

1 28 55 82 109

136

163

190

217

244

geglättetSonar




Gliederung

1. Einleitung


3. Hardware

4. Software

5. Benchmark

6. Fazit

7. Ausblick




6. Fazit

Was wurde erreicht?- Eigenes Betriebssystem entwickelt

- Eigenen Compiler entwickelt

- Durch Bussystem sehr modular erweiterbar

- Lösen der Drop Zone Mission

- Präsentation am Tag der offenen Tür

- 2 komplette RoCK-Einheiten aufgebaut




Gliederung

1. Einleitung


3. Hardware

4. Software

5. Benchmark

6. Fazit

7. Ausblick




7. Ausblick

Was wäre wünschenswert?Was wurde nicht (mehr) erreicht

• IR - Programmierbarkeit

• IR-Slave und LCD nicht komplett integriert

• Zweite RoCKWire-Master-Software nicht fertiggestellt

Was wäre weiterhin wünschenswert

• mehr Compiler-Funktionen (z.B. weitere Datentypen, zus. Funktionen)

• weitere Sensor- und Aktortypen




Gliederung

1. Einleitung


3. Hardware

4. Software

5. Benchmark

6. Fazit

7. Ausblick





PräsentationDrop-Zone-Mission mit Sonar



Robot Construction Kit

Das Team ...

Detlev Bartsch, Torsten Denno,

Pedram Hadjian, Nico Karnatz, Andre Kernchen,

Andreas Klapschus, Marcus Ladwig, Michael Patzer,

Matthias Reck, Christoph Schlagbaum, Daniel Smolinski,

Jens Wagner, Lars Wehmeyer, Thorsten Wilmer

... beantwortet gern Ihre Fragen!

pg 420 rock - ls12- · pc rs232 icd2. 22.09.2003 folie 13 pg 420 rock: robot construction kit ......

Documents