Collaborations and Alliances

[davidthefat]

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(isRunning){
}

use

if(isRunning == true)
{
}

[Jack Jones]

Yes I am thinking about it.

Beware the sound of one hand clapping.

[Vikesrock]

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.

[apalrd]

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.

Originally Posted by davidthefat

...not a big fan if

if(isRunning){
}

use

if(isRunning == true)
{
}

[Chris27]

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.

if(somePtr = NULL) { ... }
else { 
  somePtr->someField = someValue;
}

I assume this is what you meant apalrd?

[apalrd]

yes, this is what I meant. There will not be a runtime error, but a bug, which is probably harder to track down then the compile error.

[Chris is me]

Originally Posted by davidthefat

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.

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.

[Tom Bottiglieri]

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.

[Chris Hibner]

Originally Posted by Chris27

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) { ... }

I'm sooooo sorry to drag this thread off topic.

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.

[JesseK]

Originally Posted by davidthefat

if(isRunning){
}

use

if(isRunning == true)
{
}

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:

(Java code)

//Initialize CORBA References
org.omg.ORB orb = initCorbaReferences();

//Initialize the display
mDisplay.init();

Food for thought.

[ttldomination]

Originally Posted by Tom Bottiglieri

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.

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?

Thanks in advance,
Sunny

[David Brinza]

Originally Posted by davidthefat

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.

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).

[Andrew Y.]

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.

[Racer26]

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).

[Elliot191]

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.