![]() |
pic: Here is our final primary design.
|
Re: pic: Here is our final primary design.
Why did you limit your stacks to 4 high?
|
Re: pic: Here is our final primary design.
I really like the idea of having totes slide through the robot. I will have to present this idea to my team.
|
Re: pic: Here is our final primary design.
Quote:
https://www.youtube.com/watch?v=9QmJ...nCuJv3aKb8Os0G |
Re: pic: Here is our final primary design.
Quote:
|
Re: pic: Here is our final primary design.
Quote:
FRC teams are fantastic at overestimating what they can do in a given game-- something which hurts them come competition. Excellent design is driven by excellent constraints-- striking a balance between defining the right project constraints and leaving enough room for creativity can be huge for keeping team directed to building an effective robot. |
Re: pic: Here is our final primary design.
Quote:
|
Re: pic: Here is our final primary design.
Quote:
Their design seems capable of stacking higher so it was a question of why they chose 4 over 3 or 5 or 6 or whatever. |
Re: pic: Here is our final primary design.
Quote:
You are totally correct in that those stack combos would yield the same points, however, we're looking at scoring efficiency here. If you look at the game from that perspective, as you're really just battling the clock in this game, and if you didn't use any containers, the stack height wouldn't matter at all, apart from the increase in trip time. Once you do factor in the containers, a non-linear increase in points-per-second is found if you look at creating and topping off stacks of different heights. Factor in the can scarcity with the difficulty of topping off a taller stack with a container and the challenge quickly deviates from simply 'stack as high as you can' |
Re: pic: Here is our final primary design.
I really like this design, from an 'overall' perspective. It fixes several issues with a single-orientation human-player-fed lift. It also looks to keep c.g. in check when lifting 3 totes high enough for a 4th tote to to slide down the ramp underneath it. Those totes don't stand a chance!
I applaud your choice to do a 4-stack. A 5-stack is definitely cool, but I agree with others who've stated that capping a 5-stack is tough - probably not doable by the average team on a consistent basis, when compared to what else the average team could be doing to create points. You may also have a nice setup to add a passive guide system for a noodle into a RC. You're already at the right place to get a noodle, and I can't imagine a noodle guide would be terribly complex or interfere with the lift. That may be another avenue to investigate once this bot is built. |
Re: pic: Here is our final primary design.
Quote:
Assuming they have a partner who can score bins the optimization objective becomes to build the tallest possible stack that can be capped by that partner since you reduce travel time for yourself, but fewer taller stacks reduces time for your partner. So my original question was "why 4 " because it's a weird number to optimize for. If their plan was to just score on totes then a larger number, maybe even > 6 might be optimum. If their plan is to have a partner cap then 6 is optimum. Just curious as to what led them to that decision. |
Re: pic: Here is our final primary design.
Quote:
|
Re: pic: Here is our final primary design.
Quote:
We can pick up upright containers using the same ram them into the wall method as the 3 day Indiana build. The idea would be that we, pick one up, go to feeder station, build stack of 4 under it, drive to scoring platform drop off, go get next container...repeat. |
Re: pic: Here is our final primary design.
Quote:
|
Re: pic: Here is our final primary design.
I'm certain that the game will come down to the cans at the high level, maybe even at elims at regionals. If you "waste" cans by using them on 4-5 tote stacks, you are dependent on either the clock running out too fast for everybody or on the inefficiency of other teams to get cans. If you have good can grabbers, then it makes sense to make shorter stacks as time becomes the limiting factor.
JMO though. The real test will be when competitions actually begin. |
Re: pic: Here is our final primary design.
Love the simplicity of this design, you can probably get away with only 2 vertical members and A framing it properly, but I suspect the 4 vertical members makes the track easier to build and less susceptible to binding. I'm a big fan of fast human player loading, its going to be the fastest way to build stacks. I'll bet most regionals can be won by just stacking all the HP Totes and placing a couple bins.
|
Re: pic: Here is our final primary design.
We think you are the perfect robot!!!
Good strategy, keep it up. Hope to join up with you at Champs. |
Re: pic: Here is our final primary design.
Quote:
Quote:
Even though we have a "bottom stacker", we've tried to make our design as tall as possible, with the idea that if it should prove too unstable during driver practice (or early rounds), we can tone it down, while we can not exceed the design at the last minute. As long as we have RCs available, we currently expect to make a 4 or 5 tote stack, score it, then add one or two totes on top with an RC (and possibly litter) to score the big points. Unless you've come up with some whiz-bang way to stabilize the stack (and especially the RC), trying to "bottom stack" six totes with an RC on top while staying under 78" sounds like an exercise in futility. |
Re: pic: Here is our final primary design.
Quote:
Our robot is not made to win a regional on its own. we may try that in future years. |
Re: pic: Here is our final primary design.
Quote:
Carrying a full stack with speed might require an additional actuator depending on the setup - so I expect to see teams switching from precarious 6 stacks to manageable 3 or 4 stacks. |
Re: pic: Here is our final primary design.
well i guess well see you out there (;
|
| All times are GMT -5. The time now is 22:58. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi