Thread created automatically to discuss a document in CD-Media.
Team 1124 2012 Robot Codeplnyyanks Robot code team 1124 used this year in competition. here . Enjoy!Final Uber Code.zip (4.14 MB)
The UberBots’ 2012 code is attached in the paper. A brief description :
We code in LabVIEW. Justin and I are both very experienced with LabVIEW (we’ve both used it in summer internships extensively) and spent a lot of time last summer thinking about a way to architect this year’s code. This is our first year trying something structured like this, so it hasn’t been perfected yet. Eventually, we came up with the following - we call it a “dual-parallel state machine”:
The loop of the code follows three basic steps: input values, calculations, and output. They’re pretty self explanatory - one step gets all the values to input to the calculations (this varies with robot mode) and controls which mode (state) the calculations use (we call this the state controller), the next step calculates the outputs based off of the values and states passed from the input section of code, and the final step sets the outputs (with appropriate safeties).
This basic process happens five times in our main loop - once for each robot subsystem (drive, shooter, etc). These are all run synchronously in parallel with each other. We played with the idea of having each subsystem in a separate loop, but we decided against it for some performance reasons. Our code currently runs around 50 iterations per second and at ~21% CPU (without vision enabled; with vision, it runs at a little over 90%), so I think we might be able to spare more parallel loops next year. But I’ll cross that bridge when I come to it.
Each subsystem is always in a “state”. A “state” is how we define which calculations to do to the input values. This is our way of executing autonomous routines in teleop - you just change the state of a certain subsystem either by a button being pressed or some other interrupt. We have one big typedef in our code, which holds all the possible states (for example, the most common ones are “driver control” and “auto”). Each subsystem implements states in a different way, but we know that every state is implemented - sort of like an interface for you APCS/Java people.
All of the states in our code have the ability to interact with each other. Each subsystem has its state stored in a functional global variable, along with some other information such as a first call boolean. Any subsystem can access any other subsystem’s current state information. This allows for subsystems to wait for each other before executing a task (this is especially useful in coding autonomous).
Speaking of autonomous, our structure made it very easy this year. Autonomous is simply an alternative state machine controller (input value provider) which is run instead of the teleop one. Our autonomous this year consists of (for each substate) an array of the states to execute in order, their input values, and their exit conditions. These values are then passed to the calculation and output phases, and that’s our autonomous.
I’m very happy with how this code turned out - even though the rankings might not have reflected it, I actually (and unbiased) think our robot was one of the better turret shooters at the CT Regional. I think it’s pretty nice… And I’m always happy to take questions, too.