Archive for March, 2016


The Overhaul 2 Design & Build Series, Part 6: Electronica

Mar 29, 2016 in BattleBots 2016, Bots, Overhaul 2

No, I haven’t gotten into the electronic music industry, but a lot of electronic was definitely consumed during this stage of the CAD! The build season is in its last week or so, which means I’ll be prioritizing shipping a working robot with build reports and more photos to follow the April 5th ship date.

With the mechanical design basically complete for the first pass – everything at least having a shape I can think about later if need be – it was fine to give the electronics a home. The typical electrical system for a bot like this is relatively simple, and components come in bite-sized modules that just need to be mounted to something in a vaguely robust manner. Rarely do you see fully custom PCBs or integrated controllers, unless the builders are electronics engineers by practice or hobby (an example is Dale’s bots).

OH2 is sort of a mix of the two cases; while I’m not using my own RageBridges due to the simple fact that they have 2 wires instead of 3 do not run brushless motors, the controllers I am running are extensively hacked and modified to serve in ground traction application (More on that soon, I promise!) But they’re still in their original cases, so my job is kind of easy – THROW THEM IN THERE WITH SOME VELCRO AND DOUBLE SIDED TAPE AND BE DONE WITH IT!

Nah, I think I ought to do just a little better. Since the functionality of the system is a known quantity from my testing with Sadbot, I was out to optimize the survivability and serviceability. Particularly, the goals of the electronics containment structure (hereafter nicknamed the e-deck) were:

  • Full self-containment – basically, a robot control system in a box, with receiver, power supplies, and cooling as the cherry on top. It wasn’t just going to be a box of motor drivers.
  • Rapid swappability – I planned to build two or more, and if something happens during a match (but I come out on top), swap the spare unit in and deal with the damaged one later.
  • Pursuant to the first two requirements, be internally modular or easy to service so I can remove the broken component relatively easily.

Historically, when I’ve made an electronics enclosure at all in a project, it’s been a constructed (usually t-nut) box made of polycarbonate or some other plastic. So let’s start with what I know. First, here’s the layout and the space I have to work with.

At the time of this design version, the Hobbyking Graphene batteries  had just arrived on the market, and I was eager to try them out. OH2 is not a bot which needs to pull hundreds or even thousands of amps in an instant like a kinetic energy weapon would do, and the new large-capacity Graphene packs (12AH and up) were highly attractive. I designed around the 12Ah 6S packs to begin with. They’re represented with external rough dimensions provided by the HK product page here, in gray. To their left is the final configuration of the DLUX 250A motor controllers after playing with exact spacing.

I decided to start with the “known known” and package the batteries up first. They were going to occupy the only large contiguous space in the back of the bot, which was originally designed to fit four of the Hobbyking Nano-Tech 8Ah packs that OH1 used. These are actually slightly shorter than two of those back-to-back, so I had a little more room to play with.  I made a “minimum dimensional enclosure that’s a clean fraction above the size of the packs”. The enclosure will be made of  1/4″ polycarbonate, likely waterjet-cut, with plenty of my special-sauce t-nut joints holding everything together. This part I’ve done dozens of times, so I left the geometry simple for the time being in order to move onto the rest of the system.

By this time, I had begun receiving lots of parts in the mail, and I began realizing something very distressing – that two Whyachi MS-02 switches were going to be too large to fit. The newest BattleBots rules now require you to have independently-switched weapon and drivetrain power systems. While I had submitted an application showing two Whyachi switches, actually trying to size them in the design showed me that this was mostly ‘last minute homework question’ and practical. Essentially, yes I could fit two MS2 switches, but I would prefer not to.

So naturally, in keeping with the trend for this bot – I designed me own. Gee, can you make touching two wires together scientifically any more complex? Yes, I can.

Here’s what’s going on inside that block of nondescript 3D modeling clay. Hint: It’s not much. It’s literally a gigantic Fingertech switch. I designed it such that the square area of the face of the switch (where you crank the contact) is half the size of a Whyachi MS-2, so I could fit two side by side in the space of one MS2. It goes “back” further, but I had that dimension more available.

I didn’t want to get fancy with the contact method, so Fingerth-style “tightening two conductive things onto each other” was the way to go. The terminals are 1/4″ thick copper, and the contact is a 1/2″-13 brass socket head screw. Brass isn’t as conductive as copper, but sheer area makes up for it here – the cross sectional equivalent is a 6 gauge copper wire.

That is revision 1 you see up there. Come build time, I’ll show some updates to this design that make it more refined and less terrifying to use, with the possibility of it being a future Equals Zero product. For now, once again, the shape is set and I can stop thinking about it for a little while.

I’m playing the layout game a little more here, having added a RageBridge 2 to the equation. Instead of “rack mounting” like I am going to do with the DLUX controllers, I decided to lay it flat. The reason behind this was that Rage2 is rather short (heightwise, from the heat sink plate) compared to everything else, and I needed the same area to also be occupied by the switches. If the Rage were also vertical, I’d have needed to push everything sideways, right up to the width between the motors. Leaving some breathing space in a big bot is good for serviceability, the fact that I didn’t want to optimize the design into a corner right away notwithstanding.

I began generating an ESC box in the same manner as the battery box. Check out those big bus rails – that’s how power distribution will be handled. While thinking of ways of avoiding a gigantic tree-root of wires splitting off into smaller wires, I was reminded of the existence of bus bar products after digging through my wiring parts bin and finding some car audio power distribution blocks.

However, most industrial bus bars look like this, which requires putting ring terminals on the controllers. While not the end of the world, I usually prefer the direct wire contact style of the audio distribution blocks. There’s also busbars which look like this, more commonly called ground bars, in the audio power distribution block style. I started shopping around for them, before the realization that they are simply blocks of metal with set screw holes tapped into them hit me.

Well, fine then. Not like I wasn’t going full hipster on everything else electrical already, right? After doing a bit of research on bus bar manufacture, I decided to get some alloy 6101 aluminum from McMaster-Carr and just drill and tap some holes into them. 6101 is the most conductive aluminum alloy in common use for electrical appliances. Aluminum has less conductivity than copper, but you make up for it using more. The equivalent cross section of the bars I modeled is 6 gauge copper wire at the minimum.

The bus bars are offset horizontally from each other by about 1/2″. With another set of holes oriented vertically, it means I can stick a hex wrench through a hole in the top one and land it in the set screw socket of the bottom one. To prevent accidental crowbarring of the circuit (nevermind the fact that the whole bot’s going to be turned off, battery disconnected, and most likely this whole electronics deck removed from the frame when I work on it), the screw access holes will be given little nylon bushings to insulate a passing tool.

The final bus bar design is made from the 6061 bar stock, are 1/2″ x 5/8″ in profile, and about 8″ long each.

Moving on from generating the crude rectangular-box housing to stitching the edges together in my usual style.

Shown also are Anderson 75 amp Powerpoles. It’s a well known fact in the robot world that the 75A Powerpoles are actually capable of substantially more than 75A in bursts. Since I’m not a giant spinning weapon, I needed something which was more substantial than an XT or Deans connector, but to size an actual industrial connector to my load “like 200 or so amps” would make OH2 just one big connector. I brought in two pairs of them to check on the available height for mounting.

In a way, I’m counting on running extremely high voltages to avoid using high current to push power (the alternative being a low voltage system like 18-24v and like all the amps ever).


It began being easier to look at in dark wireframe mode – basically Shaded with no shade. Wireframe was too messy, and the transparency of modeling in polycarbonate with default looks meant it was still hard to see the edges. Above, I’ve added the slots for the #4-40 t-nuts.

