|
[DPRG] Are representations what makes Can Can hard?
Subject: [DPRG] Are representations what makes Can Can hard?
From: Sluggy!
sluggy9912 at swbell.net
Date: Fri Dec 8 10:48:16 CST 2006
On Thu, 2006-12-07 at 19:03 -0600, Ed Paradis wrote:
> Well on the specific aspect of odometry, I think a lot of roboteers
> never impliment anything because they are afraid what they can build
> won't be ''good enough''.
>
> They spend weeks and months trying to find the perfect set of motors
> with encoders or knitpicking over complicated methods of connecting
> encoders to wheels. They fear low accuracy, low counts per
> revolution, etc etc
In my opinion, even one tick per revolution is better than no odometry.
However, in my particular case, I have put together (what seem to be)
good mechanical and analog systems, only to find that could not reliably
count the pulses *with my software skills using the platform I'd
chosen*.
At first, it was a case of too much power and not enough programming
skill trying to count pulses with a V-20 based single board PC, the
FlashLite. The fairly low level routines required to configure and
operate the timer/counter on that chip were (probably still are) beyond
my abilities. What I did manage to do was prove that I *could* count
pulses with general I/O pins, but as more sensors and behavior got
added, I started missing pulses. I caught this early enough to realize
the futility of continuing that path, given my limited play time.
Then I had a swing too far in the opposite direction, trying to use the
BASICStamp. It's an amazingly capable and easy to use controller, it
just can't hand too much real-time-like stuff.
<digression> I recently used my BASICStamp for a proof-of-concept
experiment for a quilting machine stitch regulator. It (will)
automatically adjust the sewing machine motor speed based on how fast
the user moves the carriage. ( See
http://www.allbrands.com/products/abp09265-0073.html for the inspiration
for this project.) It reads two optical encoders in an X-Y configuration
with simple pulsin statements to determine their rotation speed, does a
quick Pythagorean calculation to determine the velocity of the carriage
they are attached to, scales that value and does a pulsout for
pseudopwm. I say pseudo because the pwm would not work well if there
were ANYTHING else in the loop. The loop would be too slow. I tried
pwmout, but it pauses the loop long enough that it made the motor sort
of pulse, though at the proper speed. </digression>
So now the swing is back towards the more sophisticated controller, but
I need one that "knows" how to do a lot of those low level things for
me. My current controller of choice is the IsoPOD. I still have a bit of
FORTH learning curve, but it's a relatively elegant language and I
haven't run into any element of my designs that I couldn't either get
IsoPOD to do or couldn't find details where someone else had done it.
The problem now is what other activity do I steal time from so that I
can develop robot software with any effectiveness? As has almost always
been the case, it comes down to Sluggy being the weakest component in
Sluggy's robot design. :)
Sluggy!
More information about the DPRG mailing list
|
