Notifications
Clear all

Dirt cheap SLAM Lidar

5 Posts
4 Users
1 Reactions
5,507 Views
Evile
(@evile)
Member
Joined: 5 years ago
Posts: 12
Topic starter  

Hitachi make the HLS-LFCD2 scanning LIDAR for manufacturers to integrate into robot vacuums and similar products it's incredibly cheap at around £30 (ebay) £36 (amazon). 

I got one on spec just to have a look at it, and it looks very similar to the RPLidar product. There isn't much data available to the public about it, I found a datasheet.

http://emanual.robotis.com/assets/docs/LDS_Basic_Specification.pdf

And it's also used in the turtlebot, integrated through ROS

http://wiki.ros.org/hls_lfcd_lds_driver
but I'm trying to write an Arduino library for it by using the ROS driver and RPLidar library as a reference. Maybe someone with a bit more time and skill in C++ would like to have a bash?

Anyway I thought you all might like to know about it as it offers significant savings over the RPLIDAR range.


   
Duce robot reacted
Quote
byron
(@byron)
No Title
Joined: 5 years ago
Posts: 1136
 

@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.


   
ReplyQuote
Evile
(@evile)
Member
Joined: 5 years ago
Posts: 12
Topic starter  

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.


   
ReplyQuote
(@ezward)
Member
Joined: 4 years ago
Posts: 16
 

@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.

This post was modified 4 years ago 2 times by Ezward

   
ReplyQuote
Duce robot
(@duce-robot)
Member
Joined: 5 years ago
Posts: 686
 

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.


   
ReplyQuote