Category: Reference Posts

Posts which contain useful reference information

The Post Where I Update Everything Ever, Part II: Wubba Wubba Drive

chorl1 Comment

First, these videos must be watched before I can explain what the hell is going on:

Anyways, the arrangement of the gears in this contraption is known as a compound planetary geartrain. The idea is not unlike a harmonic drive – the difference in tooth counts between two ring gears is exploited by a rolling constrained element inside. However, unlike the harmonic drive, or the chainarmonic drive, there is no deformation element – in the case of the harmonic drive it’s the strain in the flexible spline, and in the chainarmonic drive, well, it’s a fucking chain.

Either way, the method has been in use for quite some time to get a ridiculous gear ratio in a small space – it has historically been seen in winches, bicycle hub gears, turboshaft engine output gearboxen, and apparently also automotive power mirror adjusters as the Wikipedia image shows. It’s also the secret of how the 2.007 kit motors, the BO-P5 and BO-P6, drop a 40:1 and 120:1 respectively in two stages of gearing, if you even count the output ring gear as a “stage”. Normal planetary gearboxes are hard pressed to get 7 or 8:1 in one stage, and that is with the sun gears being tiny and comparatively fragile.

But what is the actual gear ratio of a compound planetary geartrain of the type shown in the Wiki table of planetary gearbox arrangements, row 4 column 3? I’ll drop it here in case Wikipedia ever disappears or that page gets troll edited:

where blue indicates a driving element, green and cyan indicating small and large idler gears respectively, and red indicates a driven (output) element. Black indicates a fixed element. As can be observed from the diagram, this is the classical ‘compound planetary’ arrangement of a fixed ring gear, rotating ring gear, sun gear, and two idlers of different tooth counts.

…or is it? I spent a while staring at this trying to figure out why the blue carrier stick was…. well, blue. I decided that this must have been a graphical error – if the carrier were forced to rotate with the sun gear at the same speed, there would never be dependent rotation of the planets at all. However, there was another arrangement which lacked a graphical error and seemed more plausible at the time, and it is row 5, column 4:

This is a strange illustration for sure. I’m not sure why the wikipedia editors chose to make a strange arrangement of bevel gears which nobody in their right mind would actually try to build – I’ll chalk this one up to Wikipedia being crowdsourced. But topologically speaking, this is equivalent to the former diagram. The blue input sun interfaces directly with the cyan idler which is constrained to the fixed ring gear, and mechanically locked to the green idler, which drives the output gear. So why was one including an extra factor of 1 + (z_fixed / z_driving)? That expression, 1 + (z_fixed/z_driving) is exactly the ratio of a single stage conventional planetary with carrier output.

I wasn’t sure which one was wrong or right, so I decided to try out both in Inventor using rotational mates and the model of the first (104:1) gearbox. The result clearly showed that it is in fact the former, which really says that the diagram is wrong because it indicates the blue carrier stick as being rotationally driven. In actuality, the carrier just holds the idler gears and should ideally not experience torque. What this experiment told me was that if I used a conventional sun gear input and fixed ring for the first stage, the compound planetary ratio of ( [z_small_idler * z_fixed] / [z_large_idler * z_output] ) is multiplied by a further conventional planetary gear ratio of 1 + (z_fixed / z_driving) …even though it superficially looks like division – the compound ratio is 1 – (something close to 1), resulting in a very small number, further multiplied by a 1 / (large number, the conventional planetary gear ratio) resulting in a number smaller still.

This means either I am misunderstanding the distinctions between the two diagrams, or that they’re wrong. I’m not quite confident enough to say the latter, but regardless they’re really, really wack, bro.

Empirically, then, the ratio is confirmed to be of the form 1-(z_small_idler * z_fixed)/(z_large_idler * z_output ) /  1+( z_fixed / z_driving) for tooth count z.

I now present converse method of determining the gear ratio from Shane Colton, who can put up with infinitely more math and basic mechanical physics than I can:

This is pretty much all going up because we determined that about a year from now that entire conversation about compound planetary gearbox design will have been forgotten and therefore have to be rediscovered. Now, I definitely don’t want to go through all of that again, so I will say that the speed equation on the bottom left, of the same form as the Wikipedia equation, can be algebraically transformed into the torque expression in the top right (appropriately inverted to change to speed instead of torque). It’s missing something, though, namely anything involving the fixed ring gear.

