Pflichtenheft. Intelligente Roboter. Diplomarbeit HTA-BE I96 Abteilung Informatik. Michael Dürig & Stefan Graf & Rolf Moser. Berner Fachhochschule

Transkript

1 Berner Fachhochschule Hochschule für Technik und Architektur Bern Intelligente Roboter Pflichtenheft Diplomarbeit HTA-BE I96 Abteilung Informatik Michael Dürig & Stefan Graf & Rolf Moser

2 Dokumentinformation Projekt Intelligente Roboter I96 Diplomarbeit Team Dürig Michael Graf Stefan Moser Rolf Ablageort Änderungskontrolle Version Datum Name Bemerkung md/rm Dokument erstellt md/rm/sg Vorhaben und Ziele überarbeitet rm Anpassen an Template Änderung Freigabe Prüfstelle Datum Visum Betreuer/Experte HTA-BE 25 Mai /11

3 Inhaltsverzeichnis 1 EINLEITUNG AUSGANGSLAGE UND UMFELD VORHABEN ZIELE ABGRENZUNG 5 2 PROJEKTORGANISATION PROJEKTTEAM BETREUER EXPERTE ARBEITSZEITEN SITZUNGEN 6 3 PROJEKSPEZIFISCHES VORGEHENSMODELL PROJEKTSTRUKTUR MEILENSTEINE RISIKOANALYSE 8 4 ERGEBNISSE BESONDERHEIT DIESES PROJEKTS DOKUMENTE SOURCE-CODE 9 5 KONFIGURATIONSMANAGMENT PROJEKTABLAGE ÄNDERUNGSKONTROLLE ARCHIVIERUNG UND DATENSICHERUNG 10 6 QUELLEN 11 HTA-BE 25 Mai /11

4 1 Einleitung 1.1 Ausgangslage und Umfeld Autonome Mobile Agenten (im folgenden auch Roboter) werden u.a. überall dort eingesetzt wo Arbeiten durchzuführen sind die von Menschen nicht direkt erledigt werden können. Dies kann sein weil die Arbeiten zu gefährlich sind, die Umgebungsbedingungen zu feindselig oder der Arbeitsort auf Grund seiner physikalischen Beschaffenheit für den Menschen unzugänglich ist. Diese Roboter müssen ihre Arbeit in einer natürlichen und entsprechend sehr komplexen Umgebung verrichten und die Anforderungen an ein Kontrollsystem für solche Roboter ist dementsprechend hoch. Ein solches soll möglichst robust und anpassungsfähig sein. D.h. der Roboter soll sich einerseits innerhalb gewissen Grenzen an Änderungen in seiner Umwelt anpassen können und andererseits auf vom Entwickler nicht vorhergesehene Ereignisse angemessen reagieren können. Entwicklung, Implementation und Tests solcher Kontrollsysteme nach den klassischen Methoden der Softwareentwicklung ist extrem aufwendig und die Ziele «Anpassungsfähigkeit» und «Robustheit» sind nur schwer zu erreichen. Seit ende der achtziger Jahre zeichnet sich eine neue Richtung im Gebiet der künstlichen Intelligenz ab (z.t. auch «New AI» genannt). Hier wird davon ausgegangen, dass zum Entwickeln von,intelligenten Programmen zur Kontrolle von Robotern neue Grundsätze angewendet werden müssen [1, 2, 3]. Zentral ist dabei die Situiertheit (situatedness) des Systems. Darunter wird verstanden, dass die Umwelt eines Agenten vollständig subjektiv aus dessen Perspektive betrachtet wird und nicht aus der des Beobachters/Entwicklers. Nicht der Entwickler entwirft ein Modell der Umgebung anhand dessen der Agent sich dann bestimmt verhalten soll, sondern der Agent bildet sich sein eigenes Modell mittels Interaktionen mit seiner Umwelt. Das Verhalten eines situierten Agenten basiert zum grössten Teil auf seiner aktuellen Situation und nicht auf einem detaillierten gesamtheitlichen Plan (world model). Viele der Arbeiten in diesen Gebieten befassen sich mit Grundlegenden Themen zum Verständnis der Intelligenz, der Evolution dem Zusammenwirken Evolution und Intelligenz bzw. Anpassungsfähigkeit und dem Verhalten von natürlichen und künstlichen Wesen (synthetische Psychologie). 1.2 Vorhaben Es soll basierend auf Techniken wie genetische Algorithmen, neuronale Netze u.a. sowie deren Kombinationen ein Roboter Kontrollsystem entwickelt werden, mit welchem der Khepera Miniatur Roboter in seiner Umgebung ein Ziel suchen und finden kann. In einem ersten Schritt werden mögliche Ansätze und zugehörigen, geeignete Umgebungsklassen erarbeitet und nötigenfalls vorab Versuche durchgeführt. Darauf basierend wird entschieden welche Ansätze weiter verfolgt, implementiert, optimiert, ausgiebig dokumentiert und getestet werden sollen. Wenn möglich und sinnvoll sollen sich Kontrollprogramme kooperativ verhalten können, so dass z.b. die Roboter Informationen über ihre Umgebung austauschen können. Anmerkung: Unter einem Roboter Kontrollsystem wird nicht notwendigerweise ein Individuum basiertes System verstanden, sondern ggf. ein Populations basierendes System (z.b. Genetische Algorithmen). Das bedeutet, die Anpassungsfähigkeit ist in solchen Fällen nur im Rahmen einer Population gegeben. HTA-BE 25 Mai /11

