Robotik für Lehr- und Entwicklungszwecke

DiplomarbeitspräsentationChristian Aichinger

Entwicklung eines universellen Robotiksystems zur Verwendung und Weiterentwicklung im Schulbetrieb◦ OS-unabhängig◦ Programmiersprachenunabhängig

flexibles, erweiterbares System einfach zu bedienen (hardwaretechnisch) Ausreichende Dokumentation Beispielanwendungen (Samples)

Ziele

Programmiersprachen◦ C◦ C#◦ Java

Betriebssysteme◦ Windows◦ Linux

Ziele Samples für alle

Systeme

Kombinierte Samples (Sensoren + Aktoren)

Module◦ I2C-Bausteine, Sensoren/Aktoren

Verbindung◦ USB-I2C-Converter

Zwischenplatine◦ Aktorensteuerung (Motoren u.a.)

DriveSystem◦ Eigene Energieversorgung, auswechselbar

Konzept

Bestehend aus:◦ MCK – Make Controller Kit

Entwicklungsboard, hauptsächlich für die Aktorik◦ I2C – Converter (Sensorik)

Für die I2C-Kommunikation, Sensoren

ROLEZ - Hardware

C und C# Programmierung: mcbuilder, Visual Studio 2008

Java Programmierung: Eclipse

Peripheriegeräte: Servos, Abstandssensoren, I2C-Bausteine (Temperatur, Abstand)

Hilfsmittel

Basis

Momentan ist Robotik noch ein schwieriges Gebiet für Schüler

◦ Einstieg schwer

◦ Ergebnisse lassen oft auf sich warten

Darum: Neues, universelles System, von Schüler für Schüler

Warum ein Robotiksystem?

Verwendung soll in mehreren Formen möglich sein.◦ C als LowLevel-Sprache◦ C# und Java als Hochsprachen, auch für grafische

Anwendungen

Somit ist auch eine fächerübergreifende Verwendung möglich

Warum drei Sprachen?

Java

Objektorientiert

Syntax ähnlich wie C/C++

Umfangreiche Klassenbibliothek (JDK)

Zum Ausführen wird eine JVM benötigt

C# verwendet bekannte Konzepte aus C++,

Visual Basic und Java

Objektorientiert (Mischform)

Ermöglicht eine schnelle Anwendungsentwicklung

Vorrausetzung ist das .NET Framework

Die Universalistät des Systems soll gewahrt werden

Beide Systeme werden im Unterricht verwendet

Die Entwicklung soll in möglichst vielen Unterrichtsfächern möglich sein

Warum Linux und Windows?

Der Einstieg in die Robotik ist oft schwer

Samples helfen beim einarbeiten in das System

Anwendungen werden praktisch aufgezeigt

Funktionalität der vorhandenen Hardware wird demonstriert

Programmteile wiederverwendbar

Warum Samples?

Weit verbreitetes Bussystem für Sensoren◦ Dementsprechend viele Clients

Ein Bus mit mehreren Clients möglich

USB-Geräte (USB-I2C-Converter) komfortabel verwendbar

Beste Eignung für ROLEZ im Vergleich mit anderen Bussystemen in diesem Bereich

Warum I2C?

Entwickelt von Phillips Bidirektional Master – Slave-System

◦ Ein Master – Mehrere Slaves (Sensoren)

Zwei Leitungen◦ SCL (serial clock line) ◦ SDA (serial data line)

Der I2C-Bus

Entwicklungsboard Kleine Größe – großer Komponentenumfang Viele Schnittstellen

◦ Aktoren/Sensoren◦ Programmiersprachen

Hohe Leistung◦ Atmel AT91SAM7X256 Mikrocontroller (Bis zu

55MHZ/48MIPS) Hoher Preis (Versand aus den USA)

Eigenbau: Zeitkomponente kritisch

Was ist der MCK?

MCK-Aufbau

MCK - Schnittstellen

Transport-Protokoll zum Ansprechen des MCK über Programmiersprachen

Ursprünglich für die Kommunikation mit Multimedia Geräten entwickelt

Quelloffen, Transport unabhängig, Nachrichten basierend

Übertragung per TCP oder UDP

Implementiert in viele Programmiersprachen Viele Beispielanwendungen

OSC

Die Kommunikation mit OSC-Geräten erfolgt über OSC-Pakete

OSC-Pakete

/servo/0/position 200OSC-

Container

OSC-Containe

r

OSC-Methode

OSC-Argumen

