LIDAR Sensor has arrived!

[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

[seg9585]

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

tech2077, are you having any luck with this code? When I attempt to run I get zero distance data. Also, the i2c.read() function returned "true" (aborted). I'm passing in Port.kOnBoard and the sensor is plugged into the I2C port on the roboRio

[tech2077]

Strange, it has worked for me. I've been using the mxp port so far, so I'll test with the on board one.

[tech2077]

Right now it seems that only the MXP port is supported with the LIDAR, I'm still investigating, but using the same power source and code, only the MXP I2C port will return data.

[Poseidon5817]

Dimensions: 21 X 48.3 X 35.5 mm
• Performance: Range: 0-40m Laser Emitter
• Accuracy: +/- 0.025m
• Power: 5vdc, <100ma
• Acquisition Time: < 0.02 sec
• Rep Rate: 1-100Hz
• Interface: I2C or PWM
•Max Operating Temp.: 70° C
•Eye safe, laser hazard free

Works up to 40 m, + or - 2.5 cm, <20 ms acquisition time.

We have ordered one.

[seg9585]

Originally Posted by tech2077

Right now it seems that only the MXP port is supported with the LIDAR, I'm still investigating, but using the same power source and code, only the MXP I2C port will return data.

Ah, thank you! I originally wrote up my own test code without the scheduler implementation and couldn't get it to work in this port, so I switched to yours with similar results. They seem to work just fine in the expansion port, making me curious if the I2C onboard has a bug or is otherwise disabled on the roboRio. I'll contact NI and let them know.
For now, works perfectly on the MXP, thanks again!

[JesseK]

I might get one of these to poke around with. Our programming team is talking crazy talk for autonomous, and I don't know that the drive train will have quite the precision they require to squeak in under 15 seconds.

Anyone tried this out on diamond plate? I bet more than my team has felt a twinge of failure with ultrasonics when moving from the lab to the field.

[tech2077]

Originally Posted by seg9585

Ah, thank you! I originally wrote up my own test code without the scheduler implementation and couldn't get it to work in this port, so I switched to yours with similar results. They seem to work just fine in the expansion port, making me curious if the I2C onboard has a bug or is otherwise disabled on the roboRio. I'll contact NI and let them know.
For now, works perfectly on the MXP, thanks again!

Poking around the linux side with i2ctools there are definitive read/write errors showing up for the onboard port, so I'll be sure to let them know.

Originally Posted by JesseK

I might get one of these to poke around with. Our programming team is talking crazy talk for autonomous, and I don't know that the drive train will have quite the precision they require to squeak in under 15 seconds.

Anyone tried this out on diamond plate? I bet more than my team has felt a twinge of failure with ultrasonics when moving from the lab to the field.

Anything solid and IR opaque should have good data from this sensor. The diamond plate will definitely give good distance readings, but totes and lexan still need to be tested.

[JesseK]

Originally Posted by tech2077

Anything solid and IR opaque should have good data from this sensor. The diamond plate will definitely give good distance readings, but totes and lexan still need to be tested.

The raised diamonds on the diamond plate caused excessive backscatter with the sonar sensor. A better way to put the question is, do the diamond shapes cause the Lidar laser to reflect/refract as the robot moves down the wall next to the diamond plate? If so, is it momentary and how long does it take to recover?

[tech2077]

Originally Posted by JesseK

The raised diamonds on the diamond plate caused excessive backscatter with the sonar sensor. A better way to put the question is, do the diamond shapes cause the Lidar laser to reflect/refract as the robot moves down the wall next to the diamond plate? If so, is it momentary and how long does it take to recover?

I'll do testing on this as soon as I can, but from what I have tested most surfaces do not refract it enough to actually change the measurements. The only situations I've noticed a problem is with a few thin plastics they are entirely transparent to the IR laser.

[seg9585]

Originally Posted by tech2077

I'll do testing on this as soon as I can, but from what I have tested most surfaces do not refract it enough to actually change the measurements. The only situations I've noticed a problem is with a few thin plastics they are entirely transparent to the IR laser.

Based on discussion with NI, I'm led to believe the problem may be specific to Java and not the controller itself. NI claims their ADXL345 accelerometer works just fine with I2C when using LabView modules, but I can't get the accelerometer to work with the onboard port either when using Java.

https://decibel.ni.com/content/thread/26778

[Joe Ross]

Can you try in C++ as well (either the accelerometer or the LIDAR). Java and C++ share a lot of code, and that might help pinpoint where the issue is.

[tech2077]

Originally Posted by Joe Ross

Can you try in C++ as well (either the accelerometer or the LIDAR). Java and C++ share a lot of code, and that might help pinpoint where the issue is.

Verified to have the same error.

[marshall]

We picked up one of these... it seems very sensitive to glossy/reflective surfaces. Much more so than the lidar system we yanked from a Neato vacuum robot. Not sure what others are seeing. We haven't dived into the sample code yet beyond running it.

[jhersh]

Originally Posted by tech2077

Poking around the linux side with i2ctools there are definitive read/write errors showing up for the onboard port, so I'll be sure to let them know.

What port in Linux are you referring to? What is the dev path you are using?