We’re currently having a problem with our robot where it rdqs at the end of every autonomous period, forcing us to re-enable and costing us time on every match. Has anybody experienced this problem before? if so, what did you do to solve it?
I’m not familiar with “RDQ”. What’s that mean?
3 Likes
I assume they are talking about “Robots Don’t Quit” that pops up when an exception gets thrown IIRC
Does this happen if you run a test match on your driver station?
That is usually a sign something is throwing an exception. Anything further up in the logs?
3 Likes
Like mentioned before, likely an unhandled exception. Are you declaring a variable and then using it without initializing it? Are there objects being called after auton and in teleop that haven’t been created?
You need to look closely at the stack trace to find out where it is happening. A common cause is that you try to use an object that you never created.
If you post a screenshot of the stack trace here and a link to your code (e.g. on Github), then we can be a lot more help to you.
5 Likes
As far as I know, the error is just a general unhandled exception error, without pointing to anything specific.
I believe so
As far as I know, we re-create all of our objects at the beginning of teleop, we looked over the code and didn’t see anything.
Don’t have acess to the robot currently, and I think that we’ve decided to just try to work with it untill the end of competition now. Once we’re back in the shop, we’ll try to nail down the problem further.
I strongly recommend storing your code on GitHub or something similar – it’s always good to have a backup of your code.
1 Like
If you’re reallocating everything in teleop, after allocating it in autonomous, then you’re likely allocating the same HW twice and the stack trace should tell you where. Reading Stacktraces — FIRST Robotics Competition documentation
See, for example, this thread, this one, and this other one. I don’t think they’re related to your problem, but they give examples of the exception and stack trace that are key to debugging this type of problem.
After the “Unhandled exception” message, you should see the specific error (e.g. NullPointerException), and then in the next line you see the method, file, and line number where the error occurred.
It is on GitHub, I just couldn’t test to see what error it was.
1 Like
UPDATE
We solved the problem. It turned out that we simply had a typo, and at the beginning of teleop we were trying to define an object that didn’t exist. For some reason, VsCode didn’t flag this error.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.