R-ZWEI KICKERS – Das RoboCup SPL Team der Hochschule Kaiserslautern

Die KICKERS sind umgezogen auf Github:

GitHub – AK-Smart-Machines-HS-KL/R2K-SPL: Working code repository for the RoboCup-SPL team R-ZWEI Kickers from Hochschule Kaiserslautern

Wer sind wir, die RZWEI-KICKERS ?

Wir sind ein gemischtes Team von Berufsschülern, Studierenden, Professoren, Industriepartnern – gegründet 2020 – und wir freuen uns jederzeit über Neuzugänge!

Mitglieder des R2K-Kickers Teams:

  • Adrian Müller (Prof. Informatik): Hybride KI, Projektleitung
  • Andreas Hobelsberger (AI, 5. Sem): Simulator Developer, Card Development
  • Connor Lismore (AI, 5. Sem.): Bilderkennung
  • Thomas Jäger (MI, 6. Sem): “the Trainer”, Code, Kicks, Taktik!
  • und als unser Berater: Philipp (abat+): für den Transfer der Inhalte auf Industrie 4.0 und KI Projekte

Ehemalige Mitglieder des R2K-Kickers Teams:

  • David Kostka (AI, 6. Sem.): Bilderkennung
  • Jannis Schottler (AI., 2. Sem): RobCup Junior League Weltmeister
  • Jonas Lambing(BBS KL): Cards, Deployment
  • Markus Dauth (Master Informatik 1.Sem): Agiles Testen, Optimierung
  • Mike Hindi (AI, 6. Sem): Bilderkennung
  • Felix Mayer(AI, 6.Sem.): Teach-In, Optimierung Steuerung

Über den Link unten könnt ihr unserem Chat auf Discord besuchen. Wenn ihr daran interessiert seid, mehr über uns und unsere Arbeit zu erfahren, dann besucht uns bei einem unserer wöchentlichen Treffen.

Warum wir uns “R-ZWEI KICKERS” nennen?

Was findet ihr auf dieser Webseite? So ziemlich alles: worum es geht, wie wir arbeiten, welche Arbeitsmaterialien wir für neue Team Mitglieder vorbereitet haben – und ganz unten auf der Seite eine Liste der aktuellen Projekte und offenen Arbeiten. Viel Spaß beim Lesen😉

Worum geht es? 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.

Unser Kooperationspartner abat+ unterstützt uns deshalb 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.

Unsere Naos 😃

Macht sie nicht kaputt!

“kick their asses!”

Achtung, die neuen Corona Regeln beachten.

Unsere drei Roboter Regeln😎

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.

GORE 2022

Wegen den letzten uns wohl bekannten, weltweiten Corona Restriktionen wurde der RoboCup 2019 remote abgehalten, wodurch auch einige Turniere wie der SPL nicht in der selben Form stattfinden konnten. Aber innerhalb der deutschen Community wurde schon damals ein “German Open Replacement Event” geplant, um zumindest trotz reiner remote Teams das Event unter Turnier Bedingungen stattfinden lassen zu können. 2022 war es dann soweit, dass vor dem offiziellen Start des RoboCup 2022 das GORE sich widerholt hat und im vollen Umfang vor Ort statt fand in der Handelskammer Hamburg. Remote Teams nahmen dennoch teil weil diese sogar von außerhalb von Deutschland kamen!

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 Fußball Rasen.

Voraussetzung hierfür ist die im Projekt bereits mitgelieferte IDE CodeLite oder vorzugsweise Visual Studio code. Als Betriebssysteme benutzten wir derzeit Ubuntu 18.04 LTS (empfohlen) und Windows 10 zum Einsatz.

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 vom amtierenden Weltmeister 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 Code Beispiel. 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. Weiterlesen

Welcome Days 2018: Roboter selbst programmieren

Der Arbeitskreis Smart Machines war auch auf den Welcome Days 2018 vertreten und bot im Rahmen eines Workshops einen Einblick in die Roboter-Programmierung — für Einsteiger!

Die Teilnehmer des Workshops (allesamt ohne besondere Vorkenntnisse!) konnten sich am ersten Tag zunächst anhand von Beipielcode mit den Grundlagen des Programmierens vertraut machen. Im zweiten Schritt galt es dann, diesen Code zu verbessern, zu optimieren, und zu erweitern, was sehr schnell und gut funktionierte. Und weil auf der Teststrecke gelegentlich sehr viel los war, haben einige ihren Code sogar noch um eine Bremse erweitert, falls der Thymio (unser Lernroboter) ein Hindernis — etwa einen Trödler — vor sich entdeckt. Und das ganz ohne Anleitung oder Hinweis!

