Chief Delphi

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

Alan Anderson 07-04-2010 00:44

Re: why blame the programmers??
 
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.

jmanela 07-04-2010 23:19

Re: why blame the programmers??
 
Quote:

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

Re: why blame the programmers??
 
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

Re: why blame the programmers??
 
Quote:

Originally Posted by jmanela (Post 949797)
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

Re: why blame the programmers??
 
yeah, solenoids are a [pain],

make sure you call them formally as such:
Code:

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

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

Re: why blame the programmers??
 
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

Re: why blame the programmers??
 
Quote:

Originally Posted by Robototes2412 (Post 949833)
and not informally, or as such:
Code:

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

Re: why blame the programmers??
 
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

Re: why blame the programmers??
 
Ahh, ok. Thanks for the explanation.

Jason Law 08-04-2010 23:34

Re: why blame the programmers??
 
Quote:

Originally Posted by jmanela (Post 949797)
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

Re: why blame the programmers??
 
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.

Robototes2412 08-04-2010 23:58

Re: why blame the programmers??
 
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

Re: why blame the programmers??
 
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

Re: why blame the programmers??
 
Quote:

Originally Posted by Jason Law (Post 950567)
except when the example code doesn't work...

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

BACONDUDE1902 09-04-2010 09:32

Re: why blame the programmers??
 
but programmers got the power!!!!!!!!!!!!!! :yikes:


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

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