Go to Post I don't need sleep, just more Mountain Dew. Oh, and a muffin. - hallk [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 14-11-2011, 15:10
ebakan ebakan is offline
Registered User
FRC #0254
 
Join Date: Jul 2011
Location: Mountain Vies
Posts: 1
ebakan has a spectacular aura aboutebakan has a spectacular aura aboutebakan has a spectacular aura about
Team 254 2011 FRC Code

Hey all,

I'm Eric Bakan and I'm Team 254's Head of Programming/Controls aka Chief Executive Brogrammer. With the conclusion of our last offseason event, the MadTown Throwdown, Team 254 is releasing our 2011 FRC codebase.

The code can be viewed and downloaded from our team GitHub at https://github.com/Team254/FRC-2011

We had used SVN for the duration of the season but unfortunately our server died and we lost all our SVN backlogs. Based on our programming team's previous experience we've decided to move to Git for our version control, primarily because it allows us to make offline commits when we have intermittent internet access on our developer laptop. At the moment this is merely the snapshot of our code as of the end of Championships.

We hope that releasing this code will prove useful to other teams. The included README should provide useful details about the architecture of the system and the individual files should have further notes.

Our only request is that you leave a reply if you found any of this code helpful. Everything is released under a 2-Clause BSD License so feel free to use any part of it.

Last edited by ebakan : 14-11-2011 at 15:56.
  #2   Spotlight this post!  
Unread 14-11-2011, 15:34
Jared Russell's Avatar
Jared Russell Jared Russell is offline
Taking a year (mostly) off
FRC #0254 (The Cheesy Poofs), FRC #0341 (Miss Daisy)
Team Role: Engineer
 
Join Date: Nov 2002
Rookie Year: 2001
Location: San Francisco, CA
Posts: 3,073
Jared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond repute
Re: Team 254 2011 FRC Code

Thanks for posting! The attention to detail is astounding. 4 different sets of PID gains for the elevator, depending on direction and number of stages engaged?

EDIT: And that's before I even saw the state space controller for the drive

Last edited by Jared Russell : 14-11-2011 at 15:42.
  #3   Spotlight this post!  
Unread 14-11-2011, 16:59
Unsung FIRST Hero
Greg Marra Greg Marra is offline
[automate(a) for a in tasks_to_do]
FRC #5507 (Robotic Eagles)
Team Role: Mentor
 
Join Date: Oct 2004
Rookie Year: 2005
Location: San Francisco, CA
Posts: 2,030
Greg Marra has a reputation beyond reputeGreg Marra has a reputation beyond reputeGreg Marra has a reputation beyond reputeGreg Marra has a reputation beyond reputeGreg Marra has a reputation beyond reputeGreg Marra has a reputation beyond reputeGreg Marra has a reputation beyond reputeGreg Marra has a reputation beyond reputeGreg Marra has a reputation beyond reputeGreg Marra has a reputation beyond reputeGreg Marra has a reputation beyond repute
Re: Team 254 2011 FRC Code

Incredibly exciting to see such sophisticated robot code being open sourced. I would love to see other teams follow suite
  #4   Spotlight this post!  
Unread 14-11-2011, 17:02
AustinSchuh AustinSchuh is offline
Registered User
FRC #0971 (Spartan Robotics) #254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Feb 2005
Rookie Year: 1999
Location: Los Altos, CA
Posts: 800
AustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond repute
Re: Team 254 2011 FRC Code

Quote:
Originally Posted by Jared341 View Post
Thanks for posting! The attention to detail is astounding. 4 different sets of PID gains for the elevator, depending on direction and number of stages engaged?
Thanks! We had a lot of fun this year. Did you also notice the threading and how we implemented Auto mode? We use trapezoidal motion profiles for all the drive commands to generate very smooth motions. We also improved the drive code so that it is even smoother and more responsive than the 2010 code. We learned a lot and will be applying what we learned to next year's code.

Quote:
Originally Posted by Jared341 View Post
EDIT: And that's before I even saw the state space controller for the drive
Drove the robot forwards for 3 seconds, spun for 3 seconds, modeled the robot from first principles, plugged in the ideal constants, fit the constants to the actual response, designed a controller in Matlab, deployed it to the robot, and it worked first try. Sooo tempting to try it for the other systems next year. I decided to model the drivetrain as MIMO. Previous attempts to model it as SISO were resulting in the bot twitching left and right a bit once it stopped due to the false assumption that accelerating one side did not result in any force on the other side.

If you or anyone else has any questions, we'd be glad to try and answer them.
  #5   Spotlight this post!  
Unread 14-11-2011, 18:20
JesseK's Avatar
JesseK JesseK is offline
Expert Flybot Crasher
FRC #1885 (ILITE)
Team Role: Mentor
 
Join Date: Mar 2007
Rookie Year: 2005
Location: Reston, VA
Posts: 3,625
JesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond repute
Re: Team 254 2011 FRC Code

Quote:
Originally Posted by AustinSchuh View Post
Thanks! We had a lot of fun this year. Did you also notice the threading and how we implemented Auto mode? We use trapezoidal motion profiles for all the drive commands to generate very smooth motions.
Thanks for posting the code Austin. I'd never heard of trapezoidal motion profiles, but the first Google link seems to give a basic understanding. I haven't been able to view the code yet, but have what assumptions about acceleration/deceleration of the manipulator parts (lift & wrist) were you able to make when modeling their movement?
__________________

Drive Coach, 1885 (2007-present)
CAD Library Updated 5/1/16 - 2016 Curie/Carver Industrial Design Winner
GitHub
  #6   Spotlight this post!  
Unread 14-11-2011, 18:48
AustinSchuh AustinSchuh is offline
Registered User
FRC #0971 (Spartan Robotics) #254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Feb 2005
Rookie Year: 1999
Location: Los Altos, CA
Posts: 800
AustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond repute
Re: Team 254 2011 FRC Code

We used a simple PD loop on the wrist and elevator with some gain scheduling, since it worked well enough after hand tuning. The elevator changes mass when it starts to lift the second stage, so there is a second set of constants for that case. For both the arm and elevator, they would undershoot when approaching the goal from below, and overshoot when approaching the goal from above. To solve this, we have 2 sets of constants, one per direction. This solved our overshoot problems. I also avoid integral whenever possible. We just accepted the small steady state error on the elevator and wrist, and moved on, rather than spending the extra time to tune the integral constant across 6 sets of constants. We pass a goal into the two sub systems when we hit the setpoint buttons. The manual joysticks for those two systems also tweak the goals, rather than doing anything with power.

One thing we realized when driving the robot was that it was very useful for the arm to be angled ~50 degrees above horizontal when lining up to place a tube. To facilitate this, whenever a setpoint button is hit, the elevator raises up, and then when it is all the way up, the arm tilts forwards. When the driver hits another button, the robot then goes through an "auto-score" motion which opens the claw, spits out, lowers the elevator, then raises the arm back up, and backs the robot up. This offloads a lot of stuff from the drivers.

Most of the fancy controls is in the drivetrain, which we spent easily over a month working on to tune the robot so that it was accurate and precise enough to score two tubes.
  #7   Spotlight this post!  
Unread 14-11-2011, 20:43
rachelholladay's Avatar
rachelholladay rachelholladay is offline
Registered User
FRC #1912 (Team Combustion)
 
Join Date: Dec 2010
Rookie Year: 2006
Location: Slidell, Louisiana, USA
Posts: 540
rachelholladay has a reputation beyond reputerachelholladay has a reputation beyond reputerachelholladay has a reputation beyond reputerachelholladay has a reputation beyond reputerachelholladay has a reputation beyond reputerachelholladay has a reputation beyond reputerachelholladay has a reputation beyond reputerachelholladay has a reputation beyond reputerachelholladay has a reputation beyond reputerachelholladay has a reputation beyond reputerachelholladay has a reputation beyond repute
Re: Team 254 2011 FRC Code

Ah, if only I knew enough C to appreciate it. (LabVIEW team here) I'm sure it would make me wanna tear up a bit..
__________________
Carnegie Mellon School of Computer Science Class of 2017
2012 Dean's List Winner, 2011 NWCIT Award of Aspirations in Computing National Winner

2014 - : FIRST Team 3504 Girls of Steel (Mentor)
2014 Engineering Inspiration

2006 - 2013: FIRST Team 1912 Combustion (Webmaster / Controls Capt / Beta Test Lead / Drive Capt / JrFLL Coach)
2013 Woodie Flowers Finalist for Wendy Holladay. 2010 - 2013 Regional Chairman's Award at the Bayou Regional. 2011 - 2012 Best Website at the Bayou Regional. 2010 - 2013 Beta Test Team for Hardware and LabVIEW. 2012 JrFLL State Expo Coordinator.
  #8   Spotlight this post!  
Unread 14-11-2011, 21:36
Chris is me's Avatar
Chris is me Chris is me is online now
no bag, vex only, final destination
AKA: Pinecone
FRC #0228 (GUS Robotics); FRC #2170 (Titanium Tomahawks)
Team Role: Mentor
 
Join Date: Dec 2008
Rookie Year: 2006
Location: Glastonbury, CT
Posts: 7,609
Chris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond reputeChris is me has a reputation beyond repute
Send a message via AIM to Chris is me
Re: Team 254 2011 FRC Code

Quote:
Originally Posted by AustinSchuh View Post
One thing we realized when driving the robot was that it was very useful for the arm to be angled ~50 degrees above horizontal when lining up to place a tube. To facilitate this, whenever a setpoint button is hit, the elevator raises up, and then when it is all the way up, the arm tilts forwards. When the driver hits another button, the robot then goes through an "auto-score" motion which opens the claw, spits out, lowers the elevator, then raises the arm back up, and backs the robot up. This offloads a lot of stuff from the drivers.
With that kind of automation, you can make any robot score quickly and effectively. Put it on a 254 robot and you see why they have a Championship banner.
__________________
Mentor / Drive Coach: 228 (2016-?)
...2016 Waterbury SFs (with 3314, 3719), RIDE #2 Seed / Winners (with 1058, 6153), Carver QFs (with 503, 359, 4607)
Mentor / Consultant Person: 2170 (2017-?)
---
College Mentor: 2791 (2010-2015)
...2015 TVR Motorola Quality, FLR GM Industrial Design
...2014 FLR Motorola Quality / SFs (with 341, 4930)
...2013 BAE Motorola Quality, WPI Regional #1 Seed / Delphi Excellence in Engineering / Finalists (with 20, 3182)
...2012 BAE Imagery / Finalists (with 1519, 885), CT Xerox Creativity / SFs (with 2168, 118)
Student: 1714 (2009) - 2009 Minnesota 10,000 Lakes Regional Winners (with 2826, 2470)
2791 Build Season Photo Gallery - Look here for mechanism photos My Robotics Blog (Updated April 11 2014)
  #9   Spotlight this post!  
Unread 14-11-2011, 22:16
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: Team 254 2011 FRC Code

Quote:
Originally Posted by AustinSchuh View Post
One thing we realized when driving the robot was that it was very useful for the arm to be angled ~50 degrees above horizontal when lining up to place a tube. To facilitate this, whenever a setpoint button is hit, the elevator raises up, and then when it is all the way up, the arm tilts forwards. When the driver hits another button, the robot then goes through an "auto-score" motion which opens the claw, spits out, lowers the elevator, then raises the arm back up, and backs the robot up. This offloads a lot of stuff from the drivers.
Interresting...

Is there any reason that you didn't run the elevator and arm as a single integrated system, to simplify things like this? We ran our elevator/arm as a single state machine, and part of the state transition handled actions like this (with the data input being a requested state, and the data output being a pair of setpoints), and fed the positions output into a pair of setpoint controllers and anti-death logic.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
  #10   Spotlight this post!  
Unread 14-11-2011, 22:45
AustinSchuh AustinSchuh is offline
Registered User
FRC #0971 (Spartan Robotics) #254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Feb 2005
Rookie Year: 1999
Location: Los Altos, CA
Posts: 800
AustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond repute
Re: Team 254 2011 FRC Code

Quote:
Originally Posted by apalrd View Post
Is there any reason that you didn't run the elevator and arm as a single integrated system, to simplify things like this?
The system evolved from the two separate systems with minimal automation to being connected together, and we never stopped to think about re-architecting. We also wanted to be able to move the elevator or wrist at any point in time manually and have it cancel the action.

Looking back, I really like how easy it was to write auto modes with the multi-threading that we did, and would like to make it that easy to write auto-score functions as well.
  #11   Spotlight this post!  
Unread 15-11-2011, 08:04
Jared Russell's Avatar
Jared Russell Jared Russell is offline
Taking a year (mostly) off
FRC #0254 (The Cheesy Poofs), FRC #0341 (Miss Daisy)
Team Role: Engineer
 
Join Date: Nov 2002
Rookie Year: 2001
Location: San Francisco, CA
Posts: 3,073
Jared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond repute
Re: Team 254 2011 FRC Code

Yes, multithreading can lead to prettier/less verbose auto modes, in my experience. We have been prototyping a trapezoidal motion profile as well, and I really like how smoothly it achieves distance setpoints with sub-inch accuracy. Are you using a trapezoidal profile for turning in place, as well? (I didn't notice it, but haven't gone through line by line - yet)

EDIT: Yes, I see that you did

Last edited by Jared Russell : 15-11-2011 at 09:03.
  #12   Spotlight this post!  
Unread 15-11-2011, 13:35
JesseK's Avatar
JesseK JesseK is offline
Expert Flybot Crasher
FRC #1885 (ILITE)
Team Role: Mentor
 
Join Date: Mar 2007
Rookie Year: 2005
Location: Reston, VA
Posts: 3,625
JesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond reputeJesseK has a reputation beyond repute
Re: Team 254 2011 FRC Code

I perused the code over lunch and noticed something that confused me. In your ports file you've assigned both the "B" port of an encoder and a limit switch to digital I/O 10. In order to facilitate this, was there a specific order the wires had to go into the DIN for I/O 10?

We rely heavily on limit switches to act as redundant safeties during programming as well as sensor failures, so being able to pair limit switches with encoders in this manner could save us from having to make I/O port tradeoffs.
__________________

Drive Coach, 1885 (2007-present)
CAD Library Updated 5/1/16 - 2016 Curie/Carver Industrial Design Winner
GitHub
  #13   Spotlight this post!  
Unread 15-11-2011, 14:31
Alan Anderson's Avatar
Alan Anderson Alan Anderson is offline
Software Architect
FRC #0045 (TechnoKats)
Team Role: Mentor
 
Join Date: Feb 2004
Rookie Year: 2004
Location: Kokomo, Indiana
Posts: 9,112
Alan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond reputeAlan Anderson has a reputation beyond repute
Re: Team 254 2011 FRC Code

Quote:
Originally Posted by JesseK View Post
I perused the code over lunch and noticed something that confused me. In your ports file you've assigned both the "B" port of an encoder and a limit switch to digital I/O 10.
The port definitions for the top and bottom roller encoders are probably obsolete. It doesn't look like either of those encoders is actually used in the code, so there's no real conflict.
  #14   Spotlight this post!  
Unread 15-11-2011, 14:33
AustinSchuh AustinSchuh is offline
Registered User
FRC #0971 (Spartan Robotics) #254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Feb 2005
Rookie Year: 1999
Location: Los Altos, CA
Posts: 800
AustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond repute
Re: Team 254 2011 FRC Code

Quote:
Originally Posted by Alan Anderson View Post
The port definitions for the top and bottom roller encoders are probably obsolete.
Correct. There are no encoders on the rollers. That sounds like a very old piece of code that didn't get removed as the code evolved...
  #15   Spotlight this post!  
Unread 17-11-2011, 11:00
Jared Russell's Avatar
Jared Russell Jared Russell is offline
Taking a year (mostly) off
FRC #0254 (The Cheesy Poofs), FRC #0341 (Miss Daisy)
Team Role: Engineer
 
Join Date: Nov 2002
Rookie Year: 2001
Location: San Francisco, CA
Posts: 3,073
Jared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond reputeJared Russell has a reputation beyond repute
Re: Team 254 2011 FRC Code

Austin,

Could you or one of your programmers explain the rationale behind the design of your victor_linearize function? You average 5th and 7th order polynomials together, but it isn't obvious why you do this.

Thanks

This question was brought on by this thread: http://www.chiefdelphi.com/forums/sh...02#post1085502
Closed Thread


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 09:19.

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


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