Lessons Learned

[Clayton Yocom]

I came into this year as a competent programmer, never touching Labview or any robot programming at all except one class at a community college near here (for freshmen in HS.) I've recently realized how much I've really learned, not only in Labview (which is obvious) but in programming in general. I'll go through a couple of these that really stood out to me, because they really made me think differently about how I should take coding robots in the years to come.

1. Simplicity doesn't always mean faster code execution. - We had some code that made it easy to set dual solenoids. (you give it the forward and reverse boolean and a refname, and it does the rest for you.) At championship we were given two red cards, which pretty much ended our game. One of those was *NOT* driver error, but a robot timeout. I still can't explain what happened on the field, but we made it so those dual solenoid sets work only on boolean change. This shaved about 12-13ms off of our execution time. Insane.

2. Sensors don't last when abused. - Now this is completely the robot's design that caused some of these errors, but when you program something expecting to have reliable arm+reach pots as well as left and right drive encoders, it feels really bad when you have to go back and snip parts simply because the sensor broke. XXcelsior originally had 5 limit switches. 3 on the gripper, 1 on the reach, and one that would be triggered during the arm's "park" mode. On the robot that went to St. Louis, there were a grand total of 0 limit switches. Again, simply because of design oversight, but it really hurts to have to go back and redo code simply because the arm/claw is too powerful.

3. Don't be shy. - One of the biggest mistakes I probably made this season was not being on CD more often and getting more acquainted with some of the people here. CD is an amazing resource with a vast amount of knowledge at your disposal. People here are more than willing to help you with your work, and people are just as willing to accept your help. Use the resource in front of you!

4. Holding the drive team's hands is not always productive. - This is something that I think every programming team and drive team should actively discuss. I shouldn't have to make it so that the robot doesn't do something completely obviously wrong if your commanding it to. You should have the insight to not do that. Human precision is much higher than you'd think. The arm shouldn't be able to kill itself by driving the claw through the robot, yes, but you should have the smarts not to ram the claw into the ground making the robot stand on its back two wheels. (for example, of course.)

5. Being stubborn won't get you the championship. - If you don't rethink decisions you've made in the past, and constantly review the code you've previously wrote, you won't make discoveries like #1, simply because you'll trust that the decision you made then was the best way to do it. If you can't adapt to changing conditions in code, you'll have a hard time maintaining code on a robot that goes to a competition. I was looking back at the original wiring diagrams for this year's robot. Its amazing how much different it was back then from what it is now.

And finally, 6. Don't give up. - We didn't have an autonomous for either of the two regionals we went to, not necessarily my fault, but because I just had no time with the robot (the competition 'bot, or the practice 'bot) until after Midwest. The drive team had a lot to work on after Boilermaker, and I respect them for spending a ridiculous amount of time training for Midwest, but in retrospect, a day's worth of work could have made the difference between us getting picked in the 3rd round at Midwest, and us getting picked 2nd round, or even picking. After Midwest, I felt guilty because of that, and several days later we came up with this. That was about 10 minutes worth of code that wasn't already on the robot at Midwest. Its almost disheartening that I didn't work on it more there and get us a higher seed. I was very glad to see it working fairly consistently at the end of the day on Thursday at st. louis.

I'd like to hear about what you guys learned from this build season, be it something that you liked, or something that needs to change.

PS: I'd like to thank the TechnoKat's software mentor, Alan Anderson, for teaching me the entirety of what I know about labview, all in about 2 weeks. I had a great time this year watching the team and robot evolve, and can't wait till the 2012 game

[ratdude747]

my lessons learned for labview code:

1. Always keep teleop.vi nice and light. leave the heavy stuff in periodic tasks.
2. If time allows, if a member wants to learn to program using an unused old robot, let them. I am proof at what one can learn form messing with an old robot.
3. When in doubt, always throttle down while loops.
4. Never assume when you cand test and find out.
5. no matter wh0 has more points, the watchdog always wins.
6. If your team uses dropbox or the like, always back up your most recent code revisions alongside codes for old robots. You never know when you might want to take a look at it...
7. Never be afraid to ask "noob" questions if they are serious...