Archive for the 'Roll Cake' Category


Brushless Hipsterism Intensifies: Returning to Brushless Rage. Brushless Mini-Rage!? And Trying Hub Motor Drive in a Beetleweight

May 12, 2017 in Motor Controllers, Reference Posts, Roll Cake

Oh, Brushless Rage… how far you’ve fallen. It’s been standing idle since late last year when I got the first version running. Thereafter, it began having some rather obdurate power supply problems that I couldn’t resolve with a few different attempts, and with #season3 still unknown (TO. THIS. DAY. UUUUUUGGGGGGGGGGGH.) and having to pick up and move shops, I lost motivation. Now, with the spring and summer silly go-kart season coming up, me really wanting to pregame getting Overhaul back in shape ( *cries deeply* ), and my comrades over at Robot Wars screaming for assistance, it’s time to put my robes and wizard hat again.

The last time I really worked on Brushless Rage was in October. After tuning out the first one, I went ahead and made a 2nd one. I wanted to get Sadbot running on them for a few test drives.

Here’s my innovative housing for the two controller! Bolted back-to-back with drilled holes in the Ragebridge shipping box.

And that was all! It was retained by a few zip ties running through the bottom ‘breadboard’ baseplate. I didn’t take much test video of Sadbot running on them, unfortunately;really the only one that exists within easy reach is, uhh, this one. While it doesn’t show them getting whipped, they definitely don’t not work! Yay!

But not for long. I soon lost both of the units in further off-bot tuning of settings. They didn’t blow up, but simply failed to ever power on, with the LM5017 regulator simply sitting there getting hot. The only “fix” was replacing the regulator, and I say “fix” because that really didn’t fix anything, and they would die again within minutes or even seconds.

No problem… maybe it’s just an issue with the two boards. I’ll just try another one of the five total I ended up making….

Nope. Nothing. They died one by one, all to the same symptom. I tried redoing my math for the regulator for the 4th time, thinking maybe  I made a mistake somewhere. I even tried mimicking the reference design to try and get something running. I literally never do that.

At this point, I figured it must have been something incredibly dumb and simple I missed. But why would the first two have worked at all, even for a little while?! Convinced the solution might just suddenly invent itself, I stopped thinking about it.

And so here we are, a few weeks ago, when I’m slowly building up a new rev of the logic board that fixes up some trace routing problems and Little Blue Wire problems. Again, the logic regulators kept exploding, some times dramatically taking out the input trace like seen above. The little light is strapped across the 15V gate drive supply to give me a visual indication of it being on.

What is with me and being unable to use switching regulators!? I recalled the Ragebridge Diode Debacle of 2015, and decided to take one last Hail Mary run through the datasheet along with friends to carefully cross-check each other for boneheaded mistakes and…….

TI, you assholes.

So here’s what’s going on. The Vcc pin of this chip allows you to power it from its own output voltage, which is often fairly low, so it prevents a lot of heat dissipation in the chip since otherwise it would have to derive its own power from the voltage input (up to 95V). But what I missed is this only works up to 13 volts. My gate drive supplies were 15 volts by design.

Beyond that? Who knows?! It might work, it might not. I’m guessing my first two were just high enough in manufacturing overhead that they worked for a little while. Subsequent statistics were not on my side.

Okay, whatever. I cut off the 11.3kohm feedback resistor and threw on a 9.1kohm to drop the voltage from 15V to about 12.5V and let’s see what happens.

Ah, it wakes right up.

Of course it does.

So I decided to respec the gate drive for 12.5V. Why do this instead of go for the full 15+ volts? Because I’m really aiming to make this design work at high-for-robots voltages of 36-48v, possibly up to 60V nominal with a different power stage, so I’d like to save the power dissipation in the chip’s onboard logic power supply.

The change in drive voltage will slightly affect the drive characteristics and switching time. For now, I’ll keep all the power stage parts unchanged, but I’ll probably tune the gate resistor values later.


To get rid of the noisy ripples on the feedback network and to stabilize the switching frequency, I added some more bypass capacitance to the chip. This was not included in the design at first, since I figured my large ceramic input and output caps were nearby, but it really really wants its own little private capacitor on Vcc. Gee, I thought I was a princess at times.

So now this thing is pretty much bombproof. Here’s a video of it throwing around one of the 30-pound old MIT CityCar prototype motors (which I inherited 4 of after the project was dismantled):

In that video, it’s running from 36 volts. I tested it with a smaller motor all the way up to 50V input before getting too scared for my power supply’s life; I’ll need to try it on a larger high-for-robots voltage power system later, but nothing smelled imminently unhappy!

With the regulator death issue apparently behind me (again) I decided to push another board revision. This time, I added all the necessary bypass caps and changed the layout of the logic power supply, as well as take out some parts I decided were superfluous.

The logic power supply got a little smaller and more electrically optimal. The whole thing is just less messy now. I like it – it takes up around 1/3rd square inch of PCB space on one side. At the behest of a professional PCB engineer friend, I turned the inductor 90 degrees and joined it with the LM5017′s switching node with a small trace instead of a larger groundplane. This would prevent the switching node (a source of huge voltage swings in microsecond timescales) from broadcasting as much noise.

Besides some other minor trace chasing, what’s going on down below on the board is also something experimental:

That there is a bidirectional optoisoated I2C bus for transmitting data between two microcontrollers which should never meet directly. I had a single-direction opto input on the board revisions so far, but this prevents updating of settings via the SimonK/BLHeli type bootloaders. That means tuning the settings require busting out my chip socket every time, which is annoying. I reviewed a couple of bidirectionally isolated bus schematics and decided to try this one out first, since it involved diodes only, not transistors.

The problem is, the I2C bus is a open-drain configuration with pullup resistors and ’1′ bits transmitted by pulling the line down to 0v. I kind of wanted to try keeping the opposite polarity, so to speak (even though SimonK supports an inverted input setting) just because I’m used to thinking about things this way. So I tried flipping the circuit over…. pullup resistors became pulldowns, and common-emitter became common-collector, and so on.

It makes sense in my head, but I’m sure excited to see this work!

On the board, this is the layout. It doesn’t consume much more space than my previous 1-direction optocoupler setup, and can be bypassed for testing with 2 wires if needed. That’s the nice thing about keeping things upright signal-wise.

So before I sent this board revision out, I stopped for a moment to think who would really be wanting to use Brushless Rage. I’d designed the 12-FET board to effectively replace Overhaul’s 250A DLUX controllers (with more realistic ratings, mind you). I’d say the majority of people who would buy such a thing won’t be running motors that big.

Recently, the thought of a “Half-Rage” has been coming up in my mind as something worth pursuing. This would be a board with about half the footprint of a RageBridge 2 and supporting about 1/2 of the amperage. As some curious question-askers had innocently drilled into my mind, this would be an Actually More 30lber-Sized controller.

> mfw "When are you going to make a 30lber/12lber version of RageBridge?


With this in mind, I decided to make a copy of the power stage and began downsizing the hell out of it.

Step 1: Reap what I sow when it comes to the sheer number of vias I deposited under the FETs.

After bunching the FETs together, I referenced one of the earlier abandoned Brushless Rage layout ideas for the output wires. This board is now short enough that I’m comfortable pulling the phase outputs all the way to the right with the power. Keeping all my wires on one side is something I prefer.

Somewhat final routing of the fat bus traces here. I had to move a few gate drive traces, as there was no longer an opportunity to swap sides in the middle of the FET bank. Power+ runs straight from the bottom right corner, through the bus capacitors, into the high-side FET. Power- emerges from the current shunts and then has 3 paths to return to the buscaps before being slurped up by by the wire hole on the upper right.

Here’s an overlay of the signal board design on the power stage, showing roughly the size of things. The final power stage is 2″ x 2.75″. Not the tiniest thing, but I have more capacitors than you!

This board shares a lot of thermal characteristics with RageBridge, so I’m pretty comfortable calling this a 50A continuous class controller. 50 real under-partial-throttle amps, so that’s what, like 1,200 Hobbyking Amps?

In all likelihood, this controller will be able to handle an average 63mm SK3 motor in continuous duty applications like a silly go-kart. Robot-wise, it will probably be stressed handling the same in bidirectional drive mode.

Fast forward a few days and….

OhmygoditssocuteIjustwanttohugit and then make it run a 80mm outrunner on 12S violently. I’ve ordered parts to make a handful of these, and two are going on Sadbot ASAP to be driven until something blows up!

Direct Outrunner Hub Drive for Your Little Bot

Next up, something even smaller!

So I’ve long been a connoisseur of fine handcrafted hub motors. I got curious recently on using direct-drive small outrunner motors in an ant or beetle after thinking a while on the redesign of Roll Cake. Version 1 of Roll Cake was honestly just a braindump of a vision I’ve had for years for the shape of the bot, and everythng else came second to that. On the beetle scale, the multi-pulley serpentine pulley drivetrain simply had too much friction for the Fingertech motors (which were severely underpowered for the task) to overcome.

For the next version, I’m ditching the triangular cheese wedge shape for something more straightfoward. The cheese wedge will be back for a heavier weight class. Roll Cake’s design really wants to have the middle of the bot kept clear for the flipper linkage. I’m sure I could work around it with low-mounted drive motors and similar, but this was an excuse to play with brushless things!

I based my thoughts off Jamison’s mini-gimbalbot which used camera gimbal motors for drive with a small Hobbyking R/C car ESC. It drove “okay”, certainly capable of a weapon delivery platform. So naturally, I wanted to put some SimonK-capable controllers on it and see how the handling would change. I got a small selection of motors: A pair of DYS and Quanum 28mm motors as well as a pair of Multistar “HV” 460kv motors. 460 RPM/V is reeeeeally slow for that size of motor that isn’t a gimbal motor, so I was quite interested in them.

These are the gimbal motors. I like them for their pancakeyness – the Quanum motor is more 30mm and has a bigger stator.

Playing around in the CAD model a little for component placement. At this point was when I realized Roll Cake in this incarnation might end up looking a lot like The Dentist :P

I designed up a few hubs that bolt to the face of the motors and have a tapped middle hole to sandwich a wheel. The wheels are spare 1.625″ BaneBots wheels that I originally bought for Candy Paint & Gold Teeth.

Shown with those motors is a ZTW Spider 18A controller. My typical SimonK ESCs, the Afro series, were out of stock when I placed this order, so I took recommendations from people on what I should use. The Spider series are fairly popular these days among small bot folks.

The issue is, they come with BLHeli firmware, the other other open source drone racing / vaping rig development path. It’s a newer effor than SimonK and has a more polished interface. I’d read about it before, but not worked with personally. Other builders have said it doesn’t run robot drivetrains as well due to being much more optimized for propellers. So hell, why not – this was a chance to explore that side of things.

Here’s some real life CAD layout, featuring the Multistar motors.

I really wanted to use the gimbal motors, but they disappointed me in bench testing sufficiently that I didn’t even end up installing them. Basically, they can’t draw enough current to make torque at typicall little-bot voltages. With phase resistances of 10-20 ohms, they can really only draw ~ 1amp or so. I mounted one in a vise and could stop the motor with my pinky finger at full radio stick input.

These motors might be better at 6S and up, but for the time being, since all of my small-bot batteries are 3S, I decided to pursue making a test platform using the Multistar 460kv motors.


The platform of choice was…… one of Candy Paint’s spare weapon pulleys. I literally spilled my “preformed robot spares” bin on the ground and tried to see what was good to use as a base. Hey, it’s round and has convenient wheel holes in it already! All I needed to do was quickly whip up some motor mounts (3D printed) and I was in business.


Here’s everything hooked up. That nut is for a counterweight on the front to add some friction against the ground while turning. Otherwise, it had a tendency to keep spinning and spinning if you even thought about turning.

Communicating with the ZTW Spiders was a hell of an adventure in its own right, and I am putting this post under Reference Posts because I’m 99% I will need it again or someone else will randomly find it while needing the information. If there was any industry that continually pisses me off with how undocumented and tribal-knowledge focused it is, it’s the R/C anything industry.

So, here’s how everything went down. I lost my AfroESC USB communicator, so I purchased the Spider SPLinker advertised as working with the controllers. I also bought one of these stupid things:

That’s a “SimonK/BLHeli compatible” dongle called the ESCLinker. It allegedly can talk to either kind of ESC, but there was nothing remotely resembling a manual or operating guide; all of the search results for this brilliant device were people complaining that there was no manual.

So I’m writing the manual now: This thing does not want to talk to KKMulticopter Tool (my go-to for flashing SimonK ESCs). It will only talk to BLHeli Suite. As a matter of fact, I couldn’t get the Spider SPLinker to talk to ANYTHING. For all of my tuning here on, I used the ESCLinker tool.

Here is BLHeli Suite, which is hosted on the sketchiest possible website that is one tier above compiling it from the Git repository yourself.

Notice how I’m connected to the ZTW Spider now. The ESCLinker (and SPLinker) install as virtual COM ports.  The necessary baud rate is 38400 baud, not 19200 (Afro/Turnigy USB dongles, to my knowledge)

By the way, once I realized this, I tried to talk to the SPLinker and ESCLinker on KKMulticopter Tool again using 38400 baud; no dice.

Further investigation revealed that the ESCLinker needs these options to communicate to the ESC – both options 2 and 3 will work. So if you’re listening, people mystified by the ESCLinker: Talk to it on 38400 Baud and ask it to communicate to your ESCs with BLHeli/SimonK 4-way-if bootlader.

Ugh. One of my selfish reasons for wanting Brushless Rage is so it’s one known quantity and I never have to dick around with other people’s open-source bullshit again.

So with all that behind me, I decided to try out BLHeli drive on the little pulleybot. I went with intuitive settings based on my SimonK advice, which included “Damped Light” mode, a fancy euphemism for synchronous rectification/complementary PWM, medium to low timing and maximum start power. BLHeli also has a “demag compensation” feature which appears to delay commutation to compensate for current decay in the windings. Who knows!? I wasn’t given the imprssion that its users actually understood what it meant, nor does the manual really say anything useful.

I found that Demag Compensation turned all the way up gave the best performance, along with maximum start power. However’ it still couldn’t compare with my SimonK experience. It seems like even maximum start power is much weaker than what SimonK permits you to do.

Here’s the final test drive I made with the BLHeli Spider ZTWs:

I’m honestly not very impressed. I think BLheli is very much optimized towards multirotors and helicopters (hmm, maybe it’s even called BrushLessHeli for a reason!) and the settings are more high-level and mask the underlying mechanicals of the firmware. I think this makes it much more accessible to hobbyists, though. In the end, I’m not very enamored by it.

These were my final settings:

For a direct comparison, I decided to replace the ESCs with my old SimonK Afro 30 amp units. These have been on quite a few bots now, starting with the original Stance Stance Revolution, and they were completely beat up. But they still worked!

A direct replacement into the existing wiring harness later… we have SimonK!

I found myself in the awkward position of using KKMulticopter Tool to compile a customized SimonK formware, then uploading it via BLHeli Suite because my USB dongles didn’t talk to KKMulticopter Tool; I’d lost my AfroESC USB dongle a long time ago.  BLHeliSuite doesn’t seem to have a firmware editor window that I’ve found yet.

Here it is. I found the SimonK version so much more responsive that I actually needed more counterweight on the front. So, a non-fitting bolt gets zip tied to the nut! Now the bot’s a lot more controllable:

I like it a lot. It might even be worth doing 4WD to give me more yaw damping, or I’d have to design the bot to be well balanced enough on front skids, or something. I used my typical SimonK parameters: complementary PWM, maximum braking power, maximum braking ramp speed, and adjusted start PWM limits to something like 50%.

I’m aiming to get Roll Cake and maybe Colsonbot running for this year’s MomoCon in a couple of weeks, so hopefully I’ll post up some design news soon!


Baking the Roll Cake, and How I Failed to Save Private Überclocker This Time: The Dragon Con 2016 Adventures

Sep 11, 2016 in Bots, Events, mikuvan, Roll Cake, Überclocker 4

Oh hello everybody! It’s a few days after Dragon Con and I’ve finally woken back up. Where the hell am I?! What is this metallic coating all over my face? Why have I gained 20 delicious pounds?

Here it is, the Post Dragon Con 2016 recap. I didn’t get a change to put out another update before leaving for Atlanta, and then it was a mad pre-convention dash. So this update will cover all of the construction of Roll Cake, as well as get started on the Bot that Charles Forgot – Überclocker 4.0, a.k.a “I Can’t Believe It’s Not Overhaul!”.

Amazingly enough, there were no van shenanigans on the way down. I’m staying in Atlanta a few days later again, so the return trip is still clouded in the ether, but at this time (Boston to Atlanta and now a few hundred miles locally) there are no issues to report.

Alright, I lied a little – at some point a few weeks (months???) ago, the rearmost portion of the exhaust pipe decided to fall off. It had a hanger at the very back of the frame, so did not fall completely off, but just rattled haplessly.

I think it was due to the bend passing over the rear axle being repeatedly struck by said axle when Mikuvan is loaded heavy – such as the trip to Detroit Maker Faire. So anyway, all it manifested in was things being a little louder, but at times due to the exhaust being trapped under the body and in my 3-mile-long wake vorticies, exhaust smell would creep into the cabin. This is not something I wanted to deal with for the long trip down, so I repaired in the best WEEABOO REDNECK way possible:

None of this BEER CAN bullshit… only the best Ramune bottles will be used for MY hoodrat repairs!

This held all the way until South Carolina. When I rolled into town, one of my pre-convention stops was the local Advance Auto Parts to pick up a patch pipe. The whole system is definitely in need of replacement, though. Who wants to hook me up with D U A L   F L O W M A S T E R S?

Anyways, without further ado, here are the sections of this roman noir de robots:

  1. Finishing and testing Roll Cake
  2. Designing and building Überclocker 4
  3. Robot Battles and Dragon Con recap


Icing on the Roll Cake

So this is where we build up to that ‘preview picture’ I posted last time.  One of the first things I did as soon as I put the frame pieces printing on the Mark Two was go and do basically the only machining thing, which was make the drum.

For this, I brought back an old friend. One of my first major tool purchases was this little indexing head, which made its first appearance here in a LOLioKart build report. It became my most prized possession for some time thereafter, but I left it in the shop when I mostly scuttled off to main campus and upstairs into the IDC for graduate school nonsense. With my departure, it began becoming decrepit under usage by random newbies. One of the dividing plates was lost, and one of the tilting locks was also lost after someone cranked the locking bolt too tight and sheared it off.

Every once in a while, someone does find it again and use it, so I knew it was still operational. I gave it a once-over cleanup and adjustment before starting here.

The drum blank was carved out on New MITERlathe before being transferred to the indexing head for feature drilling. I originally specified 6 bolt holes. But as it turns out, 8 holes is easier to use the indexer for, since it didn’t involve going in partial circles using the dividing plates. Just 5 cranks of the handle… So, 8 holes it is.

Next up, putting the big 1/2″-13 threads in for the cap screw “teeth”.

One tricky operation was broaching the 8mm bore for a 2mm keyway. Since Roll Cake is being built from Banebots P80 parts, so it must be compatible with an 8mm keyed shaft. I could not get a 8mm bushing & 2mm broach in time – nor did i want to spent dozens of dollars for the honor. So I did what, I guess, I would do, and carefully hacked at it with a 1/16″ endmill until I got a 2mm slot with a bit of radius at the end.

Precision! Craftsmanship! Finesse! We strive to be the opposite of this at Big Chuck’s Robot Warehouse. Zero sigmas, guaranteed, or I’m keeping your damn money anyway.


The frame parts have finished printing from the new Onyx material!

Well, hold up a little… These are extremely hollow prints that were solely to test for dimensional correctness. Things like “Does the motor fit in this hole?” and similar.

Here is a mock fit with some of the parts. I used a paint marker to pinpoint locations which needed rework – generally increasing slop or tolerances in the CAD model to get a better fit in real life.

Another arrangement of “DO NOT USE THESE FOR REAL” parts, which all had X marked on them so I was not tempted.

The two main frame halves are actually made from regular nylon for the most part, with carbon fiber loops in the center of the bot to strengthen the area. Otherwise, the regular nylon is tough and a bit flexible, which will hopefully help against some impacts.

A little pile of wheels with grommet-tires installed…

I next synthesized these planet gears from spare P80 4:1 and 3:1 planet gears. The 4:1 gears were bored out and cut to half a normal pinion length. Then the 3:1 gears were machined down for half their length, and then promptly shoved into the 4:1 hollow half-gears. The shoving first involved lining one tooth with one valley between teeth on each gear. As mentioned in the design post, these compound gears require the correct phasing of teeth to be assembled succesfully. I was probably off by some fractions of a degree on each gear.


