Archive | Projects RSS for this section

Double Whitworth Quick Return

This was an experiment of a few different things:

  • A quick return mechanism with a return ratio of 24:1
  • 3d printable herringbone gears
  • The gears can be swapped to change the ratio, without changing any other parts. Ratios of 1:4,6,8,10,12 are possible
  • The whole mechanism was designed for assembly: no more than two parts come together at any stage

I’d been using spiral-faced cams for quick-return purposes and thought maybe there was a better option. The Whitworth quick return (below) is a crank-rocker with one slow stroke and a quick return stroke, constructed by having the distance from crank pivot to rocker pivot “almost” equal to the crank length. The return ratio can be defined as r=\frac{\abs{\theta_{max}-\theta_{min}}}{2\pi}, where \theta_{max} is the crank angle when the rocker reaches it’s maximum, and similar for \theta_{min}.

With a crank length L equal to 90% of the pivot distance y, the WQR has a return ratio of about 6.5. A return ratio of 24:1 requires the ratio L/y to be about 99.2% – a tolerance unachievable with 3d printing and difficult in any other manufacturing method. But the double-crank WQR can be used as an input for the crank-rocker WQR – giving a two-stage (or double) quick return linkage that has a high return ratio while using low-tolerance links. The prototype was a good proof-of-concept but of course, a high return ratio requires very little torque on the output – even slight resistance stops the was a success

Herringbone gears provide the same smooth operation as helical gears, without the additional axial load produced by the helical teeth. They can be modelled in the same way as helical gears, except with a loft extending from the midplane to each face, in opposite directions. The ones for this project range in module from 1.2 mm to 0.8 mm, and came out pretty well, with smooth operation all around.

I wrote a script to size the gears for this project. Given a set of desired ratios, the script performs a brute-force search through m, z space to find a two-stage gearbox that can swap gears to satisfy all the desired ratios, while fitting in the available space. It then outputs a few of the best options for each ratio. For this project I chose 1:4,6,8,10,12 and the selected gears are: (given gear 1 with z1, meshing gear two with z2, at module m denoted as z1|z2_m)

    \begin{align*} 1:4 &- 20|40_{1.2} \times 20|40_{1.2} \\ 1:6 &- 20|40_{1.2} \times 18|54_{1.0} \\ 1:8 &- 20|40_{1.2} \times 18|72_{0.8} \\ 1:10 &- 17|55_{1.0} \times 22|68_{0.8} \\ 1:12 &- 18|54_{1.0} \times 18|72_{0.8} \end{align*}

The 1:10 gearset doesn’t share any gears with any other set, so I didn’t bother actually printing that set. However all four other ratios run smoothly and are easy to interchange.

The mechanism was designed such that only two parts come together at any point. This was a lot easier to assemble than the last big linkage I printed, but required a lot more fasteners. It was easy to change the gears, as the faceplate could be removed without disturbing the rest of the layout. I think that the DFA design made the skeletal aesthetic a lot “noisier” and less aesthetically pleasing than a fully-aligned design as before.

Overall this was a successful experiment and a good way to further improve my printing skills.

Spur Differential

Helical gears use an involute tooth that’s been swept along a helix. At any cross-section perpendicular to the gear axis, the gear profile is exactly the same as a straight spur gear – so a helical gear can be modelled as a loft between the top & bottom faces. The sketch defining the tooth profile gets offset by an additional amount, corresponding to the desired helix angle.

Both of these are spur differentials, printed about 6 months apart.

The white one was designed when I was new to both 3d printing and gears, so the involute is not quite right and the tolerances are sloppy. There is a lot of play and occasional jamming, and it was constructed using screws fixed with loctite.

The orange/blue one is more recent and uses my helical gear model. There is just enough clearance between all rotating parts to allow smooth rotation without any significant backlash. The nuts are all press-fit and sit flush with external surfaces – the shafts are designed such that the screws can be tightened in place without loctite. Overall a much better model!

Aquarium Lighting! Pt. 1

My aquarium is fully planted:

I have a Finnex Planted+ 24/7 RGB LED light – the W/R channels provide the necessary light for photosynthesis while the G/B channels allow for colour mixing, to give a sunrise/sunset cycle. The trouble is, the timing for this cycle is fixed and there’s no way to vary the photoperiod – which is actually a bit long for my tank and leads to algae buildup. So I’ve had to keep the light on a timed socket to reduce the photoperiod, which sadly means no more sunrise/sunset cycle. If only I had a better way to control the light…

I’m looking at moving to a longer tank, which will need a new light. Commercial options run at about $250 minimum for the LEDs and controller – if only I had a decent controller I could use cheaper LEDs!

Commercial LED controllers (for example the Phillips Hue) are cheaper, but still a bit pricey – and don’t give the flexibility I’m looking for. So I’m planning to build a custom 4 channel light controller. It will need to interface with the existing LED strip in the Planted+; after some poking around I’ve found that the microcontroller in the light supplies +15V to the LEDs and runs PWM switching to ground.

The controller will be based on a Raspberry Pi 3, because I had one lying around and it will allow for easy wifi updates of the light program. I’ll design a PCB to be printed cheaply (e.g. SeeedStudio) and plug directly into the RPi – the circuit will mimic the existing low-side switching arrangement. The whole controller will be powered by two SMPS’s – 25W@5V for the RPi and 70W@15V for the LEDs. The existing power supply is rated for 15W@15V, so this should allow for almost 3x the light level.

The total project cost should be under $100 (plus a bit of work) and will allow for much more flexibility than a similarly-priced commercial option.

Variable Stroke Pt. 1

I’ve been experimenting with variable stroke linkages for a while, with most of my new prototypes being 3d printed. These linkages have two inputs – the crankshaft and the stroke amplitude input – so I’ve been using gears to drive the two from one input.

Traditional gear manufacture involves using off-the-shelf tools to cut gears from blanks, and proper use of the tools will give accurate geometry. But 3d printing the gears requires an exact model of the involute tooth surface, which is a bit more tricky. Solidworks includes a “gear” template, but this is just a placeholder, not an accurate model. Some models can be found online, but these are almost always in imperial units. I wanted a parametric model of a precise involute cylindrical gear, using the metric standard, so I made my own.

There are 5 key numbers that define a given gear:

  • m – module
  • z – number of teeth
  • \alpha – pressure angle
  • \psi – helix angle
  • x – profile shift

I’ll discuss the last two in a later post. For now we can assume they are equal to zero, so that the model is only dependent on the first three.

A metric gear has two primary tooth size measurements aside from m: h_a – the addendum height, and c – the root clearance. These are shown below in a sketch of an “unrolled” tooth. Typically, h_a = 1.0 and c = 0.25. Four important dimensions associated with the gear are:

  • D_p = m \cdot z – the pitch diameter
  • D_a = D_p + 2 \cdot h_a – the tip diameter
  • D_f = D_p - 2 (h_a + c) – the root diameter
  • D_b = D_p \cdot cos\alpha – the base circle diameter

Involute gears use a tooth profile following an involute curve – this is by definition the curve obtained by unrolling a string from a circle. The “string” is always tangent to it’s “base circle” and perpendicular to the curve obtained, as shown below for a base circle of radius r. The position of point O is (x_O, y_O) = (r cos\theta, r sin\theta). Point Q on the involute is then:

    \begin{align*} (x_Q, y_Q) &= (x_O + l sin\theta, y_O - l cos\theta) \\ &= r(cos\theta + \theta sin\theta, sin\theta - \theta cos\theta) \end{align*}

This equation can be used directly in Solidworks as an equation curve defining the tooth face, however it only defines one side of one tooth. Ideally the modelled tooth will be symmetric about the x-axis, so the involute needs to be offset (rotated around the base circle) by the appropriate amount. We also need to know when to start and end the curve.

The rotated involute curve can be formulated by multiplying the involute equation above by a rotation matrix R(\gamma), which rotates the curve counter-clockwise about the origin by \gamma radians. The generic equation for an involute of a base circle with radius r_b, rotated by angle \gamma is:

    \begin{align*} \begin{bmatrix} x_\theta \\ y_\theta \end{bmatrix} &= \begin{bmatrix} cos\gamma & -sin\gamma \\ sin\gamma & cos\gamma \end{bmatrix} \cdot \begin{bmatrix} cos\theta + \theta sin\theta \\ sin\theta - \theta cos\theta \end{bmatrix} \\ &= r_b \cdot \begin{bmatrix} cos(\theta+\gamma) + \theta sin(\theta+\gamma) \\ sin(\theta+\gamma) - \theta cos(\theta+\gamma) \end{bmatrix} \end{align*}

The involute curve needs to be rotated such that the tooth axis lies on the x-axis, as depicted below. This angle \beta can be separated into two components:

  • The half-tooth-width angle \phi = \frac{2\pi}{z} \cdot \frac{1}{4} = \frac{\pi}{2 \cdot z}
  • The involute angle inv(\alpha) = tan\alpha-\alpha

So \beta = \frac{\pi}{2 \cdot z} + tan\alpha - \alpha, and the involute should be rotated clockwise by this angle, so \gamma=-\beta. The equation for this curve is:

    \begin{equation*} \begin{bmatrix} x_\theta \\ y_\theta \end{bmatrix} = \frac{D_b}{2} \cdot \begin{bmatrix} cos(\theta-\beta) + \theta sin(\theta-\beta) \\ sin(\theta-\beta) - \theta cos(\theta-\beta) \end{bmatrix} \end{equation*}

