Re: The Open Lidar Project - Hack the Neato XV-11 Lidar for a $200 Bounty!

But for posterity's sake, here is a little recap of my side of the story including the code packages that were lost:

Started by looking at the data from Sparkfun with the Saleae Logic Analyser software, it looks that bytes are packed 4 by four...

Plotted the data using OpenOffice Calc... - I don't recommend it when you have more than a few thousand samples, even on very recent hardware - and noticed the period was 1446 bytes (XV-11_NoShield_26-27s.zip):

Coded an ugly little software using C# and the Microsoft Chart Control lib (XV-11_Test-0.1.1-Xevel.zip) and got that from the data:

At the time, I supposed the distance data were on 12 bits, but in fact it is probably on 13 or 14 bits(see here). Need more test data.

Identified what seems to be two flags, one for "invalid reading" (red) and one I still don't know what it may be (green). The blue dots don't have any of these two flags set.

As the application was Windows only and not really well done, I started from scratch a (cross-plateform) Python script doing the same thing. The code and its next evolutions can be found here https://github.com/Xevel/NXV11 , attached is the current version (XV-11_Test-0.2.4.zip). See the README.txt for use.

In order to test the software in similar conditions to what would be real operating with the lidar hooked to an usb to serial board, I made a little arduino script that fakes being the lidar, and outputs on the COM port data from the Sparkfun NoShield recording. (code included in 0.2.4) And here is what it looks like :

On the "not published here yet" front, it seems that according to chenglung, the distance data is in mm. This would put the tests Sparkfun did in a room of around 3.3m per 3.9m (11ft per 13 ft), and this looks acceptable to me. I think it's a reasonable assumption to think that the lidar is factory calibrated and that the onboard DSP takes care of the data interpretation for us, and outputs nice values.

Also, from the video posted by chenglung, it seems that the Sparkfun guys rotated the lidar while recording. This would explain the discrepancies between the time it takes to make a turn and the 5th byte value that shimniok pointed out... Or it could not be that at all and maybe we should use the 5th byte to correct the output... More data needed I guess, once again.