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

[DresnerRobotics]

Mon 11/22/2010 2:24 PM
Xevel has just posted


Well, if it was available outside of North America, more of us could work on it...

Or I could get one from ebay, for $500+$150 shipping...

Browse: Supa Iga Catalogue and ALDI Special Buys on Catalogue AU.

[DresnerRobotics]

Mon 11/22/2010 2:45 PM
RobotNV has just posted

Also, I figured the rangefinder is running at a constant rate, and it's up to the user to rotate the assembly at a fixed rate and determine when it rotates through a full 360 degrees.

This is pretty cool since it can allow to increase resolution by decreasing speed of rotation.

[DresnerRobotics]

Mon 11/22/2010 4:08 PM
lnxfergy has just posted

This is pretty cool since it can allow to increase resolution by decreasing speed of rotation.

If I remember correctly from the ICRA paper, there is a 360-line encoder, which is used to time the output, thus you probably can't increase the resolution....

-Fergs

[DresnerRobotics]

Mon 11/22/2010 4:09 PM
Xevel has just posted

(Missing pictures unfortunately, going to try to get this restored)

Just a quick visualisation of some of the data Sparkfun provided.

I dumped the data from the logic analyser software, then separated each byte x, x+1, x+2 and x+3 to visualize their values. I used this pattern because the data seemed to be grouped by burst of 4 bytes.

Looks like the period is of 1446 bytes. Every 1446 bytes, theire seems to be a remarquable pattern where bytes x+1 and x+3 are above 0xFF, which is basically the only time these bytes have the MSB set. Maybe this could be something like the sync command... I'll have a look on the other scans.

The ods is provided too, just be careful : it's one of the ugliest thing you could see today...

If anyone has a XV-11 and is ready to team up... In the meantime I'll just post here.

[DresnerRobotics]

Mon 11/22/2010 7:07 PM
Nammo has just posted


Very nice. Looks just like the output Neato showed at the Homebrew Robotics Club in Mountain View last October.

- Nammo

[DresnerRobotics]

Mon 11/22/2010 7:14 PM
RobotNV has just posted

If I remember correctly from the ICRA paper, there is a 360-line encoder, which is used to time the output, thus you probably can't increase the resolution....

-Fergs

Why does encoder need to have the same resolution as the range readings?
If the speed is the same, then encoder resolution doesn't matter much.
If you rotate 360 degrees twice as slow, aren't you going to get twice as many points?

[DresnerRobotics]

Mon 11/22/2010 7:15 PM
lnxfergy has just posted


The encoder triggers the frame capture. You only get 1 read for each tick of the encoder.

-Fergs

[DresnerRobotics]

Mon 11/22/2010 7:16 PM
lnxfergy has just posted

Ok, hacked a few hours, I have some results !

http://forums.trossenrobotics.com/ga...original=1&c=3

See attachement for ugly C# code... To compile it, you need to have VisualStudio2008 and install the Microsoft Chart Control library, sorry :/

EDIT : I'm going to bed now, but before some explanation for those who don't want to have a look at my ugly hacks...

I considered the data as being formated as follows :

5A A5 00 C0 <XX> D1 <data>

where <XX> has varying values around 9E, and <data> is composed of the 1440 next bytes.

Inside the data part, I considered it being grouped by 4:

byte 0 : <DIST 7:0>
byte 1 : <unknown><DIST 11:8>
byte 2 : <unknown>
byte 3 : <unknown>

I got the graph shown by plotting DIST for each degree, 0 to 359 on a polar graph. I reduced the samples to one rotation for testing, but it would be trivial to do it for all recorded rotations.

The yellowish dots are from the "NoShield" data from sparkfun, ths small reddish circle is from "shield13point87".

EDIT n+1 : better image : http://forums.trossenrobotics.com/ga...original=1&c=3

Can we get a screen capture? For those that don't want to compile the code?
-Fergs

[DresnerRobotics]

Mon 11/22/2010 9:03 PM
Xevel has just posted

You were faster than me posting this... I got similar conclusions but not totally agree with just using 12 bits for distance... Why do you think this?

From the logged data I think that minimum measurable distance is given by value 0xAC and that is 172 decimal. In the paper them states that minimum was 5cm and maximum 6m. So if we assume that 5cm = 172 --> 6000cm = 206400 so it's necessary at least 18bits.

Can you try to plot using more bits?

First, it seems you made a typo : 6m = 600cm, not 600. So folowing your formula, 6m would be 20640, and that would fit on 15 bits.

I don"t think the sensor has that much resolution... they talk about an error inferior to 3cm at 600cm, that's <0.5%. what would possibly be the use of using more bits for coding the distance than what can be mesured ?

Anyway, that's not how I cam to this result : I just had a look at the graphs of the data I made, and saw:

- that X looked continuous when X+1 was constant => X+1 could contain the most significant bits and X the least significant ones

- that X+1 had small variations around thresholds => it could be in two parts, the small variations of X+1 seemed to corelate to the big variations of X, while the big variations of X+1 seemed not to be.

- that when I tested, using only the value of X looked nice but obviously something was missing, using (X+1 << 8) | X outputed some useless results (everything grouped arround very large thresholds), and using the formula I propose it looked plausible.

Not very scientific, but I don't have any other data to cross-reference...

[DresnerRobotics]

Mon 11/22/2010 9:18 PM
tmig has just posted


I too have come to pretty much the same conclusion for the protocol based on the data from sparkfun and was writing it up as I saw your posts copme up. Oh well. My further refinement is that the data is just a four byte unsigned long. This needs to be correlated to a given distance for calibration. I believe since both the closed data sets were the same data that the sensor has a minimum working distance and that is what triggered the error. After all, if the distance measured is smaller than the outline of the robot, the robot will have serious trouble maneuvering.

It would be a useful test if it could be put in a large box and get the data from that. Also a barrel of sufficient diameter might work.

There are 360 long integers for each degree, 4 bytes each, each corresponding to a distance. I do not have access to the more powerful software for graphing that I have at work, but by then it should be all figured out anyway.