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 Hindernissen und gesperrten Schleusen) und richten sich zusätzlich zu den Odometriedaten nach den Aruco-Markern aus (= Koppelnavigation). Sie kommunizieren per OPC-UA via WLAN mit den Schleusen, dem Förderband und der Zentrale. Letztere dient nur zum Starten und Anhalten sowie zur Statusanzeige.
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.
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.
Am RaspberryPi4 ist folgendes angeschlossen:
Siehe obsolet. Wurde schließlich alles neu verdrahtet.
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.
Siehe Abschnitt zum Originalcontroller.
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.
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.
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.
Obsolet. Wurde schließlich alles neu verdrahtet, bei beiden Fahrzeugen gleich.
Obsolet. Einblick in den Magic Controller. 230428: Noch immer ist unklar, wie der Geräuschgenerator zielgerichtet programmiert wird.
Siehe Abschnitt zum Originalcontroller. Dieses Fahrzeug diente schließlich als Vorbild für die Gleichschaltung beider Fahrzeuge.
Das Potenziometer ist direkt in einen Freiraum im Knickbereich montiert.
Dadurch wird der Lenkwinkel linear,
ohne Viereckgelenk (wie beim Muldenkipper) 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) Lenksensor ist, kommt hier noch ein
älteres, vorgefundenes
Potenziometer
mit 6-mm-Plastachse und M10-Gewinde zum Einsatz.
Alle anderen Sensoren verwenden
China-Potenziometer,
die kleiner sind und sich als funktionssicherer erwiesen haben.
Deren M7-Gewinde erfordern anders konstruierte Potihalter.
Zu den 3D-Druckteilen kommt ein
Stehbolzen M3×8 IG+AG
als Schraubenverlä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.
Für den Löffel wurde ein System aus Zahnrad und Zahnstange entworfen
und 3D-gedruckt, um platzsparend und arm-unabhängig die Stellung des
Hydraulikzylinders zu erfassen:
Geradezu sensationell dass das auf Anhieb funktioniert.
Der Poti-Halter ist mit einem Kabelbinder am Hydraulikzylinder
befestigt, und etwas Kleber sichert diesen gegen axiale Verschiebung.
Die Schubstange wird eine losen Schraube M2,5×4 gehalten,
wobei das vorhandene Loch in Alu mit einem Gewinde versehen werden muss.
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:
dtoverlay=gpio-shutdown,gpio_pin=5,active_low=1,gpio_pull=up.
dtoverlay=gpio-poweroff,gpiopin=26 (26 ist Standard wenn weggelassen).
Da die USV daraufhin die 5-V-Versorgung kappt,
fällt diese Statusleitung umgehend auf L zurück.
Die Dokumentation zur USV schweigt sich über die Funktion der verwendeten GPIOs weitestgehend aus. Da steht bloß „GPIOx for power management“ drin. Vielleicht:
| Pin | GPIO | Richtung | Name | Nutzung |
|---|---|---|---|---|
| 3 | 2 | SDA | - | I²C für Echtzeituhr DS1307 und Voltmeter |
| 5 | 3 | SCL | - | |
| 29 | 5 | Eingang | SHUTDOWN | ❌ Taste? Funktioniert nicht!
💡 Pin2 des PIC12F508 via 4,7 kΩ |
| 31 | 6 | Eingang | PLD_PIN | ✔️ USV-Speisestatus: H = Batteriebetrieb, L = Netzbetrieb
💡 Pin3 des PIC12F508 |
| 32 | 12 | Eingang | BOOT | ❌Akkuwarnung? Funktioniert nicht!
💡 4,7k an UCC eines '555, 10k an Masse |
| 38 | 20 | Ausgang | BUZZER_PIN | ✔️ Steuerung des (Gleichspannungs-)Piepsers
💡 H = ein via SOT23-Transistor A2L5M |
| 37 | 26 | Ausgang | BUTTON | ✔️ 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:
sudo hwclock --systohc --noadjfile --utc sudo hwclock --set --date "2023/04/26 15:00:00"
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.
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/usbmediumWäre mir lieber wenn das (wie im Desktop) automatisch ginge.
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.
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.
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:
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. Erstaunlicherweise wird das letzte Datenpaket bis zum Sankt Nimmerleinstag wiederholt, selbst wenn man den Controller „gewaltsam“ durch Herausnehmen einer R6-Zelle ausschaltet! (Mit den Einschalttasten 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 Spannungswerten gelten für die Controllerbatterie aus 4 R6-Zellen.
230825: Die Fernbedienung erweist sich als Batterienschlucker:
Anscheinend ist der Standby-Strom nicht klein genug, um gering gegenüber
der Selbstentladung (der R6-Alkali-Zellen) zu liegen.
Außerdem ist es lästig, zum Ausschalten der Fernbedienung
bei eingeschaltetem Fahrzeug eine Zelle kurz herausnehmen zu müssen.
Klar, das ist bei Flugzeugen sinnvoll, für das autonome Auto eher nicht.
Daher wurde der linke Kippschalter SWA zum Einschalter
der Batteriezuleitung umfunktioniert.
Auf der Schalter-Hilfsplatine ist dazu die Verbindung der oberen
Schalterstellung zu brücken.
Um die Hilfsplatine nicht zerstören zu müssen habe ich SWB
mit Drahtstücken verlängert und hochgesetzt auf die Platine gelötet.
Auf dem Gehäuse ist eine entsprechende Beschriftung angebracht.
Die Kanalzuordnung 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:
Siehe auch Mathematik
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 🙈:
- Kein Zugang zur Schaltplan-Quelle.
TODO: Neuerstellung
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!
Siehe Obsolet.
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
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:
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.
Der Zeitplan wurde weit verfehlt, unter anderem durch meine (endlich auch mal) Corona-Erkrankung.
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.
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).
Die neue I²C-Schnittstelle ist schichtenweise aufgebaut und gesondert dokumentiert.
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.
Weil der ATmega keine Schmitt-Trigger-Eingänge hat, ist es am einfachsten, die Schaltung mit 74HC132 mit Einzelgattern nachzubilden. Erfordert eine Leiterplatte!
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.
Eine lange Reihe von Reinfällen führte zu einer sehr, sehr langen Entwicklungszeit von gerade mal 20 Kilobyte Firmware. Mittlerweile obsolet.
Ü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“
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.
Um die Python-Steuerungssoftware (Name unbekannt) und das
TUI-Anzeigeprogramm „fba3“ gleichzeitig
kollisionsfrei zu betreiben
ins der Zugriff auf I²C mit einem prozessübergreifenden
Mutex
gegenseitig abzuriegeln.
Da es unter Linux keinen derartigen 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 Herunterfahren 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! Überprü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 liefert: BSC1 Clock-Stretch-TimeOut ausgeschaltet.
Für die abgeschalteten BSC0 ist der Wert ,
für BSC2 .
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.