Makeblock mBot Ranger: Eine Anleitung zur Programmierung des Roboterbausatzes mit der ArduinoIDE

Als Roboterbausatz wird der Makeblock mBot Ranger verwendet. Es gibt noch andere Makeblock Bausätze. Die Pin/Port-Belegung ist dann etwas anders und es gibt andere Sensoren, aber im Großen und Ganzen funktioniert das alles sehr ähnlich wie bei dem hier beschriebenen mBot Ranger.

Mit dem Bausatz lassen sich 3 verschiedene Modelle bauen (und mit etwas Kreativität noch weitere):

Der MakeBlock Ranger Bausatz verwendet ein Auriga Board mit einem ATmega2560 Prozessor, wie auf dem Arduino Mega 2560 Board (damit ist die Programmierung schon sehr ähnlich der Arduino-Programmierung). Das Auriga-Board ist die Weiterentwicklung des Orion-Boards (welches bei früheren mBot Bausätzen verwendet wurde) und kann einiges mehr.

Hier ist eine Funktions-/Ausstattungsbeschreibung (basierend auf der Produktbeschreibung aus shop.technik-lpe.de:

Der Auriga ist eine gut ausgestattete Hauptsteuerplatine, die speziell für den MINT-Unterricht entwickelt wurde. Basierend auf dem ATmega 2560 sind auf dem Auriga bereits eine Reihe von Sensoren und Aktoren vebaut, und es können externe Sensoren oder Motoren angesteckt werden. Hier ist ein kleiner Überblick:

Die offizielle Dokumentation des Roboterbausatzes schweigt sich über die Internas und Programmierung der Platine ziemlich aus. Daher basiert diese Anleitung auf Reverse-Engineering, Literaturrecherche im Internet und Sichtung vieler Forenbeiträge.

Viele nachfolgend und in den anderen Teilen beschriebene Details habe ich aus dem englischsprachigen Text von Gosse Adema (https://www.instructables.com/Advanced-Makeblock-Sensors-DIY) gefunden.

Hier sind noch einige Dokumente, die ich zusammengetragen habe:

Auch gibt es zahlreiche Github-Projekte (siehe Schlagwort MakeBlock ).

Nachfolgende Schritte sind für ein hinreichend aktuelles Linux beschrieben, konkret Ubuntu 22.04 oder neuer. Eigentlich müsste das Board aber auch mit älteren Systemen wie Ubuntu 18.04 oder so noch problemlos funktionieren.

Der Makeblock Ranger bzw. das Board und der Prozessor werden mit einer vorinstallierten Firmware geliefert. Diese Firmware ist nichts anderes als ein (recht komplexes) Arduino-Programm. Dieses Programm enthält die Basisfunktionalität (wie im Handbuch beschrieben), einschließlich der Bluetooth-Kommunikation mit der SmartPhone-App.

Dieses Programm (also die Firmware) ist im Quelltext verfügbar. Den kann man sich herunterladen (siehe unten) und nach Belieben anpassen und verändern. Das ist auch einer der Gründe, warum ich die MakeBlock Roboterbausätze ziemlich cool finde. Außerdem kann man in der Firmware jede Menge abgucken.

Die originale Firmware stellt auch die Funktionalität für die "Live"-Tests in der mBlock-Umgebung (z.B. zum Sensor-Auslesen) bereit. Sobald man ein anderes Programm hochgeladen hat, funktioniert diese "Live"-Funktionalität nicht mehr. Wenn man also wieder mit der Block-basierten Programmierung in mBlock arbeiten will und dort die "Live"-Test Funktionalität braucht, lädt man einfach die Firmware wieder hoch und mBlock funktioniert wieder wie bisher.

Für das Compilieren der Firmware sind aber noch die Makeblock-Bibliotheken notwendig. Dafür gibt es zwei Methoden:

Wie üblich in der Arduino IDE wählt man zuerst

Die Makeblock Bibliothek bringt als Beispiel-Programm die Firmware mit. Man wählt diese über Datei→Beispiele→MakeBlock Drive Updated→Firmware_For_Auriga aus.

Man muss dann in der Arduino-IDE noch den Port und die CPU einstellen: hier wählt man Arduino Mega or Mega 2560 aus (dazu gleich mehr im folgenden Kapitel). Dann kann man das Firmware-Programm übersetzen und hochladen. So kann man nach dem Ausprobieren eigener Programme stets zum Originalzustand zurückkehren.

Um das Aufspielen des Programms zu testen, kann man die eingebaute LED auf Pin 13 (wie bei jedem Arduino Board) blinken lassen. Das Programm dazu entspricht dem typischen Arduino Blink-Beispielprogramm:

Innerhalb der Makeblock-Bibliothek werden Sensoren und Aktoren über Ports angesprochen, statt direkt Pins zu bezeichnen. Dies liegt daran, dass die Makeblock-Bibliothek auch für andere mBot Modelle ähnlich verwendet wird. Die Zuordnung von Ports zu Pins ist in Quelltext-Header-Dateien hinterlegt, welche für die unterschiedlichen mBot-Bausätze anders heißen. Die für Auriga-Board verwendete Diese sind in der Makeblock-Bibliothek in der Datei MeAuriga.h definiert:

Jeder Makeblock-Port ist an 2 Pins angeschlossen. Diese Pins werden als Slot1 und Slot2 bezeichnet. NC steht für Not Connected. Ports 1 bis 10 sind RJ25 Ports (dazu mehr im Kapitel zu den RJ25 Anschlüssen [chap:rj25]).

Als Beispiel: der Port 6 ist an den analogen Pin 10 und analogen Pin 15 des Mikrocontrollers angeschlossen.

Einige Komponenten sind direkt über IO Pins anzusteuern:

Die Motoren können zwar recht einfach durch die Bibliothek angesteuert werden, hier sind aber nochmal die Pins (falls man die Motoren klassisch über Arduino Pin PWM-write-Befehle ansteuern möchte, siehe Kapitel über die Motorensteuerung Abschnitt 8):

Auf dem Board gibt es eine ganze Reihe von LEDs, die man programmieren kann. Da ist zunächst eine blaue Standard Arduino LED, die wie bei anderen Arduino Boards auf dem Pin 13 anzusprechen ist. Dann sind da noch 2 LEDs beim Kommunikationsmodul vorhanden, die primär Kommunikation über die serielle Schnittstelle (Bluetooth/USB) anzeigen. Dazu gibt es noch den 12er RGB LED Ring, bei dem man alle 12 LED unterschiedlich bunt einfärben kann und damit ein vielseitiges Anzeigegerät für Roboterzustände hat.

Dann gibt es noch eine grüne "On"-Status-LED (nicht programmierbar, hart verdrahtet), 2 rote LEDs direkt unter dem RGB-Ring (auch nicht programmierbar) und die blaue, ryhtmisch blinkende LED oberhalb des Reset-Tasters (auch nicht programmierbar).

Die eingebaute blaue LED auf dem Board ist eher schlecht zu sehen (im Vergleich zu der regelmäßig blinkenden blauen "an"-Status LED):

Diese LED wird wie bei allen Arduino-Boards programmiert - man kann das Standard-Blink-Beispielprogramm nehmen:

Es gibt zwei weitere LEDs auf dem Auriga Board und zwar die zwei kleinen roten und blauen LEDs in der Nähe des USB Anschlusses. Diese werden in der Makeblock Bibliothek nicht verwendet, auch nicht in der Firmware. Man kann diese aber mit den Arduino-Standardpins ansprechen, wenn man denn erstmal weiß, an welchen Pins diese LEDs angeklemmt sind.

Daher schaut man zuerst mal in den Schaltplan MeAuriga_Schaltplan.pdf. Die zwei LEDs sind im Abschnitt 程序更新&无线遥控 (dt. Programmaktualisierung und drahtlose Fernbedienung) aufgeführt:

Diese LEDs sind mit den Pins D0/RX0 und D1/TX0 des MEGA2560 Mikrocontrollers verbunden. Diese LEDs werden hauptsächlich dafür benutzt, die Kommunikation über diese Ports anzuzeigen. Die Anoden der LEDs sind mit +5 Volt verbunden. Also leuchten sie, wenn der jeweilige Pin (Kathodenseite) auf GND gezogen wird (LOW).

Als Zusatzmodul für das Auriga-Board gibt es einen RGB Ring (Typ: ws12812).

Der LED Ring wird über einen Controller angesteuert, der am PWM PIN 44 am ATmega 2560 angeschlossen ist. Die Programmierung des Controllers ist in der Klasse MeRGBLed implementiert, welche über die Include-Datei MeRGBLed.h eingebunden wird. Der RGB-Controller selbst wird über das WS2811/2812 Protokoll angesprochen, was aber die MeRGBLed-Klasse übernimmt.

Grundsätzlich hält die Klasse eine Datenstruktur für die RGB-Informationen jeder einzelnen RGB. Die Konfiguration der RGB kann nun durch Zugriffsfunktionen wie setColorAt() geändert werden. Dabei wird zunächst nur der interne Zustand des Klassenobjekts geändert. Die Ansteuerung des Controllers selbst und damit das Umschalten der LEDs erfolgt erst beim Aufruf von show().

Die LED 0 (bzw. 1. LED) ist übrigends die LED auf "1 Uhr", wenn man sich das Bild oben anschaut. Die oberste LED ("12 Uhr") ist die LED 11 und LED 2 (bzw. 3. LED) zeigt in Richtung "Vorwärts" des Land Raider Modells.

Der Sound-Sensor auf dem Auriga-Board wird über die Klasse MeSoundSensor (Include-Datei nur MeAuriga.h) ausgelesen.

Die Klasse hat nur eine sinnvolle Memberfunction: strength(), was die Lautstärke im Bereich 140 bis ~600 ausgibt.

Es gibt zwei Helligkeitssensoren auf dem Auriga Board:

Die Klasse MeLightSensor liest die Helligkeitswerte aus (im Bereich 0..1000) (Memberfunktion read()).

Auf dem Board ist ein DS18B20 Temperatursensor verbunden. Dieser wird über das Wire-Protokoll am Port 13 abgefragt. Die entsprechende Implementierung steckt in der Klasse MeOnBoardTemp mit der Member-Funktion readValue() (bzw. readAnalog() für den Rohwert).

Das Auriga-Board hat einen Neigungssensor verbaut. Dieser liefert für die 3 Achsen x,y,z jeweils Neigungswerte/Ausrichtungswerte und dazu die Beschleunigungen auf den 3 Achsen.

Die Achsenzuordnung ist dabei wie folgt:

Entsprechend ist die X-Beschleunigung die Beschleunigung vorwärts und Y-Beschleunigung die Drehbeschleunigung. Interessant ist die Z-Beschleunigung (Querbeschleunigung) beim schnellen Kurvenfahren.

Zum Auslesen des Neigungssensors/Gyroskops verwendet man die Klasse MeGyro wie im nachfolgendem Beispiel gezeigt.

Für den Nervous Bird (das umgedrehte Pendel) ist der Neigungssensor essentiell, damit man hier das Gleichgewicht hält. Die Programmierung eines solchen Robotermodells, der beim anschubsen selbständig vor-/zurück fährt und das Gleichgewicht behält, ist aber ein anspruchsvolleres Projekt.

Auf dem Auriga-Board ist ein passiver Buzzer verbaut, welcher an einen PWM-Pin angeschlossen ist. Der Buzzer ist an Pin 45 angeschlossen.

Beim Blick in die Include-Datei MeAuriga.h fällt einem am Schluss der Datei folgende Quelltext auf:

Hier wird also beim Einschalten der Pegel auf HIGH gezogen und beim Ausschalten der Pegel wieder auf LOW. Das ist allerdings Code, der für einen aktiven Buzzer gedacht ist, und wahrscheinlich vergessen wurde, zu entfernen.

Um den passiven Buzzer anzusteuern, verwendet man tone() und zum Ausschalten noTone(). Hier ist ein Beispiel für die direkte Ansteuerung des Pins.

In der Makeblock-Bibliothek gibt es noch die Klasse MeBuzzer. Diese kapselt den Zugriff zwar etwas, macht die Ansteuerung des Buzzers aber nicht wirklich einfacher.

Man kann mittels der Member-Funktion MeBuzzer::tone(frequenz, dauer in ms) einen Ton ausgeben. Diese Funktion implementiert einen Software-PWM (d.h. in dieser Funktion wird der angegebene Buzzer-Pin sehr häufig an und aus geschaltet, wobei das Verhältnis der an/aus-Zeiten die Tonhöhe definiert).

Somit kann man auch externe Buzzer anschließen und dabei Ports mit digitalen Pins (keine analogen/PWM Pins) nutzen.

Am Auriga-Board gibt es zwei Motorports. Jeder der DC-Motoren kann über einen PWM Pin (analoge Spannung für die Geschwindigkeit) und zwei digitalen Pins für die Drehichtung angesteuert werden. Die Ansteuerung kann einmal direkt über die Arduino-Pins erfolgen oder unter Verwendung der Makeblock Bibliothek (in der die Details gekapselt sind).

Die Motoren werden an die beiden Motorports angesteckt:

Zunächst beschreibe ich mal die Programmierung der Motoren ohne die MakeBlock-Bibliotheksklassen. Dadurch versteht man besser, wie das alles zusammen funktioniert. Danach beschreibe ich in Abschnitt 8.7 die Funktionalität der MakeBlock-Bibliotheksklasse zur Encoder-Motor-Programmierung.

Aus dem Schaltplan kann man die Bezeichnung der digitalen Pins (D46…​D49) und die PWM Pins (D10, D11) entnehmen:

Die digitalen Pins werden nun wie folgt angesprochen:

Der Encoder im Motor ist ein Drehimpulsgeber/Tacho und liefert elektrische Impulse, die man zählen kann. Damit kann man die Geschwindigkeit und zurückgelegte Entfernung bestimmen. Zum Einstieg in das Thema Encoder kann ich das Encoder Tutorial Arduino (deutsch, für Anfänger) empfehlen.

Der Encoder eines Motors ist am Arduino an jeweils zwei digitalen Pins angeklemmt. Um einen Drehimpuls zu erfassen, muss man den einen Pin überwachen und feststellen, wann dieser von 0 auf 1 wechselt. Damit man das präzise machen kann, ohne dass anderen Aufgaben im Mikroprozessor die Messung beeinträchtigen, verwendet man Interruptfunktionen. Dazu registriert man für jeden Motor eine Interruptfunktion, die immer dann aufgerufen wird, wenn am entsprechenden Pin ein RISING Signal anliegt (also der Eingangspin von LOW auf HIGH wechselt). In der Interruptfuktion wird dann ein Zähler hochgezählt, der dann für die Berechnung der Momentangeschwindigkeit und Bewegung verwendet wird.

Damit man die Rotationsgeschwindigkeit in Abhängigkeit des gesetzten PWM-Duty-Cycles testen kann, wird im Programm von der seriellen Schnittstelle gelesen. Diese serielle Schnittstelle dient eigentlich dazu, Daten vom Roboter an die Arduino-IDE zu geben, z.B. den SerialPlotter zur Anzeige (wie das schon in Abschnitt 6 mit den Sensoren gemacht wurde).

Mann kann aber genauso gut auch Text zurück an den Roboter senden. Dazu tippt man einach im SerialMonitor oder SerialPlotter den Text ein und bestätigt mit Enter. In diesem Programmbeispiel werden die Zeichen 0 bis 6 akzeptiert und je nach Zeichen wird eine andere PWM-Leistung eingestellt. In einem späteren Beispiel wird diese Kommunikation nochmal etwas erweitert.

In diesem Testbeispiel kann man den Robotor begrenzt steuern:

Alternativ kann man das auch im SerialPlotter machen.

Wenn man jetzt das Programm mal und die Geschwindigkeiten plottet erhält man ein interessantes Bild:

Da die Kette schwingt und auch nicht gleichmäßig steif ist, führt dies zu ungleichmäßigen Drehbewegungen des Motors. Um diesen Einfluss zu sehen, habe ich an einen Motor die Kette angebaut und am anderen Motor nicht. Klar erkennbar im Diagramm ist auch die Bremswirkung der Kette insgesamt - der Motor mit Kette dreht langsamer.

Außerdem scheint die Drehzahl nicht proportional zum PWM-Duty-Cycle zu steigen (vor allem bei PWM 100). Dies liegt daran, dass der generierte PWM-Takt zu langsam ist. Um dies zu beheben, kann der PWM-Timer des Arduino umprogrammiert werden, sodass er mit 8kHz läuft.

Der MEGA 2560 Prozessor hat intern Timer, die auch für die Generierung von PWM-Duty-Cycles verwendet werden. Für die Pins 11 und 12 ist der Timer 1 zuständig (16 bit). Und für Pins 9 und 10 der Timer 2. Für diese Pins ist die Standardfrequenz 490 Hz.

Diese Timer-Frequenzen kann man umprogrammieren (siehe auch Erklärung in Interrupts – Teil 3: Timer Interrupts und beispielsweise die konkret verwendete Bitmaske für Timer 1 auf Arduino Web Timers).

Der relevante Code-Block ist:

_BV(X) steht für einen Bitshift 1 << X.

Erneut getestet sieht die Geschwindigkeitsausgabe deutlich besser aus, d.h. auch die durch die Encoder erfasste Drehzahl ist auch bei kleineren Drehzahlen hinreichend proportional zur Sollgeschwindigkeit (in PWM), was man gut am freilaufenden Motor sehen kann.

Beim freilaufenden Motor wird die festgelegte Soll-Geschwindigkeit offenbar gut erreicht. Beim Motor mit Kette bleibt die Sollgeschwindigkeit etwas hinter der festgelegten Geschwindigkeit, was ja an der Bremswirkung liegt.

Im Beispiel oben wurde die Geschwindigkeit in PWM angegeben und die Drehzahl vom Encoder in Umdrehungen pro Minute (RPM) abgelesen. Die Verhältnisse sind

Damit könnte man also die geforderte Drehzahl im Bereich -340…​340 mit der Formel einstellen:

und so hoffen, dass sich der Ranger genau mit der angegebenen Geschwindigkeit fortbewegt.

ABER: Die Drehzahl eines unbelasteten Rades alleine sagt ja noch nichts über die Fahrgeschwindigkeit des Roboters aus. Denn diese hängt natürlich auch noch vom Batterieladezustand ab und vom Anstieg und von der Reibung der Kette und und und…​ Deshalb ist es sinnvoller, die Leistung anhand der geforderten Geschwindigkeit einzuregeln. Doch dazu später mehr.

Die MakeBlock-Bibliothek bietet zahlreiche Klassen für die Programmierung von Encoder-Motoren. Für die mitgelieferten DC-Motoren wird die Klasse MeEncoderOnBoard verwendet. Diese übernimmt, wie der Name schon sagt, die Programmierung der auf dem Board befindlichen Motorsteuerung. Diese Klasse erlaubt sowohl die direkte Ansteuerung der Motoren durch Setzen der Leistung via PWM, als auch die geregelte Steuerung.

Die Ansteuerung via setzen der Ziel-PWM ist die einfachste und direkteste Möglichkeit, den Roboter zu steuern. Aber wie oben erwähnt kann man so kaum eine geforderte Fahrgeschwindigkeit bestimmen. Die Klasse MeEncoderOnBoard bietet aber noch eine zweite Variante, wie man die Geschwindigkeit bzw. Motorleistung definieren kann: einen klassischen P-Regler-Ansatz.

Hierbei wird die aktuelle Geschwindigkeit andauernd mit der Sollgeschwindigkeit verglichen. Die Abweichung (der Regelfehler) wird dazu benutzt, um die Leistung/PWM der Motoren solange anzupassen, bis die Ist-Geschwindigkeit der Soll-Geschwindigkeit entspricht und der Regelfehler (nahezu) 0 wird.

In diesem Programm wird die geforderte Geschwindigkeit über die serielle Schnittstelle gelesen. Im SerialPlotter oder SerialMonitor kann man dazu eine 3-stellige Zahl eingeben. In jedem Schleifendurchlauf wird ein neues Zeichen von der seriellen Schnittstelle in einen Pufferspeicher gelesen, bis entweder ein Zeilenendzeichen (\n) folgt, oder das 4. Zeichen gelesen wurde. Dann wird der Text im Pufferspeicher mit einem \0 beendet und in eine Zahl gewandelt. Diese wird dann als Soll-Drehzahl übergeben (in der etwas unzutreffenden Funktion runSpeed(). Der Controller berechnet in der stets aufgerufenen MeEncoderOnBoard::loop()-Funktion den Regelfehler und passt den Duty Cycle (PWM) entsprechend an.

Im Quelltext besteht der wesentliche Unterschied zur ungeregelten Ansteuerung des Motors in der Festlegung der Zielgeschwindigkeit mit der Funktion runSpeed():

Hier wird die Geschwindigkeit in RPM vorgegeben. Für die Berechnung der Korrektur des PWM-Duty-Cycle wird noch der P-Regler-Faktor benötigt. Den setzt man in der setup() Funktion mit setSpeedPid():

In diesem Programmbeispiel kann die Geschwindigkeit direkt als 3-stellige Zahl angegeben werden. Entsprechend ist das Lesen aus der seriellen Schnittstelle etwas komplexer (Zeichenweise erst in einen Puffer, der dann eine abschließende 0 erhält und dann mit der c-Funktion atoi() in eine Zahl gewandelt wird).

Wir testen das wiederum mit verschiedenen Zielgeschwindigkeiten:

Man sieht sehr schön, dass der Regler es eigentlich ganz gut schafft, bei beiden Motoren die geforderten Drehzahlen zu erreichen. Nur in der höchsten Stufe schafft es der Motor mit Kette nicht ganz die geforderte Drehzahl zu erreichen, denn er läuft schon konstant am obersten Limit (Duty Cycle 100%). Aufgrund der unterschiedlichen Reibwiderstände muss der Motor mit der Kette (hellblau) stets einen deutlich höheren Duty Cycle fahren, um die Drehzahl zu erreichen.

Statt nur die Motorgeschwindigkeiten zu kontrollieren, kann man mit der Klasse MeEncoderOnBoard den Land Raider eine bestimmte Strecke fahren lassen. Das Beispiel in der Makeblock-Bibliothek Me_Auriga_encoder_pid_pos.ino zeigt die Verwendung der Klasse moveTo(). Ein weiteres Beispiel Me_Auriga_encoder_callback.ino zeigt eine Variante dieses Aufrufs, bei der bei Erreichen des Endpunktes eine callback-Funktion aufgerufen wird.

Die Idee der moveTo() Funktion ist folgende:

Der I-Parameter wird nicht verwendet.

Die Ansteuerung der Motoren selbst ist direkt über das Setzen des PWM-Duty-Cycles und der Richtungsbits sehr einfach möglich. Um aber eine wirklich kontrollierte Fahrt zu programmieren, muss man die Drehgeschwindigkeit mittels Encodern bestimmen. Dazu werden Interruptfunktionen bentuzt, welche Pulse zählen. Diese können dann in Geschwindigkeiten oder zurückgelegte Entfernungen umgerechnet werden.

Die Klasse MeEncoderOnBoard der Makeblock-Bibliothek bietet mit der Funktion runSpeed() eine P-Regler-kontrollierte Steuerung für die Motorgeschwindigkeit entsprechend einer geforderten Drehzahl. Das ist schon recht bequem. Die Funktion moveTo() der Klasse ist aber nicht so toll und sollte besser durch eine eigene Funktion ersetzt werden.