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 D R O N E S ?
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 modern , 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.
You’ve already seen that I’m integrating mecanum to add the dynamic motion of swerve without the mechanical complexity to my entry, Reckless. I thought I’d chime in because you meantioned Team 221, who have the Revolution swerve drive as part of their lineup. Well, I made that. Or, more specifically, my team, FRC 118 the Robonauts. Being involved in the development of Revolution in 2009 and the Revolution swerve that summer, I have a pretty unique perspective on swerve drive.
It fucking sucks.
We abandoned it starting 2010, and the team has never returned to it. The only reason our mentors used it on the SEV, MRV and Centaur is because space is a low speed application, and they probably aren’t going to space anyways. They’re just tech demos. Neither FRC nor BattleBots could possibly qualify as low speed, and a mere tech demo isn’t gonna cut it. And now that 118 has abandoned swerve, they’re world champions. Go figure. (RIP my high school dreams.)
My one defense of swerve using drop-in wheels like omni or mecanum is that it allows for circling like a boxer, which is why we’re using. But, drop-in wheels aren’t really the same thing as a swerve module, and is way easier to implement. Hellachopper was going to use mecanum in an omni square configuration. I think it’s a valid solution that will have an impact on the way the sport is played, same as Chomp did with her autotargeting.
On the controls side of things, I’ve run into that problem hard. My dilemna is that I want to control Reckless with a PS3 controller. It’s familiar, it’s ergonomic, and it has triggers and face buttons. In my opinion, it is superior to every aircraft controller I’ve laid hands on…except Arduino and XBee have an incredibly steep learning curve. My programmers are wallowing trying to get it to work, and we’re probably going to have to switch to a traditional radio transmitter just because of development time. If we had another year or an Arduino expert on our team we could probably pull it off, but for a group of mechanical engineering students trying to graduate while building a robot, it’s pretty difficult. I think a lot of these armchair roboteers don’t understand how hard it is to innovate on a deadline.
I couldn’t agree more with all of the above. I tend to think this is the case in all areas of competition-based engineering. We enjoy doing it because it forces us to both expand our knowledge of our chosen field beyond the limits of what we first thought was possible, and learn all the iffy old-boy rules of thumb. there is never enough time to do ALL the science, while building and testing in a short time span, so gain a nice feel for the engineering involved from understanding and experience.
I work in race cars and run up against the same the issues you do. Everyone is an expert and there are a lot of ego’s. However, there is a quiet few of us who actually get out at the weekend and try the theory out for ourselves.
I’m typing on a phone screen so I won’t go on.
FYI You have an awesome blog and it’s nice to have some smart-yet-tongue-in-cheek practical-yet-academic reading once in a while; keep it up!
Including Josh’s comment, I couldn’t agree more with all of the above.
Nth-ing Aviana on swerve drive. It is fine for very low speed robots in home and office environments, but far too slow and fragile for much else. The big issue with mecanum and onmi-wheels is the limited area of the ground contact patch, so you have to increase the size and/or number of wheels to match the traction of tank drive. Also, they often mount the rollers very close together and/or very close to the larger wheel structure, so pretty high risk of debris jamming the rollers (either large object between two rollers, or smaller object at end of rollers where they possibly rub against the wheel structure).
As for communications, Wifi was used at the start of MechWarfare (Trossen Robotics) for FPV but interference from other 2.4GHz devices nixed that. Most now use 5.8GHz FPV rigs from R/C aircraft for viewing and continue using 2.4GHz or 900MHz Xbee for control from either a dedicated hand-held controller (RPi or Arduino with joysticks, buttons, and Xbee for control; cheap LCD paired with FPV receiver) or a laptop with Xbee on a USB dongle.
Using Xbee is usually not too difficult and there are many examples out there. You basically pair two devices of the same class/specs and push whatever serial data you want between the two, but bi-directional comms for control and telemetry on a single pair can be iffy (switching between TX/RX seems to lead to long delays and dropped packets). For servos and motor controllers requiring PWM-inputs, there are several Servo libraries for Arduino that can transform the serial data received over Xbee into proper PWM outputs. The trossen forums would likely be a useful place to seek help with Xbee control of robots since many of their products use Xbee modules and arduino-compatible boards.
The biggest issue I’ve had with using PS3 controllers is actually getting them to consistently work with the PC. Using the USB connection is almost always successful, but bluetooth is crap for control even in a lab. One alternative I’ve used is a Wii controller hooked up to an arduino’s I2C port and then pushing commands over UART to an XBee (or dual-wielding Wii nunchucks on a Teensy-3.2; each one on its own I2C port since they use the same device address). Not as nice as a PS3 controller, but fewer issues with pairing since no OS is required.
I’m kindof a space nut, and you see this same thing in discussions about SpaceX, which are full of the same sort of uninformed suggestions…
“Yes, I’m sure that the SpaceX group that spent 6 months full-time would be excited by your suggestion…”
There’s a lot of Dunning-Kreuger (sp?) out there…
(I’m not a robot guy, but I always enjoy your posts…)
Charles,
I consider this post to be your greatest post yet. It may not have the interesting technical information of your normal work, but it was a great rant.
Ian McMahon
I feel your pain. It can be frustrating to hear the armchair quarterbacks suggesting wacky stuff, with no actual doing. Do more, talk less!