We are headed to Oklahoma Regional and Central Missouri this year with S.A.M. (Simply Awesome Machine).
Interesting, this is the first side by side shooter I’ve seen so far. How are your shots looking in terms of bounce out?
We haven’t had chance to test on a realistic hub. Just didn’t quite get around to building something that can compare with it. So I can’t yet answer that.
I think we will adjust our shot selection as much as we can to avoid that if it is noticeable an issue. We’ve thought that we’ve take more fender than longer shots and the speed is pretty low so I think it will be alright for that shot.
We’ve not went without a number of trial and errors with the shooter. While I do like the pneumatic loader in terms of I think more consistently feed speeds into the shooter wheels compared one that we had with solely a feed wheel in 2020, where it feed the first ball slightly slower, we have iterated through loading issues mostly to make sure it gets consistently to the right place. But also handling the potential variety of cargo, particularly the overinflated and egg shaped cargo.
Early in testing we did have backspin if the cargo contacted the front shooter surface, and so we added a strip of tribo tape and some fudge (bump-ons) to assist better consistency in loading.
We do have a little side spin. It doesn’t veer significantly from the tarmac shot, but is probably something to address better in code. We do have that sysid for the flywheels and code to change to that, but hadn’t yet implemented it. So how that is received on a real hub will be interesting for our shots.
A novel design to be sure. With your shooter so low are you worried about shots being blocked by a defender?
Short answer is yes.
Longer answer is that they liked the close shot, so moving to an open fender is necessary for that anyhow, so it already protected, although the angle is very steep (85 degrees or slightly less iirc). But we can hopefully make use of some tarmac shots when useful too. Convincing for longer shots involved showing how much more was possible in auto.
Also, I think it would be flattering in this game for us to face a defender. Frustrating I’m sure, but it probably figured less in our design choices for those reasons. We’ll see how those thoughts play out.
I’d note also that post-intake it all slopes down and the shooter is gravity fed. So that also plays into the shooter placement. It was the design student’s preferred this year. I think each year it is a challenge to do more with more complex robots and software, and the lead group pretty much wanted to finish as quickly as possible with as little complexity as they could add for practice and testing. I think they built the shooter in week 2 this season in 2-3 days, which they wanted more than taking a couple weeks to design and build a shooter/elevator combo. I do miss the advantages you get with more mechanically designed system that controls the game piece the entire path, but I’d say that was the approach this season.
That may well have been the right choice.
We basically had the robot functional around a month ago. Though it has also changed a bit since then.
Our mentoring this year has been more advisory in that students are more self-directed, even testing and figuring out what problems there are in the design and making fixes they want. We seem to less often point to potential design problems but check in when they are trying to figure out something to offer suggested causes and let them work it out.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.