Re: why blame the programmers??
 

People blame what they don't understand.

-Mechanical..although it takes time to master it, most people understand at least the very basics.

-Electrical..a little more mysterious, but still, most people have some basic grasp.

-Software..people seem to either get it, or think of it as black-magic that goes on deep within the cRIO.

-As can be seen through the Salem witch trials and other historical examples, people like to take the easy way out and blame black magic for their problems :p

Re: why blame the programmers??
 

you don't. it's not their fault. it's mechanical's fault.

Re: why blame the programmers??
 

The programers usually get blamed for several reasons:

• There's only one programmer on the team
• Not even the mentors understand what goes on in the programers head
• The programer codes the robot as if they're driving

I remember on specific instance during breakaway that our ball magnet was causing balls to be sucked under the robot. When the drive asked me how to stop the motor on the ball magnet (I was the spotter) I quickly told him to toggle the left throttle and hold buttons 4, 5, 6, and 12 for at least one second. It made sense to me at the time I programed it!

Re: why blame the programmers??
 

OK, this is amazing. We plan on having our Drive team be all software this year, so we can be like "BAM! This happened." and the pit crew can't protest.

Re: why blame the programmers??
 

Over here we like to keep trying to improve our code. It sometimes involved changing what button did what.

An alumni last year placed a spray painted plate of aluminum on the driver station and had scratched in an operations manual. One of its directions was to ask programmers how we had set up the controls this time.

This year we should have enough programmers so there will always be someone available to explain to someone else on the team what we did.

Those mechanical guys blaming programming, they are just playing hard to get. They know they love how we type in stuff and then stuff happens, or break.

Re: why blame the programmers??
 

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)

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

Re: why blame the programmers??
 

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.

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

Re: why blame the programmers??
 

You got a few days to test?

Luxury...

Re: why blame the programmers??
 

lol! Thanks for that laugh! :)


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

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!

Re: why blame the programmers??
 

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.

Re: why blame the programmers??
 

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.

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.

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.

Re: why blame the programmers??
 

The same goes for me.... :(

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

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.

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

Re: why blame the programmers??
 

Ditto. It's so much easier to combine the two.

Although 60% of the time it is electrical, so I can't really complain too much.

Re: why blame the programmers??
 

Programmers in this competition are not real programmers in its true form. I would consider them electrical engineers as they are typically responsible for developing/interfacing the software and control systems to the hardware, which is typically built by the rest of the team. They are really the most critical member of the team. Without them the hunk of metal and plastic does nothing.

Like the real world, this person (usually only one) has the least amount of time to do their job because the hardware team went way over schedule to do the build.

Some helpful hints to keep the electrical engineer happy:
1. Don't ask the electrical engineer while they are programing DID YOU GET IT WORKING yet. It gets real frustrating after you get that question every two minutes from every team member. You will know it is working when you see it working.

2. Don't ask what are you doing when it looks like we are doing nothing. More than likely we are compiling or downloading the program to the robot. Or we are in deep logical thought on the best way to program and one question might just ruin that thought.

3. Don't take the robot from us while we are programming to make a tweak say it will only take two minutes, keep it for three hours, then ask us at the end of the day why it wasn't done.

4. If you want to learn how to program don't ask for someone to teach you in week 6 of the build.

5. Don't blame the electrical engineer/programmer for all the robot's issue. Just remember when you are pointing the finger you have three more pointing back at you. From my experience that is about the correct ratio of blame. Typically we only get 20% of the time to do 80% of the work. We get blamed for 80% of the problems when only about 20% of them are the programmers fault. Good old 80/20 rule.

Kidding aside,

If you are one of the electrical engineers, find a way to program and test without the hardware. If you don't have a spare robot the best method is to do a bench setup. Find a large table, get all the electrical components, tape them down and wire them up. For this setup use the smaller motors and attach a tape flag to the shaft so you can visually see the direction they are turning. Start programing.

Good Luck.

Re: why blame the programmers??
 

As programmer I often get blamed with a lot of the errors on the robot. I find myself remembering what was said in Billy Joel's song Vienna "You know when your wrong but you don't always know when your right". I don't mind getting told that I messed up, because I probably did. What irks me is when I ask someone to check a system on the robot because I think it is electrical or mechanical and the rest of the team refuses to take five seconds to check, as well as prevent me from taking 5 seconds to stand up and look. That is without a doubt my biggest pet peeve of being a programmer. If you tell me I screwed up I'm more than happy to check, but that means that you should be nice enough to check when I say you screwed up. XD

Rant achieved.

Re: why blame the programmers??
 

If the code worked once, it will always work unless it has been changed, or something physical has changed on the robot - in which case it's mechanical problem, not programming....

Re: why blame the programmers??
 

Re: why blame the programmers??
 

Technically, if you are actually doing it like an actual control engineer would do things you have plenty of time. In all seriouness you shouldn't need the hardware to program the software. You do need the hardware to actually verify the programing is right but that should come after the robot is built.
Once again. You should be able to figure out if the robot is going to shake itself apart long before it was actually built. Its a bad design process because you are risking having the robot rip itself apart to pieces. I always wonder why this sort of behavior gets by in a competition that is mentored by engineers. There isn't a single field of engineering that doesn't actually design their control systems like this.

Re: why blame the programmers??
 

That's a personal favorite of mine: The robot was working two hours ago, no code was changed, and now it's stopped: Clearly programming. At the '09 competition our feeding mechanism stopped working at times during the competition, and the coach kept coming back to me to "fix the code". On day three, we found a weld that was spaced 1" farther apart at the top of the robot than it should have been, completely stopping the part from functioning. Funny how that worked out.

Re: why blame the programmers??
 

This reminds me of one of my first days in my job right out of college....

My lead went up to me and said half serious and half jokingly, "The most important thing to do at the start of a new project is to determine to whom to assign blame when things go wrong. Unfortunately this will have to be you!"

So really programmers you need to get on the act early and get the team to assign blame to mechanical earlier!!!!

Other great sayings.. "Don't worry we'll take care of this" "We" being the "Royal We' meaning X teamate will take care of it not me!

In all seriousness he was the best boss/mentor I could have had coming right out of college.

Re: why blame the programmers??
 

i say if the programers are getting blamed they send the blame too the build team or electrical instead

Re: why blame the programmers??
 

That doesn't work, they say we're trying to blame them for our flaws and tell us to fix our code.

Re: why blame the programmers??
 

the only people who blame the programmers are electrical. when they screw up the wiring.

Re: why blame the programmers??
 

I've determined that all problems are mechanical. The programming is only an abstract idea without hardware and the hardware implements the programming, so everything is the fault of the hardware.

Re: why blame the programmers??
 

Today, I greased the gearboxes and tightened the chains on our robot because one side was slightly faster than the other, which is obviously a programming issue.


:rolleyes:

Re: why blame the programmers??
 

Why do all the electronics accuse the programmers.
Electronics are just looking at the diagram and plugging the cables in.
That's all they do ..:yikes:

Re: why blame the programmers??
 

Electricity is a confounded thing you know. Especially since not everything conform to the same standards. Like how a set of wires provided for one sensor has a completely different arrangement and color meaning compared to another.

Re: why blame the programmers??
 

but seriously, why not blame the programmers?

Re: why blame the programmers??
 

But seriously, why should you? If you're trying to blame someone else for something, you should have a good reason for it.

Re: why blame the programmers??
 

Hah our programmers always take the heat because they're stubborn. They'd rather run the risk of messing everything up by completely tearing down and rebuilding the program instead of switching two air tubes. They wait until the robot is completely built to start programing an autonomous. And they change and load the code without telling anyone. As mechanical, electrical, and driver I think they deserve all the blame they get.

Re: why blame the programmers??
 

As electrical, it's your wires that pull out/mysteriously swap places, causing the code to go bad.

As a driver, you're the most hated person by the programmers. You tell them that the robot is broken, and it's a code problem (when a hard defensive maneuver took out a wire, say).

As a mechanical, you failed to design and build the robot to the code that the programmers had put together.

Because of all these, the programmers will say it's your fault.
:p



Now, why blame the programmers? They're sitting right there, that's why! Everyone else is moving around trying to fix the robot.
:p

Re: why blame the programmers??
 

This happened during the last few hours of the build I have 1 limit switch programmed to stop one motor simple enough.

when the limit switch is tripped every thing just dies cant move any thing just dies WITH OUT MISSING A BEAT A MENTOR SAYS "Its the programming."

and i explain the code in simplest terms so that a first grader would under stand it and with a dead serious face he still blames the programming. :( and what is worse is that we did not manage to fix the mechanical/wiring error. :(

Re: why blame the programmers??
 

That sucks when it really isn't the programmer's fault.

But thats only happened twice all of build season, once when a spacer for the lift was over-tightened, and again when a key fell out of a drive shaft.

I think it's easiest to place blame on programmers because they sit and do work, moving a mouse never looks as accomplishing as welding or milling parts, but is just as significant to the success of the team.

It still all their fault ;)

Re: why blame the programmers??
 

If all else fails, blame the business team. :ahh:

Re: why blame the programmers??
 

Depends on the problem.

Magic smoke: Electrical, possibly programming (Mecanum drive code on sticky wheels, trying to strafe, blows a Jaguar)

Robot slamming into walls: either driver or programming (mixed up drive code on wheels)

Clanking noises: Mechanical mostly, possibly programming (movement limits)

Actually, it is the programmer's fault. :P

Re: why blame the programmers??
 

Amen, folks, Amen!

Window motors won't move when connected to Jags (MDL BDC 24), but just peachy on Vics.
Programmers fault!

Mecano wheels don't drive straight at low speed, twist function used a lot.
Programmers fault! (Yes, it really was our fault! Sending Jag signals to Vics!)

Last year: LabView is worthless! Takes too long to deploy!
Programmers fault! (My first year programming, only one using LabView on Classmate, but didn't have any "Wouldn't compile errors!")

Re: why blame the programmers??
 

On my team, it's become almost a joke that it's always the programmers fault. While even after seeing that its not programming, the only other fault it could be would be either electrical, communications, or user-error (like a driver). Which could all well end up being my (the programmer, electronics, and all that is digital's) fault. Maybe if our team wasn't so mechanically-inclined and more technologically-savvy, they'd understand what I do and not be so afraid of the unknown :p

Re: why blame the programmers??
 

I believe it was 2007. I had finished programming early and was enjoying a bit of cleaning up the code. Had a mentor come in and tell me that the drive code was broken. Symptoms. Both joysticks forward nothing and one joystick forward the robot would spin one way. I thought to my self well that surly is wierd but I need to see it on the debugger. So I waltzed in there and had them run the robot. Joysticks were read right. The correct output was sent to the victors. Then I looked closer to see that one of the other mentors had cross wired the drive motors to two different victors. (Red of Motor A to positive of Victor A, Black of motor A to negative of Victor B). Before I could point this out (I was actually pointing at the wiring), the mentor who did the wiring said that the programmers need to check everything because the programming was always messed up. After I pointed the wiring out the robot ran perfectly and that mentor never came back ...

Re: why blame the programmers??
 

Well, this year was the year Mechanical and Electrical finally gave enough time to Programming, listened to what they had to say, and worked together with them to get (mostly) everything working correctly. I think it payed off, as the programmers weren't panicking, coding, testing, and fixing bugs on-the-fly between practice matches, they were seeded 4th, and they made it to a 3rd semi-final match before losing 54-64. "It's the programmer's fault" has now turned into a kind of light-hearted joke whenever something breaks.

Basically, some good communication and teamwork goes a long way.

I believe they could have won the regional if it wasn't for some field "no comms" network issues knocking out one of their alliance partners, but that's another story.

Re: why blame the programmers??
 

Yesterday, our coach said, "well, I don't think it's a code problem"

I was too stunned to even hear what the real problem was

Re: why blame the programmers??
 

In competition, it was either the driver's fault for not knowing the controls, or the programmer's fault for building a buggy control system. But I was the driver and programmer, so everything always was my fault....

Re: why blame the programmers??
 

Blame the programmer because when the arm slams down on the railing from ten feet in the air and smokes the motor during autonomous, who else could it be. (But seriously, the robot was mechanically intact, and after the arm got caught on the railing the code sent more power to the motor to try to move it, smoking the motor. Silly programmers.)

Re: why blame the programmers??
 

For years it has been a long running F.I.R.S.T inside joke, I can atest to that on my team that we always blame the programmers and the take it in stride and with a grain of salt but we always know who's fault it was weather it was electrical or mechanical, and if it ever is the programmers fault man do they hear it.

Re: why blame the programmers??
 

In all my seriousness, in my experiences, programming errors happen more than mechanical errors just because of the fact that, if you follow proper engineering procedures, it generally will not drastically alter the workings of the robot if one bolt is not tightened correctly, whereas the mistake of one character can destroy the entire code of a robot.