OCCRA
Go to Post Teams should make it a practice to protect their Victors (all the electronics, really) from the mechanical folks, with their saws and files and stone axes... - DonRotolo [more]
Home
Go Back   Chief Delphi > ChiefDelphi.com Website > Extra Discussion
CD-Events   CD-Media   CD-Spy   FRC-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Reply
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 05-01-2012, 04:43 PM
plnyyanks's Avatar
plnyyanks plnyyanks is offline
I do stuff.
AKA: Phil Lopreiato
FRC #1124 (The ‹berBots), FRC #1418 (Vae Victus)
Team Role: College Student
 
Join Date: Apr 2010
Rookie Year: 2010
Location: Washington, DC
Posts: 719
plnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond repute
paper: Team 1124 2012 Robot Code

Thread created automatically to discuss a document in CD-Media.

Team 1124 2012 Robot Code by plnyyanks
Reply With Quote
  #2   Spotlight this post!  
Unread 05-01-2012, 04:45 PM
plnyyanks's Avatar
plnyyanks plnyyanks is offline
I do stuff.
AKA: Phil Lopreiato
FRC #1124 (The ‹berBots), FRC #1418 (Vae Victus)
Team Role: College Student
 
Join Date: Apr 2010
Rookie Year: 2010
Location: Washington, DC
Posts: 719
plnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond reputeplnyyanks has a reputation beyond repute
Re: paper: Team 1124 2012 Robot Code

The UberBots' 2012 code is attached in the paper. A brief description:


Quote:
Originally Posted by plnyyanks View Post
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.
__________________
Phil Lopreiato
"It's a hardware problem"
FRC Notebook The Blue Alliance for Android
Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 11:23 PM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi