LIDAR Sensor has arrived!

[DavisC]

Thanks, so I just use kMXP instead of kOnBoard and connect to the expansion port bottom left 2 pins for sda and scl?

[seg9585]

Originally Posted by DavisC

Thanks, so I just use kMXP instead of kOnBoard and connect to the expansion port bottom left 2 pins for sda and scl?

Correct. I still had my sensor power pins plugged into the I2C power and ground ports, which seem to work (for what it's worth).

Also, if you execute myLidar.start(); in your init area or constructor, you can access myLidar.getDistance() in both autonomous and teleOp methods and allow it to run its own thread, which will help avoid bogging down the rest of your code (because the update() method includes delay timers up to ~10ms to write and read).

[WDB]

Originally Posted by seg9585

Correct. I still had my sensor power pins plugged into the I2C power and ground ports, which seem to work (for what it's worth).

Also, if you execute myLidar.start(); in your init area or constructor, you can access myLidar.getDistance() in both autonomous and teleOp methods and allow it to run its own thread, which will help avoid bogging down the rest of your code (because the update() method includes delay timers up to ~10ms to write and read).

We tried the I2C port too and failed. Moved over to the MXP and still getting zeroes.

Using lidar.start() in the teleopInit and calling lidar.getDistance() in teleopPeriodic which is returning zero. Am I missing anything?

Thanks!

[co1inw]

Originally Posted by tech2077

In case anyone is interested, I wrote up a java class for this, you can use the start/stop functions to use the built in updater Timer, or use the update function to only poll distance when needed.
LIDAR.java

Please correct me if I'm wrong, but there appears to be a bug in this file. You are calling updater.scheduleAtFixedRate(), which would be fine if you didn't already have a while() loop inside your TimerTask. Since you have a while loop, the run() function will never exit, so essentially your timer is useless and is acting like just a Thread object to run this function in the background indefinitely. The 'period' argument isn't being used, so the sensor will be polled every 10ms.

Also, since it came into the discussion, our team is using Java and we have been able to successfully use our RoboRio I2C port for a MaxBotix ultrasonic sensor, but not for the LIDAR sensor. Trying to use the LIDAR gives us write and read errors.

[Pi Fighter]

Hello all, a while ago our team posted that we were able to successfully collect data from the Lidar sensor using LabVIEW. Today I'm posting the code we're using to collect the data, as well as pictures of the placement of these VI's in the robot project. Feel free to use them as needed.

[PaulDavis1968]

Ordered! I have been drooling over this for 6 months. And we might have a use for it. I was going to buy it for my self regardless. If it works out I will get one for the team so we have two.

[dellagd]

Based on the datasheet it seems this wouldn't work on polycarbonate, since it transmittance is just as high at 905nm as it is in the visible spectrum, and the laser would mostly go right through. I really don't know much about LIDAR systems, so does anyone else with more experience know if this would be the case?

[PaulDavis1968]

Originally Posted by dellagd

Based on the datasheet it seems this wouldn't work on polycarbonate, since it transmittance is just as high at 905nm as it is in the visible spectrum, and the laser would mostly go right through. I really don't know much about LIDAR systems, so does anyone else with more experience know if this would be the case?

I asked this question on their forum.

https://groups.google.com/forum/#!forum/pulsedlight3d

[Jared Russell]

Polycarbonate doesn't have 100% transmittance for near IR, but it's still very high. You will get a small amplitude return from polycarb, which will be higher if there are scratches or dirt on the surface, or if you are getting specular returns from other light sources. You can configure the LIDAR-Lite to present either the strongest, first, or last return to you, and I'd expect whatever is behind the panel to be the strongest return the vast majority of the time (but not always).

Experientially, LIDAR sucks for detecting transparent objects and requires lots of signal processing and integration of multiple scans over time to have any chance of accurately detecting a transparent object.

[seg9585]

FYI, I have detected distance to transparent windows with moderate levels of success. I'd assume polycarbonate behaves similarly, but would have to do more testing. We are programming up the LIDAR against the roboRio tonight so I'll try it out.

[IronicDeadBird]

Man I wanted one of these and I don't even have a reason...
Any cool uses for them I have a couple ideas but none of them are viable this year cause auto too short...

[PaulDavis1968]

Originally Posted by IronicDeadBird

Man I wanted one of these and I don't even have a reason...
Any cool uses for them I have a couple ideas but none of them are viable this year cause auto too short...

I wanted one of these period. I don't care if we use it.

[muvicado]

Originally Posted by seg9585

Just wanted to share that a new LIDAR (laser radar/rangefinder) is out on the market from "PulsedLight3D" for $90 -- Class I laser so it's FIRST legal. Just arrived today in the mail, and I hooked it up to my Arduino:



Did some initial testing via I2C, seems to be very accurate between ~20cm and 650cm (as far as I could test it tonight without finding a larger room), 0.5 deg beam width

Here's a snapshot of my Serial output with distance in cm (~100 Hz samples averaged and output at 5 Hz), sitting on my desk facing up to the ceiling.


http://pulsedlight3d.com/
We're going to have fun with this!

Do you know if more than one LIDAR-Lite can be connected via CAN through the MXP's can bus?

The LIDAR-Lite appears to have a fixed slave address - 0xC4.

LIDAR-Lite Spec

Why would they not make it configurable? Seems like that would prevent one from being able to use multiple LIDAR-Lites on the same I2C bus.

Maybe I'm missing something. The LIDAR's slave address must be configurable somehow.

[Alan Anderson]

Originally Posted by muvicado

Maybe I'm missing something. The LIDAR's slave address must be configurable somehow.

The pre-release descriptions all talk vaguely about being able to control multiple devices on the I2C bus, but none of the available documentation I've been able to find mentions anything about configuring the slave address.

[muvicado]

Originally Posted by muvicado

Do you know if more than one LIDAR-Lite can be connected via CAN through the MXP's can bus?

The LIDAR-Lite appears to have a fixed slave address - 0xC4.

LIDAR-Lite Spec

Why would they not make it configurable? Seems like that would prevent one from being able to use multiple LIDAR-Lites on the same I2C bus.

Maybe I'm missing something. The LIDAR's slave address must be configurable somehow.

Okay, I discovered the slave address can't be changed on the current version of LIDAR_Lite. From PulsedLight's forum, I learned a work-around for this. Using a DIO pin for each LIDAR, connect pin 2 of connector J1 on the LIDAR to a dedicated DIO pin on the RIO, using this as a "device select" line. Just before and just after the Write/Read sequence to each LIDAR, set teh LIDAR's device select high and low, respectively. We will try this out, using a C++ application.