cant run the robot

Technical C/C++
1

We are having a very annoying problem with running the robot. This problem happens spontaneously (in our perspective) and we couldn’t figure out for several days what’s the cause of it.

First we connected the router, and it says on the DS:


Warning <Code> 44002 occurred at Ping Results:  link-bad,  DS radio(.4)-bad,  robot radio(.1)-GOOD,  cRIO(.2)-GOOD,  FMS-bad Driver Station

we tried to switch it to 5GHz instead of 2.4 in the radio but we couldn’t do that (the computer didn’t find the 5GHz rauter).

When we connect it with Ethernet cable locally it said on the DS:


link-GOOD,  DS radio(.4)-bad,  robot radio(.1)-bad,  cRIO(.2)-GOOD,  FMS-bad Driver Station

When we ran the simple robot template it almost always run, but when we add complex stuff such as gyro, PID turning, and SmartDashboard values the following error appears in the DS Diagnostics messages:


ERROR: A timeout has been exceeded: RobotDrive... Output not updated often enough. ...in Check() in C:/WindRiver/workspace/WPILib/MotorSafetyHelper.cpp at line 117

We tried to eliminate some of the complex code and sometimes it worked sometimes not. When we rebooted the cRio / the whole robot it more likely didn’t appear again for the next severals debugs but then when we added new code for example, it happened again.

We think that it happens before the constructor of the RobotDemo when in the constructor the RobotDrive [we added there 4 talons, in the constructor we wrote: myRobot(talon1, talon2, talon3, talon4) – where each talon constructed by: talon1(1).] - this is because when we added SetSafteyEnabled to false in the constructor and in the operator control, the problem still appeared, and we couldn’t reach to the main code in the while loop.

We raised some stuff that could make this problem like not very good communication (but it also happened when we connected it locally with Ethernet), smartdashboard slowing the code, or maybe wrong

2

The “good/bad” indications in those first two messages look perfectly fine to me.

If you don’t have an active wired network connection, you’ll see “link-bad”. If you aren’t using a separate wireless router on the DS, instead using built-in WiFi of a laptop, you’ll see “DS radio(.4)-bad”. If you aren’t connected to a competition Field Management System, you’ll see “FMS-bad”. If you are connected directly to the cRIO without going through the D-Link router, you’ll see “robot radio(.1)-bad”.

So everything looks the way I’d expect based on how you said it was set up.

The final message is warning you that your code is taking too long to run each time a driver station data packet arrives. If you can parallelize the complex processing so the motor control can occur without being delayed, that will help.

3

thank you for your answer.
we found out something wired: the first time we run the code, everything seems fine but if we try to run a different code, we get the timeout error. after reboot, everything work again for the first time.
do you have any idea what cause this problem?

4

I am other teamate and I want to add it is the simplest code possible.
even code of driving and turning.

5

Without seeing your code, I can’t give good advice. The best I can tell you is that you don’t want to add any long-running loops to the operator control function.

6

here is the code:

*the project name doesnt refer to what it does. more correct name will be : “Drive_With_Joystick”

DriveInCircle.zip (2.02 MB)


DriveInCircle.zip (2.02 MB)

7

the .Doc file describes all the problems we had, the archives contain some pics of them

problem with the codes.docx (406 KB)
Pics part 1.rar (797 KB)
Pics Part 2.zip (4.25 MB)


problem with the codes.docx (406 KB)
Pics part 1.rar (797 KB)
Pics Part 2.zip (4.25 MB)

8

The Target Exception (“Exception in Kernel Task New Context”) error seems* to be at the center of your problem. I’m not experienced enough with the C++ tools to suggest what to do next. Is someone else following who can give this team some assistance?

  • unless I’m totally off base and that error is actually expected when terminating debug
9

We’ve noticed something weird about the processes which run when we debug a simple program (just Talons and an ArcadeDrive with joystick).

Our main problem is that the code runs the first time very well, but then when we terminate the code (in the debug window) and debug again the same code - without rebooting the cRio - it doesn’t work.
We thought it was a problem with the cRio - like an unproper deleting of memory from the cRio between uploading the two (same) codes.
We’re are about to replace the cRio and try the code with an other (but an old version) cRio.

Anyway, we’ve found an other clue about this problem.
When we run the code for the first time, the processes on the debug window are as seen in this picture:
normal

In the times after that, when we ran the code without rebooting, there was the same error of
ERROR: A timeout has been exceeded: RobotDrive… Output not updated often enough. …in Check() in C:/WindRiver/workspace/WPILib/MotorSafetyHelper.cpp at line 117
As you can see in the following picture, only one process run in the debug code.
error

Also, we located a breakpoint in the operator control function and we saw that the code doesn’t even get to the while loop, somehow it stucks before it.
(In the first time it did get to the while loop in the operator control)

What are those processes and how does the lack of processes in the debug window related to the not updating the motors to often problem?
Maybe two codes run together because the last code wasn’t deleted, or is there another reason?

We would thank you if you’d give us advices.

GreenBlitz 4590