5 1.3 Ziele - Entwickeln eines Roboter Kontrollsystems für den Khepera Miniatur Roboter welches diesen befähigt von einem beliebigen Startpunkt aus ein Ziel in seiner Umgebung zu suchen und zu finden. Das Kontrollsystem ist in gewissen Grenzen robust und anpassungsfähig. Es kann in seine Aufgabe in einer bestimmten Klasse von Umgebungen erfüllen. Es ist nicht fest auf exakt eine Umgebung vorprogrammiert. Weitere, konkrete Teilziele werden im Realisierungskonzept festgelegt. Dieses wird Aussagen darüber enthalten, welche Ansätze weiter verfolgt werden und was die zu implementierenden Kontrollsysteme leisten sollen. 1.4 Abgrenzung - Mit dieser Arbeit soll untersucht werden wie, mit welchen Techniken und inwieweit intelligente Kontrollsysteme entwickelt werden können. Die Arbeiten werden mit zwei Khepera Miniatur Robotern und zugehöriger Simulationssoftware durchgeführt. - Die Arbeit befasst sich mit den konzeptionellen Aspekten und Testimplementationen. Aspekte wie Multi-Plattform Fähigkeit, physikalische Autonomie der Roboter und Hardware Unabhängigkeit, werden nach Möglichkeit angestrebt sind jedoch sekundär. - Die gewählten Umgebungen müssen den Möglichkeiten des verfolgten Ansatzes und denen des Khepera Miniatur Roboters entsprechen. D.h. Die Umgebungen müssen die physikalischen Gegebenheiten des Roboters und die theoretischen Möglichkeiten des Ansatzes berücksichtigen. Weitere individuelle Systemangrenzungen betreffen der zu implementierenden Kontrollsysteme werden im Realisierungskonzept festgelegt. HTA-BE 25 Mai /11

6 2 Projektorganisation Auf eine Organisationshierarchie wird verzichtet. Die Teammitglieder sind gleichberechtigt. Verantwortungsbereiche werden falls nötig entsprechend zugewiesen. Die Verantwortung für einen Bereich ist aber nicht gleichbedeutend mit alleiniger Durchführung. 2.1 Projektteam Name Vorname Dürig Michael Graf Stefan Moser Rolf 2.2 Betreuer Name Vorname Dr. Boillat Jacques Aeschimann Peter 2.3 Experte Name Vorname Eich Walter 2.4 Arbeitszeiten Teilnehmer: Projektteam Häufigkeit: Wöchentlich Dauer 4 Stunden Dienstag 4 Stunden Freitag 4 Stunden individuell Der Dienstag wird für Arbeiten und Besprechungen, welche in Bern stattfinden müssen, reserviert. Am Freitag wird in der Regel in Basel gearbeitet. Die Wochenarbeitszeit beiträgt 16 Lektionen à 45 Min dies entspricht 12h. 2.5 Sitzungen Teamsitzungen: Zweck: Projektstand, Terminüberwachung, Entscheidungen und weiteres Vorgehen Teilnehmer: Projektteam Häufigkeit: In der Regel jeden Dienstag Dauer: 30 Minuten HTA-BE 25 Mai /11

7 Reviews: Zweck: Teilnehmer: Häufigkeit: Dauer: Projektstand Projektteam, Betreuer Zwischen den Meilenstein-Reviews alle zwei bis drei Wochen 30 Minuten Meilenstein Review: Zweck: Meilenstein Abnahme Teilnehmer: Projektteam, Betreuer, Experte Häufigkeit: Beim erreichen eines Meilensteins Dauer: 30 Minuten HTA-BE 25 Mai /11

