Makerbot Cupcake CNC

Ok, so yes I have been far to slack to actually keep the blog up to date. But I have still been busy.

The main thing that has been taking up my time has been my Makerbot Cupcake CNC machine. This are a DIY 3D printer that you can by as a kit. They print by extruding hot ABS plastic (or PLA if you want to use a different type) onto a movable platform. The platform moves in the X and Y axis and the extruder nozzle slowly moves up in the Z axis as more of the object is printed.

Below you can see my Makerbot after I have printed out a few tests as seen in the foreground.


I've been working on a few small objects and so far everything looks good, however theres still a lot of room for tweaking. One of the things that proves to have the most effect on improving the quality of prints is to use a heated printing bed, this helps eliminate or significantly reduce warping of prints.

You can see the things I have made (only 1 so far) on my Thingiverse page here.

RC Sensor for Mindstorms NXT

Well its done... mostly.

The previous RC - Lego IR converter naturally progressed into this. Instead of converting to IR, which is then received by a third party NXT sensor, it made more sense to skip the IR completely and have the radio control receiver interface directly with the NXT.

To that end I had to figure out how to interface the Arduino with the NXT. From everything I had read it appeared fairly straightforward, yet there didn't seem to actually much in the way of documentation on how to do it. Typically people would use a PIC chip to do the conversion, but seeing as I (and a lot of other people) are more familiar with the Arduino it seemed a better way to go, not to mention open up a lot more possibilities later.

The NXT communicates with its sensors via I2C, at first glance it appears a fairly complex protocol, but thanks to the Arduino library it becomes a lot simpler. That didn't mean I was out of the woods yet. While HiTechnic supply pretty much all the information you need to communicate with their sensor, I was trying to mimic it. The point was that while a sensor is all well and good, you need some code on the NXT in order to be able to read data from it. HiTechnic had already released a NXT-G block to access their IR Receiver, I wanted my sensor to be able to use their code.

Its useful because once the arduino is able to mimic the original sensor you are no longer limited in what you can sense. The Lego Power Functions has an Infrared remote that has 4 channels, each channel has 2 motors that can be driven either backwards or forwards, with power being applied being varied between 0 and 100% (or between -100% to 100%)

By replacing the HiTechnic sensor with an Arduino, you gain the ability to let the NXT see 8 analog channels on a single sensor (a pity that the standard Arduino only has 4 analog inputs free when using I2C), not to mention logic on each of those channels (Forward and Reverse).
And thats just using the basic HiTechnic NXT-G block. If you were to start using NXC or some other language you remove even more restrictions.

The reverse engineering would likely not have been possible without a Bus Pirate. While I may have eventually been able to get everything working without it, it made things so much easier and removed a lot less guesswork.

So far I have tested this with a Hitec Electron6 and a Arduino Deumilinove, both being powered by the NXT's 4.3V line.
Unfortunately the 3.3V/8MHz arduinos aren't powerful enough to decode the PPM signal without losing sync. The 5V/16MHz versions work fine. That being said, if your sensor did not require the higher processing power, there is no reason why you couldn't use the 8MHz version.

Code: HERE


The main reason its only "mostly" finished is that I am not happy with the case, its much larger than I know I could get it. But that is going to have to wait until I get my Cupcake CNC machine, this will allow me to print my own cases. I also intend to add a jumper or switch to enable/disable channel mixing, but that's something I'll leave till redesigning that case. The Cupcake is a major project all by itself however, so it will be something to get back to much later.

For my next trick I'm going to try to duplicate the HiTechnic Compass sensor. What makes this more difficult is that the compass sensor is already an I2C device, so the Arduino needs to get the compass heading data and make it available where the software expects it to be. Sounds simple, except that part of the I2C topology is while there may be many slave devices there can only be a single master, and to do what I want to do the Arduino has to be both a master and a slave, making it the second master on the bus. After that is a GPS sensor. Man, I've got a queue forming...

And something I cooked up to make things a little easier when working with the NXT and Arduino:

Its an Arduino shield with NXT socket. I recently started etching my own circuit boards again, the RC sensor and this are a couple of the first boards I've made. The DIP switch allows you connect and disconnect the individual pins to the Arduino as you may want. Along with a couple of rows of header sockets to break out the connections to a breadboard and the like. I've already redesigned it somewhat as I already realised it could be better, but that's normal :P

Radio Control to Lego IR converter

When initially building my Lego rover I came across the Lego Power Functions Remote controls. However I quickly discounted them for a number of reasons, foremost being they are InfraRed only, and so useless if you are running out of Line Of Sight.

The speed control remote, while you can control the speed, its awkward to do so. While with the standard remote, you have no speed control, you merely control if a motor is running backwards or forwards, it will always run at full speed. As a result I ended up going with a radio controlled plane transmitter and receiver set.

This has a lot of benefits, but again drawbacks.

When I was looking at a different version of the rover I came across the NXT Packbot.



Being that it uses the NXT Mindstorms it it possible to include automated functions, like the ability to right itself if it gets flipped (this needs an accelerometer). But you still need to be able to control it remotely.
The company that makes an accelerometer sensor for the NXT also make an IR Receiver, that can respond to the Lego IR remote codes. I had already found code for an Arduino to decode the PPM signal, so it it was only a matter of the IR signals, something I had already done something similar for on another project. A little more digging and I found an Arduino library for the Lego IR codes. The rest was pretty easy.


The case contains a Arduino Pro Mini 5V/368, with a small daughter board containing an IR LED and transistor to boost the power of the LED.

Code : HERE (beware the code may be messy and contain un-needed stuff)

Of course before I even finished I realised what the next step was - directly connecting the RC receiver to the NXT. Although this current project works well for controlling the Power Functions remote as-is, it needs the Hi-Technic IR receiver to work with the NXT. The NXT communicates with its more complex sensors using I2C, something the Arduino can do quite happily, so it shouldn't be that hard... right?

Garage Door Sensor

If you are like us then you can't actually see whether or not the garage door have been left open or not from the house. After the door getting left open one too many times for my liking I decided to try to do something about it.


Pretty much all it consists of is two 3.3V arduino mini's connected via a serial link over a pair of xbee radio modems. Much like the standard arduino, you need a special board to plug it into the arduino mini.

