Robots

Never quite got around to finishing off these robots, all definitely work in progress. However, one day I’m sure I will find time (work allowing :)

BOT (aximummay owshay offway)


Figure 1.1 : BOT - front, back, sides, top and bottom

BOT: a simple bread board robot based around a Z80, CTC, PIO and TTL logic ICs. Built as a demonstrator when I taught the CTS module (student hardware group project). A nice platform for testing out speed control software, however, as it has grown power supply issues have made it a little unreliable. Uses a H bridge for motor control with feedback from infra-red sensors mounted on each gearbox, giving approximately 256 pulses per revolution. Equipped with two processors, one controlling sensors (speed and light) and actuators (drive motors), the other performing the high level control (navigation and behaviour etc) communication via shared memory. Note, haven’t used BOT for many years, definitely not functional.

BEN (owerflay otpay anmay oneway)

Figure 1.2 : BEN - front, back, sides, top and bottom

BEN: been working on this robot for a quite a long time, hasn’t really been designed, but has rather evolved as new hardware was added. Based on a 6502 processor for low level motor / sensor control, supported with SPLD and FPGA hardware. Do confess I have a soft spot for the 6502 as it was the first processor I really used. As a result I do have a blind spot regarding all of its failings (especially the 8bit stack pointer). The 6502 used is a modern equivalent clocking at 4MHz (can go to 10MHz but I’m not convinced the PCB/cabling is up to it). It may be long in the tooth but it does give reasonable performance (if you ignore size, cost and power :). To improve performance a little more added two FPGA co-processors: IO and Maths, implemented in extremely old Xilinx XC4005 FPGAs (owing to their 5V tolerant IO) configured by VHDL/Schematic descriptions. The Maths co-processor has a 32 bit fixed point multiplier, adder, subtractor and comparator. The IO co-processor controls the infra-red distance sensor servo motors (mounted at the front of the robot), a serial mouse used to measure distance travelled (mounted on the bottom), the ultrasonic ranger finder and a high speed serial link to the main processor board. A simplified block diagram is shown in figure 1.2.1. Ideally the co-processors would be on the processor’s local bus, however, due to cabling and space constraints (lack of connectors) I had to place these components on the expansion bus. This incurs a significant reduction in bandwidth, will rewire at some point.

Figure 1.2.1 : Low level architecture block diagram (not ideal)

Simple GPIO + MOSFET drives are used to control the main drive stepper motors (differential steering) and the horizontal and vertical head stepper motors. The 6502 generates the required motor phase signals implementing full and half stepping modes. The infra-red communications link (mounted on head) is also bit-bashed through GPIO allowing the robot to locate and interrogate active beacons in its environment i.e. robot TX wakeup code, if beacon in range it responds with its ID code. The IO-processor also implements the high speed comms link to the main processor board, buffered through a hardware FIFO and a circular buffer in 6502 RAM. The main processor board contains two processors, a 68332 micro-controller and a Xilinx MicroBlaze implemented in a Virtex II FPGA, as shown in figure 1.2.2.

Figure 1.2.2 : Top level architecture block diagram

The top level processors implement the robot’s control and communications functionality. The 68332 has at its core the CPU32 processing module derived from the 68020 processor. This communicates with the MicroBlaze processor across a high speed SPI serial link allowing functionality to be distributed between these processing elements e.g. navigation, localization, signal data processing etc. These processors and the serial to Wifi adaptor are currently being rewired i.e. the top platform in figure 1.2. At present this robot is used in a student project looking at how ultrasonic data combined with binary neural networks can be used to localize a robot within a map. The final aim of this work is implement this functionality in a binary neural network co-processor (an existing VHDL IP-core) implemented on the Virtex II FPGA.

BIL (owerflay otpay anmay otway)

Figure 1.3 : BIL - front, back, sides, top and bottom

BIL: BIL(L) the second half of the team. However, as you can see from the photos BIL isn’t feeling very well at the moment :). Currently going through a refit, replacing the ultrasonic range finder with a stereo camera system based around a pair of Kodak KAC-9628 CMOS image sensors. These will be interfaced to a Xilinx Virtex II, or Xilinx Spartan 3 FPGA, however, need to design a PCB for the frame buffer memory. Its surprising how much memory a robot needs when you start to process image data i.e. many mega bytes, owing to the camera’s VGA resolution. Definitely a work in progress. The envisaged architectural block diagram is shown in figure 1.3.1. This robot again uses stepper motors as its main drive motors. The drive circuit is a little different from BEN’s, uses 5V stepper motors operated from a 12V supply with current limiting. This reduces the coil voltage rise time, giving more drive power resulting in significantly higher top speeds. This robot can be operated using differential drive steering, but can also be reconfigured to use rear/front steering via a fixed wheel, this being rotated by an additional stepper motor (in differential mode rear fixed wheel replace with a caster wheel). The aim of this work is to use the stereo image data combined with a binary neural network to localize the robot’s position within a map. Again, it is intended that the final system will be implement in a binary neural network co-processor (an existing VHDL IP-core) implemented on the Virtex II FPGA.

