So I very rarely go off on polemics on this website. In fact, I can’t recall the last time I straight up roasted something, besides laying on Sparkfun periodically for getting their breakout boards amateurishly wrong, or complaining about literally everyone else’s motor controllers. I try to stay focused on relaying the technical and weaving tales of implementation while discussing mistakes and could-have-beens, because I enjoy clearing up the fog of knowledge when it comes to building. Not only do I like making my work accessible, but I hope every motor controller I blow up also creates a record of what kind of REALLY? IT WAS THAT? mistake the problem ended up being. It’s always that.

A little to this end is my tendency to never claim I know something that I actually don’t. I hope I’ve been pretty good at keeping to this philosophy, and you’ll notice in many posts that I tend to express uncertainty when explaining a problem because I don’t know everything about it at the time, and the reasoning will probably change later. Furthermore, as you doubtlessly know already if you’ve been on the Internet more than an hour, the quickest way to get correct information on the Internet – whether you like it or not – is to be publicly wrong about it.

This is a double-edged sword; I’ve wielded it cloak and dagger to get correct information from enthusiast groups & forums of technical discussion before, and it works great! Try it some time… just say something nitpickingly wrong, such as “You can totally use frequency-injection rotor saliency detection on surface permanent magnet motors with an Arduino!” and someone will be bound to reply “Well technically, it depends on your stator saturation model“.

Well Technically is the zip ties and duct tape of unsound technical reasoning – collect enough Well Technicallies and any poorly-founded conjecture will stand up on its own, suspended by the tensegrity of vague wording and handwaved speculation.

If you didn’t understand what the hell that example meant, don’t worry – I didn’t either. That’s why it’s nitpickingly wrong.

On the other side, relaying incorrect or incomplete information opens yourself to being called the fuck out, which is what I intend to do. So let me begin with

Stop. Talking. About how every problem in the robot fighting world will be solved by the Inter-fucking-net of Things. Or how builders should just try smartphone control already. Why don’t we all use DEEP LEARNING to strategize matches in realtime? Just shut up and build your first kit antweight.

It seems like every few months, someone on a public robot fighting related forum will make a contentious point about how NOBODY USES WIFI TO CONTROL THEIR ROBOTS? WHY? or champions the favorable characteristics of switched-reluctance motors which they learned about on Youtube approximately one millennial attention-span ago (Oh shit, I made a millennial joke! Is this self-deprecating humor or am I just a lawn security officer now?!). I regularly have people ask me why nobody uses Swerve Drives when all the high schooler robots do it already. With near certainty the poster is pretentiously tech-savvy about the Connected World or is an Internet of Things developer who probably has an Amazon Echo bickering with a Google Home about control of the sex lighting in the basement, ON YOUTUBE.

AND WHAT ABOUT  Ｄ　Ｒ　Ｏ　Ｎ　Ｅ　Ｓ ？

Robin Mitchell of Allaboutcircuits, I am now talking directly to you. In your recent article “The Resurgence of BattleBots and Robot Wars“, you put forth such affronts as “…the new Battlebot and Robot Wars series showed little technological advancement with regards to sensors, microcontrollers, and electronic warfare.” and propositions such as “…use multiple relays that isolate separate batteries from the robot which can be switched on and off using the main controller.”

Hang on a second – let me go find a “relay” that is rated for the combined current draw of all of Overhaul’s drive motors. Want to see what it looks like? This is it:

When they get that big, they’re called “contactors”, but that is besides the point; I’ll get to reasons why automatic power failover is a nice thing but (to my knowledge) completely unseen in robot combat.

Let me be clear here – I have no personal grudge against you, Robin, nor do I have a problem with Allaboutcircuits, a site that I used to reference daily years ago and should continue making a habit of. If you’ve never built and fought robots, it’s a perfectly excusable pass on the misinformation front. Everything you presented can technically be achieved and could possibly be used productively in robot combat. However, recall the 2nd part of my thesis regarding being wrong on the internet: this article is also epitomic of all of my presented complaints about outsiders observing the “technology” in combat robots and snidely commenting on it, so I feel implored to reply.

1. On the structure of precision language