The ring gear itself has also been reprinted in carbon fiber back Onyx (a material we came to call RMCC – Reinforced MarkForged Carbon-Carbon). I made the number of engagement dogs lower to guarantee the servo being able to reach between them.

Assembly for realsies begins with the bolting together of the sides. On each side, three #4-40 cap screws with washers and nuts retain the sides to the center U, and at the very rear, a #4-40 threaded rod with 4 nuts provides last-ditch backup if those front fasteners fail.

The ‘flaps’ are waterjet-cut 6061 aluminum 1/16″ thick sheet, which are bent up at the edges like so:

Well, that’s how it’s supposed to work. I really need to watch some tutorials on how to use a box-and-pan metal brake correctly, because I clearly can’t do so, ever – and it probably doesn’t help that I make sheet metal parts infrequently enough that the shared machinery is never in the same condition twice (or some times working at all), so I have no clue how it’s supposed to behave. Anyways, no two bends on this thing are alike in location and alignment. One side is workable, the other side is very twisted… Oh well, we’ll fix it in post.

Time to solve the never-quite-solved wiring problem. I made access tunnel paths for the hypothetical wiring through the back end of the U-bracket that makes the center of the bot, but physically doing it was another whole issue. “Haphazard” and “ad-hoc” are two words that each don’t quite describe Roll Cake’s wiring on their own.

I basically had to make three long cables, fish them through the two wire tunnels, and then wire everything in-place at the ends and cut them to length. These cables were the main battery, left side drive motor, and firing servo cables. The right side drive motor also passed through the right tunnel, so really it was 4 cables.

For this purpose, I used the thinnest wire I could find for the drive motors, which was some 30 gauge blue wirewrapping wire.

Everything in the bot could run directly off 11.1v – the drive ESCs (VEX controllers), even the Hobbyking TR6Av2 receiver believe it or not – you can run basically every new receiver from battery voltages since they have onboard regulators for the microcontrollers. However, the firing servo still needs 5 volts to not go crazy and burn out.

Therefore, I made a super small in-line 5V regulator from two Chinese’d  LM1117 parts.

Don’t give me no “that’s racist” bullshit – you and I know this happens on a regular basis.

This 5V line then feeds the receiver, and the servo cable is a 3-pin custom cable which comes from that. Essentially as if I were to plug it in without hacking anything.

After the electronics are installed, I made the orange roundbelts and started closing everything up. The round belts are measured using the hypothetical pitch line in the belt circle drawing in the CAD model, then shortened about 10% to accommodate stretching.

The final act is to install the linkages. This is done using long M3 bolts cut down such that their unthreaded shoulder acted as the joint pin, but I could still put a locknut on the end.

Here is the finished bot from the flappy end.

And a photo from the ‘business end’.

So how does this thing work? Well, it doesn’t really.  The serpentine roundbelt drive has too much friction for the Fingertech motors to overcome. While Stance Stance Revolution used two 22:1 Fingertech motors, they were direct driving small wheels. Each pulley adds some friction, since the belts need to be tight to transmit torque and the pulleys do not have rolling bearings, just nylon on shoulder screws. Roll Cake therefore could not move at all. I’ve built some pretty damn immobile bots, but this is literally the most immobile thing I’ve ever made!

You can hear the motors strain to move, slipping on the belt, and occasionally it scoots forward a fraction of an inch. That’s about it. In doing this, I actually burned out one of my 22:1 motors.

I began making arrangements to get some 33:1 motors from fellow competitors down in Atlanta, which should help the torque problem, and also began the search for small timing belts. MXL and 2mm timing belts come in 1/8″ wide / 3mm wide, so I could redesign the pulleys to that tooth profile. Then, the matter becomes if the Mark Two can hold the kind of tolerances needed for the tooth geometry to work out. I decided to leave that to Atlanta.

While the driving test was a bust, I did get a few flipper tests in with the drum going full speed. I’m glad to say that this part seems to work great. The servo engagement is clean and predictable. Here’s a test against a roughly 3.5 pound empty toolbox. Note that I don’t have anything springy or elastic that’s preferentially loading the linkage closed, so it depends on good firing servo timing to bring it back down.

That was actually the second test. The first test was against a heavier (4.5 pound) aluminum rail – coincidentally, the unmachined blank frame rail for Uberclocker 4. On this test, the deceleration of the drum was severe enough that the bot rotated forward against the linkage… causing the drum to strike the ground and hilarity to ensue.

Well, truth be told, that was the part of the bot I cared about. I packed all of the parts up for Roll Cake anticipating needing to do some re-engineering once I was on site. Just prior to leaving, I ordered two sizes of timing belts from SDP-SI based on the existing pitch length and what was closest to it – two 155 tooth 1/8″ wide MXL belts, and two 160 tooth ones. At least one of these will be close enough after I redesign the pulleys to be timing belt profiles with roughly the same pitch circle.


Überclocker 4.0

No fake-outs with wheels this time! This is the real deal now.

I’d been MEANING to retire Clocker version 3 (Überclocker Advance) since after Motorama 2015. Then came Dragon Con 2015…and then Franklin Institute 2015. After it won handily at FI, I decided to force myself to retire it, leaving the broken actuator unrepaired. Clocker 4.0, which has no witty Engrish name, was meant to be designed much earlier in the summer, post #season2.

Well that clearly didn’t happen… I actually started working on the design on and off in mid-July, but some contract work was keeping me entertained at the time – so designing didn’t start in earnest until August. That’s one side of being “funemployed” is that the work you do pick up is often stuff you like to do, meaning you adopt it as your own, meaning certain death if you have zero time management ability like me.

The first thing I designed up was actually the custom cast wheels that I talked about last time. I decided to use Clocker 4 as a smaller-scale experiment to try out the technique and different materials without wasting a bunch of money. The wheels were made with a 3/4 hex hub, which Clocker 3 uses and which I intend to carry over to the new bot. They were made in two sizes – 3 inch and 2 inch – to reflect the needs of the new bot.

So let’s go through the design of the bot now! Keep in mind through all of this that the principal design constraint was “Is this dimension about 50% of what it would be on Overhaul 2?” and is definitely a departure from my usual tactic of letting the part placement drive the robot. In fact, you could argue that both Roll Cake and Clocker 4 represent me trying to “design to look like something first” – Roll Cake being an old robot vision from years ago, and Clocker 4 being a scale model of Overhaul.

Just like with Overhaul 2, I began with a sanity check sketch to make sure the dimensions aren’t impossible. In this picture, the only things fixed are the wheel sizes and chassis height. Much like OH2′s design phase, I was going to let the length of the frame be malleable in order to fit components. But it should end up somewhere around 30″ in the ideal case.

I focused a little more on the pontoons first. The rectangles shown are a size of wubbie that is the closest to 50% scaled down from the type used in OH2.   While their final shape and dimensions is not settled by this sketch, I just wanted to factor them in to get an idea of the size boundaries.

Bringing in more geometry into the mix now by playing with lifting fork lengths and the height of the arm towers.

Probably the terminal stage of The One Sketch has the 2.5″ square DeWut motor profiles imported, the length of the frame adjusted, and the first pass at the upper clamp arm also drawn. Most dimensions line up with OH2 within 10% or so, which is fine. Nothing truly scales directly in robotworld, and I figure so long as the visual is complete, nobody else but me will notice!

The beginnings of the 3D design went much the same way as with most of my bots,  Overhaul included, with the generation of frame rails. You have to start somewhere, so I usually start with the back or left side, and everything sort of grows off that.

I imported the One Sketch and aligned it with the bot as a reference.

Moving on ahead a little bit, here is a more complete drive side. The front wheel is inset significantly into the plane of the front endcaps which hold the rubber shock mounts. I wanted to do this to maximize the wheelbase. Previous Clockers have had the “reactive outriggers” up front to maintain front traction when an opponent gets picked up. This version is relying solely on the rubber shock mounts deflecting, and it will be riding on the front edge of the pontoons thereafter. To maximize the chances of retaining traction in that scenario, I wanted to push the front wheels as far forward as I could.

This does open up a gap in the otherwise fully constrained tab of the frame rail, so here’s hoping that spamming the region with cap screws will make up for it.

Frame rail service for Clocker will also be a little harder harder than Overhaul. In this design, to pull the left frame rail, the pontoons and three of the six shock mounts have to be removed, and there is now more than 1 bit driver size needed. However, you could argue that OH2 also needed two bit sizes – 7/32 for the pontoon screws and 5/16 for the frame bolts.

Cloning stuff to the other side…

A very difficult step came afterwards. I now had to fit the DeWuts from Clocker 3 into this frame (I SOLEMNLY PROMISE DEWUTS WILL BE BACK IN STOCK SOON) . This presented a very serious problem, which is well summarized by NO.

You see, the average Featherweight, full-contact 30lber is generally much smaller than the Sportsman class bots, since they’re built denser with thicker materials to take KE weapon impacts. Clocker 3 is very large for a 30lb bot to begin with, at 20″ wide and 27″ long end to end, it’s almost the footprint of some of the denser 250lbers like Poison Arrow.

In order to make weight, as well as stay roughly true to Overhaul’s dimensions, Clocker 4 needs to be around 16″ wide. However, this utterly precludes the use of the DeWuts. I would need to make the bot at least 18″ wide to use them. That means proportionally more weight to cover the additional width of the bot, as well as a lot of inside space that’s kind of wasted lengthwise since more components would be able to fit next to the motors. This isn’t a bad thing by itself, but two DeWuts back to back kind of forces a different shape robot than what I was pursuing.

So I began working on the inevitable: going brushless with the drivetrain to save volume. I studied a few options which all revolved around a handful of AXi motors I picked up a few months ago (get yours today!). I borrowed a BaneBots P60 model since Jamison had already played with mounting P60s to the AXi motors. I also investigated stuffing the AXi motors into my spare P80s from Overhaul.

In the name of expediency – namely, that I had the spare P80 drive motors on hand, the AXi + P80 combination won. The 4:1 Overhaul P80s combined with the AXi motors at 7S (26v) ought to give a top speed of about 17mph, which is plenty.

The downside is extra weight. While the P80 and AXi combo weighs less than the DeWut, it weighs more than the P60 equivalent which would handle the motor power just fine. For Robot Battles where I won’t need extensive armor, I figured that letting the drive motors have 2 more pounds is fine.

However, I might actually swap these out before FI 2016 for modified P60s, since having the armor weight back would be nice.

Now importing more components – the space inside the bot is filling up fast!

I devised this quickly-3D-printable-from-Onyx mounting bracket for the AXi motor. A new pinion with a 6mm bore will be crafted out of spare 4:1 planet gears, which have 4mm bores I can hollow out.

So the AXi drive will solve the issue of width in the bot. I’m now toying with placement of the internal components. To start with, I’ll be using two of the spare DLUX 160A controllers I took out of Overhaul before the Season 2 tournament began, with a possible upgrade to Brushless Rage later using a 6-FET board (think Brushless HalfRage)

I settled for the two DLUX controllers up front mounted to a (not yet modeled) non-structural interior bulkhead, and the RageBridge in the rear corner to handle lift and clamp, also with a yet-unmodeled bracket.

Let’s begin on the fork tines now. I traced out the basic shape of Overhaul’s fork, but unlike Overhaul which uses a dead (fixed) lift shaft, I’m keeping the live life shaft of Clocker 3 since it’s fairly easy to attach to. The force transmission will be using clamp shaft collars made into hubs. There won’t be a central tube structure in the fork – both will just be held together with standoffs. The forks should, like in Overhaul, never be taking direct impacts unless I messed up horribly.

After I imported the quick fork model, which is still missing specific details like standoff mounting, I also began playing with the clamp actuator. I imported a few older Clocker actuators to check size and placement.

For this edition, I really wanted to move back to a full 550 motor actuator. This should actually give the bot a clamping force of several hundred pounds, which I wanted to have since most Featherweight class bots have negligible top armor.

The issue wasn’t so much weight (it would weigh around 1 cheap drill motor) as space. It had to fit in between the side plates of the clamp arm, first of all, and then anchor itself in a useful location that won’t impede the fork travel much. Overhaul has some issues with this which I would like to remedy for #season3 – so in a way, this is once again using the small bot to pilot something for the big one.

More details have been modeled into the fork plates now. The cross holes will have standoffs like good ol’ Clocker, not just to hold the fork sides together, but keep them level between arms. Overhaul has no such crossing feature near the tip of the arms, only the base. This was the cause of the forks becoming cockeyed during the Beta match when it got a good boop in on one of them, and I’d definitely like to solve this problem.

I decided to pursue the full 550 motor actuator at all costs, so I made one similar in construction to Clocker 3′s final actuator. The motor and gearbox? Just a 12 O’Clocker spare motor! The gears will be purchased from Vex, then modified – one to a 12mm bore, the other bored out to shove an Acme nut into.

Not shown in the above image is an “anti-buckle” MarkTwo printed piece that bridges the two thin plates and cradles the leadscrew for more of its travel. The actuator sides are in tension when clamping, but will be subject to sudden compression shock if the bot lands upside-down or I try reversing out of a grab, so I didn’t want to count on JUST 1/8″ aluminum plates.

Here it is loaded in place and showing placement. The upper anchor point was open to negotiation because the clamp arm sides hadn’t been designed yet. The lower anchor point for the leadscrew will just be a pin that is shoved through the first hole in the fork side plates, closest to the pivot point. The neat thing is this is somewhat adjustable for leverage ratios if I choose to use another hole instead.

I generated the fork side plates based on the dimensions of the One Sketch. It, too, will be held together by a bunch of standoffs – no welding here. This drawing shows some possible standoff positions. I was going to alternate inside and outside circles as I moved from left to right, like so:

The standoffs used are just some big McMaster-Carr 5/8″ hex aluminum standoffs, which for some reason are almost half the price of the neighboring sizes.

Actuator placement was a compromise between “How far does the motor stick out the top?” vs. “How far does the motor stick into the grabbing region?” since I could make the leadscrew as long or short as I pleased.

About this time, I threw Clocker 3 into the CAD model. The size different is almost comical, and at this point I wondered if Clocker 4 could pick up anything at all without falling on its face. Definitely will have trouble with the average 30SC sized bot, but again, 30lb Featherweights are smaller in general.

Anyways, moving on.

One of the next mods I want to make to Overhaul is what I call the “Anti-Cobalt System” – in other words, putting something between the frame rails so this doesn’t happen again. For Overhaul, I’ve been mentally designing it as a top and bottom plate fastened together in the middle, to close off the box and transfer sideway forces more rearward in the bot.

Since Clocker will now be competing in a high-energy class, I decided to implement the ACS for the most part on the bottom of the bot. This also acts to keep the drive chains above the plate, so they’ll be less vulnerable. I could still see this having a failure mode where in a very energetic sideways hit, the frame rails will deform in a parallelogram between the ACS plate on the bottom and the angled endcap on the top.

I’m now in the stage of generating top and bottom plates as well as random spacers. MarkForged spacers for everybody!

The single tooth will be made from some left over 1/2″ AR500 steel – good enough for the task.

I began the process of making the armor pontoons using the same method as on Overhaul. I made a master 2D sketch that represents the front face, and then a series of 3D Sketches thereafter, then defined surfaces using the sketch lines as their bounds.

The geometry for Clocker 4 is a lot simpler. There are no vertical forward-facing or side-facing wubbies, just the six widely spaced ones on the angled face. In a future revision I may consider adding forward-facing ones like Overhaul, if this decision comes back to bite me.

One major difference with these? They ride a lot closer to the ground than Overhaul’s. In fact, I will most definitely have to finish-grind the bottom edge to get enough clearance to not get hung up on them.

This is a good thing, because it resolves the other weakness of Overhaul that was clear during the beta match – the pontoons were simply up too high to be helpful, being designed to take a whomping instead of be good foot-in-the-door implements.

An overhead view of the bot basically done – you can see the standoffs between each pair of fork plates, the tie bar between the forks, and the tube which acts as the anchor for the leadscrew.

I added tabs and slots the same way as on Overhaul to prepare the pontoons for cutting and welding.

Here’s the finished bot minus cat ears!

The ears don’t seem to be necessary on Clocker 4, but it just doesn’t look right, man. I will probably design a pair up to be printed in RMCC which will bolt to the topmost hole in the clamp arm.

I left design of the internal brackets as an exercise to be done in Atlanta, since by this point I was running up on the last week available for fabrication. Hot off the CAD presses and into real life we go!

Man, it’s been a LONG TIME since I’ve done a one-shot epic waterjetting session to pop out a robot. Pictured above is the “Clocker kit”… or some 10 gauge mild steel, 1/4″ 1/2″ and 3/4″ aluminum, and some 1/16″ FR-4 laminate.

Sadly, in my cruftiness, waterjetting is no longer free – this is probably around $400 of machine time.

To prevent the FR-4 from delaminating, I brought back one of my tricks of cutting the outer profile only, and using another material as a template. So here’s how this part went – I routed the parts manually to ensure it does all the interior holes first, then the outer profile.

I laid a piece of plywood in the machine first and had it cut only the holes. Then I clamped the FR-4 on top of the plywood and continued the toolpath to cut only the profile. The 1/2″ plywood pieces then become drilling templates for conventional drilling of the holes later, which otherwise might (WILL) delaminate since they’re piercing close to the edges.

While the design was slow-cooking to completion, I continued casting wheels, making 4 of each total. I’ve basically gotten this process down, so the next step is to try out different materials.

Here, I’m readying the frame rails for countersinking and counterboring. It’s built in the same style as Overhaul, and also many 30lbers and 12lbers. The frame rails will need machining to key into each other slightly too.

One of the last operations I was able to pull off before having to depart for Atlanta was the coring of the large lift gear. This was done using MITERlathe and like 5 different tools. MITERS didn’t have a spoon-type boring bar to make a plunging face cut easy, so I had to make do using a few different types of insert cutters, switching left-hand and right-hand tools to clean out the blind pocket.

Sadly, Monday the 28th of August was upon me. I actually spent more time in the week preceding finishing Roll Cake, since I cared a lot more about perfecting that mechanism, so Clocker 4 fell by the wayside. Clocker traveled to Atlanta in kit form, shown above. I needed to do some (lol) work on it in Atlanta, such as milling the frame slots, before it could be assembled.

And that’s the bot half of the story. Next, what about the convention!? I came this far for something, I think. Whatever is causing all that noise next to the robot events, dammit!

Robot Battles & Dragon Con 2016

So before we get to the convention proper, let me interject with a proud announcement that…

…I finally got pulled over for speeding.

You didn’t think it was physically possible, right?

I’d like to thank my parents, uhh… Boston area highways…. and, of course and Smooth Automotive for the Accidental Engine Rebuild of 2015 which has restored Mikuvan’s former power so much that I legitimately now can speed. I mean, it takes a little while to get there, and no hills please, but otherwise, I can cruise at 75mph all day – just enough to get in trouble in Virginia when the speed limit drops to 60mph for an upcoming work zone and I ABSOLUTELY, POSITIVELY MUST PASS THIS ONE LAST MOTHERFUCKER ON THE RIGHT HERE and… Dammit.

He got me fair and square. In fact, he didn’t even mention how I Boston’d someone immediately before the orange construction barrel forest began. So thank you in that way, Virginia State Trooper. I’m not even going to look at this ticket until I’m back in town now, because Virginia sucks.

Alright, enough of that. As I mentioned at the beginning, there were no van shenanigans to be had. I got into town around 4:30PM Wednesday, and immediately began plotting robot finishing tactics. The first order of business was getting Roll Cake its timing belt setup, which I designed quickly once I settled in and put on print. What?

Yes, I dragged the Mark Two provided by my lovely sponsor MarkForged along. Hey guys, how’s about some hot and humid weather testing?!

The SDP-SI timing belt order arrived on Thursday afternoon, so I could test the fit immediately. More importantly, though, on Thursday…

I busted into Dale‘s shop like the good ol’ days and basically took over his entire workbench. On deck were finishing some milling and turning parts for Clocker 4. I machined the axles, finished off the wheel hubs, and made the motor pinions, among other unfinished business.

The big rear chamfer for the frame rails was also cut by tilting the head of his CNC mill 30 degrees.

Friday bot work was mostly done at the GT Invention Studio. I primarily worked on Roll Cake, doing the final installation and tuning of the timing belt drive:

The pulleys were sized by how close they were to the pitch line defined in my belt loop sketch. The difference was then made up by changing the motor pulley tooth count until the tension was reasonable (just going from 21 tooth to 18 tooth in one try was enough).