Right away, it can be seen that R5, the diameter of the fixed ring gear, can be eliminated as a design input, reducing the system to four degrees of freedom. This is because the ring gear is assumed to be as large as the sun plus a plant – in other words, R1 (sun) + 2 * R4 (first stage, larger planet)… From a pure radius equivalency perspective, this makes sense. If these were pitch circles of gears, then the ring gear would have to be exactly one sun radius plus one planet diameter.

Therefore we define the Soft Rule as follows: The ring gear pitch diameter must be one sun pitch radius plus one planet pitch diameter. From a tooth count perspective, this means the ring gear tooth count must equal the sun gear tooth count plus 2 * first stage planet gear tooth count – or concisely, Z_s + 2 * Z_p1 = Z_r where p1 is the first stage planet (previously called z_large_idler). If soft rule is obeyed, then you only select the sun tooth count, planet tooth counts, and output ring tooth count: four degrees of freedom. Why is it called “soft rule”? Because…. yeah.

The speed ratio with 4 degrees of freedom is then 1-(Z_p2 / Z_p1) / 2*(Z_r2 / Z_s) where r2 is the second stage output ring gear.

However, there is another dependency which can be eliminated in order to simplify ratio selection even further. Let the radius of the output ring (R2) equal the radius of the sun (R1) plus the radius of each planet (R3 + R4). From a tooth count perspective this is Z_r2 = Z_s + Z_p1 + Z_p2. Geometrically, this is saying that the difference in tooth count between the ring gears is the same as the difference in tooth count between the planets, which must be true if the planets ride on the same idler axle.

If this constraint is allowed, then the speed equation above reduces further to 1-(Z_p2 / Z_p1) /  (2 + [2*(Z_p1 + Z_p2)/Z_s1]) and only has three degrees of freedom: the sun and two planets.

We now have three different expressions for the speed ratio of a compound planetary gearbox with conventional first stage planetary input:

  1. 1-(Z_p2 * Z_r1)/(Z_p1 * Z_r2 ) /  (1+[ Z_r1 / Z_s])
  2. 1-(Z_p2 / Z_p1) / 2*(Z_r2 / Z_s) for dependent first stage ring gear
  3. 1-(Z_p2 / Z_p1) /  (2 + [2*(Z_p1 + Z_p2)/Z_s1]) for dependent first stage and output ring gears.

With this example of Wubba Wubba Drive, I can check if they are all equivalent:

In this example:

Z_s = 12,

Z_p1 = 20,

Z_p2 = 16,

Z_r1 = 52,

Z_r2 = 48.

For the first expression, the result is (1 – (16*52)/(20*48)) / (1 + (52/12)) =  0.025 or 40:1

