Bergwerk-Modell 1:14

Thema: Autonomes Atommüll-Endlager, bestehend aus 1 Förderband, 4 Schleusentoren, 1 Muldenkipper (offenbar ist ein Volvo A60H das Vorbild), 1 Radlader (auch wieder Volvo als Vorbild), 3 exorbitante Schaltschränke mit jeweils anderer SPS, aber mit OPC-UA, die interagieren sollen.

Obsolete Dokumentation wurde aus diesem (inzwischen unübersichtlich lang gewordenen) HTML-Dokument herausextrahiert.

Video vom Parcour: Die Fahrzeuge fahren tatsächlich autonom (nach einem festen Programm mit einigen Verzweigungen bei Hinder­nissen und gesperrten Schleusen) und richten sich zusätz­lich zu den Odometrie­daten nach den Aruco-Markern aus (= Koppelnavigation). Sie kommuni­zieren per OPC-UA via WLAN mit den Schleusen, dem Förder­band und der Zentrale. Letztere dient nur zum Starten und Anhalten sowie zur Status­anzeige.

Fahrzeuge

Thema: 2 Modell-Tagebaufahrzeuge (Radlader und Muldenkipper) mit odometrischer Sensorik ausstatten: Hier Knicklenkung und zusätzlich am Verwindungsgelenk (nur Muldenkipper). Ein typischer Fall für den 3D-Drucker.

Der Raspberry Pi 4 Compute sitzt auf einer Trägerplatine mit RTC, und eine zweite Echtzeituhr befindet sich auf der USV-Platine.

CM4-IO-BASE-B

Muldenkipper

Führerhaus-Einsatz: Fotos und 3D-Modelle

SolidEdge-Quelle. Der Innenaufbau im Führerhaus wurde komplett neu gestaltet: Der Raspberry wurde mitsamt Akkustütze, Tiefsetzsteller, USB/HDMI-Verlängerung und Kamera zu einem Block zusammengesetzt, das im ganzen im Führerhaus versenkt wird. Ohne Klebestellen und ohne Kabelbinder. Die A/D-Wandlerplatine und die PWM-Platine wurden unter die Motorhaube versetzt und der funktionslose Funkempfänger da ausgebaut. So führen nur wenige Kabel aus dem Führerhaus heraus, I²C sei Dank. Dazu sind einige Crimpverbindungen neu gemacht.

Es gibt einen beleuchteten Taster zum Einschalten und geordneten Herunterfahren des Raspberry, durch die Stützakku-Platine gesteuert. Trotzdem liegt die Ruhestromaufnahme des Autos bei 100 mA: Vermutlich frisst der „Magic Controller“ so viel. Das bedeutet, dass man den Fahrakku bei Nichtgebrauch abstecken und besser ausbauen muss.

Der Istwertaufnehmer für die Radumdrehungen besteht aus einer Anzapfung einer der drei Leitungen zum BLDC-Motor und einer geeigneten Filterschaltung mit 74HC2G132 (CMOS-Schmitt-Trigger-NAND) und einigen passiven Bauteilen. Die Schaltungsfunktion wurde mittels Oszilloskop untersucht und optimiert.

Neue Verdrahtung

Am RaspberryPi4 ist folgendes angeschlossen:

Elektro-Archäologie

Siehe obsolet. Wurde schließlich alles neu verdrahtet.

Kollisionserkennung

Rückstoßschalter: Um rückwärts an eine 6 cm hohe Kante heranzufahren und nicht aufzuklettern kommt an die Rückseite ein Antastblech („Stoßstange“) mit Schalter. Das Blech zieht sich über die gesamte Fahrzeugbreite, um auch mal schräg an die Kante heranfahren zu können. Der Schalter schließt das Potenziometer für die Neigung der Ladefläche nach Masse kurz; dann kann eben im Antastfall nicht die Position der Ladefläche gemessen werden. Notfalls fährt man ein paar Millimeter vorwärts. Diesmal etwas für den Wasserstrahl-Zuschnitt und die Kantbank. Nur der Adapterklotz ist ein 3D-Druckteil.

