We are having intermittent (every 10 - 20 second) episodes of the following:
RSL flashing pattern changes with a single pulse on lasting a half second longer than the usual flashing pattern. This is the only component that seems to flash on instead of off.
No changes to the radio.
Mode light on the RIO flashes off for 1 second.
Otherwise no RIO changes.
All Sparks flash off for less than 1 second.
All solenoids flash off for less than 1 second.
PCM red LEDs flash off.
PCM status light does not change.
PDP does not change but we have a sticky fault (flashing yellow) at all times.
Compressor turns off for less than 1 second.
We have tried everything. We believe it is code related because it is so regular and unrelated to robot movement (happens with the robot still)
Any help would be appreciated.
Thank you
Test running default code instead of your own to make sure that it’s just your code that’s causing the hangup.
Check your Driver Station log (Driver Station Log File Viewer) to see if the red CPU line is maxing out.
Check the Log Event List, too, for repetitive errors or floods of error messages (also visible in the DS message window).
It sounds like some place in your code is periodically taking all the roboRIO CPU resources.
Language?
Code?
I also think you should see if the log is seeing comms issues and disabling the outputs. At our school on 2.4 GHz, it is not uncommon to see the DS chart have almost periodic patches of lost packets. Looking at wifi availability, there just isn’t that much bandwidth and when students start watching video or downloading large files, that will sometimes use up all available bandwidth and cause delays in wifi.
If the logs show this as the case, see if you move to 5GHz.
Another issue that I’ve seen before is that the laptop was periodically leaving the wifi channel to scan and update the list of available APs. This was at a ~60sec period, and it was a driver setting. I don’ know if they were able to find a workaround.
Greg McKaskle
Are you tethering to the robot or using wireless? If you are using wireless, does the problem persist during tethering?
By this do you mean that the lights are shutting off? Or do you mean that function stops as well? For example, if you are driving forward and this occurs, will the robot stop?
Please try to clear this sticky fault. See if it comes back. If it does, you have a problem.
This to me sounds very strongly like either brownout protection mode or automatic disable from loss of control packets. I agree with all the others saying to check your DS logs. You will want to look at your battery voltage, CPU usage, and network traffic graphs. You should also check the messages to see if watchdog was ever active.
The Driver Station does not show the CPU maxing out at all.
The problem occurs at about 12-18 second intervals.
The robot only has trouble operating for about a second, but the log shows that we have around 75% packet loss for about 5-6 seconds.
During the 5-6 seconds of packet loss, we also lose about a 10% of our CPU.
Regarding the code, we are programming in Java and I am not sure what exact code you would like to see, as we are not sure where the error is occurring.
Thank You
Have you tried this yet:
It could be interference with the local wifi environment.
It could also be a process on the laptop, like an update service, that keeps periodically disrupting the robot communications.
Try setting the robot radio to use 5Ghz as Greg suggested (if your laptop supports that).
You can also watch the Windows task manager processes to see if something is popping to the top of the queue in the same period of time.
Or try a different laptop to see if it is something particular to your PC.
The answer is all of it (Everything under the src folder at least). If you are uncomfortable sharing all of your robot code, then you greatly limit how much we can help outside of hunches from past experiences and maybe asking for log outputs.
Additionally, I further support trying to run the defeat code on your robot to see if the problem persists.
Does your problem fit this description?
In particular check my post. We are having a similar issue where periodic loss of wifi packets causes our robot to briefly disable and then re-enable.
Default code had the same problems.
We updated the PCM and PDP firmware and finally cleared the sticky fault on the PDP. The motor controllers, solenoids and compressor are no longer cycling off and the robot is functioning without the brief power losses.
The power losses were noticeable, making the robot stop moving and the compressor stop for less than a second. That is now gone.
However, the packet loss episodes continue, occurring every 15 seconds or so.
We switched to 5 gHz but they continue.
We are trying to clear all the old wifi history on the computer to see if it is looking for them for some reason. Also trying to get another computer setup to use but having trouble finding time to do everything.
Task manager shows decrease in the dashboard cpu use but does not show a spike in any other activity.
We have no problem sharing all of our code (you would have to be crazy to use it), unfortunately I am unable to do it right now.
fovea1959 It sounds like a similar problem, but ours is much more frequent.
I cannot tell you how much yall’s help is appreciated. We have made amazing progress in a short time thanks to your help.