Am zweiten Tag wurde es dann ernst: Es wurde ein Thymio vorgeführt, der auf einem Ball balancierte, und Aufgabe war es, den Code dazu vollständig selbst zu entwickeln. Und auch hier waren alle Teilnehmer erfolgreich!

 

Insgesamt kann man also von einem rundum erfolgreichen Workshop sprechen. Wir hoffen, es hat allen Teilnehmern so viel Spaß gemacht wie uns und wir konnten einigen das Arbeiten mit Robotern näher bringen.

Wer es selbst einmal versuchen möchte, darf jederzeit einen unserer Roboter ausleihen. Nachfolgend die Ressourcen, die auch den Workshop-Teilnehmern zur Verfügung standen, ergänzt um Lösungsansätze:

The Tactigon Tutorial

The Tactigon board (front)

The Tactigon Tutorial

(Please note that this tutorial is work in progress)

Introduction

We appreciate your interest in programming intelligent machines. Here we show you what kind of materials, resources and know-how the working group Smart Machines has to offer. In addition, we are always available for questions and joint projects.

Our idea was to use soft- and hardware for gesture recognition to remotely control drones, mobile robots and robotic arms to intelligently support workflows. A very elegant and easy-to-use method to achieve this is the Tactigon board by Next Industries. It is a very small, easily programmable Arduino based board equipped with a gyroscope, an accelerometer and many other sensors to allow the detection of gestures, and it also comes with enough computing power to interpret them and make them useful.

The advantage of this approach is that the user can control machines intuitively through easily understandable and learnable gestures while retaining a free mind to focus on the actual problem they are working on, not on operating their equipment. And because the Tactigon uses Bluetooth, there are no wires to trip over, either.

In this tutorial we provide you with

  • references to basic information to get you started
  • example code and videos
  • the full API documentation of the Tactigon
  • game breaking issues that we’ve run into, and possible solutions

For advanced users who have already programmed an Arduino board, we have further information, for example on

  • the technical implementation of gesture recognition
  • how to tell the robot where it is, so it can accurately navigate
  • the man-machine interface concept

To develop applications using the Tactigon, the working group Smart Machines has purchased the drone Crazyflie 2.0 among others. You can find all our information on the Crazyflie, including sample code for use with the Tactigon, on this page.

An important note to conclude: All members of the HS-KL can borrow the resources of the working group at any time; for use in lessons and tutorials, or even for a graduation thesis.

 

Getting started

Before you start, you’ll need a system running Windows (tested on 7 and 10, make sure to install the latest windows updates). The Tactigon is not yet compatible with Mac, Linux or other systems (as of September 2018). Additionally, you’ll need a USB-A to micro-USB cable to upload your sketches to the board.

Please note: The Tactigon uses Bluetooth Low Energy (BLE) for wireless communication. Make sure that any other devices you want it to communicate with also support BLE.

The Tactigon is based on the Arduino platform, so for everything to run smoothly, it is recommended that you use the official Arduino IDE for development. You can find it here.
After downloading and installing the IDE, follow this guide to prepare it for the Tactigon.

The full documentation of the Tactigon can be found here and here.

Please note: All code for the Tactigon must be written in C.

 

Bluetooth Low Energy

Follow this tutorial on how to set up BLE on the Tactigon. Please note that there are code samples at the very end of the linked page which the text refers to.

Points to consider:

  • The role of Tactigon can be CENTRAL or PERIPHERAL, depending on the direction in which the connection is to be established. See bleManager.InitRole(TACTIGON_BLE_CENTRAL); in the linked tutorial code above.
  • BLE is not a mandatory part of Bluetooth. Please make sure your hardware is compatible.

Basic concepts

When working with the Tactigon or other BLE devices, you’ll run into the following concepts:

  • UART: Universal Asynchronous Receiver Transmitter. Standard serial interface between PCs and microcontrollers
  • COM: Serial port interface. Refers not only to physical ports, but also to virtual ports, such as ports created by Bluetooth or USB-to-serial adapters.
  • USB HID: Device that receives input from humans and gives output to humans.
  • The Arduino IDE can monitor the current serial (COM) interface [screenshot pending]. This can be very useful for debugging — use Serial.println("example text"); to write example text to the COM port.

Sensor values, reading out values

For a list of all classes supported by the tactigon,

click here Weiterlesen

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