(Programming) Lessons learned from week 1?

[jmanela]

For some reason, we were having trouble with the holomonic drive vi. During all of practice our drive was working fine. There were no troubles at all. Then all of the sudden, at the competition our robot begins to lose code every once in a while. We got an error message stating that we were starving the code, however when we got rid of all code that was unnecessary we were still getting the same problem. We decided to run a blank labview project just to test and see if it had worked out of the box, and it did. Then, I replaced the standard tank that the project comes with, with a mecanum Cartesian drive vi. We got the same message and received our robot would occasionally lose code as it ran like it used to. We ended up writing our own version of a tank using strictly motors and that worked. however, we still don't know why the mecanum drive would not work.

Our programming mentor suspects it had something to do with the safety config vi, however, I read up on it and if i read correctly it would just stop the motors if they didn't recieve and input within a certain time period. However, our problem was quite the opposite where all the values on our robot would stick when we lost robot code for the quick times that we did.

Any ideas?

[Greg McKaskle]

I had a great time in NJ and met quite a few people face-to-face that I otherwise wouldn't be able. It is good to mix things up.

The things I saw in week one which are easy to learn from... not necessarily code related...

1. Connect the dlink properly. Connect it to the boosted 12V on the end of the PD marked for the radio, not to a typical red/black fused 12V circuit. Also, I'd suggest using the voltage regulator. If you do not do this, your robot will lose communications whenever it starts pushing another robot and power droops.

2. Run your code through a practice match on the DS. A number of teams using Java or C++ had code which didn't leave auto. It worked fine if you only test tele. It may even work if you only test auto. The field sequence is what you care about and the DS practice match is a good approximation to that. We also saw teams who's auto managed to cause errors in tele.

3. If you are using CAN, pay attention to error handling and to cable termination. Errors that aren't handled well and aren't reported to the field may take out much of the robot and cause lots of debugging confusion.

4. Know what the latest update versions are and check to see if they have been applied. DS should be 1-05-11 or 2-27-11. Robot should be v28. You may need development tool updates as well, and I'm not listing all of those.

5. Don't disconnect the cRIO from the dlink. Direct cable the DS and development computers into the dlink. If you disconnect the cRIO, you will forget to reconnect. You know you will, so just leave it connected at all times.

6. Pay attention to the switch on the back of the dlink. It should stay in bridge mode for the competition. If it gets knocked to auto or AP, your robot will disconnect or not connect at all. Also pay attention to the barrel power connector to the dlink. If wiggling it causes the dlink to reboot, this will also happen on the field.

7. If you are using the M1011 camera with C++, be sure to get the WPILib patch.

8. If you use LV, and your CPU usage is high, move the compressor code to Begin. Turning it on each teleop packet adds more overhead than you think. The code was written to be started in Begin.

Greg McKaskle

[biojae]

Originally Posted by Greg McKaskle

3. If you are using CAN, pay attention to error handling and to cable termination. Errors that aren't handled well and aren't reported to the field may take out much of the robot and cause lots of debugging confusion.

What errors are reported to the Field?
Could a change be made to the CAN library to report CAN errors to the Field?

[BradAMiller]

This thread is great, it was very disappointing to see a team missing a match because of some software version mismatch or something else easily fixable.

We also started making a list of additional things here: http://firstforge.wpi.edu/sf/wiki/do...b/wiki/Lessons that might be useful to teams. This list will get updated as we get more feedback.

Good luck at the regionals!

[Greg McKaskle]

What I meant by reported to the field was reported to the drivers via the driver station or dashboard. If CAN errors were printed to the dashboard or DS, it would have helped pinpoint the issues much quicker.

Greg McKaskle