Looking at the 1619 reveal (https://www.youtube.com/watch?v=9TeZc5jDEdE&feature=youtu.be) and the 1678 robot (https://www.youtube.com/watch?v=qoP7XocwR-M) feels like looking at twins, though I’m pretty sure they didn’t really collaborate. I know that design convergence is real, so what’s on my mind is the spindexer concept and how it has developed. Seems like it has worked well enough for these two top teams, though I’ve also seen it abandoned by others, and utilized poorly elsewhere. If it fails, it seems like it would be hard to install a different system onto the same robot to replace it. Do y’all think it is a good choice? How do you think it will play out throughout the season? If it does fail, will this be the first real test of the new bagless opportunity to make a complete new robot for each competition?
1690 Seems to be making it work very well. I Personally think it is one of the best options. You are constantly ready to shoot and it can have a very fast unload time. Also pocketing it the way they are keeps each ball spread out evenly throughout the air and will help balls keep from hitting each other in the goal. All in all I think it is a very good route to go if you can.
Spindexers are finnicky and take time to pull off.
As a team that is just finishing up now (and we’re playing week 2 and hosting a week 1!), a spindexer was Not The Move™ for us this year. In my experience, they are difficult to maintain, and hard to get right in the first place - prone to lots of jams and stuck game pieces.
There are plenty of hopper designs that provide fast, evenly spaced indexing without needing a spindexer (95’s hopper comes to mind immediately).
I agree it would take time to get it to work correctly and to keep it from jamming 100%.
We abandoned a spindexer early, and I’m regretting it a little bit, even though our current solution is working fine. We even had a pretty good prototype of one early on, and we abandoned it because it just looked too silly.
At our local scrimmage, there was a spindexer team (167) that was probably one of the best robots there. I think they’ll do well this year, as will other teams with the spindexer concept that essentially scaled up the most effective Steamworks indexers. Of course, a spindexer by itself isn’t an automatic win, there’s still a lot of other things to go into shooting and intaking, but they certainly seem like the move for this year’s game.
If this were always the criteria, then 1678 would not exist. I do get your point, though. My team always considers the aesthetics
That might not have been the right phrasing, but it just didn’t look like a solution that was truly going to work. It was weirdly underconstrained and hard to visualize the packaging.
Yeah I know what you meant. I just took the opportunity to make a slight joke, because my team really does always ask “how good does this look”. It’s not the best approach but it’s part of our heritage.
1102 used a spindexer in 2017 but it wasn’t as good as 125/971s. This year we went that way again in part because the same student that designed the first one is now the lead engineering student on our team. They are definitely interesting devices, but if anything I don’t think if our ours fails to work well enough we would pivot completely away from it… we will just adjust it based on what were are learning about how other team’s designs are working in ways ours doesn’t.
Ours is most similar to 1690s version, but not exactly. We don’t have any problems at all with feeding the balls into our shooter, but getting the balls to sit how we want as we intake them and quickly for that matter… can be more challenging.
The spindexer / dye rotor-esque indexing system was one we initially wrote off as too difficult and outside of our resource range on day 1. We were probably right, but seeing Citrus’ robot still had us kicking ourselves because of how simple and how effective it seemed. I’m sure a lot went into making it just perfect, but I would not be surprised if teams with the ability to iterate started adopting similar systems over the course of the season.
EDIT: Kicking ourselves much less hearing from Tom that it looks easier than it is. 1678 just makes it look effortless.
There are definitely different variations of the spindexer in terms of from where and what angle the ball exits, so there is the design flexibility to integrate it into an existing robot design (to a certain extent of course).
We have a spindexer which looks very similar to 1678’s. It was slightly troublesome at week 0 (also having been only assembled the night before and incomplete), but has improved a lot in the last week or so. There are a few jamming edge cases (though most of them can either undone or at the very least prevented if caught soon enough which is nice) and we have some redesigns in mind to address them. The biggest question we’re facing is the dividers vs no dividers question and working out the pros and cons of each. Hopefully some more testing will make that decision more clear. I personally was not a fan of the cyclone at first (mostly due to packaging issues) but after having driven it around for a week or so and working out a lot of the kinks, I’d say I’m very happy with it.
I’ve found that generally, whether it’s spindexer or something else depends on if you’re looking at a tall bot or short bot. With a short bot you don’t have to transfer from the spindexer to the shooter, while with a tall bot you do. This fact helped drive our design to something that wasn’t a spindexer.
It worked decently, but we abandoned it because it would have taken up too much of our robot space for what we wanted to do with the rest of the design.
Plus, we know how a large, central hopper usually means electronics are hidden under it, and really hard to get to for maintenance. I don’t envy that.
Anticipating this early on due to the nature of the game, we opted to make our electronics accessible from underneath the robot. It was probably not entirely necessary given the design we ended up going with, but doing this preemptively gave us the flexibility to make design decisions without worrying about how accessible the electronics would be.
We have our “revolver” on a hinge so that we can access the electronics
We settled on the “Spindexer” early on. We realized it would be difficult, but the benefits out weigh the effort needed to make it right.
We are now up to 25+ iterations and refinements. But it now functions exceptionally well.
Funny story: Citrus was in our shop around week 3 of build. They were picking up some field carpet we share because of Capital City Classic. Our version of the spindexer was out and running on a prototyping setup. The very first thing Harvey walked up to and started asking us about was the spindexer. At that time it was at about 15 iterations deep. He slightly tipped his hand that they were leaning in that direction as well.
Here is a slow motion of our system with the spindexer feeding the shooter. The actual shot series is under 3 seconds long. We probably can go faster, but only time and testing will tell for sure.
By the way, we named our Spindexer Lance.
Circular indexers are popular for many reasons this year. It’s easy to fit 5 balls into one, they solve the many-to-one problem, they create a consistent feed point, they allow for human loading and a simplified / robust intake mechanism.
That said, they are hard, and a lot of nuances go into making them work correctly. Geometry, material selection, the use of dividers (or lack thereof), depth, etc. all are important and come into play. I would certainly not try to make a mid-season change from a different mechanism to a circular indexer without recognizing how it will take weeks of iteration to get the kind of performance you’ll see from top teams.
This is a good example of “Looks easy, is hard”.