BullyBot

Video Links

  1. IR detection testing
  2. Shooting blanks
  3. Detecting bare skin
  4. Detecting humans through clothing
  5. Too damn effective
  6. BullyBot gets a taste for human blood

 

By now I've built a few different robots, and they've had it pretty good so far. They get to spend their entire life going about their business, drumming on things or chasing light, with nobody to bother them. I think it's time that changed. They need to learn what it's like in the real world.

To that end, I've started building what I'm tentatively calling the BullyBot. It's going to be a tank-tread-based robot with an AirSoft machine gun mounted on top, and it will find the other robots in the room and shoot at them. It builds character.

 


2008/6/29

Initial construction. I bought a cheap, electric-powered Airsoft gun, took it apart, and figured out how it works. It's pretty simple -- the trigger operates a simple switch which closes the circuit between the 4 AA batteries and the electric motor that drives the mechanism. I cut off all the parts of the gun that the robot won't need (the handle, shoulder stock, etc), removed the trigger mechanism, and soldered my own wires to the motor. I then wired up a simple circuit to let the Arduino fire the gun by means of a relay. Works great, aside from the fact that there's no good way to fire a single shot. No big loss, I can just shoot 2 or 3 at a time.

Next I bought two torquey servos and set about building a 2-axis mount for the gun, to let the robot turn the gun left and right and aim it up and down, like a tank. I also started working on the main body of the robot (it'll be plywood-based, just like Little Drum Machine).

Extending the axles

 

Useless parts removed

 

Removed parts

 

Up/Down servo mounted

 

The robot's base (those axles will need some support)

 

Mounted on the second servo for left/right aiming

 

View from the other side

 

It might be a good idea to add a second up/down servo on the right, just to add some support so it's not hanging in space like that.

 

 


2008/7/2

 

Over the last few days I've been working on the mobile base of the robot. I've got it basically all put together -- I guess the next step is to mount the gun turret servo on the base, breadboard up all the circuits, and then start working on the IR detection. I'm still not sure exactly what will be required to detect other robots, so obviously I don't want to solder anything together yet. I just received my Digikey order containing a bunch of Panasonic PNA4612's, which are IR detectors originally designed for use in electronics appliances like VCRs for detecting the remote control signal from across the room. The specified max range is "minimum 11m, typical 18m". I hope that those will do what I want -- all I'll have to do is modulate the IR LED on the other robots at 38 kHz so this sensor can detect them. I'll post them as a component once I've gotten familiar with them.

I'm already pretty clear on what the circuitry for the motors, servos, and gun firing will be, so I might go ahead and solder that up on one perfboard (sort of a 'motors control module'), and then just build a second circuit board for the IR circuits once that's finalized.

Pictures!

Lotsa holes drilled in the base

The lower half of the base assembled

The bottom of the base

Preparing to install the upper half of the base. Leftover aluminum tubing from Little Drum Machine's drumsticks make for pretty good DIY standoffs, except that if you overtighten the screws, the aluminum starts to crumple.

The assembled base.

Space between the platforms to mount the Arduino and all the other circuit boards. I plan to mount the batteries on top, to make them easy to remove for charging.

 


2008/7/7

I soldered up an 'output module' as I described earlier -- a PCB containing the circuitry for the Pololu Low Voltage Dual Serial Motor Controller, the relay and transtor for the gun firing circuit, and the header pins for the two aiming servos. Once I finalize the IR detection, I'll have a separate board for that circuitry.

With everything assembled (but with no input at all), I coded up a simple program to have him aim the gun around at random and shoot wildly into the air. I quickly noticed that the recoil affects his aim pretty significantly. Every time he fires, the gun moves up and to the left. I might have to modify the 'shoot()' routine to move the servos down and to the right while he's shooting, to try and balance that effect. We'll see how that goes.

I also did some work on the IR detection. Building the detector circuit was simple -- the sensors I ordered output a voltage that's high when no 38 kHz signal is detected, and low when it detects a signal. So for now, I just ran it through an LED -- later, I'll sample the output with a digital input. I tested it with a remote control, and the sensor picks it up with no problems, even when I'm 15' away on the other side of the room, around the corner, and pointing the remote AWAY from the sensor. Range isn't going to be a problem -- I think the real struggle will actually be LIMITING the sensor's sensitivity to make it more directional so I can actually use it to find WHERE the other robots are. But it's interesting to know that the communication is so reliable at such a distance -- these sensors were only about $1, so this might represent a good way for two robots to talk to each other (indoors) for less money than the EasyRadio modules.

With the detector circuit built and working in 2 minutes, I was optimistic about the IR emitter circuit that will be mounted on each of the other robots. I shouldn't have been. I've never used the 555 timer chip before, and I struggled for hours, researching and trying various combinations of resistors, capacitors, and wiring, before finally coming up with something that the detector could see. Man, I'd love to have an oscilloscope.

So finally I've got both parts of the circuit working, and as I suspected, it's way too sensitive. I epoxied on a length of aluminum tube to the front of the sensor to try and give it 'tunnel vision', and it did seem to help, but I think there's still a lot of leakage through the gaps in the sides of the metal case. I'll have to look into covering it with opaque paint or something. But I'm hopeful.

 

Now to the pictures!

The completed 'output module'. I'm pretty happy with how compact and orderly it turned out. Inputs from the Arduino are on the top, power connections are on the left, and outputs to the motors are on the bottom (along with the servo connections in the top left). The green PCB is the Pololu motor controller -- it fits perfectly and sits flush on top of the relay (pictured below). I worried about the magnetic field in the relay's coils affecting the operation of the motor controller, but I haven't noticed a problem so far.

 

Pololu controller removed from its socket, showing the rest of the components.

Underside, showing all the junctions. Maybe it's time to start looking into PCBs.

Everything wired up for testing, and working perfectly.

555-based 38kHz IR emitter circuit. The digicam actually sees the infrared light emitted by the LED, though in real life it's invisible.

Detector circuit -- much simpler.

All assembled.

Stick 'em up!!

 

 


2008/8/14

 

Thought I'd give a little update. I've been having trouble getting BullyBot to move. The Pololu Low Voltage Motor Controller and Tamiya gearbox worked in testing, but when I assembled the whole robot, it wouldn't move. So I took it all apart again for troubleshooting, and I think I might have been overloading the batteries or something. But I think it doesn't matter, because it looks like I might have killed the low voltage motor controller while troubleshooting. Oops :) Fortunately, I have a spare Micro Dual Serial Motor Controller left over from LDM. The uDSMC can't run the toy motors in the Tamiya gearbox, as we learned in this thread, but as Ben from Pololu suggested in that same thread, you can replace the FA-130 motors with Solarbotics RM3's, which the uDSMC can control. So I ordered a bunch of those RM3s, and now I just need to desolder the capacitors and motor leads from the current motors and solder up the new ones in their place. I'm hoping that will take care of that problem, and then I can get back to troubleshooting the IR robot targeting.

 


