3D Robotics

### The Need for Low-Cost Sensors in Robotics

There's a very good post over at Hizook on the lessons of the hacked Kinect: Nutshell:

"The best solution to complex low cost sensing (or actuation for that matter) is to take advantage of affordable, mass-produced components, complementing them with the innovative use of software solutions that benefit from constantly declining prices of computation."

• P.S. Although we got yaw control to work with 8 pixels, it was still noisy and would occasionally lose lock and cause the helicopter to snap a fraction of a turn until the sensor would catch something else. Adding pixels around the yaw plane helped with this. But you shouldn't need more than a two or three digit number of pixels. The point, though, is that three digits of pixels is still a lot less than the seven digits from a contemporary megapixel camera, hence the "mismatch".
• @Randy,

In that particular instance the pixels were in fact about 8 degrees apart, but we were controlling the helicopter yaw angle to less than that. The trick is that the optical flow algorithms we were using can measure displacements to a fraction of a pixel. Apparently that was enough. (Honestly I was really surprised that only 8 pixels worked.)

This concept of detecting sub-pixel distances is often referred to as "hyperacuity". It comes up a lot in biological systems. There is one test called the "vernier test", where a horizontal black line on white paper is broken, with one half moved upwards a bit. Humans can detect a shift that is equivalent to (IIRC) about a tenth of a human photoreceptor, e.g. a tenth of a human "pixel". Although this may seem amazing, it is actually quite straight forward when you consider that the response curves of individual pixels to light vs. angle is not binary, but has tails that taper off as you get further away. What happens is that the ratio of light perceived by two adjacent photoreceptors/pixels can be used to provide an estimate of exactly where the associated object is to less than a pixel distance of precision. In our case, the "pixels" we used also had overlapping responses, thus the math behind the optical flow algorithm used (a 1D variation of the Srinivasan Image Interpolation algorithm, which was placed in the Arduino sketch of my recent post on injection molded optics) was able to detect sub pixel shifts.

Actually, your comment is not unrelated to the original post- one path to making something "inexpensive" is to make it "simple", and many times with a little math (or some wit) you can get a lot out of simple hardware.

• Developer

@Geoffrey,

I'm amazed that you can control yaw with only 8 pixels (of course I believe you because I believe I've seen the video).  I would have thought that the accuracy just wouldn't be there.  Say you have a 70 field of view, and only 8 pixels..surely you can only be accurate to 8 or 9 degrees.  Is that good enough?

Sorry, I realise this comment is slightly tangential to the central theme of this post.

• Chris- This was a good article to read and Thank You for posting it here. I left a comment there, and hope you don't mind if I copy the same below, as I feel strongly about this:

I enjoyed reading this article and fully agree that we roboticists, whether hobbyist, academic, or commercial, need a diverse collection of low-cost sensors. This actually applies to the DIY / homebrew community as a whole.

Repurposing or hacking already existing but inexpensive hardware is generally a good path. But in reality there can be a huge mismatch between the needs of a particular robot and the capabilities provided by the sensor. This mismatch can make engineering a solution difficult or impossible. Let me provide an example I know from vision:

Typically mass-produced image sensors are available from VGA (640x480) resolution and upwards through the megapixels nowadays. However the frame rates are generally limited to a few frames per second at high resolution and video at a lower resolution. This is understandable- these image sensors were developed for cellphone cameras or inexpensive digital cameras. However this set of specs (resolution and speed) are mismatched to what robots would need for many autonomous navigation tasks- We have found that a lower resolution combined with a higher frame yields better sensing, and in fact it is better to use less pixels when possible (otherwise you overload the processor). For example, for controlling the yaw angle of a 7" toy helicopter, we've performed this with as few as 8 (eight) pixels at a 130Hz frame rate, and we can make that same helicopter hover in place in a room using just 512 pixels total.

However to achieve these specs we had to design our own image sensor. This may sound complicated, until you realize that by just using hundreds or thousands of pixels rather than millions, you can use lower resolution (e.g. cheaper) processes, and can reduce the design time from person-years to person-months or even weeks. You can then have such designs prototyped for as little as \$6k (doable for a small entrepreneur) and, if it works, have it mass produced in the thousands for dollars or a few tens of dollars apiece. Furthermore since we designed the image sensor we could select the interface to work with any processor (or microcontroller) we want rather than be at the mercy of some choking standard.

If we had stuck with using off-the-shelf megapixel image sensors, then we would have had to use DSPs and FPGAs to perform the same, which would have drawn too much power and weighed too much to be useful.

Remember that "more" is not necessarily "better", and can often be much worse!

This basic approach- drastically reducing one particular specification of a sensor design enough so that it can be inexpensively prototyped and manufactured using older processes- is something that probably could be applied to Kinect-like sensors. It probably could be applied to a wide variety of other sensors, and fill the need for cheap sensors addressed in this article.

• I remember during the early 1990's the robotic community was hacking sonar (ranging & transducers) modules from Polaroid cameras and interfacing with the MIT Handyboard for autonomous navigation.
• 3D Robotics

Thanks, Travis. I think we can provide some economies of scale, but not nearly what Microsft/China/consumer electronics/phones can. I think our business is always going to be measured in thousands or maybe tens of thousands of units, not hundreds of thousands or millions. By the time autopilots are out then in those numbers, they'll be toys, not hacker gear.

That said, the economies of scale at thousands are not to be sniffed at, and as your post points out we leverage the consumer electronics economics by using the same sensors that you can find in phones and game consoles, so thing get cheaper without us having to do anything.

As for our own business, we didn't quite hit \$1m in 2010 (came a couple hundred k short) but will blow past it in 2011. We're running it at break-even now, rather than seeking to make a profit, because we're reinvesting any earnings into R&D for the benefit of the community, helping introduce better, cheaper, easier to use technology.

• Travis here (Hizook co-founder).  Thanks for the kind words, Chris!  The essay was written by Fred Nikgohar, the CEO of RoboDynamics -- the company that makes the TiLR telepresence robot.

The DIYdrones community can provide a really unique perspective about this issue: what role can / does the open hardware (hacker) community play in the development of personal (home) robots?  Is the early adopter and hacker community (alone) able to provide sufficient economies of scale?

I'm already super encouraged by the success of DIYdrones in this regard -- they're proving that UAV enthusiasts are sufficient to support a decent-sized company (speaking of, did you hit the \$1M projected revenue for 2010?).

I encourage people to hop over to the Hizook article and speak your mind!

Fred Nikgohar — Coming Soon