Let's Make Robots!

Global Domination Robot (GDR) Mk 2

Navigates around via ultrasound, moves turret and fires "Death Ray" at targets

Update 28 NOV 12:

- I've fiddled with the targeting code and now have it written correctly so that the GDR will enter "Sentry Mode", will scan 180 degrees using an ultrasonic rangefinder on a turret, will record the distances to everything in front of it, and then will scan back and forth and will stop and fire on anything that approaches (change in distance from previously set distances)

- I have some issues with performance on these scans as sometimes the GDR will perceive a difference in distance when none exists.  I believe this is due to a lack of regular power to the rangefinder.  I have to do some more research to see if there's a way to fix this through the use of capacitors, or running a separate power source directly to the rangefinder.  Currently it is powered (along with two servos and a laser pointer) directly from the arduino.

- My "laser death ray" has stopped working on the pin that I had it running on.  A friendly helper on one of the arduino forums pointed out that since the laser pointer is designed to run on 3V 35mA, when I run it off 5V it is likely drawing more mA than the pin socket can handle and is burning it out.  Time to do some math to figure out what size resistor I need to put in the line to the laser to bring the 5V output back down to 35mA.

- I've replaced the large wheels and caster of the GDR with a pair of tracks.  Robot moves far slower now, but is a lot more stable.

 

Update 22 NOV 12:

Here is the GDR Mk 2. I've recycled the parts from the GDR Mk 1 and made some additions/upgrades:

- Built a body for the robot out of a couple of storage boxes

- Added a 2 POF Turret to the top

- attached a laser pointer to the turret and programmed it to aim and fire

- split the power so there is now dedicated power to the motors.

 

I'm fairly happy with the outcome of the GDR Mk2 so far. Right now he just navigates around with the ultrasonic, avoids obstacles, and every now and then he pans the turret around and engages enemies with his laser. Its not really targeting anything right now, its just going to set locations for deflection and quadrant (the two POFs of the turret) and firing in a pre-programmed pattern.

This could be considered "complete" at this point based on my GDR development plan below, but I'd like to experiment with some of the Mk 3 upgrades on this build. I think I can work some of my Mk 3 upgrades (see plan below) just with changes to the programming code, but we'll see. To make it actually target someone/something: I plan to have it stop now and then, scan distances at different angles in front of it, record those distances, and then continue to scan and anytime something breaks those distances (a person or object approaches) it will fire at them with the laser pointer. I would like to have the ultrasonic get the size of the object it detects by having it pan right/left and up/down and recording when the distance changes (sides of the object) and then firing the laser at the midpoint. I'll have to play with it to see how it works.

The other upgrade that will move this to the Mk 3 model will be the ability to navigate to a specific location to set up sentry. Would love any input or advice that people could give me on this.

GDR model plans:

- Mk 1: First Bot, just an obstacle avoider

- Mk 2: Simple navigating robot that occasionally stops, pans turret around and fires "weapon"

- Mk 3: Upgrade navigation to go to move to a specific location and "guard" (would love input on the best method for this. GPS?) once in position will scan with ultrasonic sensor and when object/person approaches will target and fire on them.

- Mk 4: Upgrade size of chassis (with an old scooter or golf cart?) and replace laser pointer with an airsoft or paintball gun.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hello Kane, it's refreshing to see someone on the board who understands what robots are REALLY about.  It's not about Sweet.  It's not about Cute.  Its about TOTAL, WORLD DOMINATION!!!

Congratulations on your robot, it came out very nice.  It is cute but of course as it is laser armed no one will Dare to throw that in your robot's face...LOL.

In regards to navigation, you first have to know where you are to know where you are going.  I am interested in testing a theory for identifying the room my robot is in, by having it take 8 range measurements and then summing these to get a number.  This number would then be compared to a table of numbers (one number for each room in the house).  In theory the room which matches most closely is the room you are in.  Once you know what room  you are in, you can use a kind of  map table  in memory to navigate from one room to another.

Will that work?  Beats me, I am going to find out with robot #2, he will have a kind of sensor turret on the top of his head to shoot the room measurements.

Good luck on your project, when we get the time we should start dividing the planet up into zones of control for the upcoming rise of the Robotic Overlords...LOL.

 

 

Awesome.

Although I'm getting loads of info from you guys on the navigation part, I'm still working through the bugs on the "sensing a target and attacking it" part.  I posted this in the forums, but maybe y'all could lend a hand on this too?

What I'm trying to do is use an ultrasonic rangefinder attached to a servo to scan the area in front of the robot in a 180 degree arc, and record the distances at each degree in an array.  Then I want to have my bot scan the area over and over, re-looking that 180 degree arc.  When one of the distances changes, that should trigger the bot to fire a laser at the spot where the "intruder" is.

I think maybe I'm having trouble because I have an "if" statement within a "for" loop, but I'm not sure.  Maybe its the "continue" command? I don't know, there's a lot of commands I haven't used before in this bit of code.  Right now the bot is properly recording the ranges at different degrees, but then starts slewing the laser back and forth when it goes into its scan mode.  If nothing else everything should stop when the laser fires... or so I would think.

 

Here's the code:

#define trigPin 6
#define echoPin 7

// servo stuff
#include <Servo.h> //include servo library
Servo servoMain; // Define our Servo.  It will start set at 90 degrees

int laser1 = 5;  // set laser trigger to dig pin 5


void setup()
{
  Serial.begin (9600);  //Serial input for rangefinder if we hook it up to computer
  pinMode(trigPin, OUTPUT); //rangefinder setup
  pinMode(echoPin, INPUT);  //rangefinder setup
 
  servoMain.attach(14); // servo on pin A0
 
  pinMode (laser1, OUTPUT); // prepares pin A1 to power the laser
 
  servoMain.write(90);
}


void loop()
{
  int distancedata[181]; // defines our search deflection array
  int iterations;  // variable for total number of iterations
  int def; // sets variable for deflection
  int duration;
  int currentdist;
  int scandif;
 
  servoMain.write(0); // turns servo to start position
  delay (500); // gives servo time to get to 0 position
 
  for (int def=0; def <= 180; def++){  // this for loop will make the robot pan its servo 180 degrees and take a distance measurement
    servoMain.write(def);  // Turn servo
    delay (5);
   
    digitalWrite(trigPin, HIGH); // get distance at current deflection
    delayMicroseconds(1000);
    digitalWrite(trigPin, LOW);
    duration = pulseIn(echoPin, HIGH);
    distancedata[def] = (duration/2) / 29.1; // set distance at each deflection in array
    Serial.print (distancedata[def]);  // I used these commands to check that this section works (it does)
    Serial.print (" at ");
    Serial.print (def);
    Serial.print ("  ");
  }
 
  for (int iterations=0; iterations <= 5; iterations++){ // Sets total number of times that bot will conduct scan
 
   for (int def=180; def >= 0; def--){  // scan and check distances from 180 to 0 degrees
    servoMain.write(def);  // Turn servo
    delay (5);
     
    digitalWrite(trigPin, HIGH); // get distance at current deflection
    delayMicroseconds(1000);
    digitalWrite(trigPin, LOW);
    duration = pulseIn(echoPin, HIGH); 
    currentdist = (duration/2) / 29.1; // set distance at each deflection in array
   
    scandif = (distancedata[def] - currentdist);
   
    if (scandif >= 10){  // checks if current distance is over 10cm different from original distance
      digitalWrite(laser1, HIGH); // fires on new target if not
      delay(1500);
      digitalWrite(laser1, LOW);
    }
    else {  // continues scan if current distance is not more than 10 cm of original distance
      continue;
    }
 
   for (int def=0; def <= 1; def++){  // scan and check distances from 0 to 180 degrees
    servoMain.write(def);  // Turn servo
    delay (5);
     
    digitalWrite(trigPin, HIGH); // get distance at current deflection
    delayMicroseconds(1000);
    digitalWrite(trigPin, LOW);
    duration = pulseIn(echoPin, HIGH); 
    currentdist = (duration/2) / 29.1; // set distance at each deflection in array
   
    scandif = (distancedata[def] - currentdist);
   
    if (scandif >= 10){  // checks if current distance is over 10 cm different from original distance
      digitalWrite(laser1, HIGH); // fires on new target if not
      delay(1500);
      digitalWrite(laser1, LOW);
      continue;
    }
    else {  // continues scan if current distance is not more than 10 cm of original distance
      continue;
    }

  servoMain.write(0); // turns servo to start position
  delay (500); // gives servo time to get to 0 position

  }
  }
  }

Like fifer253 recommended, dead reckoning can be used for navigation your are talking about. Wheel/motor encoders to keep track of the X Y coords along with a compass to correct heading errors that will accumulate over time.
The best reading I've found for this is here:
http://www.seattlerobotics.org/encoder/200610/article3/IMU%20Odometry,%20by%20David%20Anderson.htm
Stephen

This looks like about exactly what I'm looking for in the future for navigation.  Thanks for the link.

I like the project. :)

