| |
In lugnet.robotics, Ben Jackson (yes, that's me, replying to my own post)
writes:
> Maybe I'll print some Code 39 and see if I can write some NQC to scan it
Well, I tried this, and it's hopeless. The RCX can't poll the sensor nearly
fast enough, and even if it could you'd need a lens to focus the sensor better.
> You'd need a full time counter task to simulate a fast clock.
Instead of using my idea, I took the suggestion of someone else and just used a
loop with a counter. It is shockingly slow. This turns out to be the real
limitation. I found I could reliably detect a bar 4-5mm wide, but even
reasonably slow scanning speeds hit the point where a single bar passes during
ONE LOOP INTERATION! If you make wide bars 3x the width of the narrow bars
they can be reliably detected.
So I devised a simple scheme for a lead-in plus a series of bits and one parity
bit. The maximum length of such a barcode (to represent the number 127) with
5mm spacing is 127mm (strange coincidence). For comparison, 16 studs is
128mm. The shortest number (0) is 55mm and all of the single-bit numbers (1,
2, 4, 8, etc) are just 65mm (1mm longer than 8 studs) so you *could* choose
such numbers for short cars. If you only wanted car *type* and not a unique ID
you could use fewer bits which would shorten things up. I could also try
"compression" with Lempel-Ziv which would make some numbers much shorter at the
cost of making others much longer.
> Then you wait for a quiet leading zone and the initial set of light->dark,
> dark->light, light->dark transitions. This gives you baselines for the pulse
> widths. Then you measure each set of transitions and decide if you saw a wide
> or a narrow bar/gap and decode. When you see the end symbol check the
> checksum and then beep pleasantly at about 1600Hz. :-)
That was my original description and it works pretty well. The code adapts
very well to different scanning speeds, as long as they are relatively slow.
Currently I'm just using datalog to store successful scans. In a real
application I guess you'd want a second light sensor to scan off of a
preprinted sheet (to select cars for your train! although I guess if you have
no points you have solved this problem already -- just start the engine and
eventually all the rolling stock will be coupled to it!).
Anyway, I'm going to get out some train cars (luckily I stored them all built!)
and try this in action. I also want to run this on a Scout and see if it can
do better (by looping faster). LegOS is another possibility, if it could
execute the main loop faster. I'll post some code later. Any suggestions on
how to distribute a program which can make the barcodes I've devised? So far
I've been hand drawing them, but I could write the postscript to make a sheet
of every barcode.
--Ben
PS -- I'll accept track in payment ;-)
|
|
Message is in Reply To:
 | | Re: how does a bar code reader work?
|
| This is going to be tricky without real arrays. LegOS may be the only option. You'll be looking for a start symbol (maybe just one framing bit, sometimes a legal character in the barcode set and sometimes just a pattern). Once you identify it you (...) (25 years ago, 30-Dec-99, to lugnet.robotics, lugnet.trains)
|
11 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
