Subject:
|
Re: Optical card reader for the RCX
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 28 Sep 2000 22:40:54 GMT
|
Original-From:
|
Steve Baker <sjbaker1@airmail*SayNoToSpam*.net>
|
Reply-To:
|
SJBAKER1@ihatespamAIRMAIL.NET
|
Viewed:
|
575 times
|
| |
|
|
Giacomo wrote:
> I'm trying to do a optical card reader using the light sensor of the RCX.
>
> I put on a 8x6 board different 2x1 smooth piecies of varios colors ,then i
> slice them near to the light sensor and i got different value depending of
> which color the sensor is seeing.
> I found that:
>
> black ones gives 31 to 34
> yellow and whithe ones gives 46-49
> blu ones 37-39
>
> and when there is nothing the value drops to 28-29.
>
> Now, i'm a bit in difficult way, because i could'nt find a way to correctly
> read the "card" : I'm using two main value, if the sensor reads more than
> 47, then it's a 1, if the value is under 47, it's a 0.
I think you would be better off looking for changes in brightness rather than
absolute values. That way, you could figure out what's going on without
having to worry about the speed at which the 'card' is moving past the detector.
With your scheme, you can't tell if a prolonged run of 'black' input is a number
of consecutive zero's - or just one zero being moved past very slowly.
Storing your information as CHANGES in colour pretty much solves that problem:
So, suppose we encode 1's and 0's as "the colour that follows a black stripe"
eg:
black - to - white == '1'
black - to - blue == '0'
anything else == ignored.
The nice thing about this is that it doesn't depend on the speed that the
card moves through the sensor. The bad thing is that you need more stripes
on the card to encode a particular number.
So feeding the sensor:
black/white/black/blue/black/white
...would produce the binary number 101 - which is 5 in decimal.
There is a problem with this though - if you are sliding a black strip,
followed by a white strip past the detector, you'll get a moment
when the sensor is seeing some black and some white at the same time.
This will fool the code above into thinking it's seeing 'blue' for
a short time. One simple way to nail that problem is to treat
'increasing brightness' as a "1" and 'decreasing brightness' as a "0".
blue -> white = "1"
blue -> black = "0"
Then there is no ambiguity. So you could use this code to read
the card:
command = 0 ; /* The number we are reading */
was_blue = FALSE ; /* Was the last thing we saw a blue stripe? */
num_bits = 0 ; /* How many bits have we read so far? */
while ( num_bits < 6 ) /* Or whatever */
{
sensor = read_the_sensor() ;
if ( sensor >= 34 && sensor <= 39 ) /* BLUE */
was_blue = TRUE ;
else
{
if ( was_blue && sensor >= 46 ) /* WHITE */
{
num_bits++ ;
command = ( command * 2 ) + 1 ;
was_blue = FALSE ;
}
else
if ( was_blue && sensor < 34 ) /* BLACK */
{
num_bits++ ;
command = ( command * 2 ) + 0 ;
was_blue = FALSE ;
}
}
}
(I havn't actually tested this - but I think it's OK)
As I've written this, the MOST significant bit is fed into
the reader first. 'command' will be a true binary number (in
this case, it'll be in the range 0..63 inclusive). You won't
need a particular 'start' code.
Unfortunately, this technique requires TWO stripes of colour
for each bit of data. You can actually get much better than
that by using the other transitions as alternative '1' and '0'
codes. eg:
black-to-white == 1
black-to-blue == 0
white-to-black == 1
white-to-blue == 0
blue-to-black == 1
blue-to-white == 0
...using that code, you'd only need one more stripe than you
need bits. However, the problem of the sensor seeing
black+white==blue means that you shouldn't encode any information
using black->white or black->blue or blue->white, etc....it gets
pretty messy.
Hence I would start with the simplest thing first!
Another thought is that you could presumably wire a touch
sensor in parallel with the light sensor to short it out
and get a solid zero. Then you could simply have black and
white strips as you did before and use the touch sensor to
pick up the gaps between them without using up any more
valuable RCX inputs. I don't think that's as elegant though.
Finally, 'real' card readers use a check digit to allow the
software to detect if it's mis-read the card. You might
want to consider doing that if the basic scheme isn't
working reliably.
--
Steve Baker HomeEmail: <sjbaker1@airmail.net>
WorkEmail: <sjbaker@link.com>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
Message is in Reply To:
 | | Optical card reader for the RCX
|
| Hello ! , I'm trying to do a optical card reader using the light sensor of the RCX. I put on a 8x6 board different 2x1 smooth piecies of varios colors ,then i slice them near to the light sensor and i got different value depending of which color the (...) (24 years ago, 28-Sep-00, to lugnet.robotics)
|
3 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
