Cricket

Jan 20, 2018

Cricket is a hobbyist-grade solution for 360º planar rangefinding and mapping. Intended to be a rudimentary imitation of LiDAR, we trade the precision optoelectronics for hardware that's dirt-cheap and readily accessible.

Let's start by reviewing hobbyist options for depth perception:

Time-of-Flight proximity sensors

ST produces some cool IR rangefinders. The VL53L0X sensor measures distances with millimeter accuracy, using roughly the same principle (time-of-flight, or ToF) that true LiDAR does. It's really impressive to see optical ToF implemented in a sub-$5 monolithic sensor, and this is definitely a space to watch. However, current downsides include limited max range (~2m in “optimal” conditions), relatively high (but dropping) cost, and most disappointingly, a very slow sample rate (~10 Hz) despite using optical ToF.

Sonar (Ultrasonic Modules)

There are plenty of cheap, easily sourced sonar modules available today. They range in price from <$1 to $5 (we're talking hobbyist-tier, not industrial) and get fairly good (+/- a few mm) accuracy out to 3 or even 5 meters. However, there are many constraints on the object you're trying to detect: it should be hard, large, and present a mostly uniform face perpendicular to the sensor. On top of that, your sample rate is limited by the speed of sound - I've seen 10-100 Hz in practice, and you can't go meaningfully faster without sacrificing max range.

Sharp IR proximity sensors

Sharp produces some interesting optical proximity sensors that have been around for a while. They work by shining an IR source on the subject, then looking for the reflection on a linear photodetector array. Downsides are a narrow range band (higher max comes with a higher min), low noise immunity, and a much smaller market supply keeping prices high.

Cricket A1

The “phalanx” arrangement does mean that the sensors partially occlude each other, but the transducers (the silver “cans”) are deep enough to make actual interference a non-issue.

While a circular board would only have about 40% more PCB area (130mm dia. vs. 98x98mm square), it ends up costing anywhere from 5 to 10 times more when we're talking prototype quantities. Almost all of the popular Chinese hobbyist PCB fabs have two major price break points: at 50x50mm and 100x100mm, i.e. there are flat rates for 2-layer boards up to those sizes. So, designing a board right up to those boundaries gets you an exceptional, sub-$10 deal, but step just a few mm over and you're looking at “custom” pricing in the $50+ range.

Speaking of interference, doesn't it seem like there should be tons of crosstalk here, given that each sensor is basically a speaker blasting a high-frequency, only vaguely directed chirp? In the geometry above, I'd certainly expect any given sensor to trigger its immediate neighbors, whose receiving transducers are only 45º off axis (the stated sensitivity cone for each sensor is ~30º, but at close range there's probably still some energy received well outside that). However, I'd guess that a sensor is pretty unlikely to trigger its diametric opposite, and maybe we can also hope for low/no interference to sensors rotated at least 90º away.

Based on this inuitive bet, Cricket was designed to trigger 4 out of its 8 sensors (the active set, separated by 90º) per cycle. The inactive sensors might hear off-target echoes, but they are ignored. Also, I figured that if just 90º offsets were too optimistic, I could always further split the cycle to only listen to sensors 180º apart - basically, we should be able to trade parallel read capabilities for noise (off-target reflections) immunity.

Tragically, I was inconsistent in mapping my trigger and echo buses, so long story short, this decision was made for me - Cricket A1 is fully serialized, only able to read a single sensor per cycle. And on each cycle, we have to either confirm that all the echoes returned, or wait long enough (25+ ms; 8+ meters at the speed of sound) to be sure that the echoes were otherwise lost or scattered. All up, Cricket A1 takes 200ms to get through a full 360º update, meaning a rather anemic scan rate of 5Hz.

Still, it's good to see real data coming back from all the sensors, and we can fix the speed issues in the next iteration.

Cricket A2

Cricket A2 fixes the bugs from A1, and starts to look like a good baseline implementation of our target features.