HS-KL RoboCup 2021

RoboCup 2014, Joao Pessoa, Brasilien. Quelle: Uni Bonn

HS KL geht zur RoboCup German Open 2021!

Der RoboCup soll die Robotik und KI Forschung fördern und das vor einem öffentlichen Publikum. Ein Fußball spielender Roboter mag  wie eine eher wissenschaftliche Herausforderung aussehen, aber man muss dabei eine Fülle von Standard Problemen – wie man sie aus der heutigen Industrie kennt – lösen, und ist damit ein guter Einstieg in die Welt der KI.

Der AK Smart Machines ruft alle interessierten Studierenden, Professoren, und interessierte Unternehmen auf, in unser Team einzusteigen, und es gemeinsam bis bin die Qualifikation für den RoboCup 2021 zu schaffen!

Unser Kooperationspartner abat+ unterstützt uns bei Projekt- und Bachelor-Arbeiten in den Feldern robuste Bildverarbeitung, innovative Roboter Programmierung und Prozessoptimierung in der diskreten Fertigung, um neue Geschäftsfelder für die Industrie 4.0 zu erschließen.

Was ist die RoboCup Standard Platform League?

Der Robot Soccer World Cup ist die Fußball WM für Roboter. Der erste Wettkampf wurde 1997 bestritten und heute werden neben Fußball auch viele andere Wettkampf Arten ausgefochten, wie z. Bsp. auch die RoboCup Rescue League, bei dem die Roboter auf eine Rettungsmission entsandt werden.

Beim RoboCup lassen verschiedene Teams aus aller Welt ihr 5 Roboter in 2 Mannschaften gegeneinander wetteifern und dabei um den Fußball kämpfen, den Gegner austricksen und Tore schießen.  Die Standard Platform League (SPL) verwendet ausschließlich den gleichen Roboter, den NAO v6.

Die kleinen Roboter müssen sich vollständig autonom über das Spielfeld bewegen und dürfen nur wenig miteinander kommunizieren, um dennoch eine Team Strategie zu entwickeln, die zum Sieg führt. Dabei sollen sie trotz allem unabhängig voneinander agieren können.

Arbeiten mit dem NAO



Arbeitsumgebung

Der kleine humanoide Roboter NAO ist unser Spieler auf dem Spielfeld und wir sind sein Trainer.
Bei uns wird er sowohl mit C++ als auch mit Python programmiert. Dabei wird Python bei der Bilderkennung, wie zur Erkennung des Balls und des Tors, verwendet und C++ für den ganzen Rest. Darunter fällt zum Beispiel seine Bewegung über den Fussballrasen.

Voraussetzung hierfür ist die im Projekt bereits mitgelieferte IDE CodeLite und das Betriebssystem Ubuntu 18.04 LTS.

Außerdem gibt es auch einen Simulator. Dann muss man nicht immer vor Ort sein um seinen Code zu testen. Der Simulator ‘SimRobot’ ist sogar von einem mehrfachen Siegerteam des RoboCup (B-Human, Uni Bremen und DFKI) entworfen.


Beispiel Code

Wie gut müsst ihr programmieren können? Beantwortet es euch selbst.

Unten seht ihr ein paar Code Beispiele. Wenn ihr in der Lage seid, nachzuvollziehen was dort passiert, dann seid ihr bestens vorbereitet.

Sollte der NAO umfallen muss er laut Regelwerk selbst in der Lage sein wieder auf zu stehen. Der folgende Code erreicht das.

void FallEngine::safeFall(FallEngineOutput& output) const { // set stiffness of each joint for(int i = 0; i < Joints::numOfJoints; i++) output.stiffnessData.stiffnesses[i] = 10; // falling backwards ? sit up. if(output.fallingBackwards) { MotionUtilities::sit(output); } // falling forward ? stand up. else if(output.fallingForward) { MotionUtilities::stand(output); } } Weiterlesen

TurtleBot 2

Der TurtleBot 2

Beschreibung und Eigenschaften

 






















TurtleBot 2 ist ein mobiles Roboterkit mit Open-Source-Software, der mit einer Blackboard Architektur namens ROS (Robot Operating System) gesteuert wird. Durch diese Architektur können verschiedene Programmiersprachen im selben Projekt genutzt werden. Diese sind vorwiegend Python und C++. Durch seinen flexiblen Baustil können ebenso diverse Komponenten ergänzt werden, damit auch mehr Funktionalitäten hinzugefügt werden können.

Im Rahmen eines Projektes wurde er von Studenten liebevoll zu Botty McTurtleFace getauft oder kurz Botty.

Videos

Botty fährt vorwärts und umgeht ein Objekt.

 

Botty fährt ein Viereck.

 

 

Ausstattung

Im Auslieferungszustand besaß der Turtlebot 2 mehrere Hardware Komponenten, um seine Umgebung wahrzunehmen und mit ihr interagieren zu können. Alle sind mit einem NUC PC mit Ubuntu 16.04 verbunden, der sich direkt als Onboard PC auf dem TurtleBot 2 befindet. Folgende Komponenten besitzt er:

  • Greifarm PhantomX Reactor
    Der PhantomX Reactor Arm ist ein ROS-kompatibler Greifarm. Der Greifarm wird über einen Arbotix-M gesteuert, welches ein modifiziertes Arduino-Board zur Ansteuerung von Servo-Motoren ist. Auf dem NUC des TurtleBot kann eine ROS Anwendung gestartet werden, welche Positionierungsbefehle für den Greifarm annimmt und diese Befehle dann an das Arduino-Board weiterleitet. Hierfür befindet sich ein Arduino-Image auf dem Arbotix-M, welches die ROS-Befehle interpretiert und entsprechend die Servo-Motoren ansteuert. 
  • Lidar Hokuyo URG-04LX-UG01
    Es handelt sich hierbei um einen Laserscanner zur Berechnung von Distanzen auf einer horizontalen Ebene. Der Wahrnehmungswinkel beträgt 240° und die Wahrnehmungsreichweite ist bis zu ca. 4 Meter.
  • 3D-Kamera Orbbec Astra
    Die Orbbec ist eine 3D-Kamera mit einem Sichtfeld von 60° horizontal und 49,5° vertikal. Dazu hat sie eine Reichweite von bis zu 8 meter.
  • Kobuki-Base
    Die Kobuki-Base macht den TurtleBot 2 mobil und beinhaltet die benötigte Lithium-Ionen Batterie. Daneben stellt die Basis auch Tasten, LEDs und Bumpers, zur Kollisionserkennung, zur Verfügung.

Allerdings erlaubt seine besondere Baustruktur durch Halterungen und Platten mehrere Etagen über der Kobuki-Base zu stapeln, um auf diese Weise mehr Platz für weitere Komponenten hinzuzufügen. Daher wurden zu den ursprünglichen Komponenten noch ein Mikro für Spracherkennung und Sprachausgabe hinzugefügt. Ebenso wurde die 3D-Kamera ummontiert und an der Unterseite einer der Platten angebracht, damit sie ein besseres Sichtfeld hat.

Arbeiten mit Turtlebot 2
Programmierung

Die Programmierung ist einfacher als man denkt. Wie bereits erwähnt unterstützt ROS sowohl Python, wie auch C++. Im folgenden wird ein Python Beispiel betrachtet, mit dem der TurtleBot 2 ein Viereck fahren soll. Ein Video davon ist weiter oben zu finden.

def drive(meter): # starte den Motor Service, um mit ihm kommunizieren zu können rospy.wait_for_service('motor') job = rospy.ServiceProxy('motor', call) # Die Nachricht ist in diesem Fall ein Objekt "call" # erzeuge die Nachricht param=[] param.append(meter) command=call() command.call="forwardByMeters" # die vom Motor erwünschte Aktion command.param=param # die zurück zu legende Distanz #sende die Nachricht response=job(command.call,command.param) # Übermittelung der Nachricht return response # Ausgabe der zurück erhaltenen Antwort def turn(angle): # starte den Motor Service, um mit ihm kommunizieren zu können rospy.wait_for_service('motor') job = rospy.ServiceProxy('motor', call) # Die Nachricht ist in diesem Fall ein Objekt "call" # erzeuge die Nachricht param=[] param.append(angle) command=call() command.call="turnRigthByAngle" # die vom Motor erwünschte Aktion command.param=param # die zurück zu legende Distanz in Gradzahl #sende die Nachricht response=job(command.call,command.param) # Übermittelung der Nachricht return response # Ausgabe der zurück erhaltenen Antwort if __name__ == "__main__": for x in range (0,4): print("Going Forward to "+str(drive(1.0))) sleep(0.1) print("Turning around to: "+str(turn(90))) sleep(0.1) Weiterlesen

Nao V6

Nao V6

Kurzdarstellung

Der Nao ist ein autonomer, humanoider Roboter entwickelt von dem französischen Unternehmen Aldebaran Robotics. Er besitzt eine Vielzahl an Sensoren, Motoren und Kameras, sowie eine Spracherkennung und -ausgabe. Seit 2008 wurden mehrere Versionen des Nao veröffentlicht . Die aktuellste Version, der Nao V6, ist 2018 erschienen.

Ausleihen

Der Arbeitskreis Smart Machines besitzt zwei Nao V6 in grau. Beide können ausgeliehen werden. Weitere Infos findest du hier.

Quick Guide

Zur leichteren Einarbeitung in den Nao bieten wir einen Quick Guide an. Darin ist u.A. beschrieben, wie man den Nao in Betrieb nimmt und wie man ihn mit Apps steuern kann.

Den Quick Guide als PDF findest du hier.

More to come!

Diese Seite befindet sich derzeit noch im Aufbau. Eine Ausführlichere Beschreibung über den Nao und dessen Funktionen wird noch folgen.

Crazyflie 2.0

Quelle: https://www.bitcraze.io/2014/07/crazyflie-2-0-photos-and-video/

Crazyflie 2.0

 

 

Features, Equipment, Summary

The Crazyflie 2.0 is an open-source quadcopter with 2 micro controllers developed by Bitcraze: The NRF51 Cortex-M0 Chip handles radio communication and power management. The STM32F405 Cortex-M4@160MHz Chip manages flight control, sensor and telemetry data, motor control as well as additional user development. Crazyflie 2.0 supports Bluetooth LE as well as 2.4GHz 20dBm radio control.

 

Hardware specifications

In this paragraph you will find a list of the Crazyflie’s hardware specifications.
These specifications match the developer’s data, a full list can be found here.

  • Mechanical specification
    • Weight: 27g
    • Size (WxHxD): 92x92x29mm (motor-to-motor and including motor mount feet)

    Radio specification:

    • 20 dBm radio amplifier tested to > 1 km range LOS with Crazyradio PA
    • Bluetooth Low Energy support with iOS and Android clients available (tested on iOS 7.1+ and Android 4.4+)
    • Radio backwards compatible with original Crazyflie and Crazyradio

    Micro-controllers:

    • STM32F405 main application MCU (Cortex-M4, 168MHz, 192kb SRAM, 1Mb flash)
    • nRF51822 radio and power management MCU (Cortex-M0, 32Mhz, 16kb SRAM, 128kb flash)

    IMU

    • 3 axis gyro (MPU-9250)
    • 3 axis accelerometer (MPU-9250)
    • 3 axis magnetometer (MPU-9250)
    • High precision pressure sensor (LPS25H)

    Flight specification

    • Flight time with stock battery: 7 minutes
    • Charging time with stock battery: 40 minutes
    • Max recommended payload weight: 15 g

    Basic functionality and features Weiterlesen

Hackathon im September: Ergebnisse der Umfrage

Vielen Dank an alle Teilnehmer/-innen der Umfrage zum Beitrag des Arbeitskreises für den ersten Hackathon im Fachbereich I/MST am Standort Zweibrücken. Wie im Vorfeld bereits angekündigt möchte der Arbeitskreis die Umfrage-Ergebnisse veröffentlichen, um einen Einblick in mögliche Themenbeiträge für den Hackathon zu ermöglichen.

Die Mehrheit der Teilnehmer stimmte für die Programmierung eines Open-Source Quadcopters, gefolgt von der Programmierung eines Roboterarms. Den dritten Platz belegten der Alphabot, sowie ein humanoider Roboter mit der gleichen Anzahl an Stimmen. Im Folgenden eine Visualisierung des Ergebnisses. Zu beachten gilt hierbei dass eine Mehrfachauswahl möglich war.

 

Regelwerk für den fortgeschrittenen Parcours

Regelwerk für den Maze Parcours

Regelwerk für den Maze Parcours (PDF Download)

 

Kurzbeschreibung

Ein autonom fahrender Roboter soll in möglichst kurzer Zeit einen Weg durch einen Labyrinth-Parcours finden.

 

Allgemeine Vorgaben

  • Die Teams dürfen dem Roboter kein Vorwissen über das Spielfeld vermitteln. Der Roboter soll das Spielfeld eigenständig erkennen.
  • Sollte der Roboter an einer Stelle feststecken, kann er beim zuletzt erreichten Checkpoint abgesetzt werden (siehe dazu den Abschnitt ‚Die Challenge‘ – ‚Nicht Vorankommen‘). Sollte der Roboter dreimal zwischen den zwei gleichen Checkpoints feststecken, darf er zum nächsten Checkpoint gesetzt werden, erhält dafür aber eine Zeitstrafe.
  • Die Bewertung des Wettbewerbs ist im Abschnitt ‚Die Challenge‘ – ‚Wertung‘ zu finden.

 

Spielfeld

Beschreibung
  • Die Spielfeldfläche besteht aus einem horizontal ausgerichteten Bodenbelag. Die Fläche des Spielfelds beträgt 150 x 150 cm (5 x 5 Kacheln mit jeweils einer Fläche von 30 x 30 cm). Sie ist an allen vier Seiten von Banden eingefasst. Die Bandenhöhe beträgt mindestens 15 Das Labyrinth wird durch Trennwände erzeugt. Die Höhe der Trennwände beträgt ebenfalls mindestens 15 cm. Eine Längeneinheit beträgt 15 cm. Das bedeutet die Trennwände haben stets die Länge von 15 cm oder eines vielfachen von 15. Die Fahrgasse für die Roboter ist mindestens 30 cm breit.
  • Fakten auf einen Blick:
    • Spielfeldfläche: 150 x 150 cm
    • Banden- und Trennwandhöhe: mind. 15 cm
    • Breite der Fahrgasse: 30 cm
    • 1 Längeneinheit: 15 cm

    Exemplarische Skizze des Parcours:

    Boden

    Der Boden ist von weißer oder fast weißer Farbe. Der Boden kann glatt oder strukturiert sein (z.B. Linoleum- oder Teppichbelag). Der Boden darf Stufen von bis zu 3 mm Höhe an den Übergängen zwischen Kacheln haben. Durch die Kacheln kann es zu Stufen und / oder Lücken bei der Konstruktion des Spielfelds kommen. Diese sind nicht erwünscht und werden von den Organisatoren so klein wie möglich gehalten.

    Fahrgasse

    Die Fahrgasse wird durch Trennwände erzeugt und führt von der Startpunktkennzeichnung zur Endpunktkennzeichnung. Der Lauf startet und endet nicht an demselben Punkt (kein Rundkurs). Die Fahrgassenbreite beträgt 30 cm. Der Organisator behält sich vor Trennwände vor einem Lauf hinzuzufügen, umzustellen oder zu entfernen, um ein pre-mapping des Parcours zu verhindern.

    Umweltbedingungen
    • Die Umweltbedingungen bei einem Wettbewerb werden wahrscheinlich anders sein als an ihrer heimischen Trainingsarena. Die Teams müssen darauf vorbereitet sein, ihre Roboter an die Bedingungen vor Ort anzupassen.
    • Die Arena könnte im Einflussbereich magnetischer Felder liegen (z.B. durch im Boden verlegte Kabel oder metallische Objekte). Die Teams sollen ihre Roboter darauf auslegen, mit solchen Störungen umzugehen. Organisatoren und Juroren werden diese magnetischen Störungen bestmöglich minimieren.
    • Die Arena könnte unerwartet durch Beleuchtung beeinflusst werden (z.B. durch Kamerablitze der Zuschauer). Die Teams sollen ihre Roboter darauf auslegen, mit solchen Störungen umzugehen. Organisatoren und Juroren werden diese Lichtstörungen bestmöglich minimieren.
    • Alle Maße in den Regeln haben eine Toleranz von ±5%

     

    Roboter

    Steuerung
    • Die Roboter müssen autonom gesteuert sein. Die Verwendung von Fernsteuerungen, Steuerung von Hand sowie die Übermittlung von Informationen (mittels Sensoren manuell eingespielte, Kabeln, kabellos etc.) an den Roboter ist nicht gestattet.
    • Die Roboter müssen manuell durch den Teamkapitän gestartet werden.
    • Kartenbasierte Koppelnavigation (die vor dem Start vordefinierte Steuerung von Bewegungen aufgrund von Wissen über die Arena oder die Position von Objekten in dieser) ist verboten
    • Roboter dürfen keinen Teil der Arena in irgendeiner Weise beschädigen.
    Bauweise
    • Jede Art Roboterbausatz oder -bausteine, ob käuflich erworben oder aus Einzelkomponenten selbst gebaut, darf verwendet werden, sofern die Programmierung des Roboters hauptsächlich und im Wesentlichen das originäre Werk der Teilnehmer ist.
      • EV3: Ausschließliche Verwendung der Sensoren des Education-Bausatzes.  Außerdem maximal Einsatz von zwei Farbsensoren.

      Zweifel müssen durch die Teams vor dem Wettbewerb mit der Wettkampfleitung geklärt werden.
      Zur Sicherheit der Teilnehmer und Zuschauer sind ausschließlich Laser der Klassen 1 und 2 an Robotern erlaubt. Das wird bei der Inspektion überprüft werden. Teams die Laser verwenden, müssen die technischen Daten / Spezifikation der Sensoren vorzeigen können.
      Bluetooth Klasse 2, 3 und ZigBee Kommunikationsmodule sind die einzigen Formen der drahtlosen Kommunikation, die beim RoboCup erlaubt sind, um z.B. Kalibrierungen etc. vorzunehmen. Die Fernsteuerung von Bots, über die genannten oder ähnliche Schnittstellen, ist generell untersagt (dies wird vor dem Wettkampflauf durch die Juroren überprüft). Bei Robotern, die über andere Formen der drahtlosen Kommunikation verfügen, müssen diese entfernt oder außer Funktion gesetzt werden. Falls der Roboter über andere Möglichkeiten drahtloser Kommunikation verfügt, muss das Team nachweisen, dass diese außer Funktion gesetzt sind. Roboter, die dem nicht entsprechen, können mit sofortiger Wirkung für den gesamten Wettkampf disqualifiziert werden.

      • Roboter können beschädigt werden, wenn sie vom Feld herunterfallen, einen anderen Roboter touchieren oder mit Objekten des Spielfeldes kollidieren. Die Wettbewerbsveranstalter können nicht alle Situationen vorhersehen, in denen ein Roboter zu Schaden kommen könnte. Die Teams sollen Sorge tragen, dass alle aktiven Komponenten eines Roboters durch widerstandsfähige Materialien angemessen geschützt sind. Zum Beispiel müssen elektrische Schaltungen vor allen Berührungen durch Menschen und vor Kontakt mit anderen Robotern oder Objekten des Spielfeldes geschützt sein.
      • Wenn Batterien transportiert oder bewegt werden, ist es empfohlen, Schutzhüllen zu verwenden. Es soll durch angemessene Maßnahmen vermieden werden, dass Roboter Kurzschlüsse haben oder dass es zu Lecks kommt, aus denen Chemikalien oder Gase austreten können.

       

      Teams

      • Gewünscht ist, dass die B.O.T. Challenge Teilnehmer im Team antreten, Einzelanmeldungen sind jedoch auch möglich.
      • Jedes Team darf nur einen Roboter im Spiel haben.
      • Teams bestehen aus 2 bis 5 Mitgliedern.
      • Jedes Teammitglied muss seine eigene Arbeit erklären und soll eine bestimmte technische Rolle ausüben.
      • Teilnehmer dürfen nur in einem Team registriert sein.
      • Mentoren / Eltern dürfen bei den Wettkämpfen nicht bei den Teilnehmern sein. Die Teilnehmer müssen sich während der langen Stunden des Wettkampfes selbst organisieren (ohne Aufsicht oder Hilfe eines Mentors).

       

      Die Challenge

      Training

      Wenn möglich, erhalten die Teams im Verlauf des Wettbewerbs Zugang zu Trainings- bzw. Kalibrierungs- und Testparcours. Es bleibt den Organisatoren vorbehalten Trainingseinheiten auch auf Wettbewerbsparcours zuzulassen.

      Menschliches eingreifen

      Die Teams bestimmen ein Mitglied als Teamkapitän und ein weiteres als dessen Vertreter. Einzig diesen beiden Teammitgliedern ist es erlaubt während des Laufs an den Wettbewerbsparcours zu treten, soweit vom Juror nichts anderes bestimmt wird. Nur dem Teamkapitän ist es erlaubt während eines gewerteten Laufs auf den Roboter Einfluss zu nehmen. Der Kapitän darf den Roboter nur nach Aufforderung des Jurors berühren. Andere Teammitglieder und Zuschauer müssen mindestens 150 cm vom Wettbewerbsparcours entfernt sein. Niemand darf während eines gewerteten Laufs den Wettbewerbsparcours absichtlich berühren.

      Beginn des Spiels
      • Ein Lauf beginnt zur angesetzten Startzeit, egal ob die Teams anwesend bzw. startbereit sind oder nicht. Startzeiten werden im Rahmen der Veranstaltung deutlich sichtbar angezeigt.
      • Checkpoint-Marker dienen als Kennzeichnung für absolvierte Abschnitte. Es dürfen maximal drei Checkpoint-Marker auf dem Kurs verteilt werden. Der Abstand zwischen zwei Markern bzw. dem Startpunkt und dem nächsten Marker darf max. drei Längeneinheiten (45 cm) betragen und nicht mehr als eine Ecke überbrücken. Gemessen wird dieser Abstand entlang der rechten Wand in Fahrtrichtung. Der Startpunkt ist ein implizierter Checkpoint-Marker und darf nicht belegt werden. Die Marker können aus Holz oder Plastikmaterial hergestellt sein. Sie sind 5 mm bis 12 mm dick und haben einen Durchmesser von bis zu 70 mm. Nach Startschuss des Wertungslaufs darf der Teamkapitän die Checkpoint-Marker auf dem Kurs verteilen.
      • Ein Wertungslauf beginnt mit einem Signal des Jurors. Sobald der Lauf gestartet ist, ist es dem Roboter nicht erlaubt den Wettbewerbsparcours zu verlassen. Jeder Lauf dauert max. 8 Minuten. Sowohl die Kalibrierung von Sensoren als auch das Setzen der Checkpoint-Marker erfolgt nach dem Startsignal und sind Teil der Zeitwertung.
      • Kalibrierung ist definiert als das Einlesen von Sensorwerten und die Modifizierung der Programmierung des Roboters, um die eingelesenen Sensorwerte zu berücksichtigen. Jedwede Form der vorherigen Kartierung führt zur sofortigen Disqualifikation und zum Ausschluss des Roboters in dieser Runde. Kalibrierung welche ein pre-mapping des Wettbewerbsparcours einschließt ist untersagt. Pre-mapping Aktivitäten werden mit dem sofortigen Ausschluss des Roboters aus dem Wettbewerb sanktioniert. Dem Juror ist es vorbehalten Wände auf dem Spielfeld zu verändern bevor ein Wertungslauf startet. Nach dem Start eines Wertungslaufs ist eine nachträgliche Kalibrierung nicht gestattet.
      Spielmechanik

      Die Modifikation eines Roboters während eines Wertungslaufs ist untersagt. Dies gilt auch für Bauteile die während des Laufs abgefallen sind. Bauteile die während eines Wertungslaufs abgefallen sind verbleiben auf dem Wettbewerbsparcours, bis der Lauf beendet wurde. Dem Roboter dürfen keine zusätzlichen Informationen über den Parcoursaufbau extern zugeführt werden. Der Roboter muss den Aufbau des Parcours selbstständig erkennen.

      Wertung
      • Ziel des Wettbewerbs ist es, dass der Roboter möglichst schnell einen Labyrinth Parcours autonom von einem gekennzeichneten Startpunkt bis zum einem gekennzeichneten Endpunkt durchfährt. Gelangt der Roboter innerhalb des vorgegebenen Zeitrahmens (8 Minuten) zum Endpunkt, so wird die bis dahin benötigte Zeit gewertet. Erhält der Roboter während eines Laufs Zeitstrafen (siehe Lack of Progress), so werden diese zu der Fahrzeit hinzuaddiert. Kann ein Roboter den Parcours nicht innerhalb der 8 Minutenfrist absolvieren, so wird die bis dahin erreichte Stelle im Parcours gekennzeichnet. Bis dahin angefallene Zeitstrafen werden zu den 8 Minuten hinzuaddiert.
      • Für Roboter die den Endpunkt des Parcours nicht erreicht haben, erfolgt die nachfolgende Berechnung, um diese in die Gesamtwertung aufnehmen zu können:
        • Ausgehend vom vordersten Teil des Roboters (wird durch den Juror definiert), wird die Entfernung zum Endpunkt gemessen. Die Messung erfolgt immer entlang der rechten Wand in Fahrtrichtung. Die gemessene Strecke wird in Zeit umgerechnet. Je begonnenem Zentimeter eine Sekunde. Die errechneten Sekunden werden zu der max. Fahrzeit und den bisher angefallenen Zeitstrafen hinzuaddiert.
        Nicht-Vorankommen („Lack of Progress“ – LoP)
        • Ein Lack of Progress liegt vor, wenn:
          • der Teamkapitän einen Lack of Progress beim Juror anmeldet
          • der Roboter an einer Bande oder Wand feststeckt und das Problem nicht selbstständig nach 8 Sekunden beheben kann

          Tritt ein Lack of Progress ein, wird der Roboter an den Start des Parcours oder am letzten passierten Checkpoint zurückgesetzt. Nur der Teamkapitän darf den Roboter aufnehmen und an einem dieser Punkte wieder absetzen. Steckt ein Roboter dreimal zwischen zwei Checkpoint-Markern oder dem Start und dem nächsten Checkpoint-Marker fest, so kann der Roboter an dem nächsten Checkpoint-Marker aufgestellt werden, erhält dafür aber eine Zeitstrafe von 15 Sekunden. Die Endpunktkennzeichnung ist kein Checkpoint-Marker und darf auch nicht als solcher markiert werden. Auf den letzten beiden Geraden vor der Endpunktkennzeichnung darf auch kein Checkpoint-Marker gesetzt werden.

          Spielende

          Die Teams dürfen jederzeit entscheiden einen Wertungslauf vorzeitig zu beenden, der gekennzeichnete Endpunkt erreicht wurde oder die Zeit abgelaufen ist. Sollte der Lauf durch das Team vorzeitig beendet werden, gehen die maximale Fahrzeit (8 Minuten) inklusive der bis dahin angefallenen Zeitstrafen und die Berechnung des Abstands zum Endpunkt in die Wertung ein.

           

          Konfliktlösung

          Juroren
          • Pro Parcours sind jeweils zwei Juroren zuständig
          • Alle Entscheidungen während eines Spiels werden durch die Juroren getroffen, die für die Arena und Personen und Gegenstände um die Arena herum verantwortlich sind.
          • Während des Spiels sind die Entscheidungen der Juroren endgültig.

           

          Die oberen Bilder sind lizenziert unter einer

          Creative Commons Namensnennung – Weitergabe unter gleichen Bedingungen 4.0 International Lizenz Weiterlesen

Robocup Kacheln

7 RoboCup Parcours-Kacheln aus Aluverbund weiß ca. 300 x 300 x 3 mm.

 

Die Kacheln kommen im Projekt „Agile Software Entwicklung – Line Follower RoboCup“ zum Einsatz und dienen dazu, den Parcours für den Line Follower zu errichten. Die Verwendung der Kacheln hat den Vorteil, dass der Parcours transportabel ist und modular gestaltet werden kann.  Die Kacheln dienen zu Lern- und Trainingszwecken und können anschließend auch bei der eigentlichen Veranstaltung verwendet werden. 

Durch den Einsatz der Kacheln soll den Studierenden die Möglichkeit geboten werden Grundlagen der Steuerungs- und Regelungstechnik (Zustandsautomaten, PID-Controller) im praxisnahen Einsatz zu erlernen und Optimierungspotentiale am Programmcode direkt zu erproben. 

Studierende lernen selbstständig Sensorzustände auszuwerten, zu verknüpfen, die Ergebnisse zu interpretieren und automatisiert geeignete Maßnahmen (Ansteuerung von Aktoren) auszulösen. Mit Unterstützung der Kacheln können die Lernergebnisse direkt praktisch angewandt werden und erhöhen somit die Motivation. Der Hersteller der Kacheln bietet qualitativ hochwertiges Material und ist auch offizieller Lieferant der RoboCup German Open Veranstaltung in Magdeburg. 

Die Kacheln aus Aluverbund sind robust und können nach Abschluss des Projekts für die jährliche Wiederholung der Veranstaltung genutzt werden. Zudem können sie für weitere Projekte, Vorlesungen und Veranstaltungen im Bereich künstlicher Intelligenz und Software Engineering verwendet werden.