Bugger | RB03

Synopsis:

• Der Bugger ist ein Träger für Robotik-Experimente.

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:

• es wird ein Raspberry Pi 3 auf dem Chassis montiert
• als OS wird Ubuntu Server aufgespielt
• die 5V Versorgungsspannung kommen aus dem Step-Down-Wandler
• Detailproblem 1:
  • Wie finden zwei WLAN-Geräte mit dynamischer IP einander?
  • auf einem Server im Internet wird eine REST-API aufgebaut
  • Dort registriert sich der Pi mit folgenden Daten:
    • eigene MAC-Adresse
    • eigener Rechnername
    • eigene IP-Adresse
    • WAN-IP des Internetgateways
    • Timestamp
  • die Registrierung wird jede Minute per Cron-Job wiederholt.
  • Wenn man den Rechnernamen und die MAC-Adresse des Pis kennt (wenn's der eigene ist, hat man diese Daten), kann man dessen IP-Adresse im LAN von dem REST-Service erfragen.
  • Die Gateway-IP ermöglicht, zu prüfen, ob man sich überhaupt hinter dem gleichen Router und damit wahrscheinlich im gleichen Netz wie der Pi befindet.
  • Damit hat der steuernde Rechner die Information, wie er den Pi im LAN findet.

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:
  • 'h' 0.5s Linksfahrt
  • 'j' (Rückwärtsgang TBD)
  • 'k' 0.5s Vorwärtsfahrt
  • 'l' 0.5s Rechtsfahrt
  • das ShellScript ist /home/buggerop/bin/controlbot
• 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
      • Caveat: timg krallt sich die ganze Terminalsession. Der Versuch screen im Modus Split-Screen zu verwenden, hat im ersten Anlauf nicht funktioniert. Es braucht daher eine zweite SSH-Session für die Steuerung.

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.