Re: Barcodes & error detection

"Rob Roschewsk" <[email protected]>
Newsgroups gmane.comp.hardware.lego.robotics
Message-ID <000d01c5b41d$5e70a8e0$0716a8c0@carbon>
Thanks, you actually made me pull out one of my old comp sci texts :-)

I remembered studying this stuff many moons ago ....

Error detecting requires a "distance" between codes of at least TWO ... what 
this means is to detect a single bit error each code must be different from 
the other code by TWO Bits .... simple example a code set that consists of 
just "00" and "11" ... we know if we receive "01" or "10" we must have 
received an error but we don't know what the intended code was.

For error correcting codes the "distance" must be raised to 3 bits, so for 
our simple example our two codes are now "000" and "111" so if we encounter 
a single bit error we could receive "001", "010", "011", ... "110" the 
difference now is if we assume only a single bit error we can derive from 
say "001" that the last "1" is the error bit and the intended code was "000"

It is also said that a code with a distance of three is "single error 
correctable" and "double error detectable" however you can't distinguish 
from the two!

The most popular error correcting code is  "The Hamming Code" 
http://en.wikipedia.org/wiki/Hamming_code basically you add 3 check bits to 
4 data bits for a total of 7 bits per symbol.

--> Rob


----- Original Message ----- 
From: "Brian Davis" <[email protected]>
To: <[email protected]>
Sent: Wednesday, September 07, 2005 1:38 PM
Subject: Barcodes & error detection


   Some of you at BrickFest may have seen Gus, a small robotic forklift that 
was
one of my GBC modules. Gus had two problems at BrickFest. First, while the
codereading task was 98% accurate, that still means on average once every 16
circuits of the course Gus would mis-read a barcode, resulting in it doing..
something inappropriate (leaving a crate on the table, pushing over or
destroying a structure, or in at least one instance making inappropriate
advances on a member of the audience). Second, after a while the 
line-following
got rough, resulting in 180 degree turns on the line.
   To increase reliability I wanted to add error-detection. Suggestions? 
Right
now the codes are made of bits (black=1 white=0) with each bit preceeded by 
a
highly reflective strip (reflective thin tape used to repair flexible 
ducts -
great stuff, especially if they'd ever produce it without printing). Since 
each
bit is preceeded by a reflective flag, I can use variable length 'words' 
(i.e. -
'0' is distinguishable from '00').
   It turns out the errors seem to only be of the form of a '1' (black)
mistakenly read as a '0' (white). Currently I can check by making sure any 
code
read has "even parity" (an even number of '1's), and not using the odd 
parity
codes. But that means of the 30 codes it can currently read (up to 4 bits 
long)
I can only use 15 (the even parity ones).
   Question (finally): given the unique nature of the errors (only mistakes 
'1's
for '0's, never the converse) is there any better error-detecting (or, even
better yet, error-*correcting*) coding system I can use? There's plenty of
options, but I want something that minimizes the number of complexity of the
barcodes (I've got to make them by hand... no, I've not made them from LEGO
tiles *yet*, it's just tape on cardboard).

   And hey, while we're on the subject... any suggestion for tasks Gus 
should
try to accomplish? Loading/unloading crates on a conveyor and wharehousing
crates, as well as detecting when it has a full or empty crate, are either
implemented or planned. When I can figure out how to position the train
accurately enough I'll work on loading crates on the train.

-- 
Brian Davis
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.