This worked….. a little. Roll Cake’s movement was still extremely strained. There was no binding of the drivetrain anywhere I could see, just that there’s too many moving things for the 22:1 Fingertech motors. It moved slowly and quite arduously, and still could not turn.

Well, there wasn’t much else I could do to alleviate this problem except swap to the 33:1 gearmotors which I was able to pick up day-of MicroBattles from Mike Jeffries. Before the event started, I went ahead and did the motor transplant.

Operating sheets and all! This was so I didn’t get any abrasive/metallic grunge into the bot while cutting down the motor shafts.

The end result? I got Roll Cake to move somewhat reliably on the floor, so I went ahead and decided to put it in its first match anyway…. against Kurtis’ Black Adder.

Dammit, Kurtis.

Unfortunately, in the arena, it moved all of 18 inches or so before farting out again. It at least managed to flip Black Adder over with a chance collision. At this point, I stopped caring, since watching the mechanism test fire was more important to me than the rest of the bot, so I just kept flapping until the end.

Poor Roll Cake. It had such a bright future.


Okay, not really.

So the flipper mechanism kept working up until the end, even though I technically never got a direct shot at Black Adder.

That’s okay – I’m already out to rebuild this thing correctly such that it’s mobile. Roll Cake 2 will just have two brushless gimbal motors for drive, as hub motors, with the same Afro30 SimonK-enabled controllers driving them. It will have 2 larger wheels up front like a classic drumbot, not this 6WD business. Since Stance Stance Revolution could basically drive upside-down on its two discs, I’m much more confident in this setup working.

So that’s it for Roll Cake. Now back to your regularly scheduled Überclocker:

In the same work session as finishing out Roll Cake, I assembled all of the modules within Überclocker – the actuator, both drive motors, wheels, and the DeWut for the liftgear.

On Sunday afternoon, I returned to Dale’s shop to make a mess one more time. This time, to carve out the giant pocket that is in the back frame rail, formerly solid 6061 aluminum. Final weight estimates showed that I did need around 1.2 pounds out of the frame rail, so I calculated the pocket size needed, gave it some more oversize for weight tolerances, and went to town.

The next operation in Dale’s shop was putting some pilot holes into the end-tapped frame rails. I figured I could run with 1 bolt in each frame rail for now, and then drill them later once I had access again to a large drill press back at Artisan’s Asylum or MIT.  This let me put most of the frame together on Sunday evening.

After I went back home, I did what I could using the remains of my high school workbench, which contained a small 10″ drill press, hand drill, and jigsaw, plus the hand tools and cordless tools I brought down, and a few kibbles of tooling that I didn’t take up to Boston with me originally.

The above was…. basically all that I could do. Mount the shaft collar to the big lift gear using a counterbore I brought. I didn’t even have any clamps left, and by the time I got back home, all of the hardware stores and home improvement stores were closed for Sunday night. I tried drilling and tapping a few of the frame screws by hand, which was an arduous procedure. I basically called it quits around 6AM Monday after trying to work on putting it together all night, and not getting much further than 10 or so drilled holes.

Basically the most important part of having tools is having consistent tools. Maybe these tools were enough for me during high school, but I also built bots in completely different ways to accommodate them (e.g. making things from UHMW plastic). Designing for tools that are not consistently available, or totally unavailable, will just end in disappointment. I realized no matter what, I could only hack Clocker so far in the remnants of my parents’ garage if it depended on a full service shop to be put together.

So here is the assembled husk of Clocker 4 next Overhaul at Robot Battles on Monday, showing what could have been if I didn’t kick my own ass… or as Will Bales puts it, Will Balesing.

By the way, shoutouts to Matt and Dan of Chaos Corps for taking the pieces of the pontoons from me on Friday and returning them completely welded on Saturday. Not just welded, but all ground and wire brushed. I owe you guys a small water balloon filled with argon!

But wait! The story doesn’t end there!

I also brought 12 O’Clocker along, figuring that I’d be able to run something in the Monday event at least. 12 O’Clocker was working fine after Momocon, so I basically packed it right back up with some spare motors. The clamp motor on it was a little baked, so I reached out to the group for spare Kitbots/1000rpm-style motors.

It actually got a few matches in and entertained the audience immensely.

In the rumble, the lift sprocket got bent hard enough to pop the lift chain off. Otherwise, 12 O’Clocker takes no damage once again! Gosh, maybe I should just scale this thing UP instead of Overhaul DOWN, right?

So no prizes this year, and not a very good Dragon Con for robots. I’m going to continue finishing Clocker 4 in the interest of Franklin Institute Robot Conflict 2016, where I hopefully will get to play with some of the big energy bots. I never had a strategy for Overhaul against vertical weapons like drums and discs (e.g. Hypershock, Witch Doctor) – besides Don’t Get Owned, I mean. I hope the Featherweight class, which is full of vertical spinners, will let me fine tune how to approach bots like that better for #season3.

By the way, there was a trip to the new Atlanta McMaster-Carr warehouse to pick up last-minute hardware. This place is

…kinda big.

Okay, REALLY REALLY BIG. Douglasville and the surrounding west Atlanta area is kind of a new target for development, and besides industrial plazas and The McMastergon, there were plenty of housing developments. What could be better than stumbling out of bed and over to Will-Call to pick up your last night’s blurrily-assembled orders? Or hell, just wheel the robot over and work on it in the Will Call parking lot. It’s like working on your shitty car in an Advance Auto Parts parking lot! Who the hell’s ever done that… not me! Nope, never.

So wait… wasn’t there an ENTIRE CONVENTION going on besides just me working on robots? Absolutely… so let’s see how that went.

As usual, I’m too lazy to put together a worthwhile costume, so I went lazily all days as “me”. Just the Overhaul team shirt, and also wearing the Axent Wear headphones around.

I got stopped way more times than I expected.

Shown above is the crew of Jamison, Cynthia, Hannalin, and Lucy, formerly all of JACD last season. This year’s group is Overwatch. Overwatch is a video game. I haven’t played a video game with any degree of seriousness since Descent II Vertigo. I assume this is all legit. Wait until you see the construction Cynthia put into the giant bow…

There was a massive Overwatch photo gathering which took us an hour or more to get out of. Pictured above in the group are Pizoobie and Bonnie.

I generally haunt costumes which have had a lot of work put into them, especially very large and unwieldy ones. I swear at some point I will make an overly complex and elaborate costume. You could argue that Overhaul is in fact such a prop.

This was cool, too. These guys were cruisingly slowly around the convention. P I P E S

Okay, I don’t even know what’s going on any more. Overwatch players, I assume this is something you’d understand.

Alright, I usually don’t give a spare minute for Kantai Collection because it’s utterly destroyed my favorite genre. But I will make exceptions for well done ones. Behold, the U.S.S. Iowa.  I watched her being “assembled” on the spot, and before that, I followed the ant trail of battleship parts being carried high overhead down the packed street by her pit crew. Her drydock workers?

Good ol’ Kancolle, ruining “girls & machinery” since 2013.

If you know who this U.S.S Iowa is, let me know and I will gladly add links and creedits.

Now here’s how to properly do it. Besides Overwatch, Cynthia, Lucy and Hanna also teamed up for something else. Shamelessly stolen from the BattleBots Instagram, it’s….

BattleBots cosplay at @dragoncon with Lucy, Hanna and Cynthia. Zachary Ernst

A photo posted by BattleBots (@battlebots) on

I’m telling you all, #season3 will be one big weeb convention. Everything is falling into place, exactly according to keikaku. Cynthia is the designer of Haru-Chan, so it was only natural that she also sketched up plans for Sawblaze and Road Rash.

Now for the event recap!

MicroBattles this year was bigger than ever. With the insect classes (1s and 3s) being the easiest and cheapest to start in, the newbie and first timer proportion this year was immense. We ended up getting over 40 robots!

Sadly I actually missed a lot of the action getting Roll Cake prepared, but here are some of my favorites.

Here we have the wild Killer Colsonbot, which is believed to have evolved from escaped Domestic Colsonbots.

That’s Pvt. Slicer, or what happens when Mike gets ahold of the Colsonbot CAD. The cage is made of layers of waterjet-cut 4130 steel carefully welded together. It had friction drive reliability issues, but it somehow won 2 matches as round pushybot. When the cage met a vertical spinner, it died.

Representing the “meh” department of Dale’s Homemade Robots, this is Noodles, a 4wd pushybot. Besides all brushless drive, steering gyro, and a crafty urethane-sheet-mounted steel plow, it has pool noodle wheels which caused a bit of controversy because in the final a piece of them came off and jammed Black Adder’s drum.

Now, unintentional entanglement is allowed in the rules for the precise reason of a part inadvertantly coming off and getting stuck in something (as opposed to intentionally throwing things into a weapon to jam it), but there was still a fair bit of “Who do you think won this match?” talk.  I actually think repeatedly hitting the ceiling against Black Adder and coming back each time is a mark against the effectiveness of Black Adder’s weapon in this match.

It’s big bot time! After being forced to run 12 O’Clocker only, I had more time to go around and appreciate the 12s and 30s. The newbie count was great at this event also – I think probably 25% first or second events.

Pictured above, The Magical Lipo-Fire or…. something or other. The build looked great! Sadly only one match however, and fortunately did not live up to its name.

First time 30lb entry “STICK A FORK IN IT!” which was having some DeWut clutch issues this event. Hey, people, read the manual! Tighten down your DeWut clutches before using!

Team JACD Season 1  principal cheerleader Andrew brings Pusheen-Bot, a pushy-bot. It’s laser-cut out of wood, so naturally it faced a chainsaw first match.  This thing actually has two 50mm outrunners in it. It’s basically BurnoutChibi in a 30lb bot, so-illustrated by Andrew riding the bot around the room before (and during…) the event.

Another new 30lber with some heavy inspiration from Clocker and megaRon (under whichever moniker Jamison decides to run it at Robot Battles…)

There were obviously a lot of bots that I skipped, and you kind of get the idea. With the return of BattleBots to a mass audience, so the hobby grows! Robot Battles, fortunately, is one of the lowest barriers-to-entry competitions there is.

12 O’Clocker all set up and with spare clamp motor installed, ready for its first match. I had immense fun in its match with Dingleframus – it was the hardest physical driving match I’ve had in a little while, and in the end, a missed charge basically caused it to hover off the stage.

Here’s “Metric Brushless Hipster 12 O’Clocker” LiftLord, a Xo creation but shown with optional interchangeable Aaron module.

12 O’Clocker ready for its first match against Abrasive Personality, a design I really want to see more of – it has a belt sander running the length of the bot, with a backstop and all. I think this kind of design needs exploring. Putting more horsepower behind it and using a super gritty belt might actually result in some serious unconventional damage.

So what the hell are those blue things on the stage that have been appearing in every video so far?

They’re my secret weapon: 3D printed model set screws. I printed about a dozen, then another dozen or so followed me to Atlanta courtesy of RocketProps. Some local folks contributed a few more…. and suddenly, a stage full of giant set screws. Robot Battles: serious business since 1967 or whatever.

Not sure what I was doing here – probably double checking the chain drive after the rumble where it was derailed due to the main sprocket being physically bent. 12 o’clocker went 1/1 plus hanging around during the rumble, which was hugely entertaining.

Well look who’s on display!  I’m told that Witch Doctor & Hypershock were also going to be present. Lies! I didn’t see any of y’all this whole weekend, so Overhaul had to have all the fans to itself. Such a sad day.

That’s a wrap for Dragon Con 2016. Once again, I’m staying a few days extra in Atlanta, and will diffuse back up north some time this week. On deck for robot work is finishing Clocker and a quick revamp of Roll Cake before FI in about 1 month. Otherwise, I’ll be hopefully creating more problems for myself with van work soon, since I want to re-winterize a few spots before things get cold (e.g. in 2 months or so). Some of my earliest rust repair is starting to come apart finally, and I have better weaponry against it now. Further down the line is word about # s e a s o n 3 and starting Overhaul….overhaul…. work in earnest. This will ideally occur over the coming winter.


Roll Cake Rises; Überclocker 4 Begins

Aug 26, 2016 in Bots, Roll Cake, Überclocker 4

On this episode of “Charles is still CADing everything distressingly close to Dragon Con“, we continue with the development of Roll Cake to the point of completion, as well as begin with I CAN’T BELIEVE IT’S NOT OVERHAUL! Überclocker 4! I depart for DC 2016 in a few days, so there will hopefully be some updates on the physical construction of these bots on the road and in Atlanta.

So I spent quite a few days on and off puzzling over how to place components in Roll Cake. As I said last time, putting square things into a triangular robot often requires a lot of compromises and “dimensional exhuberance”.

This was one of the choice placements, using a 850mAh 3-cell lithium battery, the same kind used in Colsonbot. I also had a few 1000mAh ones used in Stance Stance Revolution, but they proved to be too long in every configuration here.

One of the other “mid experimentation” screenshots. I tried locating the battery on the same side as the drum motor. This involved pushing the drum motor to the interior of the bot, an option I was not favoring since it means the drive pulley was going to be pulling on the motor can farthest away from its bearings. This would end in certain tragedy.

Plus, it’s not like this side of the bot somehow had MORE length to put a battery in!

I decided on the configuration seen here after more component juggling. This places the battery in the flatter configuration (meaning it sticks out of the side more), necessitating making the whole bot wider by about 1/4″ to accept it. However, this meant the servo could be on the same side as the battery, which was highly advantageous.

Here, I’ve also generated the motor pulleys. The wheels were a design I already had; it is a little hard to tell, but the pulley sections have a V profile instead of the square bottom usually seen in small round-belt drive pulleys. I’ve found that this tends to give better grip for small pulley diameters, working a little like a V-belt. It also tends to be more tolerant of misalignments, since there is no square side for the belt to suddenly grab and be pulled off, and is also auto-centering.

The tires are a takeaway from Colsonbot and SSR, and are actually 1″ diameter rubber grommets (for sheet metal panel holes where, for instance, wiring or tubing pass through). They’re made of soft rubber and can be easily stretched over a hub. In this application, I’ve stretched them to being 1.25″ diameter.

Due to the tightness of the space around the battery, I did something I rarely do – simulate the chain or belt path. The 3/32″ roundbelt drive unfortunately has to make a Cleveland Left past the battery, in an area with minimal clearance. I specified and ordere some tiny little type MR63 bearings for this job – 3mm ID, 6mm OD.


Here’s the belt path simulated . It will need some grooves designed in into the frame to clear. I didn’t want to make the wheel pulleys any smaller due to the limitations of the round belt – too small a pulley and they don’t grip nearly as well.


The belt kink also allows the motor drive pulleys to achieve nearly 180 degrees of wrap. So at least I know that part isn’t going to be slipping! It also directs the belt up and away from the drum motor.  I changed the drum motor to a slightly larger 2836 type motor which has a larger 4mm shaft. This desketchifies the pulley mounting significantly. The motor has been moved back to the interior of the drive pods, with the region around it beefed up in thickness and ribbed for its pleasure and rigidity.

All of the control electronics have now been moved to a pocket on the right side of the bot.

With the sides of the bot figured out as much as I care to, it was time to move to the clutch triggering mechanism. You know your unibody design has gone horrifyingly wrong when you have to start slicing the view to work on stuff.

The channel cut into the body here holds a sliding bolt-like structure which will be toggled by the servo.

Like so. This is shown in the retracted position, where the linkage holds the planetary gearbox’s output ring stationary and therefore the dog clutch ring spins freely.

And in the “This kills the servo.” position, where the sliding bolt impedes the motion of the dog clutch gear, forcing the output ring to begin spinning. This throws the cam linkage.

Based on the advisory speed of the clutch gears, which is 237.5 RPM (950 rpm/V * 11V battery / 2:1 gear ratio, then divided by another 22:1 in the gearbox) and the width of the valley between dog clutch teeth, the servo will have roughly 70 milliseconds to move the sliding bolt. These servos are rated at 0.11s per 60 degrees, and the bolt travel only needs about 15 degrees, so I HOPE there’s a healthy margin here.

The directionality of spin matter s alot. The frame is only bracing the sliding bolt in the configuration shown where the dog clutch gear is spinning clockwise. This means Roll Cake actually does have an “upside down” since the drum can only spin in one direction to use the flipping linkage. Hopefully, in a bigger version of the bot, this shortcoming will be addressed.

During this design work, I was thinking ahead a little as to how to 3D print the final product. The unibody turned out far too complicated to print in one piece, so I elected to split it into 3 pieces – left, right, and center.

One problem though. The bearing mounting supports for the drum, which are also the pivot points for the hinged flippers, make the left and right sides not completely flat if I sliced the part on the inner faces of the left and right sides.

I decided to make those rings a separate print each, allowing me to print the two halves concave-side up using no support structures, which results in a cleaner print.

Therefore, I added makeshift bolt holes on the inside of the drive sides, which eventually will have screws threaded through into the bearing mounting rings.

Each side had features added which allow me to fasten the side covers. Because the bot wasn’t symmetric, the attachment to the center U frame was different on the left and right.

One last detail was how to pass wires through. Besides the through-hole at the very back of the bot, which is supposed to fit a threaded rod (a last ditch everything-is-fucked way to keep the bot together), I put in two more semi-through-holes linking the left and right via the central frame. One will pass the battery cable, and another will be servo power and drive motor wiring.

I moved onto the final little details of the bot. Drums aren’t that effective without little feeder wedges to direct opponents into them, so I made small extensions that will mount metal — likely spring steel – wedgelets.

The side covers contain a few more injection-mold like elements to line up with the left and right sides. These will be made of heavily fiber-laden Onyx material as a desperate bid to fend off other weapons. Unfortunately the bot was already a bit overweight at this point, so no real armor here!

