VEX Robot Construction Best Practices

I thought it would be good to have a thread full of all the best building habits for teams to reference when they are building/fixing their robots, or helping others on the forum. What are all of your team’s good build habits, that enhance your robot and make it more clean/reliable?

I’ll start out with a few:
-Always support shafts in at least 2 places, with bearings.
-Always make sure that moving joints are secure, but not so tight that extra friction is caused.
-When a gear is rotating a bar, bolt the gear directly to the bar instead of using shaft locks, to avoid twisting the shaft.

1 Like

I think this is a great topic, and I took the liberty of changing the thread title. If you like, I can change it back, but I believe this one better reflects what you are trying to do.

I’ll add one:

Triangles add stiffness to squares.

My main rules of building are

  1. at least 3 pointes of sturdy contact.
  2. if a screw is against plastic or a slot it gets a washer on both sides.
  3. No keps nuts unless theyre against plastic.
  4. the wiring has to be clean. if you can see wire its not clean enough.
  5. everything has to be symmetrical.
  6. all corners must be filed and smooth. NO SHARP EDGES!
    I have more but I can not think of them off the top of my head. I am very meticulous with my robots. I take pride in the work that I do, and I like that my teams robots have always looked very clean and professional.

When building have your teammate mirror you for more efficiency.

Not possible when you are a solo team…

  1. Support axles in at least 2 places with bearings but never more then 3 places.

  2. Use screws for joints. Always use a Teflon washer in between metal joints!

  3. Avoid transferring power through axles screw your gears to your arm!

  4. When you can’t hold something and screw something in at the same time use your mouth or feet to turn your Allen wrench, to start the screw ( I’m really good at this now from being a solo team)

  5. You can never have enough rubber bands

  6. Use chain to transfer power over long distances…

  7. When designing keep your center of gravity in mind ( you do not want to be tippy) and if you are make a anti tip device)

  8. Many more but I can’t think right now…

thats not entirely true. It is better to use chain if youre concerned about your motors. The chain absorbs shock that would transfer to your motor and ruin it, but if youre looking for more efficient power transfer, gears are the way to go.

  1. Put motors on independent and easy to remove mounts so they can be changed quickly.
  2. Build pre-assembled spare parts to speed up repairs.
  3. Have redundancies on the critical components of your robots.
  4. Try new things, look at the stuff that you don’t ever use and try to find a use for it. My team thought that the SONAR modules were terrible until I tried them, and now we use it on both of our robots.

Some good programming practices:

  1. Split the code into groups, and then separate it out into different files.
  2. White space, give an extra enter between functions and smaller processes
  3. comment everything, it’s very helpful when you’re explaining what your code does and helps in debugging when you’re having problems.

Perhaps he was talking in terms of parts.

  1. If you can bend it with your hand, it doesn’t belong on your robot (very few exceptions). We don’t use the 1xN plates for anything in compression or shear–we call it “metal string” and really only use it when it is constantly in tension.

  2. Your motors shouldn’t be doing the majority of the work to keep your arm raised.

  3. Limit switches for arm motions are mandatory; this prevents the driver from accidentally breaking something

  4. Claws are activated with pneumatics to save strain on the motors.

  5. Gears should be aligned; no half-meshed gears.

  6. Put a pot on the arm when possible for preset heights.

  7. Center of gravity should be low.

  8. Use your materials for the task at hand. For example, make your arm out of aluminum (makes it easier to lift), your base out of steel (so you’re not easy to push around, and your CoG is low), and a claw out of polycarb (lightweight, easy to form, etc.).

//Andrew

[INDENT][LIST=1]
*]Check for parallelism/symmetry. For example, when mounting a plate onto 2 side support bars, be sure that the plate is either above the lip on both bars or below both (don’t put one above, one below).
*]Standoffs are good for making 90 degree angles and preventing shear when triangles aren’t practical.
*]When mounting screws through the sides of C-channel (especially 2-wide), feed screws from outside to inside (heads outside, nuts inside) for easier tightening/removal later.
*]2 arms mounted onto an axle can be spaced at any interval, but the arms are usually connected at another place at a fixed interval holes. Make sure your spacing on the axle is identical to the spacing on the other parts of the attachment, perhaps with a support strip between the arms near the axle.
*]When using metal with slots or non-square holes, make sure that screws are not prone to “slide around” (unless it’s deliberate). For symmetrical constructions, be sure that the screws are mounted in the same position within the slot on both sides.
*]Before using a bearing block, spin the hole on an axle to see if it spins freely. “Squished” bearing blocks create unnecessary friction.
*]A screw with a lock nut in a bearing block makes a pretty good “frictionless pin” and is cheaper than a shoulder screw.
[/LIST][/INDENT]

Great topic – thanks!

1 Like
  1. Use aluminum where possible
  2. KISS - Keep It Simple, Stupid
  3. Standoffs. Standoffs everywhere.
  4. DON’T CANTILEVER
  5. Make everything modular - fixing things become so much less frustrating.
  6. Make sure you can access motor screws without much deconstructing. If possible, have them all accessible through turning a wheel. It makes replacing motors a piece of cake.
  7. Avoid half-assed work and solutions
  8. Do the “shake test”. If you shake your robot around and turn it upside down, and parts come loose or fall out, you failed.
  9. Don’t leave unused holes in your polycarbonate plate. That’s ugly.
  10. Think before you cut.

\RANT

I disagree with item 4. Cantilevering wheels can be OK IF AND ONLY IF IT IS DONE CORRECTLY. If the axle is well supported at multiple points and the lever arm to bend it is very small, cantilevered wheels will not be problematic. Our cantilevered drivetrains, from this year and last, have gone through at least 7 competitions without one instance of an axle bending.

Generally, not cantilevering is a good idea, but if you feel cantilevering is the best choice, it’s not that evil.

\END_RANT

Some advice:
Iterate, iterate, iterate. Build it once. If it doesn’t work as well as you’d like, fix it or build it again. Repeat. Competition-winning robots are the result of improving on many failed prototypes.

Get lots of software development time and driver practice. Bad code or drivers can make good robots lose and good code and drivers can make good robots DOMINATE!

Make your robot easy to drive. Automate repetitive tasks like raising and lowering an arm, so instead of acting as a PID controller, your drivers can focus on winning.

Linearize your speed controller output. No single software feature (Maybe. I really like my arm control system) this year helped us be successful more than applying a simple lookup table to the values fed to the motors. It allows for better control of everything at both high and low speeds. For more information, look here.

Here are the things I try to really drill into those I mentor, some of them may be more Design than Build oriented:

  1. Reliability is the most important part of your robot.
  2. Keep the weight low and central for stability
  3. Teflon washers on motor screws (between the screw and the metal) stop screws coming loose so quickly. The same goes for stand-off
  4. Rubber bands are great as help, but be sure your robot is still going to work if they all spontaneously snap
  5. The robot is never finished. Just because it works, doesn’t mean you shouldn’t keep working on it
  6. Always aim for something that seems slightly out of your reach. It keeps you learning, challenged and interested.
  7. Build for your driving style. Two drivers using the same robot will not have the same result - and I am not referring to more-skilled drivers
  8. If you are automating tasks like lifting an arm, make sure you have a manual function too - there are field tolerances to account for here
  9. Don’t bend metal. While it is often the easiest solution, it usually weakens the structural integrity of the area - also, bending it back later will rarely end up the way you want it to.
  10. Build section by section. If you have a chassis built, you know how wide your intake can be. Or, if you have an intake built, you know how wide your chassis needs to be. Doing everything at once may seem like a good idea at the time, but it will almost always cause you grief later piecing everything together.

Note: Point 10 is less valid if you do a significant amount of design work (which I always encourage!) but the teams I mentor never seem to want to do that :frowning: Also, document everything. Whether it’s for yourself, your junior teams or awards.

1 Like

hm…

  • Always Build with Purpose
  • Strategize, Plan, And prototype before building
  • Work in Bursts. Too much strain on members will add stress, too little and nothing will get done
  • Avoid Cutting/Bending metal as much as possible
  • Construct with keps nuts first, Then when everything’s finished replace with lock nuts
  • Pre-Competition/During Competition: keep your fellow member’s morale High
  • Build to 17.5". If dimensions require something more, than it’s probably not reliable
  • Give recognition to people who gave help and compliment those who performed well
  • When discovering a problem, notify your captain and offer at least one solution
  • Parallel Construct as much as possible: Work on segments in parts etc.
  • Deconstructing and reconstructing a certain area to add a component is sometimes faster than constructing with difficuty
    -Build with bolt heads facing outwards
    -If nuts are placed in hard to reach places, stick a hex key through the hole, string a nut through the key, and pull out the key slowly while a finger holds the nut against the material
    -if you must fasten something by one point, Always use a locknut
    -When fastening something that needs to rotate with a screw, use a lock nut. if youre prototyping, install the keps nut backwards
    -Assuming time is constant: Functionality, Quick to build, and Cost friendly. Pick 2
  • Protect all pwm prongs
  • Before testing a robot, ensure that no hands are on bot at a specific point
  • Before testing a robot’s drivetrain (Auto/Drvr), elevate it with standoffs
  • Before testing a lift system/Intake, Pull out axles slightly and test polarity
  • Tighten and inspect parts of robot after every match.
  • Have Spare axles of appropriate lengths
  • Never Sand metal over electronics without protection
  • Monitor anyone who cuts metal
  • Warn first timers that cutting Vex metal will create a lot of sparks
  • Carefully insert hex keys, Avoid stripping
  • Buy those hex keys with the slight bulge
  • Build with compactness in mind
  • Build with reliability in mind
  • One Hour of driver practice is better than 1 addition
  • Build Evolvable Designs; Designs that can still function with dysfunctional components
  • Physics is wise. With more power, you have to work over time. (Power=Work/Time)
  • When Calculating for torque, make sure you accommodate for friction
  • When Calcuating for torque, do not forget to accomodate for programming values
  • When calculating for torque, remember that value is when you stall, not what you lift
  • When using rubber bands, remember that you lose power as you raise
  • Try to be as hands off as possible if you are a captain. Yes, It’s your responsibility to have a competitive robot, But it is also your reponsibility to carry on your knowledge to younger members
  • Communicate skillfully with peers. Be clear and avoid conflict. When difficulty arises on a task, ask for assistance
    -As a leader, Discuss what tasks need to be done, What tasks you need to get done at a specific date/time, organize group based on skill, and relocate members if a specific group needs help
  • Do not throw away stripped hex keys. Sharpen them with a dremel
  • Color code your hex keys with tape
  • Throw away stripped setscrews, not the whole collar
  • If screws are stripped, Cut off the heads and reuse them as couplers
  • Build with sensors when you design, even if you do not use them
  • use spacers
  • Magnets are a useful tool for cleaning up
  • Add extra caution when opening up motors
  • If you have more people than tasks to do, try experimenting, practicing for judging, make spirit equipment, or plan more fundraising activities
  • Communicate with your mentor
  • Form Close bonds with fellow students, help them if they have problems with school/ etc.
  • Save piece of metal you cut
  • avoid as much friction as possible
  • Square Bracing is much easier to do than triangle bracing, but requires more weight
  • string works well as bracing
  • Make sure you have “mindless jobs”. Give those to people who are stressed to keep team efficiency high while reducing their stress. Ex, beautifying notebook, braiding string, organizing toolbox, decorating robot, etc.
  • Keep the team healthy
  • Try not to have excess thread sticking out of nuts
  • Sometimes “being the robot” will be useful when planning out strategies for games and foreseeing difficulties
  • try fastening bolts and nuts together in the toolbox. it avoids the “pass me a thick/thin nut thick/thin screw” thought/conversation
  • For larger teams, be cautious of fragmenting
  • Change code before you change electronics
  • Tape up electronics
  • Never use zipties to fasten important components
  • When Designing, ensure that each member understands the rules and allowed materials
  • Mounting electronics with nsp/foam can reduce shock on fasteners
  • standoffs are a good heat sink for electronics
  • Combine electronics into a single sheath when possible
  • When using hightraction wheels, apply zipties for even more traction
  • Try combining as many systems as possible. EX, placing an alignment device on an arm system instead of having an extra motor to perform tasks
  • Do not waste motors on tasks which will be performed once. Use a series of locks and elastic to execute task
  • if you know you are planning to practice driving/autonomous at a meeting, make sure the first task you do is charge a battery
  • Always record in your engineering notebook
  • A plethora of bad pictures is better than no pictures at All
  • Even if a component is not used on a robot, mention it in the notebook and have pictures
  • Add Spice to your notebook. Shade with colors such as blue/yellow to avoid white spots
  • X out any blank spaces in your notebook. leave those spaces for pictures
  • A Collage is impressive
  • Add extra emphasis in the notebook to problems you had at a meeting and solutions you had to them
  • Keep the toolbox as organized as possible
    -Some spirit equipment you can build are sirens, flags, costumes, shooting bots, posters, etc.
  • Air is Unlimited
  • Rubber bands Are Unlimited

