![]() |
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. |
Re: why blame the programmers??
Quote:
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. |
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)
|
Re: why blame the programmers??
Quote:
Turns out someone was working on the electricals and unplugged a solenoid... |
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);Code:
Solenoid kicka = new Solenoid(1); |
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. |
Re: why blame the programmers??
Quote:
|
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
|
Re: why blame the programmers??
Ahh, ok. Thanks for the explanation.
|
Re: why blame the programmers??
Quote:
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. |
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. |
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 :(
|
Re: why blame the programmers??
To go with what other posters are saying:
|
Re: why blame the programmers??
Quote:
|
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