Re: Barcodes & error detection

In lugnet.robotics, [email protected] wrote:

> One suggestion that may improve your reliability
> is to use colour transitions rather than just
> colours.

   I actually started out this way, before getting lost in the number of
combinations. After you suggested it, I may actually reconsider, because:

> This would mean, however, that you would need
> more strips.

   Perhaps less; right now the reflective strips don't really encode
information, they just signal "here's a new bit coming up". By coding with the
transitions, a strip has two edges and therefore more than one "state" per
strip. True, these transitions aren't independent (the trailing edge of one
strip only encodes information due to the "interaction" with the leading edge of
the following strip), and many are undetectable (black-->black, certainly, but
also any sequence ending in a white strip would be indistinguishable from a
"return to background color") or impossible (for instance, the transition from a
black strip can only be to a brighter strip, so it's not useful to encode
information either). But, you got me thinking...

   Code any light-->dark transition as a "1", & a dark-->light transition as a
"0". Assume every edge sequence will begin and end with a white strip (the
barcodes are on a white background). Discard any strip sequence where the final
strip is white (the final strip would be indistinguishable from background). By
using up to six strips (currently, a 3-bit barcode uses six strips, three
reflective and three that are black or white as bitcodes), I can get 41 unique
"words" (as opposed to only 13 in the "old style").
   If I could distinguish a black-->white transition from a black-->reflective
transition, I could get a lot more codes. But it turns out distinguishing those
type of transitions is the reason I originally dumped this idea - it wasn't as
easy as I thought it would be. And this still might be a problem (a black strip
followed by a reflective strip should be a single dark-->light transition, but
it could be misinterpreted as two succesive dark-->light transitions given the
intermediate state). But since the bulk of the strips now act as the "spacer"
between bits, it might be easier to do.

> Change this logic to be a BW transition=0 and a
> WB transition=1, the same 0110 would be:
> |BW|WB|WB|BW

   The problem is it depends on timing. As the light sensor moves from a
reflective strip to a black strip, there is always a transition state where the
sensor value is intermediate and mistaken for white. Discarding short
transitions would work, but only if the strips in the barcode are significantly
wider than the "area" in the transitions between strips. In practice, this ended
up with strips being 3-4 studs wide, and the barcodes got really long, and not
terribly accurate.

> An alternate approach would be to use two light
> sensors and alternate the colours in parallel

   Perhaps, but I've no inputs to spare (Gus currently uses two light sensors, a
rotation sensor, and a touch sensor).

> don't know if either of these would
> improve the light sensor accuracy.

   I'm not sure either... yet. But you got me thinking at right angles to my
previous approach, and that's likely to yield some interesting observations at
the very least.

   Dang. I hate making all these stupid barcodes, but this really needs to be
looked at closer. Start with the existing barcodes I guess.

-- 
Brian Davis