Do any of you teams out there do collaborations with teams close by? Like having an under the table deal saying if any of you go to finals or something the others follow? Or even literally building the robots all together, using each other’s resources and collaborate. I want to may be collaborate with the 2 close by schools, you know who you guys are… Yes I am thinking about it.
I am totally down to do this, but I am afraid of Back stabbing and stuff like that. Honestly if the other school’s programmers have no idea what they are talking about I can not deal with, that happens in my group already so eh… not a big fan if
If someone has an under the table deal I have a feeling they wouldn’t be posting about it on a public forum. Having said that, I don’t really think these types of arrangements exist. If a team wants to be competitive they have to objectively evaluate the best robots at that specific competition when making their pick lists. Past interactions should only be moving teams around small amounts unless they are particularly egregious negatives.
With regards to building collaboration, their are many teams with arrangements like this. Some collaborating teams build the same robot (254+968, 494+70, 148+217 this year). Some collaborating teams merely share ideas, shop space or resources, I am confidant more of these collaborations exist, but they get less attention. Team IFI is one example of this type of collaboration, the teams share ideas and sometimes discuss things with each other, but do not necessarily build the same robot. A member of that collaboration may be able to address the details much better.
This year my team worked in the shop of our rookie mentee 3130. We did some discussion about the game together, however we did not extensively collaborate on design or manufacturing of our robots despite sharing a shop. Next year we are hoping to increase the level of collaboration between our two teams and also the other Woodbury team 3206. Among other things we are talking about more extensive sharing of prototyping successes and failures and a design review with all three teams to verify design concepts.
It is common to collaborate during build season and not past. We have shared crab-designs in the past, and built crab pods with other teams in their shop, but thats it.
Also:
Your first example is perfectly correct. There is no reason to not like it. It is simpler to write if(isRunning) or if(!isRunning) then if(true == isRunning) or if(false == isRunning). If you choose to compare to true, then at least put the constant first. If you make a mistake with the ==, you will end up with a compile error instead of a runtime error (and compile errors are easier to find then runtime errors). Just a habit to get into. I understand the desire to put the { on the next line, it does make things neater. The topic of C/C++ should go on a different thread.
As a CS student at CMU, I’ve always been told that
if(isSomeCondition == true) { ... }
is horrible style, and this really should be written as
if(isSomeCondition) { ... }
if(isSomeCondition = true)
Is “correct” syntax and by itself will not cause a run time error. However this will cause your program to behave incorrectly (for instance the if statement will always evaluate to true) which could definitely lead to a run time error if e.g.
2791 has done “talking collaboration” extensively for both of its years of existence. Our team’s founding mentor also started 1726 and was briefly a mentor on 842, so he and others on the team keep in regular contact. These are both teams that are extremely open about their design process, so it’s less helpful than you’d think but being able to have some really cool people to call is very nice. We’ve yet to actively build twins with either of them, though, but I guess it could be possible.
We are also an EWCP member, but the extent of EWCP collaboration so far has been basically the same “talking collaboration” as the other teams. I know that could change for 2011 though, particularly with one team…
I’m generally of the mindset that “natural” collaboration is ideal. Talking collaboration facilitates this really well; you can share ideas and concepts early on and if you have similar priorities, you can then decide to do partial or full collaboration. For example, 2791 was considering a 6 motor gearbox for awhile, and other EWCP teams were ready to fabricate this for us since they had similar drivetrains. I hope this is more extensive in the future; this would have been really useful for stuff like ball possession…
As for “pre-alliances”, I don’t ever set an alliance in stone and never plan to, but I am much more likely to push for my team to pick a friend or collabrative partner than a team we have no history with, simply because the insurance of good alliance chemistry is so vital to success. I don’t think any of the actions above are “underhanded”, though. We’re very open and proud of our collaboration and we do it for the benefit of the students on both teams.
254 and 968 have had identical robots every year since 2006.
The manufacturing is split between both teams. Every motor and sensor is wired exactly the same, and code is 100% shared. The binaries that run on 254’s robot will also run on 968’s.
Completing a collaboration effort is not an easy task. It takes tons of effort and years of engineering experience to really do it correctly. Believe me, the last thing you would be worried about if you undertook this effort is the syntax of conditional statements in C.
Anyway, coding style is vastly open to many opinions, and you’ll find that the “preferred” method changes about as often as the direction of the wind.
The reason I quoted this is because the CMU-defined “horrible style” is required by my current employer. “if (isSomeCondition)” is against the coding standard where I work (but I prefer to do it that way in my own software outside of work).
I guess my point is that anything anyone tells you about software, take it with a grain of salt. One man’s trash is another man’s treasure, and that applies to software as well.
At the end of the day, it’s still 1 SLOC and 1 operation. This line isn’t even a code smell. If such an example is a reason to not cooperate with another team then you seriously should intrinsically think about whether or not your team is capable of forgiving another team’s nuances enough to cooperate to begin with (i.e., it’s your problem and not the other team’s…).
In the real world, if you make the mistake of bad ‘style’ other programmers will let you know. Yet upper management tends to not care because it really doesn’t effect performance. So long as your company has some sort of code review process ‘style’ tends to work itself out over the long term, so it’s not even a matter of increased development or maintenance for a set of code. Essentially, this is like arguing whether the ‘//’ comments line for line are better than block /* */ comments for readability. The reality, it’s the words within the contents that matter – most of the time programmers want to know why something is necessary rather than:
If you don’t mind, could you please elaborate on how this level of collaboration began?
Were the two teams different, and then they began to work together? Were you guys mentoring that team? Did the two mentors began talking? Did you guys try a partial collaboration in your first year, or was it full-blown right away?
Collaborations are not uncommon. Collaborations may or may not involve common robots designs, agreements to pick each other in alliance selections, building in the same facility, etc. Collaborations might work out very well or perhaps not so well. Before teams jump into a tight collaboration, it’s important to understand each others’ expectations.
Team 980 has successfully collaborated with Team 4 (2006) and Team 2404 (2008-present). We discussed the possibility of collaboration with Clark Magnet in 2007 (when we had no build space), but their school policy wouldn’t allow outside students to work on the campus. Given the open desire for “coopertition” by FIRST, collaborations are quite consistent with the program. You might even want to talk to us too (yeah, I know we’re NOT one of the two close-by schools you’re thinking about).
i would say to the we kinda sorta do this. Yes we relatively have a better relationship with the teams in our area, so we know their name therefore i think its more likely that we would pick them ASLONG AS there robot is performing and fits well with our robot. I PROMISES before competition is a bad idea IMHO.
I can remember back in 2006 when 1114, 1503, and 1680 all had identical robots, 1114 chose 1503 every single time (becoming the 2nd and 3rd teams in history to win 3 regionals in the same year). After that, 1114 went their own way, and 1503/1680 built identical robots in 2007, before going separate ways in 2008, and 1680’s demise in 2009. Since 2007, at the Canadian regionals, 1114 has chosen 2056 (with the exception of 2009 WAT [1114 didn’t attend, 2056 seeded #1 and chose 2609], and 2007 GTR when 2056 seeded #1 and chose 1114.) How much of that is because they were objectively the best choice, and how much stems from their NiagaraFIRST relationships, I’m not sure. The 1114/2056 pair seems to have preferentially chosen other NiagaraFIRST bots for their 3rd partner when opportunity arises and other factors are more or less equal (2166 at GTR 2008 comes to mind), but they’ve also chosen partners they’ve won with before (2185 at WAT+GTR 2009).
It’s only truly feasible to do this if it is between two teams, because it will be guaranteed, if the robots are good, that they will be able to form an alliance.With three teams, one would have to purposely sink themselves in qualifying matches, which isn’t really fair to their random partners.
Our teams “collaborate” to a certain extent. There are three teams in our area and we share a practice field and have held a mid-build-season scrimmage. At the scrimmage our head programmer ran around to help people out, and we obviously shared tools and zip ties.
But we don’t do deals. If a team makes it to the finals they do it because they earned it.
For example, this year both Alpha+ and the Teraviks made it to regional finals, but they did it on their own steam, ended up on separate alliances, and did not choose us to join them. Which is a-okay in my book!
At least one time in 08, 2056 seeded 1st, I don’t remember where.
But consider that possibly their relationship via NiagaraFIRST actually makes them a better partner. If you had the option between your best friends and some team you haven’t played with in a long time, and you KNOW you have great chemistry with your best friend, I’d be more than willing to overlook being slightly worse in terms of robot performance. Of course, 2056 has consistently had the second best (or in 2009, arguably the best) robot in Canada, but don’t discount the friend pick.
Collaboration is easy to certain extents and hard to others. My team has never formally been an active member of a collaboration project, but we’ve done chats and such sharing ideas with some other teams, both local and over the Internet.
collaboration is a cool topic. I find that sharing ideas is a easy, but very helpful to both sides. Once you get into helping manufacture parts or even building twins it gets complicated, especially over long distances. This, however, can be a great learning point and especially very fun. I find collaboration projects really fun and always look forward to opportunities to help, receive help and just work with other teams in general.
I don’t konw what the purpose of this thread creation is, but I would more than encourage you to talk to other teams both local and far away and see if any of them are interested in collaboration. It’s really a great thing to do, it’s fun, and typically beneficail to both sides.
We found out quickly that even just a simple sharing and debating of ideas can be rather frustrating at times as well. Make sure the entire team (both yours and the collab partner’s) is willing to listen and implement proposed ideas from both sides, otherwise things will not work out as you intended. Yet another thing you learn very quickly.
As for the “go to finals or something the others follow” portion I’m going to agree with Vikesrock with:
If a team wants to be competitive they have to objectively evaluate the best robots at that specific competition when making their pick lists.
because no matter how awesome you think yours and your collaboration partner(s?)'s robots are you will never be able to predict what the other teams at your event will bring out to play.
Your fear of backstabbing and the like all comes with the decisions that will be made if and when one of the teams is an alliance seed captain. Do you pick the team you promised to put on your alliance way-back-when or do you pick this really-zomg-super-awesome robot that would totally help you win the event? What would YOU do? When it comes down to it, I personally am not a supporter of the “we’ll pick you guys if we seed” deal during BUILD. But by all means if you guys roll out into your regional with the next triplets and on Saturday decide that your partner is the “1503” to your “1114” in GTR 06 by all means pick them, but the precompetition deciding is… sketchy and will most probably put your team in a unfavorable position.
Yes I am thinking about it.
but being able to have some really cool people to call is very nice. We’ve yet to actively build twins with either of them, though, but I guess it could be possible.