At last report we had the main board in the mill working properly, allowing XY motion, head lift/lower, and chuck open/close. Getting the mill to this stage required replacing a shorted capacitor in the 5-volt power supply.

However, the so-called HF board which controls the spindle drive and tool crib is still non-responsive. It was not clear originally if this board was defective or whether a problem in the main board was impeding communications between the boards.

In August, Chris Ware from LPKF came to have a look, and determined that the problem was in the HF board, and later provided a price quote in the order of $650 for a board (with trade-in), shipping and taxes extra. Not having that kind of pocket change we persevered in diagnosing the problem.

One week we convinced ourselves that the communications were fine (both ends of the board-to-board connection use RS232 driver chips, which are pretty resilient).

Another week we determined that the “overload” light on the HF board was due to a power-up transient not being reset by the firmware, which in turn implied something else was getting the firmware upset.

Another week we determined that the processor was not even running (or, at least, not doing any program ROM accesses).

Another week we determined that the processor RESET line was being held low; it should normally hold low for 10-20ms on power up, then go high allowing the processor to run.

The next week a closer examination revealed that the RESET pin was not making contact in the IC socket anyway. Somehow the pin in the socket had been pushed back and was not springing out to contact the terminal on the IC. However, inserting a small wire to make full contact made no difference.

The RESET pin is driven by a very simple circuit: It is grounded through a capacitor, so on power-up the pin starts off at ground. The processor chip has an internal pull-up current source on the pin which charges the capacitor towards +5V. Once the capacitor is charged enough, the Schmidt-trigger input tied to the pin senses the end of the Reset state and starts the processor running. At least, that’s how it is supposed to work. In our case, the pin was being held stubbornly at about 35mV (when a wire was used to make the socket pin contact the IC pin). Using an external resistor to +5V to try to pull it up only raised the voltage by a few mV, which implied that there was (somewhere) about 20Ω to ground on the pin. On the other hand the external capacitor checked out fine.

This week, given that the socket was clearly defective and the processor condition was unknown, we pulled the processor from its socket and removed the socket from the board. The board (a fibreglass one) suffered some delamination in the process but all the vias are still fine. Cleaning up the solder holes in the board was a bit comical: we had Tennessee with the soldering iron, Richard holding the board, and me holding a vacuum cleaner nozzle to the back of the board, to suck all the holes clear of solder to allow a new socket to be inserted. It worked like a charm (and the vacuum nozzle was grounded metal so no worries about static discharge damaging the board).

Richard is holding the edge of the board (and the camera), I’ve got the vacuum cleaner hose under the board, and Tennessee is holding the corner of the board and wielding the soldering iron. It looks really awkward but was very effective at clearing out the solder from the holes in the PCB.

For next week I will have a new socket so we can see if this magically fixes the problem; if not we will have to try replacing the processor. Fortunately they are still available as NOS from Hong Kong, and they contain no ROM so we don’t have to worry about programming them.

My goal in this is to learn about motor drivers, distance sensors, and have a platform that I can use for experimentation.

To that end, I preformed a frontal lobotomy on a remote control hummer. The car was originally around $20, so even if it went up in flames I wouldn’t be out that much (initialy).

The first step was to take the outer body off. Then snip snip the brains are out. The mechanics of the car seem to be really well designed, the electronics not so much.
Next is upgrading the battery to a lithium-ion battery instead of the double A’s. I’ve done this with other projects. I use the VPX’s which are a 7 volt battery used in home power tools. They are no longer in production, so I snarfed up the last available from Home Depot. They are great because I’ve got a charger made for them, they are relativily small, and they don’t put out enough voltage to make me want to wear rubber gloves.

The next step was put in a motor controller, as well as an arduino. Both were bought from solarbotics. The motor contoller (a fun little project in itself) is mounted above the battery, and the arduino above that. The motor controller has LEDs that show the direction of the motor and when the motor is turning, and the motor controller can control two motors, so 4 lights in total. These got attached to the outer body.

The next thing added is a distance sensor. This is the first sensor added and where the software starts. My first project with my new platform was to make it stay a certain distance from whatever is in front of it. Through experimentation, I’ve found that I need to have a delay in the loop, otherwise the poor thing just sits there nervously shaking, decisions happening faster then it can react. I then tried from memory adding PID code, which gave it a rather agressive stance. It would run at an object, slow down, then back away from the object, over and over. I believe that I’m getting closer. wikipedia has some psudocode for PID controller

previous_error = setpoint - process_feedback
integral = 0
start:
  wait(dt)
  error = setpoint - process_feedback
  integral = integral + (error*dt)
  derivative = (error - previous_error)/dt
  output = (Kp*error) + (Ki*integral) + (Kd*derivative)
  previous_error = error
  goto start

That i’m going to try soon.

One problem that I noticed was that the usb connected to the Arduino was affecting the readings, so I could get things nicely tuned on a stand with the Arduino attached, but as soon as I disconnected the PC and ran strictly off battery power, the settings changed.

To that end I’ve added a bluetooth addapter. I’m excited about this, because I realized that I can do some major cpu programming on my laptop and the little Arduino only has to handle the I/O. I’d like the whole thing to be autonomous, but for now this is good. Maybe my next one will lug around a laptop.

The blue tooth adapter works fine on the Arduino, but getting the laptop to talk to it ended up being rather difficult. Finally got a device to work at /dev/rfcomm0 and if I cat’d that device I’d get all the data that the Arduino was spewing out. (Distance measurments and so on).

A trick I discovered the hard way is programming the Arduino can’t be done while the Bluetooth is online. Another switch to come for easy Bluetooth disconnect.

At this point, the RC Car has:

I’ll do more updates as I progress.

I found an Ikea Molger frame in the As-Is section (my favourite haunt!), and thought it would make a good base for a table.  So, I procured two planks of wood (walnut I think?) from the annual Woodworking Show at Bingeman’s.  I think glued them together, added dowelled wooden gussets underneath to ensure a strong bond, then planed down the top until it was smooth.  Planing was the most repetitive step, and it was fortunate that the ‘Lab had enough space to hold the tabletop until it was completely levelled.  I connected the tabletop to the frame with dowels running through the four posts, then varnished the top.

After all was said and done, it was still rather wobbly.  To strengthen it up, I got eight shiny turnbuckles, and attached them domed screws and nuts to both sides of every post.  The great thing with turnbuckles is that you can control the tension that they have on the legs by just turning them, so I tightened them until I had a much more rigid frame.

I’m not sure quite what to do with the table yet, but it’s doing a great job holding mail in our front room right now…

Based on pictures of the 50′s era Police Box, but lots of liberties taken to make it easy to laser cut. First version was 1/8 scale to make it easier to figure out the cuts.

Laser cut from 3mm hardboard and assembled with a bit of glue, but mostly it press-fits together.

The plan is to teach two fundamental and essential skills that are sadly neglected in our education system.

1. Pumpkin carving
2. Soldering

Did you know that many children reach adulthood today without ever having learned how to carve a pumpkin? We’ll provide a safe, supervised environment in which children 8 and over can learn this crucial skill, under the guidance of expert pumpkin carver and friend of the Lab, Jeff Schmidt.

Rather than simply outfitting the carved pumpkin with an old fashioned, dangerous and–dare I say–obsolete candle, Hacky Hallowe’en’s participants will then move onto building an electronic device that will flicker with beautiful LED light.

Soldering, of course, is foundational to Kwartzlab’s DNA. We’ve held several Learn to Solder workshops in the past and have been itching to do it again. This way, we can take out skills out to the community and instruct many more people than we can accommodate in the Lab.

James Bastow, circuit maestro, has designed the simple yet powerful device that anyone can learn to assemble. He’ll be building the circuit board that we’ll be using for Hacky Hallowe’en. The prototype above is something he whipped together in an afternoon to show what can be done. The kit that we’ll offer will have four orange LEDs, rather than a paltry pair of red ones.

We live in a world of electronics. Learning a simple skill like soldering and seeing a bunch of parts turn into a working device is the first step to realizing that all those gadgets that everyone uses every day are made. They’re made by ordinary people. You can make them too. It gives you the courage to take things apart and see if you can put them back together again, or re-purpose them after they stop being useful. It opens up a door to understand the world around you a little bit better.

What’s more, each of the Hacky Hallowe’en LED flicker devices is powered by a similar microcontroller as the Arduino. They can be programmed. After Hallowe’en is over, participants can bring their board into Kwartzlab and we will teach them how they can make the lights flicker in different ways, or add motors and make them work, or LED arrays that can display messages, or switches or sensors.

Once you know how the basics of these electronic devices work, you can start to build robots or home security systems or cat food dispensers or anything else you want! It all starts with a few blinking lights.

Below are the slides we didn’t get to show to the KW Awesome Foundation trustees, here for posterity. Many thanks to Eric Gerlach for putting the presentation together and making an awesome pitch.

* For the record, I wanted to call it “Carve-Free Sunday”, but that idea was quickly shot down for what are perhaps obvious reasons.

The next step was to export the solidworks object as a sterolithography file (STL). The STL file was imported into MeshCam, choosing the 4-axis option with 8 index positions. MeshCAM lets you create toolpaths from your 3D files quickly and easily. Meshcam generated G-code that would instruct the CNC machine to cut the entire object by indexing the rotary axis and using the regular X,Y and Z axis’ to position the endmill attached to the spindle. For my next experiment I’m going to try increasing the number of index positions by a much larger number.

Three Dimensional projectile created in Solidworks. Its size is .50 caliber and 1.5 inches in length.

In this MeshCam screenshot, the yellow lines indicate the 8 rotary axis positions between which the material is removed to create the object.

For my next rotary axis experiment I will try to optimize the cutting path by selecting a much larger number of indexes and cutting an object in aluminum.

Karl P. Williams

Those who’ve been following the evolution of this library, will probably be familiar with the SwitchInput class. It was intended (among other things) to provide functions that would only be called when a physical switch was closed or opened. The EventHandler class is similar, except that the conditions upon which the event is triggered are configurable and the function isn’t limited to running a single loop when the event occurs. I actually considered re-writing the SwitchInput class to be more like this, but given that it might break programs that people had written with it, I opted not to. Perhaps I’ll create a replacement in the future. Like SwitchInput, EventHandler is drived from the Thread class, with the loop() function overwritten. In its place are two protected virtual functions: condition() and on_event().

The condition() Function:

This is the function that is used to determine when the event is to be triggered. Basically, while the EventHandler object is idle, this function will be called every time the object is invoked by a ThreadList object. If it returns true, the event will be triggered, but if it returns false, the handler will remain in an idle state (this is one of those cases where I wish C++ supported lambdas (but that may be the LISP programming I’ve been doing talking (it’s hard to tell, really))).

The on_event() Function:

Once the event has been triggered, instead of calling the condition() function, the on_event() function will be called in its place. This can be thought of as a conditional loop() function. The difference being that when it returns false the handler will return to an idle state and wait for the condition() function to return true again rather than destroying itself.

A Note about kill_flag:

With a regular Thread object, the loop() function is expected to watch the kill_flag value. When it is set to true, the loop() function is is expected to terminate gracefully. As a help, this functionality is already built into the EventHandler::loop() function. If the handler is in an idle state, it will automatically terminate itself on its next call, however it may be advisable to have the on_event() function watch for this value so that it can facilitate a graceful termination (although, this is not strictly required as the handler will be terminated when the function returns false).

While I don’t feel I’ve done anything particularly ground-breaking with this new release, I hope I’ve created an adequate framework for other Arduino developers who don’t want to re-invent the wheel. As usual, I’ve made all the code and documentation available for this version.

Happy Hacking!

Pouring muriatic acid into the etchant (add the peroxide first)

The design printed onto magazine paper (for toner transfer)

Loaded into the heat press

Using the press to transfer the toner onto the board

Cooling the board down before removing the paper

Paper carefully removed from the board to keep the toner intact

The other side

Freshly made etchant starts to turn green as it absorbs copper from the board

Starting to etch the copper off the board

The front of the (almost) finished board

The reverse side of the (almost) finished board

As can be seen from the last picture, I left the board in the etchant a little too long (it was more active than I expected). Apparently, after a few uses it becomes a little slower acting, although I’ve considered using this effect to somehow watermark my boards.

The first decision that had to be made was what PCB layout software to use. Eagle seems to be a rather popular package for PCB layout (for both hobbyists and professionals) and I’ve used it at work, but it’s proprietary. As a free software developer, I’d much rather use a free (as in speech) tool if at all possible, so I set out to find one. Enter gEDA. gEDA is a GPL-licensed suite of PCB design tools.

One of the things that I’ve heard people complaining about when designing Arduino shields is the non-standard pin spacing. I didn’t really get what they were complaining about until I set out to make one of my own. There are four headers (two with six pins and two with eight) on the board, and for the most part they’re pretty standard: 100mil spacing between pins on each header and a 200mil spacing between pins on the gap between the bottom two connectors, but a 160mil gap between the two headers on the top. In the PCB editor, you could just use a 100mil grid if it weren’t for that one header. It really was a bit of a headache to get the pads in the right places.

Not wanting to have to do the work of getting the pins set up properly twice, I decided to make a custom symbol and footprint for an Arduino Uno board. That way, on future Arduino shields, I could simply drop a block representing the Arduino into the schematic and it would automatically place all the pins on the PCB where they’ll fit the board. If I drag one header around, the othes will follow to maintain proper spacing. Quite handy.

Being a suite of programs rather than a single monolithic program, creating PCBs with gEDA is a little more involved than it is with Eagle, but it’s still pretty straight-forward. You start by creating one or more schematics (one per page) with gschem. The schematic files are in a well-documented plain-text format, so you could make them with a simple text editor, but that’s way too hardcore for even me. With gschem, it’s all drag and drop.

The next step is to use the gsch2pcb program to convert your schematics into a pcb file and a netlist (it also creates a .cmd file, but I don’t know what that’s for). From there, you open the pcb file with their pcb layout editor (creatively named pcb) place the components, import the netlist, and then you can use the auto-routing feature to draw all the traces on the board. I had to play with trace and via sizing so that I could get all the traces to fit into two layers. Don showed me a way to manufacture PCBs, but it only works for two-layer boards.

Unfortunately, there are now a number of vias on the board that have a hole size of 20mil… that’s going to require a steady hand to drill. Perhaps in a later version, I’ll use SMT components to free up some space on the board so I can use larger vias.

That’s about it for my progress so far. I’ll be sure to blog some more as I actually attempt to manufacture these boards. They’re going to be a little more complex than I’d like for a first attempt at using this manufacturing process, but I’m always up for a challenge.

Happy Hacking.

EDIT 5 Mar 2011:
I almost forgot to post links to the actual project.

• Here’s my list of custom symbols.
• Here’s my list of custom footprints.
• And last but not least, here’s the actual shield.

Also, there’s a more descriptive tutorial on how to use gEDA on their website.