My intention for Wall-E is to operate in two different modes. The first is a puppet mode for use when demonstrating Wall-E or where discrete interaction is required, the second is an autonomous mode where Wall-E does what he wants on his own.

To facilitate these two different control systems on one platform I decided to use a distributed control method that splits up the higher functions and the lower functions in much the same way as our own brains are meant to be working (does anyone really know?). This means that items such a motor control and head movement are not done directly by the main controller (brain) but by instruction to a lower level controller. For this the I2C bus (network) makes sense.

TWI two wire interface

 

So the idea is that Wall-E will have an internal network of controllers each performing a specific function and these controllers are sent commands through an internal network by a master 'brain'. This allows me to swap out the master controller simply by changing the SDA (Data) and SCL (Clock) lines of the network via a switch. My intention is to have all the lower end functions controlled by a small arduino units such as the pro mini and the higher master controller be a more capable unit.

ProMini

This tiny micro-controller has more than enough programming and processing ability to act as a slave on the I2C network (I2C support directly in the chip hardware) and accept commands, process them and perform the requested function. This along with it's tiny size makes it perfect for the low level function control such as the track motors. 

Using control of the tracks as an example we see why this control scheme makes sense. In order to control his movements the 'brain' of Wall-E must have good control over the motion of the tracks this means controlling the power feed to the motors and monitoring that the movement actually occurred using the feedback encoders. It is certainly possible for a large micro controller such as the Arduino Mega to doing all this and the other functions but then the software becomes extreamly complex and processing power limitations may cause issues with the autonomous mode. 

Mega

Lets consider a simplified requirement to move forward 1 meter. To do this the controller must apply power to the track motors and monitor the encoders to see how far Wall-E been moved, once one meter has been achieved the power is removed from the motors. The power is controlled by a H-Bridge which receives a speed and direction signal from the controller, in this case motor1 and motor2 forward @ full speed. The controller must supply these signals to the H-Bridge constantly. In the meantime the encoder on the track is monitoring the actual track movement and sending back a sequence of pulses based on the speed and direction of actual movement. The controller must also monitor this signal and count these pulses to see if the movement of 1 meter has been achieved. Once this has been done the motors can be turned off again. As a micro-controller can ONLY process one thing at a time the controller spends all it's time controlling motors to move 1 meter forward and no much else. 

However if you give the job of motor control to a separate controller then the main 'brain' only has to ask the controller for 1 meter of forward movement and then go back to doing other things. This command is received by the controller dedicated to track motors and it performs all the control and monitoring functions. Once 1 meter of movement has been reached it tells the main 'brain' the command was completed. So by moving basic lower level controls to separate controllers we make the overall controlling software simpler and we free up processing resources on the main 'brain' of the system. But here's the big advantage.......the command to move 1 meter forward can be issued by any master controller so in puppet mode where the control is coming from a master that is receiving controls from a puppeteer the motors respond to the puppeteer however when the master is switched over to a more powerful computer that is doing autonomous control the same move 1 meter forward command can be issued by the controlling software without having to rewrite all the lower level controls.

So my first ideas for a control scheme look like this.....

Wall Ebvasicocontrol

This means that track control is dealt with by a ProMini operating the H-Bridge and encoders while receiving commands over the I2C network. This network being controlled by either a Raspberry Pi computer for autonomous mode or over Bluetooth from a puppet controller. In this initial design the servos controlling the head movement do not have a local micro-controller as the 16 servos are controllable directly over the I2C network. However as the movement of the head and arms becomes more complex I may add a local controller to this as well so that commands to move can be issues rather than actual motor control signals.

I am sure as this project moves on this control system will mature, change and grow in complexity but those are for later articles.