After season 2, I had a whole list of changes I wanted to make and “design regrets” …that I wanted to address.

Really, I… see #season3 as a chance to do Season 2 “correctly”, addressing things that didn’t go the way we want or designs that could have been done better.

And frankly, anybody trying to build from scratch for the season now is either a dumbass or more of a man than I…

-me, some time in 2018

 

AAAAAAAAAAAAAAHHHHHHHHHHHHH

Those words have come back to haunt me.  Great! That’s totally never happened before, right? 

Okay, okay. No more vans, I promise – not for a while, as the Cold Brutal Winter of I Hate New England Weather has fully settled in. Here we are, on the cusp of another potential (#NextWeek) BattleBots season. I still owe the world a “event report” and summary for BattleBots Season 4/2019, which I went to anyway and set up in the pits as a Ragebridge dealer.  While I obviously didn’t bring Overhaul nor was involved in any of the matches, I did get up to a lot of Learnin’ and Talkin’ to with everybody there, as well as some incidental brushless motor troubleshooting. I tell you what, kids: brushless motors are a mistake.

My takeaway from the whole two weeks of hanging out with everyone, watching all the matches, and being in the pits acting sporadically helpful or like a nuisance? The metagame has moved on, and Overhaul has to move on with it. Consider this post really a recap of all of the off-season work since then, up until a few weeks ago which I’ll cover more in detail as this post series grows. Sit down, because it’s gonna be long and filled with Philosoraptor Charles Mangst!

The Exposition

Coming out of Season 3 in 2018, I was actually very satisfied with the bot mechanically. Here’s what that entails:

• The Fantastic Combination Gearnut and packaging of the clamp actuator was greatly improved over the Season 2 ball screw design, and it worked swell the entire time. This part – and really the entire updated clamp arm for S3 – is probably going to make a straight unedited return.
• The frame brace that was added to the intersection between the outer rails and the front crossing bulkhead greatly increased the rigidity of that area, to the point where there’s no visible deflection even after getting thrown around by Witch Doctor and Warhawk.  To be fair, OH got some reasonably softball matches that season, and I’d love to see just how it would have done in another old-Cobalt style hit. But it truly was a hack to try and patch a deficiency in the original design.
• I was super into the redesign of the main lift hub, which was really my first on-purpose designed hollow weldment with attachment features. It  had a larger radius of engagement (bolt circle) with the lower forks, and enabled the forks themselves to be a single design instead of having 2 mirrored configurations.
• The cast wheels and drivetrain proved also reasonable in service. The front wheels ended up being a little too fragile and had to be replaced almost every match, but I didn’t have any SET SCREW PROBLEMS this time at least. In all, even during Season 2, the drivetrain of the bot hasn’t been a source of mechanical headache – remember in S2 I drove the entire 3 minutes, even if underwhelmingly, against Beta, and this time around barring fire issues Overhaul was in pretty constant motion the entire time.

So in summary? I did get to do “Season 2 correctly” in that limited sense. But obviously, the whole bot catching on fire issue was…. suboptimal, among other emerging and now very salient problems.

The Conflict

So did I REALLY “do Season 3 correctly” either?

Brushless Rage was tested on the bench under some simulated use cases including throwing big hub motors around. But what I wasn’t able to make time for was actually putting the system in the bots, including Sadbot, and then driving it around enough to discover the transients that would ultimately cost it matches. The development of Brushless Rage took some of 2016 and 2017 while first I was kept busy at the (then) new shop space doing consulting work, and then the startup itself ramped up significantly closer to the back half of 2017 and going into 2018. 6-FET Brushless Rage has, by now, proven itself to be rock solid in the lighter weight classes, but I could not test 12-FET to discover its limits effectively.

Not that I’m blaming it exclusively, mind you: a few other bots including Brutus and Predator actually ran it fine for multiple matches during the season. Instead, in light of some new testing performed recently with Sadbot and Overhaul itself, which I’ll discuss here in the near future, I’m rather convinced that the interaction between Overhaul’s split drive motors (i.e. two ganged motors per side) was what led to my FIERY DEATH! problems.

Here’s what is going on in the Overhaul 2.x drivetrain. I have two 63mm brushless SK3 motors per side, each going into a Banebots P80 gearbox that’s a single stage 4:1, and the outputs joined by a short chain.

Seems legit, right? The problem is, if you hold one motor still, you can just about rotate the other motor a half or even 3/4 of a turn before the slop (made of two 4:1 derp-tier gearboxes and a kind of loose chain) is taken up and you actually “feel” the other motor.

The problem comes when direction changes and stops occur. No ESC is ever perfectly timed, and no R/C pulsewidth is noise-free. Nor can you guarantee the motor stops in a useful position to quickly push the other way.  Therefore, the chances are high that in stopping and direction changes, one motor acts first – and promptly runs into the other, possibly desynchronizing with the ESC momentarily too. When this happens with a brushless setup, you usually get high surge currents for that instant. Add up enough of them and I can pretty easily see the Brushless Rages simply overcooking themselves in under 3 minutes.

It took driving Overhaul hard around the expanses of the new shop which the company moved to only this past March, with the lid off, before I was able to witness this in action: some times, one motor will just start before the other on the same side. Before then, I’d never been up close to the bot as it was rapidly changing direction, turning, or stopping (…for good reason, I maintain). All because the old shop was too small and confined to safely do it, and the lack of ground level access and dismal state of the parking lot anyway meant the psychological need wasn’t there. It “drove fine” in the limited context of the shop floor, so I hoped for the best.

The original premise of this design was to load-share the 6374 motors, which definitely have adequate power output ability to drive a heavyweight around on only two, but which do not have nearly the thermal mass needed. Work done is still work, and the same amount of energy heating up a smaller mass makes it much hotter.

But in retrospect – and only can I really say in retrospect now because others have done it as an offshoot or variation on this design – the way to do it would have been to gang the motors together themselves, instead of through gearboxes. The Robot Wars entry Magnetar (and Pulsar) built by contemporary Brushless Hipster Ellis in the UK illustrates this: two 63mm brushless motors are ganged onto a single bull gear directly. There’s minimal slop between the two, virtually eliminating the chance of the motors contesting each other.

I’m not gonna write the OH2.x design off as “too complicated” – really, the mechanicals of the thing never gave us any problems in the pits. It was designed to allow quick disassembly of the frame rails and replacement of wheels, and it fulfilled that role well. We never had spontaneous chain-falling-off or wheel-jams-up issues like so many bots did (…minus #SetscrewGhazi). What I chalk it up to be is a 2nd-order phenomenon (slop between motors) that interacted very poorly with the control architecture (dumb R/C-style sensorless commutation) and whose cumulative effects (overheating and failure of one or both controllers) were not discovered due to lack of stress testing.

And I stuck with it for 2 BattleBots seasons – one because I didn’t know better at the time, and the next because I didn’t really have the time to deep-dive into these assumptions. As for why Overhaul didn’t catch fire during the regular Season 2 matches? Well, remember the 3-way “MIT Rumble” at the end. It did consume one of the dLux ESCs, and it was a match where I was much more involved in pushing and shoving and trying to flip Road Rash back over. In the Cobalt match, #SetScrewGhazi ended the match early. And I spent most of the Beta match running away from it!

I don’t know how much it all mattered in the end anyway, because the fact of the matter is: I never liked how Overhaul 2.x drove. Not with Colsons, and not with the urethane cast wheels.

Here’s the plight I face. Everyone plays me up to be a “good driver” because of my historical wins and my usually more showy driving style. I’ve never been able to bring it to bear on the TV show. It hurts to watch OH2.x matches, and believe it, it was even worse physically being up there. Unlike Overhaul 1, and by derivation Sadbot, OH2.x seemed sluggish to respond to inputs despite being – or maybe BECAUSE OF being – overpowered drive horsepower wise. I never felt one able to put the power into the box floor. Missed charges, lost or parried pushing matches, and just plain to-the-audience questionable maneuvering were all symptoms. Like just go back and watch Overhaul 1 and Bite Force 1 again. I live for driving matches like that, and OH2.x has not been able to follow through.

Remember the Sadbot driving video I linked above? The difference between doing that with Sadbot and trying to do it with Overhaul 2.x is, at all moments in that video I felt like I was in full control of Sadbot. With Overhaul, similar attempts this year felt stiffer, and the bot was less able to effect turns predictably – even after all of my arena time with it, on a bare polished concrete warehouse floor, I found myself going “Wow, this thing drives like garbage”.

If I actually ran this match, I’m fairly positive in Sadbot being able to win 100% of the time.

 

Part of it is geometry. Overhaul 2.x has a square drivetrain layout, where Overhaul 1 rested mostly on its front 2 wheels with a wheel arrangement that is much wider (track) than long (wheelbase).  Sadbot, using the same drive system but with a very central weight bias, handles even better. A slightly oversquare (wider than long) drive will be more favorable to quick turns and controllable slides, whereas a longer-than-wide setup is going to favor a more point-and-shoot driving approach where you tend to separate turning and forward-backward driving into more discrete events.

The other part of it, as we mused over in the pits at Season 4, is just sheer contact area. Academically speaking, no robot should ever have a traction advantage over the other except as a function of wheel compound softness. Because hey, Fₜ = μFₙ right? That’s how it’s presented math-wise in robot land, and is how must physics students learn about friction. And if both bots weigh 250 pounds, the vernacular rule of thumb always goes “softer tires win because the same weight will press downwards no matter how much contact patch there is”. Go ahead – ask a question on any robot builder group if treaded wheels are “better” than slick wheels.

What I think the basic theoretical treatment misses on is how dynamic forces from robot motion, wheel compliance, and weight shifting affect both contact patch and resultant available friction force. Think of it this way: A small and relatively stiff wheel like a Colson will never really change its contact properties with the arena floor no matter what angle you mash it into the floor at. It’s going to be tiny relative to the total wheel circumferential area, and vaguely parabolic or elliptical-looking.

However, a big go-kart tire, despite being made from a “harder” rubber compound, is designed to deflect and comply with the ground. A solid foam tire might be somewhere in the middle, offering more stiffness except when you really are putting power into it, deforming the foam carcass. What it means on a high level is that the contact properties with the floor exhibit a very wide variation with the potential for simply more favorable solutions to transmitting the total available drive power of a bot to the ground. I can’t really substantiate this without writing an entire thesis on it, but a gaggle of robot nerds petting each others’ confirmation bias is at least 80% as reliable!

In other words, what a few of us pretty much concluded from the mutual chin-cupping and nodding of this season was that if you wanted a quick yet maneuverable bot, you pretty much had no choice but to use acres and acres of tires. Compliant, bouncy tires, of almost any compound and material. The most stupendously driving bots in the game – designs like Stinger/Sewer Snake, Hypershock, Free Shipping, Sawblaze, etc. all just have obnoxious amount of wheel – go look at their official bot photos.

Too much wheel for me, historically speaking. I grew up on the romance of graceful, low profile bots like the original Biohazard, and this has carried over in some way for almost all of my robot bloodlines. Even Overhaul 2.0 was, in a way, a romantic testament to the low-slung billet-machined box.  Take the top half of Overhaul off, and it’s just as nice looking as a flat lifter-box style of bot from the Classic Days. In fact, at one point, I was going to run “just the bottom” as a Middleweight at RoboGames.

That preference, I realized, also comes back to bite me when it comes to driveability. Small, rigid wheels are better suited for the point-and-shoot bots because their inflexibility also means their regime of best tractive performance is more limited.  My general feeling is that the custom cast urethane wheels with tread lines made OH2.x traction more linear and predictable, due to being able to clear box floor debris, but not necessarily any greater in magnitude. It was, at least, consistently bad to drive and I felt like I was able to somewhat work against it – but put me in a match where the opponent had Acres of Tire such as Sawblaze and even Witch Doctor at the end of Season 3, and the difference became stark.

In short, the 6 rigid and small wheels of Overhaul 2.x were not conducive to it handling predictably due to so many points of contact on a varying floor, and just not having the deformable contact patch to really transmit the power of the drivetrain into the ground, at least without overcoming the material’s own shear strength.

There was one final trend that bugged me to see in Overhaul 2.x that stemmed from its last 2 matches with Witch Doctor and Warhawk.

Even if I can self-right, the ability to get away quickly to do that somewhere else is absolutely critical.

Yes, Overhaul can self-right. It can even do so pretty quickly, but some times the bot needs a second or two to settle into the position, especially if the clamp is all the way extended. The ears actually help with this explicitly; on Overhaul 1 they were 100% critical to self-righting at all.

But, that second  will kill you because Bite Force can get the good ol’ one-two hit in. That’s the nice thing about little vertical spinners – you can just keep pointing yourself at the opponent and expect results. Again, look at the most legendary driving bots of today: they can drive in almost any position, even if not on all wheels, at least enough to get themselves out of a sticky situation. Overhaul 2.x can’t do that, and not even Overhaul 1 or Sadbot can.

In the end, if I wanted Overhaul to drive like Hypershock, so like Hypershock it must appear. I was going to have to dispsense with the romance of Biohazards Past and focus the bot’s geometry on being able to drive. I know, now, that it can grab and lift just fine. But no amount of high-performance grabby-lifty will win matches if you can’t feed the opponent in.

Personally, I wouldn’t be convinced at this point that I “do a season correctly” until Overhaul just gets out-robotted consistently. Losing repeatedly due to random mechanical and electrical bugs is just sloppy.

The Dénouement

As ＯＰＥＲＡＴＩＯＮ　ＲＥＳＴＯＲＩＮＧ　ＢＲＯＷＮ was ongoing, a lot of these newly updated design requirements were stirring in my mind. It’s what I was actually doing while brainlessly covering myself in “van powder”.  I wanted to get a new Überclocker (/30haul) together for Dragon Con, but let’s be real, ｖａｎ is already too much of a project anyway. The next best thing to aim for was NERC Franklin Institute in October, or the Orlando Maker Faire “Robot Ruckus” in early November after I get back from Dragon Con.

Basically, while I was destroying my brain cells painting the van cab, I was using the remaining few I had left to formulate what I wanted out of Überclocker v5 as a Robot Reynolds Number test model for Overhaul 3.

• As I mentioned, the lift and clamp arrangement was going to remain unchanged. This goes for Clocker too – even V4 (with Overhaul 2.0’s general appearance) managed to get off some great throws, and I was familiar with the design needs of the leadscrew drive clamp and gear-drive forks.
• It needed comically large wheels for its size. Mentally, I figured Overhaul was going to use a go-kart tire or foam-filled utility tire in the 8 to 10 inch range, so it implied a 4 inch and up wheel.
• However, and this is the important part – I needed the wheels to at least behave, on the 30lb scale, like what a foam filled or solid foam tire would behave at the 250lb scale: fairly bouncy and compliant. This actually ruled out a lot of wheel and tire choices. I could get the 4 inch BaneBots wheels again which Clocker v3 used to amazing effect, but they are fairly rigid. Same with Colsons. Custom-cast silicone or urethane wheels with a durometer of 30A or so might have given me that compliance, but from my experience casting soft urethane wheels for Clocker v4 at Franklin Institute, they were also going to shred and burn out very fast.
• The design had to accommodate what I called “butt traction”. Overhaul, and by extension Clocker v4, can’t get tilted backwards more than about 25 to 30 degrees before all the wheels are off the ground. Even Clocker v3 has “butt traction” ability – see how the rear wheels extend past the rear frame members? This is suboptimal from an armoring perspective, since a spinner can pretty easily pinch your wheels off from the back. But a part of me wondered if that was okay as long as you saw it coming.
• With all this changeup going to bigger wheels, the frame would need to be taller and denser than I’m used to – I tend to lay a lot of components out flat since the bot bases were always very wide.  I’d need to pay attention to the center of gravity of the bot and make sure it can even still grab and lift things.

While these thought for Clocker were ruminating, I was also doing a bit of lookahead – we in fact bought a good handful of bouncy 8-12″ wheels for PRODUCT DEVELOPMENT REASONS (no, like actually for the products) which were a convenient time to sample tire candidates for Overhaul itself.

In summary, by Dragon Con’s end, I had the following anchors dropped for Overhaul 3:

• It must reduce the drivetrain complexity and ideally run with 1 motor per side instead of 2, such as the C80/100 motors we extensively used before, or their equivalent today.
• It needed to have the choice (at the time) of either a brushless powertrain or a brushed one. Tests during the fall, and with Sadbot, were to help with this design fork in terms of priority.
• It will return to 4 wheel drive instead of 6 (with two awkward small front wheels). The wheelbase should be made as long as possible to accommodate for center of gravity needs, but….
• It will be a lot taller and more squat looking, more Overhaul 1 in appearance, to accommodate large compliant tires
• It needs to have tractive ability from as many angles as possible – dead upside-down, angled up-side down, butt-traction, etc.

Well, that seems like an all-new bot to me, doesn’t it? I’d said before that I’ll run Overhaul 2.x into the ground first before building a new one. But I think to be realistic, I have no other choice – modifying everything to try and satisfy these needs didn’t seem remotely practical.  Ideally, I figured, I can keep costs down by greatly simplifying the chassis design, to move to a “somewhat modified barstock” method like Season  3 Brutus or a aluminum tube-and-shapes construction like Stinger or Whiplash.

Let the Design Games Begin!

 

The “insect” classes – 1lb and 3lb bots, have foamy model airplane wheels, generically called “Lite Flites”, for the bouncy one-piece wheel solution.  Heavy bots have solid/flat-free utility wheels, which in fact a few builders cheekily call “heavyweight Lite Flites”.

In the middle, though, I haven’t really seen any compliant wheel solutions, at least not uniform material ones. What I do know exist are “shooter wheels” for robot competitions like FRC and Vex.

So I went back to good ol’ Andymark and VEXPro and checked in on what their latest lineup for these products are, and what do you know – the mass commercialization of robot competitions (BACK IN MY DAY… -me) has really diversified the product lines. Now these squishy flexure tweel things are available in multiple durometers and materials and hub configurations!

I figured my solution would be somewhere in this realm, so I got a small sampling.

I rather liked the Vex straight-flex wheels. The Andymark design is overmolded rubber on a solid core, which I felt like was more of a potential failure point, so I went for these Vex Versahub compatible 4″ diameter ones. I got a few VersaHub components along with them to see how I could make integrated drive hub solutions.

In handling these wheels, I found out that they’re maybe just a little too compliant to run as single wheels, even in the 40A hardness. What happens is, they deform between the spokes fairly badly and begin rolling more like octagons. So at this point was when I had the idea of doubling them up – they’d better approximate the aspect ratio of a fat utility wheel or small go-kart wheel anyway, and would contribute even more to available contact area. #BotsGotDuallies is an idea that might also make it over to Overhaul itself.

One of my perennial FAQs when I taught mechanical design lectures/seminars was “Where do I even start?”. Good question – what’s the first CAD file made of an Airbus A380 anyway?

I usually told people my preference is just to make one of the small, well-defined subassemblies or parts first. You can always come back to any aspect of the design later, but “grounding” the design will help lock in variables and drive other placement and geometry needs. For me, it’s almost always the drivetrain of the bot and furthermore, almost always a wheel.

So there it is – I spent a few minutes staring at the Vex parts while thinking of easy ways to put them together. I ended up settling on using the Versahub sprocket on the “wrong side” of the hub itself so I can have a wheel on one side and a sprocket on the other. I think you’re supposed to use the Vex provided spacers with the sprocket on the projecting boss side.

This assembly is the kernel of the new 30haul drivetrain. The front hubs will be keyed to mate to a live driveshaft instead of being an idler, but the rear hubs will be bored out for bearing inserts for that role. Why this configuration instead of the multiple wheeled, indirect chain drive of Clockers past (or of Overhaul present)?  That’s influenced by another durability and “mobility in depth, at all costs” consideration to be explained.

I then started with dumping geometry haphazardly to think of some high level part placement needs. See the yellow square in the middle? That was an initial placement candidate for the main lift motor. It was a study in whether or not I could separate Overhaul fully into an upper and lower half. Right now, it’s basically there with the interface between the main lift gear and its pinion being where the bot can be “split” vertically when the arm towers are unbolted. Because I was anticipating the whole chassis becoming denser, I figured the lift motors might eventually make it upwards, especially with bigger drivetrain components possibly having to occupy where they roughly sit now.

As a sketching guide, I overlaid and mated the sketch into a dummy assembly and started organizing existing 30Haul parts into it.

One of the major improvements I wanted to make, as I mentioned, was greatly simplifying the frame design into something easier to construct on the inside, but keeping the bot’s visual identity on the outside. Unlike Overhaul 2.x or even the previous 30haul/Uberclocker which sought to imitate its topology, the frame of this new design is 5 major rails and a few plates/covers, ideally down from 14 parts.  All of these rails will simply be end-drilled and tapped – no fancy corner mating blocks (I’d favored the mating block/nutstrip approach back in the day when my fabrication means were much more limited).

Will the wheels be exposed? Absolutely. Is this a bad idea? Maybe a little. Here is where my “mobility in depth” plan is fully integrated.

I realized that the doubled up wheels could offer a defensive advantage. If they are mutually connected by “not much”, such as purposefully weak bolted connection or some shear pins and the like, then under normal driving they’d act as one wheel but the outer one will be very prone to shearing off once a big enough hit gets registered. For these Vex wheels, you’re supposed to bolt through them with spacers. I’m electing to use nylon standoffs to be threaded into from both ends – so the only connection between the inner and outer wheel is nylon. I got this idea from the HDPE side bumpers I installed on Overhaul in anticipation of the War Hawk and Witch Doctor matches – they’re designed to give me an extra life if it got broadsided, tearing off first and hopefully allowing a clean escape, which they did until I ran out of them of course.

The next element is why I have the front axle as a live, driven one. Overhaul 2.x has all “dead” axles – they add immense rigidity in the neighborhood of the axle connection. In Uberclockers of the past, I’ve then indirectly driven the wheel with another chain or serpentine chain setup (ooooh, instant single point of failure) or, as in the case of Überclocker Remix, through a gear. I’ve far more been a dead axle guy, is what I’m saying. The premise of this change is to have the dead, idler wheel in the back and the live driven wheel in the front. The rear wheel will be the most exposed and vulnerable, so it should not be the entry point of power into the system. The front wheel, in an ideal world, is going to be hiding behind the Overhaul-shaped wedge pods for one, and whatever else I put on the side of the bot.

I could make the front wheel technically also an idler and use an indirect chain or a gear drive. But the durability advantage I also want to confer is toleration of being bent. If the axle is bent and the wheel is wobbly, chances are another drive chain won’t stay on and a gear drive will no longer mesh correctly. But a live axle spinning in two self-aligning bearings may still stand a chance of both just transmitting wobbly wheel motion and hopefully, with the bearing constraints, prevent the bending motion from being propagated to the other side.

All of these combined inform the drive system placements for 30Haul. I decided to mount the wheels directly to the BaneBots P61 gearboxes here, for simplicity. For Overhaul, it’s likely going to be a double bearing system with an internal intermediate sprocket/gear stage if I can’t get a good direct motor placement.  I’d prefer to keep the motors as close to the rear of the bot as possible still anyway, for center of gravity and balance concerns.

In the most ideal worst case scenario (?????!) possible 30haul/Overhaul can take a direct broadside of some kind, get a wheel(s) pinched off and get flipped over, and I can skitter away with the remaining wheel on the other side (or be completely operable still with the “inner duallie” on the damaged side), self-right, and try to return the favor. That’s my story and I’m sticking to it.

 

First passes at generating frame rails are more or less complete – there would only be slight dimensional shifts from here.

Another major facet of Overhaul 1.0 inspiration that’s making it back into the design is the “wall of wubbies”. Overhaul 2.x was designed more like Überclocker since I obviously had that creative leverage, with the frame and drivetrain extending under the lift point where an opponent would be. Optimal, perhaps, for carrying, but it complicated the chassis and those front wheels were always a source of maintenance concern (since putting so much force through even smaller than usual wheels made them come apart or wear extremely fast).

If you recall from looking at Overhaul 1 in its early stages, it just has a big rail of rubber shock mounts on the front. This was definitely a compromise with the frame we already had put together, and they proved to be too bendy in operation once we really picked something up, like Bite Force.

Wubbies need to be spaced apart to approximate being used in tension and compression to be effective – they’re not very strong in either shear, or direct application of bending.  The idea was to give 30haul a “wall of wubs” of its own, but angled, numerous and in mutual contact, and with the outer ones arranged to mimic the ‘pontoons’ of Overhaul 1.

 

I’m testing the arrangement of the above-board lift motor placement here. While I like it, it had an unfortunate side effect of placing the motor directly in the path of the clamp arm. I’d have to sink the motor below the top plate level (making mounting more complicated again) to prevent this, or make some kind of U-turn drive to keep the motor package contact.

This is a manifestation of the robot part quantum principle that I’ve talked about some times. It’s harder to arrange parts in a smaller bot, because they are relatively so much bigger. A motor package not all that much bigger than this 42mm brushless setup plus a gearbox – my 63mm brushless motors into BB220 gearboxes – is used in a robot almost 10 times the mass and over twice as large in every dimension. Just the flexibility of having more volume to put things could be enough to mitigate design conflicts.

So I wasn’t really feeling this placement after a while. I’ll keep it in the back of my mind for Overhaul itself, though.

Therefore, the next stage of the design after a lot of rough geometries and placements were done is to push things around and see if I could get a more satisfactory solution. I moved the lift motor to a position rather close to under the lift gear. This allowed all 3 of the major motors to be in close proximity, which was nice, and it changed the forward bulkhead seen in the previous photo to a horizontal one that supports all the motors from below at once.

The downside? I had to shift the front wheels back to accommodate this position change, unless I wanted to implement the indirect-drive internal chain setup right away. Given that I was more interested in the bot as an exterior topology test, I didn’t want to add complications at this stage.

So I already knew 30Haul is going to have some center of gravity issues. I was fine with accepting this as an experiment to get a feel for how Overhaul 3 might drive (and Overhaul 1 DID drive – the placement of things is not all that different between it and this design!). It was clear the design would come in underweight anyhow, so worst case I’ll add a Shiny Metal Ass as a counterweight.

The next episode: Filling in more of the CAD details and executing my famous “Build it as I design it” strategy. I think the DoD calls it “Concurrency”. Say, how’s that aircraft carrier coming along?