for navigation indoors, you will not have any luck with GPS, as the accuracy is at best ~5m and can be as bad ~15m, lots of error. for navigating, I would recommend either, if you know where you are, and where you are going, dead reckoning using motor wheel encoders, or if you can, line following. Dont know where you are? not quite sure where you are going, except there is something to guard there? I think the best option would be a becon, either IR or visible light. if you are in just one large room, you would be able to get away with just one becon, but if you are planing to navigate thru multiple rooms, hallways etc. what I would recommend would be a beacon in each space that your robot can acess, probably using some IR tec, and using say, a picaxe to modulate on top of the carrier frequency a different signal so the robot could tell the becons apart, and could drive around untill it finds one, as soon as it reaches it, not look for that particular beacon anymore, and look for a differently coded one. in this way, you could make waypoints, almost like GPS that your robot navigates to, once your robot reaches one, it will look for the next one that would be closer to it's ultimate goal, and continue in this way untill it gets there.

Great feedback, thanks for the input.  Eventually I envision this as an "outdoor" project as of course the later models of the GDR will be deployed to impose my will on targeted areas/countries on my path to world domination :), at which point I think the GPS, or a version of the GPS system, may become applicable.

What do you think about possibly setting a waypoint or "coordinate" and having the robot navigate towards it? Not a GPS coordinate, but something the little robot brain can keep track of internally?  Like if the robot knew that it started at X=0, Y=0 and it's target was at X=500, Y=500 and it had to get there tracking its own progress with a motion sensor or something?

The beacon system looks like it would work with some fairly simple logic, and I may use that as an interim, but I'd like to be able to tell the GDR where to go and have it perform its mission autonomously after that (without having to go ahead of it and set up a trail of beacons to follow).

 

Some of the other comments probably already answered your questions, but I think GPS would be simplier to implement on an outdoor robot, because to build the conceptual system you mentioned, you would probably need an IMU, possibly a compass, wheel encoders, (and then, what if you dont have perfect traction all the time? then your wheels slip, and your encoder data goes out the door) and you would have to program something that takes all that into account. Me, I am not very good at programing, but if you do do something like that, I will really look forward to seeing it happen.

Well, first I'm trying to get the targeting system straight, and I've gotten a little help in the programming forums on what I might have been doing wrong there.  After I get the GDR to target and destroy an approaching enemy then I'll work on the navigation. 

In real life I work with a system that uses a VMS (Vehicular Motion Sensor) that has a GPS backup to check itself periodically.  It can also check itself off of a known point (survey control point) to keep that VMS accurate.  I think that's probably a good system for my little killer robot too... having a primary form of navigation with a secondary check.  Anyway, like I said, its a bit down the road because I need to get the targeting system working first.