Automationssoftware - Aufbau und Programmieren von Robotern

HaWe · 19.06.2020, 10:17

Wenn man hinreichend leistungsstarke Prozessorboards hat, reicht durchaus ein einziges Board.
Und letztlich muss ja 1 die Zügel in der Hand haben, um die Daten aus den untergeordneten "Modulen" zu sichten, zu ordnen und auszuwerten, und das sollte dann eigentlich schon auch eines der leitungsfähigsten sein (Takt, Speicher, Multithreading-fähig).
Man kann ntl jederzeit überall mit weiteren Boards oder ICs über verschiedenste Bussysteme (UART, i2c, SPI, CAN) kommunizieren:
aber z.B. einem Programm-"Modul" in einem pthread oder subsumption-Behaviour ist es egal, ob es die Sensordaten direkt von onboard-Sensoren oder von vorprogrammierten remote-Clients erhält.

Aber je mehr Clients (Multi-Boards), mit denen kommuniziert werden muss, desto komplizierter wird es im Vergleich zum Single-Board.

Ich sehe für modulare Architekturen 3 praktikable Wege, Multithreading ist dabei essentiell ("Modul" verstanden als funktionelle Einheit, z.B. ein Sensor-Modul, ein Kalkulationsmodul oder ein Motorsteuerungsmodul):

a) Subsumption-Architektur: hier verdrängen Funktionen ("Behaviours") mit hoher Prio solche mit hierarchisch niedriger Prio (googeln!). Prinzipiell beruht es auf (zumindest kooperativem) Multithreading.
Vorteile: es können jederzeit neue Sensor- oder Behaviour-"Module" eingefügt werden, und es läuft auch auf sehr einfachen, langsamen Systemen wie Interpreter-Frameworks (zB. NQC oder Java etc. auf Lego Mindstorms RCX oder NXT). Auch auf dem Arduino Due mit dem kooperativen Scheduler MT geht das natürlich.
Nachteil: läuft auf langsamen Systemen ein wenig holprig und ist so nicht echtzeitfähig.
Beispiel: https://github.com/dsyleixa/Mindstor...enmaeher-6.nqc
https://www.youtube.com/watch?v=lNLPejeS-_Y
http://www.youtube.com/watch?v=z7mqnaU_9A8
hier sieht man, welche Behaviours (z.B. "Ausweichen" oder "Wenden") welche anderen (z.B."Cruise" oder "Ausweichen") hierarchisch verdrängen:

Code:

int MotorCommand;
task arbitrate ()
{         // Hier werden die Behaviour-Prioritäten festgelegt!
    while(true) {
       if (vCruise != CommNone)       MotorCommand = vCruise;    // niedrigste Prio
       if (vAusweichen != CommNone)   MotorCommand = vAusweichen;
       if (vWenden != CommNone)       MotorCommand = vWenden;
       if (vRueckAbbr != CommNone)    MotorCommand = vRueckAbbr;
       if (vNotStop != CommNone)      MotorCommand = vNotStop;   // höchste Prio
       MotorControl ();     // MotorCommand erhält seinen Wert Event-gesteuert vom entsprechenden Task
   }                        // MotorControl übernimmt dann die einfachsten Motorbefehle
}

b) preemptives (!) Multithreading auf schnellen single- (SAMD51, Rpi Zero) - oder multicores (ESP32, Rpi ab 2B), mit pthreads, thread prios und mutexes.
Wie bei der Subsumption mit kooperativem MT können dann aus den parallel ermittelten Daten optional die hierarchisch organisierten Verhaltensweisen generiert werden, wieder in einer unabhängig laufenden pthread Funktion. Anderes als bei kooperativem MT können jetzt einzelne threads keine anderen blockieren, dadurch kann das Programm in Echtzeit reagieren.
Es können auch hier jederzeit neue "Module" in Form zusätzlicher pthreads hinzugefügt werden.
Vorteile: schnell, parallelisierbar, priorisierbar und skalierbar, kompatibel auch zu C++ GUI Frameworks wie z.B. qt oder openCV.

c) modulare Systeme z.B. wie ROS auf rechenstarken Computern (Windows-PC, Rpi 3B+, 4). Hier übernimmt das ROS die Verwaltung und das threading aller Module.
Vorteile: viele fertige Module verfügbar.
Nachteil: IMO großer Installations- und Programmier-Overhead.

**Holomino** · 21.06.2020, 17:29

Keine Ahnung, wie andere das machen.
Ich habe mir einen kleinen 3€-ATXMega mit 5xUART und 2xI2C genommen und ein serielles HC-06 BT-Modul (kleinster gemeinsamer Nenner für PC, Tablet, Smartphone, Raspberry) draufgebaut.
Odometrie, Motorregelung und Posenberechnung laufen direkt auf dem ATXMega. Der Rest der Daten (Power, Sensoren) kommt von anderen Platinen oder Bausteinen über UART oder I2C und wird entweder direkt ans BT-Modul weitergereicht oder z.B. mit der aktuellen Pose verknüpft und dann ausgegeben.

Letztlich braucht es dann auf dem Rechner nur noch eine Bluetoothschnittstelle und eine an die Firmware angepasste API. Welcher Rechner früher oder später dann auf dem Vehikel selber landet, so dass der Roboter auch ohne externe Datenanbindung agieren kann, ist schlussendlich nur noch eine Frage des Powermanagement. Ein RPI ZeroW nimmt headless etwa 250mA, ein BPI M2 Zero mit 4 Kernen, aber noch im gleichen Formfaktor, liegt bei 400mA (das sind bei mir schon 40% des Gesamtverbrauches).
Alternativ könnte man sich auch mit einem Teensy herumquälen, wenn man aber auf den Einsatz von Kamera, Bildschirmein/-ausgabe (Remotedesktop über Wifi) und Web-Interface spekuliert, lohnt sich wohl der Einsatz von 50% teurerer Hardware mit nominal weniger Ressourcen nicht wirklich.

**Moppi** · 16.08.2020, 18:16

Ich hatte nun eine lange Pause, um drüber nachzudenken. Dabei habe ich meine alten Lösungen überdacht und geschaut, ob ich ähnliche Strukturen auch gerade für ATmegas mit wenig Speicher und geringer Geschwindigkeit (bis 20MHz) umsetzen kann. Angefangen habe ich bereits, allerdings nur als Gerüst. Die Idee ist eine Klasse, die das abhandeln soll. Die Programmsteuerung soll dann über eine Art Microcode geschehen, der zur Laufzeit von einem schnellen Host verteilt wird, was bei mir jetzt aktuell ein ESP-12E wäre. Der hätte auch ordentlich Speicher, um jede Menge Microcode-Pakete zu speichern, evtl. auch auf SD-Karte.
Insofern das brauchbar funktioniert, ist der Vorteil, dass meine ATmegas und auch der ESP nur noch per Arduino-IDE programmiert werden müssen, wenn sich die meine Firmware ändert. Die eigentliche Programmierung, der Datenauswertung und daraus folgende Aktionen, könnten per WLAN im laufenden Betrieb erfolgen. Austauschbarer Code zur Laufzeit gäbe jede Menge Flexibilität.
Allerdings glaube ich, dass die im System verfügbare Datenübertragungsrate zu gering sein wird, um was Brauchbares zu realisieren. Aber das muss ich erst einmal sehen.

MfG