So… I’m the lead programmer for my team, and we have encountered many mechanical problems, the result being that I have no way to test my code. This is bad because the ship date is looming large. 
Advice?
I forgot to mention that I’m using labview. Also, sorry if this has been asked before.
This happens a lot. To veteran and rookie teams alike… I know that I’ve been programming our robot between matches more times than I can count.
I do have some advice, though (some of this won’t help this year, but might come in useful in preventing this in the future).
-
Code in “units”. Don’t write a 1000 line program, build it, and expect everything to work the first time. It just doesn’t happen. Even if you only have a day to test code, try to test it incrementally. First get the drive working. Once you’re happy with that, move onto the scoring functions.
-
There are two types of tuning/debugging you will need to do: correctness testing, and parameter tweaking. A complicated sequence of commands is something that you can either get right or wrong. Other things, like PID loops, time delays, etc. need to be tweaked until they work well. You can oftentimes do “correctness” testing by running your C++ code on a PC (taking out cRIO specific things as necessary). Or you can try your LabView code in a non-real time environment. Make sure your function(s) output expected values. But tuning needs access to the robot. So make sure your code is correct before downloading to the machine, and worry about tweaking afterwards if you can.
-
Have a plan. Know what you want to get working first, what can wait, and what is just bells and whistles.
-
Write maintainable code. Use parameters and constants liberally. These will make changing things that much easier.
Good luck! It sucks sitting around watching the mechanical folks do their thing (hopefully none of my team’s mechanical team is reading this). But know that you are in good company!
EDIT: I posted before I saw you are using LabView. Still, these points should apply.
Very good advice so far.
I’d add that with LV you can do a bit more unit testing than in C/C++. As an example, I assume you’ll want to put code in your teleop for your manipulator. First write the button or joystick code, but just update global variables. You can disconnect the modules from the cRIO, run cables, and go ahead and test that you got the joystick logic correct and that setpoints to other modules look correct. Then you write a periodic loop to read the setpoint, read a pot, run through a PID to control the motor, etc.
Another tip for quicker LV coding. Avoid constants if you have any doubt of the end value. Instead, put the values into front panel controls and make your initial guesses be the defaults. Later when you can start running and need to tune, you can just type new values in without stopping, modifying, and rerunning.
Good luck.
Greg McKaskle
Awesome pointers. I really like the idea of separating the debugging and tuning into correctness testing and parameter tweaking components. Thanks very much. Hopefully, come competition day, we’ll only need to worry about tweaking a bunch of PIDs.
Just a hint for tuning a bunch of PID’s quickly. Make a box with 3 pots that plug into the driver station and write some code to take them and set there values to the loop dynamically.
I’m not a labview person so you might be able to do that with labview instead of pots, but that’s how we old fashion people on my team do it.
All these things are really good. Ill just add in my two-cents.
A. Get someone on the team that is pretty good at logic. It doesn’t need to be someone that really is into programming. Get them to sit next to you and walk through the program with them; step by step. This will kill alot of debugging time when the robot it ready for real testing. Trust me it works.
B. Write comments in your code…and some more comments. It doesn’t matter if your the only programmer writing comments just for your self will help a lot. Its the simplest thing to do but yet the easiest thing to forget.
C. If you have any limits on your robot, stuff that prevents your robot from killing it self. Program thoughs first, before you test anything make sure those limits work. Its one thing to sitting around waiting for the mech. guys to get the robot done, its something else watching them fix it when it just killed it self.
All the advise mention is great. This being the fourth year being the only programmer on our team(1 FLL, 1FVC, 2FRC). Just remember, its tiring to program but not as tiring as sawing and drilling. So its up to you to keep the energy flowing at all times(just a little something random). Good luck!
I am not completely sure of what you are suggesting here. I think you are saying that the pots will to allow you to tune the PID on the fly. If so, this sounds like a really good idea for people who are not using labview. Labview makes it easy, though (front panel ftw) 
I’m getting off topic here, but this talk about pots has sparked my interest. Assuming that I was correct about pots being used to tune the three values in a PID controller, I have another question (I don’t know much about PIDs, so this might be a dumb question). How do you determine the range of values that you want the pot to give you for the PID? Do you just make an educated guess?
Also, thanks for all the great advice from everybody. I’m starting to feel the old excitement again.
How do you determine the range of values that you want the pot to give you for the PID?
It’s basically an educated guess, based on reasonable gain ranges for your application.
yeah, the same testing problems happened to me. However, I used the electronics board to supplement for the whole board and just used the status LEDs of the stuff to get it to the point where most of it would work.
-Anthony
This is the first year I haven’t been in your situation. What my team did (and what I now recommend EVERY team do) was build the kitbot on day 2 and just left it alone with the programmers. Come week 5 when the mechanical team needs to steal all our precious electronics, we don’t care because we already finished all the moving-base stuff: TCS, camera control, PID control, etc were all done while the robot was in the design + prototyping stage.
I completely feel for you: it really sucks getting blamed for poor performance when its mostly the mechanical team’s fault for not letting you program on the robot. Try to point out that if they don’t give the programmers a few hours on the robot, everything they build will be mostly useless because it won’t be controllable. A slight reduction in mechanical capabilities because of something only partially finished is more than made up by a massive increase in robot control.
If you do get time on the robot though, remember to prioritize. Don’t waste your valuable hours trying to get TCS or camera control working, those take days or weeks to get right. Plus you can keep your control system and tune the camera after ship. Here’s the order I’d work in:
- Basic robot control (1-button, 1 actuator)
- Basic autonomous (drive-straight, drive in circle, etc)
- More advanced robot control (one-button for multiple functions if your robot has them)
- Get the gyro working, then do more advanced autonomous (pattern-running)
- Traction control
- Camera control
Of course, your priorities will vary. A shooter bot would probably have a much higher priority on camera control. But always keep in mind you can keep your control system after ship. If it doesn’t HAVE to be tested on the competition bot, then don’t waste your pre-ship time coding it.
Do you have old robot parts from previous years? We have a small test robot that can be used as a test bed while the competition robot is being worked on.
Knowing that programming this year would be worse than last because of all the changes I took extra steps. I built a plywood box that has a PDB, DSC, 2 Victors, 2 Jaguars on it. The cRIO can be placed in it or removed with only two screws. The ethernet connection is held in place with velcro.
It did require buying an extra PDB, extra connectors, and making extra cables, but I can move things between the real robot and the test bot in about 10 minutes. This allows me to have a development test bed that we can bolt onto a test chassis, or I can bring home. When we ship the robot I will still be able to work on programming, and only the weight of the cRIO, ethernet, and camera will count against the weight allotment.
It is probably too late to do this now, but I would recommend that every programming team put together a system in the off season that can be easily moved and modified. This year we put the slick wheels on the test bot and were programming traction control way before the competition robot was in shape to drive. Sure things needed to be tweaked, but basic testing was done and it was a matter of tuning, not basic debugging.
Don’t forget the withholding limit… perhaps you can hold back parts of your robot, or replicate the drive base, to work on your code after ship date.
Jason
P.S. Oh, year, just for reference… our lead programmer has made a very small request for this year. He would like one hour with the robot, in final configuration, before we ship. He has based that on a couple seasons of previous experience, and we might… just might… be able to give him an uninterrupted hour with the machine on Monday night.