Ultraschall-Entfernungsmessung: Der sattsam bekannte HC-SR04 muss an Stelle des vorher eingebauten A0221AU? das Loch am Kühlergrill der Motorhaube füllen. Futter für den 3D-Drucker.

Entwurf

Untersuchung I-Bus-Kanalzuordnung

Siehe Abschnitt zum Originalcontroller.

Problem mit Ultraschallsensor

Siehe obsolet. Der damals eingesetzte Typ ist durch fehlende Synchronisationsmöglichkeit ohnehin ungeeignet, und es handelt sich letztlich um ein Problem des Raspberry Pi 4: Einführung von Mini-UARTs.

Lagegeber: Lenkung

Gemeinsam für alle 3 Lagegeber: Die Potenziometerachse wird jeweils mit einem Servoarm ausgestattet. Als Verbindungselement dient 2 mm starker Stahldraht. Das sollte für spielarme Winkelübertragung genügen. Natürlich ist das Ganze ziemlich nichtlinear (Gelenkviereck), daher ist das Ganze an mehreren Punkten zu kalibrieren, das gleicht Nichtlinearitäten der Widerstandsbahn ebenfalls aus. Bei der Verwendung logarithmischer Potenziometer nutzt man zweckmäßigerweise den hinteren Stellwinkelbereich mit der steileren Kennlinie.

Fotos und 3D-Modelle

Lagegeber: Lademulde

Foto und 3D-Modelle

Lagegeber: Verwindung

Fotos und 3D-Modelle

Radlader

Beim Radlader ergab sich die Möglichkeit, das Lenkpotenziometer direkt in die Lenkachse zu bauen. Sieht eleganter aus und kommt ohne Gestänge aus, allerdings wird weniger Potenziometerwinkel (70° statt ca. 160°) genutzt.

Schließlich musste doch noch ein Lagegeber für den Hubarm und den Löffel her.

Der Raspberry-Halter wurde diesmal sechsteilig und dafür ohne Stützmaterial gedruckt. Da das Führerhaus von vorn und nicht von oben zugänglich ist, musste komplett umkonstruiert werden. Zudem sind die Abmessungen anders, sodass die Raspberry-Baugruppe und der Tiefsetzer diesmal getrennt voneinander sind und dieser sich unterhalb der Baugruppe befindet. Die beiden WLAN-Antennen sind hier nicht Teil der Baugruppe sondern bleiben wie bisher in die hinteren Fenster eingebaut. Die Scheiben wurden durch dickeres Plexiglas ersetzt.

Raspberry-Halter: Fotos und 3D-Modelle

Neue Verdrahtung

Obsolet. Wurde schließlich alles neu verdrahtet, bei beiden Fahrzeugen gleich.

Licht fehlt?

Obsolet. Einblick in den Magic Controller. 230428: Noch immer ist unklar, wie der Geräuschgenerator zielgerichtet programmiert wird.

Untersuchung I-Bus-Kanalzuordnung

Siehe Abschnitt zum Originalcontroller. Dieses Fahrzeug diente schließlich als Vorbild für die Gleichschaltung beider Fahrzeuge.

Lagegeber: Lenkung

Das Potenzio­meter ist direkt in einen Freiraum im Knick­bereich montiert. Dadurch wird der Lenk­winkel linear, ohne Viereck­gelenk (wie beim Mulden­kipper) gemessen. Der Potihalter wird von zwei Schrauben M2,5×6 gehalten, wobei vorhandene Löcher in Alu mit einem Gewinde versehen werden müssen. Da dies der erste (unveränderte) Lenk­sensor ist, kommt hier noch ein älteres, vorge­fundenes Potenzio­meter mit 6-mm-Plast­achse und M10-Gewinde zum Einsatz. Alle anderen Sensoren verwenden China-Potenzio­meter, die kleiner sind und sich als funktions­sicherer erwiesen haben. Deren M7-Gewinde erfordern anders konstru­ierte Poti­halter.

Lenkwinkelmessung direkt am Knick

Lagegeber: Hubarm

