Strategie und Technik
Strategie und Technik

... mehr als ein paar Teile zusammenstecken und ein Programm herunterzuladen...
Grundsätzlich gilt: Es gibt keine My-Bot-Wins-All-Strategie. Die Strategie eines Bots wird festgelegt durch den / die Erbauer mittels Konstruktion und Programmierung. Zusätzlich wirken verfügbares Budget und Wettkampfregeln maßgeblich auf die Strategien und die Möglichkeiten ein.
Darum ist jeder Bot ein Unikat mit Stärken und Schwächen.

Aus diesem Grund widersprechen sich hier auch Vorschläge und Ideen. Du musst selbst herausfinden, welche Ansätze Du weiterverfolgen willst. Hast Du andere Ansätze entwickelt, lass uns davon wissen. Niemand kann Dein Unikat nachbauen, aber wir alle können uns weiterentwickeln.

Dieser Strategie- und Technikguide zeigt nicht die "besten", "erfolgreichsten" oder sonstige "-ten"-Möglichkeiten. Es werden lediglich einzelne Aspekte der Konstruktion und Programmierung und ihre Auswirkungen beleuchtet. Hier sollen Anregungen zur strategischen Ausrichtung des eigenen Bots und Ideen zur Umsetzung gegeben werden.

Noch ein Wort an Diejenigen, die sich an dieser Stelle erstmals mit Brick-Sumo beschäftigen:

Einfach mal machen
Strategie-Faktoren
Reibung und Schwerpunkt
Der Haupterfolgsfaktor beim Brick-Sumo heißt "Reibung".
Der Bot, der die höchsten Reibungswerte auf der Arena erzeugt, kann vom anderen nicht oder nur sehr schwer aus der Arena herausgedrängt werden, kann aber seinerseits den anderen Bot "drücken".
Die Reibungswerte wiederum hängen von vielen Faktoren ab, von denen wir aber einige unter Kontrolle bekommen können.

Nicht kontrollieren können wir den Arenaboden. Ist dieser aus PVC, Holz, glatt, geriffelt, genoppt,.... egal. Alle Bots haben hier die gleichen Bedingungen.

Gewicht
Kontrollieren können wir aber das Gewicht des Bots, mit dem er auf den Arenaboden drückt.
Aus diesem Grund macht es durchaus Sinn, das Maximalgewicht des Bots zu erreichen.
Nur, Das Gewicht muss auch richtig verteilt sein. Gewicht durch Höhe bedeutet, dass der Schwerpunkt, also der gewichtsmäßige "Mittelpunkt" unseres Bots nach oben wandert. Rein physikalisch bringt derjenige Sumo-Ringer seinen Gegner zu Fall, der es schafft seinen Gegner unterhalb des Schwerpunktes zu attackieren. Sehr gut kann dies auch beim "Tackling" im Football beobachtet werden.

Fazit: Das Gewicht muss so weit wie möglich in der Nähe des Arenabodens verbaut werden. Dies sorgt dann zusätzlich dafür, dass unser stehender Bot nur mit hohem Aufwand aus dem Stand weggedrückt werden kann (siehe auch Defensiv-Strategien).

Räder / Reifen
Damit unser Bot quasi auf dem Arenaboden klebt, muss sein Gewicht nun auch auf eine möglichst große Fläche verteilt werden, um die Reibung maximal zu erhöhen.
Kleine Räder haben eine kleine Kontaktfläche zum Arenaboden, große Räder aber eine Größere.
Aus diesem Grund sollten immer die größten zulässigen Räder verbaut werden...aber... das Profil ist ausschlaggebend. Reifen mit "Baustellenprofil" haben aufgrund des Profilaufbaus weniger Kontaktfläche als Räder mit wenig Profil (bringen aber mehr Gewicht...)
Anm.: Aus diesen Gründen sind die zulässigen Teile gem. der Brick-Bot Klassen dringend zu beachten.

Die Anbringung der Räder legt die Verteilung des Gewichts auf die Fläche fest. Ein Bot, dessen Räder an den Außenecken des Bots befestigt sind, ist schwieriger zu kippen und zu "drücken" als ein Bot dessen Räder mehr
innerhalb einer Konstruktion liegen. Letzteres hat allerdings den Vorteil, dass die Räder gegen Rampen und Blockaden von anderen Bots geschützt sind.
(siehe hierzu aber auch "Die Drehung und der Drehpunkt")

Targeting
Den gegnerischen Bot zu erkennen ist einfach, ihn zu finden, d.h. zu lokalisieren, und sich ihm zu nähern, um ihn aus dem Ring zu drücken...das ist schon schwieriger.

Häufig sieht man Sumo-Bot Kämpfe (z.B. auf YouTube unter den Suchbegriffen LEGO Sumo, Brick-Sumo, Mindstorms-Sumo oder EV3-Sumo) Bots, die sich immer vor und zurück bewegen bis der "Bumper" Kontakt hat.
Gerade Bots der Klasse 1 (LEGO-Mini 15cm) kämpfen häufig so.

Wenn kein Infrarotsensor verbaut werden darf und in den Wettkampfbedingungen der Mindstorms EV3 Education-Set verboten ist, ist das nachvollziehbar. Ansonsten, gerade wenn der Ultraschallsensor zugelassen ist (bei Brick-Sumo in allen Klassen zulässig), sollte das anders aussehen.

Kurz zum Ultraschallsensor: Er hat einen Öffnungswinkel von ca. 35° - 40°.
Wenn sich also ein Bot mit installiertem Ultraschallsensor dreht, um den Gegner zu lokalisieren, bekommt er das erste Signal i.d.R. nicht, wenn er ihm frontal gegenübersteht.
Achtung: Der Ultraschallsensor findet Gegenstände weit über die Arenagrenzen hinaus.

Hier gibt es mehrere Möglichkeiten die Genauigkeit der Daten zu erhöhen, wobei grundsätzlich gilt:
Es werden nur Ziele akzeptiert, die in einer Entfernung Arenadurchmesser - 1/2 Botgrösse liegen (Ausschließen von Zielen, die außerhalb der Arena liegen) - Targetrange.
Die Richtungsdaten müssen mitgeloggt werden (also, wieviel sich der Bot gedreht hat). Das Mitloggen der Richtungsdaten kann z.B. durch gesteuerte Radumdrehung erfolgen.

In jedem Fall ist vorher zu ermitteln, wie viele Radumdrehungen notwendig sind, um den Bot .z.B. 5° zu drehen. Im Wesentlichen hängt dies von den Größe der Räder ab.

Nachdem der Gegner dann vor einem steht, sollte man mit Volldampf angreifen.  Aber....
Die Frage ist hier: wie weit soll der eigene Bot fahren ?

Es gibt hier unterschiedliche Ansätze:
  • Das erste Signal innerhalb der zulässigen Zielentfernung wird festgehalten und die Drehung erstmal gestoppt. Anschließend dreht sich der Bot um weitere 18° - 20° und steht dem Gegner gegenüber.
  • Der Bot dreht sich auf jeden Fall um 360°, schreibt die Targetdaten dann aber in einen Array. Hier wird dann nur der mittlere Wert berücksichtigt.Für LBS-Runden (Last-Bot-Standing) gilt hier: Alle Target-Daten festhalten und nur vom Ziel mit der kürzesten Entfernung den Mittelwert nehmen bzw. 18° - 20° auf den ersten Positionswert aufaddieren.
  • Der Bot fährt die ganze Strecke, die er gemessen hat, und hofft auf Kontakt (Bumper).
  • Der Bot fährt einen Teil der Strecke und überprüft dann die Richtung (..Gegner bewegen sich manchmal...)
