[teletype-guy]

True, we have only bench tested the VL53L0X, and do not yet have them on a vibrating robot, but hope to try that soon. Was thinking that at least one front and two angled L/R front corners will be handy for autonomous driving.

Other folks have mentioned that the built-in voltage translator chip in the ST satellite module causes problems when more than one satellite is on the I2C bus, but my design isolates a single satellite module via an intermediary PIC micro, so I have not looked at that usage case. I can say that with a single satellite module, I see proper 3.3V I2C bus signals with a scope. The ST satellite modules are running on 2.8V internally, so their IOVDD thresholds need to be init'd from their default 1.8V levels (ST should have scaled this automatically in hardware from IOVDD, but whatever). However, this has nothing to do with the satellite module's external I2C bus levels: the module is said to be happy with either a 3.3V or 5V I2C bus, via the translator chip.

The little PIC has a second I2C slave bus that connects to the modular cable daisy chain, and each gets set to a different address for the teensy to poll the chain. The PIC code (I will open-source all this before kickoff) takes care of the ugly sensor interface code.

The ST lidar API code is a disgusting bloated mess. After digging through the code from pololu (who extracted the essence of the api) and adafruit (who left most of the api intact), I finally figured out that almost none of it was needed for a simple default mode (1200mm), for which the min conversion time is about 30ms. I set my loop delay to a modest 40ms, which gives an update rate of about 25 ranging readings per second. I am just updating globals (aggregated back at the head of the string of lidar pods in the teensy, which is polled by the roboRIO).

So, only two things need to be done to init:
- set 2.8V mode (sets IOVDD thresholds; default is 1.8V levels)
- set I2C standard mode (not really sure this needs done either, but it is easy)

A single line starts continuous mode.

The read is easy, but the chip often returns 20 or 8190 when the reading is bad. A bit of logic in the code produces two numbers: range in mm, and a count of bogus readings, which can be used as a quality indicator -- if it is 0, then you got a valid reading; over 0 and the previous range is returned so you are kinda close; if it gets over say 10 bogus readings, then range is getting suspect. In practice I saw the bogus count only getting excessive when the distance was over the 1200mm max, but that is also good info.

The returned range numbers were off a bit but consistent, so I added a simple cal routine. Unsure whether that is the same for different chips, but will find out shortly (I have about 200 of these boards built up and about 8 satellite modules to test). Anyway, the PIC hides all that mess, so the roboRIO just looks at range in mm and the bogus-count quality number.

I also have a Lidar-Lite V1 that I tried to get the team to use a couple of years ago, but the kids were not ready. The I2C code on the roboRIO was too much to learn at the time, so I put an arduino micro in a little box, mounted the Lidar-Lite on top, and provided a DAC out so it would operate using an analog input on the roboRIO, but they still didn't use it. The Lidar-Lite is another case where a micro in between is handy to trap out bogus reading and filter and smooth the data stream so the kids are working with simpler code in the roboRIO. Funny you mentioned a pan/tilt, as I just picked up the kit from adafruit for the Lidar-Lite. I got servos with the pot output wire, so I can read and calibrate the positions. Was thinking of driving this via the teensy on the MXP board, but unclear on rules -- as I understand it, all motors and servos need to be driven from pwm on the roboRIO (and not an MXP or other processor), though PWM ports are passed through MXP and disabled as needed by the roboRIO, but maybe the pan/tilt is not a good place to offload code. Easy enough to do the pan/tilt all in the roboRIO with two pwm outs and two analog inputs. That's actually a good project for the kids next month.

Also a note on roboRIO I2C, which I used for the MXP board (java/wpilib anyway): it took some time with a storage scope and a logic analyzer to find that the I2C transaction method does not work -- it hangs the bus at the point where it should be doing a repeated-start, holding the clock low for about a second, and then just giving up and stopping. Same thing for the write-then-read method (forget the method names at the moment). Pure writes are fine. Pure reads are fine. Just not the repeated-start. So for the roboRIO polling the teensy on the MXP I2C port, I did a write to tell the teensy the data I wanted next, and then read however many bytes needed.

gil