Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   why blame the programmers?? (http://www.chiefdelphi.com/forums/showthread.php?t=84922)

Radical Pi 20-01-2011 22:20

Re: why blame the programmers??
 
Quote:

Originally Posted by dag0620 (Post 1004476)
One day the code will be written first, and then a robot built around it :P

That day has come! Our team leaders literally said "write the code for the test board. We'll design around it"

Sadly, it's not the real robot.

I do get some control over the build though when I threaten to setup the wireless system so that I can hack into the robot from the other side of the school and start driving remotely (something which I am able to do thanks to our school's wireless network)

kylelanman 20-01-2011 22:22

Re: why blame the programmers??
 
We don't generally have to many problems with programming errors on our team but the programmers get blamed for everything and the mechanical team takes the credit when everything works.

The best one was when our battery came disconnected. The programmers say the mechanical team should have zip tied the connector together....which they should have. The mechanical team says the programmers shouldn't have run and hit the wall full speed during autonomous mode in Lunacy causing the battery to fly out of the robot and the human player at the middle station to crap his pants (slight exaggeration but half the balls in the hopper went over the wall and hit him)......okay maybe that one was a programming error. ;)

DSST\neal.ian 20-01-2011 22:39

Re: why blame the programmers??
 
Quote:

Originally Posted by tsa256 (Post 947556)
That would work great except, I currently hold head programmer, and electrical. So you can imagine I get all the blame.


At least you're not alone! I'm in the same boat. OH, AND troubleshooting. If something doesn't work, it doesn't matter what it is, it's my job to figure out what the problem is and figure out how to fix it.

TD912 20-01-2011 23:09

Re: why blame the programmers??
 
Ugh, as a former programmer and head of Electrical for my team, I remember being crunched for time as Mechanical would take their time building things and wait until the last few days to assemble everything, leaving me with only a few days to properly code and test everything.

I would get it running decently, and then at a competition something would suddenly stop working after a few matches. It's not the programmer's fault if a badly soldered wire to a solenoid broke, or if the tension in some chain caused the gears to slip. >_>

Plus some members of the team don't see typing on a keyboard very productive until you actually upload code to the robot...

davidalln 21-01-2011 00:18

Re: why blame the programmers??
 
Quote:

Originally Posted by TD912 (Post 1004726)
Ugh, as a former programmer and head of Electrical for my team, I remember being crunched for time as Mechanical would take their time building things and wait until the last few days to assemble everything, leaving me with only a few days to properly code and test everything.

You got a few days to test?

Luxury...

synth3tk 21-01-2011 01:29

Re: why blame the programmers??
 
Quote:

Originally Posted by davidalln (Post 1004761)
You got a few days to test?

Luxury...

lol! Thanks for that laugh! :)


We aren't on-schedule unless the programmers are programming AT the regional. No earlier, no later.

Dustin Shadbolt 21-01-2011 01:32

Re: why blame the programmers??
 
Programmers have the pleasure of not being on the same time frame in a way. Yeah you need basic code to make sure components work but our magic comes from the time we have to ourselves after ship and the opening day of regionals. I did a majority of the programming after ship and day one of boilermaker. Especially if you are new I would recommend seeking help during day one at regionals from other teams or the volunteers!

TD912 21-01-2011 02:38

Re: why blame the programmers??
 
Quote:

Originally Posted by davidalln (Post 1004761)
You got a few days to test?

Luxury...

Quote:

Originally Posted by synth3tk (Post 1004802)
lol! Thanks for that laugh! :)


We aren't on-schedule unless the programmers are programming AT the regional. No earlier, no later.

If you consider 1 or 2 days "a few"... I would get some basic code done, make sure it somewhat worked, then work on it some more after the robot was shipped. Then I usually spent the first day of the regional fixing bugs on-the-fly between practice matches. Even then the code wasn't that great.

Luckily it seems like my team has gotten it together this year and is finally making sure they give the programmers enough time to write and test code.

Bongle 21-01-2011 09:02

Re: why blame the programmers??
 
Quote:

