Wettbewerb: Austrian Open 2017; Challenge-Team

Unser Nachwuchsteam konnte sich vom 21 bis 22 April mit internationaler Konkurrenz messen. Sie haben sich in weniger als einem halben Jahr darauf vorbereitet und konnten nun ihr erlerntes Wissen anwenden und ihr Können zum Vorschein bringen. So haben sie den ganzen Wettbewerb empfunden:

Das Team (v.l.n.r.): Claudio Nold, Alex Marugg, Gian-Reto Hemmi

Nach einem stärkendem Frühstück sind wir auch schon am Austrian Open  angekommen und konnten uns gleich an unserem Platz einrichten. Wir haben für alle Fälle fast die komplette Werkstatt mitgenommen. Dort eingerichtet ging es auch schon los. Wir konnten unseren Roboter in der Test-Arena testen und haben dabei kleinere Fehler bemerkt, welche uns vorher nie aufgefallen sind. Es sind kleinere Probleme in der Software aufgetreten, welche wir versuchten zu lösen. Bei der Problembehebung merkten wir, dass einzelne Lötstellen weniger gut gelötet wurden. Diese mussten wir erneuern. Wir haben unser Bestes gegeben, um diese Probleme zu lösen. Durch einen Bug gelang es uns nicht die Farbsensoren richtig einstellen zu können, da wir unter Zeitdruck lagen und der erste Wertungslauf auch schon vor der Tür stand. Dieser Wertungslauf ging absolut in die Hose. Danach hatten wir noch ein bisschen mehr als eine Stunde Zeit bis zum zweiten Wertungslauf. Wir gaben aber mit der Hoffnung nicht auf, da sowieso nur di zwei besten Läufe gezählt werden. Der zweite Wertungslauf war schon besser, verlief aber leider auch nicht wunschgemäss.

IMG_1512

Das Team bei der Arbeit

Die Niederlage schmetterten wir aber gleich wieder weg und durch aufmunternde Worte unserer Coachs hatten wir neue Energie und Willensstärke getankt. Wir verbrachten den restlichen Nachmittag und den ganzen Abend damit die Roboter zu reparieren und sie wieder auf Vordermann zu bringen. Wir konzentrierten uns vor allem auf die Linienfolge, da diese immer wieder andere Schwierigkeiten aufweist, wie zum Beispiel das Umfahren von Gegenständen oder durch Unterbrechungen gezeichnete Linie. Durch die harte Arbeit und unser Zusammenhalt konnten wir den letzten Lauf meistern. Es war ein Erfolgserlebnis für uns und wir waren sehr glücklich, dass es doch geklappt hat. Wir platzierten uns zwar nur im dritten Viertel der Rangliste, konnten aber viel Erfahrung mitnehmen, wie es unter realistischen Bedingungen ablaufen kann. Eine uns wichtige Erkenntnis war es, sich besser über den genauen Aufbau der Spielfelder zu informieren. Wir freuen uns auf die nächste Challenge.

 

IMG_1546

 

Eine intensive Besprechung um den Roboter

Oktober 2016, WM-Team: Erfolgreicher Start

Ein Schuljahr ging zu Ende und dadurch auch ein Jahr von Helveticrobot. Das Jahr konnten wir mit der Weltmeisterschaft in Leipzig, Deutschland beenden. Wir konnten viele Erfahrungen sammeln und aus den entstandenen Fehlern lernen. Wir haben also nach den erholsamen Sommerferien erfolgreich in ein neues Helveticrobot Jahr gestartet. Wir konnten mit der Unterstützung der Älteren einen lehrreichen Rückblick machen und uns so ein neues Konzept erarbeiten.

IMG_20160917_113204

Überblick des letzten Jahres

Mechanik

Im Monat Oktober hat die Mechanik ihre Arbeit aufgenommen. Ich habe das CAD des letzten Jahres überarbeitet und verbessert. Dabei habe ich darauf geachtet, vor allem die Schwachpunkte zu eliminieren. Das Design wurde dabei nicht gross geändert. Die grössten Änderungen fanden an den Ultraschallhalterungen, den Dribblerhalterungen und den Verbindungen der mittleren zur oberen Ebene statt.

Während der Verbesserung des CADs gab es keine grossen Schwierigkeiten. Das einzige Problem, an dem ich länger gehangen habe, war eine gute Lösung für die Verbindung der mittleren zur oberen Ebene zu finden. Letztes Jahr hatten wir zwei solcher Verbindungen, die eine war die Halterung für das Powerboard und die andere die für den hinteren Ultraschallsensor. Das Problem dabei war, dass die Halterung des Powerboards ziemlich instabil und auch nicht wirklich als Verbindung zwischen mittlerer und oberer Ebene diente. Dieses kleine, jedoch störende Problem haben wir jedoch mit einer einfachen Lösung behoben. Im derzeitigen CAD gibt es nur noch eine breitere Verbindung der mittleren und oberen Ebene, welche gleichzeitig als Halterung für das Powerboard und dem hinteren Ultraschallsensor dient.

Vor allem die Verbindungen von Halterungen zu den Ebenen wurden verbessert. So wurde den Dribblerhalterungen Steckverbindungen hinzugefügt. So werden die beiden Halterungen mit Schrauben und per Stecksystem an die obere Ebene und nur per Stecksystem an die mittlere Ebene angeschlossen.

Auf jeden Fall haben wir das CAD dieses Jahr früher abgeschlossen und können so bereits im November mit dem Ausschneiden der Teile und dem Zusammenbau des Roboters beginnen.

Elektronik

Die Elektronik hat ein Neues Mitglied bekommen. Ich habe mit zwei früheren Mitgliedern von Helveticrobot das Mainboard, Motorboard und das Powerboard angeschaut. In der darauf folgenden Zeit, habe ich die Fehler korrigiert. Auf dem Powerboard habe ich die Akkustatus-Leds weggelassen, weil man den Akkuzustand mit einem Akkuprüfer besser überwachen kann. Dann habe ich noch ein viertes Loch ins Board eingefügt, damit es besser hält. Beim Motorboard habe ich die H-Brücken besser mit dem Prozessor verbunden und das Layout verbessert. Beim Mainboard habe ich Single Bus Buffers eingefügt, damit die SPI Clock verstärkt ist und bei einem SPI Fehler der Prozessor nicht beschädigt wird.

Software

Im Oktober hat sich das Software-Team vor allem um Verbesserungen der letztjährigen Programme gekümmert. Wir überarbeiten das Fahren und versuchten das „schöne“ Fahren ins Visier zu nehmen. Wir testeten, wie genau und wie «schön» der Roboter fahren kann. Dazu liessen wir ihn einen vorprogrammierten Kurs abfahren. Dies funktionierte zunächst nicht zufriedenstellend, doch nach einigen Anpassungen im Programm absolvierte der Roboter die Strecke sehr gut. Auch das Drehen um die eigene Achse und das gleichzeitige Vorwärtsfahren funktionierte gut. Ebenfalls testeten wir, wie gut der Roboter sich um einen Festgelegten Punkt drehen kann. Sofern der Punkt nahem am Roboter selber war, funktionierte es sehr gut. Wenn der Punkt aber weiter weg war, drehte sich der Roboter nicht mehr so schön. Da wir uns im Spiel aber nur um den Ball drehen (dessen Mittelpunkt nahe am Roboter ist), sollte das kein Problem darstellen.

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.