Automationssoftware - Aufbau und Programmieren von Robotern

Guten Morgen,

vielleicht bekomme ich hier im Thread ein paar nützliche Hinweise, wie weit man zum heutigen Zeitpunkt im Thema ist, was sich
außerhalb meiner jetzigen Sicht bewegt.

Ich will mich Beispielen anfangen (um das Kopfkino etwas anzukurbeln), die an anderer Stelle schon mal geschrieben wurden: Fischertechnik, Lego

Im Roboternetz habe ich aus vergangenen Zeiten Ansätze gefunden, wo was mit Hochsprachen unter Windows versucht wurde.
Allerdings enden alle angefangenen Sachen diesbezüglich immer unvollendet. Mal von der Strukturierung der Sachen abgesehen.

Heute habe ich einen Thread aus der Vergangenheit gefunden, wie es so ist, schon wieder weggeklickt :)
Der geht in die Richtung. Hirarchischer Aufbau und Programmierung, war aber nur angerissen, mit wenigen Beiträgen.

Immer wieder mal kam dann ROS auf, habe ich kurz gelesen, damit bin ich aber nicht weit genug vorgedrungen, weil mir das
etwas unbrauchbar für Mikrokontroller erscheint, ich kenne aber auch den Umfang nicht, also was man damit genau alles machen könnte.

Als ich hier im Forum einstieg, hatte HaWe mir tatkräftig die Arduinos nahe gebracht. Da bin ich noch hängen geblieben, weil die ATmegas
viel Potential haben, von dem ich überzeugt bin, dass es für die meisten Problemstellungen ausreichend ist. Ich beobachte, dass die meisten Leute,
wenn sie irgendwo an eine Grenze stoßen, zu einem größeren "System" - Kontroller mit mehr Leistung und mehr Anschlüssen - greifen.
ATmega2560, Raspberry Pi, ESP32 usw. Man versucht mit einem System alles zu erschlagen.
Programmiert wird immer beispielsweise in C oder viel auch mit der Arduino IDE.

Wenn ich Robotik größer betrachte, als nur einen Mikrokontroller einzusetzen, komme ich zwangsläufig zu hirarchischen Systemen.
Das halte ich auch für die beste Struktur generell. Auch in anderen Bereichen bewähren sich modulare Strukturen. Ich habe aber hier im Roboternetz
so etwas bis jetzt noch nicht gefunden. Programmierung, Elektronik etc. - sonst alles vorhanden.

Aufgabenteilung, zerlegen in Teilprobleme, diese miteinander verknüpfen und an der Oberfläche mit einer von außen programmierbaren Struktur versehen:
halte ich für die sinnvollste Strategie und wird im Industrieroboterbereich sicher so gemacht (auch wenn ich darüber noch nicht all zu viel gelesen habe).
Software für Industrierobotik ist wohl aber etwas oversized für kleinere Projekte, mal von Preisen abgesehen und von benötigten Platformen, wie Linux bspw.


Was mache ich zurzeit?
Selber arbeite ich mich zurzeit voran, einen voll funktionsfähigen Roboter zu bauen. Wobei für mich der Weg das Ziel ist. Also Ende offen. Mich interessieren realisierbare Strukturen.
Dabei bin ich immer noch von regelbasierten Lernstrukturen überzeugt. Sie liefern eine genaue planbare Reproduktion von "Verhalten". Diese kann man mit anderen
Sachen aus der KI kombinieren. Also komme ich vom Konzept mit einem Kontroller, zu einem mit mehreren, ich komme zu einem modularen Aufbau, wo man
am Ende eine Programmierung draufsetzen kann. Die Module werden als geschlossene Einheiten betrachtet, sie werden in sich vollendet und bieten einen Funktionsumfang
der weiter genutzt werden kann. Dadurch wird ein Kontroller mit einer Firmware versehen, die praktisch dann unverändert bleibt. Die eigentliche Problemlösung, also
die Programmierung findet dann übergeordnet statt.


Um es mit der Maus zu sagen:
Das war: Ungarisch

Nein! - Brainstorming, mehr oder weniger und zur Diskussion freigegeben ;)




Freundlichen Gruß
Moppi

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.

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.

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

Danke HaWe für deine Lösung!