yesterday I took my BR2 on its second voyage and on numerous occasions Q Ground Control was telling me “Bad loop slippage detected”.
Any ideas what that means? I have googled and searched the forum with no answers.
Hi @3dMB,
I’m glad you asked this - someone else ran into the same problem recently, so it’s still fresh in my mind from that internal support discussion.
Basically the error occurs when an iteration of the autopilot’s update+control loop takes longer than expected, which can happen if other services or Extensions are taking up too much CPU time.
Currently ArduSub is running with a significantly faster control loop than it needs to for the vast majority of vehicles (underwater vehicles typically move much more slowly than aerial ones, and momentary control failures are less consequential), so missing a cycle every now and then shouldn’t have much impact on the vehicle operation, but if it’s frequent then it’s worth checking the BlueOS System Information and Extensions (Installed) pages to see whether anything is using excessive amounts of CPU.
In terms of solutions we’re looking to better isolate the autopilot process from the other programs in BlueOS[1], but if the error is getting annoying it should help in the interim to reduce the SCHED_LOOP_RATE parameter (50Hz should generally be fine).
potentially by giving it a dedicated CPU core, or at least allocating it a fixed portion of one ↩︎
1 Like
I’m only running ping2 & ping360 - nothing else. Could this be rectified by running the ping360 through Ethernet switch instead of USB into RPi?
Bypassing the Raspberry Pi for the Ping360 connection could reduce its CPU usage somewhat, but the loop slippage occurs when there’s insufficient CPU time available for the autopilot, so if there are other services or Extensions that are the main culprits of that then the extra capacity from avoiding Ping360 data passthrough could be insufficient / relatively insignificant.
The most valuable tool when approaching computer performance issues is a profiler, which is what the System Information and Extensions pages are for - they provide information about which programs are using the most CPU, which should help to narrow down what’s likely causing the issue, and may help to determine what can be done to mitigate/avoid it.
As mentioned though, reducing the autopilot’s control loop rate should help, without causing issues for your operating experience.
Got the same situation, while in any modes except for manual and stabilize, BAD LOOP SLIPPAGE DETECTED warning pop up, and continiosuly “ddos” attacking QGC such that it freezes and crashes, decreasing to 50hz,100hz doesnt help at all. Put in 200 and 300 decrease it to the 1 message per 5-10 seconds.
Any thoughts, it was never before there.
Got latest fw Sub and BlueOS
Hi @nurjan14 -
It you are receiving the loop slippage message frequently, it is likely that your Raspberry Pi is very busy with something! Can you share what extensions you have installed? Are you running any other non-standard software onboard?
Sharing the BlueOS log files, accessed via the gear at the bottom of the left menu, would be helpful in troubleshooting your issue.
I can share it later, but in nutshell its a BlueOS DVLA50 waterlinke extension and ROS extension. The only thing which is “non standard” I say its a extension for a ExplordHD underwater camera, DWE_OS DWE_OS - Starter Kit.
I have connected their 7 port multiplexer via USB3.0(raspberry) to type C (multiplexer) and I have 4 camera but they where never initialized for a stream.
The defualt bluerov USB camera is working but I found just today that it’s not working as well, and I am getting the error “cannot acivate stream without state”
That’s weird as it was working before with a DWE_OS and arudsub. The only thing is different is BlueOS, I reflash the new microSD card, as previous one was corrupted.
Here is log file from the BlueOS
Hi there,
Any updates on this?
.
Hi @nurjan14 -
We reviewed your logs, and don’t find anything strange. We’ve also run the same setup with ExploreHD camera and the DWE extension - no issue!
Can you make sure you’re on the latest BlueOS (1.2.4) and running the latest stable Ardusub (4.1.2) ?