![]() |
Re: 4 inches vs. 1 foot
Does your advisor have physical evidence to back his/her opinion up?
Or does he/she not feel you have the capability to do the 12" ramp? Something doesn't seem right from my point of view. I don't mind your advisor disagreeing, but he/she should encourage your ideas and help you make them a reality. Our team decided to go with a mecanum drive this year, and many engineers said to us that it will be a great challenge. They never said "Don't do it". Quote:
|
Re: 4 inches vs. 1 foot
I agree with Arefin & Evan, doing one or two things really well and consistently is far better than doing a lot of things inconsistently.
Of course, the key is to anticipate what will "win" the "game". For example, in last year's game, a team that could score well enough to win autonomous (almost every time) AND climb the ramp consistently did not really have to do much of anything else to win the game. Sure, you needed someone who could score a little, and sometimes you lost from a technical issue, a weak alliance, or a strong alliance opposing - but 80% of the time, your alliance won. Don |
Re: 4 inches vs. 1 foot
A four inch ramp would work great during qualification matches because you are paired with a diverse group of robots that have varied drive train abilities. The four inch ramp would obviously be easier to attain peak upon if it maintains the same amount of run. A twelve inch ramp would be a more attractive choice for the teams choosing alliances because their robot would most likely have a drive train with the torque and grip to make it up twelve inches in elevation. Obviosly a twelve inch peak on the ramps would be a more attractive choice over a four inch peak due the fifteen more attainable bonus points which should come in handy during eliminations.
|
Re: 4 inches vs. 1 foot
Quote:
Another key attribute is what else your robot can do. If it is an outstanding defensive robot and/or has a strong drive train and chassis, then that will help make that bot better. You mentioned that your robot would have an arm that would be okay. If your arm can score even a few times that will be huge for a ramp bot. I agree with you when you said that a robot that can elevate other robots 12 inches off the ground is better than 4 inches. If you feel strongly about this then tell your mentor and see if they can incorporate it. Mentors are supposed to help and be open to student opinions. I am interested about what you will decide to do so let me know what happens (and eventually how you do at competition), so PM me if you want. Good Luck!:D |
Re: 4 inches vs. 1 foot
I think it would be a good choice for a alli bot cuz as long as the team picking you has an arm they could score the points while you may defend them and at the end of the match hop on your bot and score the extra points. So, most deffinently.:D
|
Re: 4 inches vs. 1 foot
Our robot will be three wheel driven, with the 8'' IFI wheels.
We will be able to climb ramp which is either 4 or 12'' tall. Our mentors told us that we would be more successful if we built a 2-ramp robot. We voted and decided not to have a ramp. You should build a robot which you are proud of, and that you want to build, not necessarily what your mentors think is best. All the best, Mike (1701) |
Re: 4 inches vs. 1 foot
My gut feeling is that if you have 4" ramps then that's fine, but be sure that you can also climb ramps as well! If you are paired with a robot with a clever 12" lift, you ought to be able to make it up or you'll be wasting points.
|
Re: 4 inches vs. 1 foot
I met with a local rookie team today and noticed they too are building a ramp, but their robot had no clearance to climb a ramp. This seems to be a bit worrisome to me. I think that ramp bots will be common this year, but not all of them will get the job done consistently. I'd choose and ally with a 4" ramp that was roomy and sturdy and consistent than a 12" ramper that is questionable. Getting far in the championship rounds is all about consistent scoring. And for the love of pete, make sure your robot can climb a ramp in case an alliance member has a better ramp!
|
Re: 4 inches vs. 1 foot
i believe that both types of ramp would be advantagous but as was said before a 12 inch ramp allows another alliance partner to continue to hang tubes while getting the same amount of points as two 4 inch ramps
|
Re: 4 inches vs. 1 foot
This is how we handle this kind of situation:
At the start of each season, we always have our team define from three to five design goals for the robot, and arrange them in priority order. (The robot must accomplish task #1 before tackling task #2, etc...) Our mentors are a part of the brainstorming process, but only the students vote on the goals. Mentors may override/veto a goal due to physical impossibility (nope, no levitating robots again this year, darn...), or lack of resources to accomplish it (no money, time, tools, space, insufficient programmers available, etc), but our Mentors' primary job is really to facilitate the students (via training, advice, etc.) to allow them to build the robot of their choice. Next: The method by which the goals are accomplished is totally under control of the sub-group that is responsible for doing it! Example: our goals imply that the drivetrain has to achieve certain performance requirements, but only the Drivetrain group determines HOW that'll be done. Same for the Manipulation ("Payload") group, etc... This prevents one group (or even a majority of the team) from telling another to do something this way, then walk away leaving a small group of students (and their mentor[s]) holding the bag. As long as the machine accomplishes its goals, it's all good! Had we found ourselves in your situation, we'd let the subgroup decide on a new method to accomplish it (wings vs ramps vs bot top, etc). If that's the top priority, then be we'd shift resources (from everything else if need be) to help them solve it, so we didn't have to abandon the goal. BTW... Our robot's volume is negotiated as we go along, but most subgroups have very specific "volumes of control" and hardpoints established early on, as soon as they figure out HOW they're going to accomplish their task(s). If a subgroup later must impinge on another's volume area or change a hardpoint, those two subgroups need to talk it out. Here's how this year worked for us (so far): We brainstormed the day after kickoff. The students created five goals, and sorted them by priority. This list was then quickly ratified by a general consensus of the student body the following day at a general meeting. That meant we had our guideline goals and priorities established within two-three days after kickoff! Now we had no clue of HOW to accomplish any of it at that point, but we firmly knew WHAT we wished to do! Then, the subgroups all started making their design decisions, and met with whatever other student subteam leaders as need be, to work out gory details. Status: As of today, Goals #1 and #2 are definitely being accomplished by our machine. #3 was abandoned when testing proved it wasn't a good idea after all, and we determined by the end of week 3 that we'd be out of weight allowance way before we can accomplish #5, so we're not even wasting any more time on it. #4 may still be a possibility, but it's so doubtful at this point we're not worrying about it anymore, and students have already been moved from it to more pressing tasks. So... Even though we may end up with a machine that'll only do our top couple of items, those two are so strong the students are very satisfied with the machine we're creating. NONE of our goals needed to be modified in any way. Now Mentors often had to point at the goal priority list when things started to drift or disagreements arose, but that guideline was a fantastic aid to focus our attention, and efforts. It allowed the students to quickly (and peacefully!) resolve conflicts amongst themselves, because they set the priority list in the first place! (Variants of "Oh yea, I forgot that was our first goal" etc... was heard.) Once established, if someone wishes to CHANGE those goals, it had to be done via agreement by EVERYONE. That typically doesn't happen. The Methods often change, but the goals themselves don't change. Now, all that said, let's address your situation... IMHO it's really late in the build to be completely changing your strategy! Would four inches be your ONLY goal left? If not, and you haven't done it yet, please consider prioritizing *all* of your goals, asap! The biggest problem I often see (without priorities being set) is you tend to end up with "kitchen sink bots" that do nothing well, because groups of students are all working on different things, and no one has a clue until the very end what will be on the bot. OR, people end up fighting at the END of the build as to what is going onto the bot when they've run out of resources (weight, money, space, the ability to accomplish some task, etc...) because there was no GUIDE established. Also, because the order of what they should be working on things was never established, you end up in a situation where a lot of subteam time was wasted (or hurt feelings arose because their idea wasn't used). Or, the robot completely transformed after all of their work was done because someone had to step in and change something major to make sure the robot is "deliverable". That is a shame, and can even tear a team apart. Is this your case now? So, my question really becomes: Is going for 4" what the students wish to do now as their top priority? Was lifting (one bot? two bots?) 12" your highest priority, or is (was) something else your highest priority, like "manipulating ringers & spoilers", or "climbing upon another bot"? If for example "manipulating the ringers and spoilers well, at the top level" was your #1, AND you've accomplished it, I wouldn't really sweat the 4" vs 12" thing at all! OTOH, if this is the ONLY thing you're doing, then I'd really wonder if there isn't a way to still accomplish the 12" with whatever you have on hand, by shifting resources. Bottom line: IMO, you need to let your student established priorities decide what the bot should do, whatever that may be. Unless that is physically impossible, I'd hope that your mentors can be convinced to strive hard to support your goals. But this is just my $0.02... Don't get me wrong, teams work very well with many other organizational configurations. Many use "competing design mini-teams", "centralized design with CAD and simulation first", and other methods. All are perfectly valid methods to approach this contest. However, this is just how we avoid the entire "NOW what'll we do" dilemma late in the build when something goes horribly wrong. Whenever we run out of something, we simply just drop as many of the lower priority tasks as we have to, to allow us to shift resources (weight, student manpower, money, etc.) to focus on the higher priority goals! Our organizational method allows student subgroups the autonomy to decide on methodology, and to explore alternatives at will, without stopping everyone to involve them in making decisions on things they won't be held responsible to accomplish. This seems to work for us. Does this discussion of our methodology help you at all? - Keith McClary Chief Engineer, Team 1502 "Technical Difficulties" |
| All times are GMT -5. The time now is 22:33. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi