PICBOT 4 - a small autonomous robot

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)