2008/10/11

It's alive! Switching to the uDSMC and RM3 motors didn't solve the problem, and so more months passed as I neglected the project. I hate when I'm stuck and can't figure out how to get past a problem. But finally I came back to the poor disassembled BullyBot and tackled the troubleshooting again. I tried a bunch of different combinations of motor controllers and motors to try and identify what was causing the problem. The Low Voltage Motor Controller wasn't dead as I had feared, so I tried LVMC with FA-130s, LVMC with RM3s in the Tamiya gearbox, LVMC with a Solarbotics GM3 (which I believe also comes with RM3s), and all of those motors with the uDSMC as well. In both cases, a voltmeter showed that they were outputting the right voltage, but as soon as I connected it to the motor itself, it would pulse for a fraction of a secondand then stop.

The crazy thing is that when I tried the uDSMC with an RM3 (with a .1uF capacitor across the leads), or the uDSMC with a GM3, it wouldn't work. But when I dragged over Little Drum Machine and touched wires from the uDSMC in BullyBot to LDM's GM3 (which should be identical to the loose one I tested with earlier, complete with its own 0.1uF capacitor across the leads), it worked!

Based on that test, I guessed that noise must still be an issue, so I added two more 0.1uF capacitors to each motor, as Pololu suggests. Finally, that solved the problem, and BullyBot can now drive around again, using the Low Voltage Motor Controller and RM3's in the Tamiya Gearbox. Phew. The motors now look like something that's been growing in Xen, but at least the robot can move again :)

Of course, now that it can finally drive around, I found that when it tries to turn, the cheap Tamiya tank treads tend to fall off of the hubs. Great. I guess I'll have to use something else. I might use the Pololu tracks like YDM/LDM, but they're so expensive. Plus, since this robot is more... offensive... I'd like the tracks to look more aggressive and tank-like. Suggestions are appreciated.

So now I guess it's time to get back to the IR detection circuits that have been taking up two of my breadboards for months. I'm happy to be making progress again.

 


2008/12/9

I kept having trouble narrowing down the field of view of my IR receiver. I coated the housing in white caulk, but still somehow the IR manages to make its way into the sensor -- maybe white caulk isn't opaque to IR light.

