Hello,
We are rookie team from israel and we relly need help.
So we are asking from you, the experienced teams, to help us.
We will be very grateful if you will give us some tips or share your strategy with us.
Thank you for your help,
Team #4725, GeDarkanator.
Here is 1014’s working strategy document right now. This is what we are using to guide our design process at this point.
Working Strategy for 1014 Robot Design
We will make a robot which can score in the 2/3 goals in autonomous and teleop. (Which means it can be reloaded somehow. Possibly at the loading station. Possibly by picking up. Hopefully both.)
We will be able to execute a 10 point climb quickly.
We will be able to push other robots and/or resist being pushed.
We will be able to pick up frisbees from the floor.
Our potential human players will practice throwing for 5 (and 2) point goals.
We will also have people continue to work on climbing higher than 30 inches. If such as system is developed we will try to implement it. Such designs have to be consistent with the robot as we design it.
We will work on robot control/operation so that the robot functions well autonomously and we are able to drive it well in competition. A well driven “good robot” is generally superior to a poorly drive “excellent robot.”
What are your thoughts on the game?
Have you read any of the threads on game strategy and mechanism design this year?
What sort of building capabilities do you have?
Has your team built a robot before?
The CD is generally very willing to give advice, but you’re not giving us much to work with!
Our main strategy differs from shooting and focuses in hanging:
Our first priority is to climb to the third level every game.
Our next objective is to be able to put the colored discs into the pyramid goal while we are up on the third level
A. This requires our robot to be able to hold discs
B. Move around the field
C. And unload the discs somehow
After this is to complete autonomous as well as we can
Then comes our human players, our team is based in a town where ultimate frisbee has turned into a competitive league with a couple hundred participants, on our team alone we have 5 players who have amazing accuracy and consistancy with throwing frisbees
My recommendations:
Keep it simple but effective. Most Isreal teams only play 1 event, so it tends to play like a Week 1 event with relatively lower scores (compared to week 4-6 which typically have teams that are on their second events and score a lot of points). There are dozens of ways to score points. Make sure you figure out how to score some points repeatedly and reliably. A lot of teams will overreach and end up with a machine that does not historically score well if at all.
OPR is kind of similar to a calculated average team contribution. While there were robots last year that could score 24-30 points in Auton, a top 10 robot in the early weeks (or Isreal) would be a robot that consistantly balanced the bridge for 10 Points. There are many other simple and effective ways to score this year similar to balancing the bridge last year.
Check the links below to get an idea for what kind of scores you might be up against. Note those are alliance scores (3 robots on the field).
For your first year (or two or three), I would recommend the kit chassis, but if it only came with 2 CIMS, spring for the extra motors and go to 4 CIMS. Try to get this together soon so your programers can get a chance to work with it while you work on the other mechanisms.
I agree with James CH95. We really need to know more about your team.
What are your resources? This includes number of team members, engineering support, resources for having parts machined etc. These are huge factors in your design.
What strategy does your team feel will be most important in this game? You need to choose one that the majority of your team can support and successfully design a robot to complete.
There are significant advantages to a ‘utility’ robot for a rookie team with limited resources so don’t throw that option out the window yet.
Let us know more and maybe we can be more helpful…;)******
yes we read some threads and we will continue to read more.
and as we said we are rookies so we havent build a robot before.
we will be very happy if you will find a way to help us. if u have more qustion you want be to answer i will be here.
thank you for youre help.
team #4725
How many students are on your team and how much engineering support do you have?
we are 20-25 students in the team. we some engineering support but not alot of it.
thank you very much for youre help.
team #4725, israel
Did you guys do any training pre-kickoff or just jump right in? Either way here are some incredibly helpful resources
Miss Daisy Team in a Box - http://www.team341.com/tiab/
NEMO is an acronym for Non-Engineering Mentor Organization
NEMO - www.firstnemo.org/PDF/FRC_Resources.ppt
NEMO - http://www.firstnemo.org/resources.htm
The Green Machine - http://www.edinarobotics.com/resources
Really take a look at the above sites. They are full of outstanding information not just about team organization and administration but also about build season and competitions.
Hope this helps and like IKE said…keep it simple. :yikes:
With a new team and not a lot of engineering support you want to make sure you do not over commit by attempting too much. For example, it sounds like you are building a robot that climbs (possibly above the first level) shoots, and picks up Frisbees both from the feeding stations and the floor. That is a lot to try for given your experience and resources. I am not saying do not try for that if your team wants to. Just have some fall back plans.
Perhaps work on only accepting disks from the feeding station for now, and consider picking disks up from the floor later if you have more time and resources. The most common mistake teams make is not being realistic about what can be accomplished during the two week build build period.
You heard me correctly, the build time for a robot ideally (in my opinion) is only two weeks. One week gets consumed in strategy, design, and possibly acquiring any specialized components. Then you need to finish the building in time to leave one or two weeks for integration, programming, debug, possible retrofits to correct issues, and driver practice. If you build a robot that does less, but is completed early enough to allow extensive testing, debug and practice, you will be much better off that if you build one that does everything you wanted, but is finished on the last day of build season and not fully debugged.
Your plan to climb sounds a lot like what one of the ideas we are looking at does.
Our climbing robot design has a central channel for driving up one of the pyramid polls, and a bucket on the end of an arm for dumping disks into the scoring basket at the top.
If you don’t have a lot of engineering support I would focus on getting a robot that can move around, and possibly adding some way of dumping / shooting disks. If you can get that working, then look to hang on the bottom rung of the pyramid which I think for many will be the default.
Check out teh “robot in three days” thread to see what they were able to put together pretty quickly.
Also, don’t get discouraged, read the manuals for each part of the robot. There are resources like the “FIRST electronics test bench setup manual” that will get you to the point of having a chassis that can drive around.
You may also want to look at the pneumatics manual to see how to get pistons working.
Hope this helps
Edoga
Also, try to find another team near you and contact them. Even if you can only speak by telephone, I am sure they will try to help you.
Maybe if they are not so far, they can visit you, or you can visit them.
Good luck, and please keep asking more specific questions. We want to help.