| |
Hello,
one of my beautiful new rotation sensors was jammed right out of the
box. I built a robot to try out dynamic equilibrum, i.e., balancing a
weighted stick, only to notice that my construction didn't turn at all
because of sensor friction. That's when I tried the second sensor.
Anyway, I had a good look at the rotation sensor code. Most of the
previous approaches used the tedious state machine implementation I had
originally written, with minor modifications to state criteria. Those
criteria caused all our problems: for my working sensor, the A/D values
were actually outside the defined range in states 2 and 3.
Implementation issues caused us to make them overly narrow.
State criteria have been expanded:
0: 0xf000 - 0xffff (sufficient because only 0xffc0=max occurs)
1: 0xc000 - 0xdfff
2: 0x6000 - 0x7fff
3: 0x9000 - 0xafff
The new approach is table-driven. (All those algebra function tables and
compiler generator tools are really mixing up my brain. I have to find a
reason to use my new perfect hash function generator in legOS, too ;-)
This is how it works:
1. Convert A/D value to new state (using a shift and a table lookup)
2. If new state is valid, compute difference between new and old one
3. If difference is nonzero, retreive position change from another
table.
4. Write back changes if necessary.
Aren't tables a waste of space, Markus? No, actually all those switch
and else statements were. The tables take only 16+7=23 bytes. Overall,
we're saving some 200 bytes of binary, that is, 400 bytes of s-record
executable for the kernel.
I'm posting the new sensor code in the news section of the legOS site,
http://www.noga.de/legOS/. Release 0.2.3 won't arrive until we've made
this work for everybody.
Ciao,
Markus.
--
"Nieder mit den Zitaten!" -Markus L. Noga <markus@noga.de>
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
