
Using a Time-Of-Flight LIDAR Sensor - kungfudoi
https://mcuoneclipse.com/2016/12/03/tutorial-stmicroelectronics-vl6180x-time-of-flight-lidar-sensor/
======
quotemstr
Neat. I'm curious about why the sensor init code looks the way it does though.
It's a very long sequence of repetitive register writes. Why not do it like
this instead? Table-driven code is underappreciated, I think.

    
    
        static const struct {
            unsigned address;
            unsigned value;
        } inits[] = {
            { 0x207, 0x01 },
            { 0x208, 0x01 },
            { 0x096, 0x00 },
            ...
        };
    
        for (size_t i = 0; i < ARRAYSIZE(init_writes); ++i) {
            uint8_t res = VL_WriteReg8(i2cDeviceAddress,
                                       inits[i].address,
                                       inits[i].value);
            if (res != ERR_OK) {
                VL_OnError(VL_ON_ERROR_INIT_DEVICE);
                return res;
            }
        }
    
        return ERR_OK;

~~~
delinka
Indeed, their init routine seriously violates the DRY principle. At the very
least, each section could be implemented by a macro, but I prefer your 'table-
driven' implementation.

~~~
Gibbon1
I have a feeling writing is that way is mostly habit because you often end up
with init routines where the device barfs during init for various reasons[1]
and you need to execute 'plan b'. That said I'd consider using macro's to be a
distant third option.

[1] Classic is the uP resets and re-runs the init code on I2C bus peripherals
that have already been configured.

------
deutronium
I used a time of flight sensor in an attempt to measure the specific gravity
of beer - [https://www.anfractuosity.com/projects/zymeter-
simple/](https://www.anfractuosity.com/projects/zymeter-simple/)

[https://www.sparkfun.com/products/12784](https://www.sparkfun.com/products/12784)
\- Is the little board I used, and used a logic level converter.

I attached a little polystyrene circle to the top of the hydrometer, for the
IR to bounce off.

Unfortunately the approach didn't work too well because of yeast krausen
pushing the hydrometer about.

~~~
pyoung
That's neat! Regarding your temp sensor issues, I used the same sensor for
beer monitoring. Not sure if is is the same issue, but I was able to resolve
it[1].

[1] [http://www.blog.pyoung.net/2015/01/28/ds18b20-crc-check-
code...](http://www.blog.pyoung.net/2015/01/28/ds18b20-crc-check-codes/)

~~~
deutronium
Ooh thanks a lot for the heads up!

------
Animats
The data sheet is frustrating. It's not clear whether this device is a
carrier-modulated device or a pulse timing device. I think it's carrier-
modulated, like most low-end LIDAR devices. Multiple carrier-modulated devices
in the same space can interfere. Pulse timing devices, not so much, especially
if you randomize the pulse schedule a bit.

[1]
[http://www.st.com/content/ccc/resource/technical/document/da...](http://www.st.com/content/ccc/resource/technical/document/datasheet/c4/11/28/86/e6/26/44/b3/DM00112632.pdf/files/DM00112632.pdf/jcr:content/translations/en.DM00112632.pdf)

------
guntars
It's crazy, I've totally missed the point at which these things stopped
costing thousands of dollars and instead you can get them for $13.95 now.

~~~
Animats
I know. I went through the hell of trying to build one in the 1990s. I've used
the huge SICK LMS line scanner. Now these things are tiny and cheap, at least
for short range.

~~~
cr0sh
I have a couple of the SICK LMS units (picked them up cheap off ebay) - while
I like the fact that these tiny and low cost sensors are available (and great
for small-scale robotics) - they won't match up to a SICK unit in the near
term.

There's nothing like the range, 180 deg scanning speed, and general industrial
robustness of the SICK LIDARs.

Then again, these chips aren't the size of a small coffee maker, and don't
weigh a ton, either.

I think these devices will occupy a nice niche for when you want something
with a better resolution than either the Sharp IR sensors or some ultrasonic
pinger - but don't mind the limited range.

------
cptskippy
Pololu has published some libraries for both the VL53L0X and VL6180X that make
them a lot easier to consume.

[https://github.com/pololu/vl53l0x-arduino](https://github.com/pololu/vl53l0x-arduino)
[https://github.com/pololu/vl6180x-arduino](https://github.com/pololu/vl6180x-arduino)

I've been playing around with the VL53L0X.

[http://i.imgur.com/KFezaqU.jpg](http://i.imgur.com/KFezaqU.jpg)
[http://i.imgur.com/YM5KLRw.jpg](http://i.imgur.com/YM5KLRw.jpg)

------
infocollector
Does anyone know if this works in sunlight (at noon outside)?

------
donquichotte
Range is 10/40/60cm with accuracy 1/2/3mm (apparently there is some kind of
scaling factor). I wonder where such short range measurements with such a low
accuracy are useful.

~~~
cimnine
I could imagine this for collision avoidance in a very small UAV, e.g. a
vacuuming robot.

~~~
cptskippy
The 3m range with ~3mm accuracy is more than enough for large object alignment
as well. I've got the VL53L0X being used as a car park sensor in my garage,
it's a very complicated version of a tennis ball on a string.

