Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)
-   -   Behind The Design 2012 (http://www.chiefdelphi.com/forums/showthread.php?t=109810)

Adam Freeman 03-12-2012 15:46

Re: Behind The Design 2012
 
Quote:

Originally Posted by Ether (Post 1198328)

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

Re: Behind The Design 2012
 
Quote:

Originally Posted by JVN (Post 1198340)
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

Re: Behind The Design 2012
 
Quote:

Originally Posted by Ether (Post 1198328)

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

Re: Behind The Design 2012
 
Quote:

Originally Posted by jsmeldru (Post 1198345)
"squishiness".

Squishiness..... a word we will forever hate after 2012....

Ether 03-12-2012 16:06

Re: Behind The Design 2012
 
Quote:

Originally Posted by Adam Freeman (Post 1198342)
I pointed our controls guys to this thread. He will answer the control algorithm question.

Thanks Adam.



Ether 03-12-2012 16:17

Re: Behind The Design 2012
 
Quote:

Originally Posted by jsmeldru (Post 1198345)
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

Re: Behind The Design 2012
 
Great idea! cant wait to see it!

Jay Meldrum 03-12-2012 21:13

Re: Behind The Design 2012
 
Quote:

Originally Posted by Ether (Post 1198352)
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.

Code:

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

Re: Behind The Design 2012
 
Quote:

Originally Posted by Adam Freeman (Post 1198342)
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

Re: Behind The Design 2012
 
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?

Ether 03-12-2012 21:51

Re: Behind The Design 2012
 
Quote:

Originally Posted by jsmeldru (Post 1198476)
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.

Quote:

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

Re: Behind The Design 2012
 
Quote:

Originally Posted by Ether (Post 1198492)
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

Re: Behind The Design 2012
 
Quote:

Originally Posted by DampRobot (Post 1198483)
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

Re: Behind The Design 2012
 
Quote:

Originally Posted by JVN (Post 1198307)
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

JVN 04-12-2012 08:46

Re: Behind The Design 2012
 
Quote:

Originally Posted by Brandon Holley (Post 1198561)
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


All times are GMT -5. The time now is 09:25.

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