|
[DPRG] DPRG ORG 08 Photos
Subject: [DPRG] DPRG ORG 08 Photos
From: Kenneth Maxon
kmaxon at qwest.net
Date: Thu May 15 00:56:43 CDT 2008
Hi Dave & Group,
I didn't participate last week, but I've built a number of robots so I'll
add my thoughts...
>>I do a similar thing except that the robot comes up in a text-based
>>menu system for setting values and so forth, and one of the menu
>i>tems is "Go" to start the robot behaviors. jBot has a 20x2 line
>>LCD and five push buttons to navigate the menus and adjust the
>>values. I saw several robots Saturday with similar arrangements.
>Something like that is really handy for testing and setting up the
>robot, and especially the ability to turn subsystems on and off when
>debugging robot behaviors, set PID parameters, etc, etc.
I couldn't agree more on this point. Both my small robot Dohn Joe and my
outdoor robot ProtoBot have onboard graphics displays. (ProtoBot will
likely receive either an upgrade or 2'nd display when I layer in the
multiple video systems developed for Dohn Joe.)
Dohn Joe hosts a 320x240 color LCD that has been invaluable in debugging
vision system problems. The color depth and ability to control the back
light (super bright when on bench power, lower when running around to
conserve batteries) really pays off. (
http://nikita.argia.net/kmaxon/art_col/vid_cap4.jpg )
ProtoBot hosts a 320x240 monochrome EL/LCD combo display. It was most
useful last fall when tuning in the control system. It is incredibly
powerful to be able to plot real time in strip chart fashion the actual
speed, error, and P,I & D values and watch them as the robot moves around
the back yard, up the side hill, tries to tackle its first few curbs, etc...
( http://nikita.argia.net/kmaxon/robo_vid/protobot01.wmv )
It takes some work to drive one of these directly, or one can break down and
pay a bit more (quite a bit more) and buy one with an easy to use interface
already built in. Often the super easy interfaces (serial, I2C, etc)
sacrifice speed of re-draw, but can massively cut down on development time.
I have gone the other route and designed a few of my own direct display
drivers one or two of them (sprinkled through out my web site with HW &
SW/FW) are documented for others to see... (
http://www.users.qwest.net/~kmaxon/page/side/control37_137.htm )
>I think almost all the robots that competed with maybe the exception
>of Red Car and AJ have some sort of encoders on the wheels or motors.
>Is this true? Perhaps it would be good to collect our knowledge on
>encoders and counters and interrupts and other similar low-level
>control techniques that folks are using on their robots.
For Encoders, I've done a number of different implementations:
1) In a couple of projects I have used dedicated encoder interface chips
such as the HCTL2016 and 2020 and extended their counting range in external
CPLD interfaces to tie them back to embedded processors. One example of
this is the simple 3 axis DRO that I built for my milling machine (
http://www.users.qwest.net/~kmaxon/page/side/control30_137.htm )
2) In some really early work, on a 8031 processor I've read the values
directly from GPIO pins. On the 8031 I used a timer based IRQ (not edge
triggered or event triggered) running at a very high rate. Needless to say
this was a poor design choice and I learned my lessons back in the day.
3) In another early work, on a PIC chip I also read the values directly from
GPIO pins. In the PIC chip implementation it (the PIC chip (16C54) was only
executing three functions, 1 collect encoder counts, perform the state
decode to keep a running absolute count and periodically toggle discrete IO
pins to send the count out as TTL level asynchronous serial stream. This
third example is somewhat like example #1 but rather than using a parallel
interface somewhat expensive monolithic device I used a cheap generic pic
chip and wrote the code myself. (Examples of this can be seen in the
statistical process control arm project and the lego robot / legacy robot
sections of my web site) (
http://www.users.qwest.net/~kmaxon/page/side/control28_137.htm ) There is
an SRS encoder article with source code out there as well... (
http://www.users.qwest.net/~kmaxon/page/side/art5_137.htm )
4) Many of you that know me know that I like to use the 68332 for its
variable trade off between ease of use peripheral integration. On ProtoBot
and some of the functions in my large robot project, I use the TPU functions
on the '332 processor and then a single timer based IRQ to periodically read
the count values. I wrote an article for the SRS on this some years back
( http://www.users.qwest.net/~kmaxon/page/side/art2_137.htm )
5) There are a few implementations (projects) that I can not share the full
implementation on. I did however for a group of SRS'ers in years past
extract a small piece of Verilog code that can compile down into a very
small xilinx CPLD to read encoders. It also implements an SPI function so
that an external processor (fast or slow) can read the encoder values...
One could easily scale this to many many encoders in a single CPLD. Source
Code to monitor 2x encoders up to 60 million CPS is here =>
(http://nikita.argia.net/kmaxon/top.pdf
http://nikita.argia.net/kmaxon/spi_slave.pdf
http://nikita.argia.net/kmaxon/enc.pdf)
6) Lastly my small robot (Dohn Joe) implements encoder functions in a Xilinx
FPGA. The final implementation makes the counter available to the processor
as a memory mapped data value. In this implementation the 24bit counter (up
to ~21million counts/lines/second) is read as 3 successive 8 bit values.
This is only done due to the size of the bus used to connect the FPGA to the
embedded processor in the example code provided on the web page. In the
real implementation on the robot it is a 32 bit wide bus and it read as part
of a single cache line fetch by the processor. (
http://www.users.qwest.net/~kmaxon/page/side/control55_137.htm )
There are trade off's to each of these implementations (technical expertise,
hardware expertise, processor through-put, board space, power supply over
head, and countless others.) Some of them chew up many valuable processing
cycles and should (if at all possible) be avoided. (#2 specifically)
If one is just getting started and has a processor with an externally
exposed Harvard bus, then #1 is a great way to go. If a processor board
hasn't been chosen then a processor board with built in HW functionalities
that do not require SW intervention to count / interrupt code execution per
tick is a great way to go like the MRM, old HC11's or so many others out
there. (these are similar to #4) If you are working on one of these new
modern embedded PC's with spare FPGA fabric, then #6 is a great way to go
without having to add any extra hardware save only a level shifter to take
the 5v encoder logic down to 3.3v, 2.5v or 1.8v IOs...
One last item to throw out there... If you are implementing #2 (a software
read implementation) or processor IRQ pin driven implementation, then it is
worth while to use encoders that have differential line driver outputs if
you have large motors on your robot. People often think that the smallest
pulse width coming from an encoder is either A) at max revolutions/sec or B)
Jitter when the output dithers. Many modern encoders have jitter reduction
to deal with B). The real answer however in a large robot with high
inductance motors is C. C) is the inductive spike commutated onto the
encoder data line, just long enough to trigger an IRQ event but not to be
present when the IRQ service routine is finally entered milliseconds later.
Yep, that's a fun one to debug.... <wink - wink>
I In writing this I have drug up all those memories about how much I really
miss working on the robots and not slaving away for "the man" :)
-Kenneth
More information about the DPRG mailing list
|