t

OSC-Adresse

OSC-Nachricht

OSC-Paket

Einfache Handhabung – universelle Basis◦ libusb

Library zum USB-Handling In C, entwickelt für Linux, Windows Port existiert

Direkte Übersetzung in I2C-Signale◦ Kein simulierter COM-Port

Geringer Preis, jedoch Eigenbau Direkter Kontakt mit Hersteller

Warum i2c-tiny-usb?

Kapselung und Vereinfachung von bestehenden komplexen Bibliotheken Erstellung von Einsteiger-freundlichen Bibliotheken

Implementierung der Basis-Funktionalitäten◦ Garantiert Einfachheit, jedoch ev. eingeschränkte

Funktionalität

Erweiterte Funktionalitäten beibehaltenFür erfahrende User

Plattformunabhängigkeit in Java und CÄhnlichkeit in der Verwendung (Hochsprachen)

Grundziele für die Programmierung

1. Start mit einer schülerunfreundlichen I2C oder MCK Bibliothek

a) Anlegen einer neuen Bibliothekb) Kapselung der Klassen

2. Implantierung einfach zu verwendender Basis-Funktionalitäten

3. Beibehaltung der komplexen Funktionen

Die so erstellten Bibliotheken (C#, Java, teilweise C) werden für Samples und Applikationen verwendet

Eine Hierarchie von Bibliotheken ist auch möglich◦ Bsp.: C-Header -> C++ Lib -> C# Lib

Programmierung – Ablauf (Allgemein)

Realisierung nicht mehr von LL weg◦ Verringerung der Fehlerquellen◦ solide, leistungsfähige Software-Basis

Leichtere Erstellung von plattformunabhängigen Bibliotheken

Warum Kapselung?

Ergebnis der Implementierung

MCK C C# JavaBibliothek Nein Ja JaSamples Ja Ja Ja

I2C C C# JavaBibliothek Ja Ja JaSamples Ja Ja Ja

MCK◦ C#: Bibliothek von Making Things◦ Java: Bibliotheken NetUtil bzw. JavaOSC◦ Alle drei Bibliotheken basieren auf Open Sound

Control

I2C◦ Beispielanwendung von Till Harbaum◦ libusb-Bibliothek◦ LibusbJava – Java-Port von libusb

Verwendete Bibliotheken

C# - Bibliothek (HL)◦ Baut auf der Basis C# Bibliothek von MakingThings auf.

(Nur Windows) Java - Bibliothek (HL)

◦ Baut auf der JavaOSC Bibliothek auf. (Plattformunabhängig) Basis-Bibliotheken basieren auf OSC Realisierung eines Ticket-Systems

In C werden Samples erstellt (LL)◦ Direkte Ausführung auf dem Mikrocontroller◦ Cross Compiler◦ Kompilierung auf Windows und Linux

MCK – Programmierung - Übersicht

Vereinfachte Hardwareansteuerung für die Schüler Es werden Kommandos (für die Hardware) mittels

Tickets abgesetzt

Kommando-Typen◦ Setter-Kommando: Setzt den Wert einer Hardware-Adresse◦ Getter-Kommando: Fragt den Wert einer Hardware-Adresse ab

Schritte nach dem Anlegen eines Tickets1. Kommandotyp setzen2. Hardware-Adresse definieren (Zwei Modi)3. Eventuellen Parameter setzen (Setter-Kommando)4. Ausführen (Zwei Modi)

Was macht das Ticket-System? (MCK)

t…Aktives Ticket-Objekt Per Struktur

◦ Code: t.setGetterKommando(MCK.Servo0.Position);◦ Für Anfänger◦ Struktur enthält nur die wichtigsten Module

Per String◦ Code: t.setGetterKommando(“/Servo/0/Position“);◦ Für Fortgeschrittene und Profis◦ Alle Module ansprechbar◦ In Schleifen verwendbar

Möglichkeiten zur Definierung der Hardware-Adresse (MCK)

executeBlocking()◦ Hauptthread wird angehalten◦ Fortsetzung beim Erhalten eines Wertes◦ GETTER-Kommandos

executeNonBlocking()◦ Hauptthread wird nicht angehalten◦ Manuelle Statusabfragen mittels hasFinished()◦ GETTER- und SETTER-Kommandos

Ergebnis der Ausführung wird mittels getValue() abgefragt

Ticket Ausführungsmodi (MCK)

Realisierung von executeNonBlocking()

Java C#

Boolean ret = false;Integer res;…public void handleMessage(OscMessage msg){ … ret = true; ArrayList<Object> args = msg.getArguments();

res = Integer.parseInt(args.get(0).toString());}…public Boolean hasFinished(){ return ret;}…public int getValue(){ return res;}

Boolean ret = false;int res;…private void callBackHandler(OscMessage oscM){ … ret= true; res = (int)oscM.Values[0];}…public Boolean hasFinished(){ return ret;}…public int getValue(){

return res;}

Realisierung von executeBlocking()

Java C#

final Object sync = new Object();…public void handleMessage(OscMessage

msg){… synchronized(sync) { sync.notifyAll(); }}…synchronized(sync){ sync.wait();}

public class waiterThread{ Boolean stop = false;

public void dowork() { while (!stop) ; }

public void stoppen() { stop = true; }}…private void callBackHandler(OscMessage oscM){ if (s.wt != null) { s.wt.stoppen(); }}…s.wt = new waiterThread();t = new Thread(s.wt.dowork);t.Start();t.Join();

Zu Kontrolle des Datenflusses◦ Immer nur ein Ticket aktiv

Einfache und effiziente Unterstützung von SETTER- und GETTER-Kommandos

Unterstützung mehrerer Benutzergruppen Leichterer Umstieg zwischen den HL-

Sprachen◦ Verwendung bleibt gleich◦ Ähnliche Exceptions

Vereinheitlichung der Kommunikation über LAN- und USB-Port

Warum ein Ticket-System? (MCK)

MCK – Example-StrukturBetroffenes Objekt

Schritt Funktion

mt MakingThings-Objekt anlegenmt Port im Konstruktor wählen Port.USB oder Port.LANmt Verbindung öffnen open()mt Verbindung testen isReady()mt Ticket generieren generateTicket()t Kommando und Kommandotyp setzen Setter/Getter möglicht Kommando ausführen 1. executeBlocking() -> Ausführen und

Hauptthread blockieren [GETTER]2. executeNonBlocking() -> Ausführen und Hauptthread nicht blockieren [GETTER, SETTER]

t Bei Getter Kommandos das Ergebnis auslesen

getValue()

t Speicher den das Ticket-Objekt belegt freigeben

Dispose()

mt Verbindung schließen close()mt Speicher den das MakingThings-Objekt

belegt freigebenDispose()

MCK – Vergleich der HL-Sprachen

Java C#

MakingThings mt = new MakingThings(Port.LAN);

mt.open();

Ticket t = mt.generateTicket();

t.setGetterKommando(MCK.Servo0.Position)

t.executeBlocking();

System.out.println(t.getValue());

t.dispose();

mt.close();mt.dispose();

MakingThings mt = new MakingThings(Port.LAN);

mt.open();

Ticket t = mt.generateTicket();

t.setGetterKommando(MCK.Servo0.Position)

t.executeBlocking();

Console.WriteLine(t.getValue());

t.Dispose();

mt.close();mt.Dispose();

Bauen auf libusb auf OS-Unabhängig

C#-Lib: In DLL zusammengefasste C-Funktionen verwendet

Java-Lib: LibusbJava benutzt um C#-Lib nachzubilden

I2C - Programmierung

Bibliothek für die i2c-tiny-usb Hardware Komponente

Open Source Bietet eine einheitliche Schnittstelle für USB-

Entwicklungen Bewusst simpel gehalten OS-Unabhängig Weit verbreitet

Entwickelt in C Java-Port: LibusbJava

Libusb (I2C)

i2c_get_multiple_converters◦ Liefert die Adressen der an-

geschlossenen Converter

Wenn nur ein Converteri2c_init_win()

I2C – Example-Strukturi2c_get_multiple_convertersi2c_get_multiple_converters

i2c_init_win_multiplei2c_init_win_multiple

i2c_tiny_usb_get_funci2c_tiny_usb_get_func

i2c_lookup_addressi2c_lookup_address

i2c_write_basici2c_write_basic

i2c_read_basici2c_read_basic

i2c_close_wini2c_close_win

Einordnung des ROLEZ-Systems

Betriebssystem

Laufzeitumgebung (.NET, Java)

Übernommene Bibliotheken

ROLEZ-Bibliotheken

Benutzerprogramm

Warenwert des Endaufbaus: ca. € 150

Arbeitszeit: je ca. 230 Stunden

2 Systeme

3 Sprachen

15 Samples

Fakten