8 3 Projekspezifisches Vorgehensmodell 3.1 Projektstruktur Projektphase Inhalt Resultat Projekt-Setup Konkretisierung der Problemstellung Definieren der Ziele Realisierungskonzept Evaluation von Roboter Kontrollsysteme Bewertung der Kontrollsysteme und festlegen der zu Realisierenden Festlegen der Versuchsanordnungen Implementation Zu jeder festgelegten Versuchsanordnung : Analyse / Design Aufbau Durchführung Bewertung Auswertung Gesamtbewertung Erreichte Ziele Erfahrungen Schlussbemerkung Pflichtenheft Realisierungskonzept Implementationen und dazugehörige Berichte Projektbericht 3.2 Meilensteine Meilenstein Datum Abnahme Pflichtenheft Abnahme Realisierungskonzept Abschluss Implementation Abnahme Projektbericht Risikoanalyse Risiko Faktor Auswirkung Massnahmen Personenausfall (Krankheit, Militär, Beruf) Mittel Gross Straffe Planung, Gute Koordination, Teamsitzungen Technologisches Neuland Hoch Tief Klare Definition des Arbeitsinhaltes und der Ziele in der Konzeptphase Das Realisierungskonzept soll diesem Umstand Rechnung tragen Hardware Mittel Tief Hardware (Khepera-Roboter) doppelt vorhanden, Ausweichen auf Simulator Im Realisierungskonzept werden Erfolgsaussichten und Risiken für die einzelnen Kontrollsysteme separat abgeschätzt. HTA-BE 25 Mai /11

9 4 Ergebnisse 4.1 Besonderheit dieses Projekts Bei dieser Diplomarbeit liegt das Schwergewicht nicht primär im Software Design sondern mehr im Konzeptionellen und Experimentellen Bereich. Dies hat natürlich auch Auswirkungen auf die zu erstellende Dokumentation. Insbesondere bedeutet dies, dass wir nicht eine Dokumentation im Sinne von Analyse, Design und Implementation erstellen werden. Stattdessen werden Dokumente mit der Beschreibung der von uns durchgeführten Testimplementationen, Resultate und der gemachten Erfahrungen entstehen. 4.2 Dokumente Bezeichnung Pflichtenheft Realisierungskonzept Implementation- und Testbericht Journal Projektbericht Inhalt Beschreibung der Ziele, Projektorganisation (gilt als definitive Aufgabenstellung) Festlegen, welche der evaluierten Kontrollsysteme realisiert werden. Definieren von Verhaltensmuster welche von den Kontrollsystemen erlernt werden sollen und zugehörige Testfälle definieren. Vorhaben, Versuchsaufbau, Resultate, Beurteilung Chronologische Notizen zum Projektverlauf Projektverlauf, Erreichte Ziele, Bemerkungen, Schlusswort 4.3 Source-Code Für jedes zu implementierte Kontrollerprogramm werden die benötigten Softwarekomponenten zusammengestellt. Zeigen sich im Realisierungskonzept, Softwaremodule die gemeinsam von mehreren Kontrollerprogrammen benötigt werden, so werden diese separat z.b. in Form von Libraries erstellt. HTA-BE 25 Mai /11

10 5 Konfigurationsmanagment 5.1 Projektablage Sämtliche Projekt Ergebnisse werden auf der Ablage abgelegt. Zugleich ist dies die Adresse der Diplomarbeits Home-Page, über welche alle freigegebenen Dokumente eingesehen werden können. 5.2 Änderungskontrolle Die Versionsnummer eines Dokumentes beginnt mit seiner Erstellung bei der Version 0.1. Bis zu seiner Freigabe oder Abnahme wird die Version nur in den Nachkommastellen erhöht. Jeweils nach der Freigabe oder Abnahme wird die Version auf 1.0 gesetzt. Nach jeder weiteren Freigabe (phasenabhängig) wird die Version in der Vorkommastelle erhöht. 5.3 Archivierung und Datensicherung Die zu erstellenden Dokumente werden während der Bearbeitung in einem nur für das Team zugänglichen Verzeichnis gespeichert. Nach der Freigabe werden die Dokumente ins PDF Format konvertiert und als solche archiviert. Die gesamte Projektablage wird regelmässig gesichert. Periodisch wird die Projektablage zusätzlich noch auf CD archiviert. HTA-BE 25 Mai /11

11 6 Quellen [1] Brooks, R.A., Intelligence without representation, Artificial Intelligence 47 (1991), [2] Brooks, R.A., Intelligence Without Reason, MIT AI Lab Memo 1293, (April 1991). [3] Pfeifer, R., Symbols, patterns, and behavior: towards a new understanding of intelligence, Proc. Japanese Conference on Artificial Intelligence, (1996), HTA-BE 25 Mai /11