why blame the programmers??

[Chris is me]

The programmers are the last people to touch the robot and because the mechanical teams drop the ball, they have extremely little test time. That's why programmers get blamed all the time.

[Nick Lawrence]

Originally Posted by Chris is me

The programmers are the last people to touch the robot and because the mechanical teams drop the ball, they have extremely little test time. That's why programmers get blamed all the time.

So true.

SOLUTION: Build a practice bot.

-Nick

[Akash Rastogi]

Originally Posted by Nick Lawrence

So true.

SOLUTION: Build a practice bot.

-Nick

Practice bots get stuff done.

True fact.

[Andrew Schreiber]

Originally Posted by Chris is me

The programmers are the last people to touch the robot and because the mechanical teams drop the ball, they have extremely little test time. That's why programmers get blamed all the time.

Thems fighting words Chris.

No, really the reason is because programming is not always understood. My standard debugging practice: Reproduce the error 2 times in the pit, mech/elec check sensors/motors while prog checks the code for those inputs.

Programmers, the LAST thing you should do is say it isn't the code.

[Uberbots]

They blame the programmers because, sadly, most of the time is is the software. Furthermore, when a problem arises that could be fixed in either software or hardware, typically it is simpler (depending on the programmer) to just rewrite a couple lines of code.

Also, the programmer should be by no means the last one to test their product. Throughout the design process of the robot the programmers should have access to a simple prototyping system to at least verify if the code runs, and hopefully use some of the outputs of the test system to determine at least valid output. By the time the mechanical team (finally) finishes their part, all the software team should have to do is tune a few parameters or change a couple lines.

In my opinion if you don't have running code by the time the robot is ready for it, or you have a broken interface (e.g. programmers say left motor is pwm01, but electrical says its pwm03) then your design process is broke.

obviously how far along the code is when the robot is ready varies from team to team, but there is no excuse for having untested or incompatible code at that point.

[rsisk]

If blame is being passed around, then the person doing the blaming probably has no idea what the problem is, otherwise they would be pointing out what the problem is and getting it fixed.

Therefore, it doesn't matter if the programmer is getting the blame because by my definition above, the person doing the blaming is ignorant and should be ignored anyway.

[ideasrule]

Originally Posted by Andrew Schreiber

Thems fighting words Chris.

No, really the reason is because programming is not always understood. My standard debugging practice: Reproduce the error 2 times in the pit, mech/elec check sensors/motors while prog checks the code for those inputs.

Programmers, the LAST thing you should do is say it isn't the code.

I've said a few times that I was sure the problem wasn't the code. Every time, it turned out not to be in the code. A programmer should at least be able to tell if something definitely ISN'T a code issue, when it definitely IS a code issue, and when he should keep quiet because the cause isn't certain.

[cpeister]

We had a driving chassis this year to test code on. It was a 6WD where our competition robot had 4, but it still worked reasonably well to test drive code. When it came to programming the attachment, we had to write hypothetical code and test how well it worked by attaching servos and limit switches and encoders to the test robot, and running the drive motors in place of the attachment motors. We were able to do some testing, but never had a complete robot before ship. Afterwards, our arm was completely redesigned and included in our withholding allowance.

We still had many errors that were blamed on programming, some of which were our fault, but many weren't I guess we are first to blame because they don't know exactly what our code is doing, and because they can't see any obvious problems with the mechanical or electrical. My favourite error of the year, we had next to nothing working on the robot, except for one servo that ran when a jag should have. Programming was blamed immediately, but it turned out that the sidecars were plugged into the wrong ports, so the command for 4,6 was going to 6,6.

[Andrew Schreiber]

Originally Posted by ideasrule

I've said a few times that I was sure the problem wasn't the code. Every time, it turned out not to be in the code. A programmer should at least be able to tell if something definitely ISN'T a code issue, when it definitely IS a code issue, and when he should keep quiet because the cause isn't certain.

The programmer should not rule out a code issue in any circumstances that they cannot back up that with definitive proof. No, "Because I wrote it" is not proof.

[delsaner]

Originally Posted by Chris is me

The programmers are the last people to touch the robot and because the mechanical teams drop the ball, they have extremely little test time. That's why programmers get blamed all the time.

Even when our robot is shipped, the programmers still meet to work on codes and autonomous modes. There the last ones to touch the robot, which is the legitimate reason. (The fun reason varies with each team you talk to, IF they have a fun reason to blame them )

[wireties]

Because the mechanical guys always finish late and give electrical and software guys the last 3 days to make it magically work o.

And because the mechanical guys can't get it through their head that the robot itself is part of the servo feedback. The software can't be fully tested w/o working hardware - the gyro does not work while the robot is shaking itself apart - etc, etc, etc Classic comment: It works perfectly on the stand but not on the ground!! It has to be a software problem. Hehehe...

Just kidding (mostly) - I appreciate those mechanical guys!

[sashboy226]

Originally Posted by Al3+

The trick is to train the rest of the team to blame electrical instead.

Thats what we do. When we get metal shavings in the jags, its always electricals fault, they dont watch us close enough

[davidthefat]

Originally Posted by wireties

Because the mechanical guys always finish late and give electrical and software guys the last 3 days to make it magically work o.

And because the mechanical guys can't get it through their head that the robot itself is part of the servo feedback. The software can't be fully tested w/o working hardware - the gyro does not work while the robot is shaking itself apart - etc, etc, etc Classic comment: It works perfectly on the stand but not on the ground!! It has to be a software problem. Hehehe...

Just kidding (mostly) - I appreciate those mechanical guys!

Just have the electrical guys put together all the stuff before mechanical so programmers can test on it

[ALTrammell818]

We blame electrical

[CMSD]

Since it's usually the guys and gals on mechanical and electrical, one simple reason. The alternative is blaming themselves. Almost every problem we had at our two regionals was mechanical, but of course, the code was automatically blamed, and later proved to be completely flawless