New 1200mm LIDAR -- VL53L0X

[teletype-guy]

Hi folks:

This is a continuation from the teensyRIO post I just made in control-systems, but it seemed that discussion of the LIDAR section should be in this sensors forum.

I decided to experiment with some new short-range (~1200mm) LIDAR chips from ST -- VL53L0X. These are spec'd to 2000mm in a long-ranging configuration, but in default mode they are good to about 1200mm. They have a 25-degree field-of-view, so up to eight of them can be mounted around the perimeter of the robot (front/rear/left/right plus four corners with a 45-degree mount). Each sensor will provide a range from 20 to 1200mm at a rate of 25 times a second. The sensors mount to a small board with a little PIC micro which handles the details of its attached sensor, and has a pushbutton/light that lets you easily set each pod to a different I2C address.

The string of LIDAR pods, daisy-chained with modular cables, connect to a teesnyRIO, an MXP board that can mount a Teensy LC or 3.6 (or some others depending on pinout), and can also host another MXP board above it, with all pins passed through. The Teesny hangs on the MXP I2C port as a slave -- code running in the roboRIO auton or teleop loops can communicate constantly with the teesnyRIO. For the LIDAR system, a second I2C (master) port is routed out a 6P6C modular jack on the teensyRIO, with switched 5V to power the lidar chain up when needed, or off when not.

I will have a modest quantity of them available, and I will post the hardware design and open-source the firmware in the LIDAR Pod's PIC micro, the teensyRIO, as well as the communication code in the roboRIO. As I understand it, this makes the LIDAR/teensyRIO usable for 2017 if design files are public prior to kickoff.

So that was a lot of preamble to get to my question: within the roboRIO autonomous loop, I can constantly poll for up to eight ranging distances -- what is the best way to use that information to perform obstacle avoidance or field way-point determination? This must be much like code that uses other ranging parts (IR or ultrasonic) so how is that data best fed into the drive/steering code?

thanks, Gil Smith

[Foster]

I spent some time reading the spec sheet. It looks like it has pretty good accuracy, but the spec sheet doesn't say anything about the size of the target.

Can you post what kind of targets you are hitting? I've been disappointed with most ranging that isn't hitting a wall as the target.

[AustinSchuh]

Originally Posted by teletype-guy

So that was a lot of preamble to get to my question: within the roboRIO autonomous loop, I can constantly poll for up to eight ranging distances -- what is the best way to use that information to perform obstacle avoidance or field way-point determination? This must be much like code that uses other ranging parts (IR or ultrasonic) so how is that data best fed into the drive/steering code?

Ok, that's pretty cool Does it see the plexiglass? That's my biggest worry right now with LIDAR. Also, if there was a way to get 5 meter lidar for cheap, that would be perfect for FRC. Unfortunately, the field of view is 20 degrees, which won't give you the nice point cloud that a more expensive lidar would give you.

The industry buzz-words you are looking for is localization. You want to use the LIDAR to do localization. I'm pretty certain that the 2 meter distance is going to be too short to be useful, but if you can see the perimeter of the field, you should be pretty close to done. One of the classic algorithms is the particle filter. http://robots.stanford.edu/papers/th...tics-uai02.pdf should be useful, though I haven't read it myself to confirm. Someone like Jared Russell would have more good insight if you can get him to chime in.

Once you know where you are, you want to then follow a path in the absolute coordinate frame. The general problem of driving somewhere without hitting things wicked hard. Algorithms like ELQR and ILQR are pretty good for that, but the math is hairy. You can spend an entire lifetime on this part.

I'm definitely not an expert. I've been working on adding localization and path planning to 971's bots over the last couple years, and am getting closer.

[Gdeaver]

Early this fall our team characterized this sensor. We purchased one from Pololu. We could never get the 2 ST Micro break outs to work. It does see Poly and AL diamond plate which give the Sharp IR sensors fits. Vibration and fast movement drop the reliability allot. For many materials 1200mm is not realistic. I would say this is a good 2' sensor. I would strongly recommend A team buy one and test it to get a feel for it. Our conclusion is that for some short range applications it is better than the sharp IR and sonars. For longer distances we prefer the Lidar Lite. I like this sensor. We purchased 2 V3 on black Friday for 129$. I can envision mounting the Lidar lite on a pan tilt and using it to confirm the vision targeting data.

[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