Zu den 3D-Druckteilen kommt ein Stehbolzen M3×8 IG+AG als Schrauben­verlängerung zum Einsatz. (Das Außengewinde wird nicht als solches benutzt, nur als Stift.) Der Potihalter wird von einer Schraube M2,5×6 gehalten, wobei das vorhandene Loch in Alu mit einem Gewinde versehen werden muss.

Hubarm-Winkelmessung

Lagegeber: Löffel

Für den Löffel wurde ein System aus Zahnrad und Zahn­stange entworfen und 3D-gedruckt, um platzsparend und arm-unabhängig die Stellung des Hydraulik­zylinders zu erfassen: Geradezu sensationell dass das auf Anhieb funktioniert. Der Poti-Halter ist mit einem Kabel­binder am Hydraulik­zylinder befestigt, und etwas Kleber sichert diesen gegen axiale Ver­schiebung. Die Schubstange wird eine losen Schraube M2,5×4 gehalten, wobei das vorhandene Loch in Alu mit einem Gewinde versehen werden muss.

Zahnstangengetriebe für Löffel

Beide Fahrzeuge betreffend

Unterbrechungsfreie Stromversorgung für Raspberry Pi 4

Die USV ist anscheinend das hier. Dabei funktioniert der Ein/Aus-Taster nicht wie vorgesehen, es ist nur das Abwürgen des Raspberry durch 7 s Drücken sowie der Start (kurz drücken) möglich. Bananensoftware? Damit die Taste funktioniert, müssen 2 Leitungen zum Raspberry führen:

Die Dokumentation zur USV schweigt sich über die Funktion der verwendeten GPIOs weitestgehend aus. Da steht bloß „GPIOx for power management“ drin. Vielleicht:

GPIO-Zuordnung spekuliert, ✔️geklärt und 💡herausbekommen
PinGPIORichtungNameNutzung
3 2SDA-I²C für Echtzeituhr DS1307 und Voltmeter
5 3SCL-
29 5EingangSHUTDOWN❌ Taste? Funktioniert nicht!
💡 Pin2 des PIC12F508 via 4,7 kΩ
31 6EingangPLD_PIN✔️ USV-Speisestatus: H = Batteriebetrieb, L = Netzbetrieb
💡 Pin3 des PIC12F508
3212EingangBOOT❌Akkuwarnung? Funktioniert nicht!
💡 4,7k an UCC eines '555, 10k an Masse
3820AusgangBUZZER_PIN✔️ Steuerung des (Gleichspannungs-)Piepsers
💡 H = ein via SOT23-Transistor A2L5M
3726AusgangBUTTON✔️ PowerOff-Meldung: Dauer-H = Ausschalten nach 7 s (wenn sicherer Systemzustand erreicht)
💡 H schließt externen und blauen Taster via SOT23-Transistor W1A kurz, was zum Pin 7 des PIC12F508 führt

Eigentlich viel zu viele Leitungen. Der USV-Speisestatus ließe sich über I²C abfragen. Genauso der Alarmzustand der Echtzeituhr und die Taste für den Reboot- oder Shutdown-Request. Mit angepasstem dtoverlay=i2c-poweroff auch noch die PowerOff-Meldung. Ein kleiner Mikrocontroller mit Slave-I²C hätte sich doch sicherlich gefunden, wenn nicht eh' schon drauf (auf der Closed-Source-Platine).

Die USV ist um einen IP5310 (typischer PowerBank-IC) herumgebaut. Weiterhin gibt es einen recht zentralen SO8-Chip ohne Beschriftung, dessen Anschlussbelegung auf PIC12F508 hindeutet. Dieser ist in der Tabelle so benannt.

Echtzeituhr einrichten: Beiträge:

PowerOff-Meldung: Macht der Raspberry bereits, allerdings elend früh. Gelöst durch Deinstallation des mitgelieferten Python-Skripts und Ersatz durch Kernel-Overlay gpio-poweroff.

Mit Taste herunterfahren: Eine Diode von der Taste nach Pin 5, GPIO3, SCL macht die USV kompatibel zu Lösungen, die einen bestromten Raspberry im PowerDown-Zustand starten*. Wie das mit der USV ohne Draht gehen soll habe ich nicht herausgefunden. Irgendwie muss wohl der Raspberry über GPIO5 oder GPIO6 dem PIC12F508 erst 'was mitteilen. Denn sonst ist nix zu sehen, auch keine schmalen Flanken.

Änderungen an der USV

Power-LED geht nicht an: Ein Zeichen für zu wenig Spannung. Von der USV kommen 5,16 V (Batteriebetrieb), 5,26 V (Netzbetrieb mit 230427 aufgedrehter 5,38 V Speisung). Damit ist diese USV für den RPi4 ungeeignet! Liefert zu wenig Spannung, die nicht feinjustiert werden kann. Zudem geht die Echtzeituhr nicht richtig.

Beim Raspberry ohne Maus und Netz USB-Stick einhängen:

sudo mkdir /media/usbmedium
sudo mount -t vfat -o utf8,uid=pi,gid=pi,noatime /dev/sda1 /media/usbmedium
Wäre mir lieber wenn das (wie im Desktop) automatisch ginge.
  1. Die beste Lösung für einen Taster an einem Raspberry ohne USV und mit Netzteil (= unversiegbare Stromquelle). Mit dem Taster an SCL = GPIO3 kann man den Raspberry sowohl herunterfahren als auch wieder starten, und braucht faktisch kein Portpin, weil beim Taste-Drücken der I²C-Bus nicht benötigt wird: Der Vorrang der Taste vor I²C-Busaktivität ist erwartungsgemäß.
    Für den Betrieb an einem Bordnetz (= versiegbare Stromquelle) stört der Stromverbrauch im Schlafmodus, und eine 5V-Abschaltung muss folgen. Hier via H-Pegel an GPIO26. (Zum Einsparen von Portpins ginge das auch via I²C-Slave!) Langes Taste-Drücken zur Zwangsabschaltung muss gesondert implementiert werden.
    Ein hängender, nicht reagierender Raspberry wird ebenfalls durch langes Taste-Drücken „rückgesetzt“; ohne gesonderte Auswertung hilft nur Netzstecker ziehen.
    Eine bevorstehende Zwangsabschaltung durch versiegenden Stützakku muss dem Raspberry entweder gesondert oder via H-Puls an GPIO26 (der Raspberry enthält eine Impuls-Fangschaltung per Portpin) oder via L an SCL (blockiert I²C, am einfachsten) oder via I²C-Slave mitgeteilt werden.
  2. Drei verschiedene Bestellungen derselben USV führt zu 3 verschiedenen Platinen. Offenbar wird da ständig herumgebastelt: Sieht nach Bananenhardware aus.

Toter Lenkservo

Während der Bauma-Messe sind die Lenkservos beider Fahrzeuge ausgefallen. Dass China-Murks nicht ewig hält ist bekannt, aber Ausfall nach nur 1 Woche Benutzung?

Per Nachbestellung ausgetauscht, Fotos und Erkenntnisse siehe da.

Recyceln des Originalcontrollers

Aus heutiger Sicht ist gar nicht nachvollziehbar, warum man den Controller ausgetauscht hatte! Gegenüber dem Microsoft-Modell ist der doch viel zweckmäßiger, mit Display und (vor allem) mit Rückkanal.

Fotos

Weiterhin hat der Empänger 2 Anschlüsse, die mit I-BUS bezeichnet sind: Einen für Sensoren, und einen für Servos. Unter I-Bus oder Ibus versteht man klassischerweise den Draht zwischen Lenkradfernbedienung und Autoradio. Das hier gesuchte ist der FlySky Ibus.

Am Anschluss Sensor kommt alle 4,5 ms (?) ein lückenloses Datenpaket mit 115200-8-n-2 mit 3,3 V Pegel aus den Bytes 0x04,0x81,0x7E,0xFF, und danach sieht man einen kleinen Spannungseinbruch, weil auf Empfangsbetrieb (Tristate) umgeschaltet wird. Die Bytes sollen bedeuten:

An der Fernbedienung ist zunächst nichts davon zu sehen. Man kann aber beim Drauftippen auf die Batteriesymbole für die Remote-Batterie einen Kanal und die Voll/Leer-Werte zuordnen. So bekommt man an der Fernbedienung den Ladezustand der Traktionsbatterie zu sehen, anstatt nur die geregelten 6 V aus dem BLDC-Controllern.
Ein Wunder: Plötzlich erscheint eine Anzeige aller Sensorwerte! Ich weiß weder wie ich dahin gekommen bin noch wie ich da herauskomme.
Geklärt: Eine horizontale Wischgeste schaltet zwischen 3 Ansichten um:

  1. Hauptansicht mit Batteriesymbolen und Ladezuständen, Zugang zum Setup
  2. Ausgabewerte der Steuerhebel, genauer: der 10 Kanäle des FB-Empfängers
  3. Sensorwerte des FB-Empfängers = Rückkanal. Damit lassen sich nun endlich die Potenziometerstellungen in Erfahrung bringen!

Am Anschluss Servo ist nichts zu sehen, bis man den Controller einschaltet. Dann erscheint dort alle 4,5 ms ein lückenloses Datenpaket mit den gleichen Schnittstelleneinstellungen aus vielen Bytes. Es gibt da ein übersichtliches Arduino-Projekt zum Einlesen. Erstaunlicher­weise wird das letzte Daten­paket bis zum Sankt Nimmer­leins­tag wiederholt, selbst wenn man den Controller „gewaltsam“ durch Heraus­nehmen einer R6-Zelle ausschaltet! (Mit den Einschalt­tasten ausschalten geht nicht solange der Empfänger in Betrieb ist.) Dadurch ist keine direkte Totmann-Erkennung per Firmware möglich.

Bei allen 3-poligen Anschlüssen inklusive denen für I-BUS sind 00 (Masse) und 6P (Versorgung 6 V) untereinander verbunden. Die Empfängerbatterieanzeige am Controller (Rückkanal!) zeigt bei 5 V (vom USB) etwa „halben Füllstand“ an, und bei unter 4,5 V beginnt der Controller zu piepen. Ähnliche Anzeigen bei in etwa gleichen Spannungs­werten gelten für die Controller­batterie aus 4 R6-Zellen.

230825: Die Fernbedienung erweist sich als Batterien­schlucker: Anscheinend ist der Standby-Strom nicht klein genug, um gering gegenüber der Selbst­entladung (der R6-Alkali-Zellen) zu liegen. Außerdem ist es lästig, zum Ausschalten der Fern­bedienung bei eingeschaltetem Fahrzeug eine Zelle kurz herausnehmen zu müssen. Klar, das ist bei Flug­zeugen sinnvoll, für das autonome Auto eher nicht. Daher wurde der linke Kippschalter SWA zum Einschalter der Batterie­zuleitung umfunktioniert. Auf der Schalter-Hilfsplatine ist dazu die Verbindung der oberen Schalter­stellung zu brücken. Um die Hilfs­platine nicht zerstören zu müssen habe ich SWB mit Draht­stücken verlängert und hoch­gesetzt auf die Platine gelötet. Auf dem Gehäuse ist eine entsprechende Beschriftung angebracht. Die Kanal­zuordnung wurde so geändert, dass die beiden Drei-Stellungs-Schalter SWB auf Kanal 9 und SWC auf Kanal 10 kommen. SWD bleibt wie er war und bewirkt Vollgas beim Fahren, sonst ist die Amplitude (des linken Hebels vor+zurück) reduziert.
So sieht die Fernbedienung von innen aus:

Und das sind die Bildchen zur Zuordnung (auf das Gehäuse geklebt, wie oft hat man zur falschen Fernbedienung gegriffen?):

Simulation Fahrbetrieb

Simulation Fahrbetrieb

Siehe auch Mathematik

Schaltschränke

Für die Steuerung zweier Schleusen aus je 2 Toren sowie für das Aktivieren des Förderbandes wurde je ein Schaltschrank gebaut, also insgesamt 3, mit jeweils verschiedenen Marken-SPS (Siemens, Beckhoff, B&R) die OPC-UA „sprechen“ können.

