Archive for the 'BattleBots 2016' Category

 

The Overhaul 2 Design & Build, Part 9: Where We Actually Begin Building, n’Stuff

Jun 08, 2016 in BattleBots 2016, Bots, Overhaul 2

This is it! Now that my incredible van hangover has cleared, it’s time to get back to build reports. With 2 weeks left to go until the SEASON PREMIER OF BATTLEBOTS ON JUNE 23RD 8/7c ON ABC!!!! my hope is to clear the build itself and discuss the runup to the event as the season starts. As OH2′s matches are aired, I hope to immediately turn around and prepare analyses of them within a day or two. OH2 is not part of the premier itself, but look for it in the next few episodes that cover the preliminary rounds and beyond!

So, after seven episodes of working through the design – eight if you count my love affair with brushless drive – it’s time to start persuading metal into shape. At this point, it was late January, and I’d just gotten a load of RageBridge2 units in, so we were busy in “fulfill the delayed crowdfunding campaign” mode. It was between RageBridge logistics juggling that I was placing the first orders for materials and parts. As I mentioned in the last design post, a majority of the machined parts for this bot were going to get sent out to external shops which I’d done business with before.

I spent a portion of December and January shopping the design out to a few places, both domestic and in China, to gauge interest more than anything. Here I am, showing up with basically two dozen unique parts, for which I need quantity… 2…. or thereabouts. My contacts are largely production-oriented shops, since I needed, say, 250 DeWut casings or 500 RageBridge 2 heat sinks. They have otherwise much larger jobs that occupy machines for a week at a time. So it wasn’t surprising when only a few replied saying they had the capacity for it at all, much less the ability to turn around quickly.

Robot build seasons are always a blur, and a huge and complex robot even more so. In high school doing FIRST Robotics, it was easy to lose track of where on Earth the past 6 weeks went, and I was definitely in a similar situation with this build! I’m basically going off the photographs’ dates now to reconstruct the series of events which led to Overhaul 2. We begin in mid-February into early March as parts began arriving.  Yes, began. Basically everyone was cutting it this close for a variety of reasons, some of which I’ll likely talk about only after the season finishes airing.

So here we go! First, the main cast of characters involved.

  • Me, the principal designer and I suppose electrical system lead, since OH2 has the most hipster snob electrical system imaginable. I also machined stuff occasionally, I guess.
  • Cynthia, who assisted with fabrication and also creating the team aesthetic and presentation, as she is a graphics designer and illustrator.
  • Paige, chief waterjet babysitter and machinist/fabricator.
  • Matt, Paige’s boyfriend and Biology & Premed student, so we trained him on whatever needed doing at the time.

Oh, also, as the build progresses, I’ll be sprinkle CAD shots back in as things need validation or redesigning on-the-fly as disasters occur. I assure you there was a lot of that…

The stinger photo at the end of build report part 7 was of wheel hubs. This was the only “mass produced” part for OH2, since I knew I was going to need spare wheels no matter what. I sent this out to a nearby CNC shop, ARMSET who turned this around in about a week and a half.

During the intervening time period, I tried to work as ahead as I could on minor fabrication of the associated parts, such as sprockets and wheels. Additionally, I wanted to get a start on one of the weirdest parts of the bot – the welded plate armored pontoons up front.

What’s the same thickness as 5mm steel? 5mm plywood, and I think one of these substances is a little easier to put together over and over! I bought some birch model plywood from a local wood distributor, and then proceeded to barge back into my own former shop to use the laser cutter.

My rationale when putting this thing together: Wherever I can shove the hot glue gun, I can shove the MIG torch. This assembly process went as smoothly as I had hoped, and I ended up building 3 of these to test the assembly order, i.e. “Where do I spray the steel boogers first?”

Here’s a completed armor module in plywood!

 

I gave this pontoon a healthy coat of the closest color to Miku Blue I could locate in a Home Depot spraypaint aisle. For the record, this color is Rust-Oleum’s “Gloss Seaside”. The camera white balance isn’t happy here; it’s a lot more aqua in real life.

One of the design choices that we were making early on during the design submission period was the robot and team color palette. Overhaul during Season 1 was naked-ass steel and… red, I guess. There wasn’t much thought put into anything except making it do robot things, so we just went with a red and a gray, similar to MIT’s palette, where gray was just made of #stonecoldsteelaustenite.

This season, I was out to transition the robot to something blue. Specifically, during the early design stages that were detailed in Part 2, when the new application was being prepared, I was all set to make a Miku-themed robot. I shit you not, this is a never before seen concept image which I put together (because of course I did):

Yeah.

Now that I’ve scared everyone away, I can say that this concept was not used because there would have been basically no way to use a copyrighted character as a team mascot or have the character prevalent throughout the robot and team.

So the #mikubot concept was scrapped, but the color lives on.

Here is a round of sprockets (that’s a technical term for a group of sprockets!) that fit on the hubs. They’re waterjet-cut from 3/16″ 7075 aluminum plate. Basically, the idea at this point was to assemble wheels as soon as the hubs got in, and then keep assembling drive and lift motors and electronics until the frame got in

The other small parts on the left are retainer brackets for the SK3 motor rear ends.

Other interesting things also began arriving. For instance, these two piece of oil pipeline oil-filled nylon bearing stock. The large rotating arm parts will use machined nylon bushings for radial support. They’re moving at a low speed, so I opted to use plain bearings. Bronze would have been nice, but heavy. I figured at this bulk level of usage, the nylon would do just fine.

One of the first electrical system experiments I wanted to verify was the custom master power switches (a few pictures down). Recall that I designed these because fitting two Whyachi MS2s in the bot was becoming a daunting prospect when accessibility was factored in i.e I wanted to retain the side approach arming.

Shown above are some copper contacts that were cut from 1/4″ silver-plated copper bar, supplied by McMaster. It seems like this silver plating is largely decorative, because it was coming off if I was rubbing it too hard – probably for anti-corrosion purposes only. Oh well.

The internals of version 1, as simple as you can get. The body is a nylon with fiberglass print, made using a Markforged Mark Two.

I’d like to take this space to welcome Markforged as the first sponsor of the team this year. You’ve seen a lot of action on this website and on Jamison’s site with Markforged parts, and they know there’s no better application to have their parts mercilessly beat on to show the technology! Markforged is providing Mark Two prints and printing services on their print farm.

 

While this edition seems to work just fine (it conducts! Yay!) I wanted to refine it more and also fix the fact that the hex key could, under some angles of insertion, be the first thing to close the circuit. Obviously you don’t want this to be the case. I also wanted to add a biasing spring to lessen the likelihood that if the closing torque was insufficient, that the screw would just back off and leave everything disconnected (or worse, constantly arcing). Here is the version 2 updated basically after I finished printing Version 1. The black nylon bushing proides a long entrance guide for the hex key so it can’t touch the switched contact under normal use.

After a McMaster order, the version 2 is completed. With a dab of conductive contact grease on the spring, the action was smooth and repeatable. I was satisfied with the design at this point, so I printed more with very minor dimensional changes for fitup.

Around this time, my order of wheel bearings arrived. They’re 5/8″ bore needle roller bearings that are pressed into the hubs. Shown also is a single 5″ Colson wheel which I test-broached with 1/4″ keyways.

This work was done just in time prior to the arrival of the first big batch of parts that needed significant modification and work, which is the drive and lift gearboxes…

Oh god that’s a lot of Banebots.I ordered 10 4:1 gearboxes and 4 16:1 two-stage gearboxes, plus a basket of spare carriers, shafts, and gears.

My personal guess was that if the gearboxes were going to fail, the 4:1 drives would fail first due to rapid reversing and direct shock from the drivetrain, like running into things. The lift gearboxes would be reasonably isolated from torque impulses by the 12:1 external gearing and the clutch. I ordered enough gearboxes for drive such that I could build 10 drive motors and, in accordance to the serviceability inherent in the drivetrain design, just swap out motors and deal with piecemeal repair later.

That’s one of the things which trips up newbies some times is how expensive everything gets once you factor in the ability to repair rapidly. While the initial cost outlay might be high, what is the cost to you of losing a match when you could have been able to put the machine back together if you had parts?

Two things needed to happen to the Banebots gearboxes to turn them into drive and lift motors. The motor mounting blocks had to be machined down to 1/2″ thick, and then the hole patterns drilled. Paige and Cynthia took up this job using some of the equipment in the IDC and CNC mills in the same building.

I continued the “weird science” part of the build by working on the two-speed shiftable “P90X” gearboxes. For this, I waterjet-cut out of O-1 tool steel a replacement planetary carrier:

That’s it on the right. This carrier has (reduced size) teeth and fits perfectly into the ring gear on the left. It has hole patterns for both 4:1 and 3:1 gear stages. The idea is that the sliding ring gear either is anchored to the gearbox housing, or is meshed with this carrier and spinning with it, bypassing one stage.

Here’s a comparison of the carrier plates after I transferred the pins over. The next operation for this setup is to chamfer the edges of the carrier teeth and create a mating chamfer to the ring gear, such that they can collide and mate smoothly.

The other side of the ring gear needs to be firmly affixed to the front output block of the P80, since the ring gear is no longer held in compression between the two blocks. To do this, I basically turned the four dowel pin holes on the ring gear into holes for four shoulder screws. Notice that I’ve already cut off the ring gear here, too.

The four pins that were in the output block were removed, then their holes drilled out directly and counterbored on the other side for the shoulder screw heads.

We interrupt this build report for….

EPIC LIFT GEAR! From now on, every time I say EPIC LIFT GEAR! it will be in bolded capital letters with its own exclamation mark. Consider it a single lexeme. Anyways, the EPIC LIFT GEARS! arrived from…. Amazon. These are giant spur gears from Boston Gear, who lists its basic catalog on Amazon Prime. I’m super happy about this and encourage all industrial suppliers to do it.

Part 1 of the EPIC LIFT GEAR! is the 42 tooth, 12 pitch intermediate gear, which will be turned into the lift clutch. The other EPIC LIFT GEAR! above it is the 6 pitch output pinion. It will be face width reduced – I don’t need the ridiculous 2.25″ face width – and then broached.

I used the MITERS Clausing lathe to bore out and dish the interior of the 42 tooth gear, and also cut off its hub. This is it – the intermediate EPIC LIFT GEAR! will just have a bushing in the center such that it can spin on the clutch shaft.

Next up was the clutch shaft itself. In the latest McMaster order, I put in for a length of 1144 steel, commonly used for high-stress round things. This needed to be turned from a 1.5″ round into a 1.25″ shaft with two 0.75″ ends and a 1.25″-12 thread on one end.

I decided to practice threading again on some aluminum first, since it had been a while since I last made giant custom threads, and I was also unfamiliar with the new MITERlathe’s threading controls.

I then mounted the shaft in a mill to do the secondary keying operation. This keyway is for the 6 pitch EPIC LIFT GEAR!, since the 42 tooth intermediate gear will be sandwiched using clutch plates. However, I decided to make the keyway full-length such that I could make the clutch plates themselves keyed, to assist in torque transmission.

A little bit of Scotch-Brite and wire brushing to deburr the threads, and the clutch shaft is completed.

Here’s what the clutching setup looks like for now. I had yet to receive the order with clutch lining material and giant conical washers, and the pressure plates still need to be cut.

While this mechanical work was going on, I was working ahead a little on the electronic side of things. Little I know the build was about to take a tragic turn…

dun Dun DUUUUUUUNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

 

By the way, Overhaul 2 swag is now up on the BattleBots store. Builders get a cut of the sales of all swag, so here is your chance to indirectly sponsor Equals Zero Robotics!

The Overhaul 2 Design & Build Series: #sadbot2016, The Untold Story; Or, How to Be a Brushless Hipster; Tuning the SimonK Firmware for Robot Drive

May 08, 2016 in BattleBots 2016, Events, Overhaul 2, sadbot2016

We take a short break from talking about Overhaul 2′s design in order to talk about something far more important: Ladies and gentlemen, from this day forward, I will be acting as the CEO of Marconi Motors, a company which will take on the likes of Faraday Future for the title of most overhyped bullshit of 2016. I even made a website! It even has a mysterious teaser on it!

nevermind that i swiped the product photo from Aliexpress and hurriedly pasted a Miku figure on the side

One of Overhaul 2′s defining characteristics which I divulged recently is its all-brushless, all-the-time drive system. Ever since then, a portion of the robot combat world has been going WTF? over it, which is the correct reaction, and I agree with it.

This post is extremely lengthy and detailed, so I’ve went ahead and split it into a somewhat coherent babble, instead of an utterly incoherent one like my preferred style. Here are the “sections”, but I heavily recommend just going to the bathroom right now, or declaring your lunch break.

Update: West Coast botmongler Xo Wang has put together a great writeup on the “behind the scenes” of some of this brushless controller shenanigans, and has dug into the firmware more than I have. Definitely worth a read if you want to know more about brushless controls in general and SimonK’s inner workings!

  1. Summary of brushless systems right now, and why they all suck
  2. Background on the idea and why I chose to pursue it
  3. Picking candidate parts for Sadbot
  4. Finishing Sadbot’s drivetrain
  5. Modifying the Dlux 250A controllers and tuning SimonK
  6. Testing and refining of the whole system
  7. Tips for chopping your own ESCs

Why does my motor need brushes if it doesn’t have hair?

Brushless motors have been in use for several years as weapon motors, especially in the smaller weight classes. Cheap ones – the venerable ICBMs, or Inexpensive Chinese Brushless Motors, a term you saw here first on etotheipiplusone.net in 2010, have largely been responsible for the rise of EVERY DAMN BOT LOOKING THE SAME optimal designs with spinning weapons – like vertical discs or “Tombstone-like” horizontal impactors. In short, they offer immensely improved power to weight ratios compared to DC brush motors, even high-performance thoroughbred ones like Ampflows.

The missing link to using them for drivetrains has been control. There have been brushless-drive robots in the past, even dating back to the original BattleBots on Comedy Central, generally using paired industrial controller & motor sets, but large scale (and expensive-for-the-time) R/C gear was not unknown either. Control strategies in this world of bots for brushless drive has generally been in one of three categories, discounting fully custom developed controllers by the builder (because come on, that’s cheating):

  • Industrial servo drivers with similar industrial servomotors,
  • Modified electric vehicle drives (such as e-bike or commercial vehicles), and
  • High-end R/C hobby gear such as large marine / aircraft model controllers.

CrocBot, a 60lb design from the early 2000s.

Most recently, with the proliferation of brushless EV (such as e-bike) motors and brushless servomotors, more robots such as Overdrive and Chomp (ABC S1) have used brushless systems. These systems have become more ‘general purpose’ – you can usually plug one motor into another controller and have it either work, or require minimal tuning to work, but are still frequently sold as complete systems. The systems are usually limited in one way or another to reflect their industrial nature; examples include maximum controlled speed, motor stall protection, safety interlocks needing to be interfaced to radio systems, etc. In other words – yeah, it’ll work, but it’s a bit fiddly. Many things will work for robots if you are willing to fiddle. So that’s one constraint – ease of control implementation, and needing to be significantly invested in the details of operation of one particular system.

The second constraint of brushless drive is that of adequate operating envelopes. Hobby R/C motors, the ICBMs, are promising in their power to weight ratio and power to cost ratio, but hobby motor control equipment is not well suited for the task. Usually created for model airplanes, the controllers are lightly built, “rated” to an inch of the components’ lives using unrealistic methods, and usually do not feature reversing or the ability to maintain torque at low speeds and near-stall conditions, which is where DC motors shine. Generally, hobby motor controllers are not outfitted with any type of encoder or motor position sensor inputs, relying on motor back-emf sensing to start and run the motor, which means the motor has a minimum speed under which it will not behave. Yeah, your motor has to be moving before it can move. I know, right?! Those that are built to take Hall sensor inputs (such as these large R/C car controllers) will usually also not have current protection, so operating your motor near-stall will likely cook the controller quickly anyway.

The higher up in the market you go, generally the more robust the controller designs are, but that cost has priced brushless systems out of almost everybody’s reach except those who have easy access to them – like through sponsorships, or for whom money is no object. For the high-end R/C gear, the cost is generally high – approaching $1000 per controller, if not more, and of course you need at least two generally plus spares. Compare that with the cost of an average DC motor system for a 30-60lb bot: two DeWalt drill motors in mounts (Plug warning: like a DeWut, which I swear I will have restocked soon) and a controller to match might be under $600 total. Even for a Heavyweight of 220 pounds, two wheelchair motors and a set of Vypers runs you around $1,100 total. Cost is therefore the other constraint which has prevented widespread adoption of brushless drive systems.

Figure 1: Money money money money money

So the triangle of “choose any 2 out of 3″ scenarios for brushless drive, in short, are:

  • Industrial and commercial systems, such as e-bike parts, servo drives, and the like: DC-motor-like operation envelope, but expensive and often finicky.
  • R/C model systems: Limited operation envelope, generally unrealiable, but plug & play (with price really all over the map)

The challenge is therefore to find or create a controller that can be used with virtually any hobby type brushless motor for drivetrain applications.  Along the configurability axis, hobby equipment has a huge lead on industrial ones for the ability to “mix and match” motors, making them way better suited in principle for combat robots, which are generally bespoke systems not designed around any one particular drive constraint. Special requirements of drivetrains are the ability to handle inertial loads (recognizing that steady acceleration is necessary instead of forcible commanding a higher drive frequency, for example), rapid reversing, and DC-motor like near-stall behavior, if fully stalled behavior is not possible. And finally, it should be inexpensive enough to be worth investigating over a known DC motor solution.

It might not be optimal in all of the spaces, but it will be enough to make it worth my while.

And yes, I know that Radioactive used a plethora of NTM 50/60 motors with Hobbyking R/C car controllers for drive. But we don’t talk about Radioactive… :)

The origins of Brushless Hipsterism

I stood at the end of Season 1 wanting more from Overhaul’s drive system. Watching a lot of last year’s matches, and watching big bot tournaments in general, it seemed to me that the driving tactic in the bigger bots was more “point and shoot”. As someone used to driving 30lbers, especially a fast one like Überclocker, I had come to enjoy powerful drivetrains that can change speeds and directions quickly and which I can induce controlled sliding and rotation. I like drifting around and doing J-turns, and generally being swoopy and unpredictable. The best consistent drivers in the heavies know the dynamics of their own robots and use it to their advantage each match.

As a result, the wheeled drive modules of Overhaul, which we made knowing that the shuffler drive offered no advantages given the lack of a weigh bonus, was geared fast. Overhaul could hit up to 19mph, and overall I was satisfied with how the bot handled (with the exception of some squirreliness due to the weight being over the two front wheels only). I think the Lockjaw matches showed my driving style preference quite well, despite me constantly complaining that Overhaul drove like an overladen Chinatown bus.

But ultimately, that gearing turned out to be too hard on the Ampflow F30 series motors. Lacking experience with ‘big bot motors’, and having grown up watching winning bots use Magmotors (and their spawn, Ampflow), I poorly assumed they were virtually invulnerable. While we never overheated and cooked the windings, the brushes were the first to give out, taking out the commutators when they did. We basically came down to swapping out for spares every match as a precaution. In smaller bots, you generally toast the motor windings before the brushgear is damaged, so I was expecting this failure mode. I was dissatisfied that $300+ motors were limited in their performance by a quarter square inch of graphite.

Toasted Ampflow armatures from Overhaul in 2015

During late 2014 and 2015, some small bot builders had begun experimenting with using brushless drive with hobby controllers that were outfitted with a custom firmware written for DRONE RACING, BRO high performance multirotors. While I had glanced through their discussions, I wasn’t able to try it myself due to, umm…. certain pressing robot matters until well after Season 1 ended. I picked up some controllers which had been designed around the needs of the multirotor community and used them in Stance Stance Revolution. You can read SSR’s build report here about 1/4 of the way down where I talk about the Simonk-flashed controllers. Here’s a brief quote to save some searching:

They’re the “Afro” series from Hobbyking, and besides making me wonder how they came up with that name, I also really enjoy their extensibility. You see, the DIY multirotor community has been working on a better firmware suited their needs for years. They now have a massive database of upgraded firmwares for many of the ATMega-based brushless controllers. the Afro line evolved out of this community’s needs, and in fact contains a bootloader onboard such that you can upload new firmware using only the PWM wire – no need to try and find the programming pins on the boards. The firmwares offer many configurable options, including reversing.

Hmm. It’s piqued the interest of a few robot community folks, one of whom put together a guide on how to update the firmware to a “bot compatible” one. I performed these mods on my ESCs and did a demo video on how it affected a relatively high inertia load like a blade.

-me

The stage was therefore set for me to think about how to expand this to the realm of big bots. Quite a few 1lb through 15lb, and even the odd 30lber, had at this point used a SimonK-cracked cheap R/C controller to drive, to varying degrees of sucess. I got intensely curious over the end of summer about what the SimonK firmware does differently to make it more robust in starting detection and reversability (The answer would come as a surprise later…), and what made that curiosity stronger was the fact that there are many open-ended settings in the firmware. I wondered if these settings could be used to better suit the controller for heavier loads. Small robots are comparatively easy; that is, they have much less inertia, as well as a higher inertia to power input ratio (i.e. motors are more RELATIVELY powerful for the robot size). Many competitors got away with using stock SimonK settings or using minor modifications to braking settings, and I wanted to see if the same was still true in the 250lb range, or if I had to start tinkering with

It was clearly time for some experiments.

 The Manchurian Shenzhenistani Candidate

As usual with one of my developments, multiple independent threads of projects and explorative experiments converged on something that I could move on improving for Season 2. In other words, there’s no clean sequential path from nothing to a successful brushless drive system, so you’ll have to get the whole story.

Having experienced almost all the failure modes of using R/C airplane motors in EVs through both my own projects and the go-kart class sessions (which means I’ve seen almost all the failure modes you can possibly imagine out of anything), I knew that the controller was going to be the limiting reagent.  In robot fighting, you so rarely see brushless motors cook themselves before controllers. Why?

Modern hobby motors are usually well under 0.1 ohms of line to line resistance (the resistance between two of their three wires), which means anything you do will cause hundreds of amps to flow. The motors are no longer what’s preventing your systems from blowing up due to too much heat from current draw, so what’s next? Not really the battery either, because modern lithium batteries will also easily source many times their capacity ratings – could be hundreds or even thousands of amps from a larger pack – without blinking.

This is one of the things I taught in the go-kart class. You can’t really calculate torque and power any more from “stall” characteristics with the current generation of parts, because it will create unrealistically high results that cannot be reached. As a simple example, your motor might be 30 milliohms L2L, your battery a total of 25 milliohms for a moderately sized 6S (22.2v), and the motor controller an additional 5. The theoretical loop current that wants to flow is 22.2v / 0.060V = 370 amps.

The element in the middle, the motor controller,  has to handle throttling all of these amps that want to flow, and without current sensing on most R/C controllers, powering into a stalled motor can result in pulses of high current that very quickly heat up and destroy the FETs, board traces, etc. So the controller has to be extremely oversized compared to the motor. Those R/C controller ratings mean basically nothing, by the way, much like the horsepower of a Shopvac (This is more true for the lower end than the high end of the R/C market – which tends to be rated more truthfully).

For the motor, I was most interested in the HobbyKing SK3-63 series of motors. These things are reasonably well built, and more important, have a rotor bearing (lower left) that helps prevent the can from coming apart at high speeds because one end of it’s unsupported. They’re also currently the largest motors HobbyKing sells that have the shaft coming out of the “correct side”. The larger Rotomax series do not have a reversible shaft without remachining, and they’re designed only to be radially mounted (sticking out of the front of the plane like the old style radial engines). By power analysis, they seem to be worth roughly 1 A28-150 apiece depending on what system voltage you run at, but weigh less than half of the A28-150.

Control-wise, I had to think a little harder. Luckily, I had a bit of a head start in this realm last year when I collected all of the large Hobbyking controllers to investigate their construction and power design THEY’RE ALL THE SAME GODDAMMIT WHY for the EV design class. As the product lifecycle of nameless R/C model parts goes, some of these are no longer produced or are “permanently out of stock” as HobbyKing loves to do:

Three out of a few more that I bought and unpacked For Science

The ideal candidate would have an ATMega series microcontroller to flash the SimonK firmware directly onto and be well packaged, such as in its own case with a heat sink. That pretty much took out the YEP (yep…).

It’s worth noting that all of these inexpensive big ESCs are pretty much genericized designs. They all use some pin compatible 8-pin, ~1 amp half-bridge gate driver like a LM5109 or an IR2101, driving a rail of MOSFETs per leg of the 3-phase bridge (between 5 and 10), with buttery slow switching times. The logic power circuitry is generally a chained linear regulator setup – none of these designs supply receiver power (BEC), so it just has to power itself. Some of them have SiLabs 8051 core microcontrollers like the C8051F367, and other an ATMega8A or 8L. I’m not sure entirely of the implementation difference that requires one or the other. The Aquastar and Fatboy both had SiLabs chips, which I didn’t have any programmers for on-hand; given that RageBridge is built off ATMega microcontrollers, I already had an Atmel AVRISP mkII and magical chip sockets.

The only controller that was left after this was the dlux 250A HV, which seems to be a visual mockup of the JETI Spin 300 Opto. It’s quite hefty – under the finned double-sided case are 36 IRFB3207 – my old favorites – in a weird upside-down hand-soldered TO-220 package arrangement. The other big ESCs used surface mount devices, whether a power 8-pin package or surface mount D2PAK.

My opening shot into leveraging Big R/C for robot drive was therefore the dlux 250 and the SK3 63/74 motor. As for which SK3, I played around in the Torque Calculator for a while to get a space of satisfactory results, also considering practical needs.

I decided to use the SK3 63/74-192 over the -149 variant. While I can get more torque per amp usng the 149Kv winding (it rises as Kv, or RPMs-per-volt, falls), I would have needed to run very high voltages, like 48v and up, to get satisfactory performance. I could instead use the faster winding and simply gear down more to trade the excess speed for more torque. To a degree, this “free power via high speed” is how R/C products claim ridiculous horsepower in small packages. Anything can push 10kW if it’s spinning at 40,000 RPM… doesn’t mean it’s remotely useful to do so.

The other practical restraint is that it needs to be easily interfaceable to Overhaul’s spare wheel modules and battery, which I had earmarked for this experiment. The motors were going to spin in the neighborhood of 7,000 RPM, so I figured they were probably going through a gearbox of some sort.

I also needed to put together a frame that held the wheelpods, and would end up weighing around 250 pounds. And that’s where the story of #sadbot2016 began, and where we pick up again now.

Finishing #sadbot2016

We pick up where we left off, which is mechanical completion of the frame to the point where I could start putting in the motors into the Overhaul drive pods. To do that, I needed to mod up some gearboxes.

Here, we have Collective Internet Gasp #17,385. The gearboxes I decided to use for this experiment are BaneBots P80s. First, because I had them…. well, isn’t that all the reason you need? Second reason is, I felt like they were a good size and power fit for the SK3 motors, which have natively 8mm shafts.

Last season, we used P80s on Overhaul’s lift and clamp gearboxes, which were mated to F30-150 motors, and they held up quite well. However, in that application, they were isolated from direct loads by the chain drive and ball screw. The SK3 and P80 make such a great sized package that I was determined to see if the lower ratios could be used as a building block for drivetrains. P80 gearboxes have been one of those “parts nobody talks about” in the combat robot universe because of an early reputation stemming from quality and materials. But they’d been redesigned recently, and I honestly don’t think they’re that bad any more. But how bad are they? That’s what Sadbot was supposed to find out.

To mount the SK3s, I needed to make two modifications, one to the gearbox and one to the motor.

The 8mm shaft of the motor needed a 2mm keyway cut into it. That way, the P80 pinion can slide right on. This is one of the reasons why I thought the P80 might be a good match, because there’s minimal shaft modification needed compared to the Ampflow motor, which has a 1/2″ shaft. For that, you can only use the 3:1 ratio (and multiples thereof) because the pinion has to be bored out and keyed for a 1/2″ shaft.

I had a bunch of 3:1 P80s left over from the Overhaul actuators, so I started with those, but ordered some 4:1 gearsets from Banebots in the interest of testing the effect of higher and lower ratios on the sensorless start, the conjectures for which I’ll explain.

I also needed to put the four SK3 mounting holes into the gearbox housing, which was easy enough. The motor mounting block was shortened to 1/2″ thick from 1″ (basically, where their octagonal extension stops). This put the SK3 shaft at basically the exact right length to engage the pinions.

Here’s a completed drive unit. See what I mean about how NICELY it fits?! The SK3 is barely smaller than the P80 – 60mm vs. 62mm, so I can still even bolt the P80 using its side mounting holes to a flat plate without the SK3 hitting anything.

A few more holes and this assembly is now bolted to the Overhaul drive pods and linked up with chain. I used a stock Vex #35 double-sprocket on the P80 output, like Overhaul had hooked up to the F30-400 motors., so this step was super easy.

Drive pods are bolted in. I added a bunch of rubber shock mounts for mounting the (eventual) top plate. They needed to clear the tops of the drive modules, and I figured in case this thing ever goes to a tournament for some reason, I should have a modicum of top armor. For testing, I planned to just use some plywood.

I cooked up this quick mount for the dlux 250s that jus theld two of them nested into each other. The switch on the left is a modified Hella switch that I made when I was fed up with breaking melonscooter’s Hella switch off every few months – it turns the Hella into something resembling a Whyachi switch.

Around this time, I got an intern. Here’s Mr. Hypershock himself helping wire up Sadbot, since he was also sort of vested in the outcome. Why? Well, because [ REDACTED DUE TO NON-DISCLOSURE AGREEMENT ] and that’s how we wanted to win against Tombstone.

Make sure to catch the Season Premier of Battlebots Season 2 on June 23rd, 8PM eastern, 7 central, on ABC, to find out…

Dcoding the Dlux

So we’ve gotten the bot prepared and all the bitch wiring power system work done by Will Bales. The thing that was left on the agenda was how to stuff SimonK onto the dlux 250. Time to bust out the AVRISP mkII… Luckily, I already had the fancy socket on it from programming Ragebridges. I already had the KKMulticopter tool ready since I’d done this for Stance Stance Revolution. As a reminder, basic reflash procedures are found in this AfroESC Guide for Robots & Dummies Alike document written by Lucas Grell.

In the Github repository (because…. open…. source…. uuugggghhhhhhh) there are some directions on how to discover pinouts of new ESCs in order to assign the correct pinout and change other settings like which pins to use to drive the FETs. I hammered this out in an evening using a multimeter and oscilloscope. For reference below, the signal side pinout nonsense of a dlux 250a controller:

Yeah if you know what that means, you’re ahead of me.

In short, there’s 4 main things you have to do to set up a compatible ESC for SimonK:

  • Identify on which pins the six FET driver signals live. Phases are called A, B, and C, and the upper or lower half is notated “p” and “n” respectively. This is a bit of a carryover from earlier generations of R/C controllers that used P-channel MOSFETs on the high side of a output bridge for easy gate driving (yoink the P-channel low to turn on, easy to do from a ground-reference microcontroller). Newer ESCs use all N-channel MOSFETs, which are literally better in every way, either with special driver chips or discrete helper circuitry.
    So “p” means HIGH SIDE and “n’ means LOW SIDE here. The six FET signals are An, Ap, Bn, Bp, Cn, and Cp. This is done when the controller is off, via pin-poking to check for continuity between a microcontroller pin and the input to the gate drive, whether it’s discrete (made of helper transistors) or a driver chip.
  • Identify on which ports they live – to do this, you need to cross reference the pins using the microcontroller datasheet. I just printed out the pinout diagram and scribbled on it, so I right away knew if it’s Port B, Port C ,and so on.
  • Idenfiy what default polarity the pins are. Depending on the ESC and method of drive, it might need one set of pins to be default-high instead of default-low, with oppositely-conventioned PWM. If you get this wrong, things will probably blow up.
    This is done by powering on the controller with the stock firmware and using an oscilloscope to check pin levels.If the ESC uses driver chips, chances are everything is default-low (which is what my “All INIT_Px  = 0, no inversions” comments meant. All of the large ESCs I’ve checked that use driver chips are non-inverted.
  • Identify where the feedback voltages from the motor phases come back. This took the longest time for me, because there’s two intertwined connections going on.
    First, there’s the phase leg divider shown in the graphic “Phase structure”. You start with the multimeter in Ohms mode on one phase output, and scout for pins on the microcontroller that read resistances to that phase output; typically it will be tens of kilohms, and they’ll all be the same value. That’s what Sense A, Sense B, and Sense C are on the microcontroller diagram.
    What Sense A-C are also connected to is each other, through a “resistor star”. There was likely a pin on the microcontroller you found when you were trying to match up the phase sense pins that read some other, higher resistance value to the phase. Well, check that pin relative to the other phases, and it will probably be that same, higher value. This is the “virtual ground” of the motor. Note which pin this is.
  • Finally, the other kibbles remain – which pin is getting the R/C input pulse, and which pin is the bus voltage sensing line (and the associated resistor values to voltage input and ground).

Here’s what some screen of the kkmulticopter tool looks like with some of these settings for the dlux 250:

Your pin mileage may vary.

While the Github directions are sufficiently detailed, this is indeed a very daunting task to do the first time, but that should be the only time. So grab an EE friend…

Testing & Refinement

After arming up the firmware, we tried to confirm operation:

Hey, looks pretty okay! The stock settings would clearly work on a small bot, as they did for Stance Stance Revolution too, but it had some trouble with the Motenergy motor (“brushless etek”) which has a heavy steel disc rotor. Increasing the “start power” settings PWR_x_START helped, as did enabling COMP_PWM, which turns on synchronous rectification. COMP_PWM plays a large role in why I think any of this works, and I’ll explain why later.

After consistent behavior with the big motor, we decided to just throw it on there and have at it! Here is test number 1. Bone stock settings except for my changes to PWR_x_START.

Alright, enough excitement. I was truly surprised it could move at all.

From my motor controller debugging spidey-sense, there were two big issues in the video. First, the controller was still losing track of the motor during reversing and when I moved the stick quickly enough to try and start. Second, not shown in this video, it would reset on hard acceleration. Otherwise, it seemed to drive great, and so long as it kept moving or had enough inertial to keep both sides in motion, I could drive around as I usually would.

It was a proof of concept, but still needed refinement. Following this test, I actually reached out to the SimonK himself, through the e-mail on his website, showing the video and my (up to this point) detective work and asking if he had any guidance. Here’s an excerpt from my email:

> My question for you involves how to tune the variables to respond to
> ground applications better, which generally need much higher starting
> torque and a slower “ramp up rate” (since the load is largely
> inertial). I notice the bot has trouble some times if I punch the
> throttle stick from a moving start – the motors desynchronize
> repeatedly. Additionally, more power applied during the starting phase
> is beneficial, as is a lower ‘minimum speed’. To this end, I’ve been
> playing with the PWR_x_START variables to increase the starting torque.
> This has worked out well. I am now trying to study the code to see
> where I can adjust how quickly the motor speed may change (‘ramp rate’)
> and how to affect the controller’s minimum speed.
>
> I’m therefore wondering if you have some pointers as to which variables
> dominate what behavior of the motor. I’ve tried adjusting the
> TIMING_RANGEx variables, but this did not seem to produce different
> results, for instance. I also measured the switching times of the dlux
> so I could adjust MIN_DUTY and deadtime to better suit the large Dlux,
> neither of which affected motor behavior much.

Simon was actually quite responsive, and extremely helpful in his replies. Here are a few excerpts from his very lengthy and detailed responses:

We will probably need to discuss particular cases, since you mention two
things: motor desync when you “punch the throttle stick from a moving
start”, and “more power applied during the starting phase is beneficial.”
These issues often overlap. :)

For greater low power range, lower MIN_DUTY to something like 6 (which is
about as low as it can go without just widening a zone of minimum duty).
This just makes up for some cycles lost while the hardware jumps to the
interrupt, etc. It is set higher than needed normally to overcome coggy
motor starting in most cases (not needed for car style things).

You will probably get more torque/acceleration and maximum speed out of
MOTOR_ADVANCE=30, but it will cause more torque ripple and be less
efficient. I wouldn’t run it that high unless you’re trying to compensate
for gearing or some other issue.

PWR_COOL_START is only used if it tries to start while rotor-locked. It
specifies the duty limit that is modulated in only to avoid overheat.

PWR_MIN_START and PWR_MAX_START are the initial and eventuald duty limits
applied while in starting mode, which is the mode where we haven’t
confirmed timing yet, forcing MOTOR_ADVANCE to 30 while we figure out how
long any particular cycle is (needed to calculate an angle).

ENOUGH_GOODIES is the number of commutation steps needed to presume
confidence in the timing feedback before we leave starting mode. You can
likely set it to 6 or something if you want to not be limited by the
PWR_MIN_START, etc., duties for as long (when starting from stopped).
But, 6 commutations should probably happen very quickly unless you’re
directly driving the wheels with no reduction, or something. :)

PWR_MAX_RPM2 is totally unused (forgot to remove it, sorry).

PWR_MAX_RPM1 is the limit that is mixed in when timing is slower (longer)
than the TIMING_RANGE3 interval. This is another form of “starting ramp”
that limits the duty just based on timing, so as to avoid overcurrent at
low speeds if 100% duty is requested.

 

 

COMP_PWM can certainly help take away some of the noise that otherwise
comes up on the undriven phase. The collapse of the current flow usually
results in some noise, and that is mostly masked by complementary PWM.
This makes starting a little easier, and it will run with less diode
conduction (less heating) at the expense of more torque ripple.

In practice, the braking force and current will be highest at the
beginning, and in most cases the timing will be tracked the whole time,
usually resulting in some pull-back of the duty around the time of the
zero speed crossing…which isn’t as useful as if it did it at the start
of the direction change. To fix, a concept of a direction change really
should be introduced, and the ramp calculations should count spinning in
the opposite direction as a case twice as “strong” as when starting from
stopped.

The ramp serves two purposes, though: making it easier to actually track
the back-EMF when it’s weak (nearly stopped), and for current limiting
for large jumps. A blend of the two is probably required for your case.

 

This was all extremely helpful information, and probably makes sense only if you are also a motor control nerd. In summary:

  • MIN_DUTY is the lowest on-time for the PWM generator (so not TRULY a “duty cycle” modifier, but on-time). I lowered it, but not by much. Essentially, if it’s too high, the motor will want to immediately start moving quickly, and the heavy robot on the other side won’t. I was going to have to adjust this way down – I planned to just see how low the duty cycle can go before the MOSFETs just stop turning on fully (and be a little above that for safety).
  • MOTOR_ADVANCE is how many degrees (electrical) the controller “stays ahead” of the motor, which is important because every action – from switching MOSFETs to having current build up in the windings to it interacting with the magnets and the rotor starting to spin – has a bit of delay associated with it. The controller needs to therefore work a little ahead, so to speak. But it can literally get ahead of itself when at low speeds and near stand-still as to bump the motor back the wrong way a little. Increased torque ripple is a symptom of too high timing, and if the motor doesn’t start moving quickly enough but the controller is convinced it did, it could actually push the motor back the wrong way.
  • I was correct with the behavior of PWM_x_START, but I was confused as to what they meant and did, which was cleared up. It seems that PWM_MIN_START and PWM_MAX_START are the ones that really dominate the behavior, so I was comfortable in cranking them up.
  • The “braking force” he refers to are the settings BRAKE_POWER and BRAKE_SPEED in the firmware assembly file. These control how quickly the controller ramps the motor down if a decrease in speed is commanded. Absent a current sensing method, this is the “open loop” way to get a variable braking effect.
  • Combined with COMP_PWM, synchronous rectification, increasing BRAKE_POWER and BRAKE_SPEED causes the motor to track its ideal unloaded speed according to the PWM duty cycle (if it were drawing no-load current and just spinning attached to nothing) more closely. Effectively, this translates to the robot trying to go exactly as fast as the stick command, all the time. If it was travelling faster than the command, the PWM duty % would be lower and it would act as a brake, and vice versa, with BRAKE_SPEED commanding basically how much “lag”.

My conjecture was that COMP_PWM with maximum BRAKE_SPEED, decreased MIN_DUTY, and increased PWM_x_START was the key to making it work well for heavy loads, at least from the software side. This causes the motor to start spinning more slowly, but with more initial punch, and try to force the robot to track your transmitter stick position by active braking instead of letting it coast.

There was only one thing you as a driver had to do in this case, which is to not mash on the stick like an idiot. Smoothly bringing the commands across zero (reversing) was needed, so the robot can brake, stop, and then start again in the other direction. Having driven bots almost exclusively since the Ragebridge Era using synchronous rectification ESCs (COMP_PWM), I was already used to this and preferred it even back when controllers had shitty “ALL MOSFETS TURN ON” braking at neutral signal.

So let’s get to work. First, I decided to measure both high- and low-side PWMs at once using the 4-channel oscilloscope to check the switching time and deadtime. One trap of COMP_PWM is if your FETs don’t turn on and off quickly enough, they’ll cross conduct and reduce themselves to the simple case of touching your battery leads together. This kills the MOSFET, among other things.

 

In this screenshot, yellow is the low-side FETs of one phase leg and red is a differential measurement between the phase output (midpoint) and the gate of the high side FET, and it shows the switching timHOLY SHIT, THERE’S SO MUCH OVERLAP HOW ARE THESE THINGS STILL ALIVE IT’S ENTIRELY MADE OF SHOOT-THROUGH

Hmm, well, that would explain why the ESCs got so hot running the bot when we were pretty gentle with the throttle. Like I said, butter-soft switching times keep these controllers alive…

So that’s with DEAD_LOW_NS and DEAD_HIGH_NS at the default 300 nanoseconds, which is no.

I adjusted it out to 1400ns (shown in this image is 1300ns) to give a comfortable margin between the high-side turning off and low-side turning on. In this same setup, I also tuned the MIN_DUTY all the way down to where the yellow curve roughly ends now, which was 16. Based on the MIN_DUTY and POWER_RANGE variables now, this resulted in a roughly 2% minimum duty cycle. I probably could have shaved off more, but FETs not completely turning on will negatively affect the starting behavior.

After changing the other variables mentioned, it was time for drive test number two:

Massively improved behavior!

At this point I think I was hitting the limits of hardware. The software wanted to perform, but now that we’re pushing the bot harder, the controller is resetting constantly. Fortunately, the deadtime setting helped elimiate the heating problems entirely. After this drive session, the ESCs were still cool to the touch! So that’s what happens with your MOSFETs aren’t scientifically shorting the batteries 16,000 times a second.

I knew from my own controller designs that the amount of DC bus capacitance mattered immensely for the controller’s survival. Capacitors are a fast-reacting local farmed 100% natural and organic non-GMO source of electrons for the immediate switching of bazillions of amps. Without enough capacitance, those electrons have to come from somewhere, and that usually involves getting sucked through comparatively small-diameter wires, causing voltage sags and spikes as the FETs turn on and off. These ripples mess with the stability of everything. There is literally not a thing as TOO MUCH BUSCAP, and the vast majority of R/C hobby controllers are under-capacitored by like a whole order of magnitude.

I had to remove three of the five capacitors on the dlux 250 in order to get access to the microcontroller – they’re soldered on AFTER that shiny aluminum case is put together! There wasn’t much I could do for now – I ordered some hardcore electrolytic capacitors – UCC GPD series, in the same size but much greater capacity and ripple current than the unknown Chinesium caps on there. The original capacitors were combined 2350uF (5x 470uF), and just two of those are 4,400uF.

But they wouldn’t get here for a while yet. For now, we’ll have to take it easy in testing. I turned my attention to finishing the rest of the hardware, since Sadbot was also to test one more thing for the still-being-designed Overhaul 2.

Let’s put together the pokey stick! The item that I was machining in the last Sadbot build report has been welded to the 1.25″ cross shaft.

Here is a third P80 +SK3 module mounted to the frame of the pokey stick. I was also going to employ the SK3s in the lifter for Overhaul, so I wanted to test what kind of gear ratios I needed. Sadbot was designed explicitly to use the same gear ratio on the pokey stick and the same arm length as OH2 (at the time).

To design the gear ratio, I actually approached it from the speed perspective. A lot of gear ratios in the high tens to low hundreds-to-1 would have worked if I were okay with the SK3 guzzling a hundred amps to do so, which it will happily do. But to give the design more room for error, I limited the maximum speed of the lift to a combination of something that sounded sane to me – around 3ft/s as well as was an easy ratio to make using sprockets. I ended up being the most happy with 192:1.

At this ratio, the SK3 only needs about 70 amps to lift the designed mass at the end of the stick, and it was an easy combo of a 16:1 P80 gearbox (which I had on-hand from Overhaul’s actuator as a spare part never used), a 4:1 chain stage, and a 3:1 chain stage.

The frame is bolted to the baseplate using a bunch of cap screws (the vaguely H-shaped pattern on the upper half of the bot). Even though this is a lot of steel, I’m fairly sure in actual fighting conditions the baseplate will warp since it’s holding on to the pokey stick frame entirely by itself, so if I were to rumble this against the Boston-based 250s later, I might weld in some frame reinforcements.

And that’s basically it! At this point, Sadbot weighed around 235 out of 250 pounds. Stuffing some controllers, heavy wiring, and a top plate ought to bring it to around 240, close enough fo rnow.

I cooked up a new ESC mount for three dlux 250s on the Mark One (this was all back at the IDC prior to me leaving), and also a switch mounting bracket. This device stacks three dlux 250s on top of each other and sandwiches them together.

An alternate wiring scheme was also needed, since I was no longer just connecting two ESCs and the ring terminal stack on the master switch was getting too fat. I dug around in my wiring products cabinet and found an old audio power distribution block. It split a single 4 gauge wire to four 8-gauge wires.

After whipping everything together, it was time for test number three, now with 100% more pokey stick!

Ouch. Well, something was sure unhappy…

The post-morten of the failed ESC shows an average HobbyKing afternoon barbeque with your friends “Lack of gate protection on the MOSFETs” and “Poor PCB layout and component arrangement”.

But that asshole “Not enough buscap” keeps showing up even though you didn’t invite him.

I think I can identify the exact point while driving when these capacitors let go, to be honest. The bot went from driving smoothly to suddenly “cogging” (missing starts).These capacitor leads are obviously made of steel. They’re magnetic! That should tell you about their quality in general, really.

It was clear that with the firmware tuned so rigorously that the hardware could no longer keep up.

 Luckily, my Übercapacitors showed up. Honestly, I want to replace all five of the former caps with these. Two might be enough by capacitance, but even their wires can only handle so much ripple current. It was a short job to replace all of the remaining caps inside the ESCs for now, and I could think about how to add the rest back later.

To my horror, I discovered that during the drive-and-poke test, all three dlux 250s had at least one melted capacitor. May Brushless Robot Jesus save me.

The one that let go had both capacitors fail.

 

While Sadbot was taken apart for surgery, my 4:1 Banebots P80 stages also arrived, so I went ahead and swapped them out. This drops Sadbot’s top speed down from ~18mph to ~14mph. You know what? I’m fine with that.

A higher gear ratio means the motor has more leverage against the load, which helps in starting reliability. One of the things I taught in the EV class was this caveat for designing your drivetrain, which affected only the students who chose to go with R/C systems and sensorless drive… Hey, once they got going, it was great… They just had to do the “hump-in-place” dance to get going.

It was time for the ultimate test of ultimate destiny. Added capacitance (relative to how much they started with, hence the +2000uF you’ll see) and no further settings changes. The test subject, a piece of crufted lab equipment, weighed around 100 pounds – it was some kind of shaker table for chemistry magic, so it had a very heavy cast iron frame inside.

Result? Absolutely gorgeous, in my best Steve Irwin voice possible. I honestly forgot half of my own driving advice here and was handling it almost like Uberclocker.

What happened at the end? Well, inexpensive robot gearboxes gonna inexpensive. The P80 shaft is only retained by 1 snap ring on the inside, which got levered out from the rapid reversing loads of throwing the shaker table around.

I pulled the gearbox apart for a post mortem:

This was after I pushed the shaft kind of back in. Notice also the deformation of the D-shaft. This is another limiting factor which will affect how much torque you can push through these. An industrial planetary box like an Apex or Parker might have a one-piece machined shaft, or a shaft that fits into the carrier with huge splines. A D-shaft will concentrate stress of torque transmission onto the vertices of the D, and they’ll start deforming.  The mating D-bore in the output carrier fared much worse because of the shaft being mushed out of it.

This is actually a good destructive test of the P80 for the Overhaul 2 build, so it will make me strongly consider how they are mounted. It seems like the P80 will definitely need dual-support for high torque loads, instead of just hanging a sprocket off the motor (single support)

For further testing, I was going to haphazardly dual support the output shaft on the other end. I used the Mark One to 3D print this fiberglass-reinforced nylon bearing bracket.

The bearing bracket anchors into the baseplate and braces against one of the unused slots in the pokey stick frame, and grabs the shaft with a shaft collar. It looks sketchy, but entirely resolved the “shaft exploding out of the P80″ problem in further tests.

Unfortunately, video of these further tests weren’t collected, because by this point I’d gotten too spoiled by Sadbot working too well and would casually whip it out and impale dumpsters practice driving.

And here is the finished bot. Sorry BattleBots, this is all you’re getting. No Overhaul for you.

That top plate was a piece of 1″ thick UHMW plastic that I recovered from a group getting rid of materials. It was cut out of a larger piece using the CNC router and then “cut interior features to fit” with a jigsaw. This is actually pretty damn serious top armor in the realm of heavyweight weapons that exist right now! The total weight of the bot in this photo is 243 pounds.

During January 2016, Sadbot was moved to the Artisans Asylum along with the rest of my robot stuff after I left my job as IDC shopmaster.

Lessons Learned and So Can You!

Wow, that was a FRIGGIN’ YUUUUUUUUUUUGE build report, and probably a whole lot of material to go through. After finishing Sadbot and testing, I was entirely confident on using chopped up R/C model brushless parts for Overhaul 2.

Let’s start with a quick cost breakdown, not including “head-desking time” a.k.a nonrecurring engineering costs, which is basically the pains of developing unit #1.

  • SK3-6374 motor: $80
  • Banebots P80 4:1 gearbox, standard shaft: $90
  • dlux 250A HV controller: $210

For around $380, I get a small gearmotor that weighs 4.5lb (add 1.5lb for the big controller) which can push, by my visual estimates as well as via the Torque Calc, basically equivalent power and tractive force to the twin F30-400 drivetrain of Overhaul with a vast majority of the operating envelope. More testing will obviously be required from here to get a feel for the more long term reliability, especially of the P80s’ output shafts. Additionally, Sadbot has yet to complete the “drive off a loading dock test” to shake up everything.

Recall that all of this testing basically went on while I was working on Overhaul 2′s design, which is why you saw the SK3/P80 combination right away in the first CAD post.

So, to break down all of the testing and info presented here into a “How to” format. First, some caveats before you think brushless drive with Hobbyking gear is the harbringer of the robot apocalypse:

  • Brushless drive isn’t for everyone, yet. This is just one highly experimental implementation and only one branch of hardware testing out of many. There may be no hackable R/C hobby ESC which works best in all three domains of adequate operating envelope, reliability, and cost. Custom hardware might need to be developed to maximize all 3 of these needs.
  • The shortcomings of brushless motors remain. Even if the motor can push as much power as one three times heavier, it just means the power wasted as heat is being put into a mass three times smaller. Brushless motors win in power to weight ratio for sure, but even though they are more efficient (often 20-30% more efficient, up to 90-95%), they can draw much more current and heat up much faster. I will need to make sure that Sadbot can run for 3 straight minutes of hard driving and not toast the motors – so far, they’ve been good, but this was outside, in January, in Boston.
  • Gear low, not high. The more opportunities your ESC has to read your motor before it faceplants into the robot’s inertia, the better. That means possibly choosing a faster Kv motor over the lowest possible Kv (or RPMs per volt input rating), and gearing down more than you otherwise would. Furthermore, “chain slop” or drivetrain backlash is less preferable as a cheat to get around gearing – since once the ESC starts the motor and begins to estimate its speed well, the motor might just, once again, run into dead-stopped robot.
    Spring-compliance is preferred to “deadband compliance” a.k.a backlash. A high-ratio planetary gearbox, for instance, gives plenty of springy compliance, as do long-but-tight chain drives, or rubber belt drives. Spring compliance is where the whole system still transmits the forces, but stretches and unstretches smoothly to effect more gradual motor speed changes.
  • I still wouldn’t use this in a pushybot, says Charles, as he designs an all-drivetrain Battlebot. The region near zero speed is still a minefield with sensorless controllers. Your driving style has to change a little, and every small bot builder which has used the AfroESCs and other hackable controllers in the 12/30lb classes will agree. Basically all of these bots have been weapon platforms, which brushless drive helps by being super light weight and power dense in a bot which does not demand all from its drivetrain.

Next, here are some tips if you want to peek inside your surplus stash of massive R/C airplane controllers to flash SimonK onto them.

  • Increasing PWR_x_START increases the initial current into the motor, aiding starting. The more important ones are PWM_COOL_START, PWM_MIN_START, and PWM_MAX_START. I don’t think cranking these all the way up to “Max PWM %” will help, but certainly moving them from the stock settings did. However…
  • The greatest improvement in drivability came from well-tuned COMP_PWM (with appropriately set DEAD_x_NS times) and BRAKE_SPEED & BRAKE_POWER maximized. What this means is that the robot will never coast. It will always be forced to travel at a speed associated with your stick position, and the controller will actively brake the motor to do so. If the robot is able to coast, the controller has to push power into the motor to fight that forward velocity first, which may make it skip poles (cog) if you command too fast of a speed change. Whereas with braking, by the time you command reverse, the controller’s already brought the motor to a stop.
  • Higher timing angles do not necessarily help. For all but the very first test, I backed down the MOTOR_ADVANCE from 30 degrees to 15 degrees. Some keep-ahead is beneficial for higher speed operation, but too much will actually cause problems with inertial loads like robot drive. The firmware does not have an actual motor state observer which reads currents and voltages to solve for rotor position. It is basically performing open-loop numerical wild-ass guessing.
  • A smoother driving style is helpful. Don’t stop, then go, then stop, then turn, then stop… The more you keep away from neutral stick, the better your life becomes. Even if one side of the bot is moving and the other is standing still (turning about one side), it is trying to force the standing motor to rotate, which aids in restarting when you pull out of the turn. Learn to figure skate and stunt drive with your robot.
  • Every ESC needs more capacitors. Period – small bot or big, chances are the capacitance that comes with the ESC is borderline if not straight up laughable. Additional buscaps should be a low-ESR electrolytic capacitor strapped as close to the power devices as possible – a capacitor a foot away at your battery isn’t going to do anything. Additional caps help smooth the power input and keep the ESC motor sensing circuitry noise under control, as well as prevent violent voltage ripple that can damage the FETs. Caps are especially important in low-speed, high-current scenarios which is what every bot faces at some point, like during a shoving match (something something DON’T USE THIS IN PUSHYBOTS…)

So that concludes this grand treatise on brushless drive systems. I didn’t report on this as I went, as is my usual habit, because I was completely unsure if it was going to work at all at first, and then it turned into a bit of “secret sauce” for the BattleBots build season. However, I feel like this is now the right time to help paint a clear picture about brushless drive, especially for bigger bots, since by the state of the art of brushless motor control today, SimonK is quite crude – simple but crude, which is perhaps what works best for robot fighting. Other “DIY” and open source motor controller threads have been quietly woven together by their own communities over the past 2-3 years alone, and my attention is beginning to shift to those. Maybe I’ll pick up a set of VESCs to test on Sadbot in the near future, or I might just get back to Brushless Rage

But now we can go back to Overhaul build reports!

For actual motor control SCIIIIEEEENNNNCE, I recommend reading two things: James Mevey’s thesis and Shane’s website. I just poke things until they work.

The Belated Overhaul 2 Design & Build Series, Part 7: Cleaning Up the CAD Details, Sending Parts for Manufacturing

Apr 28, 2016 in BattleBots 2016, Bots, Overhaul 2

Wow! Can you believe it’s ONLY been only a month since the last Overhaul 2 D&B series post?? I felt like it was last year. Time flies when you’re trying to finish a robot.

So the truth of the matter is, if you might have guessed, the competition and season filming is already done. Everything was packed up and shipped on April 5th. Prior to that, the build season got hurried, so I prioritized having a robot over blogging – I know, such shame. Now that I’ve recovered, I can finally return to writing the design and build up. The plan from here is to finish up the design and move onto the build process, because now I have a whole new set of content to pre-game – the event itself! Those posts will be released as the show airs, because spoilers.

Anyways, the very last portions of the design for me to reach before “first-plass competion” was the top armor plate. After that, I could go and revisit parts of the design which nagged me or just didn’t seem right.

The nice thing about having a design that’s almost done is that the last few parts are easy to generate. That’s usually what causes me to CAD more efficiently after I start putting some parts down – there’s less of a need to “design” than to “wrap this thing around that thing”. Conversely, it’s the first few parts that really define the function and shape of the assembly, so you can’t really just skip that.

This top plate is just a “follow the outline” exercise, similar to the bottom plate. The anticipated material is 4mm titanium. I allotted that for weight, but might also make one from 7075 aluminum to save another (roughly) pound and a half in case it’s needed.

I decided to open up an air vent in the “giga bracket” on each side right above the SK3 motors, and save some weight by not having the armor extend out over them. From the previous post, one of the things I wanted to have was a cooling fan which pulled air through important parts of the bot – namely the drive motors and motor controllers. A mockup of the fan is shown near the upper right, where there’s a spare cavity in the bot. It’s a 92mm high-speed server rack cooling fan, and it fits almost perfectly between the frame rails.

To facilitate cooling, I also added a ventilation grille feature at the very back of the bot. This admits air through the battery pack area (which is shorter than the electronics deck), which allows it to flow through the motor controllers. The batteries need minimal cooling, if any at all, so their placement in the air path is incidental.

Save for some minor dimensional changes, this was the end of the top plate. You’d notice that the master switches are just kind of hanging out in the open… That will be a problem to solve later. For now, I declared #yolo and moved on to the obviously most important part of OH2 if you listen to everyone else: the ears.

Fun trivia about Overhaul 1 which most people still don’t know: The famous ears of the bot were a 11th-hour, Hail-Mary addition to aid exclusively in self-righting. The bot was pront to becoming stuck upside-down in a tilted position, and the ears forced the bot to always fall straight backwards if overturned.  This was due to the clamp arm being very tall compared to the bot’s footprint. The same issue is present in OH2, so the ears make a return!

To generate the ears, I first used the model to calculate where the center of gravity of the assembly was when the bot was upside down, and basically rotated the assembly in the view window until I found a satisfactory “line of tipping”. We did this on OH1 with the physical bot, but it was also simple to do in CAD. The idea of ear positioning is to make it such that there is no stable position in the tilted upside-down position because the ears force the center of gravity to act past that “line of tipping”, levering the bot over onto its back.

For instance, in that position, the ‘line of tipping’ is defined by the ear contact point and the back left corner of the frame. The center of gravity acts behind that line, meaning in this condition, the bot will always fall on its back. This hard to “see” in one screenshot, especially in a perspective-eliminating isometric rendering.

The caveat is that this line of tipping is only valid for a certain range of clamp arm positions. I tried to find a compromise with the arm in an arbitrary halfway-up position, like if I was trying to grab Bronco at a bad angle and got wanged (that’s a technical term) over. If the arm were fully raised, there was no position which satisfied the criterion, so like in OH1, I always need to make sure that I begin powering the clamp arm downwards as soon as I think the bot’s about to go over.

Using the “best guess” without an ear already in place, I generated the shape using the side of the clamp arm as a reference plane. Like OH1, the ear will be a bent plate weldment attached to the side of the clamp arm. Once I had the general shape, I went back and forth in the assembly to tune the dimensions little by little. The determinant was a combination of “stickout” vs. aesthetics – too big and pointy, and it started looking ridiculous. Structural stability was a far lesser concern, since it’s still a large L-section of AR400 steel involved no matter what, but obviously the larger the ears, the more they wrench on the side of the clamp arm.

Trimming a bit of material for weight purposes primarily. The way this will be loaded in the majority is “up and down” from landing, so I was less concerned about the front to back taper being intact.

This is more or less what the final ear design will look like. Now, working on this caused me to remember something that I made a few weeks prior – the big gnawing tooth up front. Remember it from this post? It was made to “have something there” and now I need to think about it again. I was facing down having to get the thing manufactured, or somehow make it myself, and it was starting to be worrysome.

Version 1 of the tooth was a one-piece affair made from a big chunk of tool steel. Version 2 takes the “important part” and makes it machinable from a much more commonly found flat tool steel stock. The total thickness is 1.5″. To make up for the thickness difference between the clamp arm plates, the triangular upper profile of the tooth will just be made into some 0.75″ thick spacers, to be cut out of aluminum.

And with that, every element on the bot is “first-pass complete” in some form. Notice that the arms are still the slightly older curved design which I explained in the Pointy Things post.

I changed the color of the pontoons to more reflect the original concept. Short of a few changes made later on during “production”, this is what the final bot looks like.

the manufacturing process begins

There’s a big change in how OH2 will be made that is a departure from anything I’ve done before, including the OH1 build.

What’s going to happen is I’m outsourcing all of the “big machining” – the frame rails, the actuator parts, etc. – to outside machine shops. Not only that, but the large steel parts are going to be laser-cut through a commercial steel vendor. I’m basically only taking care of minor manual operations or “just need 1″ kind of parts.

This is a monumental change from everything else I’ve built, where the majority of parts have been made by me, in-house. I’m taking this step for a few reasons:

  • I decided that it was worthwhile to trade money for time due to the splitup of team JACD from Season 1 – I could no longer count on equally-skilled friends who can take a CAD file and go make it, then come back and keep working together. My team this season would be more “minion” than anything else, so I had to make sure the complex-skilled tasks were taken care of.
  • If I chose to do all the machining myself, I would have to be literally machining from now until the season, on machines which I could not guarantee that I had consistent access to. Factored in with leaving MIT proper, and I couldn’t guarantee that I would be able to machine anything short of using manual machine tools.
  • Equals Zero Designs still needed my attention and I’d rather be spending as much time as I can making sure RageBridge 2s didn’t have too many teething problems or manufacturing issues popping up in the field.

What this means is that the relative cost of the build was going to go up immensely, even with my contacts at Chinese production shops. I estimated each frame as being around $5,000 of machine work, and obviously needed more than one frame for spare parts. That’s always a trap with building bots – you never really build one robot, but more like two or even three, because what’s the cost of losing a match because you did not have any spare parts to restore functionality with?

Overhaul 1 was built for an all-up cost of around $9,000. With the machining estimates for both the aluminum frame and steel armor plating, I was looking at a minimum cost of $16-18,000 if not more. Oh boy, glad those RageBridges are selling…

I put togther a package of detailed drawings and accompanying models, like the one seen below for one of the frame rails:

 

Techinical drafting instructors and machine shop foremen, start cringing.

I play very fast and loose with my drawings – basically if it gets the point of the part across, it’s fine by me. One of the upsides of working with a “bot vendor” like Team Whyachi is they “get it” – combat robot parts tend to worry much less about precision and rigorousness of dimensions, because after 1 hit, it won’t matter any more.  But it’s hard to communicate that to a local machine shop.

The package of drawings was shopped around very briefly to a few places I’ve had work done with before. It was furthermore segmented into a few parts – the big aluminum frame, and some smaller but still critical pieces like wheel hubs which I wanted dozens of in order to ensure the supply of spare wheels. That way, if a shop had time for the frame, they could take that, but if one didn’t but could still run smaller parts, they could have the smaller hardware.

The bigger your production run, generally the more attention you get from a shop. Small, quick turnaround one-offs are about the worst possible pieces you can have hired out. Companies exist which specialize in that realm, but I can’t afford them :P

While awaiting word on quotes and lead times, I began to put together parts to be made locally. For example, the electronics box (revision 1) layout for waterjet cutting is below.

The plan as of late January & mid-February was to perform the support work in-house and using MIT equipment I still had access to, assemble all the electronics, motors, and batteries, and integrate them the same week that I should hypothetically receive my parts in mid-March.

As a preview of things to come, the first parts to return were the drive wheel hubs, made by a local (Boston-area) CNC shop I had done some business with a while back…

Aren’t they gorgeous? In the next episode, we’ll see how they go together…

In the mean time, if you haven’t already, make sure to Like & Subscribe!™ the Equals Zero Robotics facetube.

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.

#nope

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!