For the second expression, the result is (1 – (16/20) / 2*(48 / 12) = 0.025, or also 40:1.

Finally, for the third expression, the result is (1 – (16/20) / (2 + (2*(16 + 20)/12)) = 0.025.

So all you really need to pick, if there are no other hard constraints on the ring gear size, the tooth counts of only the sun gear and the two planet gears. However, this is still all assuming just one planetary gear. Clearly, any weird combination of teeth can be done with just one planet, but generally planetary geartains have multiple (minimum 2, usually 3 or 5). In this case, the gear tooth counts would be limited to those which make sense and do not force the teeth to “elastically compensate”. This includes the usual design constraints such as the ring and sun must all share a common denominator that is the number of planets (for a rotationally symmetric box… you can totally fudge it like the Tamiya planetary gearbox’s second stage (yellow gears) and have the gears not totally symmetric – can you unsee it now?!). For two-planet systems, the constraint is pretty loose.

It also turns out that this compound planetary gearbox layout is not the most efficient design possible. The whole concept of relative/differential gearing, and harmonic drives, relies on wedging action and leverage, so they are as a whole not the most efficient possible power transmission method for a given ratio. If the planets are small relative to the ring gears, there is significantly more wedging action under load and the associated loss due to increased sliding friction. This somewhat old school but excellent writeup (Thanks Dale!) explains how efficiency for such a gearbox can be calculated. In fact, the example design doesn’t have a sun gear at all – the power is input directly to the planetary carrier, there is only one planet gear set, and a counterweight on the carrier keeps the system in balance.

This makes me think that 1. The weird bevel gear thing on Wikipedia isn’t crazy after all, just drawn strangely, and 2. The first diagram with the blue carrier stick is entirely wrong, especially because

…these two are right next to eachother, and they have the same gear ratio. The fuck is going on?

Anyways, what will I use Wubba Wubba Drive for? Well, it’s already been partially given away by the giant steel serrated knocker thing hanging off the second model. But, before I give more details on what contraption it’s going on, I’m going to design the rest of it first. Stay tuned for more wubbing.

In the Interest of Future Flying Objects: XBypass

chorl12 Comments

Despite losing the Spruce Goose of Quadrotors to an unfortunate semi-controlled flight into terrain where I was the terrain (from which I’m still recovering… the square area of skin has recovered by more than 75%), I haven’t quite given up on the prospect of building a flying thing yet – but for now, they will be smaller and more easily batted from the sky. For instance, I’ve figured out why Ballcopter never worked properly. The very last update left it in a state of limbo, which I can sum up in one sentence: No, it didn’t work, but more on that later.

Eventually, Ballcopter was scrapped as its foam structure was slowly eroded away by virtue of existing in MITERS.

But there will be a day.

In the mean time, I wanted to satisfy one of my persistent self-stabilizing-flying-thing itches: how to pass control inputs from a handheld  radio to the flying thing in question without having it process several consecutive servo pulse lengths. For the most common & simplest Arduino-compatible balancing algorithms, this limits the maximum control update frequency to 50hz, since the microcontroller has to actually measure 10 milliseconds of pulse commands (for, say, up to 5 or 6 channels) out of every 20 milliseconds. The remaining time is often taken up by software floating point multiplication and division.

The reason it takes so much of the loop time is because the abomination that is Arduino’s pulseIn() command. It’s a “busy wait” loop that sits and increments a counter while the pulse is being detected. It’s neither interrupt based nor uses the hardware timers (the loop is timed empirically). So while taking in a servo pulsewidth, the microcontroller can literally do nothing else. A little inefficient, in my mind.

More sophisticated ATmega based flight controllers like the Ardupilot use the chip’s hardware timers and internally generated interrupts. For instance, as far as I can tell in the Ardupilot, Timer 1 is constantly running (counting) and overflowing (resetting to count more), and pin change interrupts on the input pins are used to capture snapshots of the counter status, and the resultant pulse width is just the difference between the values when the pin changed from low to high (pulse started) and from high to low again (pulse ended). And if the counter overflowed while the pulse was high, no problem: just add the max possible value of the counter to the pulse width variable and keep counting. Yes, I spent a few hours reading Ardupilot source code to figure that out.

And no, I’m not going to steal it and use it, because it’s written all in straight Atmel C, and so it might as well be gibberish to me. I can read and  understand it, but hell if I’m going to write it.

One method around the onboard servo processing problem is completely bypassing hobby radios as an interface medium, which people often do with joysticks (with or without tethering to a computer). For example, there is the Arbotix Commander, which is essentially an XBee and Arduino in a completely unergonomic, overpriced package which seems to have functionality problems based on a few reports from my peers – I had the displeasure of dealing with the first version personally. Shane tethers his USB Playstation controller to a laptop, but that means the laptop has to be deployed whenever something has to be operated (The upside is infinite debugging and telemetry ability, which a plain R/C radio doesn’t give you).

So really what I would like is the ability to replace the transmitter-air-receiver-servo_pulses interface with something much more direct – like serial over wireless; something that just takes the transmitter inputs and pipes them directly to my vehicle, where it can be buffered and read at will. XBees make the serial over wireless problem very easy to solve. The result would be an XBee using a cheap R/C radio as a brainless “trainer box”: most radios have a “trainer port” over which servo pulses can be sent (over a cable) to a master radio, for situations like when you’re actually training someone who is utterly clueless about flying things (me) and want to take command of the vehicle if anything bad should happen. If this pulsetrain is read and parsed at the transmitter, then I effectively offload the overhead of processing servo pulses from the vehicle – allowing it to process much faster (hundreds or thousands of Hz) and making closed loop control less granular. My inputs would still be updated at 50hz, of course, but I doubt I can react to an event as fast as 0.02 seconds anyway. The vehicle can keep itself stable much faster.

…

Anyways, that’s exactly what I built. An Arduino Nano, reading the pulsetrain from a transmitter trainer port, and piping the read values as bytes over to an XBee.

It’s not nearly as epic as I made it seem to be, seriously.

I have two cheap 2.4ghz transmitters, one of which I got ages ago for Cold Arbor, and another one I picked up over the summer for Ballcopter. Which really means I have 2 of the same radio. They are both made by FlySky, but the right one is a Hobbyking rebadge. These things cost $28 brand new, with receiver, and some of the consequences of that cheapness show through – for instance, they don’t come with external servo reversing switches like every other radio, but the holes and pads are present internally to use them and if you mount your own switches the functionality is even there in the microcontroller, but no we will absolutely not spent 20 more cents to install those damned switches.  They have a 4-pin mini-DIN (also known as S-Video) connector on the back which is a trainer port.  And as usual with small Chinese gadgets, there is a community devoted to hacking them. It took me all of 10 seconds of Googling to find the pinout of that trainer port.

A little scope probing of pin 1:


The PPM pulsetrain


And zoomed in further.

The biggest difference between this “PPM” signal and the servo-style “PWM” (which isn’t even “PWM” but pulse-duration modulation… which collection of idiots agreed on these terms?) is that

  • It is falling edge driven – the time between falling edges of the square wave is actually the duration of the “PWM” pulse. When the receiver detects one of these falling edges, it will stop outputting the pulse on one channel and immediately start it on the next.
  • As a result, the actual “High” time of the pulse only goes between approx. 600 to 1600 microseconds on my radio
  • The low time is fixed duration at 400us. Makes sense – the minimum pulse lengths on the servo side, then is roughly 1000 to 2000us as it should be.
  • It “idles high” – meaning the gap between signal is +5v.

So I’d have to come up with a way to distinguish a signal pulse from the long idle pulse. Arduino’s pulseIn() doesn’t even allow in-pulse timeouts. It allows pre-detection timeouts, so you don’t wait forever for a pulse if it never comes, but it does not have “hey, this pulse is over the length I care about… let’s move on with life”. I’d have to get around this by throwing away the first update and “syncing” to the rest of the pulses, since I know how many there are and about how long they should be.

The first step of the hardware hacking was disabling the internal radio. As I found out while building the Deathcopter, 2.4ghz radios will tend to step on eachother. I didn’t want to permanently take this radio module out, however. Leaving myself the chance to return this radio to ‘normal’ duty if I ever figured out something better, I just added a pin header connection to the power supply wire. It would be left disconnected when I’m using my hack.

Next was throwing the hardware together on a perfboard. This little arrangement costs way more than the transmitter ($17-34 for an Arduino Nano and $22-25 for an XBee regular 1mW), so I really hope this isn’t the terminal solution. It’s also way underutilizing the Arduino right now, since I only have Tx and Rx pins connected, and one other digital pin hooked up to the PPM output. The transmitter provides 5 volts from the trainer port, so this board has no other power supply.

The XBee is mounted on an Adafruit XBee Adapter.

And that’s it.

Yeah, I didn’t even bother trying to source a 4-miniDIN for this. At least, not until my Digikey order arrives – until then, it’s wires jammed into sockets.

I took a few minutes hours to write the single pin read, serial write software for the Nano. The hard part was, again, thinking my code does one thing but really having it do something different – just logic errors, all caused by having to differentiate the long idle pulse from the servo pulses. But at the end of it:

There we go. I’m only piping back 5 channels out of 6 here, but this was successfully done over the air between 2 XBees. This is all done using Serial.print(), which converts everything to ASCII and thus has unnecessary overhead. When commanding a vehicle, I’d just send the raw byte values because I’m fairly sure my vehicles are not literate.

So how do I test this contraption? With someone elses’s flying object, of course.

4pcb became the subject of a few transmission tests and a whole lot of floor whomping, as seen in the test video:

While not the most economical option, it does work, and it does solve the problem I wanted to solve. I’ll probably look to refine this board or permanently mounting it inside the transmitter, possibly with a plain ATmega chip by itself so I at least don’t have to buy even more Arduini. Otherwise, creating a dongle using Arduino USB host shields and an XBee would open the floor up to using just about any gamepad or joystick as a remote.

The “XBypass” sketche as used on 4pcb is here. The general idea was to wait for the first time the 9ms long timing pulse was received, then immediately start taking in n channels, storing them, and then processing them into single-byte values (for transmission convenience as well as because 4pcb takes such single byte commands).