Viel umgebaut und fast vergessen. Steht alles unter Obsolet

Die Schaltschränke und Tore 🙈:

„Grapefruit“

Ein Not-Aus-Taster für den Betrieb am Steuerungscomputer (Laptop) wurde in eine gelbe Halbkugel eingedruckt, die mit einem massiven Eisenstangenabschnitt vom Durchmesser 100 mm beschwert wird. Form und Größe erinnert nun an eine halbe Grapefruit (ostdeutsch: Pampelmuse), mit einem roten Knopf drauf. Lädt zum Draufdrücken ein, und das soll es auch!

Fotos und Modelle

CAD-Daten.

Erster Ansatz: Nur Not-Aus

Siehe Obsolet.

Zweiter Ansatz: Inklusive 433-MHz-Gateway

Um im schlimmsten Fall vom Raspberry und/oder der WLAN-Funkstrecke loszukommen dient die Grapefruit als zusätzliche „Netzwerkverbindung“ zu den Fahrzeugen mit max. 100 kBit/s. Nebenanwendung ist die Synchronisation der Fahrzeuge untereinander sowie vielleicht auch der Torsteuerungen, um die Ultraschall-Entfernungsmesser zu entkoppeln. Die Lochrasterplatine wurde entstückt und mit PIC16LF1454 sowie einem RFM69-Funkmodul versehen. Da das Funkmodul mit 3,3 V arbeitet, dient ein Längsregler zur Stromversorgung sowohl des Funkmoduls als auch des Mikrocontrollers. Der LD59015 wurde einem Messemuster-Karton entnommen und „musste mal weg“. Der Aufdruck „596“ ist tatsächlich der für 3,3 V. Da der RFM69 genügend (64 Byte) FIFO hat, hat der Mikrocontroller nicht allzu viel zu tun.
TODO: Aufbau, Firmware, Erprobung, WebUSB-Äpp

Fernbedien-Adapter

Um doch wieder zur originalen Fernbedienung zurückzukehren und dabei eine vernünftige Autonomie vom Raspberry zu haben, ist eine weitere Controller-Platine vonnöten, die folgende Aufgaben erledigt:

Schaltplan, Layout, Fotos

Auch bei einer Leiterplatte bleibe ich beim Durchsteck-Mikrocontroller in Fassung, damit dieser bei Defekt schnell gewechselt werden kann. Auch der CD4017 ist ein Durchsteck-Typ in Fassung, aus dem gleichen Grund. Letztere Fassung darf einen eingebauten Kondensator von Pin 8 nach Pin 16 enthalten. Das Funkmodul RFM69 hat plan bestückt keinen Platz auf der Platine, und statt nach einem Steckverbinder im 2-mm-Raster Ausschau zu halten wurde die erprobte 2,54-mm-Verbindung weiter genutzt. Der neue Verdrahtungsplan macht die beiden vorgefundenen Schaltpläne obsolet. Da eine Wired-And-Verknüpfung von Not-Aus wichtiger erscheint als absolute Betriebssicherheit (denn der Mikrocontroller muss per Software die Motoren stoppen und Servos zurückfahren, bevor kein PWM-Signal ausgegeben wird; sofortiges Abschalten der PWM lässt die Motoren noch merklich nachlaufen) wurde der Schließ­kontakt verwendet.

Firmware und Details

Im Innern rechnet die Firmware mit handlichen ±125 „per125“ für die Servostellungen. Das passt bequem in ein signed char. Der Wert -128 beschreibt cNaN als „nicht vorhanden“. Alle anderen Werte außerhalb ±125 werden auf ±125 heruntergebrochen.

Den Mix-Betrieb für die Hydraulikpumpe realisiert die Firmware. Dazu muss die übergeordnete Software echte Hydraulikventilstellungen übergeben.

Takterzeugung

Wird von einem Baudratenquarz bereitgestellt. Nur damit läuft's stabil in gestörter Umgebung. Daraus werden exakte 50 Hz als Zeitbasis abgeleitet.

Der ursprüngliche Ansatz mit dem 32-KHz-Uhrenquarz und der (damit möglichen) Echtzeituhr war ein Zeit fressender Irrweg. Zumal die USV eine Echtzeituhr beinhaltet (später herausbekommen).

Plugin-Kompatibilität: Entfällt

Die neue I²C-Schnittstelle ist schichtenweise aufgebaut und gesondert dokumentiert.

Software-UART an PD1: Entfällt

Wie dort ausgeschnüffelt kommen IBUS-Servodaten und IBUS-Sensoranforderung nie gleichzeitig. Statt einer Verknüpfung mit einem UND-Gatter tut es eine mit Widerstand und Schottky-Diode.

Protokoll am IBUS-Sensor

Tiefpass für Drehimpuls

Weil der ATmega keine Schmitt-Trigger-Eingänge hat, ist es am einfachsten, die Schaltung mit 74HC132 mit Einzelgattern nachzubilden. Erfordert eine Leiterplatte!

Ultraschall-Entfernungsmessung

Siehe auch: Umfangreiche Voruntersuchung zum HC-SR04 bezüglich Empfang-ohne-Senden.

Zur Kollisionsvermeidung steht im Pflichtenheft irgendein Detektor, wobei hier ein dem HC-SR04 vergleichbares vergossenes Etwas verbaut wurde. Hauptproblem ist, dass dieser mit den gleichen Sensoren an den Durchfahrten kollidiert! In beide Richtungen! Eine Synchronisation ist zwingend erforderlich. Daher nimmt der Mikrocontroller das Senden und Empfangen komplett selbst in die Hand:

Dazu muss der vergossene Entfernungsmesser durch einen schnöden (und billigen) HC-SR04 ersetzt werden, von dem der Mikrocontroller zu entfernen ist. Das erscheint an Bastelaufwand ausreichend. Hübscher wäre noch das Zusammenlegen der Hör- und Sprechkapsel mittels Analogsignalschalter.

Vorgesehen sind nun 3 „freie“ Leitungen vom Mikrocontroller, wobei die Empfangsleitung mit dem Hardware-Capture-Feature zusammenarbeitet, was hochpräzise Zeiten auch unter Interruptlast liefert.

Teufels Küche

Eine lange Reihe von Reinfällen führte zu einer sehr, sehr langen Entwicklungszeit von gerade mal 20 Kilobyte Firmware. Mittlerweile obsolet.

Hydraulikregler ohne PID

Überlegungen, den schwingungsanfälligen Hydraulikregler anders zu realisieren. Ziele:

Schlüssel zum Ganzen ist die Übergabe von Restweg (Regelabweichung) s und Momentangeschwindigkeit v an den „Regler“. Die Berechnung der nächsten Hydraulikventilstellung erfolgt genauso wie bei einem Schrittmotor!

auto accel = [&](){v+=abeschl; if (v>vmax) v=vmax;};
auto brems = [&](){v-=abrems; if (v<0) v=0;};
auto toofast=[&](){return s < v²/2/abrems;};
if (s<=0) goto fertig;
if (toofast()) brems();
else switch (v<=>vmax) {
 case LT: accel(); if (toofast()) brems();
 case GT: brems(); // kann nur passieren wenn sich zwischendurch vmax ändert
}
// Für Schrittmotoren käme jetzt „s-=v“

Anlernkurve

Typischer Verlauf der Hydraulikventilsteuerung

Ausfallsicherer Servomotor

Das Problem mit den „Kohlebürsten ohne Kohle“ der Gleichstrommotoren in den Servos lässt sich nur durch Ersatz mit bürstenlosen Motoren erledigen. Mir würde am ehesten Schrittmotoren vorschweben, die in der nächsten Fahrzeuggeneration von einem STM32F4-Hauptcontroller via Stall-Guard-Treiber (Vorbild: Prusa-3D-Drucker) angesteuert werden. Bei (dreiphasigen) BLDC-Motoren bin ich absolut nicht fündig geworden. Der eingebaute Motor hat folgende mechanischen Daten:

Alles sieht nach einer Maßanfertigung oder Maßanpassung aus. Als Ausgangspunkt könnte ein Exemplar dienen, welches als Typ „20BY20Y“ bei Ebay zu finden ist. Der Achsdurchmesser stimmt, das Zahnrad müsste gewechselt werden. Für den zu dicken Korpus müsste das Servogehäuse aufgefräst werden, der Servo ist insgesamt 20 mm dick, für den 20 mm dicken Motor gerade passen. Vorversuche müssen unternommen werden, ob Drehzahl und Drehmoment für die Hydraulikventile ausreichen.

Bei Modell-Fahrzeugneubau würde ich auf Echt-Hydraulik verzichten und Hydraulikzylinder durch getarnte Schneckentriebe realisieren, dazu Getriebe-Schrittmotoren verwenden und ggf. Tachowellen zu den Schneckentrieben führen.

Teamwork

Um die Python-Steuerungs­software (Name unbekannt) und das TUI-Anzeige­programm „fba3“ gleich­zeitig kollisions­frei zu betreiben ins der Zugriff auf I²C mit einem prozess­über­greifenden Mutex gegen­seitig abzuriegeln. Da es unter Linux keinen der­artigen Mutex gibt, nimmt man dafür ein Semaphor. In C++ 🦎 geht das mit -pthread beim Linker-Aufruf und:

#include <semaphore.h>
 char semname[32];
 snprintf(semname,sizeof semname,"i2c%u.%02x",i2cbus,i2cslave)
 sem = sem_open(semname,O_CREAT,0660,1);	// Startzähler: 1
 sem_timedwait(sem,&tv);// Mutex belegen - und dabei nicht ewig warten (<tv> entsprechend vorberechnet)
 sem_post(sem);		// Mutex freigeben
//close(sem);		// gibt's nicht. <sem> ist kein Win32-Objekt
 sem_unlink(semname);	// bei Programmende oder Wechsel von I²C-Bus oder I²C-Adresse

Der (oder das?) Semaphor (oder die Semaphore?) befindet sich im Shared Memory, wird beim Herunter­fahren automatisch beseitigt, und ist unter "/dev/shm/sem.i2c1.5d" abgebildet. 🇨🇿 Tschechen wissen was ein Semafor ist: Eine 🚦 Ampel. Damit es auf der Kreuzung nicht kracht.

Für Python 🐍 muss man pip install posix-ipc installieren, und dann etwa so:

import posix_ipc
 sem = Semaphore("i2c1.5d",O_CREAT,0o660,1)	# Startzähler: 1
 sem.acquire()		# Mutex belegen
 sem.release()		# Mutex freigeben
 sem.close()
 sem.unlink()		# bei Programmende oder Wechsel von I²C-Bus oder I²C-Adresse

Der Semaphor-Name zwischen C++ und Python muss gleich sein! Über­prüfen kann man das durch ls -l /dev/shm: Da darf, während beide Programme laufen, nur eine Datei drin sein.

Oh 🎇 Wunder: Beim Versuch mit einer Hardwarelösung für das Clock-Stretch-Problem haben sich alle Probleme mit I²C in Luft aufgelöst, ohne dass ich weiß wie das zustande kam. Keine CRC-Fehler, kein blockierter Bus, keine Spikes, kein Fehler-Zähler der hochläuft. Oszillogramme wie aus dem Lehrbuch, ganz gleichmäßig getaktet. Einzig und allein Lese- und Schreibzugriffe sind bei errno==121 zu wiederholen. War früher schon so. Interessant ist, dass es in der config.txt nunmehr keinen Eintrag gibt, der irgendeinen i2c*-Treiber explizit lädt. Und dass sudo busybox devmem 0x3F80401C eine Null liefert: BSC1 Clock-Stretch-TimeOut ausgeschaltet. Für die abgeschalteten BSC0 ist der Wert 0x200, für BSC2 0x100.

Mit dem Kommandozeilen-Programm „fba2“ steht ein einfaches Hilfsmittel zur Manipulation von Einzelbytes zur Verfügung. Was eigentlich in „fba3“ in komfortablerer Weise (Hex-Editor) eingebaut werden sollte. Damit kann man das I²C-Interface „nackt“ benutzen und v.a. Reglerwerte einstellen.