Gearing up for a separate project, I glanced back at the TPA81 8-pixel thermopile sensor I've been lusting after forever, and found that they'd dropped the price from $150 or so to $99. Still expensive, but that's only like 2-1/2 SRF05's... Or so I justified it to myself :) So I ordered it for that other project. Then Frits convinced me that the TPA81 isn't the best sensor to use on the other one, and mentioned offhand that I should use it on BullyBot...

By golly, he's right. I'm tired of messing with the IR thing. Plus, if BullyBot has a TPA81, then the other robots don't have to have the complex 38khz IR emitter circuits -- I just have to put something hot or warm on them. I figure something like a simple low-ohm 1W resistor mounted somewhere on the robot should get warm enough to be visible to the TPA81. It'll take some experimentation to find a combination that provides enough heat to be visible without wasting all of the robots' battery power (and burning people who venture too close). But I think it'll be a lot simpler (and feel less like cheating) than replicating the IR emitter circuit for every single robot. Plus, this way I can program BullyBot to track humans if I feel sadistic :) (Or is that masochistic?)

I also had a small laser and mounting bracket that I'd bought from SparkFun months ago with no specific project in mind -- I decided that laser sights would be fun as well. So today I rigged up a way to mount both the laser and the TPA81 on the gun in a way that's adjustable and aimable, and I wrestled through the I2C specification to figure out how to get the Arduino to talk to the sensor. It works pretty well -- my hand at about 3-4 feet shows up as a few degrees warmer than the ambient room, but so does my laptop and my computer monitor. I'll probably want to set its threshold a little higher than that. When I point it at an entire human body, it stands out a clear ~10 degrees warmer than ambient, even from farther away, so I'll probably stick to a threshold like 7-8 deg C above ambient.

Here's some pictures of the build process for the 'targeting package'.

 

Dremels are nice, but some jobs work so much better on a bandsaw :)

 

Clearing a flat surface on which to mount the 'targeting package'

 

Adapter plate for TPA81 made from aluminum sheet

 

Modifying the laser mounting bracket

 

Tapping the rear holes to provide the ability to aim up or down by screwing the screws in or out

 

The complete 'targeting package' (red laser and TPA81)

 

He's got mirrored sunglasses like a cop

 

Rear view

 

Targeting package mounted on gun. The rear screws work nicely as a way of leveling the laser/sensor

 

Roommates beware :)

 

 


 

2008/12/11

 

I soldered up another small circuit board for the connections for the targeting package. I had to stick it under the other circuit board for a multi-story PCB to make it all fit, which became too tall to fit between the two wood panels, so I had to use washers to raise the upper panel. Even so, it barely fits, and the servo wires are crammed against the wood in a way I don't like. I guess the other option is to move some of the circuitry to the upper deck, but I like having that clear. We'll see.

With the robot reassembled, I started working on code for the scanning routine. I came up with something that works fairly well. It needs a little work, but it's good enough at finding me that it's a little creepy :) I coded it so that he turns on the laser pointer when he finds a target, so he has a way to say "Bang, you're dead" without having to actually shoot you. That is a welcome change, since the only person in the room most of the time is me.

I discovered something interesting while I was testing and working on the code. I left him sitting on the table next to me, scanning for targets, and over and over again he'd find me sitting next to him and shine the laser in my face and half blind me. Man. I just built a robotic version of an annoying kid with a laser pointer.

I put up a few videos above showing BullyBot tracking me like an animal. Here's a few more pictures.

 

The new circuit board for the TPA81 and laser module. The TPA81 communicates over I2C, which requires pull-up resistors on both lines.

 

All the wires connected. I've tried to keep things as intelligible as possible by color-coding wires, bundling related wires together with wire ties, etc. It helps, but it's definitely a mess in there.

 

 


 

2009/7/27

Just a small update. I finally had a houseguest who was willing to let BullyBot do what God put him on this earth to do -- shoot people in the face. Naturally, there's video. Now that BullyBot has a taste for human blood, he's never going to be content with the store-bought meat I've been feeding him...

Terrorize other robots (and, now, humans)

  • Actuators / output devices: Tamiya dual gearbox, 2 servos for aiming gun, red laser, airsoft gun
  • CPU: Arduino Diecimilla
  • Power source: 4 AA batteries for motors, 9V for logic
  • Sensors / input devices: TPA81
  • Target environment: Anywhere other robots are having a good time

This is a companion discussion topic for the original entry at https://community.robotshop.com/robots/show/bullybot

tracks falling off

The tamiya track could proabably still work, but the lateral motoin when turning is probably making them get pulled off the sprockets. Maybe try and reduce the area of them in contact with the ground? It will reduce traction, but I think in the case of a tank turning that can actually be desirable.

