Archive for Uncategorized

Custom ISR Prologue in AVR C


I fell into a situation recently where I was relying on pin change (PCINT) interrupts to decode a serial protocol. This meant I needed to be able to detect if the interrupt was triggered by a rising or falling edge. This particular protocol can have pulses as short as 1uS (8 CPU cycles) so in order to tell if the pin was rising or falling I need to sample it within 8 cycles of it actually happening. Adding time for the pin synchroniser and a non-detirministic ISR entry up to 7 cycles-ish, by the time the ISR starts you’re usually already too late… won’t stop me trying though!

Now I’ll skip the part where you tell me I should just use INT0 or poll or whatever and just look at the case where you do actually want to insert some code before the interrupt service routine (ISR) starts its prologue.
A typical ISR is defined like this:

ISR(PCINT0_vect) {
  //do stuff here

When the compiler is building this, it checks all registers your ISR modifies (including modifications by other functions you call) and pushes them to the stack. A dissasembled ISR might look something like

0000010B  PUSH R1		Push register on stack 
0000010C  PUSH R0		Push register on stack 
0000010D  IN R0,0x3F		In from I/O location 
0000010E  PUSH R0		Push register on stack 
0000010F  CLR R1		Clear Register 
00000110  PUSH R18		Push register on stack 
00000111  PUSH R19		Push register on stack 
00000112  PUSH R20		Push register on stack 
00000113  PUSH R21		Push register on stack 
00000114  PUSH R22		Push register on stack 
00000115  PUSH R23		Push register on stack 
00000116  PUSH R24		Push register on stack

...actual stuff...

00000150  POP R24		Pop register from stack 
00000151  POP R23		Pop register from stack 
00000152  POP R22		Pop register from stack 
00000153  POP R21		Pop register from stack 
00000154  POP R20		Pop register from stack 
00000155  POP R19		Pop register from stack 
00000156  POP R18		Pop register from stack 
00000157  POP R0		Pop register from stack 
00000158  OUT 0x3F,R0		Out to I/O location 
00000159  POP R0		Pop register from stack 
0000015A  POP R1		Pop register from stack 
0000015B  RETI 		Interrupt return 

This is the ISR burning a bunch of CPU cycles storing the state of whatever you just interrupted, and would be about to clobber otherwise, and then restoring it. This is pretty important, but the typical PUSH takes two clock cycles, and there are a lot of them…

It’s possible to define a ‘naked’ ISR where the compiler doesn’t give you the epi/prologue

  //do stuff here

however, now you have to worry about any registers you might be stepping on. Really, you should never use a naked ISR unless you are hand coding assembler.

My decoder is completely interrupt driven, which means my ISR actually does quite a lot, and I would very much like to have it preserve the state of whatever I’m interrupting. However it must sample the pin that changed as the very first thing it does.

Enter the naked top half:

  asm (
    "SBIS %[port], 1\t\n" //Check PINB1 and..
    "RJMP __vector_PCINT0_FALLING\t\n"
    :: [port] "I"(_SFR_IO_ADDR(PINB)) :

and the not so naked bottom half:

ISR(__vector_PCINT0_FALLING) {
  //do stuff

The top half here is built by the compiler and installed as the ISR for the PCINT interrupt we care about. Being naked, the only code it runs is the assembly you see here. It samples PINB, checks if the pin is high or low and then jumps to the bottom half which performs the rest of the ISR. If we jumped, then we can rely on the bottom half to RETI for us (also why we don’t ‘call’ the bottom half), but if we didn’t jump then we need to clean up the ISR ourselves with a RETI. We could also define another bottom half for the rising edge and replace the RETI with an RJMP to it if we care about both events. Finally, the name of the bottom half should start with “__vector_*” to stop GCC complaining.

This works because you can put any name you like in an ISR() definition. GCC will check all of its clobbering and generate the epi/prologue regardless of wether the ISR is attached to an actual interrupt vector. Once it’s created that for us, we can hand code the top half however we like and JMP knowing the the compiler has taken care of the hard stuff coming later. Though you should be careful not to clobber stuff in the top half.

Ubuntu on IGEPv2



This is a short guide to getting Ubuntu running on the IGEPv2 Rev C from a bootable SD card.  There are a few guides around that I’ve based various sections on, but I couldn’t find a complete howto that was up to date with the current hardware.  Most credit goes to Michael Opdenacker of Free Electrons.

Download some Packages

  • I’m assuming you’re building on Ubuntu.  You’ll need to install a couple of extra packages.
    $ sudo apt-get install ia32-libs git git-core qemu qemu-kvm-extras debootstrap build-essential

Install the poky toolchain

  • First download the IGEP SDK Yocto Toolchain from here.
  • Extract the toolchain to /.
    $ sudo tar jxf igep-sdk-yocto-toolchain-*.tar.bz2 -C /

This should install the cross compiler to /opt/poky. To use the toolchain you need to configure your environment, which you can do with this shortcut:

$ source /opt/poky/1.2/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi

You’ll also need to add these to your environment.

$ export ARCH=arm
$ export CROSS_COMPILE=arm-poky-linux-gnueabi-

Build the Kernel

  • Clone the Linux OMAP Git repository
    $ mkdir igep
    $ cd igep
    $ git clone git://
    $ cd linux-omap-2.6/
  • Switch to the kernel version you want to build, in this case 2.6.37-6.
    $ git tag
    $ git checkout -b v2.6.37-6_local v2.6.37-6
  • Run the build with the default configuration.
    $ make igep00x0_defconfig
    $ make -j 4

Create a Root Filesystem

  • Download rootstock from here.
    $ tar zxvf rootstock-
  • Build the filesystem. You can substitute your own username and password here.
    $ cd rootstock-
    $ sudo ./rootstock --fqdn igepv2 --login joe --password 123456 --imagesize 2G --seed build-essential,openssh-server --dist lucid

Build IGEP-X-Loader

  • Clone the Git repo
    $ cd ~/igep
    $ git clone git://
    $ cd igep-x-loader
    $ git checkout -b release-2.5.0-2_local release-2.5.0-2
  • Build with the default configuration.
    $ make igep00x0_config
    $ make

Format the SD Card

You’ll need a micro SD card at least 2GB in size. If you need some more details on how to do this step, you can find them here.  I found this to be a much simpler experience.

Note: Substitute sdc with the actual device node of your SD card. I shouldn’t have to warn you that this will destroy all data on the SD card.

  • Delete all the partitions.
    $ sudo dd if=/dev/zero bs=512 count=1 of=/dev/sdc
  • Run cfdisk to format the card.
    $ sudo cfdisk /dev/sdc
  • Create the boot partition.
    • type: W95 FAT32 (LBA)
    • size: 100MB is probably plenty
    • Mark it as bootable
  • Create the root partition.
    • type: Linux
    • size: Whatever is left
  • Write the changes to the card and quit cfdisk.
  • Format the partitions.
    $ sudo mkfs.msdos /dev/sdc1
    $ sudo mkfs.ext3 /dev/sdc2
  • Mount the partitions.
    $ sudo mkdir -p /media/boot
    $ sudo mkdir -p /media/rootfs
    $ sudo mount /dev/sdc1 /media/boot
    $ sudo mount /dev/sdc2 /media/rootfs

Copy Everything to the SD Card

  • Copy the kernel and X-Loader.
    $ cd ~/
    $ sudo cp igep/igep-x-loader/MLO /media/boot
    $ sudo cp igep/linux-omap-2.6/arch/arm/boot/zImage /media/boot
    $ sudo cp igep/igep-x-loader/scripts/igep.ini /media/boot
  • Copy the root filesystem.
    $ cd /media/rootfs
    $ sudo tar zxvf ~/igep/rootstock-
  • Install kernel modules.
    $ cd ~/igep/linux-omap-2.6/
    $ make INSTALL_MOD_PATH=/media/rootfs modules_install

Modify the X-Loader config

  • Edit /media/boot/igep.ini.
  • Specify the rootfstype.
    ;  --- Configure MMC boot --- 
    root=/dev/mmcblk0p2 rw rootwait
    ; add this line

A Few Modifications to the Root Filesystem

  • Copy tty config.
    $ cd /media/rootfs
    $ sudo cp etc/init/tty1.conf etc/init/ttyO2.conf
  • Edit etc/init/ttyO2.conf and change.
    exec /sbin/getty -8 38400 tty1


    exec /sbin/getty -8 115200 ttyO2
  • Disable ureadahead.
    $ sudo mv etc/init/ureadahead.conf etc/init/ureadahead.disabled
  • Setup the network interface by editing etc/network/interfaces. This is just an example, you’ll probably have you own details to put here.
    auto lo
    iface lo inet loopback
    auto eth0
    iface eth0 inet static
  • Add some more source repositories by editing etc/apt/sources.list.
    deb lucid main universe
    deb lucid-updates main
    deb lucid-security main

Testing the Build

  • Unmount the SD card from your development machine.
    $ cd ~/
    $ sudo umount /media/rootfs
    $ sudo umount /media/boot
  • Insert the card into the IGEPv2 and power it up.

The board should boot and you should see the kernel messages on the debug port. You can connect to the board over ssh using the username and password you used when creating the root filesystem, and the IP address you specified in /etc/network/interfaces.

The Pulsar’s Maiden Flight


So it’s been 18 days short of a year since the Pulsar arrived in a giant box.  Since then there has been a lot of time spent measuring and modelling and generally designing to figure out how to fill it with stuff to ready it for the outback challenge.

It took a few attempts at various components to get the fit right.  Measuring its sleek, sexy curves proved to be quite difficult.  The last few days have been spent shifting things around to perfect the balance and program my recently replaced radio equipment.

So as you can see in the image, the cabin of the Pulsar is pretty cramped.  On the right is the stack of avionics including Asity and the controller for the camera.  In the middle is the servo that holds and releases the water bottle (under all the cables).  Finally on the top left is the receiver used for manual control.  Asity is now capable of controlling the aircraft, so once I’ve tested it thoroughly, that receiver will be replaced with a slave receiver and Asity will take over.

Today was the latest in a few attempts, the first since January, to get the Pulsar off the ground.  I warmed up a bit by taking a the Paprika for a spin, as I haven’t actually flown anything other than a simulator for about twelve months.  The wind was a bit on the strong side but wasn’t gusting too badly, so we decided to go ahead with launching the Pulsar.

The launch was a bit hairy as always but once I pushed the throttle it had no trouble climbing almost vertically.  Once I had some altitude I could take a breath and find a comfortable attitude.  It doesn’t handle anything like the Paprika as you would expect, so I can’t apply the throttle and do a quick backflip to escape a low altitude stall.  It didn’t take much trim to get it flying level but I did leave the elevator controls linear rather than the softer exponential option.  Given the elevator is so huge this would have made it much more controllable.  So I spent the first flight bobbing up and down with over corrections but generally flying smoothly.

One major issue I had not considered was that the wings look identical from top to bottom.  This often left me guessing which way up the aircraft was, leading to a terrifying accidental barrel roll.  Given its wingspan it doesn’t flip over very quickly so my usual ‘trial and error’ approach to situational awareness doesn’t leave me with much time to make any mistakes.  I’ll probably be sticking some fluro-yellow tape to the underside.

The landing was a typical repetitive stall as I continued to overcorrect with the elevator.  Under full flaps, this aircraft can drift incredibly slowly which made the landing look like a slow motion crash.  Luckily it actually was slow so it touched down with only a slight bump.  Once I’ve sorted out the controls it should be a very nice aircraft to fly.

The Pulsar wasn’t the only plane to take it’s first flight today.  My supervisor has recently built a Pilatus Porter which has also been waiting patiently to get off the ground.  His son, Jan took the controls and it too had a successful maiden voyage.

The day almost went without incident.  I took the Paprika for another run after the Pulsar was done.  At some point during the flight, one of it’s stabilisers cracked, and was hanging limply by some balsa threads.  Miraculously, or just because of my mad skillz it made it to the ground in one piece.  If it didn’t have a v-tail, I don’t think the landing would have been nearly as successful.

So the Pulsar flies!  My work now is to mutilate the shiny white fuselage by cutting holes for the camera and payload which I can’t say I’m looking forward to.  Hopefully I can get it back up to test the bottle drop in time for my April deadline.

DSM2/DSMX Remote Receiver Protocol

The AR8000 Receiver with a remote receiver attached

I’ve been playing around with my transmitter a lot recently as flying season is starting up again and the darn thing isn’t working well.  Likewise, the receiver I’ve just installed in the Pulsar refuses to bind to my radio.  So a big fail all round by Spektrum, which has lead me to seek alternative solutions.

The AR8000 Receiver with a remote receiver attached

I’ve seen a few forum threads discussing the serial protocol used by Spektrum’s remote receivers and it seems pretty straight forward to collect the data from them; bypassing the main receiver completely.  Unfortunately the only decent write up of the details that I could find was a bit out of date, and only covered the 7 channel case.  So here is what I’ve learnt from poking this device with an oscilloscope and a logic analyser for a few hours.

I’m using a Spektrum DX8 for all my testing and will focus on the DSMX modulation as that’s what made the most sense to me.

The physical layer is a very simple asynchronous serial stream.  There are three wires: the orange is 3.3V, and will draw about 30mA, the black is ground, and the grey is serial data (3.3V).

The serial data is standard 115200 baud, 8 bit wide, no parity and one stop bit (8N1).  I’ve seen many different reports on what this speed should actually be. My own measurements of the few receivers I have puts it around the 110 kbps mark.  I’m pretty sure it’s ‘supposed’ to be 115.2K and you won’t have much trouble if you just use the standard speed.

Now things start to get a little tricky.  My DX8 allows me to select either DSM2 or DSMX modulation as well as either an 11ms or 22ms frame speed.  This seems to decide what resolution your data is (1024/2048) and will vary the packet format slightly.  As far as I can tell, the DX8 always transmits packets 11ms apart, but as my main receiver won’t talk to me I can’t see the variations in the PWM output rate.

The data format is set when binding the receiver, and is stored along with the model data in the transmitter.  You can bind multiple remote receivers, one at time as long as you have the same modulation and frame rate selected.  I just use the AR8000 to bind the remote receivers and won’t look into binding without it.

Once powered up, the receiver will wait for the radio it is bound to, to begin transmitting.  It will not send any data if it’s not receiving anything.  This is also true if the transmitter is turned off, the remote receiver will simply stop sending data.

A frame consists of 16 bytes which includes 7 channels of data.  If you are using more than 7 channels, which is the case for the DX8 then your frames will include two packets of 16 bytes, 11ms seconds apart.

Each data word is two bytes long (16 bits).  The first word is a count of missed frames which uses at least 10 bits, I didn’t manage to get it to wrap around.  The remaining seven words are channel data for the current stick positions.

The channel data is given in a seemingly random order, although during my testing it remained constant for a given modulation and frame speed even after power cycling and rebinding.

Each 16 bits contains the channel ID and the channel value, as well as a couple of zeros.  Be aware that the channel ID bits did move when the receiver was bound using a 1024 mode versus a 2048 mode.  The channel value is the 10 LSBs in a 1024 mode and the 11 LSBs in a 2048 mode.  I believe DMS2 at 22ms is the only 1024 mode for this transmitter/receiver.

The channel ID is the 3 or 4 bits above the channel value.  I say 3 or 4 as I expect this protocol can handle more than 8 channels, but I have nothing to test that with.  This identifies the channel to which the value following should be assigned. 0: Throttle, 1: Aileron, 2: Elevator, 3: Rudder, 4: Gear, 5: Aux1, 6: Aux2, 7: Aux3.

For DSMX, each channel will only be included once in each frame, so the spare words in each packet are set to all 1′s (0xFFFF).  In DSM2-2048 A few channels were repeated in the second packet.

The MSB of each word appears to identify the packet within each frame.  It is usually 0 except in the case where the word is not used for channel data (as above) or immediately following the Frame Loss Count in the second packet of the frame.

The channel values provide the duration of the pulse used to control the servos.  The following is how I plan to implement my own PWM and not necessarily how the Spektrum receivers do it.  It could be the same, I just can’t measure it while my receiver is broken.

 The DX8 allows servo travel to range from -150% up to 150%.  A typical PWM controller will go from 1000us up to 2000us for the full range of the servo, so I’ve decided to go from 750us up to 2250us to match my transmitters range.  You’ll find most of the scaling and direction of the data is done in the transmitter and only absolute positions are sent to the receiver.

There are a few details I didn’t really look into during the last few hours as I have enough to keep me going.  So hopefully this is helpful to someone else and always remember that your mileage may vary.

Pan/Tilt Prototype is Complete

PanTilt Complete Small

The pan/tilt hardware for my antenna tracking tripod is finished.  It even looks kinda like my design :D .

With the layer of zinc I didn’t account for, everything is actually pretty tight (after some sanding).  There is no play anywhere except for some slight backlash in the gears.  The mounting brackets don’t slide on the shaft and the chassis doesn’t rock on the main bearing at all.

The unit as a whole is pretty solid and weighs more than my scales will tell me.  My CAD software tells me it’s around 4 to 5 kg.

Unfortunately the small gears I received had the wrong bore size.  I couldn’t be bothered having new ones shipped from the US so I decided to drill them a bit larger myself.  This ended in fairly average results.  The gears fit the motor shaft fine, but they have a bit of a ‘wobble’ as they rotate which is less than ideal.  They’ll work for testing, but will be an issue when I put some load on them.  Some new gears from a local supplier are on the way.

The bends in the metal were off by a degree or two.  Not much, but the very tight tolerance on the shaft mounts mean that if the holes don’t line up then the shaft jams when I try to assemble it.  This was solved with my trusty sledge hammer, which was odd given the 0.05mm tolerance.

The electronics and their mounting are probably one aspect I put the least thought into.  I’m just using the Pololu A4988 controllers and mounting them in a very flimsy plastic frame.  It’s not my proudest moment, but will work for now.

I’d actually like to make my own board at some point.  The Pololu controllers are a bit pricey compared to the chip that actually does the work.  They also won’t easily accommodate a heatsink.  Without the heatsink I can only run the motors at about half their maximum power.  My own board would have actual mounting holes and a heatsink making the whole arrangement much neater.

The gears come with an M2 grub screw which is pretty small considering the load I’ll be putting on them.  These tiny screws need a 0.9mm hex key which is very small and not amongst my collection.  It also doesn’t appear in any sets I could find in the shops.

I had a go at tapping a new M3 hole for a bigger, more convenient grub screw.  This pretty much failed as the hole for a set screw is very shallow, and a hand-tapped thread tends to be crappy at the top.  So there wasn’t enough thread for the bigger grub screws.  I’ve decided to order the tiny hex key and see how the small screws go.

Right now I’ve mounted two SLA batteries on the chassis itself along with Asity as the controller.  This should let me play with it, without worrying about tangling cables.  I still haven’t written any software to control it, so no movement yet.

More Pan/Tilt Parts

PanTilt Small

The main chassis for the my pan/tilt mount is made from 5mm steel plate.  This is a rather difficult material to work with in my garage, so I opted for the services of some professionals with industrial size lasers and presses.

The lasers, as you would expect, are very precise.  All the cuts are spot on.  My main concern was with the bends.  Even with a robotic press, bending thick metals can be a bit unpredictable.  Even so, the bends came within 0.5 mm of where they needed to be.

I took the parts straight to the electroplater across the road and had him put a zinc coating on all the parts.  The process cleaned off all the crumbs from the laser as well as the heat-scale and the zinc made them nice and shiny.  Over all I’m very happy with the finish.

The parts are completely rigid, at least when tested with my puny human muscles.  The structure should be capable of quite a significant load.  The weakest point in the design will be the strength of the motors.  This isn’t an issue if the load is balanced around the rotation axes.

The plastic bearing runs mate with the steel plate of the base and the chassis with six extrusions.  The fit was actually quite tight, but after some squeezing they fit and stay together perfectly.

The steel balls fit the spacer perfectly as well.  It takes a bit of force to insert them, but once they’re in, they stay in while still rolling freely.  With all the balls inserted (I only have 9 at the moment), the spacer is sandwiched between the two runs.  The two halves spin freely on the main bearing and the spacer doesn’t rest on the bottom run.

There is one last package to arrive containing bearings, nuts & bolts.  Hopefully it will be here by the end of the week.

Pan/Tilt Heads for Antenna Tracking

I’ve fallen back into hardware mode before making any significant progress recently.  I have to say I enjoy it more, and I do have so much hardware to come up with for the Outback Challenge.

The last week has been focused on antenna tracking.  Basically I have two large yagi antennas that I need to keep pointed at the aircraft which requires a pan/tilt head mounted on a mast.

The antennas are quite large, weighing about 4.3Kg total and being about 2m long. I’d also like the mount to be stable enough to mount a camera with a suitably large lens.  Having something automatically record the aircraft will make documentation much easier.

This puts me in an awkward range in terms of pan/tilt heads. The options either seem too light and under-powered, or prohibitively expensive.

Not considering the tiny, point-and-shoot camera variety; the affordable end of the scale looks to have two serious options (although if there are any out there I have missed I would love to know about them).

The most popular in the FPV community seems to be this thing, annoyingly unnamed.  Made from laser cut wood it is more than capable of swinging a single patch antenna around, but will definitely struggle under my yagis.

It’s nice and cheap at $90 including servos.

The pan/tilt head closest to my specs is the AT Pro-1000.  This is made completely of aluminium and when using the supplied HS645MG servo on the tilt axis there is plenty of torque, about

The main drawback of this design is that it is definitely aimed at patch antennas, with large, wide structural members.  They do provide a bracket for mounting a single, smaller yagi, however getting both of my antennas on there will be awkward.

AT Pro-1000The AT Pro-1000 weighs about 1Kg and is roughly 30cm wide.  It’s price point is almost exactly where I am looking at $220 including servos and yagi bracket.

So it seems easy enough to swing patch antennas around.  Unfortunately patch antennas don’t offer the gain or the focus of a large yagi.  Outback Joe didn’t exactly get lost in a convenient place and maintaining comms is pretty critical.

The other end of the scale comes with incredible specs and some pretty fantastic features.  It also comes with a bunch of request for quote forms…

D48ESomething like the D48E or even it’s smaller cousins would easily meet my needs, and then some.

Capable of swinging over 10Kg around at 100 degrees per second (probably not at the same time) and incredible 0.003 degree tilt resolution.

The offerings from FLIR also boast ethernet integrated and all weather operation.

These are actually available from distributers in the US and Canada, but even the smallest was well over $2000.  Far beyond my budget, and requirements for that matter.

The one major difference is the design.  The D48E has more uses in mind than just patch antennas and so only offers a single mounting bracket for any accessories, making it easier to mount custom hardware.

So like most of my product searches recently, I’ve resolved to design and build one myself.  I’d be lying if I said I was disappointed :P

Over the last week I’ve been madly scheming and searching the interwebs for suppliers and I think I’ve gotten to a draft I can actually build in my garage.

I originally wanted to use 6mm steel plate to ensure it was strong and rigid.  I eventually realised that my tools are not up to steel, especially if I were to try hot-forming the bends.  I considered having someone machine the steel for me but decided that I didn’t really need steel at all.

To simplify things a few orders of magnitude, I decided on 6060/1 aluminium in stock extruded channel.  Aluminium is much easier to work with the in the backyard, and using stock in the right shape meant that my job was already half done.

At the moment I’m trying to decide between servos or stepper motors, and where to find the cheapest parts ($50 for that hub in the middle! seriously!) but the shape is pretty much fixed.  The antennas will mount towards the ends of a bar bolted to the top face.

The base diameter is 150mm and sits completely on a custom bearing, so there should be very little wobble.  I’m aiming to keep the entire cost below $300.

Meet the Paprika

Another long absence ends as I’m done with the crappy business of moving house.  Luckily have something new to talk about :D

This is my new plaything that has recently eaten up all of my time and money.  It’s called a Paprika (AKA Gem) and is the RC glider I’ll be spending a lot of time with over the coming months.

Some stats:

Wingspan: 2m

Weight: 1.515kg

Wing Loading: 4.23 kg/m^2 (13.86 oz/ft^2)

Length: 1.2m

Airfoil: MH32

I’ve gone well overboard with the power train starting with a 100A Speed Controller and ending with a 12×6 folding prop.  In the middle is an 850W Hyperion Brushless motor which will easily be capable of vertical climbs.  The rational of course is efficiency.  I expect the most efficient state for this aircraft will be when the motor is off and the prop has folded back, so the quicker the climb the sooner I can get back to gliding.  This glider won’t actually be the most efficient aircraft it can be, but it will give me plenty of flexibility to try things.

I’ve upgraded my old 36MHz radio to a very snazzy Spektrum DX8.  This thing is incredibly complicated compared to the old 4 channel with mechanical trims.  It does include a telemetry module to keep me updated on the numbers onboard the aircraft which is nice, but it’s gonna be weeks before I wrap my head around how all the other features will benefit me.

I also have some other toys, including a camera and some solar panels.  I’m not expecting fantastic results from either of them, but they will hopefully be enough to inform some avenues of research and of course more money spending.  I’ve also picked up a cheep EeePC to act a ground station.  For now it will just be downloading ESC logs and video recordings, but eventually I’ll have some kind of interface to the auto-pilot I’m in the middle of building.
Maiden flight will hopefully be early next week – weather permitting.

Just some updates

It’s been a while since my last post.  This is because I’m halfway through several projects and I’ve been trying to actually get something finished to write about.  Failing that, I think I’ll bundle a bunch of updates into this post.


The extruder fitted to the printerKapton tape finally arrived on my doorstep the other week.  This has allowed me to complete the extruder, giving me a complete Mendel! :D It appears to work in that it gets hot enough to melt the plastic I poked it with…  I’m not really sure how accurate the temperature measurement is, as MakerBot doesn’t provide any technical data about the thermistor they stock.  So providing the right temperature tables is a bit tricky.
Now I’m spending my time working out the various software tool chains available.  The main choice is between the RepRap host software and ReplicatorG.  I played around with each of them a little and their associated firmware.  The main difference between them is that the RepRap software implements a 5 dimensional G-Code interpreter where ReplicatorG controls the tool speed directly.  The 5D GCodes are much closer conceptually to the actual outputs of the printer, and I see that as the better method.  However, the RepRap implementation leaves a bit to be desired.  ReplicatorG is based on Processing so the GUI is much more stable and intuitive.  I also found the firmware, while it has less features, is also a little more robust.  So I’m ‘moving forward’ with ReplicatorG, and will likely have a number of contributions to make.
The main thing ReplicatorG is missing is support for the Mendel, as it’s primary focus is the CupCake CNC.  The work around to get the stepper extruder working with the 1.x build wasn’t very satisfying.  I’ve added support to the 2.x branch and it seems to work.  Unfortunately, early in my experimenting with the firmware, one of my H-Bridges exploded rather spectacularly leaving my printer crippled.  A replacement will be arriving tomorrow so I can do some proper testing.  I’ll put my code up along with some explanation and howtos once I’ve tested and figured out a working Skeinforge profile.


I think it’s looking realistic enough now that I’ll give it a short mention here.  I’ve been working on a new servo design intended to fit in the very thin wings of a scale glider.  The main design goal was to keep it under 6mm thick, which I’ve managed to do.  Depending on a few remaining design decisions, I think I can get it down to 5mm thin.
The development version of the servo controllerThe prototype PCBs arrived this week which I was very excited about.  I have Ben at Nias Digital to thank for getting them manufactured.  I’ve populated one of the broken-out versions so I can start testing the firmware.  This involved a lot of time with a scalpel and a pin followed by some frying pan reflow due to my lack of expensive equipment, and the need to use 0402 sized components.  It came out well however, and initial testing has been positive.
More on this one later :)

Research Poster

For those of you who don’t know, I’m actually a PhD student at the Australian National University researching Energy Based Planning and Management for Unmanned Aerial Vehicles.  Given I haven’t mentioned this here before, I think that’s most of you.
Each year the College of Engineering and Computer Science hosts a ‘poster day’ where research students can show off their projects.  So I spent the last week creating my masterpiece.  I’ve only been at this research thing for three months now, so my ideas are still a bit… ‘unspecified’.
So here is my poster in all it’s glory! Enjoy :)