(Programming) Lessons learned from week 1?

[jrz126]

Just wondering if anyone had programming issues which caused their bot to fail on the field?

[JewishDan18]

Dont use the CAN bus and make SURE your DS is properly configured if you aren't using a kit one.

[biojae]

Originally Posted by JewishDan18

Don't use the CAN bus.

Can you elaborate on that point a little for me?
Serial or 2CAN and which programming language you used?

My team used the CAN bus successfully last year (with Java), with only a few hiccups along the way.
We have only lost 2 Jags in the 3 years that they have been First legal, one (Black) which we will be RMA'ing shortly and the other (Tan) which was killed by metal shavings.

There are a few things that can still be improved with the libraries, (Exceptions and Error checking), but for the advantages that using the CAN bus have given my team out way the disadvantages.

[DonRotolo]

It would be wise to use the CPU status monitor to verify you are not maxing out the CPU. We had a failure on the field once which we attributed to CPU overload.

The regular symptoms are all the outputs of the cRio go dark for about 1/2 second, at a random interval between 10 and 30 seconds or so. The lights on the cRio, DSC and PDB stay solid, but the jaguar/victor/spike indicators blink off in unison. During match play/driving it's hardly noticed, but once we feel it was responsible for a momentory loss of control at a critical moment.

We removed some unnecessary code, but have yet to really analyze the code for inefficiencies. Our code was completely student-written, and the adults can't easily discern how it works yet, but that'll happen this and next week. (Student coders often lack discipline, elegance and efficiency, often whacking problems with brute force in convoluted and hard-to-follow ways. Max.)

Greg from NI helped us understand what to look for, and my team and I are grateful to NI for sending him to NJ, and even more grateful to Greg for consuming one of his weekends to travel from comfortable Texas to frozen NJ just to help FRC teams.

[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