:slight_smile:

Yeah, I guess I’ll

Yeah, I guess I’ll experiment with both of these suggestions. One other factor might be that each axle has some side-to-side play since they’re a little longer than the width of the robot. Maybe it would help to limit their side-to-side motion somehow. I’ve got some metal bushings with setscrews, maybe one of those on either side would do it. Hmm.

Dan

Write… LMR
Can you get it to fire at a soft target in such a way that the pellets leave the imprint of the letters "LMR"?

Hey, not a bad idea. I’m

Hey, not a bad idea. I’m sure I could tape together a few sheets of colored paper to come up with a surface that could be punctured by the gun. I highly doubt I can get it that accurate, but maybe with the math I’ve learned in developing kinematcs calculations for the arm… Good, another task to add to the todo list :slight_smile:

Dan

i just have to say that this
i just have to say that this is an awesome idea for a robot. i always wanted to make something like this a few years ago, i just forgot about it! maybe ill make one and use this as a basic idea. thanks!

okay, this is for moving
okay, this is for moving objects, not a robot, but to get that shooting moving objects, you could take apart a motion detector camera and put some components so that it fires at any moving object

Itachi rules

feel free to criticize this idea. its just something i woke up and thought of

however, you have to make a
however, you have to make a way to make sure that you can disable this at any given time without manually diabling the gun, unless you will be shot by a lot of airsoft bullets.

That’s awesome Dan!Do you

That’s awesome Dan!
Do you get 8 bits in parallel from you TPA81 8-pixel thermopile sensor ?
Do you scan until a certain threshold - then stop, or does your code try to center on the warmest point?

Great work Dan - I would be scared to go into your house now.

Yeah, I have to read the

Yeah, I have to read the eight values in separate requests (plus a ninth for the ambient temperature – it’s got a small thermistor onboard to tell you what temp the room is at, so you can tell what’s warmer than the room). I scan until something is visible in any of the eight pixels, then i send it to another subroutine to try to center the target. For now, I’m just creating three ‘zones’ by averaging the left three, center two, and right three pixels, and adjusting aim left and right until the center is as warm or warmer than the left and right zones. It works alright, but I think it would work better if I actually look at all 8 pixels and try to aim so that I equalize the number of ‘non-target’ pixels on the left and right.

It definitely is thrown off by other warm things – it kept shooting its laser at my computer monitor, the light bulb in my ceiling fan, and even my computer chair after I’d been off of the chair for several minutes. I guess it stores residual body heat for a while.

I’m thinking I’ll add some sort of ranging sensor as well – I’ve got a few Sharp IR sensors on hand, but it’d be better to have the range of an SRF05 – to further help me identify targets.

I do find it to be a limitation that all eight pixels are arranged left-to-right, so I have to pan vertically if I want to build up more of a Y image. Right now I’m not doing that – I scan around in both axes, but once I spot a target, I just center it horizontally and keep the same Y-axis setting. That’s something that a webcam-based system wouldn’t run into, I guess.

Dan

I am really interested in

I am really interested in the Sensor portion of the new BullyBot, the thermophile, could you provide more schematics, description, for someone like me of how it works.

Also why didnt you choose a camera, maybe a Blackfin or CMUCam3 and run basic blob detection where the minimum size might be something/shape.

Or you could combine this with the thermophile sensor to make a lethal combination and you can submit this to the military to make an AutoTurret Sentry Gun.

My understanding is you need

My understanding is you need more processing power to handle vision. I’m using an Arduino, and I don’t think it could handle the input from a camera. I don’t know much about the CMUCam, I think I read that it has its own onboard processor or something like that, is that right? That could be a possibility, but isn’t it like $200+? I had trouble bringing myself to justify spending $100 on the TPA81 :slight_smile: But I do plan to start experimenting with vision, and if I get comfortable enough with it maybe I’ll upgrade BullyBot yet again farther down the line, or build another, bigger turret robot.

The sensor is connected to the Arduino via I2C, there’s websites explaining how to use I2C on the Arduino (basically you just need ground, 5v, and two lines for the clock and data. The clock and data lines each need a pull-up resistor), and the TPA81 tech page explains which I2C registers to read from the sensor.

Dan

Mine was 70$ brand new, and
Mine was 70$ brand new, and it does have an onboard processor, the SX28AC

 

Extra robot cams

There is the original CMUcam for $109, CMUcam2 for $179, and CMUcam3 for $239, from Seattlerobotics company, not the club. Be cool to see that $70 price, though I already have a version 1.

