Go to Post There are no simple solutions, as every solution has its own problems. - M. Lillis [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rating: Thread Rating: 2 votes, 5.00 average. Display Modes
  #61   Spotlight this post!  
Unread 05-04-2010, 11:51
Tom Line's Avatar
Tom Line Tom Line is offline
Raptors can't turn doorknobs.
FRC #1718 (The Fighting Pi)
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 1999
Location: Armada, Michigan
Posts: 2,513
Tom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond reputeTom Line has a reputation beyond repute
Re: why blame the programmers??

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.
  #62   Spotlight this post!  
Unread 05-04-2010, 13:28
kamocat's Avatar
kamocat kamocat is offline
Test Engineer
AKA: Marshal Horn
FRC #3213 (Thunder Tech)
Team Role: Mentor
 
Join Date: May 2008
Rookie Year: 2008
Location: Tacoma
Posts: 894
kamocat is just really nicekamocat is just really nicekamocat is just really nicekamocat is just really nicekamocat is just really nice
Send a message via AIM to kamocat Send a message via MSN to kamocat
Re: why blame the programmers??

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.
__________________
-- Marshal Horn

Last edited by kamocat : 05-04-2010 at 13:30.
  #63   Spotlight this post!  
Unread 05-04-2010, 15:00
krudeboy51's Avatar
krudeboy51 krudeboy51 is offline
Only Programmer
AKA: kory
FRC #0369 (369)
Team Role: Programmer
 
Join Date: Mar 2010
Rookie Year: 2010
Location: brooklyn
Posts: 151
krudeboy51 is a glorious beacon of lightkrudeboy51 is a glorious beacon of lightkrudeboy51 is a glorious beacon of lightkrudeboy51 is a glorious beacon of lightkrudeboy51 is a glorious beacon of light
Send a message via AIM to krudeboy51
Re: why blame the programmers??

Quote:
Originally Posted by Tom Line View Post
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.
i didn`t say it was happening on my team, i just thought it happens alot on other teams and wondered why!!!
  #64   Spotlight this post!  
Unread 05-04-2010, 15:55
GaryVoshol's Avatar
GaryVoshol GaryVoshol is offline
Cogito ergo arbitro
no team
 
Join Date: Aug 2005
Rookie Year: 2000
Location: Royal Oak, MI
Posts: 5,726
GaryVoshol has a reputation beyond reputeGaryVoshol has a reputation beyond reputeGaryVoshol has a reputation beyond reputeGaryVoshol has a reputation beyond reputeGaryVoshol has a reputation beyond reputeGaryVoshol has a reputation beyond reputeGaryVoshol has a reputation beyond reputeGaryVoshol has a reputation beyond reputeGaryVoshol has a reputation beyond reputeGaryVoshol has a reputation beyond reputeGaryVoshol has a reputation beyond repute
Re: why blame the programmers??

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.
__________________
(since 2004)
  #65   Spotlight this post!  
Unread 05-04-2010, 16:46
MikeE's Avatar
MikeE MikeE is offline
Wrecking nice beaches since 1990
no team (Volunteer)
Team Role: Engineer
 
Join Date: Nov 2008
Rookie Year: 2008
Location: New England -> Alaska
Posts: 381
MikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond reputeMikeE has a reputation beyond repute
Re: why blame the programmers??

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
  #66   Spotlight this post!  
Unread 05-04-2010, 17:34
Yoel2630's Avatar
Yoel2630 Yoel2630 is offline
Registered User
FRC #2630 (Thunder Bolts)
Team Role: Mechanical
 
Join Date: Oct 2008
Rookie Year: 2008
Location: Israel
Posts: 18
Yoel2630 is a jewel in the roughYoel2630 is a jewel in the roughYoel2630 is a jewel in the rough
Send a message via MSN to Yoel2630
Re: why blame the programmers??

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 ), any other problem that may come up is really easy to pin on them

Excuse me for using the wrong terms or being unclear. My native language is Hebrew
  #67   Spotlight this post!  
Unread 05-04-2010, 18:41
LukeS LukeS is offline
4272 mentor, 1024 alumnus
AKA: Luke Shumaker
FRC #4272
Team Role: Mentor
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Indianapolis, IN
Posts: 60
LukeS is an unknown quantity at this point
Re: why blame the programmers??

Quote:
Originally Posted by synth3tk View Post
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.

Quote:
Originally Posted by AmoryG View Post
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.

Last edited by LukeS : 05-04-2010 at 20:58. Reason: elaborate
  #68   Spotlight this post!  
Unread 05-04-2010, 18:48
ideasrule's Avatar
ideasrule ideasrule is offline
Registered User
FRC #0610 (Coyotes)
Team Role: Programmer
 
Join Date: Jan 2010
Rookie Year: 2009
Location: Toronto
Posts: 108
ideasrule is a jewel in the roughideasrule is a jewel in the roughideasrule is a jewel in the roughideasrule is a jewel in the rough
Re: why blame the programmers??

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.
  #69   Spotlight this post!  
Unread 05-04-2010, 19:07
cheesepuffgd's Avatar
cheesepuffgd cheesepuffgd is offline
imperial majesty of all programming
FRC #0955 (raiderbot)
Team Role: Programmer
 
Join Date: Feb 2010
Rookie Year: 2010
Location: corvallis
Posts: 8
cheesepuffgd is an unknown quantity at this point
Thumbs down Re: why blame the programmers??

since the the code is invisible to mechies and electrical, they blame programming because programming is easy to blame
  #70   Spotlight this post!  
Unread 05-04-2010, 19:30
dag0620 dag0620 is offline
Because we're FiNE
AKA: David Givens
FRC #1071 (Team MAX)
Team Role: Alumni
 
Join Date: Jan 2010
Rookie Year: 2010
Location: Wolcott, CT
Posts: 784
dag0620 has a reputation beyond reputedag0620 has a reputation beyond reputedag0620 has a reputation beyond reputedag0620 has a reputation beyond reputedag0620 has a reputation beyond reputedag0620 has a reputation beyond reputedag0620 has a reputation beyond reputedag0620 has a reputation beyond reputedag0620 has a reputation beyond reputedag0620 has a reputation beyond reputedag0620 has a reputation beyond repute
Re: why blame the programmers??

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.
__________________
David Givens
Alumnus Team Max 1071 ('13) | FIRST Volunteer | NE FIRST

Away making magic for a bit...
  #71   Spotlight this post!  
Unread 05-04-2010, 21:22
LukeS LukeS is offline
4272 mentor, 1024 alumnus
AKA: Luke Shumaker
FRC #4272
Team Role: Mentor
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Indianapolis, IN
Posts: 60
LukeS is an unknown quantity at this point
Re: why blame the programmers??

Quote:
Originally Posted by ChrisH View Post
Quote:
Originally Posted by CMSD View Post
...of course, the code was automatically blamed, and later proved to be completely flawless
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
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.

Quote:
Originally Posted by Andrew Schreiber View Post
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.
  #72   Spotlight this post!  
Unread 06-04-2010, 00:17
FRC4ME FRC4ME is offline
Registered User
FRC #0339
 
Join Date: Feb 2008
Rookie Year: 2007
Location: Fredericksburg, VA
Posts: 324
FRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant future
Re: why blame the programmers??

Quote:
Originally Posted by LukeS View Post
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.

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.

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>

__________________
Go directly to queue. Do not pass pit.

Last edited by FRC4ME : 06-04-2010 at 00:22.
  #73   Spotlight this post!  
Unread 06-04-2010, 01:27
Al3+'s Avatar
Al3+ Al3+ is offline
ARTist
AKA: Anthony
FRC #0840 (Aragon Robotics Team)
Team Role: Programmer
 
Join Date: Oct 2009
Rookie Year: 2008
Location: San Mateo, CA
Posts: 58
Al3+ is a jewel in the roughAl3+ is a jewel in the roughAl3+ is a jewel in the rough
Re: why blame the programmers??

Quote:
Originally Posted by FRC4ME View Post
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>

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.
__________________
cout << "Hello, robotics. Goodbye, world." << endl;

"The two-axis accelerometer provided in the kit of parts (shown in the picture below) is a two-axis accelerometer." - WPILib User's Guide
  #74   Spotlight this post!  
Unread 07-04-2010, 00:15
demosthenes2k8's Avatar
demosthenes2k8 demosthenes2k8 is offline
Graduated but not gone
AKA: Matt Soucy
FRC #0166 (Chop Shop 166)
Team Role: Mentor
 
Join Date: Jan 2009
Rookie Year: 2007
Location: Merrimack, NH
Posts: 589
demosthenes2k8 is a splendid one to beholddemosthenes2k8 is a splendid one to beholddemosthenes2k8 is a splendid one to beholddemosthenes2k8 is a splendid one to beholddemosthenes2k8 is a splendid one to beholddemosthenes2k8 is a splendid one to beholddemosthenes2k8 is a splendid one to beholddemosthenes2k8 is a splendid one to behold
Send a message via AIM to demosthenes2k8 Send a message via Yahoo to demosthenes2k8
Re: why blame the programmers??

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


GSR Dean's List Finalist 2011
  #75   Spotlight this post!  
Unread 07-04-2010, 00:31
FRC4ME FRC4ME is offline
Registered User
FRC #0339
 
Join Date: Feb 2008
Rookie Year: 2007
Location: Fredericksburg, VA
Posts: 324
FRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant futureFRC4ME has a brilliant future
Re: why blame the programmers??

Quote:
Originally Posted by Al3+ View Post
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.
__________________
Go directly to queue. Do not pass pit.
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Improving the experience of programmers and the effectiveness of code kamocat Programming 18 25-12-2009 08:33
Placing Blame ExarKun666 Chit-Chat 17 24-04-2008 18:24
Who to blame for the creation of the Trackball. Chuck Glick General Forum 7 12-01-2008 22:35
I blame robotics for... JBotAlan Games/Trivia 12 05-12-2007 00:30
blame it on the doggy robot Andrew Rudolph Chit-Chat 0 26-10-2003 13:02


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

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


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