Build Your Own
Big Walker
by Daniel Albert
www.servomagazine.com/index.php?/
magazine/article/april2011_Albert
Part 3
This segment focuses on the design and implementation of the big walker’s
multi-processor distributed processing system. This part in the series is crucial in
simplifying the algorithm that creates a simple walk. Rather than one processor
controlling all the servos and reading all of the sensors, these tasks are split into
individual processors. A logical place to divide the system is at the limb level.
The same tasks required to control the left leg can control the right leg. Each
limb therefore has its own processing board (Limb Processing Board) or LPB.
Distributed Processing
The LPB is designated with the tasks of handling that
limb’s sensor input, servo control, and communications with
particular other boards. Most of today’s MCUs can easily
handle this. I used a Microchip dsPIC30F4012. It can run at
30 MIPs. For now, the big walker has only two limbs and
two LPBs. However, in time, two arms will be added.
The more complex a system is, the harder it is to
debug. The distributed system simplifies the debugging task
by applying a simple debugging tactic. That is: “It is not so
much as what the problem is, as to where the problem
is.” By isolating tasks to separate processors, we can
simplify the “where.” As with most projects, they evolve in
what is termed “feature creep.” We just can’t help adding
more functions. This is where a single board computer
system becomes harder and harder to debug. Like the
feather that broke the camel’s back, many times one extra
line of code in a complex system can allow subtle time or
resource related bugs to develop in the code in an
unrelated area. A distributed system can be naturally
immune to this. A fixed set of high priority tasks that are
isolated within one MCU can never be hogged by some
other unrelated task assigned to another MCU. That cannot
be guaranteed with a single processor with a single or
multi-threaded operating system.
Micro Controller Units (MCUs) unlike Central Processing
Units (CPUs) are designed to control some external
hardware. Typically, there are time constraints required to
handle hardware inputs and outputs. Interrupt Service
FIGURE 1. Notice the two Limb Processing Boards (one for
each leg). The ZigBee adapter is in the middle. The board
everything is mounted on is the power and I2C bus board.
Requests (ISR) are the code segments — or handlers — that
process these signals. They have top priority of the MCU.
This is confusing to some people, but ISRs are the
foreground tasks in an MCU. There are priority levels to
each ISR and the highest priority is the task most in the
foreground. Main() code is the lowest priority or
background task which is only run when an ISR is not
running. It is sometimes easier to think of this as urgency
vs. importance. Foreground tasks are urgent. Sensor
reading and servo driving of each independent limb are
time critical. They MUST be done on time. Missing a sensor
input or improperly driving a servo is not an option.
Background tasks tend to be important but not as time
critical. Making the right decision from the sensor input is
very important. Passing information to other parts of the
system is also very important. For some, it may be easier to
think of urgency and importance in time. In the case of the
big walker, urgent tasks tend to be handled in
SERVO 04.2011 63
