Back to walkers.

Adding a PIC Processor to a BEAM Walker



Walkers
  • Strider & Ping
  • proto-X-us
    gNat2
    Bio-Bug Mod
  • J's Bot
  • Scoutwalker II
  • Gnat & SNB
  • Pic Interface
    Page 6 of 6
  • So why would you want to add a PIC processor to a BEAM walker?

    First, I must say that I really do believe in the 'analog' approach to BEAM. People have done some very cool things with BEAM's nervous nets, and I know there will be more to come in the future. Having said that, I would also like to say that a processor can be an asset to a BEAM circuit too, and not an abomination.

    You don't want to replace the role of the 'nervous net' with the processor. Let the BEAM tech do It's job. Use the processor to add some machine intelligence interpreting sensor data, or to facilitate commmunications to/from the robot.

    I hope the information on this page helps those who are interested in an area of BEAM that has hardly had its surface scratched. A huge amount of potential is out here for so many things...


    I have used a variety of different Microchip PICs, from 8 pins to 40 pins, OTPs, Windowed, and Flash. The ones I have been using lately are the 16F877 and 16F876.

    Here is a schematic that can provide a minimum for a BEAM-PIC interface. It has a USART interface that enables the user to flash a new program onto the PIC using a bootloader program. Depending on the type of RS232 Transceiver you are using (Maxim, Intersil, Sipex), the values of capacitors C1-C5 will vary. Typical is 1.0uF or 0.1uF. R1 is a 1 Meg resistor for a Collpits type oscillator. R2 is 47K. Pins 7 and 8 of the serial connection are tied together to form a 'Hardware Flow Control' Spoof! Use an appropriate regulated power source, and by-pass caps with this circuit.

    One bootloader program a few of us have been using is -Rick Farmer's PicLoader.

    The modified versions of Rick Farmer's PicLoader are here. They have been modified so that only the TX and RX pins of the PIC are used, keeping all of PORTB open to the user.

    Help on setting up HyperTerminal to use with the modified versions of PicLoader can be found here.


    Here is a technique that has been used for several four-motor BEAM walkers with great results. The technique is really quite simple.

    Count steps off of the 'master' bi-core.

    All you need to do is monitor one side of the master bi-core and count steps. Each pulse from that side is half a step cycle. In my code, I refer to it as the heartbeat. Use any pin on the PIC that is a schmitt trigger input for monitoring the heartbeat, if you do, you probably won't have to build a low-pass filter to reduce motor noise. I haven't had to yet.

    This becomes the sync between the PIC and the master-bicore, and is independent from the power level. Meaning, when the power level drops from draining batteries, and the bicore cycle slows down, the PIC program will still sync with the step-cycle. This technique would also work with a variable rate bicore setup.

    I use direct polling, using a schmitt trigger input...it works for me, but there are a couple of other possibilities that I have not tried yet, if your PIC has a 'Timer1' you can use it as a counter, in count mode, it increments on every rising edge of the external clock input, - ie. from the master bicore. This would provide a transparent way of counting steps. Another interesting way might be to use the CCP1 interupt feature to capture the rising or falling edge of the bicore pulse using a small interrupt handling routine.

    The bot is controlled and monitored by four pins on the PIC. One for the heartbeat, one for the motor enable, and two for the IMX. Check out the ScoutWalker/PIC interface here.

    The heartbeat we've talked about, it is an input to the PIC.

    The motor enable controls all the motors, is on or off, and is an output from the PIC to the bicore enables.

    The IMX connections can be inputs or outputs depending on the action required. You can use them to monitor the tactile sensors so that the program knows what state the tactiles are in, or you can use them as an output to the IMX and steer the robot like a horse. The PIC's pin function can be changed from input to output on the fly, which comes in handy when interfacing to the IMX.

    All the 'A.I.' of the robot comes down to five primitive states (actions). Stop, Turn Left, Turn Right, Reverse, and Forward. Left, Right and Reverse are controlled through the IMX, Forward is the default state of most walkers, and Stop is achieved by turning off the motor enables.

    You can also use a classic horse and rider scheme, which I have used in the past. Or you can use the PIC to completely take control of the walker, if you want to, like I did for the Line Following Project.

    For a simple maze solving program you might initiate a number of step cycles left, right, or forward to implement a Left-Hand-Rule or Right-Hand-Rule scheme to solve a maze.

    Maybe you might want to make your robot head south for the winter. Add a digital compass, you probably have four pins available on the PIC. Here is a program written in assembler as an example [ scout_6.asm ~ 23kb ].

    Use the PIC as a way to integrate sensors that would be difficult, or impossible to connect directly to a BEAM circuit. Or just do it because its convenient to.

    The point is, you are not wasting any processor time to make it walk, nor would you want to. Let the BEAM circuit do the walking. Use the PIC to collect sensor data and tap the IMX on the shoulder every once in a while, or alot, if you are a real back-seat-driver.

    It should be mentioned that before you go adding a PIC to your walker, make sure your walker is working properly. Take the time to observe your robot and tweak anything that needs some adjustment before adding another layer of complexity.

    Back to walkers.