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.

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

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. 

 

 

Regelwerk für den einfachen Parcours

Regelwerk für einen einfachen Line Following Parcours

Regelwerk für einen einfachen Line Following Parcours (PDF Download)

 

Kurzbeschreibung

Ein autonomer Roboter soll in einer modular aufgebauten Arena aus Kacheln mit verschiedenen Mustern einer schwarzen Linie folgen. Der Boden ist von weißer Farbe.

 

Allgemeine Vorgaben

Die Teams dürfen dem Roboter kein Vorwissen über das Spielfeld geben, weil der Roboter das Spielfeld selbst erkennen soll.

Falls der Roboter an einer Stelle nicht weiterkommt, kann er am jeweiligen Plattenanfang wieder eingesetzt werden bzw. nach Entscheidung des Teamkapitäns vor die Start-Ziel-Linie platziert werden und eine neue gezeitete Runde beginnen.

 

Spielfeld

Beschreibung der Kacheln
  • Der Parcours im Wettbewerb ist ein Rundkurs, der in der angegebenen Richtung absolviert werden muss.
  • Die Arena ist modular aus Kacheln aufgebaut, die verwendet werden können, um eine beliebige Anzahl von verschiedenen Kursen für die Roboter zu erstellen. Die Arena kann auch in Zukunft durch neue Kacheln ergänzt werden.
  • Das Feld wird aus Kacheln von 30 cm x 30 cm bestehen, mit unterschiedlichen Mustern. Die endgültige Auswahl der Kacheln und ihre Anordnung werden nicht vor dem Tag des Wettbewerbs bekannt gegeben. Wettbewerbskacheln dürfen auf ein hartes Trägermaterial beliebiger Stärke aufgebracht werden.
  • In einem Wettkampffeld wird es mindestens 8 Kacheln geben.

Es gibt verschiedene Kacheldesigns (Beispiele sind unter dem Punkt „Linien“ zu finden).

 

 

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. Zwischen den Kacheln kann es zu Stufen und / oder Lücken bei der Konstruktion der Arena kommen. Diese sind nicht erwünscht und werden von den Organisatoren so klein wie möglich gehalten.


Linie
  • Die schwarze Linie kann mit Standard-Isolierband, 1-2 cm breit, geklebt oder auf Papier oder anderem Material ausgedruckt werden. Die schwarze Linie markiert einen Weg auf dem Boden (das Raster auf dem Boden in der Darstellung dient nur der Referenz und Wettbewerber sollten damit rechnen, dass Kacheln verdoppelt, verändert und / oder ausgelassen werden).
  • Die Linie wird 10 cm Abstand von den Rändern der Arena haben.
  • Beispiele für mögliche Kachelmuster:
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) 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 (Materialkosten bis 400 Euro), 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 bei der B.O.T. Challenge 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 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 bzw. Eltern dürfen in der Vorbereitung der Wettkampfläufe nicht bei Programmierungen und/oder technischen Hardwaremodifikationen/Reparaturen assistieren. Ausschließlich die Teammitglieder dürfen in den zugewiesenen Teambereichen an den Robotern arbeiten. Ausnahmen von dieser Regelung sind nur unter vorheriger Freigabe durch die Wettbewerbsleitung gestattet.

     

    Die Challenge

    Beginn des Spiels
    • Ein Lauf beginnt zur angesetzten Startzeit, egal ob die Teams anwesend / startbereit sind. Startzeiten werden im Rahmen der Veranstaltung deutlich sichtbar angezeigt.
    • Die Startkachel ist ein impliziter Wiedereinsatzpunkt, an dem der Roboter erneut starten kann um eine neue gezeitete Runde zu beginnen.
    • Sobald der Wertungslauf begonnen hat, darf der spielende Roboter den Wettbewerbsbereich aus keinem Grund verlassen.
    • Jedes Team hat höchstens 8 Minuten Zeit, um die Sensoren zu kalibrieren und die Strecke zu absolvieren. Die Zeit für jeden Lauf wird vom Juror gestoppt.
    • 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.
    • Die Teams können den Roboter an so vielen Standorten der Arena kalibrieren, wie sie möchten, aber die Zeit läuft dabei weiter. Roboter dürfen sich nicht aus eigener Kraft bewegen, während sie kalibrieren.
    • Sobald die Teams bereit sind, um einen Wertungslauf zu absolvieren, müssen sie dies dem Juror mitteilen. Um einen Wertungslauf zu starten, muss der Roboter vor die Startkachel für einen „Fliegenden Start“ des Kurses gesetzt werden. Der Startpunkt wird durch den Juror angezeigt.
    • Ziel ist es die beste Rundenzeit zu erreichen. Die schnellsten drei Rundenzeiten jedes Teilnehmers werden gemittelt und mit einer Vergleichswertrechnung (Bot Vergleichsfaktor, siehe Anhang) je nach Roboter normalisiert.
    Spielmechanik
    • Sobald der Wertungslauf begonnen wurde, ist keine weitere Kalibrierung möglich.
    • Nur der Teamkapitän darf den Roboter neu starten. Die Teams dürfen beim Neustart weder den Roboter verändern/reparieren noch die Programmierung ändern. Ausgenommen von dieser Regelung ist eine Anpassung der Fahrgeschwindigkeit der Bots.
    • Es gibt keine Obergrenze für die Anzahl an Neustarts in einem Spiel. Die Gesamtzeit sollte jedoch von den Teilnehmern im Auge behalten werden.
    • Einzelne Kacheln können geändert oder getauscht werden kurz bevor ein Wertungslauf startet, um die Teams daran zu hindern, das Layout des Spielfeld vorzukartieren.
    • Es ist verboten, den Roboter während eines Laufs tiefgreifend zu modifizieren.
    • Die Teams dürfen ihren Robotern keinerlei Vorabinformationen über das Spielfeld geben. Ein Roboter soll die Elemente des Spielfelds selbst erkennen.
    • Roboter die sich durch Abkürzen (besonders in Kurven und Schikanen) einen signifikanten Vorteil verschaffen, können mit Strafzeiten von 1 bis 3 Sekunden pro abgekürztem Streckenabschnitt belegt werden. In besonders schweren Fällen können einzelne Rundenzeiten von der Wertung gestrichen werden. Die Entscheidung liegt im Ermessen der Juroren.
    Nicht-Vorankommen („Lack of Progress“ – LoP)

    „Lack of Progress“ liegt vor, wenn

    • der Teamkapitän „Lack of Progress“ anmeldet
    • der Roboter die Linie verlässt und nicht selbstständig wieder zurückfindet
    • Wenn „Lack of Progress“ auftritt, muss der Roboter an den Start des Kurses in Fahrtrichtung zurückgesetzt werden. Das wird durch den Juror überprüft.
    Spielende
    • Die Teams dürfen jederzeit entscheiden, eine Runde vorzeitig zu beenden. In diesem Fall muss der Teamkapitän dem Juror den Wunsch des Teams mitteilen, die Runde zu beenden.
    • Die Runde endet, wenn
      • die Zeit abläuft
      • der Teamkapitän den Lauf für beendet erklärt

      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.

      Anhang: Bot Vergleichsfaktor

       

       

      Die oberen Bilder sind lizenziert unter einer

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