Why Build Your Own Drive Library

There's nothing wrong with a good template. EZ-Template and PROS get strong teams to a working autonomous fast, and we teach both on this site. But somewhere between rookie season and a serious competitive program, a question is worth asking: do we understand the code that drives our robot, or do we just trust it?

Spartan Design's answer was to build a small drivetrain library of our own — a thin wrapper over PROS that exposes exactly the methods our students use, named the way our students think. We call it SpartanDrive. This page isn't the library itself; it's the reasoning behind building one, so any team can decide whether the same move is right for them.

What this page is — and isn't

This is the philosophy, openly shared. The actual SpartanDrive source, API, and code generator are part of our competitive toolkit and stay with the team. The idea is the gift; the implementation is the work. You should write your own.

Why write your own wrapper

You can explain every line

When you wrote the method, you can tell a judge exactly what it does and why it's named that way. A black-box template makes "explain your code" a much harder interview.

It fits your vocabulary

Your library uses the words your team uses at practice. The gap between "what we say" and "what we type" shrinks, and rookies onboard faster.

It's a forcing function for learning

You can't wrap a PID controller you don't understand. Building the library teaches the underlying control theory better than any tutorial.

It's genuinely yours

EN4 rewards original work you understand. A wrapper you designed is the cleanest possible answer to "is this your code?"

The honest trade-off: building your own library costs time you could spend driving or building. It's the right move for a program investing in long-term programming depth — not for a rookie team three weeks from their first event. If you're new, start with a template (we teach EZ-Template and VEXcode), learn what it does, and graduate to your own wrapper when you've outgrown the black box.

The design principles we used

If you do build one, these are the principles that kept ours clean and teachable. They're transferable to any team's library, regardless of language or framework.

1. Thin, not clever

A wrapper should hide boilerplate, not behavior. If a student can't predict what a method does from its name, the method is too clever. Favor five obvious methods over one configurable one.

2. Name for the driver, not the engineer

Methods should read like instructions a driver would give: drive forward, turn to heading, stop. The vocabulary at the keyboard should match the vocabulary at the field.

3. One concept per method

A method that both moves and turns is two ideas wearing one name. Split it. Composition is a student's job and a great learning exercise; hiding composition inside a method robs them of it.

4. Document the "how it works" separately from the "how to use"

Keep a quick-reference for daily use and a deeper explanation for understanding. A student looking up a method signature shouldn't have to read control theory; a student learning the theory shouldn't have to dig through API docs.

How to start building your own

Master a template first. You can't improve on something you don't understand. Run EZ-Template or VEXcode until you know exactly what each call does.
List the ~10 things you actually call. Most teams use a tiny fraction of a template's surface. Those calls are your library's whole API.
Wrap one method at a time. Start with the simplest drive call. Get it working, document it, then move to the next. Don't design the whole library up front.
Teach it to a rookie. If a newer student can use your method from its name and one example, it's well designed. If you have to explain it, simplify.
Keep a reference doc as you go. Every method gets a one-line "what it does," its parameters, and an example. Future-you and every new programmer will thank you.

EN4 reminder

If you build a library, the library is your work and you can explain it — that's exactly what judges and the notebook reward. But the code you put in your competition robot still has to be code you wrote and understand. Learn the patterns anywhere; write your robot's code yourself.

Want the beginner paths first? Start with the VEXcode V5 Guide or the EZ-Template setup. When you're ready to think about architecture, the code organization guide covers structuring a project cleanly.