RCJ 2016; Leipzig; Wettbewerbsbericht

Vier anstrengende Tage und drei kurze Nächte sind nun vorbei. Der Wettbewerb war sehr spannend. Während leider die Elektronik sich immer wieder gegen uns stellte, konnten wir angestrengt immer wieder etwas aus den Boards herausholen. Die Kommunikation per SPI und I2C zu den Boards und Sensoren haben durch eine Störung bezüglich eines Pins, welcher die Signalintegrität zunehmend verschlechterte, das Mainboard immer wieder überhitzen lassen. Dadurch mussten wir immer wieder neue Mainboards bestücken. Wir versuchten herauszufinden, weshalb sich die ganze Kommunikation durch diesen Pin aufhing, konnten aber keinen Zusammenhang finden. Für eine kurze Zeitspanne konnten wir jedoch diese Boards nutzen, da das Mainboard dies stand hielt. Leider haben wir dies nicht sofort gemerkt und haben dann diese Zeitspanne für das Ausprobieren genutzt. Somit hatten wir grosse Schwierigkeiten an den ersten Einzelkämpfen, wie auch bei den Team-Spielen. Wir versuchten aus diesem Problem schlau zu werden, fanden jedoch nur heraus, dass an diesem Pin keine Komponenten daran hingen. Welches uns dann noch viel mehr verwirrte.

Dennoch konnten wir sehr viel aus dieser misslichen Situation mitnehmen. Wir konnten viel lernen und haben eine menge an Erfahrung gewonnen. Vor allem auch wie es ist, wenn man gegen die Zeit rennt, da wir immer wieder unter Zeitdruck standen. Ebenfalls hatten wir die Möglichkeit uns mit anderen Teams auszutauschen um neue Ideen, vor allem bezüglich der Mechanik, zu bekommen. Da nächstes Jahr mehr Wert auf einen passiven Ball gelegt wird, müssen wir uns Gedanken machen, wie wir eine Kamera einbauen können, damit wir diesen dann auch sehen können. Wir freuen uns auf das kommende Jahr.

 

robocup (2) robocup (4) robocup (7)

RCJ 2016; Leipzig; Tag 3

Ein Auf und Ab. Der heutige Tag war sehr intensiv. Das Problem mit der Kommunikation zwischen den verschiedenen Robotern konnte immer noch nicht gelöst werden. Sehr intensiv haben sich unsere Elektronik-Profis damit auseinander gesetzt. Doch irgendwie kommt man nicht auf eine plausible Erklärung, warum das SPI und I2C sich weigern um die Boards zusammen zu verbinden. Das erste Spiel war leider nicht sehr positiv für uns ausgefallen, während das zweite wiederum der volle Erfolg war. Wir konnten mit einem Verlust und einem Gewinn in den Abend tauchen und uns auf die morgigen Spiele vorbereiten. Wir sind gespannt wie sich diese entwickeln werden.

 

sdr

 

Ein Blick auf die Veranstaltung

RCJ 2016; Leipzig; Tag 1

Die Weltmeisterschaft hat begonnen. 

Wir sind gestern mit dem Zug von Chur nach Leipzig gereist. Nach dieser langen fahrt konnten wir uns im Hotel etwas erholen, um am nächsten Tag uns den Optimierungen des Roboter widmen zu können.

Nach unserem Interview, bei welchem wir uns und unsere Arbeit vorstellen mussten, konnten wir intern an dem Roboter weiter arbeiten und uns auch schon auf das Spielfeld einlassen. Leider tauchten Probleme mit der Elektronik auf, welche wir versuchten so gut wie möglich zu reparieren. Da die Halle ziemlich früh zumachte, haben wir unseren Arbeitsplatz ins Hotelzimmer verlegt. Wir sind gespannt, was der morgige Tag uns bringt.

 

Mai; WM-Team; Das SPI bringt uns an unsere Grenzen

