Playing with servo motors

I bought some cheap mini servos from DealExtreme to play with.  They're less than $4 each (in quantities of 3 or more.)

I designed a few little plastic parts to hold the servos together into a structure that can do something.  The assembly is meant to resemble a single leg from a hexapod robot, but the current design is much too weak to support any weight.  It works fine for playing with motor control software, though.

I designed the motor mounts by playing with SketchUp for a few hours.  The first thing I did was grab a pair of calipers and model one of the mini servos.  Then I just pushed the motor models around in SketchUp, and draw parts to connect them.  This is what I came up with:

I exported these parts to STL and printed them out using my MakerBot Cupcake 3D printer:

I'm still working on tweaking the printer.  After a bit of cleanup with a knife and a file, the parts work fine:

 

I like this 3D printer.  It's so easy to go from a rough idea to an actual part!

I did have a lot of trouble getting from SketchUp to an STL file.  In fact, the parts I printed out are actually mirrored compared to the design.  They work fine that way, though.  I've since discovered that getting an STL out of SketchUp is easy if you know the trick to making the STL export plugin work: the part to export has to be exploded for the plugin to find it.

The next step was to try control the arm (or leg, whatever it is.)  I hooked the servos up to an Arduino, which has an extremely easy to use servo library.  It took no time at all to get the servos responding to a simple test program.

I did have a occasional problem with the stepper motors, where all the motors would just start spasming.  It looked like the arm was having a seizure.  This turned out to be caused by my powering the 3 mini servos from a 1.5A regulated power supply, which was apparently insufficient.  I hooked the servos up to 4 AA batteries instead, and the problem went away.

After demonstrating that servo control with Arduino was a trivial task, I wanted to control the servos from a computer program.  To do this, I threw together a quick and dirty program in C#.

A side note here: I use Linux more often than Windows, and I like programming in Python.  However, I've found that when I just want to get something with a GUI working quickly, Visual Studio and C# are hard to beat.

I modified the Arduino program to watch the serial port for commands which set the position of each servo motor, and threw 3 sliders onto a form as the UI.  This worked as expected, and made it easy to set the angle of each servo.  However, even with only 3 degrees of freedom, it's rather difficult to position a robotic arm by specifying the angle of each joint.

So, next part: inverse kinematics.  Inverse kinematics is something I've found interesting for a while, but never tried to do anything with.  Luckily, it turns out that the inverse kinematics equations for this particular configuration are relatively simple.  It still took me quite a few hours to get everything working, though.  This is the page I used as a reference: http://www.learnaboutrobots.com/inverseKinematics.htm

I ended up with a picture box which can be clicked on to set the XY position of the end of the arm, while the mouse wheel sets the Z position.  It works well, and it's really neat to see all 3 motors moving in tandem to get to the designated position.  I also used forward kinematics equations to draw the current estimated configuration of the robotic arm in the background of the picture box.  Even without the physical thing hooked up, it's interesting to see the drawn arm and all the sliders move around as the picture box is clicked.

Here's a video showing the inverse kinematics in action:

This is the first time I've tried uploading an HD video.  I was going to use Vimeo, but it's not accepting uploads as I write this.  I guess I get to try YouTube.

This whole project took maybe 3 days.  About 1 day of messing around with SketchUp and printing parts, 1 day to get the Arduino code and basic sliders working, and 1 final day to get all the inverse kinematics stuff working. 

3D printer: now working better

I've been getting a little frustrated with the 3D printer.  The past couple days, it has continually been failing to get through a printed object.  It starts out well, but after a few layers the extruder starts slipping on the filament.  It digs a nice little notch in the side of the filament instead of extruding it.

I tried extruding hotter and colder, tried with the idler wheel tighter and with it looser.  I even tried taking the insulation off of the heater barrel in case the filament was melting too far up into the barrel.  Some changes made it work worse, but none made it work better.  I've been seeing a lot of this:

These are supposed to be dodecahedrons.

I did finally figure out the problem late tonight.  I completely disassembled the extruder barrel assembly.  It turns out that the PTFE thermal barrier was too tight towards the bottom, and greatly restricting movement of the filament.  I cleaned it out using a 1/8" drill bit (held by hand, not in a drill) until the filament could move through it with no resistance.  I had to remove some more material from the inside of the thermal barrier after screwing it back in to the heater barrel.  Now it works quite a bit better:

See that in the back?  It's a complete dodecahedron!  Here's a closeup:

The one on the right is sitting on top of a green laser pointer.  It glows nicely.

It was exciting to see this part completed.  I was surprised at how well bridging the top material over the hollow inside of the shape worked.

I just realized that I don't have any pictures of the completed 3D printer up here yet, so here are a couple.  The wire routing still needs some work!

More printed objects

I tried printing a couple more objects today.

I managed to get a complete MakerBot coin printed.  It looks pretty good.  After that, I tried to print a dodecahedron.  Unfortunately, the machine stopped extruding part way through the print each time I tried.

I think the extruder motor keeps going, but the pulley digs a notch into the filament instead of moving it.  I might try tightening the idler wheel a bit, but I'm wary of breaking it.  Maybe I should check that the extruder is still hot when it stops extruding; if for some reason it's cooling off, that would certainly make the filament too hard to extrude.

Here's the completed MakerBot coin, and a partial dodecahedron:

 

3D printer first partial print

Again I didn't have a lot lot of time to work on the 3D printer today.  I did get a little bit done though, including the first partial print!

I hooked everything up and tried extruding some plastic.  The first time, the plastic filament got hung up somewhere before reaching the nozzle, and the pinch wheel dug an indentation into the side.  After that, I started sharpening the end of the filament before feeding it in, and that seems to work better.  The extruder barrel seems to be slightly crooked in the PTFE thermal barrier (maybe the drilled and tapped portion wasn't drilled quite straight?), and I'm wondering if the un-sharpened filament was hanging up at the top of the metal barrel.

The first few attempts to print something resulted in a mess of spaghetti rather than a coherent part.  After messing with Skeinforge settings for a while, I managed to get a MakerBot Coin partially printed out:

This came loose and got pushed around the build platform before the last couple layers were done.  Still, it's exciting to see the first solid object out of this thing I put together!

These are the Skeinforge adjustments I made to get this far:

• Thicker raft
• Hotter printing temperatures
• Slower printing speed (to get thicker strands)
• Thinner layers (to make layers stick together better)
  

3rd day of 3D printer assembly

Unfortunately, I was only able to spend about 1 hour working on the 3D printer today, so I don't have much more done.

I got the extruder barrel assembled.  I should be ready to attach the barrel to the extruder, the extruder to the printer, then try printing something!

I spent some time trying to diagnose the non-functional optical end stop.  I had already tried a different cable and a different stepper controller yesterday.  Today I visually inspected the board, re-soldered all the joints, and verified that the LED is working and in the right way.  I then powered up the both the bad end stop and a good one to compare voltages.  I measured every joint on the board, and everything appears identical between the good and bad end stops.  The only difference is that if I block the sensor on the good end stop, the LED turns on and the signal line goes low.  On the bad end stop, nothing at all happens when I block the sensor.  I'm thinking that the sensor must be bad.

I sent a message to MakerBot.  I hope they'll send me a replacement.

In the mean time, this will not stop me from getting the printer up and running.  I understand that it's possible to run the bot with no end stops at all, or to run with just 3 (for homing.)

2nd day of 3D printer assembly

I spent another 10 or 11 hours working on assembling the CupCake CNC Kit today.  I've made some progress, but it's not done yet.

The external case assembled:

All 3 axes installed:

Electronics and end stops installed:

Extruder partly assembled:

Even though I don't have the extruder done yet, I tried running the 3 axes once I got the electronics installed.  It actually moves!  I did discover that 1 of the 6 end stops does not work.  I haven't figured out why yet.  The X and Y axes are louder than I expected; I'm not sure if I'd want this sitting on my desk printing away while I was trying to work on something else.

I continue to be impressed with the design of this kit, with the exception of the end stop triggers.  The end stop triggers are popsicle sticks hot glued in place.  The slots which hold the sticks and the optical end stops don't even all line up well, so the popsicle sticks end up angled or offset.  It looks quite messy, especially compared to the quality of the rest of the machine.

There have been a couple times while assembling this that I get something put together,  only to take it apart again a few minutes later when I realize that it could be aligned better.  This isn't really a fault of the instructions; it's more that I don't realize the entire function of each part until I see it all together.

Hopefully tomorrow I'll get the extruder finished.  Maybe I'll take a look at the non-functional end stop as well, and see if I can figure out what's wrong.

Starting assembly of a 3D printer

A CupCake CNC Kit that I recently ordered from MakerBot Industries arrived today.

I spent about 6 or 7 hours working today working on assembling it.  This is what I've accomplished so far.

Assembled the optical end stops:

Painted the large pieces that make up the exterior case (white on the inside, blue on the outside):

 Assembled the X and Y stages:

 

 

It's really neat how this is designed.  It's all laser cut plywood, held together with slots and tabs, and bolts with captive nuts.  I never knew you could do so much with plywood.

The assembly has gone pretty smoothly so far.  The instructions are very comprehensive.  I've only had a few tiny snags:

• I dented the side of a bearing trying to get it to fit into the printed pulley.  I was afraid that I'd have to order a replacement bearing and wait for it to arrive.  Luckily the bearing still turns smoothly despite the dented side.  I ended up pressing it into the pulley using a vice.
• The Y stage looks a bit different than the one in the instructions.  Not enough to cause any problems, though.
• I don't seem to have any of the M3 washers that are needed in a couple places.  I had some small washers on hand that work OK.
• It wasn't very clear to me how to attach the pulley to the X stage.  To start with, the instructions call for a M6 22mm bolt.  If my calipers are to be trusted, the closest bolt included is more like M5 25mm.  It also wasn't clear to me which way the plastic pulley goes on (directions show a wooden one), or how many nuts and washers go under the pulley.  By experimenting, I managed to find a combination that seems to hold the pulley at the correct height for the belt.  I also had to move the drive pulley on the stepper motor out further on the shaft than the instructions said.

I'd say that so far, this is extremely easy to put together.   The little things above are just enough to keep it interesting without getting frustrating.  I'm probably less than a third of the way done with the assembly though, so I'll have to see how the rest of it goes.

Arduino Oscilloscope

I have some testing I'd like to do that would benefit from an oscilliscope.  Unfortunately, I don't have an oscilloscope, and there's no room in the budget to buy one at the moment.  So I thought I'd see what kind of oscilloscope I can make out of an Arduino microprocessor.

I know an Arduino oscilloscope has been done any number of times before.  This is just my version of the concept.

I originally thought I'd have to do some moderately complex programming to make the Arduino act as an oscilloscope.  I figured I'd have to buffer readings, and have a communication protocol to transfer the data, set up trigger conditions, etc.  Luckily, I decided to run some tests before I started the serious coding.

A quick test app reveals that the analogRead() function 112 or 116 microseconds to execute (the micros() function has a resolution of 4us, so the actual time is somewhere between those two values.)  Serial.write() of a single byte takes only 8 microseconds.

The slow analog conversion time and the fast time to send a single byte gave me an idea: instead of having a complicated Arduino program to act as an oscilloscope, I could use an extremely simple program that just constantly streams measurements from an analog input pin.  For my purpose, I doubt I need the full 10 bits of A2D resolution; 8 bits should be enough.  This means that I don't even have to worry about synchronizing with the data stream from the microcontroller, since every byte is an valid independent reading.  A sample rate of 5000 Hz (200 us between samples) would only be 40kbps, which should be easily handled by a 115200 baud rate.

Unfortunately, further testing revealed that a 5000 Hz sample rate caused the serial data to arrive in large chunks about once a second.  I guess that some part of the serial line was being overwhelmed.  I don't know if it was in the microcontroller, the PC, or in the FTDI USB to serial chip.  Wherever the problem lies, a sample rate of 4000 Hz (250 us between samples) seems to cure the problem.

The resulting Arduino application is so simple that I'm going to post the whole thing here:

void setup()
{
  // need fast serial rate to keep up with 1 byte data every 250 us
  Serial.begin(115200);
}
 
void loop()
{
  static uint16_t analogVal;
  static uint32_t nextReadTime;
  static uint32_t nowTime;
  
  // start by calculating time that next read will take place
  nextReadTime = micros() + 250;
  
  // read analog value
  analogVal = analogRead(0);  

  // send analog value (as single byte)
  Serial.print((uint8_t)(analogVal >> 2), BYTE);
  
  // wait for right amount of time to do next read
  nowTime = micros();
  if(nowTime < nextReadTime)
    delayMicroseconds(nextReadTime - nowTime);
}

Pretty simple, isn't it?

Of course, now all the oscilloscope logic has to go in a program on the PC side.

I started trying to write an application in Python, pySerial, and pygame.  It was going a little slowly though, so I ended up throwing togeather a quick program in C# instead.  Here's what it looks like after a few hours of messing around:

In the first two pictures, the signal is just whatever is picked up with the analog input pin of the Arduino disconnected.  It makes a nice sine wave for testing the display application.

The third picture is the output of a pin set to output PWM with a 25% duty cycle.  The 4000 Hz sample rate of the scope is just barely enough to see the 500 Hz PWM waveform: each cycle gets 4 samples.

I don't know if this will actually be useful for anything, but it was fun to do.  I got to play with microcontrollers and computer graphics at the same time!

Evaluating LEDs for the low voltage warning device

The most recent design idea for the low voltage warning device will require a dual color indicator LED.  One of the colors should be green to indicate the "OK" state, and the other should be orange, yellow, or maybe red for the error condition.

The LED will have to be a 5mm T1 3/4 size to fit in a panel mount LED holder.

I went to Digikey and looked through the available LEDs.  I found 5 differerent ones that may work, and ordered a couple of each:

(I apologize for using a screen shot of a spreadsheet here, but I don't feel like messing around with table formatting right now.)

After receiving the Digikey order, I put the LEDs on a breadboard side by side to compare them.  There are two of each LED, one green and one other color.  Here is what they look like:

LEDs from the front in dim light.

LEDs from the side in dim light.

LEDs in bright light (shaded daylight.)

LEDs in direct sunlight.

My observations about the LEDs:

• Amber, orange, or yellow are all too close to green.  The indicator LED will have to be a red/green LED.
• The diffuse LEDs look better than the clear one (though the clear one here is also much dimmer than the others.)
• LED #3 is the best of this bunch.  It's also the brightest one.
• The LEDs are very hard to see in direct sunlight.  LED #3 in red mode is visible, but you have to be looking for it to notice it.

If I want the indicator LED to be visible in direct sunlight, I'm probably going to need a brighter LED.  I didn't want too bright a LED because it should not be blinding if used in the dark, but maybe that's not much of a concern since the LVW device is now slated to have a dimming function.

There is one LED from Digikey that looks like a good candidate; I wish I had included one in the order.  Digikey P/N 754-1235-ND has specifications similar to the #3 LED, except that the red component is twice as bright.  It's also a bit cheaper. 

Low Voltage Warning UI Prototype

In my last entry about the low voltage warning device, I said that the requirements have changed.  Among other things, the device has to have a green LED active when the voltage is OK, and the LEDs have to be dimmable.

Based on the new requirements, I think that a microcontroller is justifiable.  I have no doubt that this could still be done without one, but I like microcontrollers, and that's where my experience lies.  I plan to use one of the small AVR uCs which are under $1 in quantity.

The device will now have to have both a bi-color LED and a single button.  This single button will have to both toggle the state of the LED and allow for dimming.  I think that this calls for a UI prototype to see how well this works.

As a side note, I'd much prefer a lit button, but all that I can find are prohibitively expensive.

This is how the button and LED should interact:

• While in the normal (voltage good) state, pushing the button should toggle the green LED on and off.
• While in the low voltage state, pushing the button should toggle between flashing orange and solid orange.
• In any state, holding the button down for a few seconds should start dimming the LED.  When the button in released, the LED will maintain this brightness.
• If a low voltage state occurs, the LED should always go to the flashing orange mode (as opposed to solid orange) in order to catch the attention of the operator.
  

For a prototype, I glued a couple of switches, an LED, and an Arduino to a piece of cardboard.  Rather crude, but it works.  Here's a video demonstration:


LVW UI Prototype from James Wilkins on Vimeo.


Sorry for the poor video quality.  My camera just died on me today, so I had to resort to a web cam for recording the video.  It was either that or a cell phone, and the cell phone would have been worse.

I think that this will work.  Of course, I'll have to run it past some actual users to see if it proves too confusing.

Low Voltage Warning initial prototypes

I'm still working through the backlog of project information.  It's the second day of posting one update per day, and I think I might have enough stuff to keep this up for two or three weeks.

After creating an intial design and schematic of the low voltage warning device, the next task was to make a prototype.  The very first prototype, made to verify that the circuit actually worked, was on a breadboard.  After that, I decided to make a couple more permanent prototypes to use in testing the concept.

I wanted to use stripboard for the prototypes.  I bought some stripboard a few years ago, but this was the first time that I actually tried using them for anything.

I discovered that creating a layout for stripboard is more complex than I had expected.  I suppose it would be very easy to simply transfer a breadboard layout to the stripboard, but that would not be very space efficient.  I tried a couple of different stripboard layout programs, and ended up using the free version of VeeCAD.  It's far from perfect, but it gets the job done.  I liked the fact that component footprints are very easy to add.

One feature that I'd really like to see is an option to highlight all traces and wires that are electrically connected.  After doing a layout, I ended up saving a picture of the design and using GIMP to trace over it in various colors to verify that all components were connected correctly.  It would be easier to have this done automatically by the stripboard designer application.

This is what the stripboard design looked like (colored version):

Here is the first board that I made:

This board worked fine, and would have been suitable for a permanent installation, but it was not all that convenient to test with.  So I made another prototype, with a few changes.  The third prototype was build into a re-purposed case from a cigarette lighter power supply, and had a built-in flashing LED.  I also added a diode to protect the circuit from reverse polarity, and re-did the stripboard layout to cram it into a smaller space.  Here's the third prototype:

This version was used to do some real-world testing of the concept.  These were the observations:

• The LED needs to flash, to ensure that it will be noticed.
• There should be a green LED lit up when nothing is wrong, to indicate that the device is functioning.
• The LED is too bright at night, so it needs to be able to be dimmed.
• There should be both a 12V version and a 24V version (some airplanes use a 24V power system.)
  

This is suddenly getting a lot more complicated!  Maybe I can now justify using a microcontroller.

Here are some observations of my own about the design:

• When buying the cheapest resistors from Digikey, pay attention to the power rating.  1/2 watt resistors are larger than 1/4 watt resistors.
• I accidentally used a 16V rated filtering capacitor in the power supply.  Since a vehicle power bus can be 15V and spike even higher, and capacitors should not be used near the rated limit, this is far too low.  If I want this to work on a 24V system, I should probably use a 36V or 50V rated capacitor.  Unfortunately, 100 uF 36V or 50V caps are generally considerably taller than the 16V one I had here.  I'll have to be careful that the new capacitor will fit in whatever case is used.
• I need to add a lot of protection circuitry to this design.  A fuse, reverse polarity protection, over voltage protection, etc.

I don't especially enjoy having to take all of these things into consideration.  It's much more fun to just build prototypes and never worry about the robustness of the design!

Low Voltage Warning concept and initial schematic

I have a few projects in progress that I can talk about here.  I'm going to try to make at least one post per day until I've worked through the backlog of information.

One project I've started recently is a simple device to monitor a voltage level and warn when it drops below a certain level.  The specific application this is meant for is to monitor the 12V power in an airplane, and issue a warning if the alternator stops working.  It should work equally well in an automobile.

I've been asked by someone to design this device, with the intention of manufacturing and selling a small quantity.  These would obviously be for experimental aircraft only.  Since my electronics experience is at best "amateur hobbyist" level, whatever design I come up with will be examined by an EE before selling anything.

My little bit of electronics experience is in working with microcontrollers, and mostly on the programming side.  This project seems a bit too simple to justify using a µC, so I went in search of appropriate components to use.

A bit of googling revealed that I probably wanted to use a "voltage comparator."  I also found a number of schematics demonstrating how to use them.  These are the two pages that I found most useful for my purpose:
http://home.cogeco.ca/~rpaisley4/Comparators.html
http://www.solorb.com/elect/solarcirc/lvbeep/index.html

Based on those two schematics, I created my own circuit.  I don't have a copy of the original circuit, but if you just ignore the PTC and diode in this one it's pretty much the same:

Operation of the circuit is very simple.  There's a regulator providing a 5V source to one input of the comparator, and a trim pot acting as a variable voltage divider on the other input.  The trim pot is used to set the voltage at which the warning triggers.  When the voltage through the divider drops to less than the 5V from the regulator, the comparator activates the transistor, which turns on the LED.

Blog Reactivate!

I've been intending for quite a while now to set up a blog to use as a project log.  I had forgotten that I already had one set up here, from 3 years ago when I created the account and made just one post to the RepRap Builders blog.  So after going through a few 'upgrade' steps and messing with layouts a bit, I now have a blog ready to be used again.

I plan to use this space as a project log for all the various things I work on.  I like to create and build a wide variety of things, but I have a bad habit of starting many projects while finishing very few.  I hope that publishing my projects in progress will somehow encourage me to finish more of them.

The RepStrap that I posted about 3 years ago is an excellent example of a project started but never finished.  I had the 3-axis positioning system half done, and the extruder half done, but never got any farther than that.  Actually, that project ended up going backwards: I've moved a couple of times since then, and the MDF framework was demolished to save space.  I'm sort of resuming that project now in a less ambitious way: I recently ordered a MakerBot CupCake CNC Kit.