Synopsis:
Abstract:
Beim Stöbern im Netz fand sich das Raupenfahrwerk „Yuewalker“ von DFRobot.
Features sind:
Rahmen aus beschichtetem Aluminium
alle Verbindungen geschraubt
Rollen mit Kugellagern
1.6 Kg Zuladung
viel Platz für Montage
Schraubendreher und Schraubenschlüssel liegen bei
Step 1 - Montage des Chassis':
für die Muttern M3 ist noch ein Schlüssel 5.5mm (oder Zange) erforderlich
Zusammenbau in etwa einer Stunde erledigt.
Erster Test: zwei 1.5V-Batterien lassen das Gerät schon mal vorwärts rollen.
Zweiter Test: mit einem (kleinen) 12V-Akku (Nennspannung der beiden Getriebemotoren) zischt das Gerät zügig ab.
Caveat: Die beiden Motoren müssen antiparallel geschaltet werden, sonst dreht das Gerät auf der Stelle.
Step 2 - IR-Fernbedienung:
eine einfache IR-Fernbedienung mit Empfänger soll das Fahrzeug steuern
der Empfänger benötigt 5V. Ein einstellbarer Step-Down-Wandler erzeugt diese aus der Akkuspannung.
die Fernbedienung hat fünf Tasten. Vier Tasten steuern je einen Pin am Empfänger. Die 5. Taste steuert alle Pins gemeinsam.
Für jeden Motor gibt es einen NPN-Leistungstransistor KD501 von Tesla mit einem 2N2218 in Darlingtonschaltung plus 1N4007 als Freilaufdiode. Je ein Kanal der Fernbedienung steuert einen Transistor.
Alle Teile werden mit breiten Gummibändern auf dem Chassis befestigt, das geht ohne schrauben und lässt sich schnell ändern. Wago-Klemmen sind hier ebenfalls sehr praktisch.
Test: mit der Fernbedienung auf den IR-Empfänger zielen und drücken. Läuft und lässt sich lenken.
Caveat: die Entfernung der Fernbedienung beträgt wenige Meter und man muß auf den Empfänger zielen. Das liegt vermutlich an der geringen Sendeleistung der Fernbedienung. Andererseits kann das Fahrzeug so auch nicht „flüchten“.
Step 3.1 - WLAN-Fernbedienung:
Step 3.2 - WLAN-Fernbedienung:
per SSH auf dem Pi einloggen
Das Script „connectbot“ holt die Verbindungsparameter aus der
API und stellt einen SSH-Connect mit X11-Forwarding her.
ein Shell-Script steuert das Terminal auf „raw“ und lässt auf die vi-Cursor-Tasten hin die Motoren 1/2 s laufen:
im Ergebnis kann man den Bugger so etwa in Echtzeit steuern
Caveat: nach dem Start des Pis sind die GPIO-Pins auf „high“, d.h. das Gerät saust sofort los. Abhilfe: Motorstrom zunächst abklemmen, Pins initialisieren, Motorstrom erst dann anschalten.
GPIOs 0-8 sind beim Start high
GPIOs 9-27 sind beim Start low
→ Motorsteuerung auf PINs 9 und 10 gelegt
Netzwerk-Startup dauert mehrere Minuten. Geht das schneller?
Step 4 - Fahrkamera:
mit der WLAN-Anbindung rollt das System, soweit das WLAN ausleuchtet - auch dahin, wo man es nicht mehr sieht
Eine Kamera in Fahrtrichtung würde helfen
eine First-Person-View-Experience wäre extra geil
Diverse Kameras (aus der Reste-Kiste) wurden probiert. Ergebnisse:
der Pi schafft es nicht, das Video-Signal von der Kamera ins WLAN zu schaufeln
eine Kamera mit H.264-Encoding könnte helfen:
der Pi könnte deren Stream einfach durchreichen
das würde dem Pi das Umkodieren ersparen
Umschau nach entsprechender Hardware: namhafte Hersteller haben vor Jahren den H.264-Support eingestellt, weil die CPUs inzwischen für den Job schnell genug wären. Ach was.
im Resteversand Kamera gefunden, die H.264 und Linux unterstützt, die ist aber erst in einer Woche hier
Experimente mit den Kameras:
0ac8:332d Z-Star Microelectronics Corp. Vega USB 2.0 Camera
0c45:6367 Micromedia USB 2.0 Camera
05a3:9331 UVC 1.00 device „HD Web Camera“ SerialNumber: „Ucamera001“
die Micromedia-Kamera und „HD Web Camera“ können MJPG2
der Stream der Z-Star kann mit guvcview über SSH über WLAN mit Auflösung 320×200 in nahe Echtzeit betrachtet werden
der Stream der „HD Web Camera“ kann mit guvcview über SSH über WLAN mit Auflösung 640×360 in nahe Echtzeit mit 47..4.9 fps betrachtet werden. Die Codecs liefern:
MJPEG - 4.6 fps, Falschfarben
YUYV - YUYV - 4:2:2 4.5 fps
H264 - H.264 - unbrauchbar, voller Artefakte
RGB3 - RGB3 - 4.7..4.9 fps ← ausgewählt
BGR3 - BGR3 - 4.7..4.9 fps
YU12 - YU12 - 4.7..4.9 fps
YV12 - YV12 - 4.7..4.9 fps
guvcview -d /dev/video1 -x 640×360 –video_codec RGB3 -g none &
mit VLC laggt die Kamera schon lokal am PC übel, also ist VLC aus dem Rennen
timg -V /dev/video1
funktioniert auch passabel
das Script /home/buggerop/bin/video
startet die Videoübertragung
Step 4.1 - Kamera-Reset
Etwas geht schief mit der Anlage des Video-Devices beim Booten: /dev/video1 liefert keine Daten. Re-Plug der Kamera hilft.
Vllt. kann man die Kamera automatisch powercyclen?
echo 5-1 > /sys/bus/usb/drivers/usb/unbind
→
bash: echo: write error: No such device
- das File ist aber da
Anscheinend kann der RPi den Port nicht abschalten. *sigh*
Step 4.2 - Kamera-Zuverlässigkeit / Energieversorgung
Nach dem Systemupdate 02/2024 laggt timg
bis zur Unbrauchbarkeit. guvcview
läuft flüssiger aber nicht doll.
Es scheint, als ob der Step-Down-Wandler (liefert bis 1.5A) nicht genug Leistung bringt. Also externes Netzteil verwendet, das bleibt aber unter 800mA. Nach einer Weile rebootet der RPi ständig. Vllt. wird's dem Keks zu warm?
Step 5 - Rückwärtsgang:
Für einen Rückwärtsgang braucht es ein Relais oder eine H-Brücke.
Da das Relais seinerseits einen Transistor mit Freilaufdiode erfordert, kann man auch gleich die Brücke aufbauen.
Eigentlich würde man die Hälfte der Brücke mit PNP-Transitoren bestücken, nur sind davon gerade keine zur Hand. Stattdessen werden auch dafür NPN-Transistoren benutzt. Drawback: die erforderliche Basisspannung kann der Pi nicht bereit stellen. Der Trick: ein Opto-Koppler steuert den Leistungsteil und der Pi den Opto-Koppler.
Step 5.1: Aufbau der H-Brücken