How about door #0? Go to every team at an event regardless of whether they’re in an alliance with you or not, and ask if they have an autonomous routine. If they don’t, offer to help them write one.
The end result of this is that your increase in ranking points would be slightly diluted as compared to only writing routines for your alliance members (assuming your opponents don’t write any routines for their partners.) I can’t assume that that caveat will hold true at all though.
End result? More motion in autonomous, more RP for everybody (but it turns from whoever happens to roll the dice on alliance members, to everybody who can consistently get a switch cube.)
Maybe this is just my Minnesotan speaking, but if you offer something to one person it would be rude not to offer it to another.
Scenario 1 is perfectly reasonable. We expect it to be a very common practice at every FRC competition this year.
Our software team has already invested quite a bit of time preparing to do this for all of our alliance partners.
I am pleased to see how many teams are already working on the Auto RP problem. I agree that it seems (on the surface, to a non-programmer) to be an easy fix. I do doubt, however, that we will see many week one or two events in which most or all teams have a move-in-auto routine. Not because I don’t think there are good intentions floating, but because sometimes things get overlooked in the days and weeks when we are so busy on our own machines, and because competitions themselves can be chaotic. I bet many of you have, at one time or another, sent out some of your best mechanics/programmers/electricians to roam the pits, seeking out teams in need of help, and had them hear only “no thanks”. Many teams would rather work out their issues on their own, and maybe that includes coding issues. Maybe not. I look forward to seeing what happens.
A little off topic. Some years ago our elimination alliance captain sent his programmer over to review our code. Turns out the programmer used labview and we programmed in Java. I politely told him he could look but not touch. :] We were not having code issues and they were not a powerhouse programmer team
More on topic. I would be cautious about adding untested code blocks under match conditions.Tested would on our robot with the module integrated into our code. You never know what unintended consequences small changes in code will have.
Also like the drive forward then back auto upgrade code idea. Good utility.
I absolutely agree here that doing so would be absurd. Everyone deserves to move in auto.
My personal experience doing cheesecakes with 1678 has been awesome(and often terribly stressful at times due to limited time to implement). Last year we cheesecaked a LOT of climbers and cheesecaking climbers was WAY harder than it sounds at face value. It took a lot of time to find a way to install them in a way that was structurally sound and didn’t impede their robot functions. So after all that work what we did was let the teams keep the cheesecake climbers on their robot for the rest of Quals and Elims if they made it, even if they would be going against us. If a team was going to go to another competition we would let them keep it if they wanted. If they had no further competitions that season we asked if they would be willing to give it back. If keeping a couple hundred bucks in parts on their bot would improve their season or their ability to demo in the offseason, why should we stand in the way of that experience?
Our 2014 cheesecake was an example of something that only gave limited game utility. It was just a bolt on pvc hoop that allowed a ball to be inbounded to their bot in such a way that we could drive up and intake it directly off of them. It helped when we were teamed up with them, but didn’t really give much benefit outside of that so we usually just installed it for the match we would be with them and take it off afterwards.
The important thing is making sure to be forward, fair, and clear with your plans and to think of how you can benefit them over the course of the competition with your plans. Cheesecake should be used to raise the floor and keep it there, not give it a brief hill to enjoy and be sad it’s now gone. If you are going to put in all that time helping a team, why wouldn’t you want to see them continue to do their best. I know I cheer way harder for the teams I help at competition when they do well than I do for 1678.
Are you asking from the point of view of the team that is donating the software?
My point of view: Don’t give anyone software that you would ever want them to delete.
For physical cheesecaking, I understand expecting the parts back, because that costs money for each set of parts you donate out, but software doesn’t cost anything extra to donate to a team (other than your time, but you would spend that time working with them regardless of if you want them to delete the code afterward or not).
I’m even against asking for physical cheesecake back. We added a climber to one of our alliance partners last year and gave them a rope. Without asking they took it off at the end of the event and brought it over to our pit. We turned around and said’ “Nope, that’s yours to keep.” They put it back on and used it through their next 2 events.
[They did however decide to give us the parts back after their last event]
Yeah I share that point of view for cheaper things. When you give something to another team, you should fully expect to not get it back. For full-cheesecake mechanisms, I could see some desire to actually get the parts back, though.
It doesn’t matter. Even if those were agreed upon terms, it’s not enforceable in the slightest. If you want to cheesecake, be prepared to not get anything back because at the end of the day, they don’t have to give you anything back.
Yeah, I would even consider giving back hardware (motors, etc of a cheesecaked robot) to be voluntary. Once its on that team’s robot it can be considered theirs. Most teams will give back hardware out of professional courtesy but it’s in no way obligatory.
I find this comment a bit funny considering the source.
If we want to stretch this to extremes, and that’s what I see in this comment, why stop their. Why not extend it to the JeVois code with Grip integration teams were able to do from the document you published. Or the same for the document and code 2073 published? Where do you draw the line??
No, scenario #1 is absolutely what helping other teams, and by extension your selves, is all about.
Scenario #2 is the complete opposite.
Not sure what you mean, or what you think I mean. Miscommunication?
I agree, helping is important. My question was directed at asking, do the stakes make it ok? If the said auton results in a victory for the cheesecaked team, does that inspire them more in the long run?
AFAIK it would be possible to make packaged code that the receiving team cannot see. My question isn’t aimed at theorizing an actual situation, but rather probing what the qualities are that make cheesecaking ok or not ok.
Wouldn’t a time delay be better and potentially easier? Robot xx1 does fancy maneuver while alliance partner sits and waits for it to pass. Having it against the switch to end auto is better because 50% of the time it can score first thing in telleop.
Also I have met teams who we have tried to help program simple drive straight autos in the past and they do not wish to accept the help. They may not want it or would rather spend the time focusing on another aspect of the robot. Some teams do not want outside influence. It may be frustrating but these teams will exist.