Home High-School GhettoBot Design
https://quickwired.com/kallahar/robots_ghettobot_design.php
Micro-Panzer GhettoBot

Specifications
Frame 3/4" Poly Vinyl Chloride (PVC) pipe
Power Two 7Ah sealed lead acid batteries
Wheels Two 8" plastic/hard rubber common to push lawn mowers
Axles The pedals from a Schwin road bike.
Motors Two power-window motors off a junkyard Le'Barron
Weapon 2'6" steel arm attached to the rear windshield wiper motor from a Honda CRX
Armor Internal armor is miscelaneous steel sheets
Relays Various SPST Automotive relays
Fuses None, but there should be some!
Computer 482DX2/66, random HD/FD/Serial controller
Hard Drive Random laptop drive, big enough to fit Win98
HD Mount 3/4" foam attached with duct tape to a aluminium arm (no hard mount)
Network Acer Warplink wireless LAN (ISA/PCMCIA)
Laptop Any laptop will work, ours was a P100.

Mechanical Design
Frame 3/4" white PVC pipe. Most of the sections are 6" or 3" long. Standard T and elbow connectors are used. Some joints are glued, some are left free.
Axels The axels were taken from an old Schwin road bike. We bought the bikes for their chains and gears, but ended up scrapping that plan. The pedals just happened to fit the nylon gears on the motor. There are three set screws on the motor-end which line up with the teeth on the motor.
Drive Motors Power window motors from a Le'Barron. They have a nylon worm drive which means that the torque is good, the axel speed around 2RPM at 12V (4 at 24V) but it also means that the nylon may get destroyed. It also means that the wheels will not free-spin. They are either moving under power or they are locked in place.
Weapon Motor One weapon motor is used. It is the rear windshield motor off a Honda CRX. Inside the enclosure is the reciprocating arm. All we do is apply power and it keeps hitting on its own. Again, nylon parts, so I don't think this would work for very long before dying.
Weapon We have a two and a half foot arm which anything can be attached to. For testing we used a steel spike and a hammer. Both worked very well.
Computer Mount The motherboard is attached to a big sheet of steel via wire ties. It is padded with model airplane foam. This allows the board to move slightly and be immune to vibration (there are no hard-mounts to the frame)
Computer Cards We have a VGA video card, the HD/FD/Serial controller card, the wireless lan card, and the custom control card. They are held in my a rotatable arm which is padded to hold the cards down. The arm is held down by wire ties during combat.
Hard Drive The hard drive is extremely sensitive to any movement at all. Therefore, it is suspended by duct tape from the frame. It is inside a pack of foam. Therefore, it can swing freely, and be cushioned from all sides. There are definately no hard mounts here!
Relays 8 relays are held in a thin steel enclosure, the wires are protected. The relay enclosure is hard-mounted to the frame.
Power Board The power board is hard-mounted to the frame, it is very sturdy and only has a thin steel protection below it.
Batteries The batteries sit in a steel tray, and are held down by a battery mount. They also sit between the drive motors.


Click for fullsize
Controller Card Design
Overview The controller card boils down to being a latching output buffer for the ISA bus. You write values to the card, and it locks that in to the outputs. The outputs stay there till you write in a new value.
82C55 The heart of the card is the 82C55A CHMOS Programmable Peripheral Interface. You write a value to it and it sticks. The three ports are selected by the lower bits of the address. This means that you choose the port (A, B, C, or config) you want to write to by changing the address your program is writing to. For example, if you want to write to port C and the card is set to respond to port 280h, then you change the address you are writing to to be 282h (since port C is +2). When you write your data, it knows to put it on port C. The mode can also be set for each port to be read or write, among others.
74LS138 To set the base address for the card to respond to, you use the 74LS138 decoders. This setup guarantees that the card will only respond to one address range.
ULN2003A The ULN2003A is a high-voltage, high-current darlington array. There are seven of them per chip (why not 8?!). The 82C55 can only push 4mA on its outputs. The relays we are using need around 150mA. Therefore, we need this chip. The ULN2003A is rated at 500mA per channel!
Schematic


Click for fullsize
Relay Nest Design
Relays The relays used are SPST automotive relays. This allows high-currents to be pushed through without fear of cooking the contacts.
Connectors The bottoms of these relays have spade connectors, so we used spade sleeves soldered to 14 gauge stranded wire.
Control Wires The current coming from the control card is low (around 150mA per channel) we can use a 10 conductor 20 gauge stranded cable.
Schematic


Click for fullsize
Power Supply Design
Overview This board has two purposes. To provide up to 36V to the motors, and to provide +12, +5, and -12 to the motherboard.
Motors Power is sent directly to the motors from the batteries. This enables us to push around 30 amps through the relays.
Motherboard The motherboard is a lot more touchy. All power is filtered through voltage regulators. The hard drive needs 300mA so it gets its own LM123 (5V regulator). The motherboard needs 2.6A so we use another LM123 in a TO-3 metal can which can push 3A. The -12 goes through the LM957 which is a negative adjustable regulator in a 1A TO-220 case. The LM217 is the +5V regulator. Our motherboard will boot without the -5, and the P.G. (power good) MUST be left floating. (that one took a while to figure out)
Batteries This design requires three 12V batteries, but the third is only there to put the voltage going to the +12 regulator to over 14. Therefore, one battery could be much smaller than the rest.
Switches The DPDT switch is the main power and will turn on/off everything. The capacitors may take time to discharge though so be careful! The bottom switch is the relay override. This is a safety switch. Since the motherboard takes a few minutes to boot up, we need to turn it on before we want the motors and weapons doing anything. Therefore, when this switch is off there is no power going to the relays, and the motors cannot engage. In an emergency, either switch will render the bot motionless. (Very Important!)
Cautions Do NOT get the batteries hooked up backwards, or your capacitors will explode (see pictures page). It would be a REALLY GOOD IDEA to add fuses to the circuit to prevent things from, say, melting... Fortunately these regulators have built in thermal shut-offs (yes, we verified that one accidentally) so it is hard to actually break them.
Schematic

www.luminus.cx) wrote an excellent com object that exposes the bus to VB.
Control Software Code - Port Access Library
Overview In order for VB to access the ISA bus, we need an object. Aaron Klingaman (
How it Works All this library does is provide Read and Write functions that will read or write on the ISA bus. No checking, no timeouts, nothing fancy. Very easy to use :)
The Code
  • PortAccess.dll(run 'regsvr portaccess.dll')
  • PortAccess.zip(only needed for development)


Click for fullsize
Control Software Code - Sender
Overview The sender code is what runs on the laptop. The controls are set up to mimic Quake (ASDW) which makes driving easy. Firing, turbo, and weapon are on other keys. This bot is Doom era so there is no mouselook or jumping :)
How it Works A connection is established, data is sent. The commands to send are generated here, so it is important to make sure that they get coded right. There is an override section included which allows unsafe commands to be sent. It is possible to send any command to the bot, it could even be set up to respond to arbitrary code if wanted.
Screenshot
The Code
  • sender.exe
  • sender.frm
  • sender.vbp
  • sender.vbw


Click for fullsize
Control Software Code - Receiver
Overview The receiver code simply accepts commands from the sender and sends those codes to the controller card. There is no checking for valid commands, so be careful! The receiver also has a timer on it so if a certain keep-alive command is not received in time (around 2 seconds) then a stop-all command is sent. This is really important because if communication between the bot and the laptop is severed then we want it to stop dead.
Screenshot
The Code
  • receiver.exe
  • receiver.frm
  • receiver.vbp
  • receiver.vbw

Site by Kallahar -