One of the hallmarks of technical misinformation is nebulous & vague wording that sounds good to the casual onlooker, but sooner or later you’ll run into someone who actually know what the hell they’re talking about. The article is absolutely infested with these missteps, starting from the very beginning about rapid prototyping.

No, rapid prototyping is not JUST 3D-printing. Rapid Prototyping is a set of techniques – of which 3D printing is just one – which ideally help you reduce the time and effort needed to produce working products or concepts thereof. Though everything I do can technically (there’s that word again) be construed as rapid prototyping, nothing about Rapid Prototyping must involve a computer or a poorly-built kit noodle-pooper.

In modern parlance it is often assumed to mean the same as digital fabrication, which 3D Printing is most definitely a part of: computer-controlled machines which generally perform one task whether it be machining or extruding or lasering the ever-loving shit out of something, which can be quickly set up (rapid) for the creation of objects (prototyping!) more or less directly from a digital design file.

Now, what does this have to do with robots? Rapid prototyping techniques (plug!) and equipment have contributed to a vast paradigm shift  in how small and large class entries alike are built, and despite not being very visible on the BattleBots TV show, a significant number of entries had 3D-printed parts inside. Hell, I’m one of the two teams sponsored by MarkForged, a 3D printer company which is on the intermolecular-bond-splitting edge of 3D printed material properties.  You can also barely find a 150 gram to 3lb (“insects” class) bot these days which doesn’t have some kind of 3D printed artifact on it, possibly even entire frames and even including weaponry in the new “Plastic Ants” class.

The newest “easy way” for builders to start is no longer piecing together R/C cars with Home Depot sheet metal, but grabbing a 3D printer. That is huge. The first moment I ever felt old was the first time I was casually talking to a freshman in the fab shop that I ran at MIT and the subject of building a 3D printer just casually came up as “Oh yeah I built one of those in high school”. Bam, just like that, I officially entered intellectual cruftdom, the derpy 80s prismatic van state of epistemological being.

Beyond the limited definition of 3D printing, you have robots utilizing laser-cut steel unibodies that are ordered direct from a steel vendor by sending them CAD files and pieced together in just hours with a welder, bypassing dozens if not hundreds of man-hours of shaping metal, fitting it together, jigging it all up for welding, and then doing the welding. Every curvy or fancy looking robot exterior on the most recent show was likely not trimmed by hand, but waterjet- or laser-cut in minutes. That is the real magic of RP techniques in robot building, and I do think a lot of the current “innovators” in this realm are recent college grads & young professionals who have seen the techniques used elsewhere and brought it to the forefront in the sport.

Besides painting ideas in broad strokes, there is also a tendency by Modern Technology people to speak generally of executions, never having to have executed them or thought about what their ideas really entail. Going back to the relay problem, the solution (to a problem I contend does not actually exist) is:

One possible method is to use multiple relays that isolate separate batteries from the robot which can be switched on and off using the main controller.

Soooo…. does that mean making a battery isolation system out of relays? They sell devices for that, often for RVs and boats with multiple batteries. Either solution (neglecting the practicality of a 3rd or nth power source exclusively for the logic) means you need “relays” that can each take the full operating current of the bot, and I showed you how big that part is. Wait – no, back up. Before we even reach that, this implies you already have multiple batteries each capable of running the bot separately for the duration of the match, unless you size them to require mid-fight changeover.

Imagine if Tombstone had 3x the number of batteries it actually needed to run a match. That would be a riot! Good luck designing this system within the weight limit while still maximizing your robot’s operational ability! Lithium polymer batteries be magic, but they’re not that magic just yet.

On top of that, you have things like

The communication system could also be improved in many other ways including the use of a microcontroller instead of using an RC module with outputs that connect to actuators and subsystems.

Okay… yo, what does this even mean? You know all R/C receivers have microcontrollers in them, right? And every motor controller? If you don’t have an R/C module (which I guarantee the author doesn’t know is a real, commonly used, and nice thing that goes into your handheld transmitter  – Overhaul uses a 400mhz Long Range module system that can conceivably let me control the bot from over 10 miles away)  what does your microcontroller use to talk to your smart watch and smart dildo that you’re using as a robot control input?

If a player switched to 2.4GHz and used a module like the ESP8266 then…”

