why blame the programmers?? [Archive]

AmoryG

03-04-2010, 20:53

im wondering, if anything goes wrong with the robot why blame the programmers??(any suggestions, comments or ideas??)
:confused:

Because if hardware broke as easy as code does, no team could afford to build a robot. If we were playing a match and suddenly our robot did something it was not supposed to, I would suspect that either the code or a sensor was not working as it should. Code breaks easy, and if our robot suddenly started malfunctioning, I would load up the most basic code that works beyond a doubt to confirm whether it was us programmers we should have blamed.

tsa256

03-04-2010, 20:55

The trick is to train the rest of the team to blame electrical instead.
That would work great except, I currently hold head programmer, and electrical. So you can imagine I get all the blame.

Bongle

03-04-2010, 20:56

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

The trick is for each sub-component of a team (programming, electrical, mechanical) to listen to the other people's proposals for what is wrong, and investigate it to the best of their abilities. If the programmers say that a limit switch might have a short while the hardware guys say that the program isn't checking the switch often enough, both teams should double-check both of their components as best they can.

Quite often the programmers can direct the hardware guys to a potential source of a short or disconnected wire, while the hardware guys can tell the programmers if they're operating some system outside of its design limits. If both sub-teams can work together rather than fighting over whose bug it is, then you should have a more successful robot.

DarkFlame145

03-04-2010, 21:12

im wondering, if anything goes wrong with the robot why blame the programmers??(any suggestions, comments or ideas??)
:confused:

Because Mech and Fab can't do anything wrong to make the robot not work =P (I was the welder for my HS team) Plus our programmers did things like buy soldering irons from the dollar store, have to rewire one, and then it blows up while someone is using it. It's always the code =P jkjkjk To be Honest I dont know why people blame programing

synth3tk

03-04-2010, 21:14

Because most often, it is the programmer's fault.

JewishDan18

03-04-2010, 21:24

Typically, a program has many more points of failure than a mechanical or electrical system.

Radical Pi

03-04-2010, 21:25

Perhaps my favorite quote from the season: "The programmer's taking responsibility for the problem. It must be mechanical then!"

It's simply a black box problem. Almost anyone on a team can understand how a mechanical system works. Electrical causes much more confusion than mechancial, but it is still understandable to many. Programming is the least understood, so everyone automatically jumps to it. Programmers (on our team at least) understand almost everything on the robot, and can therefore pinpoint exactly where the problem is. Since the programmers usually figure out the problem, guess who is yelled at every time?

Oh, and my favorite error of the season was when mechanical drilled through some wire on the robot and caused everything to fail.

kstl99

03-04-2010, 21:26

Wow, I hope there is lots of joking in this thread. As someone who has programmed PLCs for machinery I am impressed that these programmers can get so much functionality in so little time. They are the last people who can test there work. They are the only ones that can work after the 6 week build but unless you have the luxury of a test robot they cannot test their code until the competition. The worst part is that their errors can be the most noticible, dead robot, erratic behavior,etc.

ttldomination

03-04-2010, 21:38

This can be a touchy topic because programmers can be semi-defensive, but I'd like to believe that mechanical can be a really visual thing, where as programming can be a mental jumble.

And we never "single out" the programming department. If something isn't working, all of the guys dive in and see if its their department. Just so happens that programming has the error. :P

EricH

03-04-2010, 21:42

Because, with 5 weeks to plan and get ready (and presumably knowing all the ratios between where their encoder is and where the wheel is that it's tracking), they STILL complain when they only get a week to test the robot and implement the minor tweaking that should take 3 days at most.

Oh, and if a mechanical guy makes a minor error, the robot can still work. If a programmer makes a minor error in the wrong place, the robot doesn't work...

(Mechanical guy joking about good reasons not to take the blame)

Oh, and Bongle-- If both sub-teams can work together rather than fighting over whose bug it is, then you should have a more successful robot. I'm sorry, but the mechanical bugs immediately get squashed by the nearest flyswatter. The programming team is therefore the only team that has bugs...:p But yes, in principle it is best to work together to find the problem and eliminate it.

Chris is me

03-04-2010, 21:47

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

03-04-2010, 21:55

Akash Rastogi

03-04-2010, 22:00

So true.

SOLUTION: Build a practice bot.

-Nick

Practice bots get stuff done.

True fact.

Andrew Schreiber

03-04-2010, 22:15

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

03-04-2010, 22:27

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

03-04-2010, 22:34

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

03-04-2010, 22:35

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

03-04-2010, 22:40

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 :p 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

03-04-2010, 22:41

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

03-04-2010, 22:43

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

03-04-2010, 22:54

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

03-04-2010, 23:06

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

03-04-2010, 23:09

ALTrammell818

03-04-2010, 23:18

We blame electrical :]

CMSD

03-04-2010, 23:31

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 :D

Burmeister #279

04-04-2010, 01:42

I wrote an essay worth of response to this and then realized it was just a rant out one of my mentors and is now saved in my /rant folder. Here's the tl;dr version:
Its always the programmers fault.
I usually don't mind it but it can get frustrating.
As for the reason its usually the programmer's fault, it's probably because its the least understood by anyone who's not a programmer. Most programmers can diagnose problems and judge whether its the program's fault and even if we don't think its the program's fault we usually are willing to go back through our code and check for errors.

ChrisH

04-04-2010, 02:18

