I like to think that nobody is intentionally making their team worse, but there are always things that slip through the cracks, or practices that you just haven’t managed to nip in the bud. What things are your team still doing that actively make things just a little worse?
I’ll start - we tend to start adding hardstops to things once a problem occurs, and have been meaning to be more proactive about it, just haven’t gotten to it yet.
We tend to assign buttons for things for testing that will not be the final button on the actual controller.
Our actual drivers never really get to experience these but it does result in some interesting conversations about which task/preset that share a button during testing get to be that actual button when the time comes.
If we would map out the controller beforehand it would save time and also avoid the discussion of “well a human hand doesn’t exactly enjoy making that shape” that has some time occurs
Not using loctite for practicebot assembly
Expected outcome occurs
Not following a logical construction path, or constructing things that cover up things that have yet to be constructed.
Its a thing that costs time in the long run, and combined with misaligned and undersized holes can damage structural integrity.
Temporary-quality wiring methods used on the “practice bot” that result in non-design-related failures in testing and associated delays.
Doubly true after the “practice bot” chassis gets a battlefield promotion to “competition bot” chassis, warts and all.
Not giving software the time they need or deserve.
That’s probably way more than 1%.
Not considering how to quickly repair or replace that critical part buried deep in your robot.
This is our first year designing a robot from scratch (we did a modified everybot last year), so we haven’t done as well as I would have liked with CAD organization and using best practices.
I suspect there will be some panicked hammering and drilling happening over the next week to deal with clearance issues and stuff that will probably crop up from that, which will also take away from much-needed driver practice.
Stripping your screw heads
Having several little spacers in a tight space on an axle. Really hope we never need to take that off!
Nothing so permanent as temporary.
Forgetting to double check the hole alignment on predrilled stock and having every hole on the cut piece wind up .25" offset!
Additionally, not know how the robot is wired, inspectors need to see them wires, and you need to repair them.
Make things easily swap-able, have standards and stuff!
CAD workflow & drawings.
Constructing without complete CAD (“You said this design is good, yes the belt is spaced correctly but why is it rubbing on this spacer?” and its friend "how do we get to that bolthead?)
Constructing with 2D-only CAD (“Yes, all the spacings are correct and everything spins the way its supposed to but this transfer shaft is cantilevered off your plate into empty space…”)
Deleting part studios when “we need a new version” and not saving off archive copies of parts/revisions that get cut for prototypes. Resulting in my favorite yesterday “We broke the prototype but we can’t cut more because the CAD doesn’t exist anymore”.
Cutting parts without paper drawings, makes it a lot harder to do mid-process checks.
And its corollary: Using worn out allen wrenches. -which in turn strips more screw heads.
Not maintaining our machines properly, especially our ancient 1990s-era AXYZ router that spits out most of our manufactured parts. Somehow it still runs well enough to give us mostly straight hole patterns.
The first thing you see in its manual is “WD-40 IS NOT A LUBRICANT.”
Assuming batteries are charged and wire connections/crimps haven’t come loose.
“1/4 and 3/16 are basically the same thing”
I’m going to put one I’ve seen a lot of teams do. Use controller buttons as toggles. When you’re in the heat of the match, you don’t have time to think about what state a toggle is in, and what pressing the button is going to do. And you certainly don’t have time to look down at the screen to know what state you’re in.
Instead, either use 2 buttons with one forcing one state and once forcing the other, or a single button that switches states while held and switches back when release.
Granted, from the cases I’ve seen teams have issues with this on the field, this actually might be more than 1% worse.
Using mismatched/not standardizing hardware.
Forget to turn the robot on.
Leave the main breaker where it can be easily hit by random stuff.
Use wood screws to attach your bumper brackets to your bumpers.
Oh, sorry, I thought you said 10% worse…