Team 2145 is going to try to develop a software module in LABVIEW that we can quickly deploy to a team on our alliance that may not have an autonomous. We’d actually like to have a few modules but our first would be getting a robot without autonomous to unload its balls for robots on its alliance to pick up and shoot. Then, the robot would go tip the ramp down, so the balls on the ramp would be on our alliance side when teleop starts (we are unsure whether or not touching the ramp is allowed in autonomous, if not please tell us). We’re not a very experienced programming team, so we thought we would share it so a team with more experience might get started first, if they like the idea.
Touching the ramp during autonomous is in fact legal and probably will be our strategy. But you can only touch your alliance’s ramp and never the other alliance’s. You can even go on your ramp and stay there during autonomous. Just be sure to never touch the other side of the carpet.
Can you touch the cooperatition ramp and get the balls from there?
No rules against it, so yes.
-How do you know what their robot will be capable of?
-How do you know what their sensors will be like?
-How do you know if they’re capable of handling balls, and if so how will you handle robot-specific configurations of ball handlers?
-How do you know if they’re capable of lowering the ramp, and if so how will you know how to handle robot-specific configurations of ball handlers?
-How do you know that they develop in LabVIEW?
-How do you know that they will let you do this?
The only time I ever wrote autonomous software for another team during a competition was 2010, when we programmed our partner to block the tunnel against 469. That took a solid block of time of me working with them on the practice field to develop and tune a basic time-based program which moved their (mecanum) robot in two steps, and that was a very easy target (they had to get the corner of their robot into the tunnel, while sitting a foot or two away, with a very large margin for error).
I will say it’s not possible. Too many variables, not enough time on their robot.
IMHO, not worth it. What if the team you assisted ends up going against you in the elimination? They will use that trick against you. You essentially shot yourself in the foot.
All valid concerns. I’m the coach of 2145, using my student’s id. And if you are not interested in the idea, we understand, don’t help. Thanks for you input.
Mrs. Webster
Lake Fenton High School
I never like hearing attitudes like this. So selfish…
Assisting another team is not supposed to be for your own good, but for everyone’s. If all teams shared this opinion you wouldn’t have teams sharing knowledge or collaberating, not to mention a community which strives to assist each other like the one that exists here on chief (or FIRST on the whole).
I understand it’s a competition, but that doesn’t mean you go around not helping other teams because it “might” help you down the road.
For what it’s worth, I wouldn’t really try this particular situation either, but more for fealisibility issues listed above than anything.
Valid concern, but I interpreted the plan as “let’s give this team the code so our alliance will have an advantage for the beginning of the match”. I merely stated that because in the long run, that plan will bite them in the butt. But if this was truly for pure altruistic purposes, I am sorry for being cynical.
I think it sounds like a great idea, but I have to agree that it would be incredibly complicated in order to work with even the majority of bots. You would have better luck just working with them to design their own, it would benefit you in the compitition and teaches them how to program on their own!
It’s called coopertition. Ever hear of it? It’s supposed to be especially intense this year with the bridges.
I don’t see how this can be done reliably or universally. If everyone used the same drive vms - maybe. Perhaps for teams that use the default software and skid/steer drive (like the kit bot) and it drives reliably, it may work now and then. It is more likely to go where you don’t intend - you might end up playing defence against your own bot! I would counsel against things like this (that can’t be tested), engineers generally avoid technical risks of unknown scope.
HTH
This is precisely the thing a lot of teams do already, as they should, by helping other teams with repairs, coding issues, or any other robot work throughout the competition. If this were a concern, none of this constructive cooperation would be going on, at all. I applaud the OP’s idea for being very much in the spirit of FIRST.
However, I agree that as some have stated, it will be difficult to get something that will interface with any robot and work in a reasonable amount of time.
This was the purpose of 1153’s Echo code (obviously not this specific purpose since we didn’t know the game, but the general idea of getting the other teams to do something).
It bypasses the difficulty of determining what the other team’s controls are by allowing the teams to directly control their robot, and repeat these actions in autonomous.
Simply set up the modules (the paper estimates 30-45 minutes for a new programmer by him or herself, but it would be more like 5-10 minutes with an experienced programmer who knows the process already), create a name for each step, tell the team to do whatever it is for that step, repeat for all other steps in that autonomous, and then set up the overall autonomous mode by entering filenames. You should be ready to go in 20-30 minutes.
Its obviously not going to be as accurate as an autonomous mode that was carefully planned and debugged over several weeks, with sensors, but its something and certainly better than sitting there doing nothing.