I cant think of anymore off the top of my head…

asymmetrical is the new symmetrical :wink:
always tighten screws as if you are never going to take them out again
efficiency over looks (no ■■■■ bots plz…)
always have a good supply of elastics and zipties for those moments :slight_smile:

even if you dont have the intake/“weird twiddley thing” figured out yet, keep on building the robot and trust your experience that it will be figured out as time goes on
use the 181818 to the max
always try to change up a few things in between competitions, keeps things interesting

I added the Bold emphasis.
Chains vs Gears gets discussed a lot over the years,
here is one: Chain or Gear Drive? - Technical Discussion - VEX Forum
posts #25 is a reasonable list of tradeoffs.

Perhaps devinc stopped reading before “over long distances” qualifier, or has a different definition of “long”.

Anyone have any quantifiable data, or a design of experiments to demonstrate gear vs chain power losses for a specific distance and gear ratio?

devinc quoted Android4life’s post, and in that quote, it says “Use gears instead of chain it is more efficient.” In the actual post, however, it says “Use chain to power over long distances…” I believe that Android probably went back and edited his post after devinc pointed out the error.

One advantage of gears is that it is easier to gear 3 or more motors together in an in-line mechanism (like a 1:1, 6-motor drivetrain) than it is to chain them. Gears are also easier to build with, since you don’t have to worry about chain tension or sprocket alignment. Chain is better over long distances, however, and is more advisable when you are powering a mechanism like a Sack Attack intake, as chain is less likely to get jammed by sacks than gears are.

I find that chain is easier to build with overall. You don’t have to worry about lining up the hole widths to match gears and you don’t have to try to fit crazy geartrains for 6 wheel drives. Tensioners are easy. Some white spacers and some standoffs, done.

Don’t bury the cortex inside the robot where the field techs cannot see it.
Allow access to the cortex power switch.
Keep the VEXnet key free of structure to improve WiFi reception.
Keep the wiring clean and organized.
Use a backup battery.
Use the wire securing plastic clips on the cortex.

Here is an example.

[ATTACH]7134[/ATTACH]

Hi

We have been told (through the grapevine) that it is a poor build practice to run two (or more) 12 tooth metal pinion gears directly together because of high friction, compared to running a pinion against a plastic gear. Hence, we have avoided doing this. Is it possibly because?

  1. They are both small gears
  2. They are both metal gears
  3. A combination of above
  4. Some other reason

Or is this plainly not true?
Can anyone please help clarify this mystery?

Thanks, Paul