For the opposite of the tooth, the involute “string” is beign unrolled clockwise: simply take \theta\rightarrow-\theta. The curve is then rotated counter-clockwise, so take \beta\rightarrow-\beta.

What are the limits of the curve? From the above diagram, the distance between the origin and Q is \frac{D_Q}{2}. Then l = \sqrt{\frac{D_Q}{2}^2 - \frac{D_b}{2}^2}. But we also have l = \frac{D_b}{2}\cdot\theta, so the angle \theta where point Q is at a diameter D_Q is given by:

    \begin{align*} \theta_Q &= \frac{l}{(\frac{D_b}{2})} \\ &= \frac{\sqrt{D_Q^2-D_b^2}}{D_b} \end{align*}

The maximum point of the curve (at the tip) is then given by \theta_a = \frac{\sqrt{D_a^2-D_b^2}}{D_b}.
The minimum point (at the root) is given by \theta_f = \frac{\sqrt{D_f^2-D_b^2}}{D_b}.
The tooth profile is then formed by tracing the involute curve (x_\theta, y_\theta) between these limits. Except for some gears (z <\approx 40 – see below) the root is actually below the base circle – and the involute is not defined below the base circle.

In this case I model the tooth flank as a straight, radial line. In reality the tooth flank is sometimes undercut, and I will go into this in another post.

3d Printer

Earlier this year I decided to get a 3d printer to help with prototyping in robotics & various other hobbies. I wasn’t particularly wowed by any of the consumer-grade options available, and it seemed like sourcing individual parts for a full DIY design would take more effort than it was worth, so I went with a kit!


My requirements were pretty simple:

  • E3D v6 hotend
  • Heated glass bed
  • >150 mm printing range in all dimensions
  • Easily expanded

There were a few options satisfying these, in the end I chose a MTW MiniMax as the best value for money.




Mechanical systems assembled

Mechanical systems assembled

It took a few afternoons to get it up & running. I started printing with PLA as most people recommend it as the best all-rounder material, but I’ve since found PETG to be stronger, more stable and easier to print.

After (slowly) printing a fan bracket I printed a case for a raspberry pi, which would act as a print server and allow me to not be tethered to the printer during a job.

Print server

Print server

Since then I’ve added a whole series of modifications, improving print quality and ease of use:

  • Y-axis cable chain (from MTW) – keeping things tidy
  • Rubber foot mounts (from MTW) – to reduce noise & vibration
  • Easy bed levellers (by beerglut) – the original bed levellers needed a screwdriver to adjust, these use thumbwheels instead
  • 360 degree print fan shroud (by beerglut) – for more uniform print cooling
  • Extruder fan mount – to cool the extruder gear & prevent it from warping PETG before the hotend
  • Sprung Z-homing screw – to reduce backlash present in the original design
  • Filament spool mount – intended to reduce the load on the extruder motor by mounting the spool on a bearing-supported roller, but this removed all tension from the spool and just resulted in tangled filament
  • Power supply cover & switch – the kit as-built includes only minimal protection from the mains wiring at the back, and needs to be turned on/off at the wall – so I installed a fused switch with a C14 socket to make it a bit safer & easier


Robot platform

This robot platform is just for my own experiments in robotics electronics & software, mostly just building on what I learned from Dusty & the NIARC project. Overall the aim is to provide a platform for localisation & mapping, for very low cost at the expense of added effort.


20170213_195947Chassis: Laser-cut acrylic with brass standoffs

Structural parts: 3d printed in blue PETG

Drive: 2x high-torque stepper motors, each driven by a TI DRV8825 driver which offers comparatively high performance for the cost. Big fat squishy tires since hard wheels didn’t perform well before. A dedicated stepper cooling fan will keep things running nicely.

Sensors: 6x HC-SR04 ultrasonic sensors, GY-85 9dof inertial measurement unit.

Electrical & Brains: TBC! The system will run off two 3S lithium batteries in series, giving 24V. I’m aiming to use a separate microcontroller for each system, with CAN communication between systems.




Last year, two friends and I entered the 2014 NI Autonomous Robotics Competition on behalf of UWA. The theme was agriculture: the robots had to navigate a course to a seed pickup point, then plant those seeds in specified locations before returning to the starting point. The robot had to avoid obstacles and (being a competition) had to be fast. We wanted a design that was cheap and easy to manufacture while still being competitive, and this was the outcome:


The 8 x 3.75m world was built from astroturf and cinderblocks, and the “seeds” were 100mm cubes made of stressball foam. The course looked roughly like the picture below, with obstacles placed randomly in the first region, and the “planting rows” in the second region. In order to gain points the robot had to traverse the entire course within 2 minutes, planting all the seeds inside the bounds of the planting rows while avoiding all obstacles and walls.


We were to be funding the robot ourselves, and with no prior parts to use we had to be frugal – so most of our design decisions were based on getting value for money regardless of the work involved. Fortunately the most expensive component was provided by NI – the onboard processor was an NI myRIO which features an ARM Cortex processor (running a real-time OS) integrated with an FPGA, Wi-Fi and plenty of configurable I/O ports. Both the RTOS and FPGA had to be programmed using LAbVIEW (C++ is possible but complicated to set up the development environment) so as the team programmer, I got a lot of practice using LabVIEW.

Early on in the design phase we settled on the layered chassis structure to make it easier to update the robot. We used wood and some standard fastenings from Bunnings for the same reason, and to reduce cost.

We decided that a two-wheeled differential drive would be simpler to program and require fewer parts (hence less risk of breakage) than other drive configurations like tracks or omni-drive. A quick analysis of torque & speed needed to run the course gave us our motor requirements and after considering a few options we settled on some stepper motors – not only would they provide the necessary power, the stepping operation of the motors would give us automatic odometry, eliminating the need for wheel rotation sensors.

As the robot was not allowed to touch any walls or obstacles, it had to be fitted with some kind of proximity or range sensors. We considered every reasonable option: IR proximity sensors, self-made LED/LDR sensors, LIDAR and SONAR sensors, and were about to go ahead with an array of IR distance sensors when we found the HC-SR04 ultrasonic range sensor online for $2 each. These are time-of-flight sensors which don’t have much control circuitry built in, so the distance measured has to be timed by the main robot controller: we used the FPGA for this as the timings between transmit and echo pulses were on the order of microseconds, too fast for the RTOS to be reliable.

The first prototype used a two-layer chassis, with three ultrasonic sensors, wheels made of plywood and rubber bands, and custom designed motor brackets 3d-printed from ABS. We wanted to be able to recycle the parts after the competition, so we kept wires long and used removable mounts.


These wheels had good traction in general, but accurate odometry was difficult on thick carpet or astroturf. We saw two solutions: to use wide tires and spread the load so that the ground didn’t get as deformed, or to use very thin wheels to penetrate through the grass to the base layer. For the competition we decided to go with the thin option, so I modelled some and 3d printed them in ABS.


These thin wheels worked very well on carpet and on the astroturf sample that we’d been given, but in the final competition the wheels didn’t penetrate far enough to the base layer so we lost a lot of traction.

One requirement of the competition was that the robot have an emergency stop button which was easily accessible and would cut power to all moving parts. Rather than use a toggle switch we opted to develop a latching circuit which would provide the emergency stop functionality as well as cutting power in case of a fault – I’ll write about this in another post.

We had two main designs for the seed dispenser: the first was a ferris-wheel type design which loaded the seeds into a circular magazine and dispensed them by placing them gently on the ground – the aim being to prevent it rolling out of the designated zone. This design placed seeds very well but it was very heavy, slowing down the robot substantially and taking the weight off the driving wheels. Despite being heavy, it was not very structurally sound and was mostly held together with duct tape. You can see it in our video for Milestone 4:

The squeaking noise comes from the poor, sad roller ball that sits between the drive wheels and the dispenser – at this point we realised there were major balance issues but we did not have the time to redevelop from scratch. Making the dispenser stronger would have meant even more weight so we redesigned it completely and went for a square tube-shaped hopper made of balsa:


This layout was a bit less delicate in placing the seeds, but it was stronger than the wheel design and was a tiny bit lighter. The final competition was looming and so most of our work from here on was more or less a hack to just keep it running – exemplified by the mechanism one of my teammates built to dispense the seeds from the hopper, which was a Scotch yoke cobbled together using stationery around his house, and worked perfectly:



This also fit very nicely with our goal of keeping things cheap and easy to manufacture.

The robot ended up struggling in the competition and was knocked out in round 1. The round included 3 runs of the competition course: on the first run the robot didn’t move as it couldn’t get enough grip, and on the second and third runs it was too slow and got lost – but it didn’t hit any obstacles! So we were not docked any points and finished the round with zero points. In the end we placed equal 20th with a few other teams who had similar troubles. We stuck with our initial project goal of keeping the robot cheap (final parts cost was ~$200, compared to many teams who used a $1000 LIDAR sensor) and easy to manufacture, and made it to the final competition while meeting all project milestones. Overall this was very rewarding and the design/build/compete process was a lot of fun!