Luckily it seems like my team has gotten it together this year and is finally making sure they give the programmers enough time to write and test code.
Every team I've ever been on (2003, 2004, 2006, 2009, 2010, 2011 so far) has said that. I've never had the competition robot for more than a couple days before ship. Every year, it's "this will be the year the robot is ready for the programmers a week early", and every year it's "oh sorry, we need to adjust this widget or slightly rebuild this whatzit, so you can't program with the full robot".

You can certainly do most of the basic control stuff without the robot (or with a previous-years robot) and we often do, but if you're using any sensors more complicated than a limit switch, tuning things (autonomous/PIDs/vision/linetrackers) is impossible.

apalrd 21-01-2011 09:33

Re: why blame the programmers??
 
It might seem strange to some, but I already wrote almost all of the base code for this year. We know what we are building and what it will do, so I can write all of the software and debug it in a simulated environment, then spend a few days tuning the robot control loops and fixing robot-specific issues.

It helps to have a chassis to work with. You can most certainly work on drive code, automation, and vision on just a chassis. Even if you have to re-tune some of the code for the real robot, simply knowing that the algorithm works as you wanted to, and finding the 10% of cases where the code dosen't work as expected (and fixing them) can be a great help.

fsgond 21-01-2011 10:12

Re: why blame the programmers??
 
The program is the only thing that runs the entire match start to finish. It also has the ability to make or break any part of the bot.

Lightfoot26 21-01-2011 10:15

Re: why blame the programmers??
 
Quote:

Originally Posted by tsa256 (Post 947556)
That would work great except, I currently hold head programmer, and electrical. So you can imagine I get all the blame.


The same goes for me.... :(

thefro526 21-01-2011 10:33

Re: why blame the programmers??
 
If I may make a suggestion for some of those that are on either side of the Programming vs. Mechanical Blame Game:

Communication is key, especially with something like Mechanical and Programming. A large portion of Programming can be done without a Robot in front of you, I'd estimate something like 80%-90%. Mechanical should communicate the design to the Programmers as early as possible so that the Programmers can begin writing code, so that once the robot is completed it's just a matter of tuning the code and making minor changes.

This year, once our Design was settled, I went to the head programmer and outlined all of the robots functionality, I told him the number of motors, how they would be driven (relay vs. speed controller), planned sensor feedback, autonomous Strategy, Pneumatic Layout, etc etc. This gives he and his team a solid two to three weeks to code, if not longer, which should help keep them from being stressed out once the robot is done because the bulk of the code should already be written. I'd suggest teams that haven't done this should do it soon.

That doesn't mean I'm going to stop blaming the programmers when things go wrong though... ;)

Alan Anderson 21-01-2011 10:45

Re: why blame the programmers??
 
During a couple of years, the TechnoKats build schedule included explicit "programming has priority" time one evening each week. No mechanical work was to be done on the robot that evening, except for repairs when the software broke something. It worked out pretty well.

This year we dug our 2007 practice 'bot chassis out of the robot graveyard hall of fame, replaced a couple of wheels, and wired it up with a cRIO control system. It's a perfect software playground. I'm a little worried that this year's competition 'bot won't be ready for wiring up anytime soon, but as soon as it is, we'll have software ready to go.

SudoSammich 21-01-2011 13:05

Re: why blame the programmers??
 
I'm running into this very problem now, there's literally no way the code could possibly cause the error we're running into with the drive train, every other programmer's confirmed that and yet...still falling to me. The only possible solutions are the power distribution system and the wrong orientation of wheels (holonomic drive featuring 45 degree omnis)...but the team's become convinced the programming team isn't up to the task. It's running default code /facepalm.

I'd have to agree with a lot of the posts here though, it's easier to blame something you can't see. If the mechanical aspects are wrong, it's (generally) easier to see. You can just say "oh, the tube isn't fitting correctly in the gripper". With code, the only people who can confirm the code is written properly are the programmers, who people don't generally trust when they say it's fine. It's like an older (now graduated) programmer once told me: "The chain can break on the field, and if nobody sees it you're expected to fix the problem".

Now that that little rant's over with...I think the other reason is that it's likely the programmer's fault a lot of the time lol. Unless your code's perfect, someone will find that little glitch that triggers the watchdog when the joysticks are in position (-.46, .53) lol


All times are GMT -5. The time now is 13:36.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi