Kinect, cRIO crashes, and RetVal 3
 

We've been having a few issues getting our kinect code (in Java) and cRIO to work properly this year. The first issue we had was when our code accidentally called the cancel() method of a command that had not yet been instantiated. Before we got the usual NullPointerException and "Robots don't quit", the robot locked up and continued to leave all outputs in the state they were in when the error happened. As the robot uncontrollably drove forward for about 2 seconds, it printed the cryptic error message "RetVal: 3" several hundred times, then stopped and printed the stack trace. All motor control outputs were disabled, but relays remained on.

After fixing the mistake, we thought we resolved the problem, but we again experienced the RetVal: 3 message again, which appeared in netconsole about 10 times, and lost communication with the robot. This happened several more times throughout the night, and the cRIO boot time began to increase after each code change. Reimaging did not solve the problem.

Our kinect code creates a kinect stick, then calls the getY() method on that KinectStick. The only time we read values from the Kinect are during the disabledPeriodic method, but all crashes happened when the robot was teleop enabled.

Re: Kinect, cRIO crashes, and RetVal 3
 

Are you using the Cypress PSOC?

Re: Kinect, cRIO crashes, and RetVal 3
 

No. I think the problem has something to do with the KinectStick object. The problem appeared when it was added, and I haven't seen it crash when the KinectStick was removed.

Re: Kinect, cRIO crashes, and RetVal 3
 

IIRC, in 2012 teams solved these kinect problems by plugging in a cypress i/o board and setting it to advanced mode.

The kinect code (and way over complicated driver station communication code) is somewhat of a disaster. We've seen our fair share of random communication issues with even the sample software. Looking through the WPI source, they've left a few interesting comments, like "//temporary hack for 241", which I'm sure made sense to the person writing the software at the time, but doesn't really help.

The issue is with the mystery method "getDynamicControlDataFn.call4() , which returns a mystery value of three (not 0, 1, 2 that is shown in the comment).