Das Fahren bis zur Arenabegrenzung, also bis ein Signal vom Farbsensor kommt, macht hier wenig Sinn, da der gegnerische Bot ja vor der Begrenzung stehen sollte. Gerade weil die Drehung des Bots Zeit kostet, wie auch die Ermittlung der richtigen Position, sollte Dein Bot nicht wie ein wilder Stier bis an den Arenarand stürmen.

Alternativ sollte man überlegen, ob der Sensor nicht drehbar auf einem mittleren Motor positioniert werden kann. Hier kann, durch Parallelverarbeitung auf dem Brick, der Sensor suchen während der Bot sich bewegt.
Diese Methode hat den Vorteil, dass die Radumdrehungen irrelevant sind, da hier die "Radardrehung" gemessen wird. Im Falle, dass der gegnerische Bot den Eigenen bereits durch die Arena drückt, ist eine Lokalisierung über Radumdrehungen nicht sehr hilfreich.

Eine ähnliche Routine macht auch bei einem festeingebauten Ultraschallsensor Sinn. Hier wird ständig verglichen ob sich ein Ziel innerhalb der Target Range befindet. Ansonsten wird die Fahrt gestoppt und neu gesucht.

In alle Fällen behält man mit dem eigenen Bot die Situation unter Kontrolle, erkauft sich aber den Nachteil, dass der eigene Bot während der Lokalisierungszeit quasi hilflos ist, es sei denn durch die Parallelverarbeitung werden eigene Aktionen durchgeführt. Hierbei ist dann allerdings immer auf die Auswirkung auf die Positionsdaten zu achten.
Die Drehung und der Drehpunkt
Eigentlich ist die Drehung eines Bots einfach zu programmieren: Großer Motor rechts +100, großer Motor links -100 und fertig.

Das Problem mit der Drehung ist, dass sie exakt und kontrolliert ausgeführt werden muss, um die Zielfindung nicht zu stören.

Wie gut oder wie nicht ganz so optimal eine Drehung abläuft wird im Wesentlichen durch die Konstruktion des Bots festgelegt.

Bei zwei einzeln angetriebenen Rädern liegt der Drehpunkt genau in der Mitte zwischen diesen Rädern. Hier wird allerdings ein Drehwiderstand erzeugt, weil die nicht-angetriebenen Räder über den Arenaboden "geschleift" werden.

Stehen die Räder und Achsen dicht beieinander, so ist der Widerstand geringer als wenn sie weit auseinander angebracht sind. Anders gesagt: die nicht angetriebenen Räder entwickeln einen umso höheren Widerstand (aufgrund der Reibung am Arenaboden) umso weiter sie von den Antriebsrädern entfernt sind und umso weiter sie voneinander entfernt sind (Achsenlänge). im ungünstigsten Fall verändert sich durch das "mitschleifen" der Räder die Position des Bots.

Somit hat, bauartbedingt, ein 20 cm Bot (Klasse 1e) einen geringeren Drehwiderstand als ein 30 cm Bot (Klasse 3) (angenommen, jeder Bot hat die Räder an den Außenecken positioniert).

Rein konstruktiv kann der Drehwiderstand jedoch gemindert werden:
  • Die nicht-angetriebenen Räder stehen enger zusammen als die Antriebsräder (Dreiecks-Konstruktion).
  • Die nicht-angetriebenen Räder haben jeweils eigenen Achsen oder sind mittels eines Differentials verbunden. Dadurch kann jedes Rad in der Drehung eine unterschiedliche Strecke zurücklegen (Stichwort Innen- und Außenradius).
  • Die nicht-angetrieben Räder sind beweglich angeordnet oder gar mit einer Lenkung versehen, so dass sie sich in die Drehbewegung hineindrehen.
  • ..oder..oder ..oder.
Ihr seht, die Konstruktion der Räder und Achsen hat auf die Wendigkeit eines Bot eine Menge Einfluss. Hierzu kommt dann noch der Reibungswiderstand je nach Reifengröße usw.

Siehe hierzu auch die Studie: Räder und Antrieb
Reaktionszeit
Grundsätzlich gilt: Wer sich nicht bewegt hat verloren.

Der gegnerische Bot kann, wenn der Eigene sich nicht bewegt, genüsslich seiner Strategie folgen und uns seelenruhig aus der Arena drängen.

Da wir hier keine Opfer-Bots konstruieren wollen, müssen wir also zusehen, dass wir
  • ständig in Bewegung bleiben damit wir schwerer zu finden sind
  • Die Programmierung so anpassen, dass die einzelnen Routinen uns nicht ausbremsen.
Um die Laufzeit der einzelnen Programmroutinen unter Kontrolle zu behalten bietet es sich an, die Routinen mit der Logik "tue das solange eine Bedingung nicht erfüllt ist" oder aber "tue das solange ein Zustand anhält" durch Routinen zu unterbrechen, die sich über den aktuellen Zustand des Kampfgeschehens einen Überblick verschaffen.

Dies ist insofern auch hilfreich, um auf Geschehnisse reagieren zu können die so und in ihrer Abfolge nicht im Programm berücksichtigt wurden (fehlertolerante Entwicklung).

Um das umzusetzen kann ein Ungetüm an bedingten Schleifen programmiert werden. Das wird relativ schnell, gerade für den ungeübten, unübersichtlich und frustrierend.

Alternativ können parallele Prozesse programmiert werden die die Sensoren (Bumper, "Radar", Farbsensor) permanent abfragen und ggf. die Hauptschleife unterbrechen.
Dies macht allerdings nur Sinn, wenn in der Hauptschleife nicht gerade z.B. der Befehl "bewege dich 3 Sekunden vorwärts" läuft, da dieser Befehl, wie alle "tue etwas für x Sekunden/Umdrehungen" nicht unterbrochen werden kann, sondern erst nach der Ausführung die Schleifenunterbrechung wirkt.

Somit ist es besser, alle "tue etwas für x Sekunden/Umdrehungen"-Anweisungen in eigene Schleifen zu legen. Somit würde das dann heißen "tue 10-mal für 0.3 Sekunden etwas" statt " tue für 3 Sekunden etwas". Diese Schleife kann dann alle 0.3 Sekunden von anderen Routinen unterbrochen werden.

Es bietet sich an, beim Testen auf "bewegungslose" Momente des Bots zu achten und hier die Programmierung, z.b. auch durch Zufallsbewegungen anzupassen. Wenn sich der Bot nicht bewegt wirkt auch keine andere Routine auf die Motoren, so dass hier teilweise erheblicher Spielraum existiert.

Die Laufzeit von Programmroutinen, gerade wenn dort Berechnungen stattfinden, kann erheblich verkürzt werden, wenn die erweiterten Rechenfunktionen genutzt werden.
Statt also einzeln den Radumfang mit der gemessenen Gradzahl und diesen Wert dann nochmals mit einem Korrekturwert zu multiplizieren, kann das wunderschön in einer Formel erfolgen.

Array-Berechnungen (wie oben zur Zielfindung beschrieben) laufen meiner Erfahrung nach am langsamsten ab. Hier sollte ein Logik gefunden werden, die Arrays so selten wie möglich aufzurufen und abzufragen.
Beispiel eines rotierenden Radars mit Annäherungsfunktion
Wettkampf-Strategie
Offensiv-Bot
Reine Offensiv-Bots treffen wir überwiegend in den Brick-Sumo Klassen 1 und 1e an.
Aufgrund der begrenzten Abmaße und einsetzbaren Teile bleibt hier auch nichts weiter übrig, als offensiv vorzugehen.
Der Kampf wird i.d.R. durch den Bot gewonnen, der den niedrigsten Schwerpunkt hat und/oder den Gegner als erstes trifft (Überwindung der Masseträgheit durch einwirkende Geschwindigkeit und Eigenmasse).
Immer häufiger werden hier auch Rampen eingesetzt, die die Aufgabe haben, den gegnerischen Bot anzuheben und somit seine Antriebsräder vom Arenaboden "zu lupfen".
Innerhalb der Regularien kann eine solche Rampe nach Start der Runde heruntergeklappt werden und dann durchaus ein Hilfsmittel sein, dass zum Sieg führt.

