I know that the Kick off strategies are different for each team due to size and resources and because we have a relatively small team, each of us tend to wear several hats as we scramble through the build season…
What I am curious about is what your team focused on first or in parallel once the kick off occurs and you know what the challenge is…
Our first year, we didn’t know much and we focues on the chassis first which took a long time and we were left with the impression that we should have focused on how to score first…
Our second year, we focused on how to score first and found that we should have spent more time focusing on the manipulators…
This year during the off season we are trying to learn as much as we can but are left with the impression that we should focus on manipulators first…
So what works best for other teams and is there a right thing to focus on first for those teams that can not do it all at once?
Your feedback is appreciated and good luck in the upcoming competition.
In my opinion and in my team the manipulator and drivetrain are both important and should be worked on at the same time, we even have a different STL for each of them. Now if it is a rough terrain game, or a speed game, the drivetrain will probably be a bit more imortant. Unlike Aim High where you could stand still and still shoot.
Focus on your drivetrain first. If you can’t drive, you can’t compete. Even if all you can do is drive, you can always be a useful contributor to an alliance.
Your immediate task following kickoff will be to focus on game strategy. What will be the most important thing you can do in the game? Will you be able to design a robot to do that, or do you need to begin making compromises? What kind of payoff will you get from what you design? Is the payoff from auto mode (whatever we get this year) worth the effort of programming it? Do you go for the highest point scoring mechanism, or is a lower-scoring robot what you will be making?
You might come up with a good solid design that can get a consistent number of points. Or an iffy design that if it works will get you a lot of points, but if it doesn’t work instead of a slick robot you’ll have a very expensive boat anchor on your hands.
I’ll try to keep this short, but it will come from a top down perspective so it might get a little long.
You asked about a Kick off strategy. So here is where I would start.
Determine what your team is capable of doing, know your strengths and weaknesses.
Now that you know your limitations, remember them so you don’t try to do something way out of your reach. Don’t be afraid to stretch, but be realistic.
List all the ways scoring is possible in the game presented.
If defensive action is possible in the game, consider ways to do that as well.
Determine your teams “Game Strategy”. How do you want to reliable contribute to your teams alliances. Scoring, defending, both?
Remember what you determined in steps 1 and 2. Now, apply that to step 5 to figure out what to build.
Prioritize the basic portions of the robot’s build to find what has the highest need to be completed first. As an example, as Cory mentioned, if you can’t drive, you can’t score. (Or can you??) Being a “small” team, you may not be able to do all things in parallel.
Make all these determinations with steps 1 and 2 in mind.
This is just day one. These things should be completed ASAP after Kickoff as possible. This will allow you to move forward with some good, basic direction.
This is just a suggestion: What every you decide to do, make sure it is reliable. Can it score reliably, drive reliable, defend reliably, not break easily? You will be much more successful with a robot that does one thing reliably than a robot that does multiple things unreliably.
I know this is a very short and limited list. I **do not **expect it to apply to all teams. It is based on my years of experience with small teams with limited resources. Your mileage will vary.
If you are concentrating a lot of time and effort on your drive train I cannot suggest the IFI Kitbot chassis enough. I know 397 used it this year and it worked really well. Instead of focusing on a fancy chassis we were able to make our robot launch the ball. This is basically me saying, don’t reinvent the wheel, if the kitbot will meet your needs then by all means use it and save yourself the risk of having a drive train that fails on the field.
If you have the necessary resources, focusing on drivetrain concepts, ideas, and a prototype can save you a lot of headaches during build season. CD has a lot of ideas in various threads already.
The ideas can take just as much time as building them.
I’d rather spend most of the time thinking about the z-axis function/manipulator during the 6 weeks, among the other million things we have to do.
You will get a very wide set of answers depending on how old the teams are that are answering.
For instance, most well established teams have a playbook that they draw from that already has a wide chassis, a narrow chassis, plus the trannies and drivetrains to run each.
Those teams will immediately focus on overall game strategy, which should take no more than a couple of hours to talk through, and then how best to start designing their manipulator. Likewise, those same teams will already have a well developed autonomous program that is reasonably quick for them to implement.
In many instances the “ideal” manipulator will drive your chassis design.
If I could conjecture a bit: some people have suggested that the game may radically change this year. I think perhaps they’re right (crosses fingers). I think that when teams can start selling pre-built chassis, it’s a pretty fair bet that the game design is in a rut.
To wrap it up:
Determine a strategy using rough engineering guesses ( torques from the motors, engery calculations, etc). Estimate the power required for the tasks, since the one true limitation we have is motors. That strategy should determine the direction you’ll take for the game. Then decide if your manipulator will need to drive the chassis direction, or if you can develop them in parallel. Then break into teams and get to work!
In my 2 years with FRC, I have noticed that it is almost impossible for about more than 3 people to work together on one “thing”. It just won’t work.
So, first, my team takes ~1 week to go through and try to come up with designs. After that, the people who have the know how to build the designs go and work on the manipulators with a team or 3-4 people. This way, we can test ~3 designs at a time.
Meanwhile, we have an another group of people who work on the chassis, and the chassis alone. At this rate, the chassis is up and running in ~2 weeks, and by them, most of the manipulators design have either been ruled out, or are having their final touches made.
This method works the best for our team. Multitasking is key for FRC, and you should definitely not focus on one core part and the leave the others to hang.
Tom, there is a difference between selling pre-built chassis and selling the optimal chassis for the game. I view it as helping out teams so they don’t need to focus on that. How many teams have I watched as the struggled to move with a chassis they made themselves. Moving should (in most cases) be second on anyone’s list. My generalized list would be:
-Develop strategy (auton and tele-op)
-Moving chassis
-Prototype manipulators
-Wired chassis (for programmers to start doing auton with and drivers to practice with)
-Prototype some more manipulators
-Decide on manipulator
-Build manipulator
-Mount manipulator
-Soft stops (if necessary)
-Drive practice
-Auton
I think it shows why I support teams who use pre-built chassis. If you have the resources to build a stair climbing swerve drive that is AWESOME, but I have seen too many teams struggle to move not to understand that not all teams have that sort of ability.
That being said, Tom does bring up some good points, if you see you will need 2 CIM motors in your manipulator then your drive train would need to be modified so always keep that in mind.
The first thing is to decide what you want the field to look like at the end of the match. Do this for both autonomous and teleop. It can actually take several days to figure this out, depending on the subtlety of the game.
Then start working on how you are going to make the field look that way. Now you can start thinking about how will you manipulate the field objects to achieve your goals. Start with all sorts of ideas and narrow them down. Figuring out how much power is required to accomplish a certain task is one way to eliminate the really unpractical ideas.
Use the Kitbot or an old robot to prototype your best ideas. Experiment with how well your chosen design works in real life. Do you grab that Trackball firmly and easily or do you spend your time chasing it around the field trying to catch it?
Once you have a prototype that works well, go design your real robot. The build goes much faster when you know what your robot will look like before you start.
The BeachBots typically don’t start building our real robot until sometime during week 3. In '05 we didn’t cut metal until 4 weeks after Kickoff and didn’t make a final decision on our drive concept until week 5. (We were carrying two concepts and the frame was designed to accomodate both)
By the time we start building we have a running prototype that our drivers can practice with and our programmers can use to debug the code, but it probably would not pass inspection. It almost certainly violates the “must be fabricated this year” rules. That is OK, it will probably never leave the shop, at least not until the off-season. As “real” parts are built we make 2 and incorporate improvements into the prototype bot. This way, when the real one ships it has an older brother left behind. Then our drivers go and wear out the tires on the practice robot.
Thanks for the compliment Andy. Don’t get me wrong - I think what you’re doing is awesome - giving people access to an absolute top of the line chassis is great. The kitbot was one step in that direction, and what you’re doing is the next step for teams who are missing the time, technology, or manpower to do it all.
I just think that looking back over the last 4-5 years, the drivetrains are starting to look remarkably similar - and the bots are beginning to reflect that with more commonized parts. Even if the new game was to simply halve the allowed robot footprint, it would push innovation to begin again. But I’m getting off-course from the original topic.
With regards to Chris’s post - this is the first year we’re purposefully setting up to have a couple chassis “ready” for the kickoff day. We should already be programming the movement portion of autonomous within a couple hours of kickoff - even if the base we have is the wrong size at least we’ll have the program written to move the actual one.
If you made it I am not 100% sure that is allowed. Also, I know it has been said time and time again but it is still true, do not lock yourself in to one chassis until you know the game. There are games that a 6 wheel drive robot works great, some games where Mecanum works better. Until you know the game you should not decide on one way of playing it.
Oh, we won’t be using it for any sort of competition. It’s the chassis we are putting together to learn the early control system. Using it to set up the initial programs after kickoff is legal. Many many teams use the previous year’s bot to do the same. This is the first year we’ll have a working bot to start playing with :).
Know your team strengths and weaknesses. Play to those strengths!! I’d encourage our team to pick just a couple of new technologies/techniques to add to the robot each year.
Also remember, you don’t have to do it all to be competitive. Last year, we saw several robots at each regional that had a great, simple drive system (as Cory emphasized the importance of already!) coupled with an incredible auto mode. I think back how quickly our team could’ve put together a driving robot and then spend weeks practicing and programming it. We probably would’ve done a bit better than we did. Instead we spent weeks on a riduculusly large manipulator and did just average. (But it is fun to watch a big robot lift a big ball really high)
Back to Cory’s point about the importance of driving. For a bit of reflection, there was a time when it would take teams weeks to get a driving robot together. Hmm, how do we use this drill motor to drive a robot? With the addition of the kit chassis and gearboxes, it is now a rarety to find teams that can’t drive. But it doesn’t take away from the importance of having a RELIABLE drive system - our drive chain failed at SAC last year in a match and then couldn’t get fixed for the next match. Two big losses like that and it really took us out of contention, and moreover, who wants to pick a robot as an alliance partner if they can’t RELIABLY drive. The CONSISTENT scoring robots will always make it on a alliance if they aren’t choosing one themselves.
I guess I’ll throw in another key objective to shoot for… Finish the bot the week before it ships! Use that last week to program tweak and PRACTICE. I know some teams like the ?(fill in your favorite)? can throw together a robot in Week 5 or 6 because they have a fully operational prototype and resources, but the majority of us can’t pull that off. So I tell our team they really just have 5 weeks to get this done. We have used this objective since 2005 and our performance at regionals has drastically increased.
So keep those points in mind as your team decides what to tackle this season - what can you do to ensure that it will it be RELIABLE and a CONSISTENT scorer?