.... the code was automatically blamed, and later proved to be completely flawless :D

I find this very hard to believe. Flawless code would violate the First Law of Programing. There must be a flaw, you just haven't found it yet :p

Andy L

04-04-2010, 02:35

"because when it's mechanical, something falls off. When it's electrical, smoke appears."

someone on our team said this last year, and last year it was programmings fault :P

JBotAlan

04-04-2010, 02:46

So, this season 2586 had a straightforward 4wd drivetrain, with an AndyMark Toughbox on each side. It worked wonderfully after the mechanicals put it together, all the way through practice.

However, by the end of Traverse City, our driver was complaining every other match that the drivetrain was "lagging". Being that we couldn't reproduce anything similar in practice, we dismissed it as an unknown problem that hopefully wouldn't come back. Just in case, when we got back to the shop, we replaced all of the gray Jags with black ones and stress-tested; all seemed to be well.

Flash forward to Troy. Two or three matches into the competition, we are making a terrible grinding noise. We got it back into the pit and found that one of the gearboxes was frozen. Taking it apart, a pile of metal shavings fell out. What the driver described as "lagging" was actually chunks of gears floating around inside the gear boxes.

Why did this happen in the first place? Well, as it turns out, greasing your gear boxes is highly recommended. :p

Moral of the story: even if it seems like a programming problem, it can easily still be a mechanical issue.

Other moral: don't dismiss what your driver is reporting. He knows how the thing is supposed to feel, and when he's articulating that it feels "weird", even if he can't describe it, there's very likely something wrong.

biojae

04-04-2010, 02:51

I tend to agree with the others above, though the only times that the programmers were blamed on my team (That I am aware of anyway...) were electrical issues.

Once last year, the driver complained that he couldn't drive. The joystick was plugged into the wrong port on the DS because of a hurried dash to replace a broken DS. (Dang ethernet ports!)

The only other error was a missing fuse, it was taken out while some debugging was performed, but forgot to be replaced :o

EricH

04-04-2010, 02:56

I find this very hard to believe. Flawless code would violate the First Law of Programing. There must be a flaw, you just haven't found it yet :p
Yep. I thought I had a good program for doing something (not involving a robot).

Then I went to test it, and it wouldn't load a file in correctly. Fixed that.

Then it's not catching some things it should. Fixed that.

Now it's really going haywire, but I know where the problem is. I *only* have to rewrite a couple of functions or so...

ideasrule

04-04-2010, 03:32

This year, the only time something went wrong in teleop that WAS a programming issue, programmers didn't get blamed! During the Rochester regional the drivers were experiencing massive lag with the robot, but blamed the FMS and never told the programmers about it. At the end of the day, I finally overheard them talking about the lag and fixed the problem within several minutes.

Moral of the story: better communication!

Foster

04-04-2010, 07:13

Great,what did you do to fix the lag? We had a lag problem at FLR and ended up pulling the vision code.

Tom Ore

04-04-2010, 07:57

It looks to me that we should address the very notion of "blame." This is a team sport and the team sinks or swims together. When there is an issue the team needs to find the best way to handle it. It can put incredible stress on one or two people if the rest of the team starts to lean on them for a solution. Instead, be supportive of the group (mechanical, electrical, softwre...) trying to solve the issue.

After the season is over, there is plenty of time for a "lessons learned' meeting to talk about what when right and what went wrong. This will help next season go more smoothly.

Jack Jones

04-04-2010, 08:17

Dkt01

04-04-2010, 12:15

I just love how anything bad is the programmer's fault, but anything good is accredited to mechanical. I have been on both teams, but I like software because we get to make things work.

Tanner

04-04-2010, 12:27

I always find it interesting when someone blames the code as it just leads me to find something I didn't think about when coding the code. Plus I also get to blame someone else later, though I don't do that too often.

I just wish I could find some way of blaming the mechanical team after the robot went backwards in autonomous at Peachtree...

-Tanner

kgzak

04-04-2010, 12:41

Because most often, it is the programmer's fault.

Because if hardware broke as easy as code does, no team could afford to build a robot. If we were playing a match and suddenly our robot did something it was not supposed to, I would suspect that either the code or a sensor was not working as it should. Code breaks easy, and if our robot suddenly started malfunctioning, I would load up the most basic code that works beyond a doubt to confirm whether it was us programmers we should have blamed.

Most of the time, on our team, it was the hardware. Our main code wise was motors running backwards, but that was because a day before competition the build team decided to turn the motors 180 degrees. We also had watchdog errors, but that was because our WGA was bad. I don't remember any other problems with code/electrical.

iblis432

04-04-2010, 14:43

I get very irritated at this also. If it's even remotely possible that programming was actually the issue, i'll check it, but when we run the code, it works fine, nobody has even touched the labtop between matches, then something messes up the next time around, i find it very hard to believe its my fault. I've sat through lectures before about how its my fault when it was electrical or mechanical. I'm not afraid to say i messed up, but i wish i wasn't the only one like that on our team. If they would at least inspect the robot before blaming me i'd be happy, even if they didn't see the issue the first time.

Al3+

04-04-2010, 14:54

I just wish I could find some way of blaming the mechanical team after the robot went backwards in autonomous at Peachtree...

Obviously the wheels were mounted in reverse.

The trick is for each sub-component of a team (programming, electrical, mechanical) to listen to the other people's proposals for what is wrong, and investigate it to the best of their abilities. If the programmers say that a limit switch might have a short while the hardware guys say that the program isn't checking the switch often enough, both teams should double-check both of their components as best they can.

Quite often the programmers can direct the hardware guys to a potential source of a short or disconnected wire, while the hardware guys can tell the programmers if they're operating some system outside of its design limits. If both sub-teams can work together rather than fighting over whose bug it is, then you should have a more successful robot.

My comment wasn't completely serious. I'm not in favor of automatically denying that a problem is a code error unless it's glaringly evident that it's not a code error. (For example, the signal light wasn't blinking correctly. Nothing in the code deals with the signal light at all.)

I'm just lightheartedly expressing how often it seems that programmers investigate an issue only to discover an underlying electrical problem.

Egg 3141592654

04-04-2010, 14:57

I, being the ONE programmer on our team, know your pain. There are three main reasons why people love to pick off programmers.
1. Code isn't physical, aka nobody can see you fix it, and nobody except for programmers can fix it.
2. Unknown Logic, Many non-programmers think that programming is VERY simple so when something goes wrong, they think that it is "just an easy fix" (probably not)
3. Strength in numbers, It is easy to blame 1 or 2 people then a whole mechanical section, or electrical section.

It is really too bad programmers are placed in this situation, i mean, they're just as important as any other section of a team.

ideasrule

04-04-2010, 15:43

Great,what did you do to fix the lag? We had a lag problem at FLR and ended up pulling the vision code.

That lag problem was because the code was, contrary to my expectations, saving files to the cRIO. The cRIO filled up and the robot became extremely laggy.

Another lag problem we had at the Waterloo regionals was because we used a pool noddle to fix the camera in place, and the pool noddle was pushing against the camera's reset button.

billbo911

04-04-2010, 16:34

Three thoughts:

1) Without good mechanics, programming doesn't mean squat.

2) Without decent programming, even incredible mechanics means nothing.

3) Why fix blame? Find the problem and work together on a solution!

NorviewsVeteran

04-04-2010, 18:22

3) Why fix blame? Find the problem and work together on a solution!

We would, but the programmers have to fix the code first.

davidthefat

04-04-2010, 21:51

2. Unknown Logic, Many non-programmers think that programming is VERY simple so when something goes wrong, they think that it is "just an easy fix" (probably not)

Seriously, I showed up to a meeting late and the 2 other programmers tried to get the solenoid working for 3 hours... I only took 3 minutes to get that working... :confused: Sometimes I feel like I am the only programmer...

ideasrule

04-04-2010, 21:53

Seriously, I showed up to a meeting late and the 2 other programmers tried to get the solenoid working for 3 hours... I only took 3 minutes to get that working... :confused: Sometimes I feel like I am the only programmer...

Yeah, programming anything in teleop is really simple. The hard part is always autonomous, especially if you're planning to use vision.

RandomStyuff

05-04-2010, 07:46

I guess I'm lucky then. In my team there is full understanding by all teams of the other teams. The mechanical is easy to understand, and the programmers understand the mechanical. A quick course on the electrical was given by me to all team members just before the start of the season (electrical is in programming team's turf here, although it's pretty much a cooperative thing).

The thing that makes my team slightly special is the understanding of programming: my school is called Aleh High School of Sciences, and as you can guess from the name, it's a pretty geeky school, where around half the students study computer science. As weird as it may seem, this year all of the 12th graders in my team except for one (our connectivity manager) major in Advanced Computer Science which includes in it a couple of university level courses. Next year, the two leaders of the Mechanical team are also Advanced Computer Science students, and the management will again be made up of almost exclusively Advanced CS students, with the only blacksheep being a girl who is doing the normal Computer Science course (cause she couldn't fit the advanced one into her schedule without taking out Chemistry or Physics)

The end result is a team which not only understands what code is, but can actually read it. This year when both my number two and I were gone for a few days during the season, a 12th grader from the Mechanical team came and took over temporarily in making sure the code is done. Our Mechanical manager even sat with me and helped me debug some code during a free hour once.

That doesn't always help though: we have a running joke that I'm probably to blame for (seeing as at the start of the season I was sure our programming team could do anything we wanted (which isn't too far from truth, we got the Innovation in Control award for some pretty awesome algorithms we implemented with our camera and and other impressive things like rewriting half of the WPI-libs stuff, including the low-level, and writing our own accumulator, to be able to get 3 gyros working on the robot.)). Every problem that comes up our Mechanical team's manager shouts "They'll fix it in software."
The climax came three hours before the shipping, when we discovered our scale was mis-calibrated, and that we were 7 kg overweight. Our mechanical team manager again shouted that we'll fix it in software :D (technically, if you write all the unused 0s into 1s there needs to be a positive charge, therefore the electrons leave for the battery, saving you the weight of an electron for each one.... sadly, the maximum you'd be able to save is about as equal to 1/10,000th of an atom... some bored kid did the math).

efoote868

05-04-2010, 09:36

The key to success is knowing who to blame for your failures.

If its the first time after the programmers touched the robot, it very well could be the programmer's fault.

If its the first time after the programmers touched the robot and its the first regional competition, it probably is the "programmer's fault", but its also the "team's fault" for not letting the programmers have access to a fully completed robot during the build season.

If its during the tenth match at competition and everything was working fine for all the other matches, and if the code didn't change between then, there is a high probability that it is NOT a programming fault, and it is electrical / mechanical.

I remember back in 2008 we had a solenoid that wouldn't work properly. We went from both ends of the spectrum - mechanical (replacing the solenoid) and programming (printf's in code to verify everything was as expected), followed the wires and met in the middle. Seating PWM cables in spikes are a real pain, this one jiggled out so it was only contacting two pins out of three. The spike would blink green-orange, but never go red.

Mrs.Drake343

05-04-2010, 10:02

Our programmers have issues with always trying to make it better. We have threatened to duct tape their arms to their sides once the code is in and working properly...so they can't tweak it any more.

exprg:melonhead

05-04-2010, 10:42

programmers get blamed only because it's so easy to say that what you are working on is flawless. for me, the first to blame is electronics whether it's right or wrong! if you don't understand it, it's easy to believe there is something wrong with it. simple as that.

thefro526

05-04-2010, 10:47

People tend to blame things they don't understand... Most non-programmers don't understand programming, therefore they blame it for any problems they can't solve.

Strangely enough, I don't think enough people thank programmers... Without them, your robot wouldn't even move.

Mark McLeod

05-04-2010, 10:56

Our programmers have issues with always trying to make it better. We have threatened to duct tape their arms to their sides once the code is in and working properly...so they can't tweak it any more.
I assume you do the same to your mechanical crew of course?
I'm firmly of the opinion that mechanical engineers and build crew should be shot at the end of week 5...:yikes:
Only pit crew should touch the robot for maintenance purposes after that...

That never happens though.

exprg:melonhead

05-04-2010, 11:00

Strangely enough, I don't think enough people thank programmers... Without them, your robot wouldn't even move.

thank you Fro! it amazes me that things that happen behind the curtain of building the robot can be taken for granted. my team just assumes that the robot will function properly. if they push the joystick forward, they expect the robot to move in that direction. i personally believe that the code is half of the robot. like you say, without it, you can't move. but to go from the other end, i take the electrical and mechanics for granted as well. generally, if we have the idea, i expect them to build it, and as soon as they do, i code it before we run the bot again. so i guess i'm kinda inversely guilty

FRC4ME

05-04-2010, 11:01

Well, the programmers get blamed more often because, objectively, code error are responsible for more problems than mechanical errors.

But that's not really the programmers' faults. A recurring theme I've heard (and experienced) is that the builders will spend five weeks, six days, and twenty-three hours building the robot, then turn it over to the programmers and say: "alright, now download the code. What do you mean it doesn't work? You had six weeks to work on it!"

Unfortunately it doesn't quite work that way. ;)

PingPongPerson

05-04-2010, 11:40

At least on my team, it's becuase when the programmers are testing the drive, they usually smash the robot into a wall at least 5 times. :)

Tom Line

05-04-2010, 11:51

You say "Why blame the programmers?"

I say, why is any blame allowed on your team? Aren't you all working in the same direction, for the same goal, and doing your best? If so, then it's up to both the students and the mentors to very quickly correct the problem and explain to anyone who wants to perpetuate 'blaming' someone else that you are ONE team. Not a bunch of sub teams.

I had an emotional event with one of our students earlier this year when he said "xxxxx broke. As always." Now that he's gotten a little more involved with the TEAM I'd be shocked if I ever heard it again.

Remember. There is no controls team, no mechanical team, and no business team without The Team.

kamocat

05-04-2010, 13:28

Here's some simple stuff:
Code doesn't break.
If the robot used to function, and now it doesn't, though the software hasn't been changed, then something in the hardware changed.
The code still works, but for a different setup.

Allowing the whole team to participate in troubleshooting requires two things:

clear communication
isolation of errors

It's generally true that singular components of the robot changed, not the robot as a whole. Clear communication is required to determine what was deliberately changed since the robot last worked, and what might have failed.

Of course, you're not actually done troubleshooting until the problem is fixed, and you know WHY it's fixed.

krudeboy51

05-04-2010, 15:00

GaryVoshol

05-04-2010, 15:55

Arthur C Clarke's third law: "Any sufficiently advanced technology is indistinguishable from magic."

Since only the programmers understand the program, it is magic to the rest of the team. And since magic doesn't exist, the fault must be the programmers who created the magic. ;)

Code doesn't break. It reacts exactly the same time every time. When something new happens that never happened before, it's because the mechanicals, electricals or drivers gave the code some new stimulus that wasn't tested before. So it's the other teams' fault for not supplying enough test cases.

MikeE

05-04-2010, 16:46

There are exactly* 3 reasons:

1) Intellectual. Software is conceptual not physical and therefore harder to understand than mechanics. As so many have said above, it's easy to blame something you don't understand and may be slightly frightened of.

2) Number and complexity of interfaces. There is far more to the software than just the code a typical team's programmers write. All of these other software components have bugs, undocumented assumptions, edge cases etc. and are not well documented.
The mechanics just interacts with itself, the carpet, a ball and maybe other robots.

3) Mentoring. Many teams have a no software engineers amongst the mentors, so students don't get advice on reliable design, robust coding practices, or understand how to manage the central strength/curse of software: it's flexibility (e.g. through configuration management).

* rhetorical license #MA32145

Yoel2630

05-04-2010, 17:34

I think many times code is uploaded without the necessary adjustments.
So most of the time it's programmers blaming electrical connections, but because the electric team is usually done before the programmers, the problem is due to code! and then when they fix all the "mistakes" in code, such as i/o addresses or sending the opposite signal (1 instead of -1, which of course can be also solved by switching wires :p ), any other problem that may come up is really easy to pin on them :P

Excuse me for using the wrong terms or being unclear. My native language is Hebrew :)

LukeS

05-04-2010, 18:41

Because most often, it is the programmer's fault.
I'm sorry our program cannot handle hardware failure as well as you would like. I'm sorry it can't detect that the kicker hit & broke the drive encoder. I'm sorry it can't detect that the latch is broken (as in holds, but for less than 1 sec) and that the loader arm needs to stay extended.

In seriousness though, it programming's fault 3 times.
1) I accidentally commented out `break;' in a series of 1-line cases. (dumb---- attack)
2) Andrew accidentally commented out `break;' in a (different) series of 1-line cases. (legit reason, was making changes on the fly at comp.)
3) We had a ``real'' bug. The code worked most the time, but failed to handle a fringe-case with censor input. I wish I could remember exactly what it was. I wrote this part of the code

stipulation: If a hardware change is made that necessitates a code change, but the programmers are not informed of this, it is not programming's fault.
stipulation: If the programmers were not correctly informed of what the code should make the hardware do, yes you can maybe blame programming a bit. But it is not a `code problem'. The code is perfect. It does what we tell it to. Any incorrect behavior is because we told it to do the wrong thing. We have 2 exceptions to this. If we told the code to do the wrong thing it is probably because physical told us the wrong thing. We have one exception to this.

Because if hardware broke as easy as code does, no team could afford to build a robot. If we were playing a match and suddenly our robot did something it was not supposed to, I would suspect that either the code or a sensor was not working as it should. Code breaks easy, and if our robot suddenly started malfunctioning, I would load up the most basic code that works beyond a doubt to confirm whether it was us programmers we should have blamed.
Yes, but:
1) we haven't changed the code since yesterday, when it was working.
2) when we did change the code before that, it had nothing to do with what broke
3) no, there is no chance that it no longer has code on it. It went out and ran, didn't it?
Therefore, the sensor broke, the wire came out, or you burnt out the motor.

ideasrule

05-04-2010, 18:48

There IS one possible coding problem if the robot suddenly breaks after working for 10 matches: race conditions. It's hard to have a race condition with robot code, but it's one thing to keep in mind when coding or debugging.

cheesepuffgd

05-04-2010, 19:07

since the the code is invisible to mechies and electrical, they blame programming because programming is easy to blame
:mad: :mad: :mad: :mad: :mad:

dag0620

05-04-2010, 19:30

The same problem arose at CT.

It was the practice rounds. Our Autonomus program (the part of the code I was responsible for this year) has a limit switch rigged up to some mechanics, which when the robot approaches the lined up balls, has the kicker kick (obviously more to it then that). But for some reason it wasnt working.

Obviusly to some degree there was pointing of fingers, but it was more or less everyones theories, as no one really was denying it could be there fault. So as the mechanical team checked mechanics and Electrical, my partner in Crime and I checked over our work. After cooperation with the members of both areas, we found a metal chip in the wiring, which was causing the problem.

So yes we had the pointing issue, but we did work together and fixed what the problem.

LukeS

05-04-2010, 21:22

...of course, the code was automatically blamed, and later proved to be completely flawless :D I find this very hard to believe. Flawless code would violate the First Law of Programing. There must be a flaw, you just haven't found it yet :p

Well, of course: performance issues. Fortunately, we are dealing with an RTS, which means it doesn't need to perform well, just `well enough'.

Seriously though, missing features. We made this code work, so we didn't get to the [x cool feature] (camera, gyros, accelerometers)

There will always be flaws, however, it is a skill to control where they are. What he means is that the relevant portion of the code was flawless.

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.