Der Einsatz von "Hebern", egal ob mechanische Liftarme oder in höheren Klassen (Klasse 3 und 4) auch pneumatische Vorrichtungen (LEGO-Technics) hat sich scheinbar nicht bewährt, da das Gewicht der Bots zu hoch dafür ist.

Offensiv-Bots zeichnen sich durch hohe Bewegungsgeschwindigkeit und einen tiefen Schwerpunkt aus.

In den höheren Klassen sind reine Offensiv-Bots selten, da hier, aufgrund der Baugröße, häufig auch defensive Konstruktionen und Programmroutinen zum Einsatz kommen.

Eines haben aber alle Offensiv-Bots gemeinsam: wenn sie einmal am Gegner dran sind, gibt es nur eine Richtung: Vorwärts.
Hier gibt es allerdings auch einiges zu beachten:
Aus Sicht der Programmierung merkt unser Bot es i.d.R. nicht, wenn seine Räder durchdrehen. Aufgrund der durchdrehenden Räder hat er aber nur eine verminderte Bodenhaftung. Ein Gegner, der vollen Grip auf den Rädern hat kann uns also genüsslich zum Rand schieben während wir uns noch in der Schleife "Volle Kraft voraus" befinden.

Hier hilft es, den Antrieb zwischenzeitlich mal abzuschalten. In diesem Augenblick erhöht sich die Reibung sofort. Selbst wenn der andere Bot uns schiebt kann das die Rettung sein.

Alternativ kann die Motordrehzahl direkt nach Kontakt mit dem Gegner heruntergeregelt werden. Wer also mit 100% auf allen Rädern angreift ist häufig besser beraten, während des Drückens die Geschwindigkeit zu reduzieren, um die Haftung der Räder nicht zu verlieren.



Defensiv-Bot
Defensiv-Bots finde ich persönlich extrem unterhaltsam (als Zuschauer...). Defensiv-Bots tauchen vereinzelt in der Brick-Sumo Klasse 2 (25cm) und des Öfteren in der Klasse 3 auf.

Ihre herausragende Fähigkeit ist es, den gegnerischen Bots mit alle Angriffen ins Leere laufen zu lassen und einen mehr oder minder schnellen Zufallssieg zu erreichen. I.d.R. ist ein Defensiv-Bot auf ein "Unentschieden" aus (12 Kämpfe unentschieden = 12 Punkte, dafür muss ein Offensiv-Bot 6-mal gewinnen...)

Defensiv-Bots bewegen sich, im Gegensatz zu Offensiv-Bots, sehr langsam um die Haftung der Räder nicht zu verlieren. Sie haben große Reifen und konstruktiv die beste Gewichtsverteilung auf den Rädern. Teilweise wird hier schon ein 4-Rad Antrieb eingebaut.

Um die langsame Drehgeschwindigkeit zu kompensieren sind sie rundum durch abgerundete Schilde geschützt die das typische "Verhaken" der Bots in einander minimieren. Rampen, um den angreifenden Bot auflaufen zu lassen, sind hier Standard.

Aus konstruktiven Gewichtsgründen sind diese Bots nur in den höheren Klasse des Öfteren vertreten.

Eine konstruktive Konterstrategie ist hier der "Klapp-Bot". Ein offensiver Bot, der einen Klappmechanismus hat kann zwar angehoben werden oder auf ein Schild auffahren, seine Antriebsräder verlassen hier jedoch nicht den Boden (Hinterradantrieb). Hierbei ist die Gewichtsverteilung des Bots und die Position der Antriebsräder entscheidend.
Dies hilft allerdings wenig, wenn der Offensiv-Bot keinen Umkipp-Schutz hat und soweit den gegnerischen Bot heraufklettert, dass er selbst umfällt.

Rein konstruktiv ist in der Klasse 2 (weil ohne LEGO-Technics-Teile) auch eine tiefe Rundum-Stoßstange hilfreich. Diese verhindert das "unterfahren" durch Schilde und Rampen.
Situativ-Bot
Situativ-Bots sind spannend und komplex. Sie tauchen in der Klasse 2 und vermehrt in höheren Klassen auf und zeichnen sich aus durch:
  • Unterschiedlichste Konstruktionen. Hier entscheidet jeder Konstrukteur, welcher Strategie er mit welchen Techniken kontern will. Aufgrund der unterschiedlichen Schwerpunkte in der Konstruktion sieht man hier die abwechslungsreichsten Bots.
  • Unterschiedlichste Programmierungen. Da unterschiedliche Konstruktionen auch unterschiedliche Räder, Sensoren, Auf-/ und Anbauten bedeuten, ist hier alles auf exakt diesen einen Bot hin programmiert.
  • Sie agieren und reagieren unterschiedlich, je nachdem ob sie sich im Such-, Angriffs- oder Verteidigungsmodus befinden.
So ein Bot wird nie fertig....

In der Konstruktion sind sie sehr aufwendig und es gibt, im Gegensatz zu Offensiv- und Defensiv-Bots, hierfür im Netz keine Bau- oder Programmieranleitungen.

Ungeachtet dessen ist ein Situativ-Bot durchaus mit einem Offensiv- oder Defensiv-Bot zu schlagen. Es gibt halt, wie oben beschrieben, keinen Bot der immer gewinnt.
ZF und GF
Beim Bot-Bau schlägt der Zeitfaktor (ZF) zu.

Insbesondere Situativ-Bots können in der Konstruktion schon mal 60 und mehr Stunden verschlingen. Die Programmierung ist bei allen Bots (meiner Erfahrung nach) immer um den Faktor 1,5 - 2 aufwendiger.

Auswirkung im Wettkampf hat allerdings auch der, weder durch Konstruktion noch durch Programmierung zu beeinflussende, Glücks-Faktor (GF).
Wenn der gegnerische Bot exakt die Strategien verfolgt, auf die man seinen eigenen Bot vorbereitet hat und dann noch die Räder die Haftung nicht verlieren, dann ist dieser Wettkampf einfach ein Höhepunkt.... bis zum nächsten Gegner...
Sensor-Kalibrierung
Farbsensor
Diejenigen von uns, die nicht täglich mit Messgeräten arbeiten, verwenden wahrscheinlich zu wenig Zeit darauf, sich mit der Funktion eines Messgerätes (Farbsensor) und der Kalibrierung auseinander zu setzen. Für uns ist dieser Beitrag gedacht.

Mich hat gewundert, dass in mehreren Fights die Bots über die Arenabegrenzung hinausschießen, obwohl ein Farbsensor eingebaut und korrekt programmiert wurde. Das Buch von James Jeffry Trobaugh „Winning Design“ (engl.), erhältlich unter ISBN 978-1-4842-2104-4, hat mir hier die Augen geöffnet (Weitere Lesehinweise findest Du hier)

Im Brick-Sumo kann es, je nach Strategie und Konstruktion, notwendig sein, einen Farbsensor zur Erkennung der Arena-Begrenzung einzusetzen.
In diesem Fall wird der Farbsensor auf die Erkennung einer schwarzen oder weißen Begrenzungslinie abgefragt.
Was aber ist eigentlich „schwarz“ oder „weiß“?
Der Farbsensor sendet ein Referenzlicht, dass wenig (Schwarz), in Zwischentönen (Grün, Rot, usw.) oder sehr viel (Weiß) reflektiert wird. Das Thema der unterschiedlichen Wellenlängen lasse ich hier aus Vereinfachungsgründen mal weg.