I toyed with the idea of a backplane connector style of battery attachment, where the Powerpoles are mounted to the polycarbonate enclosures, and the whole assembly kind of snaps together and gets bolted in place. I even modeled a 180-degree rotatable Anderson Powerpole mount to do this, seen above.

However, the more I thought about it, the more I wanted electrical connections to be as compliant as possible, not hard-mounted. So, the bot-side electronics enclosure will get this Powerpole mount, but the battery itself will just have a loose connector pigtail.

After establishing how big the enclosures were, it was time to flow a bracket around them to hold them in place. This had potential to be the largest part ever printed on a Markforged machine yet, so I was highly tempted.

The premise of this universal bracket was to contain the enclosures using massive areal contact of something mildly compliant (nylon), and also to presenting vertical bolting features to further restrain horizontal planar movement as well as vertical movement.

It also acts an air guide shroud for the drive motors. At this point, I’d been thinking of ways to do forced-air cooling of the whole system, and the holes & vents in the electrical deck were created with that in mind. I was planning on having a central fan somewhere – likely in the empty space to the right of the lift motors and having it pull air through the bot.

Here is the completed Everything Bracket, with its own mounting features.

I’m now at a point where the whole design is basically “first-pass complete”, meaning I know where everything goes and what it should do, even though it might not be well thought out or optimized. I find that this point is a very helpful one to reach, because the changes you’ll make to the design tend to be evolutionary instead of revolutionary (scrap it and start over). Not to say I haven’t done the latter, but…

In the next episode, I’ll introduce some of the very last CAD kibbles before the real fun starts – the build reports!

The Overhaul 2 Design & Build Series, Part 5: The Top Clamp Arm and Actuator CAD-o-rama

Mar 21, 2016 in BattleBots 2016, Bots, Events, Overhaul 2

We’re beginning to reach the “minimum entropy point” of the design now, which is the point where I know exactly what needs to get designed and do those in sequence. For me, this usually occurs at the 2/3rds or 3/4ths mark (roughly), when I see the light at the end of the CAD tunnel. Basically, after this, the design sequence will probably get more chaotic as I visit and revisit portions of it.

This post will start where the previous left off, with me beginning to sketch the basic form of Overhaul’s characteristic rounded upper arm.

During the design of OH1, we went through a few arm shapes and construction methods. In large part, the rounded shape was dictated by the desire to avoid bends or miter-welded tube sections to maximize strength, since OH1 at this point was still focused on crushing. We’d already designed the lift arms to be the “tubes and AR400 side plates” method seen again in OH2′s lifting forks, so it was a matter of maximizing strength while minimizing weight.

The arm plates had large circular cutouts to reduce weight without adding stress rising sharp corners, and also looked cool because it was a Preda Raptor knockoff looked like historic machine tool cast iron girder frames. With a bit of reinforcement, that clamp arm turned out to be the most rigid thing on the bot, even without the reinforcing cross-tubes we designed to be welded into the holes.

I wanted to keep the design and look (adding to the visual continuity of the bot) so I started modeling the same way we did for OH1 – with a really big circle. The inner circle is not concentric, rather driven by the radius of the circle forming the hub/attachment portion and the desired tip width. The third constraint in the size of the inner circle was…

…the welded crosstubes. Through some geometry-mancing (geomancing is taken), I came upon a solution for the outer and inner circles which incorporated commonly available sizes of steel tubing that had the holes spaced all roughly the same distance apart. The spacing is not exact, but visually hard to discern the differences. That’s it, I’m keeping this design. It cannot possibly get better from here.

Modeling in the cross tubes. They keep the front portions of the jaw, where the highest compressive forces are seen in an attack, from spreading or buckling. OH1 relied on the tooth joint itself and a sheet of steel that was rolled to match the curvature of the outside of the jaw, welded to the top edges of the side plates.

I quickly modeled a tooth that could be machined from some tool steel in principle, but left it highly unoptimized. I just wanted something visually there to guide the rest of the design, and intended to come back to this later. While I could have this manufacturered, it’s shaped in a way that would require a larger, more expensive block of steel to start with, and also more setups and operations.

The tooth could be used in the ‘hooking in’ direction shown, or it could be turned around. I used the triangular hole pattern specifically for this, since it would keep the design versatile and allow different tooth placements and possible other attachments depending on who I’m facing.

With the top end of the bot visually anchored, it’s time to start thinking about actuation. For starters, I dropped in the “sketch model” actuator I made for the application, which contains a SK3 motor, a P80 gearbox, and some arbitrary solids that may or may not make sense. This allowed me to see how much it didn’t make sense and how porked I was for space, which was very. I spent a while figuring out the best angle to mount the actuator such that it remained serviceable, didn’t stick out too much, and most importantly, could get me the jaw travel I wanted without running into anything else. I’d say the latter two were the most difficult, since the design was anchored substantially in general by the time I got here.

One way to get better actuator placement was to back down on the size of the motor, but that’s for manlets I wanted to retain the high powered grab-or-smash capabilities, especially in conjunction with a very bad idea I began prototyping in November.

After some more design evolution, I’d like to point out the three key features of the new upper clamp actuator. It’s still custom, for a higher force to weight ratio than what I could buy commercially.

First, I decided on a compromise position between the upper “I want to use my motor as landing gear” position where it’s highly exposed unless I gave OH2 a massive steel mohawk, which would be KINDA COOL… or the lower “I want to use my motor to absorb a Tombstone hit” position. The position I chose is in the middle.

This keeps the actuator securely within the two walls of the upper clamp arm. However, it causes a significant bending force to be applied to the leadscrew because it’s pushing off center. The proportion of the bending the leadscrew sees is a ratio between the distance offset from mounting axis (the big hole) to the leadscrew’s axis, and the spacing of the two bearings of the leadscrew (the purple object – there’s another one hidden from view to its left). This meant I had to be careful with OH2′s clamp force calculations, as they could now easily exceed the bending strength of the leadscrew.

Notice also the new motor choice – now an A23-150 Ampflow motor, the “nanoAmp” motor. It’s relatively new to the market, and is roughly the size of a common FIRST Robotics CIM motor, except higher performance. This design change was driven mostly by my desire to exert a constant force on the grabber – something which the “hobby level” brushless systems can’t do yet. I wanted to be able to do this since ball screws are very low friction and will backdrive easily, so if I don’t want to lose grip on someone, I need to keep a bit of power going into the system for holding. It was then not difficult to design around a Ragebridge 2 to use the current-limiting feature, so I couldn’t accidentally bend the actuator.

According to my calculations (… I just used that for real… oh god … oh god) the maximum safe current was about 70 amps using the A23. At this point, the tip of the jaw can push with around 2500 pounds-force. That’s in low gear – in high gear, the leadscrew isn’t a limitation, since the motor can only push around 1000lb-force at stall current and I should not be stalling the A23 at full input voltage unless I was interested in suddenly making a surprise flamethrower.

Obviously not the 6000+ pounds that OH1 was capable of, but we never were able to use it in a match anyway. This new limit would necessitate redefining the mission of the bot; I’d only ‘go for the crush’ if the opponent had armor worth doing that to, such as under 3/16″ mild steel – OH1 managed that at a current of around 80 amps on the F30-150 clamp motor, yielding a force of roughly 5000lb. It managed 1/8″ steel at around 40 amps, which is still within reason for this new actuator.

