Behind The Design 2012

[Brandon Holley]

Originally Posted by JVN

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]

Originally Posted by Brandon Holley

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

[Nemo]

Originally Posted by JVN

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.

[Ether]

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?

[dtengineering]

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

[Adam Freeman]

Originally Posted by Ether

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.

[Ether]

Originally Posted by Adam Freeman

I pointed our controls guys to this thread. He will answer the control algorithm question.

Thanks Adam.

[Tom Line]

Originally Posted by Adam Freeman

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.

[Jay Meldrum]

Originally Posted by Ether

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]

Originally Posted by jsmeldru

"squishiness".

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

[Ether]

Originally Posted by jsmeldru

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.

[Jay Meldrum]

Originally Posted by Ether

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" ); 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);
        }

[DampRobot]

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?

[Tom Line]

Originally Posted by DampRobot

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

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!

[Ether]

Originally Posted by jsmeldru

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.