Bezogen auf „Schwarz“ und „Weiß“ gibt es hier aber noch den Einflussfaktor „Umgebungslicht“ bzw. „Streulicht“.

Streulicht: Ist der Farbsensor zu hoch eingebaut, so nimmt er auch das Streulicht von der Sonne oder der Raumbeleuchtung auf. Eine schwarze Fläche wird für ihn dann zu einem hellen Grau, eine weiße Fläche ggf. zu einem leichten Gelb. Aus diesem Grund sollte der Farbsensor recht niedrig eingebaut werden. Idealerweise wird das Streulicht durch Beschattungsmaßnahmen (z.B. Rahmen / Schild) zusätzlich vor Streulicht geschützt.

Randerkennung: Soll das Programm bereits reagieren, wenn der Farbsensor den inneren Rand der Arenabegrenzung erkennt (Schwellwert) oder erst, wenn er die komplette Arenabegrenzung unter sich hat.

Umgebungslicht: Je nach Beleuchtung der Arenafläche (Sonnenlicht, Leuchtstoffröhren, Fotolampen, usw.) besteht die Gefahr, dass der Farbsensor unterschiedliche Werte zurückgibt. So kann die Arenabegrenzung im heimischen Wohnzimmer unter der warmen Wohnzimmerbeleuchtung erkannt werden, in einem Klassenzimmer mit Leuchtstoffröhren jedoch nicht.

Kalibrierung: Der Farbsensor kann auf zwei Wegen kalibriert werden: Zum einen werden die Kalibrierungsdaten auf dem Brick per Kalibrierungsfunktion gespeichert oder zum anderen in einer Textdatei (auch auf dem Brick). Wesentlicher Unterschied der beiden Methoden: Auf dem Brick kann nur ein Wertepaar (hellster und dunkelster Wert) gespeichert werden. Diese gelten dann für alle angeschlossenen Farbsensoren. In einer Textdatei können die Werte je Sensor separat gespeichert und abgerufen werden.

Ich verbleibe hier bei der Speicherung auf dem Brick per Kalibrierungsfunktion.

Grundsätzlich sollte die Kalibrierung am Ort des Wettbewerbes, möglichst direkt an der Arena, durchgeführt werden. Es empfiehlt es sich, ein Stück Kalibrierungsmaterial (PVC-Folie mit Musterlinie) dabei zu haben, falls der Zugang zur Arena zum Kalibrieren nicht möglich ist.
Achtung: Die Kalibrierungsdaten werden im Brick nur bis zum Ausschalten oder bis zur Re-Kalibrierung festgehalten.

Durchführung:
  • Kalibrierungsprogramm starten
  • Sensor über eine schwarze Fläche halten und zentrale Taste am Brick drücken
  • Schwarz-Wert ablesen und zentrale Taste drücken
  • Sensor über eine weiße Fläche halten und zentrale Taste am Brick drücken.
  • Weiß-Wert ablesen und zentrale Taste am Brick drücken.
Hiermit einfach mal bei verschiedenen Lichtverhältnissen und mit unterschiedlichen Abständen zur Farbfläche probieren.

Nach dieser Kalibrierung sind der Weiß- und der Schwarz-Wert eingespeichert und die Farben können wie gewohnt abgefragt werden.

Mit diesem einfachen Programm lässt sich auch der Grenzbereich zwischen Arenafläche und Arena-Begrenzungsring ausmessen. Dies ist allerdings nur notwendig, wenn Du auch schon reagieren willst, bevor Du den Begrenzungsring komplett unter Dir hast ...
Brick-Sumo / LEGO-Sumo Kalibrierung des Farbsensors
Share by: