Hi. i have been getting this error on my code, does anyone know why this is caused. also our robot acts crazy sometimes like our chassis or arm or intake acts unexpectadly, maybe this could be the issue?
Profile your code and find out what function is running the slowest.
1 Like
What this error means is that your code is taking too long to run. The robot normal runs all of your periodic functions every 0.02 seconds. Sometimes though the code takes a long time to run and your code may run once every 0.04 seconds or longer depending on the code that is running . What this error tells you is that each periodic cycle takes more than 0.02 seconds.
There are 2 main causes for this.
-
You are running a lot of code. In this case you just have a lot of things for the Rio to process and it is not able to keep up at a speed of 0.02 seconds. As long as this isn’t too drastic (for example if it takes 0.2 seconds per code cycle that is a problem) this should not be to big of a problem, other than maybe the robot feeling a tiny bit sluggish in its actions.
-
There is one part of your code that is taking a really long time. For example one function taking 0.3 seconds will cause problems because the code will wait for it to finish and not continue running while the function is running. There are many reasons this can happen. One example is that applying configurations to ctre motors now waits for a response from the motor. The time it takes for the motor to respond can be long and will stop your code.
So how do we determine which option this is? The main thing we want to look for is whether there are specific functions that take an unreasonable amount of time and how long each code cycle is. To do this try the link @nstrike sent. It will show you how long each function takes. Try to look for one that take significantly longer than the rest. If you find one try to find out why it takes so long and change it so that it will be shorter. If you do not find one check how long each code cycle takes. If it is consistently a relatively small number (say less than 0.05) this should be fine. If not you may want t find ways to make your code more efficient.
Hope this helps, and can help more if you need it.
If this happens occasionally, then it’s not a problem. If it happens a lot, then it will likely cause control lag and unexpected actions.
It’s a little hard to read sometimes, but the log should be telling you which specific method calls are causing the problem. It can help to open your log in the DS Log File Viewer. Look for any entries over 0.02 seconds.
If you tell us which methods are causing the problem (or share your DS log/event files) and share your code, then we can give you more assistance.
1 Like
I was looking for a profiler! NStrike you deserve a medal for the amount of support and good info you drop on these forums thanks.
1 Like
Hi, just to better understand the underlying mechanism. Do you know whether, in this case, the process (thread?) that has been running for too long is stopped or whether subsequent commands are just time-delayed? thanks!
Hi, as far as im concerned they are just time delayed.
1 Like
All commands, triggers, and periodic functions are called from a single thread. (The design intent here is that teams don’t have to worry about thread safety.). If one of these functions is too slow, it will simply delay everything else.
To expand on my earlier message, it’s fairly common to see a couple of these messages when the robot first starts running or changes mode because you often have one-off setup work to do like loading autos and generating paths. If they continue, then you will get control lag, whereby your commands aren’t being run often enough.
We can tell a lot more if you post your DS logs and share your code.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.