Download Flyer:

Das AKSEN-Board wurde 2003 im Bereich 'Technische Informatik' im Fachbereich Informatik und Medien an der FH Brandenburg entwickelt und befindet sich seitdem in der Anwendung in Robot Building Labs an verschiedenen Fachhochschulen (u.a. Hannover, Brandenburg, Hamburg, Dortmund ... ) und Universitäten.

Das AKSEN-Board realisiert 2 Anwendungsfälle:

1. als eigenständiger Controller für reaktive Robots (ähnlich 6.270, RCX, NXT, Arduino, C-Control etc.)
2. als Aktor- und Sensorserver in einem RCUBE - System

Das AKSEN-Board tritt in unserem Labor die Nachfolge des 6.270-Boards an. Durch die langjährige Erfahrung mit verschiedenen Controllern für reaktive Roboter wurden von uns folgende Anforderungen definiert.

Sie wollen mehr wissen ...

• Handbuch (1.5 MB, PDF)
• Aktuelles CD-Release: AKSEN-CD Version 1.04 mit AKSEN-Lib 00.965, Flasher 1.4/0.3, Handbuch 1.04 (45 MB, zipped, 07.02.2005)
• 20.12.2006 - Bugfix des Empfanges von moduliertem Infrarot und Umstieg auf sdcc 2.6.0 in der AKSEN-Lib 0.970: Migrationsanleitung auf Aksenlib 0970.pdf, EXPORT-0970.zip, sdcc
• 11.05.07 - USB-RS232-Adapter: Bricht der Flashvorgang über einen derartigen Adpater ab, so versuchen Sie einen der beiden verzögerten Flasher (Windows) aus dem ZIP-File USB-RS232-flasher.zip
• 08.12.2008 - Bugfix beim mehrmaligen Selbstbeenden eines Prozesses AKSEN-Lib 0.971: EXPORT-0971.zip (Migration wie bei 0.970)
• Bauanleitung zum Selberlöten des AKSEN (PSD muss von der FH Brandenburg programmiert werden)

Ausprobieren

• im KI-Labor jederzeit nach Absprache
• Informationen zu Zubehör, kostenlosen Teststellungen bei Ingo Boersch

Pizzabote 2024 - Breitensuche praktisch

In diesem Bachelorprojekt geht es um die Konstruktion und Programmierung eines Roboters, der Pizzas einzeln an Kunden ausliefert. Die Welt ist formalisiert, nicht wirklich essbar und dennoch real und physisch:

"Ihr Roboter erhält den Auftrag, eine oder mehrere Pizzen auszuliefern. Das Streckennetz ist ein einfaches Gitter, in dem es jedoch zu Störungen und damit zu unpassierbaren Kreuzungen kommen kann. Die gute Nachricht ist, dass Sie über globales Wissen verfügen und die aktuelle Karte der befahrbaren Wege dem Roboter kurz vor dem Start zur Verfügung gestellt wird."

Das ist auf einem Mikrocontroller in C mit einer Breitensuche möglich, wenn man sie denn implementieren kann, alle Sonderfälle berücksichtigt und mit 7000 Byte(!) Speicher ohne Heap auskommt. Der Aktionsplan muss dann "nur" noch ausgeführt werden. Das Acoustic Vehicle Alerting System (AVAS) darf natürlich nicht fehlen.

Die Aufgabe wurde in diesem Projekt von den 4 Teams hervorragend gelöst. Bei vier Runden und drei Lieferadressen sind theoretisch 124 Punkte für ein Team möglich, wenn alle Lieferungen funktionieren und kein anderer Roboter die Adresse zuerst beliefert, wie z.B. im Finale. Die Punktetabelle zeigt, wie nahe die Teams der optimalen Punktzahl gekommen sind.

Die Roboter

Wettbewerb am 17. Januar 2024

Es traten 5 Roboter zum Wettbewerb an: PizzaPronto, Form Follows Function, Name1 und driveReal(Fast).

Nach erfolgreichen Einzeldemonstrationen und den ersten drei Runden qualifizierten sich Form Follows Function und PizzaPronto punktgleich für das Finale. Im Finale waren insgesamt drei Pizzen zu liefern, wobei die entscheidende Frage war, wer die dritte Pizza liefern kann. PizzaPronto war durch eine strategisch bessere Wegplanung (siehe Video) in der Lage abzukürzen, die Pizza schneller als der gleich schnelle Gegener zu liefern und zu verteidigen.

Creative Commons Lizenz

Pizzabote 2022

Das Unternehmen Nuro.ai (Kalifornien) entwickelt ein kleines vollautomatisches Lieferfahrzeug und erhält im Jahr 2019 eine Finanzspritze von 940 Millionen Dollar. Geldgeber ist der Investmentfonds des japanischen Technologiekonzerns Softbank. Es folgt eine Kooperation mit Domino’s Pizza: "Once an order is ready to be delivered from a participating location, Domino’s employees will load it into one of several compartments in Nuro’s thin, stout R1, which packs a proprietary combo of laser sensors, cameras, and computers. The vehicles top out at 25 miles per hour and are fully driverless ...".

Ist das schon SAE-Level 4?

Eine Zeitlang werden die Lieferroboter von einer Eskorte begleitet, aber das ändert sich im Jahr 2021: die aktuelle Version R2X fährt ohne Eskorte - allerdings nun mit einer Fernsteuerung als Lösung für Notfälle.

Nuro nennt in seiner Stellungnahme an die NHTSA vier (unscharfe) Bedingungen, damit der Lieferroboter SAE-Level 4 erreicht:

• eine gute Karte,
• langsamer als 25km/h,
• schönes Wetter und
• keine komplexen Situationen, wie Unfälle, Straßensperrungen ....

Zitat: "When these conditions are met, our vehicles operate autonomously without any expectation that a driver or passenger will respond to a request to intervene, meeting the Society of Automotive Engineers’ definition of Level 4 autonomy. " [Quelle: Delivering Safety: Nuro’s Approach (PDF)]

Aufgabe

Konstruieren Sie mit dem AKSEN-Board ein mobiles autonomes System (Roboter), der im Testareal des KI-Labors Pizzen einzeln an mehrere Kunden ausliefert - aber Vorsicht: einige Kreuzungen sind gesperrt! Und natürlich muss ein Robotersystem mit Stromversorgung, Motoren, Getrieben, geeigneten Sensoren und Greifer gebaut werden. Falls die Probleme zu groß werden (und groß werden sie auf jeden Fall), besteht die Fallback-Möglichkeit beim Abschlusswettbewerb mit einem manuellen Planer zu starten.

Wettbewerb am 13. Januar 2022 im eingeschränkten Präsenzbetrieb.

Es traten 5 Roboter zum Wettbewerb an: Deception (M), ML_Power (M), Fritzi (A), Kiki (A) und BetterNERF (A). Die mit (A) markierten Systeme planen die Fahrwege automatisch im 7000 Byte großen Hauptspeicher, die anderen manuell.

Im Wettbewerb setzten sich die vollautomatischen Systeme deutlich gegen die teilautomatisierten durch. Die Spitzengruppe bildeten Fritzi mit 44 Punkten sowie Kiki und BetterNerf jeweils mit 97 Punkten. Das Finale gewann Kiki knapp gegen BettterNerf.

Die Roboter

Das PST-Thema im KI-Labor: "Kleine Aufgaben sollen durch die Konstruktion und Programmierung einfacher Maschinen gelöst werden."

• Kleine Aufgaben? Es werden C-Programme (max 100 Zeilen) mit Datentypen und Kontrollstrukturen benötigt. Sie lernen im Projekt, diese zu schreiben.
• Maschinen?! Die Ausführung der Programme erfolgt auf kleinen Maschinen, die Sie selbst aus Sensoren, Motoren und Sensoren konstruieren.

Ergebnisse

Schiebepuzzle@Home: zuhause konstruiert, online diskutiert und vorgeführt

Das Schiebepuzzle ist ein bekanntes Beispiel zur Aktionsplanung. Das Puzzle besteht aus einem 3x3-Feld in dem 8 Plättchen in einer Stellung angeordnet sind. Die Plättchen können horizontal oder vertikal in Richtung auf die freie Stelle bewegt werden. Die Aufgabe besteht darin, in der Ausgangsstellung die Plättchen sukzessive solange zu verschieben, bis die Zielstellung erreicht wird. In jeder Stellung gibt es mindestens zwei und höchstens vier Schiebemöglichkeiten. Wenn wir von durchschnittlich drei Möglichkeiten ausgehen, so ergibt dies einen Suchbaum der Verzweigungsrate 3. Bei einem typischen Lösungsweg der Länge 20 ergibt dies eine Gesamtmenge von 3^20, also etwa 3,5 Milliarden Knoten in der untersten Ebene des Suchbaumes. Dies ist mit reiner Tiefensuche oder Breitensuche nicht mehr zu bewältigen - oder vielleicht doch? PS: Sie haben 7000 Byte Speicher für Ihre Datenstrukturen.

Aufgabe

Konstruieren Sie mit dem AKSEN-Board ein autonomes System (Roboter), das eine 3x3-Version des Schiebepuzzles repräsentiert und dieses lösen kann. Das Puzzle sollte dabei stets gut sichtbar sein, so dass alle Zwischenstellungen des Lösungsvorgangs gut wahrgenommen werden können. Eine Anzeige auf dem LCD-Display reicht nicht aus. Die Stellung soll mechanisch visualisiert werden, idealerweise mit tatsächlichen Puzzleteilen.

Und natürlich muss ein Robotersystem mit Stromversorgung, Motoren, Getrieben, geeigneten Sensoren und das Puzzle gebaut werden. Falls die Probleme zu groß werden (und groß werden sie auf jeden Fall), besteht die Fallback-Möglichkeit beim Abschlusswettbewerb mit einem manuellen Plan zu starten.

Wettbewerb online am 14. Januar 2021

Es traten 5 Roboter zum Wettbewerb an: Tilting Eggs, QWRTY, IR-06, OptoBotV2.2 und Kubus. Das Finale IR-06 (37 Punkte) gegen Kubus (31 Punkte) gewann fehlerlos IR-06.

Der autonome Pizzabote SAE-Level 5

Wir wiederholen die schwierige Aufgabe vom letzten Jahr, bei der ein autonomes Fahrzeug entworfen, konstruiert und programmiert werden soll, das selbständig kürzeste Wege in einer übergebenen Karte plant und ausführt. Der Anwendungsfall ist ein Lieferroboter, wie er in verschiedenen Städten erprobt wird. Das System übernimmt hier sowohl die Rolle des Roboters (Lokalisation, lokale Navigation mithilfe der Sensorik, Abliefern der Pizza) als auch die der Planungsschicht, bspw. einer zentralen KI-Komponente, die auf die Verkehrssituation der Stadt zugreifen kann und Routen nach aktueller Verkehrslage berechnet (globale Navigation).

Und natürlich muss ein Robotersystem mit Stromversorgung, Motoren, Getrieben, geeigneten Sensoren und Transportkapazität gebaut werden. Falls die Probleme zu groß werden (und groß werden sie auf jeden Fall), besteht die Fallback-Möglichkeit beim Abschlusswettbewerb mit einem manuellen Plan zu starten. Es traten 4 Roboter zum Wettbewerb an: _007, Bumblebee, Rüdiger und Fathi. Das Finale Bumblebee (84 Punkte) gegen Fathi (73 Punkte) gewann Fathi.

Der autonome Pizzabote SAE-Level 5

Im Straßenverkehr werden Autos von leistungsfähigen Fahrerassistenzsystemen gesteuert - aber bisher nur im SAE-Level 2 [1], d.h. unter ständiger Beobachtung des Fahrers. Aktuelle Pressemeldungen berichten von ersten Serien-Fahrzeugen mit SAE-Level 3, in denen der Fahrer seine Aufmerksamkeit abwenden darf und bei Problemen vom Auto gerufen wird [2].

Stellen wir uns nun einen unbemannten Transportroboter vor, der auf einer öffentlichen Straße vorsichtig Güter von A nach B transportiert, bspw. einen Pizzaboten mit SAE-Level 5 für den Stadtverkehr. Probleme bei der Auslieferung entstehen bei Staus, Baustellen oder durch liegenbleibende Fahrzeuge. Der damit verbundene Verlust befahrbarer Strecken erfordert ein Neuplanen von Fahrtrouten. Und hier kommen Sie ins Spiel.

Ihr Roboter erhällt den Auftrag, eine oder mehrere Pizzen auszuliefern. Das Streckennetz ist ein einfaches Gitter, in dem es allerdings zu Störungen und damit unbefahrbaren Kreuzungen kommen kann. Die gute Nachricht ist, das Sie über globales Wissen verfügen und die aktuelle Karte der befahrbaren Wege dem Roboter kurz vor dem Start zur Verfügung gestellt wird. Entwerfen, konstruieren und programmieren Sie einen geeigneten Roboter!

Roboter

Im Wettkampf Ende Januar 2018 traten die vier Roboter Sion, Simon, Kabelbinder-Jack und Roberat gegeneinander an, wobei die letzteren mit automatischer Wegplanung fuhren. Die Ergebnisse finden sich in der Punktetabelle. Im Finale setzte sich Kabelbinder-Jack knapp gegen Sion durch.

Die Roboter werden in folgenden Projektarbeiten beschrieben.

• Roboter Roberta
  "Da Roberta sich beim Abarbeiten längerer Fahraufträge einige Male wie eine „Prinzessin“ verhalten hat, dachten wir, es wäre eine gute Idee, zu überlegen, die Fahraufträge nach der zurückzulegenden Distanz zu sortieren. So kann sich Roberta langsam an die Herausforderungen des Alltags gewöhnen. Die Fahraufträge werden nun aufsteigend nach den Kosten der jeweils nächsten erreichbaren Kreuzung sortiert. So erhalten Fahraufträge mit geringeren Kosten eine höhere Priorität als jene mit höheren Kosten. Als Sortierverfahren haben wir den Bubblesort angewendet."
• Roboter Kabelbinder-Jack
  "Dieses Projekt hat uns sehr viel Spaß gemacht und unser Roboter „Kabelbinder-Jack“ ist ein Ergebnis guter und konstanter Teamarbeit. Wir haben alle während des Semesters geforderten Ziele umgesetzt und rechtzeitig zum Wettbewerb einen konkurrenzfähigen Roboter an den Start gebracht. Auch wenn es trotzdem noch einiges zu verbessern gibt, sind wir mit unserer Arbeit zufrieden, da der Roboter jede Route aus der Datei der Fahraufträge erfolgreich bewältigen kann. "
• Roboter Sion
  "Am Anfang war alles ja noch sehr ruhig und machte auch viel Spaß, aber irgendwann begann der Druck zu steigen, weil auch die Anforderungen stiegen. Nachdem der Roboter schon geradeaus fahren konnte sollten wir jetzt Greifer bauen, und damit auch die entsprechenden Getriebe montieren und einen Taster noch dazu, damit der Roboter weiß, dass er zum Lieferpunkt der Pizza angekommen ist. Gehen wir einfach mal tiefer in den Aufbau… "
  
  

[1] Levels of driving automation are defined in SAE INTERNATIONAL STANDARD J3016

[2] Audi 07/11/17 The new Audi A8: future of the luxury class 

Autonome Fahrzeuge zum Transport von Passagieren im öffentlichen Raum "nehmen Fahrt auf".

Nach einer Pressemeldung des BMVI plant Bundesverkehrsminister Dobrindt eine Teststrecke für autonome Fahrzeuge auf der Autobahn A9 in Bayern.

Singapur, mit dramatischen Problemen durch den Individualverkehr, geht noch einen Schritt weiter. Im Herbst 2014 testeten Besucher in zwei großen Parkanlagen ein PRT, bestehend aus führerlosen Taxis, die Golf Carts ähneln. Im nächsten Jahr soll das Projekt in die Strassen der Stadt ausgeweitet werden, um den Personentransport auf kurzen Strecken langfristig zu Fuß, mit dem Fahrrad oder dem PRT abzuwickeln. (Quelle: Technology Review).

Im Bachelor-Projekt orientieren wir uns an dem Anwendungszenario PRT und lösen es in vereinfachter Form.

Projekt im KI-Labor

Das modellierte PRT im KI-Labor besteht aus maximal drei erreichbaren Passagieren (blaue Bälle), die zu einer zentralen Veranstaltung (Linie AB) gebracht werden wollen. Natürlich einzeln und so schnell und sicher wie möglich. Aufgabe der Studenten ist somit der Entwurf, die Konstruktion und die Programmierung eines autonomen Roboters. Als globaler Sensor stehen dem Roboter Informationen über die aktuelle Verkehrslage (gesperrte Kreuzungen) zur Verfügung, die er zur selbständigen Planung seiner Fahrt verwenden sollte. Die Kombination aus Verkehslage und Passagierinformation bezeichnen wir als "Fahrauftrag". Der Roboter sollte beliebige gültige Fahraufträge erfüllen können. Die Aufgabenstellung erklärt die Details.

Ergebnisse

Beim Abschlusswettbewerb zum Tag der offenen Projekte am 22. Januar 2015 traten vier Temas mit funktionsfähigen Robotern an, in Klammern die in der Vorrunde transportierten Passagiere:

• Theseus (5)
• Driver (4)
• Robi (8)
• Jack the Gripper (12)

Jeder Roboter zeigte zunächst einzeln seine Fähigkeiten, gefolgt von einer Vorrunde mit jeweis drei Starts. Die gesammlten Punkte entschieden über den Einzug ins Finale. Jack the Gripper gewann die Vorrunde mit der maximal erreichbaren Punktzahl von 124, alle 12 Passagiere wurden innerhalb der Zeit fehlerfrei transportiert. Als Zweiter erreichte Robi das Finale, obwohl er bei den Passagieren ab und zu daneben griff. Theseus befolgte als ehrlichster Roboter exakt die Wettbewerbsregeln - auch wenn das bedeutete, wenige Zentimeter vor dem Passagier zu stoppen, da die Zeit von zwei Minuten abgelaufen war. Arbeitzeitregelungen gelten auch für Roboter. Driver zeigte mit dem A*-Algorithmus eine gute Planungsleistung, verzählte sich allerdings bei einigen Kreuzungen.

Im Finale "Drei Scheichs" zahlte sich die höhere Geschwindigkeit für Jack the Gripper aus, der damit einen Fahrgast mehr als Robi bediente.

Erreichte Punkte im Gesamtergebnis.

Fotos vom Wettbewerb

Architektur und Nutzerschnittstelle zur Missionskontrolle und -Visualisierung für autonome reaktive Roboter in einem einfachen Personal Rapid Transit

Ziel der Arbeit ist die Entwicklung einer Applikation zur Missionskontrolle und –visualisierung zur Nutzung im Lehrprojekt „Masdar City“ im Bachelorstudiengang Informatik. Hierzu sind die Anforderungen zu analysieren, bspw. welche Phasen die Kommunikation umfasst, ein gegen Übertragungsfehler und -verluste abgesichertes Protokoll sowie eine Client-Server-Architektur zu konzipieren und umzusetzen. Der Funktionsnachweis soll mit einem Kommunikations-Simulator erbracht werden, der als Textdatei vordefinierte Testfälle abspielt.

Kolloqium: 13.06.2014

Betreuer: Prof. Dr.-Ing. Jochen Heinsohn, Dipl.-Inform. Ingo Boersch

Download: A1-Poster

Wir wiederholen das schwierige Projekt "Masdar City" des letzten Jahres, in dem planende Roboter konstruiert und programmiert werden. Einen reaktiven LEGO-Roboter zu bauen ist zwar spannend, aber einen Roboter, der darüberhinaus zunächst einen optimalen Plan erstellen muss, ist etwas anpruchsvoller. Es handelt sich 'nur' um eine Planung in einer deterministischen Welt und auch die Fahrtausführung rechnet nicht mit dynamischen Überraschungen - aber dennoch muss ein passendes Suchverfahren mit wenig Speicher und CPU-Leistung umgesetzt werden. Der damit gefundene optimale Fahrweg ist aber noch kein Aktionsplan und erst noch in Handlungsanweisungen zu übersetzen. Die einfacheren Probleme reichen von der Regelung zum Linienfolgen, Getriebebau, Greiferkonstruktion bis zur Lokalisierung. Wird nur eines der Probleme nicht gelöst, erhält man trotz harter Arbeit einen nicht funktionierenden Roboter - Zeitplanung, Arbeitsteilung und realisitische Einschätzung von Schwierigkeiten werden missionskritisch.

• Bug,
• The Shame,
• Spacepolice,
• Jacob, die Zicke und
• der Bussomat.

Die Systeme zeigten hervorragende Leistungen im Wettbewerb am 16.01.2014, fast alle funktionierten komplett. Im Finale wurde die zuverlässige Spacepolice knapp vom etwas schnelleren Bussomat überholt. Unten die bis zum Wettbewerb unbekannten Fahraufträge, die Punkteliste und Fotos vom Wettbewerb:

Perspektiven von PRTs

19 Schüler und Schülerinnen des von-Saldern-Gymnasiums haben erfolgreich an den Projekttagen „C und LEGO“ im Bereich „Intelligente Systeme“ des Fachbereiches Informatik und Medien vom 09.09.2013 bis 12.09.2013 teilgenommen. Das beste Team erreichte 95 Punkte. Welche Aufgaben gelöst werden, entscheiden die Schüler selbst.

Inhalt:

• Entwurf und Konstruktion eines autonomen Systems mit dem AKSEN-Board
• Programmierung reaktiver Systeme in C
• Kennenlernen von Sensorik und Aktorik kleiner Roboter
• Vorstellung der Lösungen

Dauer: 15 h

Fotos vom Wettbewerb:

 PRT - Personal Rapid Transit

Ein PRT-System ist eine Flotte kleiner Fahrzeuge, die jeweils eine oder wenige Personen ohne Zwischenhalt zu individuellen Zielen transportieren. Das derzeit größte geplante PRT-Netz mit 30.000 3000 Fahrzeugen entsteht in Masdar City, einer am Reißbrett entworfenen Stadt in der Wüste der Vereinigten Arabischen Emirate. In Masdar City sollen 50.000 Menschen CO2- und energieneutral leben und arbeiten. Fahrzeuge mit Verbrennungsmotoren wird es dort nicht geben. Eine erste Testinstallation eines PRT-Netzes der Firma 2getthere (Niederlande) mit 10 Fahrzeugen, zwei Personen- und drei Frachtstationen ist seit August 2011 in Masdar City in Betrieb.

Probleme im PRT-Netz entstehen bei Überlastung (globaler Stau) oder durch liegenbleibende Fahrzeuge. Der damit verbundene Verlust befahrbarer Strecken erfordert ein Neuplanen von Fahrtrouten. Und hier kommen Sie ins Spiel.

Aufgabe

Ihr Roboter erhält den Auftrag, eine oder mehrere Personen abzuholen und zum Ziel zu bringen. Das Streckennetz ist ein einfaches Gitter, in dem es allerdings zu Störungen und damit unbefahrbaren Kreuzungen kommen kann. Die gute Nachricht ist, das Sie über globales Wissen verfügen und die aktuelle Karte der befahrbaren Wege dem Roboter kurz vor dem Start zur Verfügung gestellt wird.

Es ist eine der schwierigsten Aufgaben der letzten Jahre in diesem Projekt, da zusätzlich zur Roboterkonstruktion und -programmierung auch die Breitensuche eines optimalen Pfades zwar nach Lehrbuch aber mit vielen Detailproblemen zu lösen ist. Diesmal existiert keine Minimallösung (eingängig, wiederholbar, einfach zu bauen [BHL98]) - entweder ALLE Komponenten erfüllen ihre Aufgabe oder das System scheitert. Der Umfang der zu lösenden Teilprobleme erfordert eine klare Arbeitsteilung im Projekt, 10 Studenten in vier Teams nahmen teil.

• Mehr zur Aufgabe, Zwölf Testfälle , Kodierung der Fahraufträge 

Folgende Roboter traten an, verlinkt sind die Projektberichte:

• Crawling Hornet,
• Robi,
• Hurby,
• V4P8S,

Fotos vom Wettbewerb:

Am Mittwoch, den 17.10.2012, konnte die Projektgruppe 'Autonomes Segelboot' des Master-Studienganges Informatik dank mildem Wetter einen letzten Wassertermin im laufenden Jahr durchführen. Die Gelegenheit wurde dankbar angenommen, um die Neuzugänge des 1. Semesters in die Praxis des Projektes einzuführen.

Das Segelboot führte ein Reihe von Testläufen durch, während derer die neuen Projektmitglieder selbst Steuerung und Planung übernehmen konnten. Es wurde klar, dass das Projekt noch viele Aufgaben bereithält.

Mission

“The objective of the navigation contest is to evaluate a boat’s ability to accurately navigate a short upwind‐downwind course, all without manual between two red marks sailing windward to a mark in approximately 20‐60 m distance. After rounding the mark on port, the boat shall sail between the red marks again.”
[Sailing instructions, World Robotic Sailing Championship / International Robotic Sailing Conference 2011, Universität zu Lübeck]

Regeln

• 20‐60m langer Kurs mit einer Wende
• Abwechselnd drei Versuche, die beste Runde zählt
• Koordinaten der Bojen sind erst kurz vorher bekannt
• Zeitmessung beginnt bei Linienüberquerung
• Keine Punkte in der Runde bei: Bojenberührung,manuellem Eingriff bei Sairo
• Start gegen den Wind

Ergebnisse

Fotos

Table: Winner at 14.08.2012 is human

Fig: Screenshot mission control station

Ende April scheint der Segelroboter mit der neuen Architektur bereit für die erste Mission: autonome Fahrt zu einem Zielpunkt - ohne Segel mit Motor. Ideale Bedingungen bot hierzu das Gelände des Märkischen Seglervereins Brandenburg nahe der Regattastrecke, bspw. ein Ruderboot und Steg. Wetterbedingungen: leicht bewölkt, trocken, 16°C, Windstärke 0-1.

Mehr Fotos

Folgendes sollte getestet werden:

1. Handlebarkeit:

• Transport Boot und Team
• Inbetriebnahme am Wasser (Mast, BootsPC starten, GPS-Tracker aktivieren, Boot schließen)

2. Generelle Anforderungen:

• Schwimmfähigkeit
• Wasserdichtigkeit
• Schlagseite

3. Funktionalität Fernsteuerung:

• Steuerbarkeit der Aktorik
• Boot damit navigierbar?
• Reichweite

4. Funktionalität WLAN:

• Ad-Hoc-Verbindung realisierbar
• Reichweite

5. Programm manueller Modus (Fernbedienung + VNC):

• Sensorwerte anzeigen: Kompass, GPS
• Werte plausibel?
• Aktoren tatsächlich ohne Funktion?

6. Programm autonomer Modus:

• Steuerbarkeit der Aktorik durch BPC
• Umschalten zwischen den Modi

7. Missionen

• Mission definieren, übertragen und starten
• Anfahrt GPS-Punkt (geradeaus, verschiedene Längen) + Halten der Position
• mit An- und Abschalten des Motors
• Fahrt Quadrat/Rechteck/Dreieck aus GPS-Punkten
• Fahrt zu einem Polygon aus GPS-Punkten

8. Laufzeiten der Akkus protokollieren: Boot, Bootsrechner, Ufer-PC

Beim Meilenstein ergab sich eine lange Liste von neuen Aufgaben und insbesondere war der Motor durch den BootsPC nicht mit einer ausreichenden Geschwindigkeit ansteuerbar, so dass der Missionskern des Meilensteins nicht voll erreicht wurde. In zwei Wochen auf ein Neues.

Der ambitionierte, aber fehlgeschlagene Versuch der 'Zicke' im letzten Projekt mit einer direkten Fahrt durchs Labyrinth den Sieg zu erringen, inspirierte zwei Teams zu ähnlichen Konzepten: Roboter Thunder mit Hecklenkung und Abstandssensorik zum Wandfolgen, sowie Flying Knipser mit Odometern und aktiver Lokalisierung. Beides sehr vielversprechend und eine starke Konkurrenz zu den beiden Linienfolgern FOOK und Scared Lizard. Diese hatten allerdings eine 'geheime' Strategie in der Hinterhand, die bei zu schnellen Gegnern einen destruction-Modus vorsah, der eine der Spielregeln ausnutzte.

• Thunder von Sebastian Gräbitz, Dennis Schmidt
• FOOK (Flaming Octo-Optokoppler) von Josef Mögelin, Mathias Seetge
• Flying Knipser von Christian Heile, Sebastian Ali Nasrollahkan Shahrestanaki
• Scared Lizard von Benjamin Hoffmann, Daniel Schmidt

An fünf Tagen vom 20. bis 24. Juni 2011 bauten 21 Schülerinnen und Schüler des Leistungskurses Informatik der 11. und 12. Klassen des von-Saldern-Gymnasiums im KI-Labor autonome Roboter. Die Woche endete mit dem Abschlusswettbewerb am Freitag, 24. Juni, 13 Uhr im KI-Labor (Raum 130 im Informatikzentrum).

Thema: Das Kværner-Verfahren

Download: Plakat 

Die Roboter basieren auf dem AKSEN-Board und müssen zum Lösen der Aufgabe ein robustes Getriebe, Sensoren zum Erkennen des Startsignals und der Linien und Kreuzungen aufweisen. Problematisch war diesmal die hohe Anzahl gering untersetzter Getriebe und die damit verbundenen Probleme mit nicht vollständig geladenen Akkus und schwer zu kontrollierenden Regelschleifen. Auch war der Platz (und die Luft) etwas knapp, dank der neuen Klimanalage, die bald in Betrieb geht. Folgende Roboter traten an:

• Troll
• Das Fahrrad
• Alcoopterix 4.0
• Aligator13
• Kirbey
• Triple X
• Bernd

Natürlich ging am Wettbewerbstag Einiges schief, Roboter gaben vorm Wettbewerb ihren Geist und die Konstrukteure die Hoffnung auf. Im Einzelwettbewerb löste sich die Spannung, als die Teams gegenseitig ihre Systeme präsentierten, und dabei feststellten, dass von sieben Systemen nur drei den Wegpunkt A erreichen. Im Konkurrenzkampf setzen sich Kirbey und Das Fahrrad durch, wobei Kirbey zweimal sicher die volle Punktzahl erreicht. Das Finale gewinnt Kirbey.

Ergebnisse: Punkte (pdf)  und Fotos von R. Zimmermann

Konzeption eines autonomen Segelboots und Realisierung eines Reaktions-Prototyps

Ziel der Arbeit ist der Entwurf eines autonomen Segelbootes und die Erstellung eines ersten Reaktionsprotypen. Die besondere Schwierigkeit des Themas liegt in der Vielzahl zu treffender missionskritischer Einzelentscheidungen, die ein Verständnis des Gesamtsystems als autonomer Roboter voraussetzt.

