pic: (447) How do YOU keep programmers out of the electronics?

One member of our team, we still don’t know who, wired a little badly during our “in house competition” before FIRST. One of the victors on the test bot had both the power input and ouput cables goin to the fuse board. It made nice smelling smoke.

Ok guys… this has really gone on for way too long. The electrical team is called that because they handle all the electrical hardware on the robot. If you have one, it means that you have some faith in their abilities. The same applies to programmers with their job being software. If a problem arises, playing the blame game just wastes time. The way i see it goes like this.

  • Blame teams -(time passes)

  • Figure out who got blamed more -(more time passes)

  • Losing team goes insane trying to find the problem with other team standing vindictively behind them - (you’ve missed 1-2 practice matches)

  • Other team begins to search for problem in losing teams area of expertise -(missed another 1-2 practice matches)

  • Giving up the other team begins to scour their area for the problem with the previously losing team being vindictive - (miss or operate badly in 1-4 Seeding rounds)

  • Problem is finally found and hopefully resolved -(two whole teams are worn out and a lot of time is wasted)

The times may be shorter or longer, but what I’m saying is always entertain the possibility that your team did it. Each team should work on finding and solving the problem their area of expertise. The problem will almost always be found faster and you save your whole team a lot of headaches.

So back to the topic. How do I keep the programmers out of the electronics? Mutual respect for each other’s work and an understanding of efficient team dynamics.

On our robot the program port is right beside the wheels so I have to go in between the chains to get to it… all they would have to do is turn it on while I’m working to kill my precious fingers (or my precious serial cable)! But that’s why I unplug the pwms! To save my fingers. :smiley:

(I usually plug them back in afterwards)

Nice pic. except we wouldn’t be keeping our programmer out of the electronics. We’d be keeping other kids who might screw up the electronics out of there. Not mentioning names, there is a kid on our team (freshman this year) who has a lot of dedication and hard working skills. The only problem is that he gets annoying cause he talks a lot and likes to “fix” stuff on the robot. lol. that would be perfect for this kid. thanks for the idea. :smiley:

-Crash

lol, on 1549 all of us except our 1 programmer are ellectrical and mechanical. I am learning C as well, not to replace him as he is brilliant but so i can write things in that he attributes to “operator error”. In short…

If the ellectronics and mechanical both work, programmers blame THE DRIVERS!!!

Been there, and As a lead mentor, when I get really grumpy, I make programming back up every hex file with a useful name, So the one that was somewhere near correct can be put back in while they sort out what went wrong.

Biff: You’d get along well with our electronics/programming mentor…

Our problem usually lies in mechanical people messing up… I’ll never forget that somehow they shorted out one of our relay outputs with a chain… That was amusing, especially as they scream and say “uhhhh… pickle… are sparks a good thing coming out of that black box???”. Ya, it was fun.

But you should be nice to programmers, we don’t like being blamed for everything (because its so easy). I think last year one of the teachers told me to fix like a mechanical design flaw in software… this year i think he told me to take 10 pounds off in software… You should love your programmers :slight_smile:

But I do think that since electronics and programming are so related, its a good idea to have one team work on both. It keeps things less confusing. Last year we had to play the pick the pwm port game, where before almost every match they had rewired the PWM cables to different outputs because they didn’t know which went where. That was oodles of fun, especaially if it didn’t get worked out before the driver had to drive it… Though, beware programmers with screwdrivers is a good motto… looks at scars hammer + screwdriver + programmer = bad

A mousetrap? sighs yet another software problem…

ya, we play the blame game all build season, but when it comes time to compete, problems get fixed fast, but its because, at least on our team, down in the pits its just the lead students from each sub team, none of the “underlings”

but i give mad props to all the up and coming programmers and electricians, who have messed up, got blamed, and fixed their problems, because one day, you will be the head electrician or programmer, down in the pits, making those 5 minute fixes for the finals

One (serious) suggestion for anyone who hasn’t already done this:

The robot controller can often (read always) be hard to reach. If you plug serial cables into the program and tether ports and run them neatly to somewhere somewhat accessible on your bot it becomes much easier to plug in. You can even put them up high (depending on the bot) so you don’t even have to bend over to plug them in! hows that for convenient!

Also, a rocker switch attached to the reset and program buttons in an easy to reach place is also a good idea.

  • Toby

I found a really nice solution to this, provided you have someone who can follow a wire from one end to the other :slight_smile:

//Left drive motors
#define drive_left_1 pwm01
#define drive_left_2 pwm02
//Right drive motors
#define drive_right_1 pwm03
#define drive_right_2 pwm04

I have a file full of those… and I use the drive_left_1, etc in the code… so when it comes time to wire the robot, I print the file, and then its just matching :slight_smile:

Hrm, sounds like a good idea, I’ll have to try that next year

I kind of learned electronics as I went… Up until about a week ago, we had victors supported only by their wires on the practice bot, because I would wire them, and not know how to mount them, so they just kind of hung there.
Having to wait for someone to wire stuff up was not a fun way to do things, so it was much easier for me to learn to do stuff… didn’t seem that hard to do, other then verifying everything a couple of times.

Then again, I learned a lot this year… the code would often be sitting waiting for someone to hook up the hardware… with everything, pneumatics, wiring, etc… That happened until I started adding it myself… then the program/spike/victor would be waiting for the actual robot component to be added.

Now I’m the first one called to the pit when something stops working, rather then last year, where they wanted me as far away from the robot as possible :slight_smile:

Personally Having Sub-Teams and the team as a whole is good and bad.

Sub Teams Bad: Lack of Communication, Place of Blame is always diverted from the ones who caused the mess (Just be honest and say sorry its my fault - no reason to lie), If the person just comes around to “only program the robot” you run a very good risk of them not being able to show up and further complicating things.

Sub Teams Good: Your able to concentrate more at the matter at hand, You feel better that you have control as to whats going on and everyone else has to guess =), Brings in more team members who can find a place or their fortee - ( what they can do the best )

Personally I like having subteams, It gives everyone the time and place and order to which things should be done. First The Build Team builds the structure, Electrical Wires up the structure, Programmer comes in and tells the structure what to do. If for some reason the programmer sees that something would cause the program not to work he should consult someone before taking action. The only thing a programmer has say is where he would like the robot controller to be so he can access tether and programmers port -OR- which i have never seen yet:

A DB9 extension coming from both the tether and the Programming Ports and placed on the robot for easy access so that the programmer doesn’t have to dig around / remove things to get access to the RC.

A DB9 extension coming from both the tether and the Programming Ports and placed on the robot for easy access so that the programmer doesn’t have to dig around / remove things to get access to the RC.

we put one of those on our robot … then in the first regional, we took them of for weight … ROFLOLMAOL!

its the little luxuries that go first

one good thing about sub teams is it lets the individual aspects of the robots be excelled beyond “just getting it done”

the small success our team has been blessed enough to have in the way of innovation awards, i like to believe, comes from specialization based on sub teams

if you just want to “wire up that there robot” yes, electronics is just wiring that anyone can do. but if you want to learn and excel, its best to have sub teams were you can concentrate and flourish in your individual area of interest

don’t get me wrong though, everyone on our team is expected to be proficient in at least two “areas” so communication between sub teams is made much much easier

Is that Victor an 883 or an 884? I can’t tell… :stuck_out_tongue: :stuck_out_tongue:

(surprised no one said that yet)

Its definitely a red 884 ( which are far more reliable than the blue ones ) :rolleyes: