Dirt cheap SLAM Lidar

@evile

That looks a very good price and thanks for the heads up.  I cant help write an Arduino library but hope someone will pick this up.  I'm on a robot/electronics hiatus until I make further progress on house improvements but when I get back to this hobby I do hope theres a nice driver awaiting me ?.  Good luck with getting your driver completed.

I managed to work out a lot of the serial protocol today, its a bit different from the Turtlebot one which is an LDS-01, this isLDS-02 and it seems to have more commands.
I got stuck for a while for 2 reasons, it pretty much won't output data unless it's spinning, and I had it motionless, the motor control is separate on this one (unlike the LDS01), but it must have some kind of shaft encoder.So I wasted a lot of time on that.

Lost a couple of hours to a dodgy spec which says it's 3.3v serial, but I wasn't getting much out of it until I removed my logic level converter (but I might have had that wired up wrong).
Anyways, I can stop and start the data stream now, and there's some identifiable incrementing angle values, but the rest is garbage at the moment. I need to figure out if it's just a byte conversion problem, or something to do with the packet length or checksum. That will have to wait till tomorrow though.

@evile Any progress?  I'm thinking of getting one of these.  This ROS robot programming book specifically references a driver for the HLS-LFCD2, which is the one referenced in the specification you linked.  So you might want to check out that ROS book and find that particular driver. 

As for the specification, Section 5, DATA INFORMATION, indicates that it sends 42 bytes of data for each 6 degrees of rotation. Looking at the code in the robotis git, it runs as a state machine, first look for two sync bytes; an 0xFA follow by a 0xA0.  These two bytes are the first two bytes of the first 42 byte data frame; for 0 to 5 degrees.  This is followed by 59 more data frames, each with 42 bytes.

• For the first 42 byte data frame, the first two bytes are 0xFA followed by 0xA0 and the angle index is assumed to be zero
• For subsequent 42 byte data frames, the first byte is ignored (probably a zero?) and the next byte is the angle index (between zero and 60)
• Then 2 bytes low/high for RPM
• Then 6 packets of 3 @ 2 byte integers; one for each degree in this 6 degree data frame.  For each degree, the first integer is 'intensity' (presumably of the return signal), the second integer is dist_m (distance, in millimeters?) and the next two bytes are reserved.  So that's another 36 bytes.
• Then two bytes for checksum.

So that is a total of 42 bytes.  Byte order is an issue for the two byte integer values.  It's possible you may need to swap the bytes on your microprocessor when you read them into a 16bit integer.  I've done this in the past with a macro that I can redefine depending on the microprocessor architecture I'm running on.

So there are 60 total data frames in a 360 degree sweep for a total of 2520 bytes.

As for the angle index, it can be used to calculate the actual six degrees represented in the data. The angle index byte, which ranges from 0 to 60 is multiplied by 6, so the angle for the data frame is 6 * the angle index.  Except for the very first data frame, because the first two bytes are used for sync, we just assume the angle index of zero.

So it also looks like to start the motor you send one byte, the 'b' character.  To stop the motor, you send the 'e' character byte. 

Does that all sound correct?

So what do you think, is it worth getting one of these?  Thanks.

I'm trying to set up the ydlidar 360 but also there isn't a lot of direction but they do have good support so far but it was $73.00 not bad but a little tricky to set up thus far.