Laser Range Finder: Lidar Lite vs SF02
prof_braino
Posts: 4,313
I received an email that LIDAR-Lite is finally shipping. I'm very interested to compare this to the SF02, and getting ready to set up testing I maybe biased towards the SF02, and wish to ensure my testing is not skewed or influenced by my subjective opinions.
Is anybody else expecting or interested in LIDAR-Lite? Maybe we can compare notes and reproduce each other's experiments.
In any case this should be fun and interesting to determine which niche each items is best suited.
Is anybody else expecting or interested in LIDAR-Lite? Maybe we can compare notes and reproduce each other's experiments.
In any case this should be fun and interesting to determine which niche each items is best suited.
Comments
The fine data sheet: http://pulsedlight3d.com/pl3d/wp-content/uploads/2014/11/LIDAR-Lite.pdf link does not contain a data sheet, its only a product brochure. Annoying.
The Dragon Innovations site does not have the forum working. They are in fact updating the docs as I'm working on this, the operators manual I started with on Sunday now has a date of Monday. I'm going to try contacting the developers again. They did not respond to my offer to review the requirements and docs at the beginning of the project. One would think they'd at least want to get the docs ready before making them public.
I'm interested in a LIDAR type product and planned to dive in once I get past some of my current projects. Right now working on an I2C IR non-contact thermometer, the MLX90614 so there might be some overlap for me playing with the LIDAR-Lite.
Here's what I've found thus far:
From the 3d Robotics Store this Laser looks to be $72. The range is spec'd at 40meters but the manufacture's site brochure says 60 meters for the laser 905nm. So the $72 seems to buy a 905nm and not the LED type with 850nm and less range. Is this the version you have? How long did you have to wait before it shipped?
It appears the User Manual just came out and is available at the Pulsed Light website. The date is Nov 10, 2014 and that's the date of their last revision on the webpage-- hopefully all those changes made it into the new manual. One I noticed was:
"October 24th 2014 – Default I2C Address Change. Added registers for Software/Firmware Versions. Typo corrections too numerous to mention…."
The brochure says the SA is 0x84 and the manual says it is 0xC4 (page 3). I might be mistaken, but I think I2C address are 0 - 0x7F. The Parallax software shifts the SA addr left 1 such that only 7 bits are actually used. The addr might actually need to be 0x62 or if you use 0b11000100 it doesn't seem to shift binary. The MSB might be a command bit.
BTW I was thinking of writing a routine that would scan an I2C bus looking for ACKs and build a list of the valid addresses it found. I had a heck of a time getting the I2C to work until I added an "input(pin)" on the SDA line after the "i2c_busy". After the "i2c_busy" the SDA output was forcing a logic zero, so I changed it to input letting the pin float high through the 10k pullup.
Also I noticed in the brochure the part has a PWM output in parallel with the serial output. Coming in the same line is a trigger-- do these signals trip over each other? Are you getting the PWM output?
If the price is real I might be interested in comparing notes. I'm just starting out in simpleIDE C and wondering what you're using, Spin perhaps? I think it will be awhile before I start with Spin but I would like to get my feet wet with PASM.
Anyway, that should let you know what's on my mind.
Dom..
http://pulsedlight3d.com/pl3d/wp-content/uploads/2014/11/LIDAR-Lite-Operating-Manual.pdf
https://store.3drobotics.com/products/lidar-lite/
Note the slave address they're using. HA!
Dom..
prof_braino,
I've had problems getting the MLX talking to the 12c bus and found that the i2c_busy locked up my device. After reading more about i2c protocols it seemed the arbitration in the MLX prevented further communication after the i2c_busy queried the bus. According to the documentation the bus should be released with a stop. Adding the i2c_stop after the i2c_busy made it work reliably.
i2c_busy(busID, slaveAddr);
i2c_stop(busID);
Dom..
[ that command sequence is "put value 0x04 in register 0x00" ]
Does anyone know if the Master is specificed to wait for the Slave to come back,would this be "wait until Slave sends and ACK" or similar?
The Propforth I2C just goes fast as prossible, and the other devices we've used always responsed in time.
If you would like to see my test code and notes it is posted at:
http://code.google.com/p/propforth/wiki/LIDARLite
Tomorrow I hope to do the side by side comparison with SF02
Also: the Slave address I used was 0xC4 to send and 0xC5 to recive. That "7 bit address" shifted, and least significant bit designating read or write, always throughs me for a loop. I bet if they put a little more effort into it, they could make it a little more confusing. Or maybe not.
At night, the LIDAR-Lite measurements become invalid around 16 meters. I definitely got solid readings at 15 meters. I also saw a few at 17 and 18 meters, but performance was not consistent above 16.
At night, the SF02 measurements become invalid around 40 meters. Performance was consistent up to 31 meters. At that distance I had to stop walking and aim carefully. Then readings were again consistent to about 39 meters. I started getting invalid readings between 39 and 41 meters. I did not get anything above 42 meters.
Tomorrw: Daylight testing
I offered comments on the documentation. One item is the doc state the device operated at 2.7 volts to 6.0 volts. I did not want to fry my quickstart, so I ran it off the LIDAR Lite off the prop 3.3 volts pin. The range was very reduced from the expected range. The docs did NOT state the expected range at the lower voltage, only the max range at 5.0 volts. The guys pointed out that the stated range (40 meters, I think I saw 40 to 60 meters ar least once) is only when the part is run at 5 volts. I don't think that was in the docs, I think it should be.
I've convinced myself the prop as a 3.3 volt I2C Master will not damage and not be damaged by talking to a 5.0 volts slave (can somebody verify? I'm not an expert on I2C). I measure my USB output voltage (4.3 volts with quickstart running) and did the math and I think the LIDAR will be able to listen and talk to the prop when connected to the quickstart Vin.
[ I2C HI = Vin * 0.& =4.3 *0.7 = 3.01, and I2C lo = 0.3 * Vin = 0.3 * 4.3 = 1.29, and this is ok for both devices]
While it might not get the full specified range, I can expect to see a noticeable improvement over the 3.3 volts results.
Its snowing here, so I won't be testing outdoors until the weather is nicer.
can compare notes and reproduce each other's experiments."
I got mine a few weeks ago. I understand your extreme apprehension at frying something with 5v, especially the Lidar Lite as it appears bound to be in a state of unobtainium for quite some time.
I have only done limited testing and my results with LL powered at 3.3v vs. 5v seem to roughly mirror yours.
Two thoughts:
1) Using level translation. Can't the Prop take a 5v input if series coupled via a 1k or greater resistor?
2) You probably know that the Lidar Lite can do pulse-width output single-shot or free-run.
Rick In Plano Texas
I now think that using Prop as 3.3v master and LL as 5.0 volt slave is ok, it will not hurt either.
The 1k current limiting resistor is NOT needed with I2C (I think) and in fact rounds the edges too much and made it NOT work. Now I use plain wires.
I'm using LL with Prop Quickstart on a laptop whose USB measures at 4.3 v, so the slave can detect the master's high and low.
I did not get the LL to do any free run, I found that I have to send the measure command every time I ask for a byte. And that I need to wait 33 ms (when running the LL at 3.3v). But it might go down to 20ms (as stated in the data sheet) now that LL is at 5.0 volts.
LL guys asked that I hold offr my testing until they have a chance to make changes to the datasheet, I made many suggestions and asked for many changes.
PM me if you want to compare notes privately.
The Prop's clamping diodes will end up pulling the I2C bus down to about 4.2V but this usually isn't a problem for 5V devices.
It doesn't matter which device is the master or slave. They both only pull the line low. The only high logic states is set by the pull-up resistors.
You generally don't want a current limiting resistor in series on an I2C line since it acts as a voltage divider.
I too am working with the SF02 and soon the LIDAR Lite. I'm building an "open source" scanner. My discussion can be found here: http://diydrones.com/group/ardurover-user-group/forum/topics/contributing-to-giving-sight-to-av-s
RoboBill
I'm hoping to use a laser rangefinder to scan the ground ahead of my robot for obstacles.
I thought this video was interesting. It sure scanned the area faster than my cheap servo scanner did.
I'm still undecided about what sort of scanning hardware is required in order to detect obstacles.
The gimbal I'm using cost less than $3 and servos were only a few dollars each.
I just ordered a Lidar Lite. It looks like I'll be joining you in comparing the two sensors.
IMO, having access to laser rangefinders is a very exciting development in hobby robotics.
BTW, I've written a couple of Spin objects which allows a Propeller to act as a serial bridge for the SF02. There are links to these objects in this thread. The code used to scan the area in front of the robot is located in my "Cleaver" GitHub repository.
I just got my lidar lite units; which I2C object are you using to communicate with it? Hopefully I can get it working sometime this weekend.
Mine arrived yesterday. I haven't powered it up yet. Hopefully I'll try it out tomorrow. If/when I get it working, I'll post the code.
If I need to, I can load an Arduino with some sample code and monitor the exchange with a logic analyzer. The Arduino plus LA never fails me (as long as the Arduino code works).
The following code compiles fine but doesn't return the correct distance (always returns 65535). I've tried changing the device address and removing/adding pull up resistors with no change.
LL_DEmo.spin
i2c.SPIN
Also note that pull ups are not required (I suspect the Lidar Lite has internal pull up resistors).
LL2.zip
Fantastic!
Thank you very much for sharing your work. I really appreciate it.