Figure 1.3.1 : Top level architecture block diagram

BUD (aximummay eedspay amageday)

Figure 1.4 : BUD - front, back, sides, top and bottom

BUD: original designed as a prototype buggy for a robocup football team, however, now used as a test platform for high speed robot control. Unlike the previous robots the main drive motors are DC motors with a 11:1 reduction gear box. For the size and weight of this robot these motors are considerably over spec’ed allowing the robot to achieve quite impressive rates of acceleration and top speeds (measured by the depth of the indentation left when it crashes into a wall). Architecturally a relatively simple architecture based on a 68332 micro-controller, interfacing to both gyroscope and accelerometer sensors through its SPI serial interface. Motor control is implemented using a standard H bridge controller (MOSFET) and PWM. In addition to the gyroscope and accelerometer each wheel has a simple wheel encoder. The encoder disks are printed onto transparencies and glued onto each wheel as shown in figure 1.4.1. These are ‘read’ by an infra-red sensor i.e. measuring and thresholding the reflected light from the clear and black segments, giving either 4, 8, or 16 pulses per revolution.

Figure 1.4.1 : Wheel encoders

Figure 1.4.2 : Top level architecture block diagram

To minimize the amount of damage to the departments skirting boards BUD’s control algorithms can be tested on a simple rolling road, as shown in figure 1.4.2. This allows one drive motor to be monitored using a high resolution encoder as it drives/accelerates a known mass. This data is logged by another 6502 board (data logger) allowing the user to download this data (iHex format) after each test run. In addition to this known load a variable load can be applied to the drive motor using a ‘load’ motor. This is coupled to the mass using a friction drive wheel, pulled into position by a solenoid during a test run. The voltage applied to this motor is again controlled by the data logger (6502) through a DAC, allowing previously uploaded load curves (iHex files) to be applied during a test run e.g. to simulate a inclines, variations in terrain, rough/smooth surfaces etc. At present this robot is used in a student project looking at how sensor data can be combined to control/enhance the robots maneuvering abilities at high speeds.

Figure 1.4.2 : Rolling road

BOD (ellowyay iangletray ersonpay)

Figure 1.5 : BOD - front, back, sides, top and bottom

BOD: this robot is a general purpose mobile platform constructed to temporarily replace BIL. The intension is to evaluate and implement the vision processing algorithms required in BIL on a standard laptop PC with a webcam. To maneuver this platform two DC motors with a 50:1 reduction gear box are used (due to its increased weight), controlled using a standard H bridge controller (MOSFET) and PWM. The main navigation , obstacle detection, course correction algorithms are implemented on the laptop PC using camera image data, therefore, the platform has minimal number of additional sensors: left/right light sensors and front/rear bump sensors. There is space for four addition bump sensors i.e. front left/right and rear left/right, which will be added later. These actuators and sensors are controlled by another 6502 base control board which is connected to the laptop PC via a RS232 serial link. This communication link allows the PC to request sensor data and send movement commands e.g. move forwards 50cms, turn left 90 degrees etc. These commands are buffered in the 6502’s local RAM and are issued as each command completes. At present this robot is used in a student project looking at how camera data combined with binary neural networks can be used to localize a robot within a map. The final aim of this work is implement this functionality in a binary neural network co-processor (an existing VHDL IP-core) implemented on the Virtex II FPGA.

Figure 1.5.1 Top level architecture block diagram

BAL (ootay uchmay otay inkdray)

Figure 1.6 : BAL - front, back, sides, top and bottom

BAL: always wanted to make a balancing robot i.e. a Segway Bot. Currently in the process of making a test platform using the two infra-red range sensors mounted front and back. The intension is to use the difference of these sensor signals as the error signal to a PID controller, allowing the robot to balance without the need of the brass standoff shown in the photos. Hope to also use the gyroscope and accelerometers used by BUD, definitely a work in process. Hope to get a prototype working by the end of the year (work allowing).

BOB

Figure 1.7 : BOB - front, back, sides, top and bottom

BOB: was constructed as a simple platform to test an ultrasonic beamform array i.e. using multiple TX and RX ultrasonic sensors to improve the accuracy and resolution of range readings. Missing two ultrasonic RX/TX modules which would have been mounted in the middle of the sensor head array. To be honest didn’t really work, need to have a look at this one again. Currently mothballed.

BAO

Figure 1.8 : BAO - front, back, sides, top and bottom

BAO: a simple robot arm made from an old printer. Currently mothballed.