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

[Tyberius]

Tue 11/23/2010 1:29 PM
shimniok has just posted


FJ_Sanchez -- totally agree. Per your plot they must be related.

Here's a full plot of header vs. 5th byte... the first part of the curve looks pretty smooth, and it gets nasty after.

Image: http://lh6.ggpht.com/_59HHJuZw_Rk/TO..._timestamp.jpg

The interval vs. 5th byte/3rd long gets quite a bit better if I just plot the first, smooth, 10ms (first 50 data points)

Image: http://lh6.ggpht.com/_59HHJuZw_Rk/TO...rd_first50.jpg

[Tyberius]

Tue 11/23/2010 1:38 PM
shimniok has just posted

Not to derail (ignore me if need be) but does anyone know what CMOS imager is being used ?? It would have to be wicked fast (3600 fps?!) right? Any speculation?

[Tyberius]

Tue 11/23/2010 1:39 PM
Xevel has just posted


The correlation between the 5th byte and turn speed looks good, good job

Xevel -- what tool are you using for graphing the polar chart and the youtube vid (cool vid btw, nice work!)

For the earliest results, I used the charts of the Microsoft Chart Control library.

For the rest, including the video, I use the points cloud of VPython
(http://vpython.org/contents/docs/visual/points.html), and I compute the positions of the points in 3D as :
Code:
---------
pos = (dist * cos(angle), dist * sin(angle), 0)
---------

[Tyberius]

Tue 11/23/2010 2:01 PM
lnxfergy has just posted

Not to derail (ignore me if need be) but does anyone know what CMOS imager is being used ?? It would have to be wicked fast (3600 fps?!) right? Any speculation?

According to the IEEE paper, they limited it to only 10 vertical lines -- that can account for most of the speed up.

-Fergs

[Tyberius]

Tue 11/23/2010 2:47 PM
FJ_Sanchez has just posted

I think it's right also... https://sites.google.com/site/chengl...-matlab-script

[Tyberius]

Tue 11/23/2010 2:56 PM
Nammo has just posted


Is anyone here using their own unit, or just getting data from the Sparkfun unit?

I can understand not being too excited about voiding warranties...

- Nammo

[Tyberius]

Okay guys, restored this the best that I could. PHEW, that was painful.

I may have lost some images/video, so if anyone sees something missing, PLEASE post a 'recap' with any relevant info. Thanks!

Please proceed with the discussion, and my apologies for the hiccup!

[FJ_Sanchez]

Thank you for your job! I was worried of losing this information

Kudos for you!

[Xevel]

Hooray ! \o/ Thanks Tyberius !

In the meantime I posted my python code here : https://github.com/Xevel/NXV11
and synthesized the info I had here : https://github.com/Xevel/NXV11/wiki

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 :

Looping through 7 samples:
[ame="http://www.youtube.com/watch?v=vneaaKsa2Dw"]YouTube - XV-11 Lidar - live distance update with spoofed data[/ame]

Looping through 31 samples (limited by the max size of an array, 32k...)
[ame="http://www.youtube.com/watch?v=BDxdUr76BDA"]YouTube - XV-11 Lidar - Live Distance Update[/ame]






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.

[Tyberius]

Thanks for the recap Xevel! + rep from me, excellent work!