The sensor is fully self contained, sensing the door status and switching on power to the transmitter using a mercury tilt switch (I've had this sitting around for AGES, you can see it stuck to the inside of the left case in the picture above) The arduino's used are the 3.3V version, meaning that it can be powered by a pair of AA batteries.

The receiver is the same arduino mini, xbee connector board and xbee as in the sensor. the main difference is that is it hooked up to power permanently. The door status is indicated by a 10mm ultrabright LED. I included a 5V regulator in the case after blowing up the previous mini I was using. The arduinos all have a an on board voltage regulator, but the ones on the mini can only handle 12V maximum input, pity the first plug pack I hooked up to it was 18V ;_;
Result - one dead mini and one new keyring.


The 20C piece should give you some idea of just how small the mini arduinos are.

Yet another majorly over engineered solution to a simple problem. At least this one works.

Pentax IR Camera Remote

I've been meaning to buy/make a IR remote for my camera for a while. Pentax sell one, but it ends up close to +$50 by the time it arrives. So after some research I set about about making my own.

The first thing I was going to have to deal with was physical size. The second thing was power, the last was start up time. This meant that an arduino, no matter what flavour was just not going to work. A PICAXE would probably work, but an AVR microcontroller was the best choice as it fit all three criteria well.

The best place to start for any beginner with AVRs is this tutorial. It covers pretty much everything from the ground up. Which was fine as I had no idea where to start.

My plan was to build something based off this DIY Canon IR remote. Of course my camera was a Pentax so while the circuit was definitely helpful, the IR code itself was completely wrong.

Some digging came up with a couple of leads. The first was that there was a Sony remote code that would work. Lots of them in fact if various forums were accurate, but none of them gave a specific code, just which button on some persons remote. I had the Sony IR protocol on the arduino, but I had no idea which one. and there was literally thousands of possibilities. I hatched a cunning plan!
I could have the arduino send the codes to the camera, but would never know which one was the right one. Except that if it worked, the camera would take a picture. Add a small LCD to display the current code and problem solved!

Well it sounded good in theory. For some reason it didn't work like it should have. Hmm... back to the drawing board.

Some more digging and I found an open source Pentax remote for the Palm and as luck would have it the docs included information on the signal.

Now I was making headway.
Breaking out the arduino again I programed it to send the new code. Still no go. What the hell? Everything said that it should work but nothing. Some more investigation and I found that the IR remote mode has to be manually turned on. Ok. It works now /facepalm.

Which left me wondering if my original plan would have worked after all, if I had set the camera properly. Not that it mattered, the AVR chip awaited!

I used a attiny85 simply because that's what I had on hand. Its massive overkill for this but worked well. The attiny25 or attiny45 would work just as well.

The circuit is as simple as possible, just a battery, a button, a LED and the chip. The code itself I also modified from doc-diy's, simply changing it to match the Pentax. Some fiddling and it was all working.




Below is the code I used: LINK

// IR Remote to mimic Pentax F remote to control Pentax K100D etc cameras
#define F_CPU 7900000 // crystal frequency
#include <inttypes.h>
#include <stdlib.h>
#include <avr/io.h>
#include <avr/sleep.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#define HPERIOD 0.01524
#define RATIO 0.4
#define NPULSES 32
#define HPULSES 411
#define PULSES 7
#define LEDOFF 0b00000001
#define LEDON  0b00010111


int main(void)
{
uint16_t i;
uint8_t p;


DDRB  = 0b00010110; // pin PB0 is input, pins PB1-PB4 are output
PORTB = 0b00000001; // pull-up for input pin PB0
asm volatile ("nop");
asm volatile ("nop");

for (;;)
{
for(i=0;i<HPULSES;i++)
{
  PORTB = LEDON;
  _delay_ms(HPERIOD);
  PORTB = LEDOFF;
  _delay_ms(HPERIOD);
}

_delay_ms(3); // instant

for(p=0;p<PULSES;p++)
{
  for(i=0;i<NPULSES;i++)
  {
      PORTB = LEDON;
      _delay_ms(HPERIOD);
      PORTB = LEDOFF;
      _delay_ms(HPERIOD);
  }
  _delay_ms(1);
}

_delay_ms(12);
}

}

Hardware result



As I said, this was to be as simple as possible and I think I succeeded. The case itself is a Hammond case from Altronics and is only 35 x 50 mm.

So yes the remote was working well, but I still wondered what would have happened with the Sony code scanning. I set the rig back up and started the scanning. Turns out that yes it would have worked if I had set it up properly in the first place. The scan came up with more than 45 codes between 0x000 and 0xfff. The "correct" code would be closest to 0xFE0, which equates to 7 pulses as per the PRCF documentation . The camera is very slack however so lots more work.



There were however a couple of caveats. The IR mode on the camera only stays on for so long. I think it was about 5 mins without a shot before it stops listening. But if you send the right/wrong code it can stop listening a lot earlier. This was important to know as I was planning on later building an interval meter which would allow me to do time lapse photos/movies. If the camera was going to stop listening to the interval meter after just a few minutes it wasn't going to work, I would have to use a cable remote rather than IR remote to trigger the camera.

Radio Controlled Lego Rover

One of the things that came up over winter was that we had an intermittent leak in the roof. In a place we couldn't get to. So I had a brilliant idea (well it seemed like a good idea at the time...)

My plan was to build a remote controlled rover, complete with a colour camera on a pan and tilt mount so I could get it into place and see where the leak was coming from.

For control I was going to use a pair of the Arduino microcontrollers I had, hook up XBee radio links and use them. For actual control I figured I would use a Wii nunchuck. The Arduino can decode the data from the accelerometer in the nunchuck and turn that into commands to control the rover.

Brilliant!

The XBee is intended as a serial data link. so you can send almost any data you want in both directions. But its not really intended for real time control. I got massive lag spikes that brought on flashbacks of "Bloodfeather Belts" (*shudder*)
The original idea also used tank tracks like the ones on this Dozer set.
Unfortunately the tracks are made of plastic with no rubber, so on a hard smooth surface have almost no grip at all. It couldn't even get over a 1 cm high piece of wood.

Not so brilliant.

Ok, This was going to take some more work.

The end result looked like this:

I decided that the best way to handle real time control was to use a system that was designed for just that. I found a (relatively) cheap Tx/Rx pack in the Hitec Optic Sport with Electron6 receiver. The nice thing about the Electron6 is that after a quick mod the Arduino was able to pull the raw data out rather that scan every single servo channel.

So what is in that mess? Well in that lot is an arduino and its prototype shield (left), behind that (unseen) is a Pololu serial servo controller. A wireless camera on a servo pan/tilt mount (top) with the rover's battery underneath that. The blue thing to the right of that is the Electron6. The green thing behind that is the 8V supply for the camera+light (seriously, WHY 8V ?!?!). At the back of the rover (right) you can see the two motor speed controllers with the copper coloured heatsinks. Each of the wheels is driven by its own Lego Power Functions XL motor, these things have a serious amount of torque and have a stall current of 1.8Amps, so I needed to make sure I didn't blow anything up.

Ok now this sucker RAN. But I was sure I could make it less complicated. Some investigation later and I turned up just the thing.

The main reason for the Arduino was to handle the Left / Right mixing. The rover drives like a tank in that it doesn't have any steering other than varying the rates of the left right motors, however I wanted to be able to steer using a single stick on the remote, that way I could you use the other stick to control the camera. So what you do is you take the X/Y coordinates of the joystick and convert them into L/R values. There was already a piece of hardware that robot makers already use to do just this. The Pololu Trex handles this and more. I replaced the arduino, prototype board, serial servo controller and two electronic speed controllers with a single board.

This time it came out something like this:

The green board to the right is the Trex. You can see how much simpler it ended up. The servos for the pan/tilt connect direct to the Electron6

A few days later we had a nice big rain storm, so I climbed up and left the rover in the roof. Down in the lounge room I sat comfortably maneuvering the rover. Only to discover after getting it about a meter in that there was no way I was going to get it to where I wanted. In fact there was almost no way I was going to be able to build a rover to do it. There were 20cm high beams and gaps about half a meter wide to get over.

It might have been a good idea to check these sorts of things to start with.

/facepalm

Beta 22 Balanced Amplifier

The first project I started this year back in February was the well known AMB Beta22 Amplifier. This is a DIY amp that you can built in a variety of different configurations. The Beta22 itself is a single channel amplifier powered by a Sigma22 power supply.

I decided to go the whole hog and go balanced. This requires 4 amplifiers as each channel uses 2 amps each. For more info see here.

After looking at the parts lists I ended up buying Beta22 and Sigma22 kits from Glass Jar Audio. Jeff's kits made assembly a whole lot easier than it may otherwise of been. /salute

I originally decided to build the Beta after seeing Namaanf's build, in AMB's gallery here.

Considering how much this was going ot end up costing anyway I decided to do things right, and not cut corners (for once).
The end result took me nearly 4 months to complete, including waiting for parts to arrive etc.

Like Namaanf, I also decided to go with a Twisted Pear Joshua Tree attenuator (volume control). This little number is a microcontroller driven relay attenuator. The main reason for going with this is that being a balanced amp I would otherwise need a volume pot that had four sets of contacts on it. Something that makes managing space in the case more difficult. Not that using the Joshua Tree solved all my problems, in fact if caused a few new ones.

The JT that Namaanf used was the Version 1. In this version its PSU board was long and thin. But in the Version 2 that I got the board was shorter and fatter. Not a problem I thought until I tried test fit everything in the case. Yup, it wouldn't fit. Glad I found this out before I finished designing the I/O board.

End result was I had to redesign both the main power supply and the I/O board from what I had originally planned.

The amplifer all cased up. At the rear of the case is the custom I/O board, with the Joshua Tree relay board stacked on top to the right.

The power supply all cased up. To the left (the rear of the case) you can see the custom controller board.

And finally both together.

The front panels I had made by Front Panel Express. The cases were from Par-Metal. The buttons (which change colour indicating mode) are Bulgin.

Oh, and yes it sounds great :)