Big Minibots

[Mike Betts]

Originally Posted by theprgramerdude

If it's burning out halfway up the pole, it's safe to say they didn't engineer the thing - they just built it and prayed it would work. Complete burnout's like that would occur because the motor is operating in a red zone on the power curve, something that could have easily been avoided had analysis been done on the machine.

Hey... My team used the micro-switches also... But to call someone ignorant or lacking in a science background because they build a big minibot is just wrong...

The same logic, being "competitive", that permits switches to fail applies to allowing motors to burn up... That is assuming that all of you self righteous "engineers" actually considered the consequences of your actions... There are teams who "guessed" at the motor torque curves and others who used switches that "seem" to work... Is one engineering oversight less important than the other?

I prefer to think that any team who fielded a working minibot and delivery system should be praised and not looked down upon because they took a different path to the solution...

This can't be what FIRST is about...

I hope I have made my point and I will post no more on this subject.

[theprgramerdude]

My team used the switches also; I have to say that they work great, at least for the time being. I just wish that their application required them to be a bit more robust; we've already broken a few by crushing them.

Mike, a working minibot is a working minibot. No one reasonably doubts that that is a good thing to achieve. However, I think the point that people are trying to make, which may be confusing/rude some due to it's harsh language, is that it can be improved to be better at the goal it's trying to achieve. FIRST isn't about teaching kids to do it once, and then be done.

[boomergeek]

Any team that first worked on their own to try to design a minibot, understand the physics and math and the engineering specifications and then built it and experimented and refined it- has done great engineering instruction.- It's quite commendable and appropriate to spend long hours brainstorming and experimenting free from the din of other teams ideas.

In real engineering, when is not appropriate to understand the approaches of your competitors? In real engineering, customers don't want engineering teams that can just copy: they want a team that create ideas and throw away ideas and sometimes learn and improve from what they see from competitors. If you are heavily inspired from some other team's work, then spend the time to understand the physics and spend considerable time to improve on it versus just copying it.

We were not impressed by the reliability of the gearboxes: especially using the hubs directly on the wheels: after only a few times up the pole using about 10 lbs of normal force, the wobble seemed obvious that the gearboxes would not last a season's worth of stressful pole climbing.
The gearbox sounded inefficient and the speed of our pole climbs were approximately the same as those shown in the Kickoff video.
We saw smoke and lost a motor/gearbox that first week after we got the kit.
We lost a second motor on our bigger minibot (4.4 lbs) that uses the motor/gearbox after we got back from our first Regional.

It was partly the quest for reliability that led us to simplify and get rid of the gearbox. Less weight means less stress on the motors. Dynamometer results posted here on CD helped.

Is it good engineering not to network and know how good the competition is?

Because of the cross fertilization of ideas between teams, the robots at week 8 of competitions can be much stronger than those at the first week.
The question is: what should your team do with this wealth of information and ideas for solving the challenge? Should your team ignore it? Should your team understand how fast the competition is but not how?

These are not necessarily easy questions to answer.

Any mentor/volunteer willing to spend time and energy facilitating any of the physics lessons, the engineering design, the fabrication, or the testing, etc. is helping students immeasurably.

Many teams end up spending TOO much time redesigning their robot and school work or other aspects of life suffer. The key is balance and mutual respect.

Big ; little ; can't we all just get along?

[MrForbes]

We have a kind of medium sized minibot. I was not involved in designing/building it, we have a new mentor who took this on with several students. I think I would have done more research into how to eliminate or at least modify the Tetrix gearboxes, but the design we have did end up working well and won us a few matches. We had some depolyment issues during the heat of competition (the elimination rounds were really heated, compared to qualifying) and we also had a problem with the minibot where it didn't go up the pole all the way. We did find the loose nut that caused it, after a few failed attempts. The looks on the faces of the two young students who fixed it, and got us that win....just priceless....

[Jin Hayashi]

In terms of physics, we would have loved to have made a lighter minibot with a better gear ratio. In terms of practicality,we worked on the KISS principle. KISS won over physics for us.

Our reason for making a big minibot was due to lack of experience and lack of shop resources.

Our team didn't have any experience with FTC before the kickoff. The minibot was built by a student who joined our team three weeks after kickoff and a parent who was a first year FLL mentor. Our minibot used the NXT, due to the mentor's knowledge of NXT programming and its sensors.

We are also working out of the garage of one of our mentors. We had to budget our usage of power tools for building the hostbot and minibot. Which limited the amount of tool time for the minibot team for making it faster.

I was amazed and pleased that we got a minibot working with the amount of experience and resources the two had before shipdate. Although we lost many minibot races with other teams, it was satisfying just to successfully launch the minibot.

[wilsonmw04]

Originally Posted by squirrel

The looks on the faces of the two young students who fixed it, and got us that win....just priceless....

That, Sir, is what this is all about. :-)

[Captaindan]

our mini bot is about medium size but the difference with ours compared to others at the bayou regional was that ours was deployed and went up 100% of the time and in the final round which our alliance was victorious it was literally the minibots that won the match had a great time at the regional hope to see the same teams and more next year seems like the mini bot slamming against the pole and not doing anything was a constant result for many teams

[PAR_WIG1350]

What I am beginning to see here is diversity not only in minibot size preference, but also in reasoning. Some people decided on small minibots for simplicity or reliability, and some people chose larger minibots for the same reasons. The motives might have been budget, durability, speed, or "because this is what we know how to do," but it doesn't really matter all that much in the end. Teams are settling into their comfort zones. Teams chose to build their minibots as big or as small as they are because that is what the individual team has found to work best for them. It fits their unique needs and priorities of the team most effectively for the resources and know how available. That is the answer to the OP's question.

Quod erat faciendummaybe...

[AndrewN]

At regionals: any minibot large or small is better than none.

A reliable minibot that will last the whole regional is better than one that fails every 2nd match.

It's rare to see a match where all 4 minibots are deployed let alone reach the top of the pole. Reliability matters more than speed (at regionals).

Early Friday Seattle, it was clear having a working minibot & deployment system was a match winner. Late Friday it was becoming clear that a "good" hanger robot was better than a minibot.

At championships, it'll be different - everyone will have working minibots, everyone will have working robot manipulators.