MIRO ist eine offene Indoor-Roboterplattform. Teil 4 - Softwarekomponente: ARDUINO (AVR)

Wir bauen die Softwarekomponente der MIRO-Plattform weiter auseinander. Ich möchte die Software unter AVR genauer untersuchen. Aus diesem Grund werden wir dem Thema zwei Teile widmen. In der ersten beschreiben wir die allgemeine Struktur der Bibliothek und in der zweiten die Implementierung einiger Schlüsselklassenmethoden.

Inhaltsverzeichnis: Teil 1 , Teil 2 , Teil 3 , Teil 4 , Teil 5 .

Die Software für ARDUINO war die größte der selbstgeschriebenen. Im Allgemeinen liegt fast die gesamte Logik der direkten Arbeit mit Aktuatoren und Sensoren des Roboters beim AVR. Und auf dieser Ebene wird API implementiert - eine schnelle Entwicklungssoftware für MIRO.

Die API-Struktur ist im Wiki-Abschnitt des entsprechenden Repositorys beschrieben . Bisher nur in russischer Sprache. Und jetzt werden wir den Code genauer analysieren. Ich werde nicht absichtlich vollständige Klassendeklarationen abgeben, sondern sie mit den Auslassungspunkten "..." abkürzen, sodass nur die im Moment wichtigen Dinge übrig bleiben.

In unserem Softwaremodell besteht jeder MIRO-Roboter aus einem Chassis und einer Reihe verbundener Geräte. Bei der Konstruktion wurde davon ausgegangen, dass das Roboterfahrwerk - es wird immer ein Fahrwerk auf Rädern sein - Laufroboter oder Roboter, die andere Bewegungsprinzipien verwenden, separat betrachtet werden sollten.

class Miro : public Robot { public: Miro(byte *PWM_pins, byte *DIR_pins); #if defined(ENCODERS_ON) Miro(byte *PWM_pins, byte *DIR_pins, byte *ENCODER_pins); #endif ~Miro(); ... }; 

Die Miro-Klasse ist eine Klasse der obersten Ebene und beschreibt die vollständige Konfiguration des Roboters. Diese Klasse ist der Nachfolger der Roboterklasse, die nur die grundlegendsten Funktionen des Roboters beschreibt.

 class Robot { public: Robot(byte *PWM_pins, byte *DIR_pins); #if defined(ENCODERS_ON) Robot(byte *PWM_pins, byte *DIR_pins, byte *ENCODER_pins); #endif ~Robot(); Chassis chassis; void Sync(); int attachDevice(Device *dev); int dettachDevice(Device *dev); ... protected: Device* _devices[ROBOT_MAX_DEVICES]; byte _device_count; }; 

Der Designer führt die Ersteinrichtung der Chassis-Pins und die Anfangswerte der Roboterkonfiguration durch.

Die Sync () -Methode implementiert die erforderlichen Operationen für das Chassis und für alle an den Roboter angeschlossenen Geräte in jedem Schritt des Hauptschleifenzyklus () der ARDUINO-Skizze. Die Miro Sync () -Methoden der Miro-Klasse rufen die entsprechenden Sync () -Methoden des Gehäuses und aller mit dem Roboter verbundenen Geräte auf.

Die Robot-Klasse enthält auch einen Zeiger auf ein Array von Geräten, die mit dem Roboter verbunden sind, sowie Methoden zum Arbeiten mit diesem Array (ein neues Gerät verbinden, trennen, nach Index und Name suchen). Die Roboterklasse enthält auch ein Objekt der Chassis-Klasse - das Chassis.

Aber fangen wir mit etwas Einfacherem an - mit Geräten. Jedes Gerät, das mit dem Roboter verbunden werden kann, sei es eine LED, ein Sensor oder ein Aktor, der nicht direkt mit dem Chassis (Wagen) zusammenhängt, wird durch seine Nachfolgerklasse beschrieben, die für alle Geräte in der virtuellen Geräteklasse gilt:

 class Device { public: virtual void Sync(); virtual void setParam(byte pnum, byte *pvalue); virtual void getParam(byte pnum, byte *pvalue); virtual byte getPinsCount(); virtual char* getName(); virtual byte getParamCount(); protected: byte *pins[2]; }; 

Die virtuellen Methoden setParam, getParam, getParamCount sind mit dem Zuweisen, Empfangen und Bestimmen der Anzahl der Geräteparameter verbunden. Der Parameter kann eine beliebige Eigenschaft sein: die Helligkeit der LED, die Position des Servoverstärkers usw. Die Nachfolgerklasse jedes Geräts implementiert diese Methoden auf ihre eigene Weise. Der Zweck der getName- und getPinsCount-Methoden ergibt sich meines Erachtens aus dem Namen. Die neu entdeckte Sync-Methode ist eine spezielle Methode zur blockierungsfreien Gerätesteuerung und -automatisierung einiger Gerätevorgänge, die regelmäßig bei jeder Iteration der Hauptschleife ausgeführt werden müssen.

Betrachten wir nun eine mehr oder weniger allgemeine Implementierung der abgeleiteten Klasse.

 class MIROUsonic : virtual public Device { public: void Sync(); void setParam(byte bnum, byte *pvalue); void getParam(byte bnum, byte *pvalue); byte getPinsCount(); char* getName(); byte getParamCount(); void Init(byte trig_pin, byte echo_pin); void On(unsigned int max_dist); void On(); void Off(); int getDist(unsigned int max_dist); unsigned int getMesCount(); private: bool _isOn; unsigned int _mesCount; unsigned int _dist; unsigned int _max_dist; }; 

Bei der Bestimmung der Klasse eines Ultraschall-Entfernungsmessers (oben) gibt es neben den Methoden des Elternteils auch Methoden:

• Init - Initialisierung;
• Ein und Aus - Gerät einschalten (Entfernungsmesser);
• getDist - gibt die vom Entfernungsmesser gemessene Entfernung zurück;
• getMesCount - gibt die Anzahl der Messungen zurück, die seit dem Einschalten des Geräts durchgeführt wurden.

Um den internen Status des Geräts zu speichern, werden die folgenden Felder verwendet:

• _isOn (TRUE - das Gerät ist eingeschaltet, gesteuert durch die Methoden On und Off);
• _mesCount (speichert die Anzahl der Dimensionen, die in der getMesCount-Methode verwendet werden);
• _max_dist - maximal benötigter Abstand zur Messung *;
• _dist ist die tatsächlich gemessene Entfernung.

Und nun zur Erläuterung der Sync-Methode. Wenn das Gerät den Status _isOn == TRUE (on) hat, wird der Messzyklus selbst mit der Methode Sync ausgeführt und das Messergebnis im Feld _dist aufgezeichnet. In diesem Fall gibt die Methode beim Aufruf von getDist sofort den in _dist aufgezeichneten Wert zurück, es findet kein Messzyklus statt. Wenn _isOn == FALSE (off) ist, wird der Messzyklus im Gegensatz dazu nur während des Aufrufs von getDist ausgeführt. In der Sync-Methode wird nichts gemessen. Es wird davon ausgegangen, dass der Programmierer die Sync-Methode des gesamten Roboters aufruft, die wiederum die gleichnamigen Sync-Methoden aller mit dem Roboter verbundenen Geräte und eines Objekts der Chassis-Klasse (Chassis) aufruft.

Von den Geräten in der API sind nur die Dinge implementiert, die MIRO jetzt hat: LED, Ultraschall-Entfernungsmesser, Lichtsensor mit Fotowiderstand, Servoantrieb, Zeilensensor.

Das Chassis leicht berühren. Diese Klasse implementiert den "abstrakten Wagen" des Roboters. Es enthält Methoden, mit denen Sie Mover steuern können.

 class Chassis { public: Chassis(byte *PWM_pins, byte *DIR_pins); #if defined(ENCODERS_ON) Chassis(byte *PWM_pins, byte *DIR_pins, byte *ENCODER_pins); #endif ~Chassis(); void Sync(); float getVoltage(); int wheelRotatePWMTime(int *speedPWM, unsigned long time); int wheelRotatePWM(int *speedPWM); bool wheelIsMoving(byte wheel) {return this->_wheel_move[wheel];} byte getWheelCount() { return WHEEL_COUNT; } #if defined(ENCODERS_ON) int wheelRotateAng(float *speed, float *ang, bool en_break); unsigned long wheelGetEncoder(byte wheel); ... #endif //ENCODERS_ON private: float _vbat; //Battery volgage bool _wheel_move[WHEEL_COUNT]; char _wheelDir[WHEEL_COUNT]; byte _wheel_PWM_pins[WHEEL_COUNT]; byte _wheel_DIR_pins[WHEEL_COUNT]; void _init(byte *PWM_pins, byte *DIR_pins); #if defined(ENCODERS_ON) byte _wheel_ENCODER_pins[WHEEL_COUNT]; bool _wheel_sync_move; float _wheelAngSpeed[WHEEL_COUNT]; float _wheelSetAng[WHEEL_COUNT]; float _wheelSetAngSpeed[WHEEL_COUNT]; ... #endif //ENCODERS_ON }; 

Betrachten wir einen Wagen ohne Geber und in der Regel ohne Rückmeldung, so gibt es hierfür einfache Steuermethoden mit einem PWM-Signal. Wenn sich Encoder im Wagen befinden, wird die Klasse viel komplizierter. Um das Leben des Benutzers zu vereinfachen, erscheinen darin Methoden wie:

• wheelRotateAng - Raddrehung bei vorgegebenen Drehwinkeln mit vorgegebenen Winkelgeschwindigkeiten;
• wheelGetPath - gibt die Länge des von jedem Rad zurückgelegten Pfades zurück;
• wheelGetLinSpeed ​​- gibt die aktuelle lineare Geschwindigkeit jedes Rads zurück;
• wheelGetAngSpeed ​​- Gibt die aktuelle Winkelgeschwindigkeit jedes Rads zurück.
• wheelGetEncoder - gibt die Anzahl der Antworten der Encoder jedes Rads zurück.

Und eine Reihe von Hilfsmethoden. Sowie eine Antriebskalibrierungsmethode. Im Detail werden die wichtigsten Methoden der Chassis-Klasse das nächste Mal betrachtet.

Mit Blick auf die Zukunft ist an dieser Stelle anzumerken, dass diese gesamte Miro-Bibliothek leicht mit jedem anderen Roboter mit einem zweirädrigen Differenzialbewegungsschema angepasst oder ergänzt werden kann. Und mit einem gewissen Aufwand - und zu anderen Antriebs- und Lenkkonfigurationen. Im Falle einer Differentialschaltung müssen Sie nur die Konfigurationsdatei config.h korrekt beschreiben. Und ohne RPi. Zum Beispiel haben wir in weniger als einer Stunde für unser regionales BlackMirrorCTF-2019-Cybersicherheitsturnier an unserer Universität alles über solche Kleinen ins Leben gerufen ( Link ).



Die Roboter hatten eine Schnittstelle für den Zugriff über TELNET und ein Befehlssystem zur Fernsteuerung. Das Dokument mit dem Befehlssystem war irgendwo versteckt oder verschlüsselt. Die Teilnehmer haben die IP-Adressen gescannt und die Ports auf den Robotern selbst geöffnet. Bei einer erfolgreichen Verbindung gaben die Roboter eine Einladung heraus und die Teilnehmer verstanden, dass sie "eingetreten" waren. Nun, dann brachten die Teams die Roboter entlang der Autobahn zur Ziellinie. Ursprünglich wollten sie die gesamte Strecke mit Robotern irgendwo in einem isolierten Raum mit installierter IP-Kamera machen, aber die Organisatoren hatten einige Probleme mit der IP-Kamera und verloren etwas an Charme.


Das ist alles für jetzt. Es ist möglich, dass sich das Programmmodell im Laufe der Entwicklung ändert. Übrigens, es wurde kürzlich leicht modifiziert, nachdem der Code etwas erfahrener aussah als OOP-shchik.

Vor dem fünften Teil - lassen Sie uns über Encoder, Winkel und Kalibrierungen sprechen.