Eine Anforderungsanalyse soll zeigen, welche Komponenten für ein autonomes Agieren eines Segelboots notwendig sind und wie sie in das Gesamtsystem eingegliedert werden. Dabei ist eine sorgfältige Auswahl der Komponenten zu treffen, wobei besonderes Augenmerk auf Kriterien wie zum Beispiel Platzbedarf, Gewicht oder Stromverbrauch gelegt wird, da in diesen Bereichen Beschränkungen mit der Verwendung eines Segelboots einher gehen. Nachfolgend muss jede Komponente einzeln auf ihre Funktionalität getestet werden. Bei den der Sensorik oder Aktorik angehörenden Bauteilen muss sichergestellt sein, dass über eine Schnittstelle auf die zur Verfügung gestellten Messwerte zugegriffen bzw. Steuerbefehle an sie übergeben werden können. Anschließend sollen alle Komponenten in geeigneter Form miteinander verbunden und im Segelboot untergebracht werden, wobei auf Wechselwirkungen zu achten ist, welche die Komponenten in ihrer Funktion einschränken könnten.

Wichtig ist außerdem die Realisierung einer hardwarebasierten Fallback-Möglichkeit, sodass im Notfall eingegriffen werden kann und von autonomer zu manueller Steuerung gewechselt werden kann. Schließlich soll es ein zentral im Hauptcontroller ausgeführtes Programm ermöglichen, alle von den Sensoren gelieferten Messwerte abzufragen und auszugeben, Steuerbefehle an die Aktoren zu senden und auf eventuelle Eingaben eines Benutzers zu reagieren.

Kolloquium: 11.03.2011

Betreuer: Prof. Dr. Jochen Heinsohn, Dipl.-Inform. Ingo Boersch

Download: A1-Poster, Diplomarbeit  

Studenten bauen bessere Roboter als Schüler, oder?

• Dancing Queen (Christian Kohls, Helge Scheel)
• Stanglnator + Küken (Daniel Kiewitz, Stefan Dieckmann, Daniel Kiertscher)
• Zicke (Nathanael Jurke, Alexander Scharow)
• Drunken Fist (Paul Lehmann, Bertram Sändig)

Die Punkteliste zeigt den knappen Sieg des Stanglnator. Eine kurze Präsentation (12 Minuten) zu den 4 Robotern senden wir als Grußwort an die HAW Hamburg zum dortigen Roboterwettbewerb:

Fotos vom Wettbewerb (Fotograf Ronald Zimmermann).

An fünf Tagen vom 13. bis zum 17. September 2010 bauten 13 Schüler des Leistungskurses Informatik der 13. Klassen des von-Saldern-Gymnasiums im KI-Labor autonome Roboter. Die Woche endete mit dem Abschlusswettbewerb am Freitag, 17. September, 13 Uhr im KI-Labor (Raum 130 im Informatikzentrum).

Thema: Das Kværner-Verfahren

Download: Plakat 

Die Roboter basieren auf dem AKSEN-Board und müssen zum Lösen der Aufgabe ein robustes Getriebe, Sensoren zum Erkennen des Startsignals, der Linien und Kreuzungen aufweisen. Das auch die strukturierte Programmierung eine wesentliche Rolle spielt, war sicher eine Erkenntnis der Woche. Folgende Roboter traten an:

• Alpha-Bot
• Predator 13
• Robozicke
• Optimus Prime
• PaMaMa

Im Wettbewerb hatte der Favorit Optimus Prime Probleme beim Linienfolgen und konnte die hervorragende Leistung der vorangegangenen Tage nicht stabil wiederholen. Auch Robozicke wollte mit dem Kopf durch die Wand, obwohl sie im Vorfeld schon das Labyrinth gemeistert hat. Predator 13 fuhr besser als erwartet, die Spitze übernahmen in den Vorrunden PaMAMa und Alpha-Bot mit zuverlässigen Fahrten und Kollisionen. Im Finale erreichte Alpha-Bot den Punkt C um wenige Sekunden früher und wurde so von PaMAMa nur wenig getroffen. Alpha-Bot erreichte und blockierte somit Punkt D (Beweisfoto).

Ergebnisse: Punkte (pdf)  und Fotos von R. Zimmermann

Mister Plüsch

• Studenten: Andre Morgenthal, Marcel Geßner, Stephan Lapoehn
• Mr. Plüsch ist ein behaviorbasierter autonomer, mobiler Roboter, der durch sein herziges Aussehen (hiefür wurde einem Plüsch-Schneemann das Fell über die Ohren gezogen) und kecke Ohrenbewegungen eine Tierähnlichkiet hervorruft. Werden die Ohren von roten Laserpointern getroffen, so drehen sie sich weg und der Roboter versucht zu fliehen. Dabei achtet er auf Hindernisse und rollt mit den Augen. Die ambitionierten Ideen warfen in der knappen Zeit nicht komplett umzusetzen.
• Projektdokumentation

Trash Box Robot

• Studenten: Peter Hirschfeld, Sebastian Schmidt, Thomas Tröllmich
• TBR beruht auf der einfachen Idee: "Einen R2D2 gibt es noch nicht, also bauen wir einen". Der TBR verfügt über Hindernisvermeidung mit IR-Reflektion und Sonarsensor, eine Kamera zur Rot- und Gründetektion, einen LiIon-Akku, modifizierte Servomotoren, ein Speakerboard mit Verstärker, einen beweglichen Deckel (Öffnen und 360°-Drehen mit Schleifkontakten!), LED-Zeilen zur Stimmungsanzeige - alles wie bei den anderen Robotern gesteuert durch das AKSEN-Board. Umgesetzt wurde eine behaviorbasierte Architektur mit esaklierenden Stimmungen und Original-Starwars-Sounds. Zusammen mit dem nächsten Roboter war er der Star bei der öffentlichen Präsentation.
• Projektdokumentation

Magic Cube Hacker

• Studenten: Felix Schwarz, Maik-Peter Jacob, Marcel Haase
• Ein Roboter, der selbständig einen verwürfelten Zauberwürfel (Rubik's Cube) erkennt und löst, hat drei Probleme: die Mechanik zum Kippen und Drehen, die Bildverarbeitung zum Erkennen der Lage der Würfelsegmente und nicht zuletzt die Suche im Lösungsraum oder wenigstens einen Lösungsalgorithmus. Nun diese Projektarbeit konnte alle Probleme lösen. Die Lösungszeit beträgt ca. 45 Min, die Zuverlässigkeit hängt etwas vom Umgebungslicht ab - aber es funktioniert.
• Projektdokumentation

Projektabschluss

• MagicCubeHacker und TBR in Hamburg (10MB)
• Vorrunde Horst vs. Killerzwerg (20MB)
  
• Vorrunde Marvin vs. Isy (10MB)
• Zwischenrunde Guenter vs. Hector (10MB)
• Halbfinale Guenther vs. Peter (10MB)

Der Leistungskurs Informatik (12. Klasse, 17 Schüler) führte am 25. und 26. Januar 2010 ein zweitägiges Projekt im KI-Labor durch.

Ablauf erster Tag:

• Begrüßung durch Prodekan Prof. Dr.-Ing. J. Heinsohn
• notwendige Konzepte in ANSI-C (A. Ripperger)
• AKSEN-Einführung (I. Boersch)

Ablauf zweiter Tag:

• Praktikum AKSEN
• Arbeit an den Aufgaben.pdf, Ziel 15 Punkte!

Beispiel:

• Aufgabe 6 (Lichtschalter) 7 Punkte + Aufgabe 14 (Helligkeitslauflicht) 8 Punkte oder
• Aufgabe 30 (Fernsteuerung) 17 Punkte
• Empfehlung zwei einfache Aufgaben

Eine Aufgabe ist gelöst und wird abgenommen, wenn:

• Funktion: funktioniert?, funktioniert immer?
• Einfachheit: überflüssiger Code?, geht es einfacher?
• Verständlichkeit: strukturiert?, kommentiert?

Ob die Punkte erreicht wurden, ist hier zu sehen.

Ein paar Fotos

Aufgabenstellung

Nun die Aufgabe klingt einfach: Gewinnen Sie den Wanderpokal zurück, den die FH Brandenburg vor einigen Jahren für den Fussball-Wettbewerb zwischen den KI-und-Robotikprojekten der FH Hannover, HAW Hamburg und FH Dormund gestiftet hat. Kann das klappen? -

5 Gründe für Zuversicht (was gibt es nur an der FHB):

• 4 Damen im Projekt
• Kompass-Sensoren, Li-Akkus (beides aber nicht eingesetzt)
• Kamera zur Ballerkennung mit hoher Reichweite
• neue Routine zur Torerkennung mit hoher Reichweite
• PEARLBOND 103 (inzwischen auch in Hamburg)

Teilnehmer

Ergebnis

Beobachtungen und Lehren

• nur ein Roboter benutzte einen Ballkäfig, Kicker wurden aus Spulen (+ 4 9V-Blocks), LEGO-Zahnstangen als Schusszunge oder Hebeschaufel realisiert, Dribbler wurden keine gesehe
• Hamburger nutzen durchgängig die qfix-Plattform mit neuen Getriebemotoren, allerdings wird gewechselt, da zuviel Verschleiß - Dortmund schlägt hier den Motor RB35 vor
• 12V-Motoren, die bei zu hoher Leistung die Motortreiber zerstören, können auch das AKSEN beschädigen
• die A4-Begrenzung führt zu Türmen - eine Gewichtsbegrenzung einführen?
• omnidirektionale Roboter verlangsamen auf ca. 1/3 auf Schlingen-Auslegeware
• aus Dortmund kam ein Balsaholz-Roboter (gute Idee) mit selbstentwickelter Platine für die Beaconerkennung
• IR-Empfänger SFH313 sehen den Ball auf ca. 70cm, Kalibrierung auf Umgebungslicht durch Drehen auf der Stelle, Parallelschaltung (verOdern) von IR-Sensoren
• Sensoren zur Ballbesitzkontrolle über dem Ball nach unten richten
• Distanzsensorik (ausser bei den Brandenburgern) ausschließlich Sharps mit Verstärker (3 bis maximal 4 Stück pro Roboter)
• Beacons aus Hamburg sind deutlich stärker als Originale, d.h. Reflektionen an Wänden, T-Shirts etc.
• fast fertige Plattformen bieten Wettbewerbsvorteil (gewollt?)
• HAW: gemischte Teams aus Angewandter und Technischer Informatik, Kooperation mit Technikern machbar?
• überwiegend reaktive Systeme, viele mit Multitasking
• Ballerkennung wichtiger als Hindernisvermeidung (hier genügt Zufallsfahren)

Dokumentationen

• Blackdeath mit Dribbler und Kamera, Film (7MB)
• Fotostrecke vom Wettbewerb

Aufgabenstellung

• Punkteliste
• Fotostrecke vom Wettbewerb

Im Projekt “Hasenjagd” im WS 07/08 erwies sich die Detektion des fremden Infrarotsignals (mit 100 bzw. 125 Hz moduliertes Infrarotlicht auf einem 39kHz-Träger) als schwierig, sobald der eigene IR-Sender eingeschaltet wurde. Dieser Beitrag beschreibt ein Detektionsverfahren, das schon in der einfachsten Version eine deutliche Verbesserung der Erkennungsleistung im Vergleich zur AKSEN-Bibliothek zeigte. Vielleicht auch interessant für Fussballspieler in Hamburg und Dortmund?

Das PDF beschreibt die Lösung und enthält einen Codeschnipsel, zur Simulation dient die Excel-Datei.

detektion-von-ir.pdf losungswege.xls 

Das Projekt
Die Stadtwerke Brandenburg schützen ihre Liegenschaften durch ein besonderes Konzept vor Graffiti - regionale Künstlergruppen versehen die Gebäude, Stromkästen, Trafostationen mit Kunstwerken. Die Initiative und Themen gehen dabei von den Stadtwerken aus, dennoch bleibt den Künstlern noch viel Raum zur Verwirklichung eigener Ideen.

Im Projekt mit dem Fachbereich Informatik und Medien der FHB ging es um die Verbindung von LEGO-Bausteinen, Technik und Informatik - das trifft so ziemlich genau das RobotBuildingLab,  welches seit 1996 im Labor für Künstliche Intelligenz des Fachbereichs angeboten wird. Ein besonders fortgeschrittener Roboter mit einem RCUBE-System wurde als Motiv gewählt und fotorealisitsch auf einer Trafostation in der Bauhofstraße "verewigt".

Der Roboter R2D0 ist ein Roboter, der über eine Kamera seine Ladestation sucht und sich so autonom mit Energie versorgt. Der Roboter kommt ohne jegliche Funkverbindung aus. Konstruiert wurde er von den Informatik-Absolventen Martin Ahlborg und Ronny Menzel.

Die Gestaltung und Ausführung wurde von der Brandenburger Gruppe um Guido Raddatz vorgenommen, weitere Arbeiten und Kontakt unter goldenehaende.de und pikfein.com.

• Hier die Aufnahmen

• Aufgabenstellung
• Abgestimmte Regel: Hindernisse sind stets höher als 25 cm
• Punkteliste
• Fotos vom Wettbewerb
• Roboterdokumentationen: FUZZY, POINK (src), Graby, Ghost Rider
• Film (~18 Minuten, 360x288, 43MB)

Gerd und Tim Kolberger beschreiben im folgenden PDF, wie die Motortreiber des AKSEN durch die RN-Mini H-Bridge ersetzt werden können, um Motoren größerer Leistung anzusteuern. Anwendung fand die Idee für einen omnidirektionalen Fussball-Roboter mit Faulhaber-Motoren für den Robocup Junior: aksenexternemotordriver.pdf 

Ein Artikel von Sascha Schneider beschreibt den Opfersensor, der mit einfachen Mitteln silberne und grüne geklebte Objekte vom Untergrund und der schwarzen Linie unterscheiden kann. opfer-oder-nicht-opfer.pdf 

Im Februar traten zwei von FHB-Studierenden konstruierte autonome Roboter fußballspielend im Turnier gegen ihre Konkurrenten aus der FH Hannover, HAW Hamburg und FH Dortmund an. Gastgeber war am 2. Februar 2007 die Fachhochschule Dortmund, nachdem der Wettbewerb 2006 in der Buchhandlung Lehmanns in Hamburg und 2005 im Labor für Künstliche Intelligenz der FH Brandenburg stattfand. Das Turnier ist eine kleine Tradition zwischen den Studierenden der (inzwischen) vier Fachhochschulen und schließt an der FHB das Projekt „Künstliche Intelli-genz“ von Prof. Heinsohn und I. Boersch für Studierende des siebenten Fachsemesters der Infor-matik im Sommersemester ab.

Alle fünfzehn entstandenen Roboter basieren auf dem im FBI entwickelten AKSEN-Board, das in den Laboren der beteiligten Fachhochschulen verwendet wird. Sie verfügen über Infrarot- und Sonarsensoren zur Wanderkennung, Sensoren für die Ortung von Ball und Tor, teilweise über Odometrie und Kompass und natürlich vielfältigste Antriebs- und Schußmechanismen (bspw. Maggie mit der Schußzunge). Doch erst ein Programm verbindet Sensorik und Aktorik zu einem intelligenten System, hierbei kommen Automaten und behaviorbasierte Ansätze zur Anwendung.

Trotz vieler guter Ideen konnten die Brandenburger Roboter dieses Jahr nicht die ganz großen Erfolge erringen und der Wanderpokal geht für ein Jahr an die Studierenden der FH Dortmund. Hier einige Fotos.

Die Brandenburger Roboter:

• Maggie von J. Walther, M. Koplin und C. Paschen (Beschreibung)
  
• Bart von J. Lanvers und C. Jager

Die AKSEN-Lib 0.970 behebt einen Fehler der Infrarotdetektion beim Multitasking und stellt auf SDCC Version 2.6.0 um. Wir empfehlen den Umstieg und haben die Bibliothek mit einer Migrationsanleitung für Windows (Dank an Christoph Paschen) auf http://ots.fh-brandenburg.de/aksen bereitgestellt.

Grundregeln

• G1: Was nicht verboten ist, ist erlaubt
• G2: Der Tisch bleibt unberühr
• G3: Es dürfen keine externen, absichtlich beigefügten Kräfte auf den Roboter einwirken (Wind etc.
• G4: Der gegnerische Roboter darf nicht (absichtlich) zerstört werde
• G5: Allgemeine Grundlage sind die RoboCup Junior 2004 SOCCER Regeln (http://www.robocup.org)

Spielregeln

• S1. Spieldauer: 2 x 90 Sek. mit Seitenwechsel
• S2: Es wird „1 gegen 1“ gespielt.
• S3: Es gibt 2 Halbzeiten mit je 90 Sekunden. Die Pause zwischen den Halbzeiten beträgt maximal eine Minute.
• S4: Falls nach 2×90 Sek. kein Sieger ermittelt wurde, wird 90 Sekunden um ein Golden Goal gespielt, wird auch hier keine Entscheidung gefunden, folgen abwechselnd 5 Elfmeterversuche von den 5 neutralen Punkten, dabei gilt ein Zeitlimit von 20 Sekunden pro Versuch. Dabei wird der Roboter jeweils vom Schiedsrichter an beliebiger Position auf der Mittellinie gestellt – jeweils ausgerichtet auf das gegnerische Tor. Gibt es auch nach dieser Elfmeterrunde keine Entscheidung, wird gelost.
• S5: Jedes Team hat vor dem Spiel, sowie in der Halbzeit, max. eine Minute Zeit, den Roboter zu initialisieren, dabei gibt der Schiedsrichter an, welcher Roboter auf welches Tor schießt. Bei Spielstart wird jeder Roboter von einem Teammitglied gestartet. Das Startsignal kommt vom Schiedsrichter.
• S6: Beim Start und nach jedem Tor wird der Ball durch den Schiedsrichter in die Mitte des Feldes, die Roboter durch je ein Teammitglied direkt vor das eigene Tor gestellt.
• S7: Während des Spiels darf nur der Schiedsrichter über die Spielfeldumrandung greifen, Ausnahme sind die Initialisierung, das Starten des Roboters am Anfang jeder Halbzeit und Neustart nach einem Tor. Greift ein Teammitglied trotzdem ein, hat die gegnerische Partei das Spiel automatisch gewonnen.
• S8: Bei einem Foul, Verhaken der beiden Roboter oder ähnlichem stellt der Schiedsrichter beide Roboter auf der Höhe der Verkeilung mit der Front zur Wand ( sie stehen also mit dem Rücken zueinander ). Der Ball wird genau zwischen die beiden Roboter platziert. Nun wird das Spiel fortgeführt.
• S9: Bei aktueller Langeweile darf der Schiedsrichter nach freiem Ermessen den Ball, einen oder beide Roboter auf den nächstgelegenen neutralen Punkt setzen.
• S10: Definition Tor: Der Ball muss die Rückwand der Toreinbuchtung berühren
• S11: Ist ein Roboter nicht mehr funktionsfähig, bleibt er auf dem Spielfeld stehen, bis die aktuelle Halbzeit vorüber ist.
• S12: Drohnen sind nicht erlaubt.

Irreführungen

• I1: Es dürfen keine absichtlich verlorenen Teile auf dem Tisch platziert werden
• I2: Das Signal des Balles darf nicht simuliert werden - da die Roboter aus Brandenburg als Abstandssensoren mit Infrarotsendern arbeiten, heisst das hier: zusätzliche Infrarotquellen müssen gepulst werden.
• I3: Die Torsignale dürfen nicht simuliert werden

Roboter und Spielfeld

• R1: Über jedem Tor befindet sich ein IR-Beacon (100 Hz bzw. 125 Hz unterschiedlich für die beiden Tore). Die IR-Beacon sind jeweils 25 cm über dem Tor angebracht.
• R2: Die Größe der Roboter im Urzustand ist auf die Fläche einer DIN-A4-Seite beschränkt, dieses gilt auch für die beweglichen Teile – wenn ein klappbarer Greifarm installiert ist, darf der Greifarm nach dem Ausfahren maximal 5cm über das DIN A4 Blatt herausragen.
• R3:Zur kontrollierten Ballführung sind zwei Mechanismen erlaubt: R3.1 oder R3.2
• R3.1: An der Front dürfen zwei Kabelbinder oder Legoleisten angebracht sein, um den Ball besser kontrollieren zu können, diese dürfen maximal 75% des Balldurchmessers lang sein. Der innere Abstand zwischen den Kabelbindern / Legoleisten darf sich nach vorne nicht verjüngen, es sind ein offener Winkel bzw. parallele Abstände erlaubt. Zusätzlich dürfen die Leisten seitlich gesehen nur so viel verdeckten, dass der Ball immer noch mindestens 50% frei sichtbar ist. Mit dieser Art von Ballführung ist eine Fahrt mit Ball erlaubt. Jede weitere Massnahme, den Ball festzuhalten (z.B. Tape), gilt als „Ballkäfig“.
• R3.2: Es darf an der Front ein Ballkäfig installiert werden, den der Roboter senken darf (und somit den Ball am Roboter sichert). Wird der Ballkäfig vom Ball entfernt, muss sich zunächst der Roboter etwa 10 cm (einen Handbreit) vom Ball entfernen, um somit dem gegnerischen Roboter die Möglichkeit zu geben, den Ball unter Kontrolle zu bringen, bevor auf das Tor geschossen wird. Wird der Ball zu lange kontrolliert, wird der Roboter ohne Ball vom Schiedsrichter willkürlich auf einen neutralen Punkt gesetzt. Der Ball bleibt am Platz liegen.
• R4: Sobald der Roboter den Ball im Ballkäfig hat, kann dieser sich mit dem Ball maximal für 3 Sekunden frei bewegen. Nach Ablauf der 3 Sekunden muss dieser sich vom Ball eine Handbreit entfernen und 1 Sekunden stehend warten, bevor zum Schuss angesetzt wird.

• 4. bis 8. September 2006
• Aufgabenstellung Teilautonome Fussballer,
• Punkteliste, Fotos

• Aufgabenstellung: Autonome Theseus-Roboter, siehe Aufgabenstellung
• Nach wenigen Wochen stellten sich die fünf Teams als hervorragende Roboterkonstrukteure heraus, so dass die Rahmenbedingungen etwas schwieriger gestaltet werden konnten (auch in der Wirklichkeit ändert sich oft das Pflichtenheft während der Implementierungsphase). Ins Zielgebiet des Testareals wurde eine Rampe eingefügt, die Schwierigkeiten bei zu tief sitzenden Linienfolgesensoren erzeugt. Kreative Lösungen waren hierzu Schubkarren, Sensoren auf Höhe der Radachsen und Neigungssensoren.
• Beim Wettstreit am Donnerstag, den 22. Juni 2006, zeigte sich, dass die Roboter die Aufgaben alle hervorragend lösen konnten. Dies ist erkennbar an den Punkten der Einzelwertungen und daran, dass der Minotaurus in neun von zehn Runden besiegt wurde.
• Durch den parallelen Start zweier Systeme setzten sich Unterschiede in Geschwindigkeit und Zuverlässigkeit durch. Erstmals in der zehnjährigen Geschichte unserer AMS-Wettbewerbe erreichte ein Roboter die theoretische Höchstpunktzahl von 5 x 29 = 145 Punkten - der Roboter Gabi. Es soll am Aufkleber gelegen haben.
  Hier die Ergebnisse.
• Einige Fotos

• Juni 2006: Die Chaos Designer vom Grasow Gymnasium starteten bei der Robocup Weltmeisterschaft in Bremen in der Disziplin RoboCupJunior Rescue Secondary mit einem selbstkonstruierten AKSEN-Roboter. Hier traten 38 Mannschaften aus aller Welt gegeneinander an: Deutschland (13), China (7), Slowakei (3), Portugal (3), Japan (3), Australien (2), Grossbritannien, Argentinien, USA, Taiwan, Norwegen, Iran, Irland. Gestartet wurde zur Anregung der Kommunikation in paarweiser Kooperation.
• Die Aufgabe: Liniefolgen (inklusive Ecken, Lücken und Rampen), Finden und Anzeigen von grünen und silbernen 'Opfern', Umfahren von Hindernissen und entgegenkommenden Robotern. Der Parcour in Bremen war entsprechend einer Weltweisterschaft sehr schwierig, aber lösbar. Preise wurden vergeben an ein Team aus Taiwan, zwei aus China, zwei aus Japan, zwei aus Deutschland und das irländische Team.
• Fotos der Schüler

• 27.2. bis 3.3.2006
• Teilnehmer: 15 Schüler der 11. Klassen des Bertolt-Brecht-Gymnasiums
• Ablauf der Woche
• Minimale Einführung in Sprache C (anhand von P. Baeumle-Courth)
• Aufgabenpool für AKSEN-Board
• Aufgabenstellung der Facharbeit
• Punkteliste

• Team 1 + 2: IR-Basisstation ud autonomer mobiler Sucher
• Team 3: Bergsteiger mit Hindernisdetektion
• Team 4: Hubschrauber mit Schalter
• Team 5 + 6 + 7: Laufmaschine mit Hindernisdetektor und -Räumer

AIS WS05/06 RoboCup (FH) die Zweite

• Vier Studenten der Studienrichtung "Intelligente Systeme" fuhren am Freitag, den 10. Februar 2006 nach Hamburg und nahmen dort mit ihren Robotern an einem Wettkampf für Fussballroboter teil. Anstoss war um 18 Uhr in der Lehmanns Fachbuchhandlung (Kurze Muehren 6 / Naehe Hauptbahnhof).
• Katja Orlwoski, Regina Wehren, Maurice Hüllein und Benjamin Hoepner konstruierten und programmierten ihre autonomen Robotersysteme im Projekt und in der LV "Applikation intelligenter Systeme" im Modul IS3. Der Wettstreit findet zum zweiten Mal zwischen der Fachhochschule Dortmund, der Hochschule für Angewandte Wissenschaften Hamburg und der Fachhochschule Brandenburg statt.
• Teilnehmer: 6 Roboter aus Hamburg, 4 Roboter aus Dortmund und 2 Roboter aus Brandenburg

• YellowPanther2
• Calculion

Die Hamburger Roboter

• Projekt Integration Kognitiver Systeme

Lehren aus dem Wettbewerb

• Leichte Roboter leicht im Vorteil
• Präziser Schuss wichtig (Elfmeter)
• Zuviel Kraft zerstört bei Blockade das Getriebe
• Dortmunder Riemenantrieb bewährt
• Ballkäfig hat Vorteile gegen schwache Roboter, aber Nachteile gegenüber anderen
• Lowcost-Infrarot-Lösung (FHB) für Abstandsmessung ausreichend
• Nur reaktive Roboter am Start
• Beste Frauenquote in Brandenburg
• Buchhandlung als Wettbewerbsort sehr geeignet

• 5. bis 9. September 2005
• Aufgabenstellung Das Kvaerner-Verfahren
• Punkteliste
• Fotos

• Aufgabenstellung: Autonome Fussballroboter, siehe Regelwerk zum RoboCupFH
• Ergebnisse vom internen Wettbewerb am 23. Juni 2005
• Ergebnisse vom nationalen Finale am 9. Juli 2005
  
• Fotos
• Projektberichte
  
  • Böse Giraffe (Hüllein, Höpner)
  • Yellow Panther (Wehren, Orlowski)
  • Jaqueline (Peschmann, Gorzelitz)
  • JaMeCa (Rube, Kuhle, Beyer)


• Projektpartner an der HAW Hamburg und FH Dortmund (Fotos, Videos, Projektberichte)
  

• Vorbereitung
• Böse Giraffe (FHB) - Cylon Warrior (HAW) 3:0
  Erste. und zweite Halbzeit
  
• RoboX (FHD) - Darth (HAW) 0:5
  Erste und zweite Halbzeit
  
• Yellow Panther (FHB) - Yoberd (HAW) 1:0
  Erste und zweite Halbzeit (mit Koggenfahrt)
  
• Böse Giraffe (FHB) - Hansebot (HAW) 2:0
  Erste und zweite Halbzeit
  
• Darth (HAW) - Yoberd (HAW) 1:0
  Spiel
• Böse Giraffe (FHB) - RoboX (FHD) 3:0
  Erste und zweite Halbzeit
  
• JaMeCa (FHB) - Cylon Warrior (HAW) 0:3
  Erste und zweite Halbzeit
  
• Yellow Panther (FHB) - RoboX (FHD) 1:0
  Erste und zweite Halbzeit
  

• Yellow Panther (FHB) - Cylon Warrior (HAW) 2:3 nach Elfmeterschießen
  Erste und zweite Halbzeit, Elfmeter
  
• Böse Giraffe (FHB) - Darth (HAW) 1:2
  Erste und zweite Halbzeit
  

• Cylon Warrior (HAW) - Darth (HAW) 2:0
  Erste, Erwärmung und zweite Halbzeit
  

Das CompactFlash - Speichermodul (kurz CF-Modul) ist Teil des RCUBE Systems. Es bietet die Möglichkeit, im autonomen Betrieb größere Datenmengen auf einem FAT16-Dateisystem der CompactFlash-Karte zu speichern bzw. zu lesen. Damit können Sensor-, Lern- oder andere Daten über einen Stromausfall hinweg erhalten werden. Die Daten der CF-Karte lassen sich in einem üblichen Kartenlesegerät in den PC einlesen.

Die Verbindung mit den anderen Boards erfolgt über den CAN-Bus. Andere Boards des Systems können so über CAN-Pakete Daten lesen oder schreiben.

Nutzerhandbuch CF-Modul

Maschinelles Lernen am Laufroboter ELFE - KI-Projekt WS 2004/2005

Zusammenfassung

Projektziel

Ergebnisse

• 6. bis 10. September 2004
• Aufgabenstellung Teilautonome Fussballer,
• Plakat, Punkteliste,
• Fotos

Aufgabe

Energieversorgung mobiler Systeme

Projektplan

Verlauf

Projektschein

Das KI-Projekt wird gesponsort von Farnell Deutschland

Wesentliche Erkenntnisse des Projektes

• Es ist möglich, energieautonome Roboter mit 6.270-Boards + Legotechnik umzusetzen.
• Behaviorbasierte Architekur (Subsumption/Brooks) gut geeignet
• Behaviors müssen mit einer Erwartungshaltung observiert werden (Zeitlimit, Streßlevel o.ä.)
• Behaviors der Selbstbeobachtung müssen zufällige Entscheidungen treffen, um dead locks zu vermeiden
• Lichtabhängigkeit der Systeme (insbesondere beim Hindernisvermeiden) durch IR-Differenzmessung vermeidbar
• Ladeschaltung zum Aufladen von Robotern mit 6.270-Boards wurde entwickelt
• Fotos aus dem Projekt
• Eine Bewertung von Akkutypen bezüglich der Eignung für Autonome Mobile Systeme finden Sie im Poster zu Akkumulator-Arten (Schülerpraktikum Mathias Menge)
  

Links

• SlugBot - Ein Roboter sammelt Schnecken zur Energiegewinnung (IAS-Labor der University of the West of England)
• Gastrobots - Roboter, die Ihre Energie aus natürlichen Materialien, z.B. aus Zuckerwürfeln, beziehen (University of South Florida)