In diesem Monat ging es drunter und drüber. Wir haben unsere neuen Räder bekommen und konnten diese mit den selbst hergestellten Subwheels bestücken. Das Erfolgserlebnis schlechthin war die Hülle. Wir massen die Hälfte des Gewichts, wie letztes Jahr. Und die Stabilität hat sich fast nicht verändert. Wir liegen nun gut im Gewicht drin. Leider macht uns aber die Elektronik immer wieder eine Strich durch die Rechnung. Das SPI, mit welchem die Boards verbunden sind, bekommt zu viel Strom und bratet regelrecht unser Mainboard. Wir haben leider noch nicht erkannt wieso, dies so entstehen kann, sind aber dran um diese Problem zu beheben. Dennoch bleibt uns im Moment nichts anderes übrig, als neue Mainboard zu bestücken und diese versuchen so lange es geht am Leben zu behalten. Die Programmierung versucht sich ebenfalls am SPI, da aufgrund dieses Problems die Ballsensoren nichts sehen und somit keine Strategie sinnvoll getestet werden kann. Die Strategien können aber schon geschrieben werden und somit können wir danach diese gut testen.

April; WM-Team; Neue Energie

Nach den Austrian Opens haben wir neue Energie getankt. Wir konnten zusammen sitzen und uns überlegen, wie wir nun vorgehen können und Verbesserungen anbringen können. Wir haben einen neuen Zeitplan erstellt, welchen wir nun befolgen können, da wir nun neue beziehungsweise andere Komponente haben um an denen zu arbeiten. Wir konnten verschiedene Elektronische Aspekte fertig stellen, welche essentiell für den Roboter sind und uns nun an den Feinschliff wagen. Programmiertechnisch versuchten wir das die Sensoren bessere Werte herausgeben, damit wir den Ball und die Ausrichtung schneller laufen lassen konnten. Ebenfalls haben wir uns an eine Strategie gewagt, die ist jedoch noch nicht vollkommen gelungen. Die Hülle des Roboters wurde dabei auch besprochen. Wir brauchen eine sehr leichte, dennoch stabile Hülle. Diese vom letzten Jahr, war sehr stabil, dafür auch ziemlich schwer. Und da die Kapazität des möglichen Gewichtes sich langsam ausschöpft, können wir nicht mit einer solch schweren Hülle rechnen. Wir haben uns entschieden, die Hülle mit einem anderen Kleber zu kleben und weniger von diesem zu benutzen. Die ersten Test damit können bald verübt werden.

März 2016, WM-Team: Lowlevel fast fertig, Platinen bestellt, neue Dribblerrollen

Programmierung

Da die neuen Boards nun angekommen sind, konnten wir uns voll der Programmierung des Lowlevel widmen. Das heisst, dass wir die Boards so programmiert haben, dass sie Werte an das Mainboard geben, mit denen das Mainprogramm eine Strategie ausführen kann. Zudem konnten wir auch die Kommunikation zwischen den Boards zum Funktionieren bringen. Auch die Kommunikation zwischen den Bots konnten wir verbessern, sodass diese nun stabiler funktioniert. Auch bei den neuen Boards schalteten wir den WDT ein, da auch diese nicht immer ganz zuverlässig funktionieren. Im Grossen und Ganzen hatten wir grosse Fortschritte diesen Monat gemacht.

Zudem investierten wir relativ viel Zeit den anderen Teams zu helfen, da diese noch Probleme hatten.

Elektronik

Ende Februar bzw. Anfang März waren die Leiterplatten für die überarbeiteten Sensoren zur Erkennung des Balles bzw. der Begrenzungslinien angekommen. Diese hatten grosse Priorität, da noch ein wenig Lowlevel Code sowie Filter geschrieben werden mussten.

Die Lichtsensoren hatten im letzten Jahr grosse Probleme bereitet, da immer wieder manche Exemplare kaputt gegangen sind, jedoch niemand von uns einen Makel am Schaltplan ausfindig machen konnte. Wie sich erfreulicherweise herausgestellt hat, ist dies mit anderen OpAmps nicht mehr aufgetreten. Wir vermuten, die zuerst verwendeten Verstärker waren all zu anfällig auf ESD, oder sogar schlicht fehlerhaft, haben aber keinen Sinn darin gesehen dem noch näher nachzugehen.

Die Ballerkennung wurde völlig überarbeitet: Vorher hatten wir (wahrscheinlich für Fernbedienungen u.Ä. konzipierte) integrierte Schaltkreise verwendet, wodurch zwar das Interface zum Prozessor einfach, sowie die Erkennung der Richtung des Balles gut war, die Entfernung jedoch nur höchst ungenau abgeschätzt werden konnte. Weiterhin war die Form der Leitplatten eher mühselig.

Wir verwenden nun unverstärkte Photodioden und verstärken sie „selber“ mittels eines Fet-Operationsverstärkers (pragmatischerweise der selbe wie bei den Liniensensoren). Dieses Signal wird mittels des internen Analog/Digital-Konverters eines AtXmega5e gelesen.

Dies hat sich, bis jetzt, als eine gute Lösung für unsere Ansprüche herausgestellt.

Der Umstieg auf diesen anderen, aber recht ähnlichen Prozessor hatten wir als eher trivial eingeschätzt, wir begegneten aber einem schwierig zu findenden Bug: Wenn man den Timer auf Port C benutz, funktioniert dort fast nichts mehr. Wir sind natürlich erst nach erheblichem Aufwand bez. Fehlersuchen auf die Idee gekommen, einen Fehler im Microcontroller selbst zu vermuten.

Sobald wir uns von der Funktionalität der neuen Designs überzeugt hatten, wurden einige kleine Fehler im Layout der Platinen korrigiert und auch die „Slaves“ bestellt.

Des weiteren haben wir unsere Stromversorgung überarbeitet: Wir verwenden nun andere Gleichstromwandler und haben einige /quality of life improvements/ wie Sicherungen, Verpolungsschutz und dreistufigen LED-Indikator für den Akkuladestand.

Mechanik

Das CAD wurde komplett fertiggestellt. Die verschiedenen Teile wurden ausgesägt. Wir testen noch mit verschiedenen Malerrollen, um unseren neuen Dribbler herzustellen. Die ursprünglichen, welche wir bisher immer genutzt haben sind leider nicht mehr Verfügbar. Dennoch haben wir neue gefunden, welche sich sogar der neuen Grösse super anpassen kann. Nun bleibt noch die Frage, wie wir die Festigkeit dieser unterstützen können, damit der Motor nicht nur die Stange selbst sondern die ganze Rolle drehen kann. Wir haben gemerkt, dass wir durch die zusätzliche Platte sehr viel an Stabilität gewinnen können, dennoch bleibt es offen, wie wir in der Gewichtslimite bleiben können. Da wir eine ganze Platte hinzugefügt haben. Dennoch, wir bleiben optimistisch und versuchen so viel wie möglich aus der neuen Platte auszuschöpfen.

März 2016, Challenge-Team Rescue A: Endspurt

Das Rescue-Team A steht kurz vor ihrem ersten internationalen Wettbewerb.

Programmierung

Durch Verzögerungen in der Elektronik in der letzten Wochen, haben wir uns den Bibliotheken gewidmet. Da die Elektronik wieder aufgeholt hatte, konnten wir uns nun dahinter setzen. Leider konnten wir unsere Idee nicht so gut umsetzten wie wir wollten und haben uns dann auf eine andere Lösung geeignet. Wir haben verschiedene Boards gleichzeitig benutzt, welche zusammen vernetzt waren. Durch diese schnelle Lösung konnten wir uns der High Level Strategie widmen. Wir hatten eine ziemlich genaue Vorstellung wie diese Aussehen sollte, durch das war die Strategie sehr schnell fertig zu stellen. Dennoch treten immer noch kleiner Probleme auf, welche wir versuchen zu lösen.

Mechanik

Diesen Monat haben wir die noch nicht ausgeschnittenen Teile ausgeschnitten und zu einem Roboter zusammengebaut. Erfolg zeigte sich beim Einbau der Sensoren, welcher grössten Teils reibungslos verlief. Dieser Erfolg stellte sich allerdings auch bald wieder ein, als die zuerst verbauten Servos sich als funktionsunfähig erwiesen und ausgetauscht werden mussten. Dabei zeigten sich einige Konstruktionsfehler, welche zur Folge hatten, dass einige Teile verändert werden mussten, um die auszutauschende Teile zu erreichen. Doch es gab auch einige Änderungen in dem Plan: Die Erste betraf die Sensoren, welche sich teils als überflüssig erwiesen; eine weitere Veränderung betraf der Auslademechanismus. Statt wie geplant die Ladefläche zu kippen, bauten wir eine Blockade, die nun ausgeklappt als Verlängerung für die Ladefläche dient. Durch diese Veränderungen konnten wir leichter unsere Ideen verfolgen.

Januar 2016, Challengteam Rescue B Line, Step-by-Step

Programmierung
Da unser tatsächliches Board noch nicht fertiggestellt ist, haben wir mit Hilfe eines Breakoutboards für unseren Prozessor bereits einige Bibliotheken getested und zum Laufen gebracht. Wir können nun den UART-Debugger auslesen und LEDs umschalten. Aufgrund der Bauweise des Breakoutboards stiessen wir dabei auf einige Schwierigkeiten – so leuchtete die LED genau dann, wenn wir es nicht erwarteten, was uns zuerst verwirrt hatte. Weiterhin haben wir versucht, Sensoren über ADC auszulesen und Servos anzusteuern. Momentan arbeiten wir noch daran, dass alle Low-Level Bibliotheken bereit sind, wenn unser Board fertiggestellt ist.

Elektronik
Ich habe den Schaltplan fertig gezeichnet.Es gibt 11 Adc Stecker mit einer Spannung von 5V und 3V. Um die Motoren ansteuern zu können brauchen wir eine H-Brücke. Mit einem Pwm-Signal wird über diese H-Brücke der Motor angesteuert. Ich haben einen UART-Stecker darauf gelötet und 2 Stecker die je mit einem Pin welcher für eine zweiten UART wäre. So könnte man wenn man einen zweiten Uart bräuchte diesen aus diesen zwei Steckern zusammenbasteln. Ebenfalls habe ich noch zwei digitale Stecker gemacht.

Mechanik
Wir haben das CAD vollständig fertiggestellt. Es war ab und zu eine Platznot vorhanden, welche aber relativ schnell behoben werden konnte. Wir mussten uns gut überlegen, wie wir das mit den Kits machen, welche wir abwerfen müssen. Dabei haben wir auf den Erfahrungsbericht des letzten Jahr gebaut. Wir haben ebenfalls eine drehende Platte mit Löchern drin erstellt. Wir hoffen auf eine gute Lösung der Reibung zu finden, damit der Motor nicht überlastet.

Dezember 2015, Challengeteam Rescue A Line, Newcomer am Start

Unsere frischgebackenen Challenger haben ihre erste Schritte zum Fertigstellen des Roboter gemacht.

Mechanik
Wir Neumechaniker der Rescue A erhielten an einem Samstagnachmittagunsere erste Einführung ins CAD zeichnen. Wr lernten als allererstes 2DSkizzen zu erstellen und diese danach zu den gewünschten dreidimensionalen Objekten weiter zu verarbeiten. Zuallererst standen
wir an jeder möglichen Ecke an, doch was zuerst nur grobe, klobige
Klötze waren, wurde bald etwas exakter und mehr der Vorstellung
entsprechend. Um weitere Übung zu erhalten, begannen wir Objekte wie
Pingpongschläger abzuzeichnen. Gegen Abend lernten wir noch, wie man
verschiedene Bauteile zu einem vollendeten Roboter zusammensetzen kann
und wie man Pläne herstellt aus welchen danach mit Material gebaut
werden kann. Nun heisst es weiterhin fleissig üben und langsam erste
Ideen für unseren Roboter sammeln.
Nicht zu vergessen ist natürlich, dass wir unser Zimmer aufräumten und
die Legos nun für ein Jahr beiseite stellen bis sie von den nächsten
Newcomern wieder genutzt wird.

RescueA_Mechanik

