Aufgrund der vergleichsweise geringen Hardware-Kosten und der vergleichsweise einfachen Ansteuerung erfreut sich Kinect bis heute auch im Bereich der Robotik großer Beliebtheit, obwohl Microsoft die Technik schon lange aufgegeben hat.

pieye bietet seit einiger Zeit ein ToF-Kameramodul namens Nimbus 3D an, das einen RPi in eine Tiefenkamera verwandeln soll. Als Autor eines Kinect-Buchs konnte ich mir deshalb Experimente nicht verkneifen. Vorab: Unter [1] findet sich ein PDF mit einem Vergleich diverser Tiefensensor-Systeme auf der Basis von Kinect-Sensoren.

 

Hardware

Elektor lieferte die Kamera in einer vergleichsweise kompakten Verpackung, die neben der eigentlichen Platine, einem Flachbandkabel und zwei Schrauben auch das 3D-gedruckte Abstandsformteil von Bild 1 mitbringt.

Bild 1. Formteil: 3D-Druck ist immer und überall.

Wegen der großen Menge an zu übertragenden Daten des verwendeten Sensors erfolgt die Kommunikation zwischen Platine und Einplatinenrechner über den Kamera-Port. Hierzu muss man vor dem eigentlichen Anschließen der Platine darauf achten, den Kamera-Connector des RPi mit dem Flachbandkabel zu verbinden. Danach verbindet man die Karte mit dem GPIO-Port, installiert die Schrauben (etwas hakelig) und erfreut sich an dem in Bild 2 gezeigten gezeigten Ergebnis.

Bild 2. Der Tiefenscanner ist jetzt prinzipiell einsatzbereit.

Beim Test mit einem RPi 4 blieb nach dem Anschließen der GPIO-Header und dem Einsetzen der Schrauben ungefähr ein halber Millimeter Abstand. Die schwarzen (und ebenfalls 3D-gedruckten) Spacer dürften also etwas zu lang sein. Dieses Problem lässt sich allerdings mit einer Feile oder einem Proxxon IBS lösen.

 

Inbetriebnahme

Sehr schnelle Hardware hat seit jeher die für Endanwender unangenehme Eigenschaft, in unixoiden Prozessrechnern häufig nur durch Kernelmodule und andere schwierig zu konfigurierende Elemente ansprechbar zu sein. Im Fall des Nimbus 3D ist dies einfacher, da eine ownCloud-Instanz mit fertiger Imagedatei bereitgestellt wird. Wenige Tage vor Redaktionsschluss lieferte der Hersteller dabei ein Update, das neben der Unterstützung für den Raspberry Pi 4 auch ein GitHub-Repository brachte. Wer sein Image unter [3] herunterlädt, kann eine hohe Datenrate nutzen – die ownCloud-Instanz ist manchmal etwas lahm (Bild 3).

Bild 3. Wer sein Image bei GitHub herunterlädt, kann eine hohe Datenrate nutzen – die ownCloud-Instanz ist manchmal etwas lahm.

Ein Test des Images nimbus_rpi3_rpi4_v0.1.78_d998e541_shrink.img.gz auf einer SD-Karte in einem RPi 4 funktionierte nach dem Update in einem Trockenlauf. Der Autor blieb hier aber bei einem RPi 3B+. Das System startete einmal neu und präsentierte dann das Terminalfenster (siehe Bild 4).

Bild. 4. Der Zugriff auf den Desktop ist mit dem bereitgestellten Image „etwas kompliziert“.

Für die eigentliche Inbetriebnahme ist neben einem per HDMI angeschlossenen Monitor zum Überprüfen der Status-Ausgabe vor allem eine Internetverbindung erforderlich. Nimbus 3D ist kein Stand-Alone-System. Ein RPi ist vielmehr – wie bei einem Kinect – als Kamera vorgesehen, die von ihm „aufgenommene“ Informationen an eine Workstation überträgt. Wegen der hohen Framerate führt eine Gbit-Ethernet-Verbindung hier zu weniger Latenz. Zur Stromversorgung ist ein extrem leistungsfähiges Netzgerät erforderlich: Die Verwendung des offiziellen Netzteils bzw. eines echten Äquivalents verhindert Probleme.

Die nächste Aufgabe besteht jedenfalls darin, die IP-Adresse des RPi zu ermitteln und die zugehörige Webseite danach im Browser eines PCs etc. zu öffnen. Wer wie ich Ubuntu nutzt und den RPi sowie den PC im selben Netzwerk unterbringt, kann nach folgendem Schema mit NMAP auf die Suche gehen:

 

tamhan@TAMHAN18:~$ nmap -sP 192.168.1.0/24

 

Starting Nmap 7.60 ( https://nmap.org ) at 2020-08-11 06:06 CEST

Nmap scan report for sagemcom (192.168.1.1)

Host is up (0.00055s latency).

Nmap scan report for raspberrypi (192.168.1.66)

Host is up (0.0015s latency).

Nmap scan report for TAMHAN18 (192.168.1.68)

 

Das hier verwendete Kommando ist übrigens nur dann gültig, wenn der Router dem Netzwerk-Client IP-Adressen nach dem Schema 192.168.1.x übergibt. Bei anderer Basis-Adresse müssen Sie die Eingaben entsprechend anpassen. Bei erfolgreicher Verbindung zeigt sich die Webseite wie in Bild 5.

Bild 5. Der Scan funktioniert problemlos.

Man kann hier sowohl meine Hand als auch die an der Decke befindlichen Kabelkanäle und sogar die Gasleitung vergleichsweise gut erkennen. Dies ist nicht wirklich erstaunlich, da das Datenblatt eine Auflösung von 352 x 288 Pixel bei einem Messbereich von 0,1…3 m verspricht.

Im Nahbereich haben Tiefensensoren erfahrungsgemäß Probleme. Da ich gerade einen Tektronix 577 geöffnet hatte, zeigen die Bilder 6 und 7 zwei Scans davon.

Bild 6. Aufnahme eines geöffneten Tektronix 577.
Bild 7. Aufnahme eines geöffneten Tektronix 577 aus anderem Winkel.

Auffällig ist vor allem, dass die zur Beleuchtung verwendeten LEDs unter einer gewissen Minimaldistanz zur Überbelichtung führten.

Wichtig ist hier zweierlei: Erstens leuchten die auf der Platine befindlichen LEDs nur sehr schwach rot, denn es handelt sich dabei um Infrarot-LEDs. Zum Test ihrer Funktion eignet sich die Kamera jedes handelsüblichen Smartphones. Mein BlackBerry hatte keine Probleme damit, das Leuchten der LEDs sichtbar zu machen. Weiter gilt es, die vergleichsweise hohe thermische Instabilität zu beachten. Im meinem wohltemperierten unterirdischen Bunker herrschte eine Raumtemperatur von 20 °C. Obwohl der RPi komplett offen auf dem Tisch lag, entwickelte er hier Temperaturen von bis zu 70 °C. Die Verwendung eines RPi in Gehäusen ohne Kühlung ist daher nicht sonderlich empfehlenswert.

Die Anzeige von Tiefeninformationen im Browser mag interessant sein, doch ob dies den Preis von fast 230 € rechtfertigt ist die Frage. Erfreulicherweise gibt es eine Python-Bibliothek, die Entwicklern die Integration der Tefeninformationen in hauseigene Anwendungen erlaubt. Interessanterweise setzt der Anbieter bei der Implementierung der Kommunikation konsequent auf Websockets - ein Verfahren, das Python 3 in Version 3.6 oder neuer voraussetzt. Ich habe bei den nachfolgenden Schritten mit Ubuntu 18.04 LTS gearbeitet. Auf meinem PC war Python in der Version 3.6.9 installiert.

Im nächsten Schritt wird die in Python enthaltene Paketverwaltung PIP eingespannt, um die Bibliothek herunterzuladen. Achten Sie darauf, nicht versehentlich statt PIP3 die zu Python 2.X gehörende PIP-Version zu verwenden:

 

tamhan@TAMHAN18:~$ pip3 install nimbus-python

. . .

Successfully installed certifi-2020.6.20 chardet-3.0.4 idna-2.10 nimbus-python-0.0.4 numpy-1.19.1 requests-2.24.0 urllib3-1.25.10 websockets-8.1

 

Für einen einfachen Programmierversuch bietet sich dann ein nach dem folgenden Schema aufgebautes Testprogramm an:

 

from nimbusPython import NimbusClient

cli = NimbusClient.NimbusClient("192.168.1.66")

header, (ampl, radial, x, y, z, conf) = cli.getImage(invalidAsNan=True)

 

Nach dem Import der Nimbus-Bibliothek erzeugt man ein Client-Objekt, das die Verbindung zum als Kamera dienenden RPi enkapsuliert. Danach folgt auch schon der Aufruf der Methode getImage, die eine Gruppe von Vektoren mit den diversen Tiefendaten zurückliefert. Diese kann man danach nach Belieben verarbeiten. Ich würde hierzu MatPlotLib einsetzen. Dieses Programm und der Rest der Python-Bibliothek funktionierte bei meinen Tests so einigermaßen. Manchmal klappte es nicht mit dem Verbindungsaufbau und ich musste den Prozess hart unterbrechen.

 

Exkurs: Die Arbeitsumgebung

Auch wenn das Handbuch die Verwendung des bereitgestellten Images dringend empfiehlt, wollte ich dennoch eigene Versuche durchführen. Ich setze hierzu dann doch auf einen RPi 4, der mit dem Firmwareimage 2020-08-20-raspios-buster-armhf-full.img ausgestattet wurde. Im nächsten Schritt erfolgte durch Eingabe der folgenden Kommandos ein Update der Low-Level-Arbeitsumgebung:

 

pi@raspberrypi:~ $ sudo apt-get update

pi@raspberrypi:~ $ sudo apt-get upgrade

pi@raspberrypi:~ $ sudo rpi-update

 

Nun musste ich noch den Paketquellen-Ordner hinzufügen. Hierzu ergänzte ich die Datei /etc/apt/sources.list mit Superuser-Rechten um das Kommando deb http://apt.pieye.org/debian/ nimbus-stable main und führte danach das folgende Kommando zum Hinzufügen eines SSH-Schlüssels aus:

 

wget -O - -q http://apt.pieye.org/apt.pieye.org.gpg.key | sudo apt-key add -

sudo apt-get update

 

Nach dem obligaten Reboot wird am Ende der Datei /boot/config.txt wieder mit Superuserrechten die folgende DTOverlay-Deklaration hinzugefügt:

 

[all]

#dtoverlay=vc4-fkms-v3d

dtoverlay=irs1125

 

Nun konnte ich den für die Auslieferung der Tiefen-Images verantwortlichen Server installieren – achten Sie darauf, in raspi-config nebenbei den I2C-Bus freizuschalten (sudo raspi-config -> 5 Interfacing Options -> P5 I2C):

 

pi@raspberrypi:~ $ sudo apt-get install nimbus-server

 

Danach ist abermals ein Reboot erforderlich. Die folgenden Kommandos sorgen für das Herunterladen der Web-Oberfläche und der Installation der für ihre Abarbeitung notwendigen Unix-Serverdienste:

 

pi@raspberrypi:~ $ sudo systemctl start nimbusServer.service

pi@raspberrypi:~ $
  sudo apt-get install nginx git

pi@raspberrypi:~ $ git clone https://github.com/pieye/nimbus-web.git

 

Zu guter Letzt musste ich noch die Datei /etc/nginx/sites-available/default editieren und die Root-Deklaration nach folgendem Schema auf die aus GitHub heruntergeladenen Elemente zeigen lassen:

 

root /home/pi/nimbus-web;

 

Nun fehlte nur noch die Eingabe von sudo service nginx restart, was den Webserver neu startete und die Web-Oberfläche unter der IP-Adresse des RPi ansprechbar machte. Dies rief ich via meinem PC auf, und erfreute mich an drei schwarzen Bildschirmen. Eine Analyse des Dienste-Zustands ergab, dass sich der Dienst kurz nach dem Aufruf wieder verabschiedete, und mir den schwarzen Bildschirm von Bild 8 hinterließ.

Bild 8. Der Server verabschiedet sich gleich wieder.

Dieser Fehler ist auf eine Inkompatibilität zwischen Kernel und Treiber zurückzuführen, dem Hersteller bekannt und wird immer wieder behoben.

 

Lohnt es sich?

Außer Frage steht, dass pieye mit dem Nimbus 3D einen vergleichsweise preiswerten Tiefensensor anbietet, der - auch im Vergleich zum Kinect - durchaus beeindruckende Ergebnisse liefert. Wer heute einen kompakten Tiefenscanner benötigt, hat in diesem Bereich wenig Auswahl. Dass es für militärische Anwendungen bessere Sensoren gibt, ist klar. Ob man allerdings so viel Geld dafür ausgeben will, ist eher fraglich.

Neben den unbestreitbaren Vorteilen des besprochenen Produkts bestehen aber durchaus Aspekte, die es zu verbessern gälte. Dass keine Pads existieren, über die man die Platine direkt bzw. per Netzteil versorgen kann, hat mich gestört. Bessere Python-Software wäre übrigens auch nicht verkehrt. Auf jeden Fall hoffe ich, dass ich mit diesem Review dazu beitragen kann, dass sie sich schon vorab eine ungefähre Vorstellung von dem machen können, was mit diesem Sensor auf Sie zukommt.

 

----------------------------------------------------------------------------------------------------------------------

Wollen Sie weitere Elektor-Artikel lesen? Jetzt Elektor-Mitglied werden und nichts verpassen!

----------------------------------------------------------------------------------------------------------------------