Serpentine Arm - Control System
HOME

PART 4: CONTROL BOX
I am a firm believer in physical control panels (as opposed to a strictly monitor and mouse-click approach). A physical control box of this complexity is certainly a big investment, but it allows the eyes to stay on the robot while the hands work the controls. Also, more than one thing can be done at once when there are joysticks and knobs.

This panel controls a wide range of operations and tests of the robot. The PC only needs attention during startup / checkout. After that, everything is controlled by the control box.  
[ContolBoxPanel.JPG]

Inside the Serpentine Arm's control box.  The central element of the unit is an ADAPT912 HC12 MCU board (green). The MCU performs analog to digital conversions of all the panel pots and joysticks, and acts as a relay station. There is an analog multiplexer board to allow the reading of many analog values, as wel as input and output digital port expanders.  There is also an RS-232 / RS-485 translater board.  
[ControlBoxGuts.JPG]

More information related to the Serpentine Arm Control System can be found in the Wrist Page, and Software Page.


 
INTRODUCTION
The control system of a robot is its lifeforce; without it there would only be a stack of parts.  The control system is like the nervous system of an animal in that it is composed of sensors, processing elements, communication links, and outputs to actuators.

A good definition of "robot" is AN EXTERNALLY CONSTRAINED MECHANISM - a machine that can do anything it is told to do by some external agency.  Compare this to a mechanical clock which is INTRINSICALLY constrained - the clock's physical embodiment controls what it does, and it only does this one thing.  Many real devices are a combination of the 2, and it is hard to say if they are "robots".

The Serpentine Arm is a true robot, in that all motions are externally constrained.  Each of the 12 joints can be at any angle at any time, and it is up to the control system to make the right angles happen at the right time.  This is a critical job because the machine can easily damage itself, objects, or nearby people if these joints go to the "wrong" places. There are 2 layers of complexity to this job. The first is self-knowledge / self-control.  The second involves knowing where things are in the real world and adjusting self to possibly avoid or intercept them.

We live in a world of incredibly complex machines, both natural and man-made, and take control systems for granted. It is a humbling as well as a fascinating journey to try to construct an animal-like control system - even one as simple as this.
The above diagram shows a single servomechanism as it was finally implemented (for clarity, only 1 of the 4 for this microcontroller and 1 of the 2 for this H-Bridge are shown).

The Microcontroller.  The left box represents the ADAPT912 B32 microcontroller board (Technological Arts).  This contains a Motorolla 68HC912B32 microcontroller as well as connectors and support circuitry.  The microcontroller (or MCU) listens for velocity commands at the serial port (Rx) from the higher control levels, and constantly tries to execute these commands, within limits. 

The MCU reads the HCTL2020 chips periodically, so it always knows motor position.  The MCU is initially given a set of "Position Limits", and will not command the motor beyond these, a limited first line of defense against erroneous commands.  Also, if commands stop coming, the MCU will ramp velocity down to zero - a crucial safety mechanism in velocity controlled systems.  The MCU also uploads position data and status information when requested.

The actual servoloop is a basic PID strategy with the 3 gains figured out by trial and error.  Although textbooks on control theory make closed-loop control seem extremely complex, making a reasonable functioning system is pretty easy. The intensity of the corrective motor force is just {(Gain1 x Error) + (Gain2 x ErrorRate) + (Gain3 x ErrorSum)} .  This evaluation / correction should occur some hundreds of times per second (easy for a MCU).  The gains can be tweaked with potentiometers during design phase, and the signs matter!

Since a VELOCITY CONTROL strategy is used, the higher system (a PC) can be somewhat inconsistent in the periodicity of its commands.  This is important since it is very hard to get Windows PCs to do things WHEN you want.  In practice, there are about 18-28 command cycles per second, and this gives pretty smooth machine operation.  Windows must use processor time for background operations, so even moving the mouse slows the cycles per second.  The beauty of velocity control is that you don't need to send commands at a very high rate.  However, velocity control means the MCU has an extra job in figuring desired position based on velocity command and current time. And also, the PC must adjust its velocity commands according to true position as reported by the MCU.

The MCU program was written in assembler and programmed into FLASH with MINI IDE.  Debugging was done mainly by progressing the program in small bits, and using some extra pins and an oscilliscope to visualize what was happening.


PART 2: SYSTEM SAFETY
When you put lots of hours into constructing a somewhat delicate robot arm, the thought of a software bug causing a destructive lurch is never far off.  Software development is a cycle of changes, bugs and fixes -  not a big deal in most cases, but when software is connected to machinery, bugs and their effects are a major concern.  Even when the software is perfected, there are unpredictable situations that can cause trouble - like a person in the way during a fast extended rotation, or a failure of an electronic component.

Several techniques are employed in the Serpentine Arm's control system to avoid damage, both during program development and during normal operation. 

* Main Power Shutdown.  Several situations can automatically trigger main power shutdown.  This is a pretty drastic step which causes the machine to go limp and drop, but may prevent major damage from an "epileptic siezure".  The main control panel also has a toggle switch to do this, and after any major changes there should be a finger at the ready to kill power.

* ServoBoard Limits: The servoloop MCUs are initially given upper and lower encoder limits (the expected maximum joint angles) and won't command action beyond these.

* ServoBoard "Auto Velocity Rampdown": If the commanding PC freezes, gets disconnected, or for any other reason stops commanding, the servoboards will automatically ramp any motor velocities to zero.

* Masterboard Directional Limits: A separate MCU (the "Masterboard") watches joint potentiometers and will restrict any joint from going too far by electrically blocking the H-Bridge command.  This protects against ServoBoard failure.

* Masterboard AutoKill: A separate MCU (the "Masterboard") watches joint potentiometers and will kill system power if any joint goes past a preset value. This is a last resort which protects against various hardware and software failures.

* Whisker Azimuth Halt:  If a side whisker contacts anything during an azimuth (main rotation) move, the azimuth motor will halt. This is done at the AzBoard MCU level, independent of PC. 

* Whisker Down Halt:  If a down whisker contacts anything during a downward move, the PC is notified and may decide to halt.

* Dangerous Posture Halt:  The PC keeps track of posture based on encoders and joint potentiometers, and will stop motion if a self-hit, or pedestal-hit is imminent. 

* Posture Data-Discrepancy Halt: The PC keeps track of posture based on encoders and joint potentiometers, and will stop motion if a large discepancy between these 2 exists.  Such a discrepancy would indicate either a large loading (like a person is holding back the arm), or a sensor failure.

* Modular approach to PC software:  The lower level robot interaction routines which have the greatest potential for harm were perfected under carefully controlled conditions and frozen as Visual Basic Modules.  Later, the higher routines could be worked out without much risk. 

* Sonar Modulated Halts: The PC receives sonar data from the "hand", which can be used to locate objects.  This data can be used in various ways, including hit avoidance.

* Bungee-Cord: The arm was sometimes bungeed to the cieling  such that it could move within a small range for tests, but couldnt hit itself or the pedestal. This was done after any major control system changes.




 

PART 3: A NETWORK OF MCUs, AND A MASTER PC.
Why MCUs?  A good question is "why not have the PC do everything?" The answer is that the PC, although it has an extremely powerfull processor, is not well suited to real-time control because it cannot measure or generate accurate pulses, or even measure a voltage.  Microcontrollers (MCUs) may be dumb compared to a Pentium 4, but they excel at low-level tasks like these. 

In fact, the PC and the MCU have opposite strengths and weaknesses, and it makes perfect sense to use both. The PC handles the high level thinking, generates fancy displays, and allows lots of data storage.  The MCUs do the low-level jobs like motor control and sensor reading.

An MCU of the type used (HC12) cannot handle all the low level work alone, several are needed.  This is good in a way: it allows a modular approach.  Simpler problems can be solved and encapsulated in a single MCU.  Since assembly language programs are tricky to work with, it is nicer to work with a few small ones than one big one.

It would be great if the PC had a "magic reach" so it could read and write memory cells in the various MCUs on the robot. But in fact this requires  complex communication circuitry, firmware (in MCUs), and software (in the PC).  The final result, after hiding some layers of functionality, SEEMS like magic reach from the PC's perspective.

The communication system is a multidrop full-duplex serial network.  The PC serial port is used for I / O, and this RS-232 signal gets translated into the RS-485 protocol for better noise immunity, multidrop capability, and distance.  The PC speaks to all MCUs, all the time, but a given MCU obeys only messages meant for him.  The MCUs speak to the PC one at a time, and only when the PC requests it.  The PC can deliver commands and data to specific MCUs, and requests various groups of data from specific MCUs. 

There can be 8 MCUs in the network and one PC. The 8 MCUs and their functions are...
0:Control Panel        Physical User Interface
1:MasterBoard        System Safety, Sonar, Lamps, Joint Pots
2:MotBoard1458        Servoloop Control of motors 1,4,5,8
3:MotBoard2367        Servoloop Control of motors 2,3,6,7
4:AzBoard        Servoloop Control Azimuth motor, whiskers
5:WristBoard        Control 3 hobby servos, accelerometers, grip force
6:Pour Station        (not built)
7:Available

An example of the commands to and uploads from a single MCU (#2) are shown below.
[FirmwareEG1.gif]
[FirmwareEG2.gif]

 





 
Serpentine Arm Control System Diagram (partially shown here) Click for full size: 2000 x 3134  1.19MB
PART 1: THE SERVOMECHANISM
The most basic building-block of the Serpentine Arm's nervous system is the servomechanism.  A servomechanism APPEARS to the higher levels of the system to be a simple physical thing (like a motor shaft or an elbow joint) that goes where you tell it to go, or at a speed you tell it to go at.  If commanded frequently, the result is a controlled move. 

In fact, servomechanisms are mini nervous / physical systems unto themselves. The centerpiece of this little world is the gearmotormotor with its built-in position sensing optical encoder.  A microcontroller keeps track of the current motor position and compares it to the desired position, and the difference between these forms the basis for corrective commands to the motor.  An electronic valve called an "H-Bridge" takes commands from the microcontroller and converts them into actual motor voltage.  This is also known as "closed loop feedback control".
I thought it would be fun (as well as smaller and far less expensive) to build the servomechanism myself.  A test and development rig (photo above) was built to roughly simulate the situation in the actual robot. On this rig, the electronics and firmware could be worked out without crash-up risk (unlike the actual robot there was continuous rotation allowed). 

Reading The Encoder.  The rotation sensor on the motor is an optical encoder, it puts out 2 channels of pulses as the motor rotates, and it is possible to discern the motor's direction, speed and location from these pulses.  While a microcontroller can be used to decipher these pulses, it gets tricky when there are 4 motors per microcontroller.  So I opted for a chip that handles this job, the HCTL 2020.  This chip keeps a 16 bit count of where the motor is at, and the microcontroller can ask (one byte at a time) for the value at any time, and also can zero the count.  It should be noted that encoders don't know absolute position, only position relative to the latest zero-out.  The Serpentine Arm has potentiometers (which DO know absolute position) at its joints to help with this initial zero-out.
UP to Serp Arm Overview
works of  Carl C Pisaturo