VL53L1X mit AVR

Hat hier jemand schon mal den VL53L1X unter nem ATMega (jenseits von Arduino und STM) ans Rennen bekommen?

Ich drück mich da gerade etwas rum: Ich hab den Sensor da, aber absolut keinen Bock, für nen kleinen Test den Arduino-Wire-Kram auf C zu portieren.

erstmal ganz kurze Frage weil mir die Kinnlade auf dem Boden schleift, das Ding hat 16x16 ToF Pixel die man selektiv (2x2 Area) nutzen kann?!
Von der Doku her kurz reingelesen scheint es mir als ob die einem garnicht die Wahl lassen als deren Treiber zu nutzen, irgendwie bisschen doof.

Aber der API Doku nach zu lesen denke ich das porten sollte grundsätzlich garkein Problem sein, sofern da keine Funktionalität außer I2C genutzt wird ... leider lässt mich ST die API nicht ohne Anmeldung runterladen

Das Porten ist schon nen Problem, weil die STM-Jungs Dich mit 40 Code-Dateien beschmeißen (ich hab die API bereits runtergeladen) und Dir durch die Blume mitteilen: Die API ist die Referenz (also kein Registerdatenblatt, kein Minimalbeispiel, da stehe ich schon mal gar nicht drauf).
Ich habe auch schon ne Implementierung für den AVR gefunden (https://github.com/SensorDots/MappyDotPlusFirmware), aber die ist noch aufgeblähter als das Original.

Drum dachte ich mir, vielleicht hat's jemand hier schon mal etwas schlanker portiert und lässt mich partizipieren (Dann kann ich mit die 3+x Tage geschätzte Umsetzung sparen).


(warum bekommst Du Muskelschwäche in der Kinnlade? Die Dinger gibt's seit geraumer Zeit z.B. bei EXP-Tech)

Zitat:

---

(also kein Registerdatenblatt, kein Minimalbeispiel, da stehe ich schon mal gar nicht drauf)

---

Ganz deiner Meinung, ich muss mir nur mal ne neue spammail basteln dann lad ich mri das mal und guck mal rein, ob der moppes portfähig ist ... die github lösung ist auch irgendwie sehr speziell mit dieser mappersache da drin


https://github.com/pololu/vl53l1x-ar...er/VL53L1X.cpp

die sieht schonmal schlanker aus, auch wenn es ein bisschen polulu typisch mit makro zugekackt ist XD

https://github.com/sparkfun/SparkFun...rduino_Library

sparkfun hat eine relativ saubere lösung (persönliche meinung)

https://github.com/stm32duino/VL53L1X/

ich glaube aus der kann man fast am meisten gewinnen :)

So, hat etwas gedauert, bis ich mich drangetraut (endlich mal Ruhe dafür gefunden) habe. Nicht ganz, wie vermutet 3+x Tage: es waren nur 2 Tage.
Anbei der allerallererste Test, quasi die Abkupferung des Polulu-Arduino-Beispiels als entarduinote, reine AVRStudio-Version. Naturgemäß wird es so mit knapp 6kB etwas kleiner auf dem Controller. Wer Spaß hat und C kann, der wird wohl die Wertabfrage aus der main-Funktion auf'n Timer-Interrupt legen.

Ich hab noch die ROI-Funktion hinzugefügt. In den Sparkfun-Quellen sind sie zwar falsch implementiert, aber immerhin findet man eine Spur, wohin die Reise geht. In der Original-ST-API habe ich mich nach der dritten Ebene ehrlich gesagt schwer am Kopf gekratzt, die rechnen da von links nach rechts und wieder zurück, völlig oversized, kein Wunder, dass die API so groß wirkt.

Vorweg noch dazu: Wer die ROI-Funktion nutzen will (immerhin bekommt man nominal seinen Erfassungswinkel mit 4x4 Spads auf 17° beschränkt), muss mit massiven Reichweiteneinbußen rechnen. Bei ca. 40cm war bei mir mit dem aus dem Chip zurückgegebenen validen Messstatus Schluss. Aber auch das ist im DB des Sensors irgendwo beschrieben.

Testhardware: 8MHz-ATMega168 mit UART, TWI und drei KontrollLEDs.

Anbei auch noch die Quellen des PC-Testprojektes (C# VS2010), damit man was von der Wertanzeige hat.

Controller: Anhang 34152
PC: Anhang 34153

Nachgereicht: Den VL53L1X als Nahfeldsensorik mit ca. 20° nach unten geneigt auf einer drehenden Sensorplattform (60U/min) zusammen mit einem LidarLite V1.

Brett und Schraubenkasten liegen unterhalb der horizontalen Messebene des LidarLite (blaue Messpunkte), können aber durchaus vom VL53L1X (schwarze Messpunkte) ab einem Abstand von ca. 40cm erkannt werden (gelber Kreis markiert 50cm Abstand).

Messergebnis
Anhang 34277

Szene
Anhang 34278

Hatte gerade vor einer Woche das Vergnügen mit einem ST-FAE aus genau diesem Produktbereich zu reden und auch prompt ausgefragt über das Teil :D

Kern der Aussage: Man kann an die einzelnen Pixel Informationen getrennt herankommen und damit quasi eine mini-ToF Kamera bauen (also mit echter Optik) aber dafür müsste ich mindestens ein NDA unterschreiben XD

Hat jemand Erfahrung was ein NDA als Privatperson bedeutet?!

Was mir bei deinem Projekt durch den Kopf geht ist den Sensor oben auf den Robo zu packen und einen 360° Spiegel (+ ggf. Linse) darüber zu montieren und dann die Umgebung auf die Pixel zu mappen (bis auf die zentralen 8x8, da sieht man nur den Robo) denn so hat man rund herum mindestens 4 Pixel pro Raumsektor und kann dadurch sogar die Plausibilität des Signal sicherstellen, indem man einfach prüft ob das Signal mit der Distanz und dem Winkel überhaupt richtig sein kann (je näher das Hindernis kommt, um so mehr Pixel müssten einen vergleichbaren Distanzwert zeigen, wenn man die Verzerrung durch den Spiegel und den Winkel rausrechnet ... BESSER sogar man kann die höhe und vll. sogar die grobe Form des Objektes schätzen)

Bei Verstoß wirst Du nach Guantanamo geschickt und mal ordentlich watergeboardet.

Letztendlich kann ich mir zwar vorstellen, dass in den mannigfaltigen Registern auch irgendwo die einzelnen Werte der Spads liegen. Mich macht es allerdings schon misstrauisch, dass lt. Datenblatt der optische Mittelpunkt auf +/-2 Spads zu kalibrieren ist. Ich würde mal schätzen, so ganz genau bekommt man die Optik bei so geringer Brennweite nicht hin?!

Warte, ist da schon eine Optik drinne? Ich hatte das so verstanden dass man "nur" den Effekt einer Lochkamera hat wenn man die Sensorfläche verkleinert!?

Da müsste man mit einer Linse nah am Loch auch eine vernünftige "Sehschärfe" erreichen könne wenn amn alle Pixeln einzeln lesen kann oder?!

RTFM:
"SPAD (single photon avalanche diode) receiving array with integrated lens"

Nur, wie willste die zusätzliche Linse in x/y-Richtung ausrichten? Bei den typischen Halbleitergrößen musst Du ja mindesten auf nen zehntel genau platzieren.

Ohhh Nachtrag, im DB ist angegeben: Unter dem IR-Filter-Glas sitzt eine Linse mit 0,85mm Durchmesser, darunter die 16x16 Spads, auf die dann irgendetwas Fokussierendes auszurichten wäre. Um mit dem Brennpunkt der Optik auch genau das mittlere Spad zu treffen, müsstest Du also auf 0,05mm ausrichten können.

Nachträglicher Nachtrag: Geht doch gar nicht. Die Sende-IR-Diode sitzt so nahe am Empfänger, dass sie durch eine Glasfaseroptik am Empfangsobjektiv umgeleitet werden müsste.

Nachgereicht: Nachdem ich es auch erst heute zufällig über Dritte mitbekommen habe. Seit Juni gibt es von ST die Ultra Lite Driver API.
Was jetzt bei 56 MB Download so besonders Lite ist, erschließt sich mir zur Zeit noch nicht, aber ich werde mal beizeiten en Detail schauen, was aus dem Paket an neuen Erkenntnissen über den Sensor zu ziehen ist.

mit Lite meinen sie dass man an weniger "Vorverarbeitung" in der Library gelegt hat und etwas tieferen Zugang zu den Funktionen gönnt.

"der Chip hat eine riesige Anzahl an Kontrollregistern und vor allem Kontrollfunktionen für die Laser LED, an die wir aus Sicherheitstechnischen Gründen unsere Kunden nicht unbedingt heranlassen wollen"

Das war O-Ton eines FAE von ST