It's been awhile since I played around with PIC-based robots
(PICBOTs), one reason is because modern PC's no longer have parallel
ports and in general make it difficult to write PC programs which can
access ports for programming the things. My old PB2-mini still works
but the stuff I used to use to program it no longer works. I need a new
robot hacking platform that works with modern PC's and programming
tools, like a plain serial terminal and programmers like the PicKit 2.
I also need something to stress my new
rebuild of my old SIMPLE
compiler to make sure there are no remaining issues before using it
for production code.
The idea of a PICBOT is a small solar-powered self-sustaining
programmable robot based around a PIC chip. They don't really do
anything useful other than provide a platform for testing ideas for
navigating around their environment and learning how to not get stuck.
Typically they use a pair of pager motors for propulsion and use
photocells and feeler switches to sense their environment. Since it is
powered by light, they need a way to sense the supply voltage so they
can sleep while power builds up, then move around a little with the
stored energy. It is also useful to have some way to sense obstacles
before they run into them. I've made a few of these, including the original PICBOT, the PICBOT 2, a mini version of the PB2, an IR obstacle detection mod for
the PB2mini, and modified the
PB2 to be "PICBOT 3" with
extra
memory and IR modules to program more advanced stuff using a simple interpreter. All of these
designs are outdated and the programming tools no longer work on modern
machines... need something different.
This time around I want to outfit the design with a standard
PicKit-2-compatible programming port with the capability of also being
a plain serial port so that once programmed it can be accessed using a
terminal emulator rather than having to deal with the nightmare of
having to program apps that access hardware, which is no longer the
trivial thing it used to be. I doubt a small PIC will have enough flash
to actually include the interpreter compiler on-chip but it can at
least permit hex images of the internal and external eeproms to be
programmed and extracted in text form using a terminal emulator, the
actual compiler/decompiler can get back to being a fairly simple BASIC
program that doesn't have to be concerned with port access... that way
I won't be locked out of my toys by modern technology. Even though
modern PC's also lack serial ports, USB serial adapters are common and
work fine connected almost directly to PIC pins.
Here's a draft of a new PICBOT 4 design... [hmm... could be better]
The PIC16F684 processor has 2Kwords of flash for system programming,
128 bytes of ram which doesn't sound like much but is plenty, and 256
bytes of internal eeprom for persistant variables. To this I added a
8Kbyte external eeprom to store robot code to be interpreted. The
interpreter encoding format limits the size of robot programs to
4Kbytes but the encoding is very dense (common operations take just one
byte), in the past I never got close to hitting the limit even with
large programs that implemented self-programming neural networks and
other learning schemes. The extra 4KB can be a whole other program that
can be run by the currently running program, or could be programmed to
be data storage. The design doesn't specify what the thing is
programmed for, just the limits of what it can do.
I had to do some pin sharing to make it all fit on a 14-pin PIC, the
motor outputs are also used as analog inputs for reading the battery
voltage and the amount of IR light hitting the photodiodes. The two
feelers are read using a single analog pin to sense the 4 possible
feeler states. The external eeprom has its own pins to avoid funny
business when reading and writing the eeprom. To ensure proper startup
and force the robot to sleep when power is low, a reset "trigger" is
used on the PIC's MCLR input - if the supply voltage is below the
trigger voltage then the PIC is held in reset, essentially turned off.
The sensors are powered from the trigger output to avoid drain when the
power is low. The motor drivers are implemented using H-bridge chips,
each essentially 4 transistors in a package. Extra diodes avoid the
"smoke" state where the high and low transistors are on at the same
time. The driver circuit is insensitive to drive voltages below about
1.2V so the motor pins can be used to sense analog voltages below that
level. This reduces resolution to a bit less than 8 bits, and the
sensors can't be read while a motor is activated, but for this app
that's fine. It doesn't have true IR obstacle detection (like the PB3
design and some other fancier PIC-based robots I've made) but those
modules are hard to find these days. This design uses a scheme similar
to the mod I made for my PB2mini - it measures the photocell outputs
then turns on the IR LED(s) and measures again, any difference
indicates IR light reflecting back off of something. Certainly not as
reliable as real IR modules, bright light will wash it out, but should
provide at least some indication of nearby objects. The 3M resistors
might need changing to adjust the sensitivity (the PB2 eliminates them
altogether), a driver might be needed to pulse the IR LED with more
current, or possibly the photodiodes replaced with phototransistors
(need to be careful to ensure the voltage doesn't exceed the motor
driver threshold). All sensors can be read via the serial port using
debug code to figure out what works and what doesn't. There's one spare
line so if necessary it can be used to multiplex more sensors, turn on
real obstacle-detect modules, etc.
Right now (11/18/2012) this design is just an idea I want to
pursue... how fast that happens depends on my work schedule. Before
building anything I need to get the "simbot" interpreter translated
into SIMPLE2 to use my current toolchain and working as a standalone
interpreter on my PicKit 1 demo board, flashing LED's in response to
test code loaded into the PIC's internal eeprom. That's a project all
by itself, and the main one I need to do to test the simple2
compiler... but that'll determine how much room I'll have left for
implementing robot driver code and how fancy I can get with the user
interface.
11/20/12 - first step is done, HLLPIC lives... even if just from
internal eeprom at the moment but I've got all the old code I used to
use for reading a 24LC64, shouldn't be much trouble to convert as the
interpreter code from the same app was fairly easy to get running along
with a serial interface for programming it and a compiler for creating
the code to load into it. More on the
embedded page. Got about 0.9KW left for external eeprom and A/D
drivers and robot-specific stuff, can't get too carried away but it
looks like it's going to fit. If not, looks like the existing code will
run mostly as-is on a 4KW PIC16F688. For less pin sharing could use a
18-pin PIC16LF88 but the register layout is different, some in page 2
requiring two extra instructions to get at (one bank select is bad
enough).. and there's something minimalistically apealing to making it
work on a 14-pin processor. [HLLPIC now does external ee and has an
analog read instruction that can be pointed to any channel.. about
0.4KW free].
12/2/12 - on the other hand... the 20-pin PIC16F690 is looking lots
better than the '684/'688... and it's cheap and I already have one..
was included with one of my PicKit 2 dev boards (which I can no longer
find in stock.. best to never depend on a particular programmer/dev
kit).
Here's a rough idea...
This version uses a physically bigger PIC but has several
advantages...
Fewer parts to do the same thing
No funky pin multiplexing, simpler programming
Better processor with more flash and ram
Hardware eeprom access for faster interpreter fetching
3 pins left over - could be a 5V enable and inputs from Solarbotics
"Prox Dots" for real obstacle detection
(but I still want to see what I can do with the simple IR illuminate
method)
Still using software serial to use a single programming connector
for flash or serial.. no good reason to use hardware serial when the SW
serial subs are just a couple dozen words and can share the ISP pins.
But hardware eeprom access is a big advantage, should boost the
interpreter from about 1000 commands a second to over 2000 @4mhz.
Terry Newton (wtn90125@yahoo.com)