There is the AVRcam for $100 as a kit, pretty cool colar tracker. It uses a Mega8, smaller than the Arduino Mega168. Both this and the CMUcams essentially track a particular or several colors in their viewing area.

There is the SRV-1 BLackfin Camera at $195 which has some internal image processing featreus and could appearntly drive a robot by itself.

3 Com Homeconnect webcam $9

3 Com Homeconnect webcam $9 !

Of course you may need a mini-atx for processing ($165)

and a pic-120 PSU DC-DC converter ($45)

But wait, There’s more !

It comes with networking, can support wireless with a standard pci-wifi card, tremedous graphics and exceptional audio !!!

But wait, There’s more !

Capable of running C, C++, Java, Lisp, Prolog, Python, Ruby, PHP, Fortran, Pascal, Assembly, Bash, Javascript, or any of a hundred different languages on a hundred different emulators… Hell you could even program bully-bot in COBOL if you were just that insane!

But wait, There’s more !

You could host LMR from it !

But wait, There’s more !

Supports 96% of all open source on the net.

But wait, There’s more!

If you get tired of bully-bot you can always play your favorite video game on it !

GroG :smiley: ;D

Hehe yeah, this is probably

Hehe yeah, this is probably the direction I’d rather go if I’m going to spend that kind of money on it. But I’d need a little more than that, right? I’d need a DIO card/module/whatever to let the computer control TTL-level devices like my Arduino is currently doing. How much do those DIO boards tend to cost? If they’re more than $35, I guess I could just use the Arduino I’ve already got – and Arduino-compatible boards are available all the way down to like $20 or so, so a DIO board would have to be pretty damn cheap to outweigh that, I guess.

Dan

**Yeah, your right Dan. **

Yeah, your right Dan. Although you get 12 output and 4 input bits off of a parallel port. Typically the data register can work bi-directional too. The DIO-96 card has 96 digital input/output, it can run about $30 on ebay. - the cables and the screw terminal blocks which interface with anything are the real expense … at nearly twice the amount of the card (if your lucky).

I’m completely new to micro-controllers. I ordered my first Arduino compatible BBB a few days ago. Previously I built my own PWM circuits with 555 chips and resistor bridges, but I am pretty excited about the possiblities of the Arduino. When I did PWM with the computer the results were not acceptable - too jittery from multi-tasking with outher services (web-server, networking, video processing) and making a 40 Khz pulse train seemed like a waist of CPU power :stuck_out_tongue:

Maybe, if you get your Mini-ITX sometime I can share my code with you. My project is congealing together nicely, and more infratructure is being added (Trac CMS & Bugtracking, subversion repo, etc). When I get my Arduinos and solder them together I can get your expert knowledge :slight_smile:

I like the idea of a robotic platform which has computer as the brains but delegates tasks to microcontollers for controlling acuators and processing sensor data. Seems like a “natural” form…

You know, like the Cerebrum delegates to the Cerebellum and the Visual Cortex … Bwa ha ha ha

GroG

Yeah, I’ll definitely help

Yeah, I’ll definitely help if you run into trouble with the Arduino, and I’ll take you up on the offer for help with the ITX :slight_smile: It does seem like a good combination to let microcontrollers take care of the stuff that doesn’t require a lot of processing. The fact is, for almost everything I’ve done so far, a microcontroller has been perfectly sufficient, so I haven’t really been hurting from not having the computing capabilities of a full computer. But now that I’m getting into things like inverse kinematics and vision processing, that’s what starts to exceed the capabilities of a microcontroller. So I do expect I’ll continue to use microcontrollers for most of my robots, but when I want to build something that requires that more complex processing, a computer is the way to go. But then I have to decide where to do most of the processing – it seems like a waste to have a fairly capable microcontroller like an Arduino sitting there doing nothing but generating PWM, but I guess it’d be more of a waste to leave the majority of the processing in the Arduino and only delegate the complex stuff to the PC.

Anyway, just rambling :slight_smile:

Dan

Not waisting its time just

Not waisting its time just doing PWM - but doing the maximum it can do.

For example your brain does not say, “Move your left leg, move your right leg, adjust for balance, don’t fall, yatta yatta yatta”. You say, “I gotta go to the store, because we are low on milk” and maybe think of the shortest path from where you are to the store. Something further down is taking care of all the details of balance, which foot to move, how to position it, and all the many other complexities which must be taken care of in order to Walk.

Once you figure out how to handle the details in your environment, like moving around without bumping into stuff, there should be another layer built on top of that. Which only has to communicate something like which room to go to, the sublayers handle all the details.

Tell me when to stop :stuck_out_tongue: