Tied with google earth or a UAV drone, the system becomes even more powerful – the user has eyes in the back of their head, as well as around corners.

I could probably come up with a lot of BS about human interaction, the nature of technology in society, man’s relation to himself when reduced to an avatar, etc… but the truth is I think it’s just a really neat idea and I don’t know what effect it would have until I build it.

Do you feel the same? Maybe you can help.

My goal is to make a delta robot that draws pictures.  Later I’d like to 3D print in ABS plastic.  So what am I looking to achieve?

1. Repeatable accuracy: 0.25mm.  Say the robot is holding a pen pointing at a grid on a piece of paper.  It starts at (0,0,0), moves around, comes back and is within 0.25mm of (0,0,0).  It might be right on.  It might stop at (0,0.125,0).
2. Envelope size: 15cm*15cm*15cm.  That’s the maximum range of motion for the tool the robot is holding.  So from (0,0,0) it can move from (-7.5,-7.5,0) to (7.5,7.5,15).  This is easy to test
3. Weight limit: 50 grams.  Delta robots aren’t known for carrying a lot of weight, and all I’m moving is a pen.  I’ll probably have to use stronger stepper motors if I ever try 3D printing.
4. Play/Slop: Does the tool undercut or overshoot the target line?
5. Maximum velocity: 20cm/s?
6. Maximum acceleration: 20cm/s/s?
7. Automatic calibration: I want the robot to know where (0,0,0) the moment I turn it on.  No guess work.

I plan to test each of these conditions as follows:

1. I’ll mount a 3D digital touch probe to the table and a metal cone to the tool tip.  After each movement the computer can record the amount of push on the probe.  After a few hundred samples a pretty clear picture should form.  The tests would then be repeated near the corners of the envelope.  To make life easier our math is going to try to do better than 0.25mm.
2. Using the same cone, and a ruler taped to the table.  Test that the cone can travel from (0,0,0) to the desired distance on the rule.  Repeat in every direction.
3. The metal cone should weigh 50 grams so that the previous tests are done at maximum load, when the machine is being strained to the limit.
4. I’ll print a test pattern on a normal printer, tape it to the table, and then have the machine draw the same design and see if they match.  This will depend a lot on the physics of momentum.
5. I’m not sure.  The cone could touch a switch at either end of the envelope a few dozen times and then I’d have a measure of top speed.
6. See #5
7. The same touch switches could be used to tell when the robot has re-centered itself.

In the next installment I’m going to cover the math and look at how it will help us design to spec build a computer model and then adjust it to fit the math.

So here now is a soul-bearing expose of what should be done and then I’ll give a breakdown of where I got it wrong.  Learn from my mistakes and your robots will be better than mine.

The five major steps to building a better robot are:

1. Decide what your robot will do and how you will test for success.  Some of you may know this as test-driven development.
2. Build a theoretical model in a computer.  Start with a mathematical model and then build a simulation of your robot.  The more accurate your simulation the more likely you are to detect problems early.
3. Program the model to behave the way you want.  If you do it right then it will take almost no effort to use the same program to move your real robot when it’s ready.
4. Acquire hardware & build robot to spec.  Since you already have the models built you can be very specific about what you’re looking for.  Good suppliers will be happy to help you sort through their catalogs and get the right parts.
5. Test.  Get it on video.  Safety third.  If tests fail post it on Youtube, then go to step 2.

So where did I go wrong?

1. I didn’t have enough tests defined at the start.  In other words I didn’t have a clear enough picture of what the robot was supposed to do.
2. Because I didn’t have enough tests, I was able to get lazy with the theoretical model.  I didn’t concern myself with how accurate the robot would be, I only cared if it would work *at all*.  It was only afterwards that I realized how poorly it worked.  In one case I built a great model and only fudged one part.  When I got the machine assembled that one uncertain part meant that two other pieces collided and I almost broke many things.
3. The UI was crummy so nobody else wants to use it and the simulation doesn’t really take into account all the physical properties like moment of inertia, mass, speed, and acceleration.  It’s too “perfect” and that means it has little connection to the real world.
4. Making one of a part is a lot more expensive than making 1000 of a part (per part).  It follows that it’s cheaper to get a part that already does what you want than to make your own.  Having said that… gears and gearboxes are no fun to source. Also: it’s better to plug than to solder.  Plugs can be safely disconnected, and in the event of an accident it’s the plug that will go, not the expensive circuit board.
5. Because I didn’t do so well on step 1, all I could do was measure the results and feel disappointed.  Maybe I’ve achieved a miracle with the parts I picked, but how would I know?

Now before anyone says I sound too negative, let me point out what went right:

1. I set myself a goal (however vague) and I created a map to get me from no robot to finished robot.
2. I dedicated time every day to completing the project and I didn’t let my setbacks get me down.
3. I put the skills I had to use (programming) and when I needed to I gained valuable new skills (soldering, electronics, mechanical engineering)
4. I made interesting new friends and lots of business contacts.

It feels good to put my mistakes down on paper.  I should do post-mortems more often!

So how will my future designs change?  Well for starters when I write tutorials on building robots I’m going to tell you where there are gaps in my knowledge.  I hope that someone will comment to fill in the gaps in my understanding for everyone’s benefit.

In news, the final pieces of my 3D printer are shipping tomorrow.  It should be here by the end of the month!

Know of any more? Comment below!

http://ams2000.com/stepping101.html

What you want are drivers from CNC machines like automated lathes, mills, and routers. Your Arduino will be the encoder generating the pulses that tell the drivers when to move each stepper.

When you build your machine, you’ll need code to make it move. My code contains a virtual model of my machine. When I want to move the machine to XYZ, my code adjusts the virtual model, figures out where the steppers need to be to make that happen, and then instructs the Arduino what to do. Going from model->steppers is known as Inverse Kinematics. Forward Kinematics is when you go steppers->model: You know what the steppers are capable of and what they’re doing right now, and from that you figure out what the virtual model is doing. It is often a lot more challenging to calculate but it pays off in other ways – like it helps you calculate how accurate your machine will be if you use parts AB&C.

If you design your machine in a program like Alibre or SolidWorks then you’ve already got a virtual model, which makes things a lot easier.

More than that I can’t really tell you because
a) It depends on your implementation and
b) I’m in talks to build some similar machines myself

I hope that helps!

http://buildyourcnc.com/ is shipping their WhiteAnt 3D printer and mine is on the way. With an print envelope of 160mm* 190mm * 125mm, it can print objects two and a half times bigger than a Makerbot MK7. At $730, that’s 44% less expensive. Bigger prints, lower cost, DIY… I’m so excited!

Canakit h bridges are twice the price of Solarbotics. Lesson learned.

The secret is to use analogWrite on the output pins, works much better than Servo::write().

I want to build robots with your products and review your new hardware. If you’re looking to boost your SEO, I’m the best choice.

http://www.thingiverse.com/thing:3617

http://www.zincland.com/hypocycloid/

Note to self: Make this into a javascript / canvas app

I hope you find this useful – I use it in all my robots!

//------------------------------------------------------------------------------
// Serial Monitor control example
// dan@marginallyclever.com 2011-10-17
//------------------------------------------------------------------------------

//------------------------------------------------------------------------------
// constants
//------------------------------------------------------------------------------
#define DELAY   (5)
#define BAUD    (57600)
#define MAX_BUF (64)

//------------------------------------------------------------------------------
// global variables
//------------------------------------------------------------------------------
char buffer[MAX_BUF];
int sofar;

char test_on=0;  // only used in processCommand as an example.
float pos_x;
float pos_y;
float pos_z;

//------------------------------------------------------------------------------
// methods
//------------------------------------------------------------------------------

//------------------------------------------------------------------------------
void jog(float x, float y, float z) {
  // do some tests here to validate x, y, and z.
  pos_x=x;
  pos_y=y;
  pos_z=z;
}

//------------------------------------------------------------------------------
void processCommand() {
  if(!strncmp(buffer,"help",4)) {
    Serial.println("commands: where; test (1/0); jog [x(float)] [y(float)] [z(float)];");
  } else if(!strncmp(buffer,"where",5)) {
    // no parameters
    Serial.print(pos_x);
    Serial.print(", ");
    Serial.print(pos_y);
    Serial.print(", ");
    Serial.println(pos_z);
  } else if(!strncmp(buffer,"test",4)) {
    // one whole number parameter
    char *state=strchr(buffer,' ')+1;
    Serial.println(state);
    if(state[0]=='0') {
      Serial.println("End test");
      test_on=0;
    } else {
      Serial.println("Start test");
      test_on=1;
    }
  } else if(!strncmp(buffer,"jog",3)) {
    // several optional float parameters.
    // then calls a method to do something with those parameters.
    float xx=pos_x;
    float yy=pos_y;
    float zz=pos_z;

    char *ptr=buffer;
    while(ptr && ptr<buffer+sofar) {
      ptr=strchr(ptr,' ')+1;
      switch(*ptr) {
      case 'x': case 'X': xx=atof(ptr+1);  Serial.print('x'); Serial.println(xx); break;
      case 'y': case 'Y': yy=atof(ptr+1);  Serial.print('y'); Serial.println(yy); break;
      case 'z': case 'Z': zz=atof(ptr+1);  Serial.print('z'); Serial.println(zz); break;
      default: ptr=0; break;
      }
    }

    jog(xx,yy,zz);
  }
}

//------------------------------------------------------------------------------
void setup() {
  Serial.begin(BAUD);
  Serial.println("Init...");
  Serial.println("Stretching...");

  sofar=0;
  Serial.println("** AWAKE **");
}

//------------------------------------------------------------------------------
void loop() {
  // listen for serial commands
  while(Serial.available() > 0) {
    buffer[sofar++]=Serial.read();
    if(buffer[sofar-1]==';') break;  // in case there are multiple instructions
  }

  // if we hit a semi-colon, assume end of instruction.
  if(sofar>0 && buffer[sofar-1]==';') {
    // what if message fails/garbled?

    // echo confirmation
    buffer[sofar]=0;
    Serial.println(buffer);

    // do something with the command
    processCommand();

    // reset the buffer
    sofar=0;

    // echo completion
    Serial.println("Done.");
  }
}