2012 FRC Team 1717 Uncut

[jakemochas]

Dear FIRST Community,

We would like to thank all of you for a great season of FIRST Robotics! As you may know, our team is made up of all seniors and we only get to do FIRST once. Thanks for making our experience so awesome! We had a fantastic time competing in the Long Beach and Central Valley Regionals and on the Newton field in St. Louis. From helping us in the pits to competing with gracious professionalism out on the field, everyone really made this season memorable!

Our 2012 robot is named Lindsay Rose in honor of our classmate who passed away during our freshman year. Lindsay would have been a senior in the Dos Pueblos Engineering Academy (DPEA) and would have been a member of Team 1717 this year. Her competitive spirit and energetic personality were definitely missed during the late nights of build season. We really cannot express how much her sweet, adventurous, and caring personality impacted everyone around her.

A few weeks before kickoff, the DPEA and Team 1717 were able to move into a brand new facility. In the past, our program resided in a 900 square room. In the new facility, we were able to setup a full size Rebound Rumble practice field. After St. Louis, we decided to take some final videos of Lindsay Rose in action before we dismantled the field. We have included links to the videos (below) along with a brief description of each video. We hope you enjoy watching them.

Thanks again,

2012 FRC Team 1717, the D’Penguineers


Watch the entire playlist here: http://www.youtube.com/playlist?list=PL51FE6FC40790DD2B

Swerve Drive
This video demonstrates the fluid motion of our swerve drive as well as some of the neat features specifically added by our programming team to aid in playing Rebound Rumble. In order to play a game that has its roots from basketball, we thought it would be advantageous for our robot to spin and pivot like a basketball player.
http://www.youtube.com/watch?v=kZHaTGiakZM

Swerve Slalom
This video demonstrates the more complex maneuvering capabilities of our swerve drive.
http://www.youtube.com/watch?v=p9WHMssEF4U

Bridge and Barrier Mechanisms
This video demonstrates our robot's ability to drive over the bridge, balance on the bridge, and cross the barrier.
http://www.youtube.com/watch?v=rM80DE3dBZk

Single Ball Shoot-Around
This video demonstrates a drill that we used to help our drivers line up for shots more quickly.
http://www.youtube.com/watch?v=Fn4XNM5Q2pQ

Collecting and Shooting
This video demonstrates a drill that we used to help our drivers reduce the amount time it took them to collect and shoot three balls. We also ran variations of the drill, only collecting one or two balls at a time.
http://www.youtube.com/watch?v=ZZsz-EZLI4w

30 Second Endgame Strategy
This video demonstrates a potential way to defeat the triple balance. In the event that we ended up on an alliance without the triple balance capability, we wanted a back-up plan. Rather than have our human player feed us balls throughout the game, we would take and score our opposing alliance’s balls. This would allow our human player to accumulate 6 balls. Typically at 30 seconds, there were still a few balls on our side of the field, and with the human player's 6 balls in hand, thrown properly, we could put up a lot of points. The assumption was that if teams were going to triple balance, we would likely be undefended during the last 30 seconds. We would send our alliance partners to double balance for 20 and we would try to make up the difference. Enjoy the buzzer beater!
http://www.youtube.com/watch?v=qCzHHwj2qZo

Shooter Accuracy and Precision
This video demonstrates the accuracy and precision of our shooter. The robot could shoot with this consistency from anywhere in the key and at the fender. The balls used in this demonstration run the gamut and vary in firmness and age. Some are fresh out of the box while others are more than a month old.
http://www.youtube.com/watch?v=yg_ssvGBqEs

Speeding up 6-Ball Autonomous for St. Louis
This video demonstrates the minimum time in which 6 balls could be shot by our robot during autonomous. On the night that this video was taken, our programmers successfully tripled our shooter’s rate of fire while maintaining the same accuracy. We needed to speed the process up to make it possible for other robots to feed their balls to us and guarantee that we could score all of them during the 15 second autonomous period.
http://www.youtube.com/watch?v=p7fbkfA8Pic

Highlight Reel
This video is shows our robot in action playing the 2012 FRC game, Rebound Rumble.
http://www.youtube.com/watch?v=rVDy4-b_hxo

[rsisk]

wow, I think I saw that 30 second end game a couple time in person ;>

[Ekcrbe]

Congrats on the amazing season. It was an honor to compete against you on Newton in St. Louis, and you probably deserved a finish better than Division Semifinalist with all the capabilities of the Lindsay Rose machine. Good luck in the future, and with your unique structure, Team 1717 seems poised to remain a force in FRC for years to come.

[Akash Rastogi]

All I can say about that slalom - http://www.youtube.com/watch?v=z1DzZ7oShl4

Your team simply amazes me.

Is there a site that discusses the curriculum your school has in place for the grade levels? I'd love to learn what the 9-11 students learn and what type of projects they work on as well as how it all transfers to the FRC team their senior year.

Congrats on a great season!

[bearbot]

Any idea if the CAD will be released to FRCdesigns or to the public it was a real game changing robot

[Steven Donow]

Any idea if the CAD will be released to FRCdesigns or to the public it was a real game changing robot

Oh, what I would give to see CAD of a 1717 bot ::rtm::

[LeelandS]

What a machine. Very inspiring, naming the robot after your classmate.

Lindsay Rose is, in my opinion, the best machine not on Einstein. Maybe I'm wrong to say that, with the likes of 469, 67, 341, etc. missing the Championship Stage, but I would say 1717 surpassed them all. They were mobile, with a swerve that has become renowned in the FIRST Community, accuracy with shooting that was unparalleled, and an ability to acquire balls at a rapid pace, making them a quintessential scoring machine.

1717's 2012 robot is absolutely amazing! I wish I could have seen it first hand. 1717 has been largely unknown in the past, save for those on the West Coast and some circles across the country. Now, I think 1717 is going to be on everyone's radar.

[Mk.32]

Wow.. that is epic...

Also on another note is it just me or is that like 30 milling machines on the right side of the field :O

[Steven Donow]

All I can say about that slalom - http://www.youtube.com/watch?v=z1DzZ7oShl4

Your team simply amazes me.

Is there a site that discusses the curriculum your school has in place for the grade levels? I'd love to learn what the 9-11 students learn and what type of projects they work on as well as how it all transfers to the FRC team their senior year.

Congrats on a great season!

The closest to that would probably be The New Cool. It's a few years old now, but it does give a nice insight into what their design process was like, and that was the year they created their swerve.

[Walter Deitzler]

The closest to that would probably be The New Cool. It's a few years old now, but it does give a nice insight into what their design process was like, and that was the year they created their swerve.

I talked to 1717 at Championship this year and learned that they have designed a completely new swerve since 2009. This year they used independent swerve modules because of the motor allowance, unlike in past years.

This was a fantastic robot and I loved getting to see the robot in action in these videos. I would also like to agree that 1717 is the best robot not on Einstein, for the reasons that Leeland stated. I had brought a teammate to watch Championships with me (my team wasn't actually competing) and I would always point out whenever 1717 came out to compete on Newton. He was astounded at there speed and accuracy of scoring.

Great machine, great team.

[IKE]

Congrats on the 150 in a row. That is quite the accomplishment. I seriously doubt that much more than 10% of FRC have even cycled that many balls through their shooter.

[Brian Selle]

Amazing robot, one of my favorites. Couple of questions...

1) Does the shooter wheel run continuously at a nominal or the last speed?
2) Is it using camera tracking? Continuous?

[CalTran]

http://www.youtube.com/watch?v=z1DzZ7oShl4


That just about sums up my thoughts on Lindsay Rose. Absolutely amazing.
Your shooter consistency has got to be the top shooter in FIRST Robotics this year. The performance you put on was absolutely inspiring, and something all teams should strive for. And your swerve just, *puts on sunglasses*, drives circles around all other swerves.

I think one thing never mentioned enough is that the members on 1717, each year, are having their rookie year, yet every time make excellence a standard.

[Hjelstrom]

Awesome robot. I love the end-game strategy too!

[Gregor]

I have not seen a team that matches your shooting capability. Your ability to shoot from wherever you choose is unparalleled by anyone. And your speed and agility just adds to the awesomeness!

[msimon785]

Since my first year in FRC, 2008, I have been inspired time and time again by the robots and professionalism of Team 1717.
Through their refined image that permeates their designs, dress and even performance, the team serves as a model for many of the teams that compete with them (note: structure notwithstanding).
This year, we had the honor of receiving three 2011 DPEA alumni as mentors for 1515. They were not only hugely knowledgeable and helpful, but they imparted their skills unto us in a manner that can only be described as GP. They made the season fun, even at the most grueling times.

Thank you 1717, and I hope (know) that you will continue to put out more of the amazing machines as have been demonstrated in recent years.

[Karthik]

Simply amazing. This robot will go down in FIRST history as one of the best to never make it to Einstein.

[JamesTerm]

Dear FIRST Community,

Swerve Drive
This video demonstrates the fluid motion of our swerve drive as well as some of the neat features specifically added by our programming team to aid in playing Rebound Rumble. In order to play a game that has its roots from basketball, we thought it would be advantageous for our robot to spin and pivot like a basketball player.
http://www.youtube.com/watch?v=kZHaTGiakZM


All of this is absolutely amazing... I gotta ask... would you mind sharing how the controls are mapped to the drive. In particular the spin and pivot. (We like to call this slide turning). Was it intuitive to the driver and useful to have and use?

[msimon785]

All of this is absolutely amazing... I gotta ask... would you mind sharing how the controls are mapped to the drive. In particular the spin and pivot. (We like to call this slide turning). Was it intuitive to the driver and useful to have and use?

I know from our mentors that they utilize their gyro to make the controls driver-relative and thus location-aware. In other words, regardless of the orientation of the robot, if the driver moves the joystick forward, the robot will travel away from him. This was done to make it more intuitive to the driver. With that said, I only know this of their 2011 (non-independent) swerve system, and even then you will need a 1717 student to confirm and expand on that.

[Lil' Lavery]

I'd like to shake your programmers' hands.

[Siri]

This is amazing! It was truly an honor to play with you on Newton, and you set the excellence standard for our team. Thank you for all the inspiration you've brought our students (not to mention our mentors).

[Jared Russell]

Oh boy.

Every year our team has a contingent of students (and mentors) who want to build a swerve drive. Every year, we decide to do something different based on our analysis of the game and our team's capabilities. These videos are going to make that conversation a lot more challenging next year.

Hopefully someone from 1717 can elaborate a bit on their swerve implementation, which has been fine-tuned to perfection.

EDIT: What gyro do you use for field-relative control?

[sgreco]

This robot simply amazes me. The accuracy and precision of the shooter is incredible. The pivoting around a wheel, and rotating while moving is just amazing to me.

[CalTran]

Huh. 1717 is not going to IRI? I guess that it makes sense, with the entire team having graduated already...

[Mk.32]

Huh. 1717 is not going to IRI? I guess that it makes sense, with the entire team having graduated already...

I wouldn't mind taking that robot to IRI for them :cool:

[R.C.]

1717 is by far one of the best robots in FRC this season. They've been making cool robots since 2007 (since I remember them). Their implementation and quality is unreal. After talking to their mentors, they've built a solid team.

It was great playing with/against you guys at CVR. We were really rooting for you guys to win it all this year! Can't wait to play with you guys next year!

-RC

[stundt1]

Awesome robot does anyone have vide of their elimination semi matches?

[jakemochas]

Hi everyone!

I was a student on the team this year and I was one of the programmers. I worked on all aspects of programming the robot but my focus was the shooter. Thank you for all of the kind words.

We have been following the responses in this thread and we will respond to them over the next week so. I am working to consolidate questions and then I will either answer your questions or I will work with the assistance of members of our team depending on their area of expertise. Please check back if you are interested. Thanks again for the support!

Jake
FRC Team 1717

[R.C.]

Hi everyone!

I was a student on the team this year and I was one of the programmers. I worked on all aspects of programming the robot but my focus was the shooter. Thank you for all of the kind words.

We have been following the responses in this thread and we will respond to them over the next week so. I am working to consolidate questions and then I will either answer your questions or I will work with the assistance of members of our team depending on their area of expertise. Please check back if you are interested. Thanks again for the support!

Jake
FRC Team 1717

Jake,

Is there by any chance you could put up close up pics of the intake/shooter/robot etc...

I was slightly too buys talking to Amir/the kids and checking out the amazing modules to really get a chance to take a look at the rest of the bot!

Thanks,

-RC

[Walter Deitzler]

Jake,

Is there by any chance you could put up close up pics of the intake/shooter/robot etc...

I was slightly too buys talking to Amir/the kids and checking out the amazing modules to really get a chance to take a look at the rest of the bot!

Thanks,

-RC

Expanding on this: Could you upload the CAD to FRC-designs.com? I would absolutely LOVE to see the CAD of a 1717 bot.

I have seen that this request has already been posted, but I felt the need to echo this plea.

Edit:: Please don't feel obligated to do this, it is just a request. You do not have to release your CAD, and I understand if you don't.

[msimon785]

The CAD would be absolutely wonderful. While you may choose not to release it (and that's perfectly okay), keep in mind that it would hugely benefit the entire FIRST community. Additionally, it is not unheard of for power-house teams to release their CAD, and FRC-Designs is a wonderful outlet to do so (148,973 come to mind).

Either way, would it be possible to get pictures of the independent gearboxes? Preferably with the module installed. I had the chance to see your old ones in 2011, but never got to see the 2012 modules up-close.

[stundt1]

The CAD would be absolutely wonderful. While you may choose not to release it (and that's perfectly okay), keep in mind that it would hugely benefit the entire FIRST community. Additionally, it is not unheard of for power-house teams to release their CAD, and FRC-Designs is a wonderful outlet to do so (148,973 come to mind).


I second this it would help the First community out. You dont have to release it and Im okay with that decision.Keep in mind teams like 148,33,2337 have released theirs this year also.

[AdamHeard]

It's helpful for teams to release their CAD files, but don't pressure teams to do so or try to make them feel obligated to due so based on GP.

[Mark Sheridan]

Those were some amazing videos. I absolute love this robot. Its just so original and ingenious. I also have the honor to be on the receiving end of that 30 second end game.

What would be really cool is a tour video of Dos Pueblo's new engineering academy building. The New Cool showed how hard everyone was fighting for it. It would be nice to see the fruit of that labor. Judging from background of the videos, it was a happy ending. Plus, I know my team's school is curious about Dos Pueblo's engineering program.

In regards to releasing the CAD, their mentors told me the Swerve drive alone took 5 students and 5 mentors over 2000 hours to create. I think its perfectly fine if 1717 does not want to release their CAD. They worked so hard and learned so much. I think the journey is the greater reward. I think its great that some teams release their CAD but its ok for a team to not want to. sometimes things are too precious to share. Besides maybe its better to share the journey than the reward.

In that regards, I would like the thank 1717 (and 973 too) for inspiring my team to explore swerve drive as a summer project. We are in the project feasibility phase, we know there is no guarantee of success. Even if we don't make it out of the feasibility phase, I am pretty sure my students will learn a lot.

[LeelandS]

I don't know about you guys, but I'm way more interested in their targeting software! I love the Swerve drive and all, but many-a-team have developed a Swerve drive through their histories that had people swooning. I haven't seen a single team with such pin-point accuracy as employed by 1717.

Seeing 1717's code would be quite the early Christmas present :) But Adam is right. It's unfair to ask a team to release their stuff. If 1717 feels right about releasing the stuff they put so much work in, then they'll do it. If not, we can only continue on the path of exploration and striving to reach that elusive point at the top of the mountain where 1717's robot parties with all the other legendary machines of yore.

Once again, 1717, congratulations on an amazing machine. My views of 1717 have certainly changed through this season (not that I held any negative feelings towards them or anything like that). If 1717 can continue to build robot's of this quality, it'll only be a matter of time before we hear Dave introducing them on Einstein. And from there, the confetti storm for them won't be too far off.

[AdamHeard]

In that regards, I would like the thank 1717 (and 973 too) for inspiring my team to explore swerve drive as a summer project. We are in the project feasibility phase, we know there is no guarantee of success. Even if we don't make it out of the feasibility phase, I am pretty sure my students will learn a lot.

We're likely running a 6/8wd next season ;)

[Garret]

What would be really cool is a tour video of Dos Pueblo's new engineering academy building. The New Cool showed how hard everyone was fighting for it. It would be nice to see the fruit of that labor. Judging from background of the videos, it was a happy ending. Plus, I know my team's school is curious about Dos Pueblo's engineering program.

I believe they actually just had an open house a few weeks ago. I don't know if they will hold more or if this was a one time thing because they just got the new building.

[Mark Sheridan]

We're likely running a 6/8wd next season ;)

how odd, the drivetrain that is running against swerve in our feasibility discussion is a 6/8wd;)

[CalTran]

We're likely running a 6/8wd next season ;)

That is quite an optimistic statement; without even knowing next years game! :rolleyes:

I think we should just drop the topic of releasing the CAD or not, because all the more we talk about it, all the more they are going to feel pressured into it. Rather than emulating their swerve, study all the swerves and use 1717's swerve as a baseline for the performance you want out of yours. You're never going to beat them in a driving fight if you're using the swerve that they designed and practiced with. You need something that would out perform theirs.

[Andrew Schreiber]

Well, this is NOT helping me not want to build a swerve...

1717, it was a pleasure to see you guys this season, your swerve is an inspiration.

[JamesTerm]

I know from our mentors that they utilize their gyro to make the controls driver-relative and thus location-aware. In other words, regardless of the orientation of the robot, if the driver moves the joystick forward, the robot will travel away from him. This was done to make it more intuitive to the driver. With that said, I only know this of their 2011 (non-independent) swerve system, and even then you will need a 1717 student to confirm and expand on that.

Thanks for the heads up and this was an idea we considered for last year's game (especially since most of the time the robot was facing you), but given what is said here... I feel there is a missing piece to the puzzle... A gyro can give delta's of angular acceleration but what can ensure the robot's heading is calibrated? Is there some point of reference that can be sensed dynamically while rotating?

I'll be anxious to hear how/if they solved that problem. :)

[JVN]

Very, very VERY impressive. I wish I had gotten a closer look in St Louis.
Kudos to 1717 on such an amazingly capable machine. Everyone involved with that robot should be VERY proud.

Each year we are given an engineering challenge. Each year we all struggle to pull some engineering excellence out of our hat and create the perfect robot for the challenge. This robot certainly just drips in engineering excellence. :) Even without a Championship win, this robot represents a HUGE success.

I'd love to hear more about the process that went into the creation of this beast:
What sorts of iteration did you go through?
What systems came together quickly, which ones did you struggle with?
What decisions came easy, and which ones did you debate most?

Thanks for dropping my jaw!
-John

PS - This is the first time in a looong time I've been impressed with a swerve drive. I feel bad for all the teams next year who will be inspired to do swerve thinking they'll end up with something like this, only to be... surprised by what they actually end up with. ;)

[jakemochas]

The closest to that would probably be The New Cool. It's a few years old now, but it does give a nice insight into what their design process was like, and that was the year they created their swerve.

I talked to 1717 at Championship this year and learned that they have designed a completely new swerve since 2009. This year they used independent swerve modules because of the motor allowance, unlike in past years.


Our first year doing swerve was in fact the 2009 season in the game Lunacy as stated above. Our design process for that year is detailed pretty well in the book, The New Cool. Each year since 2009, we have decided to continue using swerve.

In the 2010 and 2011 seasons, we found it beneficial to be able to translate from side to side. This was especially true in last year’s game Logomotion when positioning the robot to score. In the past two years, our robot could either translate in any direction or rotate in place. It could not, however, rotate and translate simultaneously due to the mechanical limitations of our motor-gearbox-module-arrangement. Based on our comfort level with the different motors in the kit, we didn’t feel that it was worth taking high powered motors from key mechanisms and allocating them to the drive or using lower power motors to create an independent swerve drive.

This year, however, with the new motor allowance, we were able to allocate 8 motors to the drive and still have enough high quality/power motors remaining to effectively power all of our remaining mechanisms. With those 8 motors allocated to our drivetrain, we were able to create a swerve drive system with 4 independent wheel modules. The independent modules allowed us to implement spinning while driving and pivoting around one wheel.

[SenorZ]

Inspiring as always. We enjoyed our one (+replay) match with you guys.

[BJC]

Very, very VERY impressive. I wish I had gotten a closer look in St Louis.
Kudos to 1717 on such an amazingly capable machine. Everyone involved with that robot should be VERY proud.

Each year we are given an engineering challenge. Each year we all struggle to pull some engineering excellence out of our hat and create the perfect robot for the challenge. This robot certainly just drips in engineering excellence. :) Even without a Championship win, this robot represents a HUGE success.

I'd love to hear more about the process that went into the creation of this beast:
What sorts of iteration did you go through?
What systems came together quickly, which ones did you struggle with?
What decisions came easy, and which ones did you debate most?

Thanks for dropping my jaw!
-John

PS - This is the first time in a looong time I've been impressed with a swerve drive. I feel bad for all the teams next year who will be inspired to do swerve thinking they'll end up with something like this, only to be... surprised by what they actually end up with. ;)

I will reitterate all of what Mr. V-Neun said. I absolutely love this robot and would love to hear more about your teams design process and build season schedual.

I'm already looking forward to seeing what you build next year,
Regards, Bryan

[MichaelBick]

Thanks for the heads up and this was an idea we considered for last year's game (especially since most of the time the robot was facing you), but given what is said here... I feel there is a missing piece to the puzzle... A gyro can give delta's of angular acceleration but what can ensure the robot's heading is calibrated? Is there some point of reference that can be sensed dynamically while rotating?

I'll be anxious to hear how/if they solved that problem. :)

Yes magnetometer. But it lags, so you have to run it through a filter.

1717 has inspired me. They are truly one of the best teams in FIRST, and I am so glad that they have finally found the spotlight(if they had not already by showing up on Einstein in 2009). The quality of each and every robot they make is amazing.

Swerve is a very hard drivetrain. They make it look very easy. However, even if they do not release their CAD, I highly recommend to any teams looking into swerve that you look at 973's Emperor Swerve. I feel that it is mechanically equal to 1717's drivetrain. You should furthermore look at 973's CADs regardless, because they are an example of how to make a competitive robot.

Again, to all teams looking into swerve: it is a very hard drivetrain. Adam has even said that they are likely not going to compete with a swerve again next year. The amount of driver practice, programming, and build time required just to get a competitive swerve, is unachievable than 95% of teams, and furthermore not worth the return on investment those teams. Prototyping in the offseason is a must, and don't expect to compete with it after only a year of prototyping. 6/8 wheel drive is an absolutely competitive drivetrain, that I and many other teams, including powerhouses, will recommend.

[Akash Rastogi]

Yif they had not already by showing up on Einstein in 2009)

Small correction, they were Galileo finalists and the CMP quality award winners.

[akoscielski3]

Small correction, they were Galileo finalists and the CMP quality award winners.

yea, if you read their book... lol

[jakemochas]

I know from our mentors that they utilize their gyro to make the controls driver-relative and thus location-aware. In other words, regardless of the orientation of the robot, if the driver moves the joystick forward, the robot will travel away from him. This was done to make it more intuitive to the driver. With that said, I only know this of their 2011 (non-independent) swerve system, and even then you will need a 1717 student to confirm and expand on that.

Last year and in all previous years, we did not utilize a gyro with our swerve drivetrain. As a result, all previous robots have been driven from a robot-centric view.

All of this is absolutely amazing... I gotta ask... would you mind sharing how the controls are mapped to the drive. In particular the spin and pivot. (We like to call this slide turning). Was it intuitive to the driver and useful to have and use?


Because the drivetrain was capable of such complex maneuvers, a goal for the programming team this year was to make the robot as easy to drive as possible. This was incredibly important because we are all seniors and our team has rookie drivers every year. Almost everyone on our team has been capable of driving the robot in a rudimentary fashion when using the joysticks for the first time. They really enjoy the simplicity and the intuitive nature of the controls.

This year, the simplicity of the driver’s controls were particularly important. Our drivers had never driven a FIRST robot because we were moving into our new facility. As a result, we were not able to give them the proper introduction to driving a robot. The first time our drivers were able to drive a robot was 2 weeks after build season ended when we finished our practice robot. Before the LA Regional, our drivers had less than 10 hours of driving practice.

The layout for the driver’s controls and programming implementation are as follows:

The driver has 2 joysticks to control the drivetrain. Like last year, the left is used to translate the robot in any direction and the right joystick’s x-axis is used for rotating the robot. Unlike last year, however, this year we used a gyro to make the controls for the drive field-centric. If our driver pushes the joystick away from himself, the robot moves away from him regardless of the robot’s orientation.

The gyro makes basic driving easier, but it also makes it possible to spin while driving. All the driver does to spin while driving, or “slide turn”, is move the left and right joysticks together. The robot moves with the direction and speed of the left joystick. The robot’s spin speed and spin direction are dictated by the right joystick. Spinning while driving has become an integral part of all of our driver’s maneuvers. The spinning while driving made it much easier to avoid defensive robots, collect balls, lineup for shots, and make final adjustments on the bridge.

To pivot around a specific wheel, we used 4 buttons that each correspond to one of the wheel modules on the robot. When the driver holds down one of those buttons, the right joystick’s spin commands adjust to pivot around that wheel. The pivots about a single wheel were used less frequently, but helped in situations where we wanted to maneuver around a robot that was pushing us or line up at the fender after collecting a ball from in front of the fender.

Spinning while driving became natural for our drivers because of its implementation and joystick mapping. Our robot was able to perform maneuvers in the game that were not possible in previous years. An example of our robot’s maneuverability can be seen in the slalom swerve video from our original post.

http://www.youtube.com/watch?v=p9WHMssEF4U

[CalTran]

Well...they technically showed up on Einstein as the Galileo back up bot, and sat on the side of the field...

[jakemochas]

I know from our mentors that they utilize their gyro to make the controls driver-relative and thus location-aware. In other words, regardless of the orientation of the robot, if the driver moves the joystick forward, the robot will travel away from him. This was done to make it more intuitive to the driver. With that said, I only know this of their 2011 (non-independent) swerve system, and even then you will need a 1717 student to confirm and expand on that.

Last year and in all previous years, we did not utilize a gyro with our swerve drivetrain. As a result, all previous robots have been driven from a robot-centric view.

All of this is absolutely amazing... I gotta ask... would you mind sharing how the controls are mapped to the drive. In particular the spin and pivot. (We like to call this slide turning). Was it intuitive to the driver and useful to have and use?

Because the drivetrain was capable of such complex maneuvers, a goal for the programming team this year was to make the robot as easy to drive as possible. This was incredibly important because we are all seniors and our team has rookie drivers every year. Almost everyone on our team has been capable of driving the robot in a rudimentary fashion when using the joysticks for the first time. They really enjoy the simplicity and the intuitive nature of the controls.

This year, the simplicity of the driver’s controls were particularly important. Our drivers had never driven a FIRST robot because we were moving into our new facility. As a result, we were not able to give them the proper introduction to driving a robot. The first time our drivers were able to drive a robot was 2 weeks after build season ended when we finished our practice robot. Before the LA Regional, our drivers had less than 10 hours of driving practice.

The layout for the driver’s controls and programming implementation are as follows:

The driver has 2 joysticks to control the drivetrain. Like last year, the left is used to translate the robot in any direction and the right joystick’s x-axis is used for rotating the robot. Unlike last year, however, this year we used a gyro to make the controls for the drive field-centric. If our driver pushes the joystick away from himself, the robot moves away from him regardless of the robot’s orientation.

The gyro makes basic driving easier, but it also makes it possible to spin while driving. All the driver does to spin while driving, or “slide turn”, is move the left and right joysticks together. The robot moves with the direction and speed of the left joystick. The robot’s spin speed and spin direction are dictated by the right joystick. Spinning while driving has become an integral part of all of our driver’s maneuvers. The spinning while driving made it much easier to avoid defensive robots, collect balls, lineup for shots, and make final adjustments on the bridge.

To pivot around a specific wheel, we used 4 buttons that each correspond to one of the wheel modules on the robot. When the driver holds down one of those buttons, the right joystick’s spin commands adjust to pivot around that wheel. The pivots about a single wheel were used less frequently, but helped in situations where we wanted to maneuver around a robot that was pushing us or line up at the fender after collecting a ball from in front of the fender.

Spinning while driving became natural for our drivers because of its implementation and joystick mapping. Our robot was able to perform maneuvers in the game that were not possible in previous years. An example of our robot’s maneuverability can be seen in the slalom swerve video from our original post.

[CalTran]

Spinning while driving has become an integral part of all of our driver’s maneuvers. The spinning while driving made it much easier to avoid defensive robots, collect balls, lineup for shots, and make final adjustments on the bridge.

The pivots about a single wheel were used less frequently, but helped in situations where we wanted to maneuver around a robot that was pushing us or line up at the fender after collecting a ball from in front of the fender.

An example of our robot’s maneuverability can be seen in the slalom swerve video from our original post.

I've watched that video a few times, but do you happen to have a specific match that you think showcases this feature the best? I'd like to see not only how your team used it, but how a team would react to this maneuver happening.

[JamesTerm]

Unlike last year, however, this year we used a gyro to make the controls for the drive field-centric. If our driver pushes the joystick away from himself, the robot moves away from him regardless of the robot’s orientation.


Thanks for giving the layout and it makes sense given that it is possible to drive field centric.

I have to ask... what language are you using to program?
I looked into the gyro class (I use c++ wind-river) and found this:


/**
* Reset the gyro.
* Resets the gyro to a heading of zero. This can be used if there is significant
* drift in the gyro and it needs to be recalibrated after it has been running.
*/
void Gyro::Reset()


How did you solve the problem for potential drift? Is there something you calibrated against to keep it in line? How reliable can it keep its heading? Does it matter where the gyro is placed on the robot?


Also I want to make a correction from the last entry... "spin and pivot" is different from "slide turns". Watch this video (sorry some of you have seen this before).

www.termstech.com/files/SwerveDriveDemo.wmv

The slide turns... are turns made in slide mode where slide mode is a toggle button pressed. This is robot-centric and does not require a gyro... the way it works is that there is a fundamental desired linear and angular velocity that get translated. The slide mode is a simpler case of not applying centripetal force to keep the robot driving in a straight line. It is like playing asteroids using the thrust button. Since we apply force for centripetal force we can be aware of how much force is applied at all times and dampen the overall velocity (without sacrificing direction) to stay within a limited amount of force. This helps prevent the robot from an accidental tip over... and with our high CG this year... that comes in handy.

[jakemochas]

Yes magnetometer. But it lags, so you have to run it through a filter.


We did not use a magnetometer. We only used a gyro. Our implementation of field-centric swerve drive with a gyro can be seen below.


What gyro do you use for field-relative control?

Does it matter where the gyro is placed on the robot?


We ended up using a SparkFun gyro (product# 9094), but we were not satisfied with performance of this gyro with the cRIO’s analog interface. It is important that you mount the gyro in a spot on the robot that has little vibration because it is very susceptible to noise. I would recommend mounting it to the frame of your robot.

Thanks for the heads up and this was an idea we considered for last year's game (especially since most of the time the robot was facing you), but given what is said here... I feel there is a missing piece to the puzzle... A gyro can give delta's of angular acceleration but what can ensure the robot's heading is calibrated? Is there some point of reference that can be sensed dynamically while rotating?
I'll be anxious to hear how/if they solved that problem. :)


I have to ask... what language are you using to program?

How did you solve the problem for potential drift? Is there something you calibrated against to keep it in line? How reliable can it keep its heading? Does it matter where the gyro is placed on the robot?


The gyro measures angular acceleration, which we use to determine the orientation of our robot. When the robot is booting up, it calibrates the sensor by measuring the analog voltage when the robot is motionless and establishes that as a baseline. We used the C++ Gyro class provided by WPILib to integrate the analog channel and show us our current angle. We know the orientation of the robot at the beginning of the match and zero it then.

Throughout the season, we tried a variety of 500 degree/second gyros that were attached to the analog port on the cRIO. In the end, though, we were not satisfied with any of the gyros. The gyros had significant drift, asymmetrical behavior, and were extremely sensitive to collisions on the field. In about 45 seconds, the gyro would drift by as much as 60 degrees and the advantages of the gyro would be lost.

In order to solve this problem, the drivers rezeroed the gyro every time they lined up for a shot at the fender or the key (the Reset() function). For all of our shots, the robot faced directly forward, which gave the perfect opportunity to rezero. Between each shot, the gyro was good enough to keep the robot oriented in the correct direction. Also, we trained our drivers in a no-gyro mode (robot-centric) in the event of a gyro failure. This training paid off. Even though we had gyro calibration failures in each regional event, the robot appeared like it was operating normally to the outside observer.

In the end, we were not satisfied with the performance of the gyro. One of our goals for next year is to find a better gyro solution for our swerve drive system.

[AdamHeard]

In order to solve this problem, the drivers rezeroed the gyro every time they lined up for a shot at the fender or the key (the Reset() function). For all of our shots, the robot faced directly forward, which gave the perfect opportunity to rezero. Between each shot, the gyro was good enough to keep the robot oriented in the correct direction. Also, we trained our drivers in a no-gyro mode (robot-centric) in the event of a gyro failure. This training paid off. Even though we had gyro calibration failures in each regional event, the robot appeared like it was operating normally to the outside observer.

In the end, we were not satisfied with the performance of the gyro. One of our goals for next year is to find a better gyro solution for our swerve drive system.

We used a gyro in the same fashion for pretty much the same drivetrain and agree 100% with your comments. We also zeroed on shots and are looking into better implementations for a gyro.

[JamesTerm]

Yes magnetometer. But it lags, so you have to run it through a filter.


Woe! ok can you elaborate on this? So is there a particular part I can research, and is it legal? This is some exciting stuff! :)

[JamesTerm]

In order to solve this problem, the drivers rezeroed the gyro every time they lined up for a shot at the fender or the key (the Reset() function). For all of our shots, the robot faced directly forward, which gave the perfect opportunity to rezero. Between each shot, the gyro was good enough to keep the robot oriented in the correct direction.

Ah ha! Oh that's cool. When the robot faced directly forward, did you take that moment to have a keying solution? (see below)

We call a keying solution when we would find a good place to "key" our position and orientation. From that we calibrated where we were on the field, and then could use the feedback from the encoders to make it possible to move around the key to fender area for a little while and still be position aware. We'd interpolate evenly spaced key points in an error correction grid and calibrate shots from those points (i.e. 3x3 grid). IIRC I think Jared (341) used an error correction table as well.

While I'm here... I noticed the tune of the shooter speed sounded very consistent. Did you PID the rate of the shooter to an encoder, and did you use victors or Jags? It seems to lock on to the rate very well!



In the end, we were not satisfied with the performance of the gyro. One of our goals for next year is to find a better gyro solution for our swerve drive system.

So what are your thoughts on using a Magnetometer? I'm googling like crazy right now about this! ;)

[rsisk]

Something that I've been wondering, what on your bot was stabbing the fender in LA?

[jakemochas]

Something that I've been wondering, what on your bot was stabbing the fender in LA?

Our barrier-crossing mechanism was deployed when we lined up for a fender shot. That only happened once in all of our competitions and driver practices. You can see the barrier-crossing mechanism in a video at the beginning of the thread.

[Siri]

This year, however, with the new motor allowance, we were able to allocate 8 motors to the drive and still have enough high quality/power motors remaining to effectively power all of our remaining mechanisms...Can I ask what drive & steering motors did you use in 2009-2012?




Anyone who hasn't, read The New Cool. I keep remembering this one line as I read this thread:
"We're Team 1717. Nobody knows us here."
...1717 Coach Amir Abo-Shaeer at the 2009 FRC World Championship



How quickly things can change when you're truly dedicated.

[jakemochas]

Can I ask what drive & steering motors did you use in 2009-2012?

Below I have provided an overview detailing our swerve drives for the years 2009-2012:

2009
This was the first year that we decided to use a swerve drivetrain. Our drivetrain was split down the middle of the robot. On the left side, both of the drive wheels were paired together and powered by 1 CIM motor through a single speed belt reduction that used timing pulleys. The left wheels were also paired together for turning. The turning was powered by a banebots RS-545 though a banebots planetary transmission.

The right side of the robot was a mirror image of the left side.

2010
The drive for the wheels were again coupled together in pairs. Both of the left wheels were driven together and both of the right wheels were driven together. To power this drive, each pair of wheels was powered by two CIM motors through a two-speed transmission that was a re-packaged AM supershifter gear-set with some custom modifications.

For turning, the front left and back right wheels were paired together and the front right and back left wheels were paired together. This enabled both translational motion in any direction and rotation of the robot about its origin when it was not translating. Each turning pair was powered by a single fisher price motor through our custom gearbox with purchased gears.

2011
The wheel pairings were the same as in 2010, but the turning motors were banebots RS-775 motors.

Our drive transmissions were custom two-speed transmissions that were optimized for our swerve system. The turning transmissions were custom as well. Also, we cut all of our gears in house and they were made from steel.

2012
In 2012, our drivetrain consisted of four independent wheel modules. Each wheel module’s drive was powered by one CIM motor with a two-speed custom gearbox. Our wheel module’s turning was powered by a single banebot RS-550 with a custom transmission. All of our gears were made from aluminum and they were cut in house.

In an upcoming post we will provide some pictures of the 2012 modules and describe them a little more thoroughly.

[Steven Donow]

In an upcoming post we will provide some pictures of the 2012 modules and describe them a little more thoroughly.

And the countdown for what could be one of the greatest posts ever begins...

[Akash Rastogi]

Jake, what method were you using to cut your gears in house? Are they stacked plate gears?

Also, you said your team had 2 speed transmissions optimized for your swerve, what iterations did your transmissions go through in order to optimize for a swerve?

Thanks for all the great insight!

-Akash

[R.C.]

Jake, what method were you using to cut your gears in house? Are they stacked plate gears?




I believe it was cut using the 4th axis (Tormach CNC?). They were definitely not stacked gears and were pocketed very nicely.

-RC

[jakemochas]

Jake, what method were you using to cut your gears in house? Are they stacked plate gears?

Also, you said your team had 2 speed transmissions optimized for your swerve, what iterations did your transmissions go through in order to optimize for a swerve?

Thanks for all the great insight!

-Akash

I believe it was cut using the 4th axis (Tormach CNC?). They were definitely not stacked gears and were pocketed very nicely.

-RC

We cut our gears using a Tormaq CNC mill equipped with a 4th axis. The gears are cut using involute spur-gear cutters. Below is a McMaster-Carr link where you can order the type of gear cutters we use. I have also included a picture of a gear cutter below.

http://www.mcmaster.com/#gear-cutters/=i19i2u

http://i21.geccdn.net/site/images/n-picgroup/TLM_5-862-0105.jpg

We buy round stock and from that we make gear stock. I have included a sample picture of a piece of gear stock below.
http://www.sdp-si.com/web/images/product_images/Gears/Spur-Gear-Stock.jpg

In order to make the gear stock, we use the process shown in the video link posted below. In the video, however, they are making a single gear. We use this same process to make an entire piece of gear stock. After we make the gear stock, we part it off in a lathe to make the individual gears.

http://www.youtube.com/watch?v=sCuf6RqM7e0

[JamesTerm]

We did not use a magnetometer. We only used a gyro.

In the end, though, we were not satisfied with any of the gyros. The gyros had significant drift, asymmetrical behavior, and were extremely sensitive to collisions on the field. In about 45 seconds, the gyro would drift by as much as 60 degrees and the advantages of the gyro would be lost.

In order to solve this problem....

One of our goals for next year is to find a better gyro solution for our swerve drive system.

Ok I'd like to throw an idea to you, and others feel free to shoot holes through this (couEthergh cough cough).


I'm going to start out with two assumptions that I hope people can help me verify:

1. A gyro... has quick repsonse, but is subject to drift
2. A Magnetometer does not drift but has a slow response (lag)

If these assumptions are correct (to the way I'm thinking they work), then I'd propose the idea of having them work together to yield a quick reponse heading that remains fairly accurate.

I've solved this kind of problem before at work and since you are a c++ programmer... I'll show you the code where I do this. right here:


size_t GetPlayPos()
{
DWORD playpos;
//size_t SampleOffset=0;
size_t SampleOffset=(size_t)(0.038 * m_SampleRate);
m_lpdsb->GetCurrentPosition(&playpos,NULL);
playpos/=m_BlockAlign; //convert to samples

//Note: This design assumes the buffer size (of our secondary buffer) is the same size as the sample rate. This is fine for now, but at some
//point I may need to make a distinction if I have to change the buffer size.

time_type CPUClock=((__int64)time_type::get_current_time()+m _ClockPhaseOffset) % 10000000;
double CalibratePlayPos=(double)CPUClock*m_SampleRate;
int PhaseOffset=(int)playpos-(int)CalibratePlayPos;
int iSampleRate=(int)m_SampleRate;
//Check wrap-around case
if (PhaseOffset > iSampleRate>>1)
PhaseOffset= ((int)playpos-iSampleRate) - (int)CalibratePlayPos;
else if (PhaseOffset < -(iSampleRate>>1))
PhaseOffset= playpos - ((int)CalibratePlayPos-iSampleRate);

double Current_ClockPhaseOffset=(double)m_ClockPhaseOffse t + (((double)PhaseOffset / m_SampleRate) * 10000000.0);

//check math
//CPUClock=((__int64)time_type::get_current_time() + (__int64)Current_ClockPhaseOffset) % 10000000;
//CalibratePlayPos=(double)CPUClock*m_SampleRate;
//printf("Test-> playpos %d, %d \n",playpos,(size_t)(CalibratePlayPos));

const double dSmoothingValue=0.1;
//blend the current phase error to the current phase offset
m_ClockPhaseOffset=(__int64) (((1.0-dSmoothingValue) * (double)m_ClockPhaseOffset) + (dSmoothingValue * Current_ClockPhaseOffset));
//debug_output(p_debug_category,L"playpos %d, %d, %d\n",playpos,(size_t)(CalibratePlayPos),PhaseOffset);
size_t Error=abs(PhaseOffset);
//printf("\r%d ",Error);
//if (Error>1000)
// debug_output(p_debug_category,L"%d\n",Error);

return AdvancePosition((size_t)(CalibratePlayPos),SampleO ffset);
}



In this example we want to determine the play position of the audio cursor inside a sound card (using direct sound). The reality is the GetCurrentPosition() method is similar to using (what my assumption is of) the magnetometer where it has lag (about 20 30ms of repeated results). This is not acceptable! So to solve the problem I use the PC clock since it has a quick response (e.g. like the gyro). The way this code works is it applies a continuous error correction to whatever the current clocktime is read... so it would be like using the gyro reading as your base answer and applying the magentometer error correction on it. The design here is similar to using P in PID (in the PhaseOffset variable)... and doing a blend function on the error computed. The blend allows the gyro to have more influence on quick movement and less influence on slower movements while over time it is always recalibrating itself to the correct point of reference. I hope this idea is useful and the assumptions about the sensors are correct... I may have a run with these. :)

[rachelholladay]

(Sorry to totally deviate from the robot design discuss, but i have a question..)

As you may know, our team is made up of all seniors and we only get to do FIRST once.

Maybe because this is so radically different then the way my team is structured, but this statement seemed a little odd to me. Is it by design or accident that the team is all seniors? If by design, then why? I am very curious..

[msimon785]

(Sorry to totally deviate from the robot design discuss, but i have a question..)



Maybe because this is so radically different then the way my team is structured, but this statement seemed a little odd to me. Is it by design or accident that the team is all seniors? If by design, then why? I am very curious..

It is by design. On 1717, 9th, 10th and 11th grade are spent in preparation for the culminative senior year that is FIRST. I know in 10th and 11th grade, you have the option of coming to competitions (I don't remember the details, though), but your only experience building an FRC robot is in 12th grade.

IIRC, each grade focuses on a specific aspect of engineering - so the students get a well-rounded background - before they participate in FRC.

[jakemochas]

Hi everyone,
I am trying to answer all of your questions and I have many responses ready to go. At the moment, however, the thread will not let me post links or images to the forum. Many of the answers would be incomplete without this content. We are working as quickly as possible to get your answers up!
Thanks,
Jake
FRC Team 1717

[JamesD]

It is by design. On 1717, 9th, 10th and 11th grade are spent in preparation for the culminative senior year that is FIRST. I know in 10th and 11th grade, you have the option of coming to competitions (I don't remember the details, though), but your only experience building an FRC robot is in 12th grade.

IIRC, each grade focuses on a specific aspect of engineering - so the students get a well-rounded background - before they participate in FRC.

As I've heard, the FRC competition in the senior year is the culmination of the 4 year program. They aren't just a robotics team, but an engineering academy.

The BeachBots have had the pleasure of knowing and competing with team 1717 for several years now and have seen them grow into a powerhouse team. They continue to improve each year and are wonderful competitors and friends.

On May 26th the D’Penguineers had an open house at their new engineering academy building in Goleta and invited the BeachBot team, as well as many others, up to visit. Many of us took the drive (3.5 hours that should have been 2) to go visit with them.

As many of us know, Amir's program and foundation at Dos Pueblos High with which he created the "Dos Pueblos Engineering Academy" is a great example of what can be done to promote, inspire, and educate students, not just in engineering, but in many disciplines that have a significant contribution to our culture and future.

I don't know if it's all in the “New Cool” book about them or not (that’s still on my reading list), but if you have any interest in replicating what they are doing (and you should) I think these notes will give you a bit of an idea of how to go about it.

================================================== ==========================

Engineering Academy notes:

Key: Curriculum is approved by the University of California schools so it counts toward entrance requirements. Parents prefer their kids take courses that help them get into college. Without this approval it's a nice program, but parents won't invest as much into it and won't want their kids to invest time in it since it wouldn't count towards college entrance requirements. [There are many universities that recognize FIRST students and offer scholarships to them, but the time invested with the team is not often recognized as satisfying a university entrance requirement]

Steps to make it happen (how it can be replicated):

1. It starts with someone passionate about it to drive it (thanks Amir!).

2. Build a board of directors - a few or all of these people are to emphasize funding and organization. They provide the Board of Directors for the 501(c)3 corporation.

3. Create a 501(c)3 organization - the foundation. This includes creating a mission statement and creating the financial structure needed (bank accounts, double signature approval process), financial
accountability, etc. A lawyer and an accountant on the board would help greatly with this.

4. Study and replicate DPEA's curriculum: Art, Science, Math, Engineering (technology). Art is important as it leads to design and creativity. DPEA (Amir) has done all the legwork, just replicate his curriculum, he seems glad to share it. Again, the curriculum is critical as without the UC approval it's just a nice club. Note that FIRST robotics is a part of the program for the second half of the senior year. It’s not a robotics program but an engineering program. FRC is just the last project (in a long line of increasingly more complicated projects) for the seniors.

http://www.dpengineering.org/academy/plan/four_year2

- Read the example projects and course descriptions on this page (really, take some time to review this stuff):
http://www.dpengineering.org/academy/plan/courses2

5. Design a plan: building needs, number of kids, equipment needs, personnel needs - paid and qualified teachers and engineers. Finding or training the right teachers will be important. Even to the point of having them spend time with Amir if possible. Define a budget, organization, and implementation schedule.

6. Begin to seek funding, both initial and on-going commitments. Develop a presentation for fundraising that includes detailed goals, costs, budget, etc. Include some students in the presentation to local businesses, corporations and foundations. 10 minutes long, no more. In person presentations if at all possible.

7. Develop a website and marketing materials leading into step 8 below.

8. Build energy in the community. Promotions, awareness, value to kids and community. I think this too is critical. DPEA works well since Santa Barbara is a small town community (well to some of us). Marketing to the local businesses, television station, newspapers, and the people in general works better since they all identify with the community (businesses want to be seen as participants, giving back; people want to see local schools, teams, doing well; etc.) In a metropolitan area you would have to define what your support community is and build lines of communication, marketing, awareness, value, and excitement about the project, etc.

9. Based on funding, create a timeline and identify resources needed at each point. Then for sustainment.

10. Begin implementation. Identify qualified instructors. Retired engineers? Possibly even seek donation of current engineer's time from corporations (4 hours, twice a week, who knows). Art teachers. Math & Science teachers.


Advantages from using Amir's work:
- curriculum approved by UC schools so it counts toward entrance requirements
- he's already done a lot of the leg work on all this
- visibility of his program

I think it would be good to have those at DPEA take a look first, to see if there's anything I missed that they think would be helpful to add. Could be something big I'm overlooking that they could point out.

[rachelholladay]

It is by design. On 1717, 9th, 10th and 11th grade are spent in preparation for the culminative senior year that is FIRST. I know in 10th and 11th grade, you have the option of coming to competitions (I don't remember the details, though), but your only experience building an FRC robot is in 12th grade.

Why? (Personally, it would break my heart to only do FRC one year)

[Steven Donow]

Why? (Personally, it would break my heart to only do FRC one year)

When reading The New Cool, it's easier to understand why. These kids are basically trained for FRC. Their senior year, school is FRC. And it's not like prior to senior year they're just learning engineering, from what it seems like, they basically are doing FRC-like things.

A thought I've always had as to "Why 1717 haven't been to Einstein/been champions" is the fact that they're all FRC rookies every year. But they're not. They spend 4 years completely surrounded by FRC.

Plus, as the poster from 1515 said, they(1717 students) do go on to mentor.

[dcarr]

I had a few questions regarding encoders:

We're working on our drivetrain over the summer. The past two years we have used CAN with our Jaguars, connected to a 2Can, but it has been riddled with problems. So we are switching to PWM which I know you guys use and plugging the encoders into the sidecar. Since each encoder can take 2 I/O ports, how did you manage that-did you fill one up? (if so, did you use more than one sidecar?) How did your sensor arrangement work, did you use many others besides the encoders and the gyro?

Thanks for taking the time to answer these questions, it is greatly appreciated!

[dcarr]

One more thing...the swerve modules seem to rotate a lot as you stop and prepare to shoot. Is this part of re-zeroing the gyro for each shot, or some other reason?

[jakemochas]

Hi everyone! Our answer to the gear cutting question has been approved and can be seen above at post #65. The post is above because it was posted on the 18th, but it didn’t show up until today. We are working hard to post all of our other answers as well! Thank you for your patience.
I had a few questions regarding encoders:

We're working on our drivetrain over the summer. The past two years we have used CAN with our Jaguars, connected to a 2Can, but it has been riddled with problems. So we are switching to PWM which I know you guys use and plugging the encoders into the sidecar. Since each encoder can take 2 I/O ports, how did you manage that-did you fill one up? (if so, did you use more than one sidecar?) How did your sensor arrangement work, did you use many others besides the encoders and the gyro?

Thanks for taking the time to answer these questions, it is greatly appreciated!

In order to PWM our 14 motor controllers and have enough I/O for the encoders, we did use two digital sidecars. As a result of the new motor allowance this year, it was the first time we used two digital sidecars.

We had many sensors on our robot that were wired to the analog and digital slots of the cRIO. For our swerve drive, we used two types of sensors: we used magnetic encoders on the analog board for wheel orientation and optical encoders for the wheel drive. Also, the gyro was attached to an analog port.

For the shooter, we used a magnetic encoder attached to the analog breakout to detect the platform position. For the hood angle, we used a multi-turn potentiometer on the analog breakout. To detect flywheel speed, we read from a light sensor that was attached to the digital sidecar I/O.

One more thing...the swerve modules seem to rotate a lot as you stop and prepare to shoot. Is this part of re-zeroing the gyro for each shot, or some other reason?

The rotation of the wheels when we prepare to shoot is mostly from re-zeroing, but some of the turning is from fine adjustments the driver makes while lining up for the shot.

[JamesTerm]

To detect flywheel speed, we read from a light sensor that was attached to the digital sidecar I/O.


When you say light sensor do you mean optical encoder?

[Jared Russell]

When you say light sensor do you mean optical encoder?

He may just mean a light sensor (like a Banner sensor, or a 2011 KOP line sensor) being used as a digital tachometer with a piece of reflective tape or a photogate. Nothing to "encode" (in a quadrature sense), since your wheel generally isn't changing the direction that it rotates.

[JamesTerm]

He may just mean a light sensor (like a Banner sensor, or a 2011 KOP line sensor) being used as a digital tachometer with a piece of reflective tape or a photogate. Nothing to "encode" (in a quadrature sense), since your wheel generally isn't changing the direction that it rotates.

Thanks Jared, that is what I was thinking as well... I'd love to see how well this compares against an encoder (either kind)... as of now, I am still frustrated with encoders with these high of speeds.

[BradenKing]

I was in awe of your drive system during the whole competition. I designed my teams transmission, and we were also right across from you guys in the pits at St. Louis.


P.S. Sorry to be a little off topic, but did you guys ever figure out exactly why your robot was dying at the Championships during Quarter-Final Matches 1 & 3?

[JohnSchneider]

P.S. Sorry to be a little off topic, but did you guys ever figure out exactly why your robot was dying at the Championships during Quarter-Final Matches 1 & 3?

And in one or two qualifying matches in the same alliance station (Station 1 red).

We actually had the same problem, and 1717 came over and compared notes with us. We couldn't find anything out of the ordinary that would cause the comms to fail, especially on our end. We both had perfect readings. It was suspicious that it was always the same alliance station.

I hope the results of the Einstien testing unveil what happened on the division field too.

[jakemochas]

Sorry to be a little off topic, but did you guys ever figure out exactly why your robot was dying at the Championships during Quarter-Final Matches 1 & 3?

And in one or two qualifying matches in the same alliance station (Station 1 red).

We actually had the same problem, and 1717 came over and compared notes with us. We couldn't find anything out of the ordinary that would cause the comms to fail, especially on our end. We both had perfect readings. It was suspicious that it was always the same alliance station.


We have not been able to determine why our robot died in any of our matches. Our Robot died on Friday in Qualification Match 101 on red 1. On Saturday, our robot died in Quarter-Finals Matches 1 and 3 on red 1. Finally, our robot died in Semi-Final Match 1 on Red 3. We died on Red 3 and Red 1 so our original thinking about it only having to do with red 1 was ultimately disproven.

[jakemochas]

He may just mean a light sensor (like a Banner sensor, or a 2011 KOP line sensor) being used as a digital tachometer with a piece of reflective tape or a photogate. Nothing to "encode" (in a quadrature sense), since your wheel generally isn't changing the direction that it rotates.

Thanks Jared, that is what I was thinking as well... I'd love to see how well this compares against an encoder (either kind)... as of now, I am still frustrated with encoders with these high of speeds.

When you say light sensor do you mean optical encoder?

It is a reflective photointerrupter with emitter and detector facing in the same direction. We have 16 black marks that are evenly spaced on the side of the flywheel to provide data for the detector.

[Akash Rastogi]

Can I just add that even the level of professionalism in each of 1717's students' posts is pretty inspiring. What an amazing group of people you must be to work with. Thank you for such insightful and detailed explanations.

[JB]

Can I just add that even the level of professionalism in each of 1717's students' posts is pretty inspiring. What an amazing group of people you must be to work with. Thank you for such insightful and detailed explanations.

Well said Akash. This has easily been one of my favorite threads on CD this year, mostly due to the timely and professional responses of Jake. Still hoping to see some pictures.

[jakemochas]

Congrats on the 150 in a row. That is quite the accomplishment. I seriously doubt that much more than 10% of FRC have even cycled that many balls through their shooter.

Our original goal for the video was to shoot 100 balls because based on our shooter’s performance, we knew this was possible. This video was the first time we have actually counted how many balls we can shoot in a row. After 100 balls, we decided to keep going out of curiosity. By the 150th ball, we were not able to feed the balls into the robot quickly enough to keep up with the rate of fire. We will always be curious to see how many more balls we could have scored.

To tune the shooter, we shot over 3000 balls to get the correct PID values for the flywheel, hood and platform and the correct bank shot for the largest variety of balls. During and after build season, we continued to experiment with different control loops and shots until we found the performance that can be seen in that video. We collected a variety of data on different types of shots, including both swishes and bank shots. In the end, we found that the bank shot was the most forgiving.

1) Does the shooter wheel run continuously at a nominal or the last speed?
2) Is it using camera tracking? Continuous?

I don't know about you guys, but I'm way more interested in their targeting software!

As the programmer responsible for the shooter, I will give an overview of the shooter code. I think many people are going to be surprised how we aim our shooter. Originally, our goal was to shoot from anywhere on our half of the field. As the build season came to an end, we decided to hold our shooter back as part of our withholding allowance to continue working on shooter code. In the time before our competitions, we ultimately got the camera tracking to work from anywhere. However, we were surprised to realize that we could shoot more quickly and accurately with crosshairs on the drivers station and a video feed. After we watched a regional in week one, we reassessed our shooting strategy and reduced the number of locations on the field that we felt were strategically advantageous and worked on those.

In order aim the shooter, we created 5 preset values. For the key, there are left, center and right presets. For the fender, there are left and right presets. Our co-driver holds down either the “fender” or “key” button on his joystick and moves the joystick towards the direction of the hoop. For the fender, it will set the platform angle, flywheel speed, and hood angle to the correct values to make the shot. No other adjustments have to be made for the fender shot because it is a relatively high percentage shot. For the key, our co-driver moves the joystick to the left, middle, or right to get the preset hood angle, platform angle, and flywheel speed. From that distance, the presets would only work if the driver perfectly lined up the robot to the left, right, or center. To compensate for any robot misalignment, our co-driver uses a video feed on the driver station with crosshairs to make the final adjustment to the platform angle. The hood angle and flywheel speed are taken care of by the code. Although our shooter is capable of shooting more quickly than we do in a competition, we have a limiter on the shoot button that detects when a shot is fired and pauses for 100ms to make sure the previous shot has cleared the rim.

The flywheel runs continuously at its last speed. Our flywheel is only set to two different speeds: one for the fender shots and one for the key shots. A PID control loop maintains the speed of the wheel as balls are shot. Additionally, the co-driver can incrementally increase or decrease flywheel speed. This feature was implemented in case the wheel speed sensor failed and we had to run open-loop.

[JamesTerm]

However, we were surprised to realize that we could shoot more quickly and accurately with crosshairs on the drivers station and a video feed.

Before I reply to this quote I wanted to thank you for everything written in this last post... it was very inspiring. :)

I am very surprised by this statement too, and I'm wondering if you feel that you have done everything possible to make the vision code as fast and efficient as possible. Also was the vision code processed on a PC based driver station, or in the cRIO?

I'd be curious to know how fast the vision detection could lock on to the target... as I've heard (and seen video) of other teams that could lock on to the target in real-time.

[LeelandS]

However, we were surprised to realize that we could shoot more quickly and accurately with crosshairs on the drivers station and a video feed. After we watched a regional in week one, we reassessed our shooting strategy and reduced the number of locations on the field that we felt were strategically advantageous and worked on those.



Wow... This surprises me. I knew of a handful of teams throughout the season who effectively used camera cross hairs. 1507, a shooter powerhouse at Finger Lakes, won the regional with those cross hairs. I believe I heard at one point 217 was using them as well, and 67 had borrowed the code for them for some time (thought this may be incorrect. Memory doesn't serve me well nowadays).

But I never expected 1717, one of, if not the, most precise shooters in the world, would use them. This really convinces me that you don't need complex systems to do well.

[Hjelstrom]

We have not been able to determine why our robot died in any of our matches. Our Robot died on Friday in Qualification Match 101 on red 1. On Saturday, our robot died in Quarter-Finals Matches 1 and 3 on red 1. Finally, our robot died in Semi-Final Match 1 on Red 3. We died on Red 3 and Red 1 so our original thinking about it only having to do with red 1 was ultimately disproven.

Have you looked at your driver station log files from those matches?

[smistthegreat]

Wow... This surprises me. I knew of a handful of teams throughout the season who effectively used camera cross hairs. 1507, a shooter powerhouse at Finger Lakes, won the regional with those cross hairs. I believe I heard at one point 217 was using them as well, and 67 had borrowed the code for them for some time (thought this may be incorrect. Memory doesn't serve me well nowadays).

But I never expected 1717, one of, if not the, most precise shooters in the world, would use them. This really convinces me that you don't need complex systems to do well.

Not trying to hijack the thread, but I just want to clear this up. We did not use crosshairs. We just had the straight camera feed that we used to line up.

Also, this thread is just full of awesome.

[Gdeaver]

Our team has done 4 wheel 360 rotation independent swerve also and loved looking at your drive at champs. Similar but different design. In the past we have used a least distance algorithm for steering. Sometimes it's quicker to rotate a short distance and reverse the drive motor. Do you do that in your code also? This year we eliminated the motor reversal part. We still check the shortest rotation direction. The bot seams to drive much smoother this year. How did your team handle the steering algorithm?
We do not have field centric control but are looking to add the gyro this coming year. In a match on average how long did the gyro go before errors added up to the point it affected driving? How many seconds before a zeroing was needed? Did you try any digital (I2C or SPI) gyro's or only analog?
One last question. What wheel angle sensor did you use. Do you feel it's accuracy and resolution are good enough or do you feel high resolution is needed. How many degrees of lash does the steering have. Our bansbot gear boxes have allot of lash. We haven't found another gear box solution that we can afford.

[Adam Freeman]

Wow... This surprises me. I knew of a handful of teams throughout the season who effectively used camera cross hairs. 1507, a shooter powerhouse at Finger Lakes, won the regional with those cross hairs. I believe I heard at one point 217 was using them as well, and 67 had borrowed the code for them for some time (thought this may be incorrect. Memory doesn't serve me well nowadays).

But I never expected 1717, one of, if not the, most precise shooters in the world, would use them. This really convinces me that you don't need complex systems to do well.

Leeland...you are correct. We switched to cross hair aiming at the Troy district and immediately saw a jump in our scoring numbers. It was worth approximately 2 balls/match.

Congratulations to 1717 on an incredible season. Easily the most accurate shooter this season.

[LeelandS]

Not trying to hijack the thread, but I just want to clear this up. We did not use crosshairs. We just had the straight camera feed that we used to line up.

Also, this thread is just full of awesome.

Gah. Sorry again Bryan. It seems most of the things I was told about 1507's robot were unconfirmed and not quite correct -_- I'm really sorry I keep getting the info about your robot mixed up.

[Garret]

It is a reflective photointerrupter with emitter and detector facing in the same direction. We have 16 black marks that are evenly spaced on the side of the flywheel to provide data for the detector.

Do you happen to know what part number that sensor is? I have been trying to find out what types of sensors are good but have no idea where to start looking for those sensors, let alone what ones are good/suitable for FRC.

[jakemochas]

As promised, here are several pictures of our swerve module. On this particular module, there is no turning sensor or wheel encoder, but the brackets that mount each one are present. As you can see in the photos, this module has a two speed coaxial shifting transmission for the drive and a single speed transmission to turn the modules. Nearly all of the parts were custom fabricated. All internal parts including our gears were made in our shop. The sheet metal box structure for the wheel module and transmission plates were made by one of our sponsors.
Enjoy!

http://www.chiefdelphi.com/media/img/ae1/ae18c8c13d9120ff8ebe9bd53d8c8fb0_l.jpg

http://www.chiefdelphi.com/media/img/4ff/4ff1c3a058048bdfdb2c0bd13a6d3087_l.jpg

http://www.chiefdelphi.com/media/img/47c/47c770bd83797f4e2d9fb835e1d66bd4_l.jpg

http://www.chiefdelphi.com/media/img/265/2652e2b830627a635e057ecb614b368a_l.jpg

http://www.chiefdelphi.com/media/img/c68/c68707c0934240c1d0cb3621f757dd0a_l.jpg

[jakemochas]

As promised, we have posted pictures of our wheel modules (they can be seen in recent images or you can search "1717 wheel module" on CD). On this particular module, there is no turning sensor or wheel encoder, but the brackets that mount each one are present. As you can see in the photos, this module has a two speed coaxial shifting transmission. Nearly all of the parts were custom fabricated. All internal parts including our gears were made in our shop. The sheet metal box structure for the wheel module and transmission plates were made by one of our sponsors.

To make sure everyone's questions get answered, I would appreciate it if all of the questions are posted in this thread.

Enjoy!
Jake
FRC Team 1717

[JamesTerm]

As promised, we have posted pictures of our wheel modules (they can be seen in recent images or you can search "1717 wheel module" on CD).
Enjoy!
Jake
FRC Team 1717

Thanks for the pics of wheel modules... sorry I missed your msg last month I sent you one recently. I'm having problems with CD notifies via email.

[jakemochas]

Why was it that you choose to use custom gears for the Rs-550 reduction over banebots planetary gearboxes? Was there any weight saving this way?

We are using Banebots RS-550's for our turning transmissions. We tried to use Banebots transmissions in the past for our swerve, but found them to be too unreliable for our liking.

Our turning transmissions have now run for hundreds of hours on our practice robot and there is no visible wear on the teflon/anodized coating. They have required no service other than the initial lubrication with dry grease. Our current turning transmission gear-train weighs less than a Banebots as well. Also, the backlash is a little better than the Banebots but not by much.

[gixxy]

Awesome.

I actually get to read "The New Cool" this summer for school!

[GRT808]

The gears with the smaller teeth in the swerve drive, are they 32 DP? Where did you get them from (you didn't make them yourselves did you, noticed the earlier post about gear making)? And do they come anodized or did the team anodize them themselves?

Also, for electrical, are those Anderson power connectors?

[42!]

Thanks for the answer. It really sheds some light on the design of the module. On another gear question, Does your team manufacture their own bevel gears? Or do you source them from someone else?

[msimon785]

Thanks for the answer. It really sheds some light on the design of the module. On another gear question, Does your team manufacture their own bevel gears? Or do you source them from someone else?

I believe in 2011, 1717 used MC #6529K14 (http://www.mcmaster.com/#6529K14). They of course finished the bore (hex) and cut down the face width to their needs. Not sure about this year or other years, though. They may have used something different.

[jakemochas]

I read in the "1717 Uncut" CD thread that a couple of thousand hours were invested in this design.


I'm confused how ten people could even spend 2000 hours working on a model during the build season and still have time to actually fabricate it, let alone design the rest of the robot. I mean, with school, homework, sleep, and my team's build space not being open, I wasn't even able to put in 200 hours over the course of the entire build season, and that includes time spent CADding at home.


I think the "2000 hours" is collectively over the course of the 4 year time period in which they started using swerve. It could be in one build season, but like you said it would be tough.

The wheel module design this year was completely new. The new motor allowance for this year allowed us to build independent swerve drive without sacrificing power for other mechanisms. We designed the module during this build season as rookie seniors. It took about 2000 man hours to both design and fabricate 10 wheel modules (4 for the official robot, 4 for the practice robot, and 2 spares). The fabrication process of the modules was quite time-consuming and tedious.

On average, we seniors put in about 500 hours during the robotics season. Some of us, including the programmers and drivers, exceeded 750 hours during the robotics season. We are able to dedicate this much time to robotics because we are in our second semester with a light course load. Also, we only get one opportunity to do this awesome competition so we are extremely excited and dedicated to building our robot!

[jakemochas]

I notice the wheel position sensor is not in the pictures. What sensor did you use.


Do you mean a sensor for the rotation of the module? I believe it is pictured in the black bracket in this picture

Looks like the sensor mount and a coupling but, what sensor was used. It does not appear that the timing belt pulleys are 1:1 so I'm guessing a quadrature encoder?


For turning, we keep track of our absolute position using a US Digital M4A. The sensor is setup 1:1 with the absolute wheel position. You can see the bent sheet metal bracket in Wheel Module Picture 3 to the front left.

For the drive, we are using an optical encoder that is attached to a small aluminum shaft. This shaft is directly coupled to the CIM motor and therefore one-to-one with the speed of the CIM. It keeps track of wheel rotations. You can see the flat mounting plate in Wheel Module Picture 4 right next to my thumb.

[Andrew Lawrence]

Sorry about resurrecting an old thread (albeit an awesome thread), but I've been thinking about the accuracy of this shooter for the past week. Aside from the crosshairs and software put into shooting, what mechanical advantages did it have? Like what mechanically did they do to their shooter along with the code to make it so darn accurate?

[JamesTerm]

Jake, (or anyone else for that matter)
I have a question about swerve drive... is it common to allow some degree of freedom of being able to align the wheels perfectly straight if you want to go straight? It seems like if you tighten your grip too much you may run into oscillation. Assuming there is some tolerance what would be a good metric for this (I think I remember reading 2 or 3 degrees somewhere elsewhere in the forum).

[jakemochas]

Hello Jake,
I was wondering where you got your pulley's from? How did you mount the pulley that turns the swerve module? From pictures is looks like a clamping style pulley.

cheers,
Mark Sheridan
3309 mentor

The pulleys are made from pulley stock purchased from Stock Drive. The clamp is a custom machined part that clamps onto a specially designed custom cut pulley that originally came from a length of pulley stock.

Sorry for the late responses. Thanks for all of your interest in our robot!