Bescheidener, unvollendeter Versuch meinen Fotokamera-Ladeadapter zu zeichnen.

Programmierung
Unsere Aufgabe wird es sein, ein „zerstörtes Gebäude“ zu durchqueren und im letzte Raum Opfer in Form von reflektierenden Bällen zu retten. Bis jetzt haben wir geschaut, wie in ungefähr unser Roboter funktionieren sollte und welche Sensoren und Motoren wir dazu benötigen. Das Ansteuern der Sensoren und Motoren wird eine grosse Herausforderung für mich sein, da dies nicht mehr so einfach ist wie bei den Lego-Roboter. Deshalb wird meine erste Aufgabe sein, mich in die Thematik reinzulesen, wie man sich das ganze Vorstellen kann. Ausserdem sollte ich mir überlegen, wie ich diverse Sachen handhaben möchte, wie zum Beispiel das Umgehen eines Hindernisses, die Lokalisierung der Evakuierungszone oder den Übergang vom Linenfolger zur Endzone. Im Endeffekt habe ich noch nichts Sichtbares erreicht, aber in dieser ersten Phase wird es wichtiger sein Informationen zu sammeln und sich Gedanken zur Umsetzung machen.

Oktober 2015, WM-Team: Nicht nur die Roboter kommunizieren

Das WM-Team hat sich Zusammengesetzt und sich so neue Designs und Verbesserungen ausgedacht. Wie bekannt, ist jeder Anfang schwer, doch unser WM-Team meistert dies mit Bravur, in dem sie zusammen an die Probleme rangehen.

Neue Boards

Schon letztes Jahr haben wir ein paar neue Boards designt. Dies kam uns sehr entgegen, da man auch so das Design des Roboters an sich besser anpassen konnte. Dieses Jahr versuchen wir noch mehr zu verändern, während die Mechanik versucht das meist Möglichste aus den Einschränkungen herauszuholen, ohne dabei die Regeln zu verletzen, versuchen wir in der Elektronik uns so gut wie es geht anzupassen. Unser momentaner Schwerpunkt liegt auf den Ballsensoren, welche mit neuen Komponenten bestückt werden und eine neue Form bekommen.

Verbesserung der Kommunikation

In diesem Monat haben wir nach dem vorangegangenen Planen mit dem eigentlichen Programmieren begonnen. Die grundlegenden Funktionen haben wir vom Programm des letzten Jahres übernommen. Zuerst haben wir die Ordnung im Programm verbessert um den Code ein wenig aufgeräumt und ersichtlicher zu gestalten. Dies wird das zukünftige Arbeiten deutlich erleichtern. Auch haben wir die Kommunikation zwischen den Robotern, die mittels Bluetooth funktioniert, überarbeitet, sodass sie nun zuverlässiger funktioniert und bei eventuellen Verbindungsunterbrüchen die Verbindung augenblicklich wieder herstellt. Zudem werden jetzt Warnungen gesendet, falls bei der Initiation der Roboter etwas schiefgehen sollte, sodass wir entsprechende Massnahmen treffen können. Da der Bot letztes Jahr nicht sehr präzise und gleichzeitig auch schnell fuhr, wollten wir dies nun verbessern. Da unsere ersten Versuche damit nicht zum gewünschten Ergebnis geführt hatten, werden wir etwas tiefer in den Code eingreifen müssen, um die Fehler zu beheben.

Eine dritte Ebene

Wir haben uns diesen Monat mit der Elektronik zusammen, vor allem auf das theoretische Designe festgelegt. Mit vielen Diskussionen wurden grundlegende Sachen verändert, welche wir nun versuchen in einem CAD wiederzugeben. Dabei darf nie das Gewicht ausser Acht gelassen werden. Eines der grössten Veränderungen, wird eine zusätzliche Platte dicht über den Rädern darstellen. Durch diese Platte, werden wir versuchen die Sensoren besser zu schützen und unserem Roboter einen besseren Halt zu bescheren. Das CAD wird momentan realisiert, damit man auf auftretende Fehler aufmerksam gemacht werden kann.