I’m in the process of building a database of highly effective mechanisms and robots for my team to look back on for inspiration in the future. I’ve rummaged around chief delphi and am a little surprised at the lack of a thread about the technical aspects of the building and testing of turrets. I’m wondering if teams who have made turrets previously would like to give an overview (and hopefully some of the details) of how you go about deciding when turrets are necessary, and what your process is or was for building them.
Turrets are surprisingly common considering how complicated they must be to build and control, I hope having teams who’ve experienced building them share their experiences will help teams who don’t know here to start.
Dig around for 987 (The High Rollers) documentation. They have a history of building great turrets. Their 2016 machine was glorious, much to Pridetronics’ joy.
Tim
Being a on a third year team and this year being our first time ever shooting high (super impressed with the students), the hardest thing we found was vision targeting really. The only other issue I can think of is what most teams probably had. Which was getting the right speed for shooting at different distances. At every competition we had to keep working on our speeds. Loved our turret, not sure if we would have preformed as well as we did without it. If the game is right we may revisit a turret.
The reason we went with it is because we originally had multiple positions to shoot from on the field. (ended up we only used 2 spots) In my own opinion as stated above by Andrew, we didn’t have to rely on having the drivetrain lined up perfectly for aiming.
First off, I am on Team 3309’s Chairman’s Team and not too involved on the building process. Because of this, I’m just going to respond to your question about how we went about deciding on a turreted shooter.
For the 2016 and 2017 FRC games, knowing how to play the 4 RP system is essential to ranking high. If you want to do well at your events, you need to build a robot that can guarantee RP on its own which begets the 2 RP bonus for winning.
Team 3309’s 2017 robot was geared towards both the shooting and gear aspects of STEAMworks because, without being proficient in either, we would not seed well. With this in mind, we decided very early on to have a shooter that could get 40 kPa in autonomous to leave us all the time left in tele-op to focus on gears. A turret is vital to this strategy because it allows us to shoot from multiple positions, minimize complex line-up/auto pathing situations, and shoot under defense in our matches.
While we were only ever able to get 40 kPa in autonomous just once (on Hopper field, red alliance), we found that our robot was able to at least get that 40 kPa RP in most of our matches starting in LA (our second regional). This single RP, when attained in each of our qual matches, gave us a major boost in the rankings because most teams would only have either 2 RP in a match or 0 RP depending on their match schedule (2 RP for winning, 0 for losing, but none for getting 12 gears/40 kPa). In a sense, our robot could seed well without entirely relying on a good match schedule.
This is mostly how we were able to seed 2nd on Hopper field while only having a 6-4-0 record. In each qualification match on Hopper, whether we won or lost, we had at least 1 RP for reaching the shooting objective.
TL;DR - We went with a turret because it made the 40 kPa objective easier to achieve in qual matches which helped us rank higher and perform better.
Team 254’s Technical Binder from 2016 should have some information about how they built their turret. Hopefully this helps, as it was incredibly successful.
Firstly, it’s really not that hard to use a drivetrain to rotate a robot! If your team can’t handle this, you probably can’t handle a turret. Why make life harder for yourself?
The actual mechanism of putting a ball shooter on a turret, and powering the turret, is indeed pretty easy. There’s really nothing exotic or difficult about it. The challenge though is, depending on the game, it can be far more difficult to tune a ball shooter to work with a turret than a stationary shooter. Many turrets will shoot differently at different angles, depending on how the ball is fed into the shooter. This varies greatly depending on a number of factors - degree of compliance in the game piece, spin on the ball as it is being loaded, how centered the shooter is within the turret, trajectory of the ball into the goal, etc. These are not hangups to brush away and figure out in integration.
You’ll see in 2012 lots of teams that did go with turrets (33, 177, etc) actually put a large chunk of the ball elevator on the turret as well. This was because the 2012 game piece was particularly hard to accurately shoot with a turret at arbitrary angles. If you can design a mechanism like this, it may help with repeatability.
Whoa, back the truck up! It is waaay harder to tune a PID/motion profile to use the robot as the turret, that is if you want it to be fast to target and consistent to a gnats behind. Sorry Chris, but I’d argue that to the end of time. In order to get both the Stronghold and the Steamworks robot to azimuth to target in less than 1 second was extremely hard. There is also the issue that if you’re up against a wall, you’re done.
On the other hand, your point about a turret screwing up ball entry is spot on. At least that’s what we’ve experienced with the Stronghold design (and that wasn’t even a turret). To what I think your point was, watch out for the hidden issues with a turret. It’s not just the turret mechanism you need to get pass.
While this is true, it’s difficult to use this as a method of aiming when defense is constantly bashing you enough to change your shot angle / position, and in some situations like this year, the wall is too close to provide an effective arc to shoot balls in at a high enough throughput. Games such as 2012 are an excellent example of your point, where shooting against the fender was a great strategy and huge advantage to many non-turreted teams (though most turreted teams abused to privilege of not requiring precise lineup).
I think you two are both right. It’s a difficult problem but you are either shifting the difficulty between software or hardware. Turning a skid steer chassis is a hard software problem because tuning has to take a LOT of things into account. Turrets are a harder mechanical solution because of feed problems.
Like many problems in FRC, you can solve them mechanically or programmatically.[1]
[1] Marshall, however, likes to solve them by throwing sensors at the problem… literally, throwing them. I’m not sure which this falls under.