deckard

Forgot to answer the question in my previous post. It probably has the laser scanner on board because it was already there before the Kinect was attached, used as the input to the SLAM system, and why bother to take it off? It gives better quality depth information (in 2D) so he may still need it.

The Hokuyo device is a linear scanning laser rangefinder with much better accuracy and range than stereo camera + texture projector (like the Kinect) sensors are achieving. It costs around $2000. That device itself was a revolution when it was released since previously everyone used SICK LMS devices at $20,000 each. Now most labs and some undergrad programs can afford the Hokuyo. The Hokuyo is less accurate than the SICK, but it's good enough for many purposes and, hey, it's affordable. The Kinect gives relatively noisy and and low-resolution data, but it's another order of magnitude cheaper AND it's 3D. More choice for the well-off and a whole new world for those without big research grants.

"What kind of application blocks on disk IO but nothing else for extended amounts of time? I'm having a hard time seeing how installing an SSD and maxing out your cores are terribly related otherwise"

Virtual memory paging to/from disk. This is probably why the new MacBook Airs feel faster than the CPU+RAM specs suggest.

Sure. We started doing this last summer, and this is the first paper accepted for publication that uses the method.

http://autonomy.cs.sfu.ca/doc/wawerla_icra10.pdf

and here's a draft of our paper on the methodology, with rationale.

Long paper: http://autonomy.cs.sfu.ca/doc/wawerla_submitted_2009.pdf

Original short workshop paper:

http://autonomy.cs.sfu.ca/doc/wawerla_rss09_workshop.pdf

For context, here's the lab's publication list:

http://autonomy.cs.sfu.ca/publications.html

We plan to continue this, even if the idea doesn't catch on.

Here's a practical solution I have proposed in my community (autonomous robots):

1. package code and data into tarball or VCS repo.; 2. place package on long-lived website; 3. compute SHA1 hash or similar from package (if git is used, this is the revision ID, conveniently); 4. publish the URI and hash in any paper that makes claims based on that code or data;

5. as a reviewer, prefer papers that follow this method, all else being equal; 6. as an editor, suggest that submissions use this method.

(Edit 2: In case it's not obvious, the purpose of the hash is to allow users to be pretty confident that the code they downloaded is indeed exactly the code used in the paper. By putting the hash in the paper, I make this promise. If I want to make an improved version available, I just put it up at the same site, but I must make the exact original available and identifiable as such. This simple method of ensuring identifiability is our contribution.)

My group does this with every paper. I have a paper describing this method coauthored with a student under review now at a good journal, and I'm looking forward to seeing the response. (Edit 1: see link in comment below)

I'd also appreciate feedback from HN.