There are, of course, a slew of unknown factors I have not accounted for – for example, immense friction between the trunnion surfaces could raise the maximum compressive force the clamp can exert before the motor “sees” an excessive bending moment. Or my leadscrews are made from Chinesium instead of induction-hardened E52100 bearing steel. Like I said – every fuckup I might make, right here for you to see, ON TV.

The sound you hear is everyone rushing to make weight for some titanium top armor.

Second (yes, now we get to Second) it uses what would have been one of the large cross-tubes in the upper clamp arm for one of the trunnions. This was a “might as well” type decision – I was going to have to intrude upon the volume of that tube to place the actuator anyway, and so would have had to remove that cross tube from the design. Using the cross tube allows me to still use it for some degree of anti-buckling of the side plates.

Third, wait, what do you mean “high gear and low gear”? (Go back and read the section about My Calculations™) Aren’t P80 gearboxes single speeds?

Not if you are depraved like me. Introducing the “P90X” gearboxconcept:

That is a design for a two-speed, shifting Banebots P80 (with significant modifications). I studied the design of the DeWalt gearboxes and took note of how they accomplished multiple speeds, and duplicated it using the parts of the P80 with some custom machining. In short, the ring gear of a 2-stager is split in half, with one half either forced to be locked to the housing with pins, or spin freely relative to the housing but locked into the first stage gear carrier effectively skipping that stage. Using the 16:1 as a starting point, I can get either 16:1 or 4:1.

This is a project which is basically its own story to tell, so I’ll leave the details of its construction to the later build posts. I’m comfortable with using this idea for now, since if something goes wrong or if it’s unreliable, I can always drop back to a 1-speed normal P80 like a pussy depending on who I might be facing.

Taking the ‘solid block sketch’ of the actuator and making actual features in it now. This part will be carved out of a big aluminum block – a one piece billet trunnion & gearcase. Inside, I’m making features to mount bearings. Using the maximum bending force calculations, it was pretty easy to size some big angular-contact bearings for the job. They require preload, which the ball screws I’m going to get have an adjustment nut for (They’re from the same vendor as the ball screws for OH1).

With some details in, I started placement of the assembly to fine tune external dimensions. This is the “motor high” position now.

And the new “motor low” position. Still not a fan of potentially exposing the motor to a wiggling 250lb opponent, even though it gets me more range of swing on the forks:

As seen here, the “motor high” position current causes the motor to be the hard stop for the fork actuation. To remedy this, I was going to give the clamp arm sides a small extension behind the motor. The “motor high” position causes me to lose around 7.5-10 degrees of possible fork swing. I think I can deal with this.

Moving on to more details! First, I had to reconcile the size of the actuator body with the necessity of mounting things into it. This meant making it ever so slightly wider, to accommodate both case screws and discrete gearbox mounting screws.

I briefly entertained the thought of integrated P80, meaning swapping the gearbox front output plate for an integrated bearing pocket & ring gear holding socket, but decided against it.

In retrospect, I probably should have done this to save some motor mounting volume – it’s not like it’s hard to remove the front plate from a P80 if I had to swap stock gearboxes, and my P90X design could also be accommodated since it simply replaces the center ring gear portion. As long as I was having something super custom machined…

I’ve hollowed the other block to have motor mounting features and the output bearing now. From there, it was cutting away stuff that didn’t have to be there. The openings in the case are to accommodate a larger output sprocket than what otherwise could fit fully inside – I could have made the walls ridiculously thin, but why even bother at that point? Just open the thing up and gain some more sprocket diameter.

Doing it this way let me use a 1.8:1 external reduction to the ball screw, instead of the 1.5:1 I could have gotten at most otherwise.

The last part of the actuator to be designed was the….

ball screw nut shaft

Alright, I said it.

Yeah… that. The discrete rod end bearing (“ball joint”) took up an extra inch of travel for its own mounting threads, so I designed an integrated one. The extra travel gained is worth about 2.75″ of travel at the tip of the tooth due to the leverage ratio.

Test fit of the actuator in the design. Seems legit!

The retaining method for the trunnion tube, a 2.75″ OD steel DOM tube, is a Giant Snap Ring. Also note the small mini-mohawk that I gave to the upper clamp side plates. This extends about 1/4″ past the motor and will hit the top plate first. The tip radius there is fit to weld a section of 3/4″ OD steel tubing over for more robust contact area – I’ll determine the need for this “dynamically” later on.

Time for a brief aside from actuator and clampy-jiggy modeling. I’ve been thinking of ways to retain the rotating shell of the SK3 motors since starting the project, but always put it off. It’s essential that this gets supported, because otherwise, the whole spinning mass of the big outer rotor is being supported by a little aluminum stick in the middle. A China-luminum stick. That’s just asking for an impact to break the whole motor off.


So, two of the P80 mounting screws get extended another 10mm (using 50mm instead of 40mm cap screws, for instance), and hex standoffs get screws onto the extended studs. A little plate with a flanged bearing sits at the end of the standoffs, and the flanged bearing rides on the 10mm shaft nub on the back of the SK3. Self-contained and rearrangeable.

Back to clampy-thing!

The next step is modeling Overhaul’s characteristic self-righting ears. Everyone seems to think they were decorative, but they were vital to OH1 being able to self-right.

Überclocker, for instance, is short enough with the fork and clamp down to fall onto its back, from where I can swing the forks up for quick righting. The curved upper arm of OH1 (and OH2) means the tilted upside-down position, where the bot is roughly at 45 degrees rolled over, is stable. This is bad. We discovered 3 days before ship that OH1 could not get out of this position in any way.

The ears were added to artificially shift where the stability point was, such that with some arm movement downwards, we could guarantee the bot falling onto its back, and then being able to push upwards and over. OH2 should be able to “dynamically self-right” easily due to the sheer speed of the fork, but better to have insurance.

I decided to make the ears one-piece from a bent steel plate for easier fabrication. The weldment would use two points on the upper curve and then a tangent to one of the cross tubes for alignment. All-around, better than the freehanded triangles of the OH1 ears.

Cutting out a few ounces where it wasn’t needed to support the weight.

And here we have them attached to the upper clamp arm.

The shape and extents of the ears are not settled. In fact, they will NOT be settled, made, and attached until we get OH2 together for a self-righting test. By Inventor’s center of gravity calculations, this shape should work in most arm-down positions. But real life testing will be needed to validate this part.

Up next: Electronics, electronics, and more electronics. As a mechanical engineer, I am obligated by oath to leave “the electrical stuff” for last!

The Overhaul 2 Design & Build Series, Part 4: Ramps, Forks and Clamps, the Pointy Things CADpocalypse

Mar 15, 2016 in BattleBots 2016, Bots, Events, Overhaul 2

In this part, I’m moving on from the aluminum parts of the bot and putting in some REAL STEEL. First order of business is designing the front armor, the angled pontoons for which Overhaul 1 was somewhat famous for. Next, I’ll put in the lifting forks, and finally the Razer upper clamp arm which is supposed to Razer come down on opponents and mercilessly crush them like Raz… hey, wait a minute.

Welcome to the Overhaul 2 Design & Build series, episode 4: A New Work Plane. Because that’s what’s going on here. So many work planes

The work planes are where sketches are drawn to make the solid pieces. While Inventor will let you sketch directly on the surface of a part in an assembly, I wanted to keep this part a little more separate from the assembly. Therefore, these work planes are defined from the assembly parts, but will still be around if I delete the part (e.g. to replace it with a new version), or edit/delete a frame part.

I honestly didn’t know what I was aiming for when I started. I knew the general shape of things from the sketch model, so I just started making a basic wireframe. The best term I could probably use to describe these first few versions of the pontoons was “Gundam armor”. Impractically faceted and pointy, and likely very hard to make in real life.

Here’s one completed example. I wanted too many things out of one design – the flat sides for easy attachment to the shock mounts, the sloped outsides to deflect KE weapon blows, and the sloped upper panel to protect the liftgear and better act as a w*dge passive-traction-leverage-implement. (It’s no longer polite to say w*dge in BattleBots!)

That’s how many work planes I got up before I decided to just start over. This was the accumulation of 3 revisions, so it included a lot of angles and facets I ended up ditching.

Here we are, after tossing THAT part in the dumpster of bytes. This shape more approximates the original sketch, with its sloped sides and double-angle front. I initially did not pursue this because I was thinking that modeling the non-straight sides would be a pain. To generate the surfaces, I use the wireframe (made of many sketches on different planes) to generate boundary surfaces in Inventor.

The double-angle front armor was borne of some musing about how to overcome horizontal spinning weapons. You can usually do only two things with big KE weapons – absorb them, or deflect them. The former usually ends quite badly.

We saw in the Bite Force vs. Tombstone final how effective usage of material geometry can bounce KE weapons around, since no matter how  much energy you pack in a weapon, your bot still only weighs 250 pounds. The idea of the double-angle pontoons is similar to that of a Jersey barrier, which is designed to bounce wayward cars back towards the correct side of the road. The lower angle slope guides the weapon upwards, and then the sudden higher angle slope destabilizes the now elevated weapon. The height of the angle change is set just barely above the average blade height of all the big hitters at BB season 1*

Adding to this deflective geometry is the soft rubber mounting points, which on a good connect will squash and cause the pontoon to come into contact with the ground. The hope is that this will basically mean the opponent suddenly reacts against the arena floor, adding to the bounce effect.

That’s the theory – we’ll see how it works in practice. But the effectiveness of even a single angle, solidly mounted deflective plow can be seen in the snippets of Captain Shrederator vs. Stinger (trust me, it was even more awesome in person) as well as the Bite Force final.

*The sound you hear is everyone rushing to build variable height weapons

Adding more of “the details” to the pontoons – now they have vertical panels and bottom plates. These are all still surfaces. The plan is to use this part made of surfaces as a reference to “grow” the final plate models from.

For now, I left this surface as-is since at the least I’ve defined the shape of the pontoons and therefore the shape of the front of the robot. I moved onto the next Most Critical Module, which was the lifting arm assembly.

I burped this out after a few hours of thinking about how best to attach the forks. Fundamentally, it’s a big center hub with an ear attached to it where the lift actuator will eventually mount – dimensions and spacings for this were guessed, since I hadn’t designed that yet and wanted to keep it flexible. A similar structure appears on Uberclocker Remix on its main lift shaft.

For OH2, I wanted the forks to be easily removable in the event of oh god I got owned but somehow won. To do this, the fork arms can’t be made a permanent part of something, and the attachment method also needed to be rigid in bending as well as be able to handle what might end up being thousands of ft-lb of torque if I actually use the full crush force on something.

I decided on a dead shaft system where the fork arms also have bearings (rather, just bushings) in them with the hub a separate piece. Eight 3/8″ threaded studs are anchored into the hub, and the forks are retained by 8 nuts once they are slid onto the hub. The way to quickly remove the forks would be to remove the lift shaft (two bolts), then undo 8 nuts per side, and then slide them out.

The lift hub is therefore a totally indepedent structure, so I could conceivably run OH2 even without arms or without the clamp for some reason.


Because this thing will be reacting all of the clamp actuator force through itself, I decided to check in on how the material was going to handle it. Having a 5″ round wad of solid aluminum in the center is great, but not for weight. I wanted to see how far I could hollow it out while retaining rigidity, so it was back to the good ol’ FEA tool.

If you haven’t ever seen FEA before, it basically does all of the stupid bending-twisting-beam calcualtions you had to do in engineering school by hand with a stupid lookup table (IF YOU’RE LUCKY AND HAVE A VERY GENEROUS PROFESSOR), on very finely subdivided elements of the part such that the result is a model of how a very complex geometry reacts to forces and deforms, broken down into simple numerical problems for the computer to crunch through quickly. Quicker than you. No, I’m not bitter about my Mechanical Engineering degree or my classes at all. Why would you even THINK that????

In a typical FEA simulation, you set the constraints (how the part can’t move), set the loads, the materials, and any contact conditions (e.g. between 2 parts, between 2 materials), and let the computer have at it. There’s many ways to do FEA WRONG that I won’t get into detail here.

Here, I’m doing a bending force analysis on the point where the clamp actuator mounts. I wanted to see if this would cause problems with the whole thing deflecting when OH2 mashes down with a few thousand pounds of force. The conclusion is that no, this hub is fine. Double shear for the win!

I usually design to Yield Strength for materials (the point which a material bends). It’s more common to design to Ultimate Tensile Strength – the point when the material breaks. I prefer Yield because if something bends in battle, you’re hosed, but this won’t put any planes in the air…

Having run through the hub once, I started generating the lifting forks. They’re going to be made from some steel tube and some steel plate, cut out into scientific shapes and joined in less than scientific ways by yours truly.

At this point, I was still interested in curved forks. I wasn’t quite sure how I was going to make these yet, but hey, why not try CADing something different? The tube profile was generated with a Sweep of the square tube profile (modeled without fillets).

Now in solid form…

I did something slightly nontraditional here, and made each of those elements you see – the tube, the tube caps, the fork curved square tube, etc. a separate solid body in one single Part file. This let me easily reference the parts off each other. To break this down into things I can cut, I highlight and save each solid body individually.

Modeling the “fish hooks” at the end from what will be waterjet-cut steel plates.

Time to see if this fork can stand up to the maximum force exerted by the upper clamp arm. This is a view of the “finite elements” in “finite element analysis” – the computer solves iteratively how each of those little triangular sides deform based on some relatively simple continuum mechanics rules. I modeled for 2500 pounds-force per side, at the tips. This is basically the full, err, bite force of the upper clamp arm (ideally each fork seeing 1/2 of the load).

First attempt: Dorky mild steel tubing.

Nope. Utter failure. Everywhere.

Second attempt: 4130 steel, normalized (not heat treated). This was assuming I could get 4130 in those needed sizes, which later proved to be a problem. This is “edgy” – the yellow on substantial parts of the tube means that on overload conditions like mashing someone into the wall, it could bend and fail there.

Okay, how about using geometry instead of more hardcore alloys? I modeled a single rib that runs the length of the fork arm on the inside. This is not preferable at all, since I don’t want to have something sticking up right where weapons can reach it, but I was interested in how it changes things.

The rib option is workable. This result is a little deceiving, since I had the force concentrated on a small region of the material (the hook), so it will deflect more than everything else. Really what I’m paying attention to is the green-yelow on the rib itself and the tube being largely blue – the rib has transferred most of the stress out to itself, which is what is expected.

The bolt holes are still a little concerning. They are, however in regions which will be tightly bound next to other parts, which simple FEA modeling doesn’t capture.

Instead of the rib, what if I just went to a thicker steel section? Here’s 1/4″ wall tubing (still using 4130 – not even sure if it existed at this point!). The performance is better than the 1/8″ tube version without the rib, but actually not too much. Since the rib is further away from the imaginary axis which this arm would bend along, it can resist the forces far better than more steel closer to the axis. Geometry!

I stuck with this for now, for the purposes of moving on. All of this analysis was really completed in one evening, by the way, so this wasn’t days and days of running simulations. I was willing to trade the inability to use all of the upper clamp force for some “easy” – roll a tube, weld some plates on, whatever.

I’m going to skip ahead a few weeks here, since I like the continuity of this thread about the forks. You’ll get to see the “final” fork design, even if the photos of OH2 from here until a few posts more will be showing this “old” design. Basically, after finishing the bot in whole, I began revisiting parts which I felt I had left “sketchy”, including the forks. In the intervening weeks, I had called around getting quotes and prices for sourcing the arm tube. I had thought I had a handle on sourcing 2″ square 4130 tubing, but I was either imagining it or they changed the Matrix between the design and my revisit.

Bottom line was that I thought using 4130 was no longer realistic in the (Time * Frustration) factor department. Therefore, I decided to capitalize on known available materials, and good geometry.

This time, I’m using a “tube and side plates” approach where the side plates define the shape of the arm and also carry the majority of the weight. The tube really is there for closing off the top and bottom surfaces (sideways rigidity) at this point, and I could even replace it with a rolled curved plate and have an H-profile beam.

This design kind of looks like the original “rib” design, except the ribs are sort of discretized into the new side plates.

The plan was to cut them from the same material as I was making the upper clamp – AR400 plate.

AR is my new favorite  material after building OH1. It’s just so good and versatile, and is my mental go-to if I need a ~140ksi yield strength material that can remain mostly flat. Usually, stuff with that high tensile strength isn’t easily welded, but they designed this alloy specifically for tacking Iron Man suits together in the oilfields with tin cans as filler material or something, so it’s also easily weldable. You do lose some strength in the weld area, but again – geometry can help overcome, or at least offset that.

Throwing it into the FEA module. I modified the location of the force so it wasn’t causing signficant deflection of a single point (the hook) – instead, it’s centered on the large planar face.

Some geometric changes and lightening holes later, and this is the curved arm design. The holes in the side lost about 2 pounds without substantially raising the stress levels.

The geometry here is modeled as “bonded”, meaning no movement at material boundaries is permitted. Clearly this isn’t true in real life – to approximate it, I’d have to weld substantial portions of the holes to the arm tube, or the movement will cause one or the other part to exerience more stress than designed. FEA is one of those things which is tobe melded into everything other aspect of a design, not the end-all answer to a problem.

Skipping forward again another week or two, I was discovering that the tube rolling process was going to be problematic. First, the sides won’t be flat any more – the tube will bow out. Second, there was no tube roller nearby that could handle the material – not in my network, anyhoo. To get the tubes rolled by a known bot-friendly company would have been 2 weeks of leadtime since they were on the west coast.

So I decided to do the final refactor of the design into something which can be built right now with materials and methods on-hand. This means angles.

The “look” of OH2 had been defined by the curved forks, so I wanted to keep an element of them in the final design while hiding the square tubes. Conveniently, the curved side slats are also excellent gussets. The idea was to approximate the curve as best as I could with regular square 2″ tubing.

The above shape with the “elbow” of square tube sticking out underneath…

…which I hid with an “inverse fish hook” coming from the side slats. Hey, they look intentional now!

Looking at the analysis of this part, the problem areas are where I’d expect them – the areas of the side slats near the elbow primarily. (After this picture, I increased the fillet radii substantially and the narrow neck near the elbow was no longer an issue)

As I had modeled these new AR400 plates with anticipated cutting tolerances, there’s gaps in them which I could not force to be “bonded” contact. As a result, you can see the corners of the front angled plate being “highly stressed” – causing the safety factor minimum to be artificially low in that region. In real life, these are going to be welded securely.

Alright, time to undo the timeskip (this was “roughly week of 3/7″). Now we return to the pontoons and upper clamp arm.


I took the surface reference model for the pontoons and literally grew those surfaces into 3/16″ plates…

…and then did my usual “edge stiching” finger joint method on the individual plates. This will make the part very easy to self-fixture for welding.

More details, such as internal gussets, have been added to the pontoons, with more to come.

With the front pontoons done, I brought in some more components as a bit of “work-ahead” – thinking about the next step while I’m working on the current one. I knew what I had to do for the upper clamp arm, so I just had to crank it out while thinking about electronics mounting, the bane of mechanically-minded robot builders everywhere. Can I just cast the whole thing in hot glue and be done with it?

Coming up next: The upper clamp arm geometry and actuator!

The Overhaul 2 Design & Build Series, Part 3: The Drivetrain and Lift System CADnado

Mar 11, 2016 in BattleBots 2016, Events, Overhaul 2

Alright kids! Buckle in, cuz I’m not stopping the CADvan until I have to pee at some point, usually around Stamford, Connecticut.  Oops, sorry – I forgot that this isn’t me piloting Mikuvan on an average trip to New York Maker Faire or Motorama…

This post begins the long journey from the concept sketch model to what will hopefully be the finished design. The primary goal is to show the evolution of the design and my thought processes.

One thing that will be a little slight in these posts is technical content – the hows and whys of selecting a certain component. I already knew much of what I wanted to work with when I began, having built Sadbot as a power system mule before this all started.

What I’ll do is recap the construction of Sadbot and how many of the power system components were picked after this segment of CAD model posts – there is a lot of interesting science to help advance the state of the sport which I was able to distill. What “engineering” content there will be in this series of posts will be more centered on mechanical engineering and materials, since this IS designing the frame and structure.

We begin with the trailer photo in the previous post, the new OH2 frame besides Sadbot:


Using the information about component placement from the 3D sketch model, I began making individual part files that represented the frame rails. I tend to start with drivetrains and bases first. Not everyone does it this way, but I figure if the robot can’t move, then I’m in bigger trouble.

The choice of frame rail material is massive 1.5″ by 4″ aluminum bar stock. I went for this extraordinarily beefy material since OH2′s frame was, for the most part, also going to double as its armor. The aluminum rails will be hollowed and machined out (“hogged”) where needed to save weight. One upside of using a large starting section area is that even if much of the material is removed, it is still more rigid than a full smaller section.

Great, first I’m a Bite Force knockoff, now I’m an Icewave knockoff.

The thick rails allow the use of offset bolt patterns to increase the fastening rigidity of the joint (compared to, say, 5 bolts in a line) as well as avoiding the postage-stamp effect where the bolt holes become a neatly placed line of perforations.  But now it looks like an Icewave knockoff.

All of the frame bolts are 3/8″-16 size.

Modeling in more of the structure, including the cross-rails. The initial spacing of the wheels was determined by the sketch model, which had wheels positioned according to the drive motors. This, as you’ll see, will change a lot.

One of the first things I modeled “for real” was the drive wheel hubs. This uses a retaining ring system similar to Überclocker’s final wheel hub interation, and is designed for the 2″ wide Colson series – 5″ x 2″ in the back, 3″ x 1.5″ (with a spacer) up front.

The hub permits sprockets to be mounted on one or both sides, and the center bearing is a needle roller bearing system to minimize friction. To transmit wheel torque, the whole hub is double-keyed with 0.25″ standard keyways.

Modeling in the plate that holds the drive motors now…

One of the issues which plagued OH1 – and really, most of my bots – is serviceability. While we became fast at replacing something on OH1, that doesn’t mean it was good. I aimed to make all top-level components which could break – motors, batteries, controllers in particular – be serviceable without taking apart the frame rails. The wheels would be an exception, as the shafts make up part of the frame.

In particular, since the motors and controllers were going to be highly experimental, I wanted the ability to swap them out quickly. OH2 has four drive motors not just for power, but in part for redundancy.

Shown above is the drive motor area, where I’ve designed them to pop out the bottom. After unbolting the motor mounting plate and disengaging the drive chains, both drive motors on one side just slide out from underneath. There will be a small gap in the baseplate for the rotation space, which will just get covered with some duct tape to discourage the collection of arena grunge.

More motor mounting details get modeled in on the underside. The motor mounting plate is roughly T-shaped.

I originally had the four holes on the outside also facing out the bottom, but it would have required that region of the outer frame rail be made pre-emptively solid to accept the threaded holes for the bolts. To keep the design more flexible for now, I decided to keep the holes in the more space-saving configuration by having the bolts point into the smaller motor mounting plate.

I flipped the design back over and added all the rubber shock mounts to the top. I bought a few different candidates from McMaster-Carr prior to this, in order to appraise the candidates.

The strategy with the shock mounts (or as we kept calling them, wubbies) this time is to use many more smaller ones in a more distributed fashion. Not only will there be these facing upwards and forwards, but also some facing sideways.

When the bot loads the front pontoons this time, the six shock mounts on each side will be put into compression and tension to react the load, instead of just being bent. Twelve ought to be enough to hold the forces – if not, McMaster has harder versions of the same mounts.

I’ve generated the motor mounting plates here and have put in mounting features for the gearboxes. The holes are slotted for chain tensioning adjustment.

The vaguely completed frame so far! Here, I’ve added two of the side shock mounts. These don’t play as much of a role in a lift, but if I get whacked on the side, they help isolate the pontoons from the frame.

With all of the frame rails and critical features in place, I added a baseplate. The school of thought for fastener placement here is “Whatever patterened the easiest”. It’s likely not all of these fastener holes for #10-32 countersunk-head screws will get used.

Now that a box frame with bottom was complete, I started bringing in other parts for sizing verification.

With the shape of the frame basically defined, it was time to start putting up the arm towers.

In keeping with my preference for the “This is a drivetrain. Everything else bolts on here.” design school, I decided to make the arm towers a separate piece each. Here’s pass #1 at the design.

This was also a move for manufacturability. The idea is to make everything from the 1.5″ x 4″ barstock, and then waterjet-cut the arm tower to rough shape, then finish-machine.

Pass #1 got the idea across. I decided to use the arm towers to additionally brace the large cutout in the side rails where the motor pass through, so I extended them past the motors. Furthermore, the long rear slope evokes the arm towers of OH1 more (it had a highly sloped backside).

The arm towers are anchored with five giant 1/2″-13 bolts apiece. Nothing will fail here… if the arm towers get torn out, something very, very bad has already happened and stripped threads are no longer something I need to worry about.

Once the shape of the lift towers was set (for now, anyway), it was time to fill in the details.


From Sadbot experimentation and some math, I had a range of gear ratios which would be acceptable for the lifting forks. The goal was to get an arrangement of some combo of gears and sprockets to get into tha range.  The ratio to hit was approximately 180:1, with 16:1 of that taken care of by the P80 gearbox on each motor. This would permit the Sk3 6374/149 motors to lift a 250lb opponent at the very end of the roughly 24″ long arm at roughly 42″ per second.

Almost 4 feet per second, up or preferrably also down. Überclocker was well known for smashing opponents on the arena floor over and over, and this was a move I wanted to duplicate with OH2. That’s literally 10 times the speed of OH1′s linear actuator lifting arm.

Why gears? Remember that in the initial sketches I had a big sprocket modeled. Well, after thinking aout it during the arm tower designs, if I was going to have unboltable arm towers, then what good is it if I have to find and remove a chain master link to service the liftgear? A HUMONGOUS SPUR GEAR will permit me to unbolt the arm towers and just lift everything off for independent service, and furthermore, just smash it on and tightened the bolts down when done.

The liftgear must be then beefy enough not only to stand the static force of holding an opponent – already 500+ft-lb of torque at the lift shaft, but also the forces of me slamming the transmitter stick in the opposite direction of travel and the impacts with the floor. For now though, ratio was more important than tooth size.

The idea was to have the big gear be part of the removably top assembly. So to start off, the little gear (“pinion”) must be mounted in the frame. This first attempt was with a 3:1 output stage, which kept the intermediate stage requirements also reasonable – it’s difficult to get more than 4 or 5:1 in a single stage without making one gear tiny.

The gears shown are 6 Diametrical Pitch, 36 tooth and 12 tooth.

But that design left the pinion directly in the line between the frame and lift towers. Attempt #2 is a 4:1 output stage with a 48 tooth 6 DP gear and a 12 tooth pinion.

For those keeping track, a 48 tooth 6DP pinion is 8.3″ across. It’s the size of your face.

While the 48/12 arrangement put the pinion at a good location on the vertical axis, gear calculations showed that the tooth forces were going to be too great. The smaller the gear, the more tooth force is needed to transmit torque. I was going to have to make the gear from hardened tool steel for it to have a chance. Therefore, I downgraded the output stage to 3:1 and decided to use a 15 tooth pinion (Alright, so it’s 3.2:1. Bite me.)

To retain the ratio, the lift towers had to be increased in height slightly, which was something I was willing to accept.

By the way, these gear tooth numbers aren’t being magically summoned. I was thumbing through various gear manufacturer’s catalogs and industrial suppliers which carried those products in stock. I wasn’t going to start specifying custom-machined gears just now…

One of the difficult “real life engineering” things I tried to teach in the 2.00gokart course for the freshmen and sophomore students was that you had to be able to buy or source the thing you designed, so don’t spend too much time optimizing for the peeeeeeerrrrrrrrrfect system. Chances are, the supplier won’t have it, and your beautiful numbers will crumble to dust in front of you like a timeless story of fairy tale justice.

Since both 48 and 15 tooth gears existed in real life, I settled on that for the time being. Now it’s time to design the intermediate stage. The input ratio – 16:1 – and the out ratio – 3.2:1  – were both anchored. To hit the target ratio, I needed a 3.75:1 intermediate ratio.

I had to play some geometry games. Shown above are the two lift motors, each with a 12 tooth pinion – the smallest available pinion in that Diametrical Pitch with a 1/2″ keyed bore. And really, the smallest gear I was comfortable fitting on the motor shaft due to the bore size. Any smaller and the distance between the keyway in the gear and the bottom of the tooth become very small, risking it failing there.

With a 12 tooth pinion, to get a 3.75:1 ratio I would have needed a 45-tooth gear. Unfortunately, I couldn’t quite find a geometric solution here. The diameter I would have needed to fit the 45 tooth gear meant pushing the lift motors further apart and further down. The baseplate is one constraint, but the shaft axes impinging on the drive motor area was another one. Plus, nobody seemed to have 45-tooth gears in stock. It’s a bit of a weird tooth count.

A 42 tooth gear made for a near-perfect arrangement where the motor were seated on the baseplate and also spaced closely together. This meant I could only get 3.5:1 in the space, leading to a total ratio of 179.2:1 from the motor.

Okay, whatever. That’s 180 enough. 2 plus 2 equals 5 for large values of 2, and sufficiently small deviations about a designed optimal point will generally go unnoticed for the majority of loads. I was honestly happy I could get close to 180 at all. The best part? Everything was in stock!

I moved forward with the 42-tooth intermediate gear. At this point, I also began to think about how to clutch the output shaft. Having such a high gear ratio makes your system prone to inertial damage. The very act of suddenly stopping – like slamming an opponent on the ground – causes the motor’s inertia to be magnified many times through the gear ratio, adding more stress to the gear teeth in a very short amount of time.

Plan A of clutch design was using a Trantorque keyless bushing. These things are cool. When you stuff it into the bore of your gear or sprocket and tighten the nut, the outside collar expands and inside collar contracts, causing immense friction. That’s how it transmits torque. Transmits. Torque. TranTorque. Hey, I think I get product marketing, guys!

My plan was to purposefully half-assedly tighten it onto a hardened and polished shaft such that it could slip at some hopefully pre-determined load. Hardened and polished is critical so the surface does not gall up and destroy itself – both the smoothness and hardness are important.

How do you size gears? Well, you could pick up a mechanical engineering textbook and do it OLD SCHOOL COOL, or use the gear generators and analyzers now built into many modern CAD packages. These are the equations and tables in those textbooks packaged in a way a lazy millenial* can understand.

That’s how I found out the 12 tooth pinion was going to be very unhappy. The key number for my purposes is the Sf value to the right. That’s the Tooth Breakage Safety Factor. That’s what you DON’T WANT TO HAPPEN. For the 12 tooth pinion, it was getting awfully close to 1 – and by that I mean like, 2 or 3. In robot-smashing duty, you never, ever design anything for a low safety factor. I’m sorry, aerospace & rocket folks. Your robots always lose for this reason.

Gear 2 is the larger gear, and notice how its safety factor is something like 7.6. This tells me the gear material is very much overkill for strength. In fact, it might be fine being made from aluminum. I decided to keep modeling it as steel for now for weight purposes. When I need it, I’ll hopefully be able to shed a few pounds by moving to aluminum – this would entail, for example, waterjetting an epic gear from 7075 plate or similar.

The other very red and concerning looking numbers are not of interest to me here. One is the Tooth Pitting safety factor, and the other is the Static Contact safety factor. These are important if your gears are running for a long time and you’re looking for longer term tooth wear reliability. All modern gear design methods factor in many different little environmental conditions as well as the desired running lifetime.

For me, that’s like, 5 minutes – so I really only care about teeth breaking.

*Note: I am probably on the very trailing edge of who’s usually considered millenials these days, being a product of the late 1980s like my van. I use the term both to express indignant outrage and to disparage my peers’ achievements depending on what is politically advantageous at the moment.

Using the Trantorque GT clutch-bushing idea, I continued to build up the infrastructure of the liftgear. Here, I’m putting in downloadable models of bearings and shaft couplings to see how much space I have.

One design evolution was in the length of the bot at this point. I wanted the liftgear to be double-supported, meaning they were surrounded by frame rails on both sides. This enhances the rigidity of the area immensely, since the gear loads were no longer being supported by twisting the front frame rail.

But already, there was no space to put a secondary frame rail here. The lift motors and drive motors were too close together.

Solution: Make the bot an inch longer. The 3 vertical holes are for a 0.75″ thick transverse frame rail to help bolster the motors.

As seen here!

Alright, a few days after this design session, I received a Trantorque GT bushing I had ordered in the mail. Conclusion: no

Not because the idea was flawed, but that the bushing is made from a soft steel. After all, it’s supposed to be mushed into the bore of a large fan pulley or something and stay there for decades. I became concerned about controlling what slips on what using this bushing. Bushing slips on hardened, polished shaft? Sure. Bushing slips against bore of unhardened, similar-alloy steel gear? Bad. I’d be machining the bushing out after that.

So I threw that idea on the ground and decided to make my own. Shown above is a very drastic torque limiting clutch.

Here is a cross section of the clutch. I just took an industrial torque-limiting hub for sprockets and made it longer.

Those things are really simple. A big nut pushes a (usually) Belville Spring onto a pressure plate which is keyed into the shaft, and the pressure plate is what transmits the torque. The brown material is clutch pad, which McMaster-Carr sells in VERY EXPENSIVE sheets.  Some quick calcs show that this clutch should be able to hold up to around 500 ft-lb of torque with that big Belville spring I picked out from McMaster-Carr (which sells it in VERY EXPENSIVE packs of………… 1). There might be a pattern forming here, I think.

Dropping the new torque limiter in the CAD and continuing to build up infrastructure by air-placing parts.

A set of spider couplings join the gearbox output shafts to the intermediate gear stage.

This is here for 2 reasons. First, for springy compliance: While the big torque clutch gives frictional compliance, a single high-energy impact, such as getting tapped by the Pulverizers or an opponent bot’s hammer or being run into a wall with the arm up, etc. could still put enough energy past the intermediate gear stage before the clutch even starts slipping to damage the gearboxes. The springy compliance absorbs this brief input of kinetic energy by deforming the rubber/urethane core of the spider coupling.

So the liftgear has two protection mechanisms. The torque clutch prevents the motors from driving and overloading the mechanism, while it and the spider couplings work together to prevent external driving forces from being shoved back into the motor with a vengeance.

Once I was happy with the air-placement of everything, I began wrapping frame rails around them.

Here, reason #2 of the spider coupling’s role is revealed. I’m also using them a bit as dog clutches in conjunction with a motor mounting block that can be unbolted and slide out quickly should something bad happen to the lift motors and they need to be replaced. Another design for serviceability factor!

This basically concludes all the design work on the liftgear. From here, after letting the design bake for a little while, it’s time to move onto designing the front armor pontoons.

We begin with a bunch of reference planes…

The Overhaul 2 Design & Build Series, Part 2: How to Design an Overhaul!

Mar 08, 2016 in BattleBots 2016, Events, Overhaul 2

In the previous post, I presented a summary of why overhaul1 sucked the various shortcomings of the Overhaul 1 design. This will be the first of two (or more…) posts which heavily dive into the details of CAD modeling, and SOON! you’ll get to see the Overhaul 2 design in its entirety. The idea of these posts is to show how the design evolves incrementally from the crude sketch to complete model…. and also the little changes made to it even after it’s “complete”, because that happens every time. Always.

My software of choice is Autodesk Inventor. Yup, I’m a child of the Autodex. They got to me first in 2005 when I was a wee lad high school sophomore, with handing out Inventor Professional to FIRST Robotics teams. MIT largely ran off Solidworks, and during my time as an instructor I also taught intermediate to advanced Solidwanking (that’s a technical term) for the design classes, but whenever I do something for my own projects, Inventor is still my go-to.  These days, Autodesk tends to push Fusion 360 to the maker crowd and it’s generally free with limitations. Even just a few years ago, if someone asked me how to start using CAD programs, it was hard to give an answer that was accessible. That’s changed now with Fusion, 123D, Onshape, and other platforms, which is great. If you’re a student or have .edu affiliations, you can get students’ and instructors’ licenses for Free (as in Beer) from Autodesk Educational Community for a few years at a time.

So anyways, all the screenshots you’ll see will be out of Inventor Professional 2016. My opinion is that on the average non-commercial (or even light commercial) usage level, the difference between Inventor and Solidworks is largely like Ford and Chevy – largely the same features, same commands, and same structure are seen in both, with some nitpicky differences such as I’ve never successfully turned on a headlight in a Ford car, I’m pretty sure. “Solidworks vs. Inventor” is like the vim & emacs debate of CAD students, so I’ll just say that I’ll have none of it here.

Let’s begin with the sketch from July 2015.


This sketch was actually the last in line of several I was playing with, which sadly were not saved. It originated from the desire to push the “dustpan” front end of the robot into the drivetrain a little, such that I could have front wheels almost directly under the center of lift. This was something that we played with for Overhaul 1, as shown in this CAD party photo from last year.

As can be seen, the bot was a lot more sloped, and the earliest designs of the shuffler modules reflected that. We were going to make the front armor heavily sloped and stuff the front of the drivetrain under it. But that evolved away for reasons which I do not remember well – possibly ease of fabrication focused.

The rest of the shape of the sketch followed the thread of putting wheels under the new dustpan region. Those wheels had to be smaller than the others, which was fine. I originally had the design as 4 wheels instead of the 6 shown (3 per side), and I think that would have been passable. However, I decided to explore 6 wheels to give me more options for wheel placement – basically, tuning the “front” and “rear” wheelbases independently as needed. 6 wheel drivetrains also have the benefit of being able to place the center wheel very slightly lower (“drop center”, for you FIRST kiddos) such that the bot is basically 4wd at any point in time on a shorter wheelbase, preserving turning speed while affording a large stable base.

Beyond that, the sketch was simply “what looks kind of okay” on the dustpan profile and body length I drew. There was no science behind the other dimensions – I just wanted something on screen to stare at. I liked the idea of a multi-faceted dustpan for cool looks, but wasn’t entirely set on it.

Fast forward to October. Season 2 was supposed to have been announced 3 months ago and I was in the middle of RageBridge 2 development, when suddenly, applications for #season2 opened up! Uh oh, now I actually have to put things in the frame sketch. It became obvious very fast that this bot was too small – nothing useful could fit inside the space as-drawn, even though it looked nice and compact!

So I made it longer.

As you can see, I literally made every dimension a bit longer, and put some sketch boxes in to represent motors and stuff. Also shown in this sketch is an imported side profile of Overhaul 1. Yes, even after stretching the new design (“Holy crap, 3 feet?!”) it was still shorter than Overhaul 1.

This sketch was reasonable to start making “3D” so I could start playing with placing part models.

So I did just that! I took this sketch, stuffed it in an Assembly file, made it a reference drawing, and started extruding parts off it. Just solid blocks.





Everyone who saw this sketch model said it looked like Bite Force. Well gee, I’m sorry not sorry if some times in engineering there is an optimal geometry to get something done. That’s going to start biting BattleBots in future seasons, I think, when more of the design space is “claimed” by certain successful designs. But we’ll burn that bridge when we come to it, as I always say.

Noticeable additions to the sketch include little side strakes on the lifting arms. I put these there for looks largely, but Überclocker’s “fish hooks” have been wildly successful in snaring bots that the fork gets under, so I was planning on including similar entrapment devices. Did I mention pointy bots look cool? They do, right!?

Another side profile shot with OH1 in the background as a halo.

Whoa… quite a jump from the last picture here. Actually not so much. I just hid the square arm and replaced with with 1/8th of a circle that intersected the lift axis and was tangent to the ground, and then extruded a bunch of shapes off it. I think this looks cooler – the curved arm works well with the upper arm (which has been separated into individual pieces, but still all driven off the big assembly master sketch). Not only that, but the constant curvature is stronger than a sharp angle joint with faced with the bending forces imparted into it by the top arm.

I was playing more with the top and back sides of the bot at this point, trying to emulate the sloped-back look of OH1. I made a simple Sheet Metal part with 2 bends in it to give some more non-square shape to the sides. And the cherry on top was of course the now-classic Overhaul Ears, also a Sheet Metal part that was referenced from the top center hole in the arm.

Nothing in this assembly can move – it’s all just sketches and extrudes. It’s a visual clay-model for me to think about the shape and size of the bot.

This is the previous sketch model with the top plate removed. The arm towers just grow out of the big solid rectangular extrude feature that is the body, so my next step was to hollow it out a little bit to add part models inside.

Now it’s starting to look a bit like a robot. I stuffed some sprockets in to get an idea of plausible drivetrain scenarios. How much chain/gear/belt ratio you can use is largely dictated by things like wheel size, and that’s influence by robot shape. I grew this design from “robot shape” downwards – many people grow designs from “I have this motor” upwards. In this case, since it’s a bot which is trying to take after a previous design, I wanted to establish the form first.

Notice also that the bent-style top plate is gone, in favor of a single flat plate that forms the sloped back of the bot. Again, just playing with shapes – I decided to let component placement dictate where I put top armor and back armor. So long as things fit inside, we’re chill.

Look! It’s Sadbot! I have a whole build report on this thing that some builders in the community will find very interesting.

Especially after this next image.

Here I am trying out a few test components. Keep in mind that these were all part models I had on hand, or extracted from manufacturer websites. The blue bricks are batteries – the same 8.0Ah, 18.5V lithium packs we used in OH1, just a flatter configuration. The purple things are motor controllers, and the gray cylinders are motors themselves. These are quite different from what I’m used using in bots, especially big ones.

I can hear jaws dropping, the “I KNEW IT”s, and the finger snapping from some of you already. Again, explanations in due time, I promise.

Also shown in the photo – on the right upper corner, two Whyachi MS2 switches, since the new rules required separating drivetrain and weapon power, and some more big sprockets and gear models downloaded from McMaster-Carr to, once again, get a rough idea of how much gearing I can put into this frame. Less than 2 hours of clicking around separate the last two images, so no magic is being exercised here.

Here is a different configuration of the interior. Motors and controllers are often the biggest-ticket items in a bot design, so you kind of wrap the thing around them because they ultimately dictate how your robot drives and behaves. They’re also the juiciest and most prone to damage from abuse, so it’s good that everything is kept in the center.

Instead of a “2 x 3 stack” like previously, this arrangement is just all the motor controllers in a row, laid out flat. I liked this arrangement more, because it lets all controllers be accessed equally for replacement or service if needed. I imagined just having a huge bus rail attached to the battery pack that the controllers plug into, so I can rip one out easily if need be. Their heat sink fins being vertical also helps for heat dissipation, which if you’ve read enough RageBridge development posts, is the number 1 enemy of motor controllers.

The 7-in-a-line arrangement was very tight on space though. I could have made the bot wider – and did, briefly. But on one side of the bot, I played around with pushing the drive motors further out. The gearboxes shown in the design are Banebots P80 gearboxes, which proved themselves well on OH1′s lifter and clamper/crusher gearboxes, so I contemplated using them for drive. Part of Sadbot’s mission was to see if a few of them could handle a 250lb-class drivetrain. In this sketch model, I had the bright idea that I’d basically use the P80′s longitudinal structural bolts to mount them to the frame – just use longer ones, so they poke out the back of the gearbox.

Pushing the drive motors further out enabled me to free up almost 5″ of interior space across the width. That was plenty to put the controllers in, separated comfortably, with room for future mounting hardware, since you don’t just throw things inside a bot frame and hot glue them in…. Okay, fine, some of you do.

It was in this state that I submitted the application to BattleBots for Season 2 in late November. Everything KIND OF makes sense, everything OUGHT TO fit, and SHOULD work on a good day. Seemed legit to them!

As for how this region ended up – here’s how it looks in the finished design.

well that escalated quickly

Some things changed. Some things are gone. Some are still there! The next few posts will tell the story of how everything got to that point. You know how I said “oh, not much work separated these two images”. Well, a whole lot of damn work separated these last two!

It was now late November. Time to stop CADing for giggles, and start CADing for real. This is where it begins….