Sunday, February 28, 2010

Mill: new bed, new spindle, new problems...

I did end up getting an aluminium plate to increase hight consistency and a spindle to eliminate runout. Here's a picture of both installed:

They did their job. Hight is much more consistent now and runout is nonexistent. Also, the new spindle is sooooo quiet! Here is a closeup of a 39mm by 17mm circuit outline done with this setup.

As you can see, the bit consistently took the copper off without leaving burrs and the bit never went deep enough to dig into the glass fiber / epoxy, which dulls the bit. Another reason why you don't want to dig past the copper layer is because the bits for this kind of work are V shaped and would make the traces thinner the deeper they went. Also, when you dig in it just looks ugly. Anyways, I thought all my problems were solved... but it turns out I just got lucky. I have now identified a lot more problems.

First, let me explain my experiment setup. In order to waste as little material as possible I wanted to try something a lot smaller than I have tried in the past. I settled on an opto end-stop that I use on my mill and printer (thanks Zack). I can now say that choosing this board was brave. The traces are 16mil (0.4064mm) and the pads are 10mil (0.254mm) from each hole's edge to the edge of the pad. Still, this board should be obtainable and prove I will have no issues with SMT moving forward.

I attempted this board five times, using different settings. Six problems consistently surfaced, of which I will describe below.

1) PCB Thickness Tolerance


I am still experiencing depth issues! I was under the impression that blank PCBs had a consistent thickness. I was wrong. The board I am working with varies in thickness from 1.49mm to 1.52mm randomly. This is enough to make the bit dig in, in some areas.


Poul-Henning Kamp, a FreeBSD developer who dabbles in milling PCBs has considered this problem and has a solution. His solution entails grounding the board, turning off the spindle, and probing the board with the milling bit in a 4mm X 4mm grid. He then parses new Z values into the GCode based on this hight information. His unique solution cannot be directly used by me, but the concept could be applied.

I estimate it would take me 20 hours to write and test software / firmware to automate this task.

2) Bad Motor Coupling


Refer to the following image.

What you are looking at is a diagonal trace, enhanced and sharpened. As you can see, every 1.41mm the Y axis seems to slow and then speed up, resulting in a wave type effect. Inconsistencies like this can be really bad if they are in certain places of the design. They could result in an incomplete circuit, or a circuit that will fail. The cause is a bad motor coupling that is causing the motor to wobble, storing up energy and then releasing it once per revolution. The motor also looks a little off axis, or it could be that the drive-shaft is slightly bent.


I need to redesign the part and print a new one. I also need to make sure the motor is being held in the right position and that the shaft is straight.

It may take me a few prints to get the coupling right, so I will estimate it taking me 3 hours not counting printing time.

3) Not Round


These pads are suppose to be perfectly round and they're not. I double-checked the gcode through NCPlot and the code looks fine.

Solution: ??

I'm not sure on this one. Either this will be fixed when I fix the Y axis or there is something else at play.

4) Incomplete / Grounded Pad


Two of the pads have a little bridge connecting them to the rest of the copper. Again, I checked the gcode and this should not have happened. What's odd is it's the same two pads on all five goes. If this was the aforementioned Y axis issue then I should have seen some randomness.

Solution: ??

Again, not sure. I think it may have to do with play from starting and stopping quickly in a small area. I am planning on running a few tests to eliminate possibilities.

5) Drifting Hole


When drilling after milling I'm finding that the holes work their way to a milled groove.


Pcb-gcode has a feature to tap the holes with the milling bit after milling. I think that will eliminate this issue.

6) Inconsistent Traces


As you can see, the trace on the left is thinner than the trace on the right. This should not be because they are both 16mil traces. Again, I double-checked the gcode.

Solution: ??

I'm crossing my fingers that this is the Y axis again. I will just have to see.

So... it looks like it will take me +25 hours to solve these problems. I mention this because I want to make it clear that if you are planning on milling PCBs then plan on spending a lot of time getting it to work. Granted, some of these problems would not be faced if I had just bought a mill, but there are still a lot of things to get right.

Friday, February 26, 2010

Spiderwheels: Golden Ratio...

Lately, in the back of my mind, I have felt that there was something visually wrong with my spider. Finally, the reason for wrongness clicked. I didn't incorporate the golden ratio. I've heard about this ratio from several sources lately. The most in depth source I remember was from NOVA: Secrets of the Parthenon. You may be able to still catch it on hulu. Wikipedia also has a pretty good overview of the golden ratio. My understanding is that this ratio has been known for a really long time and can be thought of as the mathematical equivalent for beauty and is around 1 / 1.6. Here is the golden ratio found in the Vitruvian Man:

As you can see, from navel to foot is 1.6 times the distance from navel to head. There are an enormous amount of other examples found in nature and architecture, but I will leave that for Wikipedia. I decided to apply this ratio to my spider in two ways. First, I decided to make the tibia 1.6 times the length of the femur, as shown.

Second, I decided to make the circuit board 1.6 times longer than it is wide. To tie it together I made the width of the board the same length as the tibia. Here are some renders of before and afters. I am in the process of printing the new parts.

For me, incorporating the golden ratio into the design makes it pop. I am interested in how others feel, as well as in whether the golden ratio has influenced robotics design before.

Sunday, February 21, 2010

Spiderwheels: first steps...

I am a perfectionist, which is not always a good thing. I have had the hardware needed to make my long anticipated spider for months. However, I was focused on doing it right the first time. I was focused on designing a pcb and making it on my mill. I finished designing the board weeks ago, but my mill is still not ready.

I decided a simpler proof of concept was well overdue. This weekend I buckled down and drank a lot of Red Bull. I finished printing the parts I needed for the legs, I cut and stripped the wires, and I hooked my sanguino up to a breadboard.

Connecting all 18 servos alone took hours.

Snapping the legs together took longer than expected, too.

But the finished product, though only a proof of concept, gave me chills. I have been awaiting it's completion for many months.

Extending the firmware to support all six legs, as well as writing the walk sequence took several hours. Every time I dig this deep into c++ I end up having to re-conceptualize pointers. The sequence could still use some tweaking, and some of the parts could be more exact, but it moves!!

I am still excited to see the more robust solution I envisioned, but I am still months away from that. In the mean time, since I have STL files from the printed parts, it wasn't much trouble to render an animation of what it should look like after the prototype phase.

Sunday, February 14, 2010

Spiderwheels: the third dimension and circles...

If you've been following this blog you'll know that I did most of the math needed for spider movement several months ago. However, to keep it simple I left out a dimension. Where once I only considered D and H I now need to consider x, y, and z.

This weekend I pulled the equations back out in order to add the third dimension. Thankfully the previous equations could remain unchanged with the realization that:

D = sqrt(x2 + y2).
H = z.

Thus, I could still use these equations:

a1 = 180� - tan-1(D / H) - cos-1( (L12 - L22 + D2 + H2) / (2 * L1 * sqrt(D2 + H2)) ).

a2 = cos-1( (L12 + L22 - D2 - H2) / (2 * L1 * L2) ).

The third and final piece of this puzzle is an equation for the angle a5. Simple trigonometry gives us:

a5 = tan-1(x / y).

I've also been working on building out custom servo / leg libraries for my arduino. In order to prove that the equations for a1, a2, a5 work together fluidly and that my libraries are coming along I ran this expression:

void loop(){ 
  // circle
  for(float i = 0; i<360; i = i +0.9){
    goTo((70+(24*cos((i/180)*PI))), (0+(24*sin((i/180)*PI))), 30);
void goTo(float x, float y, float z){
  int i;
  for(i=leg1.findNeededPulses(x, y, z); i>0; i--){
    leg1.pulseToPosition(x, y, z, i);

It simply draws a circle of radius 24mm at a height of 30mm. Here is a video of it in action: