View Full Version : Behind The Design 2012
Tom Line
03-12-2012, 01:13
In 2012, Team 1718 asked for and received authorization to attempt to produce a new 'Behind The Design' book. After searching for submissions and compiling the responses, the team realized that we didn't have enough material to put together a book that could do the previous Behind The Design books justice. So the team decided to take another route.
Instead of a novel, the team decided to release the sections that were completed as a serial book: a new section would be released each week in December, leading up to the 2013 kickoff. Much of the information in this first release has been discussed elsewhere, so we considered this our "Beta Test". Another new section on a different robot will be released next week.
Thanks to teams 67, 341, 971, 1218, Richard Wallace, and AndyMark for their help in putting this together.
Please give us feedback. We've never tried something like this, and we're very interested in how the community thinks we can improve it. Enjoy!
Behind the Design: Installment 1 (http://www.fightingpi.org/Resources/Business/Behind%20the%20Design.shtml)
Akash Rastogi
03-12-2012, 02:17
This is fantastic! Thank you guys for putting this together.
Excited for the next one!
This looks great! Looking forward to the next chapter.
This turned out really well. I can't wait to see the next chapter of another great team.
Adam Freeman
03-12-2012, 08:44
Looks great! Thanks for including us.
I was really hoping for another book, but I can understand the difficulty in gathering and coordinating all of the information required to create a book as good as the first two.
Feedback: There are a couple of pictures where the captions are carried over from previous pictures (CAD of the frame - caption references utility arm sketches, Utility Arm motor calcs - caption references the shifter).
Looking forward to next week.
This is fantastic. Thanks a ton for putting this together, and thanks to the teams who shared design info for the project.
Our team marveled at the conceptual simplicity and versatility of 67's arm as soon as we saw the first videos of that robot, and we plagiarized some elements of that design to upgrade our robot before our second competition.
Jared Russell
03-12-2012, 13:13
Love it!
As an aside, there is no reason why every single team in FRC can't document their season as well as this book/67 did. It is easy to do, yet it becomes a powerful tool for showing to judges, presenting to sponsors and parents, and studying to iteratively improve your robot building process.
This. Is. Fantastic.
I wish there was one of these for every robot. Scratch that... I wish that EVERY TEAM would take the time to do this for their robot.
Kudos to 1718 for facilitating this, but I wish they didn't need to.
-John
I wish that EVERY TEAM would take the time to do this for their robot.
+1
It would be awesome if teams would pledge to create something like this during the build period. It really doesn't take much to create a goldmine of information.
+1
It would be awesome if teams would pledge to create something like this during the build period. It really doesn't take much to create a goldmine of information.
I look forward to seeing 1687's next year.
Akash Rastogi
03-12-2012, 14:47
This. Is. Fantastic.
I wish there was one of these for every robot. Scratch that... I wish that EVERY TEAM would take the time to do this for their robot.
Kudos to 1718 for facilitating this, but I wish they didn't need to.
-John
Maybe it's time you put out another JVN Challenge? I remember some of your previous ones, but I'm not sure how many teams followed through.
The graph on the top left of page 8... I assume this is an open-loop test at 12 volts. The text says the team chose the 8000 rpm free speed, which would be the 1:2 gear ratio according to the graph. The text also says 4000 rpm was used for shooting from the key. Does anyone know what control algorithm 67 used for shooter speed?
I look forward to seeing 1687's next year.
You definitely will -- If I can find enough supporting images and WIP diagrams, I may put one together from 2012 as well to help support this project.
dtengineering
03-12-2012, 15:39
Really nicely done. Congratulations and looking forward to seeing more. Perhaps, over time, it will be possible to compile enough articles like this to come out with a new book every two or three years.
I could see a format that would have team/game specific articles like this interspersed with articles on community involvement, chairman's presentations, imagery... almost like a text book on best practices for running an FRC team.
Jason
Maybe it's time you put out another JVN Challenge? I remember some of your previous ones, but I'm not sure how many teams followed through.
Lots of teams were quick to say they would "of course do this!" Almost none actually did. :) Looks like 67 did.
-John
Adam Freeman
03-12-2012, 15:46
The graph on the top left of page 8... I assume this is an open-loop test at 12 volts. The text says the team chose the 8000 rpm free speed, which would be the 1:2 gear ratio according to the graph. The text also says 4000 rpm was used for shooting from the key. Does anyone know what control algorithm 67 used for shooter speed?
Ether,
I believe the plot was a theoretical calculation of motor RPM v. time that one of our engineers created to help us determine what gear ratio we wanted to use for our shooter gearbox. The data showed that the 2.5:1 ratio was the fastest to reach 4000RPM, which is what targeted for our "normal" shooting speed.
The 8000RPM free speed is a typo on my part. It should be more like 6400RPM.
I pointed our controls guys to this thread. He will answer the control algorithm question.
Adam Freeman
03-12-2012, 15:55
Lots of teams were quick to say they would "of course do this!" Almost none actually did. :) Looks like 67 did.
-John
Following John's lead, I have tried for a couple of years to document our design "on the fly" during the build season. Every year starts out great, until we get actual parts that need to be put together. Then I spend most of my time with the parts and not with my computer....and nothing further gets documented.
We have had students take notes, mentors take notes, build journals, online design logs, etc.... it always ends up incomplete.
Most years we have created a Tech notes for our students to hand out when talking to judges for awards. These tech notes are usually pulled together at the end of teh build season and summarize the design and main aspects of the robot.
This year I decided to since our robot was so unique, it would be worth it to post it on CD. The response has been incredible.
I plan to continue on with it. Maybe one year the documentation will keep up with the build and I won't have to spend hours/days creating a new document.
Jay Meldrum
03-12-2012, 15:59
The graph on the top left of page 8... I assume this is an open-loop test at 12 volts. The text says the team chose the 8000 rpm free speed, which would be the 1:2 gear ratio according to the graph. The text also says 4000 rpm was used for shooting from the key. Does anyone know what control algorithm 67 used for shooter speed?
Ether: We used a PID. The input was the rate of a light sensor (3 division flywheel was on the shaft of shooter). We had 3 preset shoot speeds based on different locations on the field: top of key, bottom of key, hail mary. We also manually modified those speeds during the match depending on ball "squishiness".
Tom Line
03-12-2012, 16:04
"squishiness".
Squishiness..... a word we will forever hate after 2012....
I pointed our controls guys to this thread. He will answer the control algorithm question.
Thanks Adam.
We used a PID. The input was the rate of a light sensor (3 division flywheel was on the shaft of shooter). We had 3 preset shoot speeds based on different locations on the field: top of key, bottom of key, hail mary. We also manually modified those speeds during the match depending on ball "squishiness".
Thanks for the quick response Jay.
Couple of follow-up questions if I may:
1) Perhaps you've posted this somewhere already, and if so my apologies: could you share a bit more detail about your PID? e.g. did you use feedforward, or integrate the PID output, or tune I like P. How closely were you able to hold speed. stuff like that.
1) Adam mentioned you selected the 2.5:1 gear speed reduction because it was the fastest to reach 4000 rpm. Did you try using a bang-bang controller which is noted for reaching the setpoint very quickly.
kylie.student.9
03-12-2012, 18:06
Great idea! cant wait to see it!
Jay Meldrum
03-12-2012, 21:13
Couple of follow-up questions if I may:
1) Perhaps you've posted this somewhere already, and if so my apologies: could you share a bit more detail about your PID? e.g. did you use feedforward, or integrate the PID output, or tune I like P. How closely were you able to hold speed. stuff like that.
We integrated the PID output. Within the PID, we only used the proportional and derivative terms.
We were able to hold our speed within +/- 50 to 200 rpm; depending on the set speed. We tuned the PID to be the most steady at the bottom of the key shot.
I would say our biggest issue while tuning the PID was handling the split second/recovery when the ball entered and went through the shooter. We noticed huge shooter speed recovery variations with a few balls (We called them the "pumpkin balls" :D); thus missing the shot. At one point we tried adding additional logic to "power thru" any quick decreases in shooter speed. That didn't end up working well so we just continued to tune the PID to match the majority of balls.
Here is the function that we wrote in place of the PIDWrite provided by WPIlib. Thus still allowing us to use the WPIlib PIDController.
void PIDWrite(float output) {
//Used in place of WPIlib PIDWrite for cannon control
//m_cannonUpToSpeed is used to allow/deny the feeder to feed balls
if((m_cannonSetPoint - 5) <= m_CannonEncode->GetRate() && (m_cannonSetPoint + 5) >= m_CannonEncode->GetRate())
{
m_cannonUpToSpeed = 1;
}
//500 is our "hail mary" setpoint
else if(m_cannonSetPoint == 500)
{
m_cannonUpToSpeed = 1;
}
else
{
m_cannonUpToSpeed = 0;
}
m_CannonDemandedVoltage += output;
if(m_CannonDemandedVoltage > 1) m_CannonDemandedVoltage = 1;
if(m_CannonDemandedVoltage < 0) m_CannonDemandedVoltage = 0;
m_Cannon1->Set(-m_CannonDemandedVoltage);
m_Cannon2->Set(-m_CannonDemandedVoltage);
}
Tom Line
03-12-2012, 21:31
Ether,
I believe the plot was a theoretical calculation of motor RPM v. time that one of our engineers created to help us determine what gear ratio we wanted to use for our shooter gearbox. The data showed that the 2.5:1 ratio was the fastest to reach 4000RPM, which is what targeted for our "normal" shooting speed.
The 8000RPM free speed is a typo on my part. It should be more like 6400RPM.
I pointed our controls guys to this thread. He will answer the control algorithm question.
Remarkable. That is the exact same compression, gearing, and speed that we had. After our second competition we switched from 775's in a custom Cim-Sim over to 550's in a banebot gearbox due to poor alignment (our fault) in the gears of the Cim-Sim. Our gear ratio, compression and shooting RPM still stayed the same though. I wonder how many other teams came to the exact same solution.
DampRobot
03-12-2012, 21:34
Thank you. This is such an awesome resource. That arm probably made team 67's robot my favorite in all of FRC.
How were teams picked? Was there a nomination process? Or was it more based on who had already released build season documentation?
We integrated the PID output. Within the PID, we only used the proportional and derivative terms.
We were able to hold our speed within +/- 50 to 200 rpm; depending on the set speed. We tuned the PID to be the most steady at the bottom of the key shot.
Thanks for the detail.
I would say our biggest issue while tuning the PID was handling the split second/recovery when the ball entered and went through the shooter. ... At one point we tried adding additional logic to "power thru" any quick decreases in shooter speed. That didn't end up working well so we just continued to tune the PID to match the majority of balls.
Spin-up recovery is where bang-bang control excels. If you've never played around with bang-bang control for a shooter wheel, that might make an interesting pre-build project. There's some detail here:
http://www.chiefdelphi.com/media/papers/2663
... make sure to read the thread too. There's a lot of good discussion in there, as well as links to other threads.
Jay Meldrum
03-12-2012, 22:11
Spin-up recovery is where bang-bang control excels. If you've never played around with bang-bang control for a shooter wheel, that might make an interesting pre-build project. There's some detail here:
http://www.chiefdelphi.com/media/papers/2663
... make sure to read the thread too. There's a lot of good discussion in there, as well as links to other threads.
Bang-bang... never knew what to call that method. We did try that method at first though it didn't quite work as well for us as the PID. I believe it was primarily because our shooter wheel did not have much inertia (just used the plastic kit wheels that we turned off the tread of).
Definitively something to revisit though. Thanks!
Tom Line
04-12-2012, 00:30
Thank you. This is such an awesome resource. That arm probably made team 67's robot my favorite in all of FRC.
How were teams picked? Was there a nomination process? Or was it more based on who had already released build season documentation?
We originally contacted the top 25 teams from the FRC top 25 website. Unfortunately, many had to drop out of the process for multiple reasons over the last several months.
67 was the only team who had previously put out an informational document - that's why we started with theirs, because it was primarily a matter of reformatting it into the BTD format that the books used in the past. We tried to stay true to those books. I always thought they were a wonderful resource and artfully done, but then I'm an engineer so what do I know :D
It was a bigger job that we originally thought. Writing, formatting and proof reading (mostly formatting) each submission takes anywhere from 8-20 hours. That doesn't include getting back to teams for additional content and photographs. So in a way, we're lucky we didn't get a ton of submissions.
Next year, I hope to start earlier, and we're going to work with FIRST and potentially ask for submissions from any team who has won a robot award so we end up with more teams. That's quite a ways off, and I"ll have to get buy-in from our new students before we even decide to repeat this next year.
I'll leave the business awards to some other busybody!
Brandon Holley
04-12-2012, 03:38
This. Is. Fantastic.
I wish there was one of these for every robot. Scratch that... I wish that EVERY TEAM would take the time to do this for their robot.
Kudos to 1718 for facilitating this, but I wish they didn't need to.
-John
It seems ripe for FIRST to offer an award that surrounds a team's design process, or documenting of said process. Maybe it would fit into an existing award, but having teams submit a formal report documenting their season (limited to a couple pages, like 67s) would go a long way in encouraging teams to keep a record of their build.
It'd also likely produce some AWESOME reading for all of us.
For most teams, build season kind of starts and finishes and thats it. Almost all of us wonder where the time has gone and where we could have made improvements. We should all have a better record of how our build seasons progressed!
-Brando
It seems ripe for FIRST to offer an award that surrounds a team's design process, or documenting of said process. Maybe it would fit into an existing award, but having teams submit a formal report documenting their season (limited to a couple pages, like 67s) would go a long way in encouraging teams to keep a record of their build.
Agreed.
The VEX Robotics Competition has several awards which require an engineering notebook, and description of the team's engineering process to be eligible. The "journey" is definitely part of the award.
I would love to see stronger emphasis on this from FIRST.
-John
Agreed.
The VEX Robotics Competition has several awards which require an engineering notebook, and description of the team's engineering process to be eligible. The "journey" is definitely part of the award.
I would love to see stronger emphasis on this from FIRST.
-John
FTC is on board with that. Teams need an engineer's notebook with the journey documented for at least three of the awards (Think Award, Rockwell Collins Innovate Award, PTC Design Award). There's no reason FRC couldn't move in that direction.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.