When I say this, it is said in good humor, although it usually ends up being true. And, even while I say it, I am usually running though the code, checking out if it could be a code issue. (It's even become sort of a good humored routine to blame programmers, then for us to retort).

What bothers me is when we know it can't be code for whatever reason (see the 2nd part of my above post), and people still insist it is. When I say, ``Look, trust me, I have considered this. It's not code.'' please trust me. I know what I'm talking about. Sure I'll check it again, but that's not going to be it, so don't waste both of our time, have someone else be checking other stuff too. Don't make them move so I can prove to you that it is not code.

FRC4ME

06-04-2010, 00:17

What bothers me is when we know it can't be code for whatever reason (see the 2nd part of my above post), and people still insist it is. When I say, ``Look, trust me, I have considered this. It's not code.'' please trust me. I know what I'm talking about. Sure I'll check it again, but that's not going to be it, so don't waste both of our time, have someone else be checking other stuff too. Don't make them move so I can prove to you that it is not code.

Lol. Earlier this year the programmers experienced this on my team. One of the drivers insisted that the left joystick of the tank steering was causing both sides of the tank drive to spin, rather than just the left side. So three programmers set out to prove it wasn't a coding issue: two lifted the robot off the ground while one moved the left joystick forward and back. Sure enough, only the left side moved. They then said, "see? mechanical problem," put the robot down, and went back to work. :D

Although I remember the time on 339 when a Victor burst into flames. All of the programmers (myself included) turned to the lead mechanical mentor and said, with confidence, "hardware problem!" It was rather funny at the time. :p

EDIT - Oh, and I saw this once:
Me: "The left motor needs to be reversed, but other than that, everything works well."
Electrical: "We can fix that in hardware!"
Programming: "We can fix that in software!"

<five minutes later>

Me: "Umm...the left motor is still reversed."
Electrical: "We fixed that!"
Programming: "We fixed that!"
Me: <facepalm>

:p

Al3+

06-04-2010, 01:27

EDIT - Oh, and I saw this once:
Me: "The left motor needs to be reversed, but other than that, everything works well."
Electrical: "We can fix that in hardware!"
Programming: "We can fix that in software!"

<five minutes later>

Me: "Umm...the left motor is still reversed."
Electrical: "We fixed that!"
Programming: "We fixed that!"
Me: <facepalm>

:p

Happened to our team too. Actually it was more complex. We had two independently driven motors on each side, and just one motor out of four was reversed. Not realizing this, we flipped the entire side, so the other one on that side was now reversed. Then the electronics changed the wiring on the first one, making the whole side reversed.

Also the drivers once went into a match with the joysticks backward. He mentioned to me afterward the confusion this caused, and I almost went to fix the direction until he clarified that it wasn't the drive that was reversed.

demosthenes2k8

07-04-2010, 00:15

Sadly, this happened a LOT on our team this year. Software received the robot Thursday before ship, and had what little time remained to get the code working on it. It worked (mostly) for unveiling, but mechanical kept changing how things were going to work throughout build season.

And then came competition-GSR.

One particular example of software getting unfairly blamed was when we went to go into a practice match, with a robot that we had JUST been running in the pit, and spent all ten minutes trying to get communications. After we left without getting anything done, the mechanical lead looked like he was ready to kill the software lead (me). I found out after I left for lunch that they had unplugged the camera and plugged the special practice gaming adapter into its port. Not software, they shouldn't even have been touching that wire!

I agree that software gets blamed because software doesn't really have anything concrete to show, unlike the other subteams. However, I think that a bit more mutual respect would be a good idea. It's rather annoying to have subteams blaming each other for everything instead of working, and always assuming that it's never their fault. Especially when it IS their fault that software doesn't get the robot until really late.

FRC4ME

07-04-2010, 00:31

Also the drivers once went into a match with the joysticks backward. He mentioned to me afterward the confusion this caused, and I almost went to fix the direction until he clarified that it wasn't the drive that was reversed.

As I recall, when I first joined 619, their programmer showed me a feedback loop from a while back that involved a total of seven reversals: the joystick inputs were reversed in the getters and at the point of use, the motor outputs were reversed in the setters and at the point of use, the feedback was reversed in the getter and at the point of use, and an intermediate calculation was multiplied by -1.

Since then we've made sure to define conventions - gyro spinning clockwise should be positive, motor going forward should be positive - and ensure step-by-step that all of the hardware code follows them.

Alan Anderson

07-04-2010, 00:44

jmanela

07-04-2010, 23:19

For any of you programmers musing about the invisibility of software, here's a concrete suggestion to make it easier for the non-programmers to relate: give your software a way to show itself. You should at minimum be able to show the value of each sensor on either the Dashboard or the Driver Station "LCD screen" display. Any internal states should similarly be exposed for diagnostic purposes.

Consider it "defensive programming" -- done properly, you can quickly see if any sensors are not behaving properly, and tell the electrical team where to focus their attention before they start pointing fingers at the software.

And if they still don't believe you, what i would do is show the non-programmers an example of example code that should be proven to work. (assuming you use LV, i'm not sure if they give examples for other languages, but you could always look on CD :rolleyes: ). This is another great way to test out sensors and say, hey if this doesn't work, then something else is messed up.

Also, utilize those blinking lights on the C-RIO. For example, when we I was programming the kicker function (our kicker uses two solenoids and a latch to give a pressurized kick), and tested it, it worked the first few times. However, eventually it stopped working. If you look on the solenoid module on the c-rio, there is a set of lights for the solenoids and they light up when they are activated by the program. I showed everyone else (non-programming) that when the kicker worked, or did not, the lights would light up in the same pattern with the same timing. It turned out to be a mechanical problem.

bassoondude

07-04-2010, 23:28

This is why my team doesnt have subteams of any sort. while not all of us are programmers (actually, most of us arent) we all work on just about every other part of the bot, so we never lay blame on anyone or any group of people. If we seriously cant find a problem, we then blame our programmer, who usually finds the lose wire or faulty circuit breaker that was the real cause of the problem. Moral of the story: ITS NEVER THE PROGRAMMERS FAULT! (unless it is)

TD912

08-04-2010, 00:25

Also, utilize those blinking lights on the C-RIO.

We went to the practice field, and our pneumatic kicker didn't work when the joystick trigger was pressed. I start getting blamed for changing something in the code. I quickly looked at the lights on slot 8 of the cRIO, where the pneumatics bumper plugs in. Pressing the trigger caused them to turn on.

Turns out someone was working on the electricals and unplugged a solenoid...

Robototes2412

08-04-2010, 00:58

yeah, solenoids are a [pain],

make sure you call them formally as such:
Solenoid kicka = new Solenoid(8,1);

and not informally, or as such:
Solenoid kicka = new Solenoid(1);

Don't let the cRIO program for you, its a dumb terminal, it wont do stuff right.

timothyb89

08-04-2010, 02:31

I'd have to agree with something that's been said here a ton: The hardware guys don't see/understand the code most of the time, they're quicker to blame the thing they don't understand.

It naturally happened a lot this year for us and essentially it came down to a 50/50 split between being the code or not. Eventually the team learned to put up with it and the hardware guys got to be pros at checking wire conductivity when a motor/solenoid/sensor/whatever stopped working and we eventually were able to work out a good debugging processes between the mechanical and programming team.

But I think the most awesome thing that happened (cooperation-wise) was that (a week or two ago) a few people from the mechanical/drive team came to ask the programmers for coding lessons. Essentially, they had wanted to understand the code so they could figure out whether it was a mechanical or programming issue without jumping to conclusions.

As the programmers do most of the electrical work as well, I think most of our team understands what the others are doing. Short of teaching the non-programmers how to code, we've historically tried to make sure to explain important info about how the code workd to the mechanical team. At the very least we want to make sure everyone understands (and agrees!) with our reasoning when we say "it isn't the code!".

The communication really helps though. I know I'm probably wrong about half the time (*cough*), and running my reasoning by someone else- programmer or not- is a great way to see weed out logic problems and fix issues faster.

synth3tk

08-04-2010, 11:52

and not informally, or as such:
Solenoid kicka = new Solenoid(1);

Don't let the cRIO program for you, its a dumb terminal, it wont do stuff right.
Worked fine for us. Is there any performance-hindrance reason not to use this call?

Radical Pi

08-04-2010, 12:22

There isn't really any performance issues with that, it just re-calls the function with the slot explicitly defined. I think the point was that you are assumming the library has it right

synth3tk

08-04-2010, 12:45

Ahh, ok. Thanks for the explanation.

Jason Law

08-04-2010, 23:34

And if they still don't believe you, what i would do is show the non-programmers an example of example code that should be proven to work. (assuming you use LV, i'm not sure if they give examples for other languages, but you could always look on CD :rolleyes: ). This is another great way to test out sensors and say, hey if this doesn't work, then something else is messed up.

Also, utilize those blinking lights on the C-RIO. For example, when we I was programming the kicker function (our kicker uses two solenoids and a latch to give a pressurized kick), and tested it, it worked the first few times. However, eventually it stopped working. If you look on the solenoid module on the c-rio, there is a set of lights for the solenoids and they light up when they are activated by the program. I showed everyone else (non-programming) that when the kicker worked, or did not, the lights would light up in the same pattern with the same timing. It turned out to be a mechanical problem.

except when the example code doesn't work... Hn... Compressor code with solenoid week 4?! It's alright Josh, youlearned for next time.

Agreed the kicker was definitely programmed correctly. Notice how nobody blamed you? We found out quickly that it actually was an electrical, pneumatic, mechanical problem. So I took 99% blame and fixed all 3 areas.

Also, from my limited experience, everything goes a lot smoother If the lines between subteams are very small. For example, I am on the mechanical team, but I can adequately do all of the eletrical and pneumatics too. I even managed to figure out how to inverse things and call different joystick inputs and stuff in labview. When our much needed programmer was gone for the night, I "magically" rearranged some things in the program (yes I did know what I was doing). Of course, our programmer checked it first thing when he came back. Having a person who knows how to do multiple areas can avoid for a 10 minute battle of this subteam did it, etc.

And, no. If someone gave me a blank VI to program the robot, I would just look at them, laugh, and call Josh. Lastly, our team values oUr programmers. Without them, our robot would never work very well.

Andrew Y.

08-04-2010, 23:45

Robototes2412

08-04-2010, 23:58

i remember making lights flash on and off on my team's robot, controlled by a button. I claimed they activate when an error occurs, i had a lot of programming bugs, and had to take the lights off :(

BigJ

09-04-2010, 00:03

To go with what other posters are saying:

Program defensively. Make sure you can put your numbers where your mouth is.
Make an effort to understand exactly what your code is doing so that you are usually not in a situation where you go "Oh... I never thought of that."
Make an effort to understand exactly what the intended mechanics/pneumatics/etc are supposed to be doing. Sometimes you can meet them in the middle way easier than making them do it over. Remember, mechanical are your friends, no matter what lack of hours they let you have on the robot.
Never assume it isn't the code. I can't tell you how many times it WAS the code. *sigh*...
Always strive to improve your methods. Come up with a good documentation and output setup so that new programmers can be easily integrated into your team's development. That way when mechanical asks the rookie programmer something, they don't always have to point at you. :)

jmanela

09-04-2010, 09:09

except when the example code doesn't work...

Solenoid Test Vi was just a freak of nature...

BACONDUDE1902

09-04-2010, 09:32

but programmers got the power!!!!!!!!!!!!!! :yikes:

Racer26

09-04-2010, 09:42

The one I always find happens with me, is the robot code works flawlessly for 4 or 5 matches, then spontaneously STOPS working properly. I get told to check the code, and my response is invariably "code doesn't change on its own, if it worked before, then one of its inputs has changed, or ceased functioning" Its often that an encoder has died, or something along those lines.

gvarndell

09-04-2010, 10:55

im wondering, if anything goes wrong with the robot why blame the programmers??(any suggestions, comments or ideas??)
:confused:

If you intend to become an embedded systems software developer, then you either get really good at proving it's not the software or you're doomed to forever be a whipping post for the hardware folks. :o
Defensive coding and stellar debugging skills will prevent wasting years of your career in the finger pointing game and will make you quite valuable to boot.

Racer26

09-04-2010, 14:08

If you intend to become an embedded systems software developer, then you either get really good at proving it's not the software or you're doomed to forever be a whipping post for the hardware folks. :o
Defensive coding and stellar debugging skills will prevent wasting years of your career in the finger pointing game and will make you quite valuable to boot.

QFT. I graduated my FRC team, went on to get a Bachelor of IT, and now work for a company doing PC and embedded software. I regularly get blamed when it breaks.

cheesepuffgd

09-05-2010, 23:28

At least on my team, it's becuase when the programmers are testing the drive, they usually smash the robot into a wall at least 5 times.

that was one time!!!!

TStark115

20-01-2011, 16:05

It's not aways their fault and most of the time it's not.

billbo911

20-01-2011, 16:47

Why? Because as part of the mechanical team, we can't possibly blame ourselves.

dag0620

20-01-2011, 17:33

Ohhh I was dreading the comeback of this thread!

I've come to the conclusion, it's the age old story, and every team has it, and no-one will ever win it.

But I will admit, as a programmer, we mostly do the bidding of the Design and Mech Teams. I think outside of the Control Board and Autonomous, we have no creative control.

One day the code will be written first, and then a robot built around it :P

davidalln

20-01-2011, 18:07

from a mentors point of view:

(WARNING...im a mechanical type of guy)

we usually hated on electrical...until we found out they could put pretty lights that flash on our robot...so now programmers are to blame for all things.

Your programmer made those pretty light pulsate over time during the match. Continue blaming electrical.

PAR_WIG1350

20-01-2011, 19:42

Your programmer made those pretty light pulsate over time during the match. Continue blaming electrical.

Unless a 555 was involved. But honestly, I find that problems are evenly distributed throughout the robot. However, Magic smoke, the smell of melting stuff, a chain that has come off its sprocket, and binding gears are really obvious. A sign error, or a missing increment/decrement operator, on the other hand, can be difficult to track down, and those are just simple, easily solved problems. more complex errors, such as accidentally causing a function to fail to execute by making the conditions it would normally execute under impossible (such as

void myfunction (void)
int main()
{
int nvar=0;
if nvar>1
{
myfunction ();
nvar=0;
}
else
{
}
//...
}

and elsewhere you had a function in which an error increments nvar by 1 such that every 2nd error triggers myfunction, but you removed that section of the code, now whatever crucial task myfunction does to fix the error never occurs, and the errors just continue on to oblivion. But just by looking at the code, it would be hard to diagnose that.

Thus, the programmer's aren't blamed more often, they just have to do more work to find the problem before thy can even begin to fix it, thus it seems like they are always getting asked to fix things, since they are always working.

davidthefat

20-01-2011, 20:05

Honestly, it only takes one integer or one symbol to make your robot go hay wire. But that only takes a second to fix. If it is mechanical failure, it is harder to fix. So people are being optimistic and blaming the one that is easier to fix. That is what I have learned from my experiences in the club.

Joe G.

20-01-2011, 20:13

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

plnyyanks

20-01-2011, 20:23

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

MAldridge

20-01-2011, 20:36

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!

demosthenes2k8

20-01-2011, 20:43

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!

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.

MagiChau

20-01-2011, 21:22

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.

Radical Pi

20-01-2011, 22:20

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

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

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

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

synth3tk

21-01-2011, 01:29

Dustin Shadbolt

21-01-2011, 01:32

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

You got a few days to test?

Luxury... (http://www.youtube.com/watch?v=13JK5kChbRw)
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

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

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

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

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

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

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

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

George Nishimura

22-01-2011, 06:41

That would work great except, I currently hold head programmer, and electrical. So you can imagine I get all the blame.

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.

riptide

22-01-2011, 09:16

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.

iblis432

24-01-2011, 09:47

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.

iv1777

24-01-2011, 10:35

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

Robototes2412

24-01-2011, 11:40

import time
time_code_was_changed = time.time()

if robot.is_changed() and robot.time_was_changed() > time_code_was_changed:
print("Mechanical")
else:
print("Programming")

Adam Y.

24-01-2011, 11:51

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.

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.

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

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.

SudoSammich

24-01-2011, 12:38

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

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.

kaliken

24-01-2011, 15:13

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.

hcps-maxwelltd

24-01-2011, 18:24

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

demosthenes2k8

24-01-2011, 18:31

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

fyrefrost

24-01-2011, 18:35

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

Radical Pi

24-01-2011, 23:30

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.

NorviewsVeteran

24-01-2011, 23:36

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:

cilginbilgin

26-01-2011, 03:58

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:

MagiChau

26-01-2011, 06:35

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:

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.

cheesepuffgd

26-02-2011, 19:36

but seriously, why not blame the programmers?

demosthenes2k8

27-02-2011, 00:25

but seriously, why not 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.

El Geffe

27-02-2011, 01:59

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.

EricH

27-02-2011, 03:24

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

Twisted eric

27-02-2011, 03:58

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

El Geffe

27-02-2011, 04:21

and what is worse is that we did not manage to fix the mechanical/wiring error.

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

Chickenonastick

27-02-2011, 04:26

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

ThaineP

27-02-2011, 10:04

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

kws4000

28-02-2011, 08:06

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!")

RoBoTiCxLiNk

13-03-2011, 22:47

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

drakesword

14-03-2011, 10:39

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

TD912

14-03-2011, 15:08

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.