With the addition of the wedgelets and filleting every interior corner, the design is complete. To service either side of the bot, the five countersunk screws are unscrewed (the shoulder screw for each wheel axle is not bolted in, having clearance holes for the heads, so I can run the bot without sides easily and also not have to juggle wheels each service.

The hypothetical open position of the flipper.

And here is a “transparent frog” photo showing the incredible mess going on inside this bot. Like I keep saying, I’ll be damned if it does anything meaningful besides self-destruct.

And now I cut up the frame for 3D printing! Five parts total – two sides, the center U-frame (which will be heavily fiber-braced), and the two bearing support rings.

As a preview for what Roll Cake looks like IRL, here’s a pretend-o-bot from this past weekend. There will be build reports!


This post is now about wheels.

Hah, you thought you were getting a Überclocker design update. Well, in a way, it’s highly relevant, since I’m designing and casting custom wheels for this build from urethane resin and 3D printed molds.

One of the shortcomings of Overhaul this year at BattleBots Season 2 was the horrifyingly bad traction in the arena, compounded with my choice of wheel being poor for an overpowered drivetrain. I discussed a lot of this in the beta match recap. Basically, after the tournament, I was determined to investigate making my own wheels after seeing a few builders (including Beta) do the same. For me, the goal was less to get a specific wheel size or custom geometry than to find an alternative to the thermoplastic rubber Colson wheels, since nobody to my knowledge makes a real vulcanized-rubber 5 inch tire.

After doing some Internet Research, I decided the easiest way to start was to go with a polyurethane compound. There are many choices in that space designed to fit different applications.

Most of it, though, is optimized for some kind of mold making and so was hard to find relevant information for . That’s in fact one problem for me coming in as an outsider to the industry – I don’t know the industry words and niches where different terms mean different things. I tried finding natural rubbers and synthetic rubber base ingredients, as well as vulcanizing compounds (‘cure packages’) for natural rubber. But the only companies I was able to get ahold of were in the moldmaking & casting industry, and they’re so specialized that they didn’t know anything outside of the use of their product for moldmaking.  Anyone with connection to the world of flubby substances is welcome to make recommendations – I really want to create a wheel with the same durability as a vulcanized rubber tire, like a car or go-kart tire, just with a softer compound. Now, slicing bits of tread off real tires and bonding/screwing into a custom hub is a possibility, but I really want to look at the next level up in elegance first.

As luck would have it, I was at the Detroit Maker Faire that weekend with the usual Power Racing Series crew. I had come only to help marshal the race and act as a tech/safety inspector – Chibi-Mikuvan sat out this race since I had not repaired the damage from last year’s New York Maker Faire. 10/10 would get sunburned again. I managed to get ahold of some Smooth-On company reps at a booth, so I got to hassle them with questions about the gooey substances they manufacture, including such cold-open gems like “So, what rubber would you use for a Battlebot wheel?” Based on the response, I’m apparently better at picking up middle-aged company sales reps than the ladies.

After 10 minutes of explaining what the hell it is I’m actually doing… since they’re mostly here again for the moldmaking and resin casting of tiny figurines and the like, two compounds came up very quickly – ReoFlex, a urethane rubber, and Simpact, a “rubberized plastic” as they put it. Both are, as far as I can tell, urethane-based. ReoFlex comes in softer Shore hardness ratings (20-50A) and Simpact in higher ones (60-80A). For reference, a skateboard wheel is usally 70 to 80A, a car tire around 60-70, and Colsons that are used in robots are usually their 65A Performa line. They were both recommended for higher tear strength relative to other similar products, which is important for wheel integrity.

So I went to Reynolds Advanced Materials locally and got a few hits of the stuff.

Lovely. Now what? Do I just pour one into the other and run for it?!

I next designed a core to hold onto the rubber tire. I knew nothing about this, and couldn’t find any good resources about “How to design cores for urethane rubber wheels”, so I freelanced based on what makes sense in my head. Those features were:

  • Lack of hard square edges – gradual transition angles between rubber and plastic
  • High surface area for good bonding
  • No overhangs that can trap air bubbles
  • Through-hole features to enhance gripping the rubber in case bonding fails

That’s what I came up with. Just a basic tapered V shape that has a bunch of through-holes around the permieter. I referenced the outer dimension of a 3″ Colson wheel, so if everything fails miserably, I can bail out to Colson wheels.

I desigend it so it could be 3D printed without support structures, so I can pass it directly from print bed to mold. Speaking of mold,

I then designed up a two piece mold that the wheel core sits in. The tread around the outside was added as an additional element to help traction in a box environment. The argument of tread vs. slicks has been a perennial subject in robotland, and now with my experience in the BattleBox, I think it’s pretty critical to increasing your effective traction. While a smaller bot like Clocker won’t really need it, I wanted to experiment with the molding aspect more, so treads it is!

The reason I think a light tread pattern is beneficial is because while you’re not trying to displace water or mud like in a road car tire, or grab onto rocks and dirt off-road, there is still plenty of fine powder-scale debris in the average arena. This debris is made of little metal bits, worn tire rubber, and SET SCREWS some times loose hardware. A tread that helps evacuate this debris would help put more rubber on the floor.

Tread design is one of those things I could spend a lot more time reading about than I had patience for at the moment, so I went for a simple helical groove pattern. The idea of the helical groove is to keep the contact patch relatively consistent (think meshing with the ground like helical gears) while trying to spread box debris sideways.

The mold was designed as one piece and then split into two pieces. Registration pin holes (not shown here) will keep the two mold halves aligned when together. A hexagonal bushing fits in the wheel and also keeps it centered in the mold.

By the way, I FINALLY, after literally 10 years, learned and used what Autodesk Inventor has for “part configurations”. In Solidworks, configurations are variations on a part stored in the same part file, so you can make different length standoffs, or different sized wheels, that each have the same feature history – no Save Copy As bullshit. In Inventor, this has been JUST barely out of my workflow path to be annoying enough and JUST stupidly named enough (SERIOUSLY? iPART???) that I have, almost on principle, never learned it. As a result, when I need to do a project that will make use of Configurations, I actually use Solidworks. And when I do my own stuff where my CAD file structure can be a Nightmare beta, I just Save Copy As or liberally spam Derived Components.

But that’s no more, because I watched a 5 minute Youtube video showing the basics of iParts, iAssemblies, and iMates, and just freelanced the rest based on expectations and mapping from Solidworks.  So there! Now I’m fully Solidworks-free :p

And that’s how I made a 2″ wheel and mold just by editing some numbers in a table!

The molds were printed using the Mark Two machine in basic nylon, almost hollow. These didn’t need to be structural, after all, just quick to make.

Mold halves with finish-sanding on the flat face (there was a small amount of warping) and installed registration pins.

The retainment method is by a single hose clamp.

This is what the wheel looks like seated into the mold. A 1/4″-20 bolt keeps the wheel core tight against the bottom of the mold to prevent overspill.

I mixed up a dose of Reoflex 50 and put it in a borrowed vacuum chamber to pull out air bubbles. The mixing process introduces air, which makes your material basically a shittily-blown foam once cured and robs it of structural integrity (and surface smoothess & dimentional accuracy for people making cast objects from the material).

Next came the gentle resin pour. Simply fill to the top of the rim!

This is what the wheels look like. Pretty bland B R O W N color, but this can be pigmented if I so desire (Miku Blue wheel time??)

They feel pretty durable, but only testing will tell. This involves actually having a bot together to use them. So on the next episode: How to Scale your 250lb BattleBot and not Hate Yourself, a Self-Help Book by Charles.

Roll Cake, the Revenge of the Wubba-Wubba Drive

Aug 12, 2016 in Bots, Roll Cake

It’s time.

Time for what, Charles?!



I bet nobody saw that one coming! It’s always robot fighting time here at Big Chuck’s Robot Warehouse & Auto Body Center! I’m your host, Big Chuck. And today, we’re going to talk about OBAMA’S ANTI-WEDGE AGENDA flywheel flippers.

Actually, let’s talk about all stored mechanical energy flipper weapons. I’m talking about flywheels and springs, but not including pneumatics. Those former two approaches have been rare penguins in the world of robot fighting, and I think there have been only a half-dozen or so successful ones, meaning it worked consistently or at all.  They both need methods to carefully input mechanical work, decouple the source, and then carefully couple the storage medium (be it flywheel or spring) to the output.

One of my metrics for how difficult a design is to pull off is how many approaches there are to the problem. I always love to pick on the “small vertical drumlet” design as an example. If you take a look at the registration field of a big open event like Motorama… or hell, even BattleBots Season 2, you see a lot of the same design topologies show up repeatedly. In the open-arena environment, those designs are the apex predators, and over time, the design space gravitates towards them. Almost all small vertical drumbots look alike and have the same idea about weapon design and drive, because it’s what’s proven to work, and if you want to win, you want to build what works.

On the other hand, just about every flywheel flipper which has existed has used a different approach to “access” the energy stored in the flywheel. You have the direct flywheel-coupled low speed punter and the automatic-tripping dog clutch of Dale, the “Jam a Colson in it” of Magneato and Zach’s previous bot Jack Reacher, and the face-cam spinning ring of Warrior (which probably has the all-time flywheel flipper high score).

The inside of Warrior (Clan…Dragon… SKF) showing the cam ring and notched linkage which rides in it, released by a servo.
Original photograph by BoomBots, rediscovered later by Kevin Hjelden

That, in my opinion, is how you know a design is still a challenge. Not to dismiss the effort that goes into building a small vertical drumlet, since reliability in a design is always difficult to attain. The way I see it is that the less a design is “settled” on a single approach means the less people have attempted it.  When it comes to spring and flywheel flippers, the engagement of the flywheel is always the sticking point. It inevitable requires tricky machining or unwieldy linkages and couplings, or clutches. Get any of these wrong and you just make a kinetic energy grenade in the arena, which is fun to watch for everybody except you.

Now, I have a fair bit of history with trying to design flywheel flippers and spring flippers. It’s in fact one of the designs I’ve tried to work on the most. For example, we now take a trip back to 2006. I had to rummage through not one, but two old hard drives to find this photo directory!


This was the first time I put together a “two ended” bot design. That means it has an active KE weapon that’s also used to actuate a flipper in the back. I had an interest in a design like this for a long time due to the existence of Warrior, but wanted to see it in a vertical spinner; at the time, Nuclear Kitten was still quite successful (I was, you see, the prototypical Small Vertical Drumlet kid, and this gives me infinite hipster cred, right?). After Dale build the 2nd OmegaForce, I thought that the triangular shape was well-suited to a design where the flipping linkage was a scissor type design, which just hinged on the bot, riding the ground, until commanded to open up.

It was always this opening up which was the hard part, and in fact this is as far as that design ever got. I can find no additional photos or Inventor files relevant to it.

Fast forward about 5 and a half years, and here we have the bot for which the original wubba-wubba drive post was made. This is the first time this design is being made public, because it never got far enough for me to want to write a design post. I designed a few variations of the “KE kicker” weapon, which was an internal flywheel (the large aluminum shell stayed still and the “Hard drive head” looking thing spun around it) geared around 40:1 to the kicker.

The actuation mechanism was a one-sided Differential Analyzer style torque amplifier (reasonable video here). God that’s a lot of link text in that sentence. Essentially, the post-geared flywheel spun a winding drum, around which a steel cable was wound loosely a few turns. The steel cable connected to the scissor linkage on one side and a small winch motor on the other. When the winch motor pulls on the cable, it tightens around the drum and transmits the force instantaneously to the linkage. As long as the winch motor wanted to spin faster than the drum (i.e. apply a force on the cable), the linkage would move. If the winch motor stopped, the force is released to the degree that the flipper linkage tries to pull against it back downwards. If the winch motor is powered the opposite direction, the linkage closes again since the drum cannot grip the now loosened steel cable.

It was something I read about in a textbook, then tried winding a string around a spinning motor shaft and pulling weights with it across a workbench. I was confident this idea would work. The ‘winch’ was just a fast DC motor running a sector gear that had hard stops, such that in one rotation of the drum, the motor is forced to stop and reverse, and that linear distance covered by the drum rotation was enough to fold the linkage out.

The design above did not progress further because it was too heavy. My desire to keep the mechanism coaxial made it too heavy. Furthemore, I recognized that the motion only worked in one direction. There was no powering closed, only gravity and any springs I put in the flipper mechanism to help it back down.

That didn’t stop me from making an updated less-heavy version of the kicker, which involved an external flywheel:


Now, this flywheel was super interesting, as I had forgotten I ever designed it. What you see is a P80 gearbox with a brushless motor built onto it.


Yup, you can tell this was thought up in my Era of Designing Silly Hub Motors. P80-flywheel-motor!

In the end, this design also never progressed beyond the point shown. And I honestly am not sure why – I may have lost interest and moved onto rebuilding Überclocker, or I still thought it was too messy to work well.

By the way, another artifact from late 2006 in my “D:\old\Backup of C\old\pics\old\….” directory was this:

That’s a Test Bot version 5 concept with a spring flipper. Looking back at this mechanism from where I stand now, it’s clear to me that I at least learned 1 or 2 things at MIT, which I think was the idea of going in the first place. The mechanism, while sound in theory, has a lot of nuanced problems that would have made it not work.

The idea of the mechanism was that there was a block with a ratchet/hook (think roller coaster climb ratchet) which could be moved along the bot via leadscrew. The ratchet preferantially springs towards the center of the bot and can grab a movable block which compresses the spring as they travel along the leadscrew. At the end of travel (back of the bot), a small ramp structure forces the ratchet away – this structure is not modeled here) and pop goes the spring. Then it has to travel all the way back to the start and hook the ratchet over the block again to reload. Works in principle, and I can see it working IRL with some critical geometry changes.

This, too, was as far as that design got – those who knew me in that era would know that I went to a standard 4-bar lifter for Test Bot in 2007.

So, as you can see, I’ve had a lot of false starts when it comes to these things. For the longest time, in fact I’d say since I produced these first designs in the mid-2000s, I’d never attempted to build them, writing it off to “Well, Dale and Whyachi have already done it more elegantly than I can, so why bother”, and distracted myself with grabby-bots and vehicles of questionable utility to society.

Well that’s kind of a shitty attitude, isn’t it? And one that I keep trying to beat out of others, such as my former students, whenever I had the chance. So why the fuck don’t I just take my own advice?!

People who read the MarkForged blog might have already seen a preview of this design. I wrote that article as a part of their marketing push for the new Onyx material (which is currently the only 3D printing material I care about), when this design was in an earlier stage. It was also heavily summarized for a general technical audience. Now, it’s time to dive into the full gory details of development!

Wubba-Wubba Drive’s Revenge

I first began reading about compound planetary systems (Hereafter: wubba-wubba drives) for a MIT Media Lab project during my freshman year in 2007, when we were trying to package a high-ratio steering servo inside the wheel of the CityCar project. I mentally filed the WWD away as a useful mechanism, but the filing cabinet was in a mental block scheduled for demolition due to blight suffered from Charles’ Angsty Emo Middle School Years, and as such the record was lost.

So I forgot about it until the BO-Px motors in 2.007 showed up, and it renewed my interest in exploring it. That’s how the “Wubba-wubba-bot”, which was never named, came to be.  It was a compact way to get the reduction I needed without multiple stages of planetary gears.

After the BattleBots season was over, I was looking for another “family” of robots to build, so to speak. The past couple of years have seen me rebuild and revise Überclocker, my clampy-grabby bot bloodline. With Clocker finally retired (FOR REALSIES) after its tournament win last Franklin Institute, and with the summer robot season in effect, I was thinking about what other less-loved design to pursue for the next little while. A lot of conversation with Landon (of The Dentist) about flywheel flippers… because, I love you guys, promise, but let’s make the Dentist even more out-there for #season3…. made me remember the Wubba-Wubba Bot and how I left that design hanging in space.

What if I started with a small concept and grew it eventually larger and larger? One of my problems was starting with a 30lber, I think. It made for too much of a material and effort investment into something which would probably not have worked. And with my recent habit of 3D printing stupid beetleweights, it was abundantly clear to me that a 3lb concept would be the way to start. After all, I had recently scrapped both SSR and Colsonbot ( RIP ), so had spare running gear for a small robot.

I still lacked a way to actuate the linkage that was satisfactory, however. One of my reservations about the cable-driven system was that it only powered on the opening swing, and could not apply force the other way. Furthermore, if the flipper were forced open externally or could not close (something caught under it, mechanism damaged and jammed, etc.) there is a risk of the cable bunching up and becoming tangled. A possible failure mode is the bot getting stuck with the scissor link open upside-down (or facing straight up) without the ability to close the linkage again.

All hypotheticals, but a design like Warrior poweres both on the upswing and downswing. When I was designing the Wubba-wubba Bot, I briefly entertained an alternative engagement mechanism which was brought back up while talking about designs with Landon.

The best way to describe this method is probably to watch this video of my ‘toy gearbox’ that I made for the design:

Here’s the first rendition of that toy gearbox, showing the split ring gears and compound planets – planet gears of slightly differing tooth count, but conjoined.

The way this new triggering mechanism is intended to work is that stopping one of the ring gears forces the other ring gear to spin at a speed determined by the compound planetary gear ratio. Stop the other, and the former rotates in the opposite direction at the same ratio. Basically, you pick a “ground” (zero velocity) and the other output is forced to spin with positive or negative polarity.

Say for example one ring gear is connected via a cam linkage to the flipper (the ‘cam gear’), and the other is ordinarily free to spin, but can be stopped a large brake or dog clutch (clutch gear). The stopped clutch gear becomes the ground, and the cam gear is forced to rotate the linkage. Let go, and the linkage stops the cam gear from rotating continuously, so the clutch gear goes back to freely spinning.

This method was one that I discovered by accident in 2012 spinning the WWD model, but I was intent on exploring the Torque Amplifier cable-driven method. When the original Wubba-Wubba Bot design was shelved, so was this idea.

The advantages of this method of engagement include a large cylindrical engagement surface which can be arbirarily large (e.g. to act as a brake band rotor, or give more surface area to a big magnetic clutch, etc.) and an all-mechanical power transmission once engaged, without being reliant on friction surfaces. Furthermore, it permits designing the cam system to give a sinusoidal acceleration. This means no crashing an energy source suddenly into a mechanism and forcing it to match velocities, but the movement of a cam attached to this gear can start at a point of maximum leverage.

I think I got more excited than the Dentist team over this design, so naturally I had to go make a ‘toy model’ to play with, which is shown above and in the video. The gear with the cam lobe, obviously, is the ‘cam gear’ and the other one the ‘clutch gear’.

And so begins the tale of Roll Cake, which was a robot name suggestion given to me a while back (for no particular design) by Rebecca, also of the Dentist team.

How do you start designing a 3lb-class drum spinner? With a drum!

I cooked up a fairly basic 3 pound drum. The body is made of a spare aluminum billet, and one endcap is removable and has a pulley built into the endcap. The teeth are made of 1/2″-13 socket cap screws. In this weight class, this is a somewhat common approach for drums.

Notice that the shaft is keyed. I played a little while mentally with the topology of the drum feeding into the gearbox, and decided that a live shaft was far less troublesome to deal with than a dead shaft. Reason being, I’d have to make a gear that mounts and spins on the drum anyway, and it would need to be large enough to support its own bearings.


I began generating the ‘toy gearbox’ that was seen above at this point. The planet teeth and pinion were chosen very carefully: They’re BaneBots P80 3:1 and 4:1 planet! The plan was to machine them down and shove them into each other to create a ‘single stage wide’ compound gear. The larger ring gear, at this point, was intended to be made from a piece of P80 ring gear, with the compound ring waterjet-cut.

That changed to the compound gear being 3D printed using Onyx material in order to save space and integrate the actuation cam. The “clutch gear” now has the aforementioned dog clutch teeth “cut” into it. In a bot this size, I elected to use the good ol’ stick in the bicycle wheel spokes method of stopping the clutch gear. There will be a solenoid or servo that carefully pokes something solid into the gear’s outer ridges.

If this arrangement is confusing, here’s what’s going on inside. The drum is the flywheel, the live shaft (not pictured) drives the pinion gear (sun gear), which drives the larger half of the compound planets.

After some drum adjustments, I went onto lay out the shape of the bot. The triangular shape is established here. I was fairly set on the shape and the double-sided flipping linkage, as it was a part of the original vision. The dimensions were, for now, best-guess as to what I’d need, and my job in CAD is just to make sure changing them later is not too painful.

Made solid and with a wedge cutout. This is when it started looking either like a slice of cheese, or a cake slice, and when the name “Roll Cake” was adopted. The shorthand project code I assigned to this bot for CAD files and stuff – such as “cb” for Clampbot (Uberclocker), and “gc” for Overhaul 2 (Giga-clocker!) is “wfo_”…. what WFO stood for I will leave a mystery.

A little more shape definition and with imaginary component placements. My tactic with unibody beetleweights is to start with a shape and “machine away” what I don’t need. I design things a lot more like what I’d do for an injection molded product, minus things like draft angles, but doing so means it won’t be that hard to MASS PRODUCE COLSONBOTS FOR EVERYONE! YAY!

The next most critical thing to do was define the arm linkage. I drew a circle that was my ideal “cam throw” and generated a V-shape linkage to fit the rest of the bot. The dimensions were all “dartboard legitimate” at first, then tuned to get the desired swing.

This was modified as dimensions required, but the linkage could open to around 45 included degrees total. There’s no point in having too much throw, as the opponent is liable to just come off, but too little means having to transfer kinetic energy in a shorter window, leading to higher part stresses. This is a general sense of things – absolutely no dynamic simulation was done whatesoever.

The sketch linkage was replaced by Real Life Flappy Things built from them. These hinge from an extension of the live axle bearing housings, and will be made from .075″ aluminum sheet. Reasonably rigid, not that heavy.

The “big cut” opened up the interior of the bot for linkage placement. I next modeled the linkages themselves. The cam connector link has one “big end” that wraps around a 6808 type (40mm bore) bring bearing, which is what sits on the cam itself. The other linkages are basic dogbones. These guys will be 3D printed from carbon fiber-backed Onyx, a material we have lovingly named Reinforced MarkForged Carbon-Carbon (RMCC), for maximum rigidity against buckling.

Notice now that the body halves are now hollowed. From here, I’ll be adding internal bosses, ribs, and cavities for the components.

I next generated the anchors to the upper and lower flaps. This actually resulted in some geometry shifting as far back as shifting the drum, so I could cut out two identical flaps in 2D (from a flat plate), fold them the opposite way from each other, and end up with the hole spacings I needed. Otherwise, the upper and lower flaps would be different parts completely.

I started running into a problem while testing the swing of the linkage on either side. There is NO position at the front half of the bot which doesn’t interfere with the linkage swing!

This meant there was basically nothing holding this bot together side to side. The live axle can’t be counted on for structural rigidity, though shaft collars at either end would help keep things together.

So the solution was to delete the crap out of that whole area, and go back to the “big cut” in the center to fatten up the back of the bot. Above is the linkage  shown in full deployment. When folded, it sits in the circular cutout at the back laterial frame member.

One solution to the “can’t hold the bot together” problem is shown here – fatten up the back frame rail and extend it into a U shape that hugs the sides of the bot. This basically sealed the decision to 3D print the frame as 3 or more pieces – left, middle, and right, and join them together. The center can be made of high-rigidity RMCC while the sides can be more conventional nylon and kevlar, which is lighter and a little more compliant.

So there we have the looks of the bot and the general placement of things inside. Coming up next? A weeks-long adventure actually trying to fit things inside. It turns out a triangle is a crappy shape to put square and round things into. Also upcoming soon, the rebuild of Uberclocker version 4.0!