Bergwerk-Modell 1:14

Am RaspberryPi4 ist folgendes angeschlossen:

• Unterbrechungsfreie Stromversorgung mit 2 LiIon-Standardakkus
• Spannungsregler vom Fahrakku
• Kamera am Kamera-Port via Flachkabel
• WLAN-Daughterboard auf Rückseite mit 2 Antennen
• Micro-SD-Karte

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.

Draufsicht
Seitenansicht 1
Seitenansicht 2
Seitenansicht 3
3D: Potenziometerhalter
3D: Arm
3D: Buchse

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 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.

Foto von rechts unten
Foto von rechts oben
3D: Beide Teile
3D: Potihalter
3D: Getriebekasten schwenkt Potiachse

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.

Ansicht von oben
Ansicht von links
Ansicht von vorn-unten
3D: Beide Teile
3D: Potihalter
3D: „Schnabel“

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.

Foto
3D: Alle Teile
3D: Poti-Halter
3D: Zahnrad
3D: Zahnstange

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:

• Tastenstatus zum Raspberry um schließlich „sudo systemctl reboot“ bzw. „sudo systemctl poweroff“ von einem Systemdienst (Dämon) ausführen zu lassen. Vielleicht ist es dtoverlay=gpio-shutdown,gpio_pin=5,active_low=1,gpio_pull=up.
• Poweroff-Statusleitung zur USV, die H ausgibt, sobald der „poweroff“-Zustand erreicht ist. Ein weiterer Systemdienst erledigt das, womöglich 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:

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:

• Inbetrieb­nahme
• ioctl-Problem. Da habe ich die Vermutung, dass beim Öffnen von /dev/rtc der Treiber eine Adjustment-Datei lesen möchte, mit der er Gang­fehler der Uhr kompensieren möchte. Und das Fehlen der Gang­fehler­korrektur­datei gleich mit einem Komplett­lese­fehler quittiert. ZeilennummernUmbruch

  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.

Entprell-Kondensator 33 nF
Taster an GPIO3 via Diode 1N4148
USV-Schaltplan (Auszug)
Huch! Ein anderer Mikrocontroller!
Taster an GPIO3 via Diode 1N4148
X728 V2.3 Unterseite
X728 V2.3 Oberseite

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

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.

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?

• Servo-Bezeichnung: HDKJ D3015
• Servocontroller-Chip im Innern: AF 06116
• Motor-Aufdruck: 1723RE-19120 210814

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.

Originaler FlySky-Controller
Touch-Screen
Ausgebauter Empfänger
Beides nebeneinander
Display zeigt Sensorwerte!

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:

• 0x04 = Paketlänge
• 0x81 = Hi-Nibble = 8 = Sensor entdecken, Lo-Nibble = Adresse 1
• 0x7A, 0xFF = 16-Bit-Prüfsumme. Am Empfänger alle Datenbytes auf 16 Bit vzl. erweitert und addiert und mit der 16-Bit-Prüfsumme addiert soll 0xFFFF ergeben. Wie blamabel, mal wieder keine CRC einzusetzen.

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 221221 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:

• Geöffnet wie eine Muschel
• Die Hauptplatine mit STM32F072 in der Mitte
• Dieser Flickdraht überbrückt die beiden vorder­seitigen Ein-Taster und sorgt so zum beinahe-sofortigen Einschalten des Gerätes beim Schalten an SWA. Hingegen das Ausschalten bekommt der ATmega328 nun (230905) mit, weil per Failsafe-Einstellung die Kanäle 1..8 eine Null senden, wobei Kanal 5, dem Taster hinten links zugeordnet, niemals regulär eine Null senden kann.
• Detektierter Schaltplan der Ein/Ausschalt-Logik der Fernbedienung. Während die Firmware läuft hält diese Pin 54 (PB15) auf H-Pegel; L-Pegel kappt die Stromversorgung. An Pin 53 (PB14) bekommt der Mikrocontroller den Ausschalt-Wunsch mitgeteilt, dem er (in der derzeitigen Standard-Firmware) nur nachkommt, wenn der Empfänger aus ist. Prinzipiell könnte eine überarbeitete Firmware den Ausschaltwunsch dem Empfänger mitteilen so dass dieser die Fahrzeugbatterie abschalten könnte: Das also für später!
  Es ist der Mikrocontroller, der die Kunstpause beim Einschalten macht.

• Muldenkipper {640×249} (groß {1280×720})
• Radlader {640×249}

• Anfrage 04 81 7A FF = Ist Sensor an Adresse 1 da? Wenn ja ist die Antwort dieselbe: 04 81 7A FF
• Anfrage 04 91 6A FF = Was misst der Sensor? Antwort: 04 91 00 02 66 FF mit
  • 00 = interne Spannung in 1/100 V
  • 01 = Temperatur in 1/10 °C
  • 02 = Drehzahl (RPM) ohne Komma
  • Andere irgendwo angegebene Kodes funktionieren nicht! Eine Live-Umschaltung funktioniert ebenfalls nicht.
• Anfrage 04 A1 5A FF = Miss! Antwort: 04 A1 00 00 58 FF mit 00 00 = Spannung 0 Volt

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:

• Korpus-Durchmesser 17 mm, Korpus-Länge 24 mm, Achsdurchmesser 1,5 mm
• Zahnrad 11 Zähne, Modul 0,25, Messing, sicherlich aufgeschrumpft
• Befestigung triebseitig 2× M2, Teilkreisdurchmesser 10 mm, Gewinde 0,8 mm, Einschraubtiefe max. 1,6 mm

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.