INTERNET OF THINGS BRO DETECTED! You’d swear with the number of people singing the gospel of the ESP82x system that it will singlehandedly stop Russia from starting Cold War 2: Thermonuclear Boogaloo on the 20th here or something.

(Nevermind the fact that the preceding sentence to this misplaced quote “The radio frequency that these robots use will most likely be around the 27MHz channel” is absolutely, indisputably incorrect, as 27mhz has been banned in most larger weight classes since the late 1990s and prior to the rise of 2.4G spread-spectrum hobby radios in the mid 2000s, most robots were mandated to run on 75mhz using compterized PCM transmitters. This is just being factually wrong instead of spiritually wrong.)

Anyways, in this case, I assume what’s going on is another case of hipster engineering colloquialism – when certain people say microcontroller what they mean is an Arduino. Yes, a separate microcontroller can be used to collect all of the information proposed – voltages, currents, temperatures, etc. Again, there’s that Well Technically factor: Yes, you could collect all of this data, and yes, you could transmit it over WiFi to an iPad set up with a custom dashboard app you wrote, but all of the data in the world about your CO2 tank upstream pressure doesn’t help you when the tank has been eviscerated and unceremoniously thrown across the arena by Minotaur.

Having these onboard sensors does not inherently make the robot better at robotting. It’s like having the same telemetry in a car – it will help you potentially tune the car for performance, but does not alone make it faster. This information could very well help you discover a design issue with the robot – motors drawing too much current and heating up too quickly? One weak battery out of four? Better take care of those before you run out of postponements! Telemetry and “sensors” comes up a lot – likely because people who keep ragging on this are IoT bros – and the praise of Team Storm in the opening for adding sensors to their old and tired design to instantly make it ｍｏｄｅｒｎ , parallel to the phrasing of robots being “improved” by sensors, is a good example of my second thematic struggle with futurists in the robot world, which is:

2. On optimality of cross-discipline solutions

I don’t blame people for talking about automatic battery-switching failure detectors or first-person view cameras with dynamic robot-to-field orientation control or any of that. The fact of the matter is, they could be speaking from experience (or out their ass) in a field where such things are common and expected – automatic failover is virtually required in server power supplies (and the servers themselves in modern datacenters). FPV is increasing in popularity within the vaping rig drone community because flying a drone while “sitting in it” can be very intuitive, more so than trying to stare at it from 1000 feet away.

It is the insistence that their favorite golden engineering goose will equally lay golden eggs across all fields, without any relevant experience to back up the fact, which I am considering here – the insidiousness of Well Technically is at play once more. Again, I don’t care so much about being straight-up factually incorrect, because that’s easy to fix.

Remember the Reddit thread I linked to at the beginning. If you haven’t Reddit, the gist of it went something like:

Well, robot builders don’t like new things like WiFi – look how long it took them to use 2.4Ghz radios!

That’s because most R/C 2.4ghz systems for sale did not meet robot-specific needs, but now they do.

…But robot builders definitely don’t like new things, look at how few people use brushless motors, everything uses brushless motors!

That’s because most brushless systems for sale did not meet robot-specific needs, and still kind of don’t.

WELL GEE I THOUGHT THIS SPORT WAS ABOUT TRYING NEW THINGS

Let’s talk more about swerve drives. Swerve drive, bro! Holonomic motion, bro! Got 8 degrees of freedom on my drivetrain, bro! Any direction, any time, bro! My conversations with what must be the closest thing to the Jehovah’s Witnesses of robotics because they will never, ever shut up about DO YOU HAVE A MOMENT TO TALK ABOUT OUR LORD AND SAVIOUR TEAM 221? swerve drives once they find out I build combat robots consistently goes something like:

Do any battlebots [with a lower-case B, this is important] use swerve drives?

Not any current ones, only a few have tried in the past, but none have been successful.

Oh, that’s weird. They’re the best drivetrain for this kind of stuff.

Why do you say that?

You can move and attack from any direction!

You certainly could, but durability due to the increased mechanical complexity is a concern, as well as added weight.

Well you just have to { CNC machine all of the parts from titanium, use this design I found on ChiefDelphi, place them closer to the center of the robot and armor around them };

Additionally, not many weapons and strategies can take full advantage of omnidirectional motion. It all comes down to design compromise and what you want from your robot.

Well you can just…

Those choices in brackets? I’ve personally had to absorb and nod my head to each of them. My most memerable instance involved someone literally following me for 10 minutes describing how if the robot just had 4 flipping arms, one on each side, then it would be a good use of swerve drive because it would be universally defended.

JUST.

That word is like the dual of Well Technically, like the superhero and supervillain comic story of Half-Baked Idea City. For every Well Technically rebuttal, there is a Just conjecture.

Now hang on a minute here… If your robot already has weapons on every side, does it really need omnidirectional motion at that point!?

All of this might sound like I am the sheriff of the GET OFF MY LAWN police force. And you know what – maybe I am a rookie officer in training, having been in the game for too long and the ‘stock solutions’ for common strategic problems having calcified in my design process. But let me be clear here: What really Brinells my bearing races is not that people want to try to build Cloud-powered Robots-as-a-Service, but that they immediately pose it as the best possible solution to a problem they otherwise profess ignorance to. It’s not that you can’t use ESP8266 modules in your custom radio, but the coming right out guns-ablaze and saying that it is better than R/C radios.

Better in what way, being easily customizable beyond user comprehension in an application where communication errors can result (and have resulted) in the runaway of a machine literally designed to kill the fuck out of other machines?

It’s not that swerve drives have never been used in BattleBots (we don’t talk about Radioactive), but it is always presented as inherently better than tank-style steering, despite the added moving parts that must remain in close alignment to work properly, because in combat robotics all of your parts always stay aligned!

What these examples have in common is that people will take their knowledge of something which has an apex predator status in their field of work (or interest) and assume that it would work just as well in another context, change be damned. Robot fighting, truth be told, is a pretty damn redneck sport in the grand scheme of technological competitions. Nothing that relies on banging two objects into eachother really hard for entertaniment can be that refined, right?

We are, in some sense, a bloodsport of technology. That has historically made robot fighting easy to talk down to by people working in technological industries, especially software and AI. Add to this most bot builders being in the mechancal engineering or machining/fabrication industries, or simply being mechanically inclined, and you have a perfect fuck-shit-stack of lost-in-translation: The finery of the often extensive mechanical design work and manufacturing effort being unappreciated by someone who’s never picked up a tool, and the perception of sophistication they associate with their choice of career, or their preference of controls and intelligence complexity.

The person who followed me around the building trying to convince me that swerve drives were the Alpha and Omega of robotic drive solutions? I challenged him to build a scale model of his concept robot in any weight class, and that I would permit full normal usage of my shop for the purpose and make myself available for consultation. Never heard a peep from him since.

Don’t be that guy. If you want to explore “smartening up” the sport, do so and deliver. Probably the most under-stated thing at BattleBots Season 2 was the auto-targeting hammer of Chomp, and it’s a shame they devoted only like 3 sentences on the show to it. Very few people have ever attempted auto-firing or target-seeking weapons. They knew it was a huge risk and that it might not work, but GOD DAMN IT WAS DELIVERED. I like to think that I pushed the front of using hobby-class brushless gear in robot drives with my 6-month-long development cycle and immense risktaking getting Overhaul 2 into the arena with all HobbyKing motors and controllers. The evolution of technology in robot fighting is truly, and some times literally, trial-by-fire.

Go to a competition and learn what kind of details you might have missed while perfecting your off-the-wall design concept; enter a kit antweight and get your ass handed to you in a match to see how hard it is to maintain an entry. Then build your gesture-controlled SLAM-navigated swerve-drive Hoverboard-motored* Internet-of-Things-connected self-Tweeting BattleBot. The whole sport would appreciate your contribution, even if it gets turned off at 0:11 by an errant power-handling relay.

*I challenged myself after talking to the High Priest of Swerve Drives to design a swerve-module which could conceivably drive a 250lb Battlebot and not weigh much more than a typical drivetrain does, while being heavy duty. This actually is possible, as illustrated by DeathRoll during Season2; it had four seg-thing motors running at 36V each and was pretty maneuverable. The module ended up weighing around 25 pounds, and used a A23-150 Ampflow motor for steering. Four of these would weigh about 100 pounds, so it could happen, but would need tight integration into the frame design to have weight for anything else like weaponry.