Subject:
|
Re: Struggling with encoder wheel
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 12 Apr 2001 04:52:05 GMT
|
Original-From:
|
Steve Baker <sjbaker1@airmail.!IHateSpam!net>
|
Reply-To:
|
SJBAKER1@stopspamAIRMAIL.NET
|
Viewed:
|
800 times
|
| |
|
|
Chris Osborn wrote:
> If I had room for a 64 element array...
Can't you just use a large switch() statement inside a function to
simulate a 64 element array? If none of the values in the array
ever change:
int array ( int x )
{
switch ( x )
{
case 0 : return element_0 ;
case 1 : return element_1 ;
case 2 : return element_2 ;
...lots of typing...
case 63: return element_63 ;
}
}
...(replace the element_N's in the example with whatever you were
going to put into your array) then wherever you had array[x], just
write array(x).
...I'm not sure if it'll be any faster - but it's certainly worth a try.
If it's not faster (because of it doing 64 comparison/if's in the worst case)
then you can use a binary 'if/else' tree:
int array ( int x )
{
return (( x < 32 ) ?
(( x < 16 ) ?
(( x < 8 ) ?
(( x < 4 ) ?
(( x < 2 ) ?
(( x == 0 ) ? element_0 : element_1 ) :
(( x == 2 ) ? element_2 : element_3 )
) :
(( x < 6 ) ?
(( x == 4 ) ? element_4 : element_5 ) :
(( x == 6 ) ? element_6 : element_7 )
)
) :
(( x < 12 ) ?
(( x < 10 ) ?
(( x == 8 ) ? element_8 : element_9 ) :
(( x == 10 ) ? element_10 : element_11 )
) :
(( x < 16 ) ?
(( x == 12 ) ? element_12 : element_13 ) :
(( x == 14 ) ? element_14 : element_15 )
)
)
) :
....lots more typing - nerves of steel - and a bad headache... ;
}
This looks ugly - but it should only take 6 comparison/if's to
decode any element of a 64 element array.
Anyway - the idea is to substitute DATA space (which is extremely
valuable in RCX) for CODE space (which is relatively plentiful).
> I also still have problems getting semi-accurate reads. As the wheel
> turns and the sensor sits between two different colors, it tends to
> see it as a different gray and misreads.
Yep - that's a problem with using a four colour system. We've talked
about this several times before in the context of bar-code readers...it's
the same problem.
I guess in your case, you should require that you see at least two consecutive
readings with about the same brightness or else you ignore the reading and
nudge the wheel around a bit more.
--
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
http://freeglut.sourceforge.net
|
|
Message has 1 Reply:
 | | Re: Struggling with encoder wheel
|
| (...) Hey, that was a great idea! I couldn't use ?/: to do it (NQC doesn't know those operators), had to actually write out all the if/else, but I actually just added it into my wheel generation program, so it printed out the function for me and I (...) (23 years ago, 12-Apr-01, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Struggling with encoder wheel
|
| (...) If I had room for a 64 element array, I'd just use that and make a lookup table. Unfortunately I don't, and I can't figure out a way to pack things in and still look them up with any speed. I also can't find any way to mathematically convert (...) (23 years ago, 12-Apr-01, to lugnet.robotics)
|
19 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
