New BlueOS or Ardusub causing delay at about 2 hours into dive

Yesterday I took one of the ROVs out with a fresh install of the new BlueOS, new cockpit for steam deck and new ardusub (4.7.0). At around 2h into dive 1 the ROV started acting like a drunkard, with delay in reaction to command. After changing battery, reboot etc, on the second dive exactly the same happened again at around the 2h mark. When this happened on the second dive, I started fault finding. I turned off the steam deck and used cockpit on the laptop, which initially seemed to rectify the issue, but then was hit with many loss of connections and disarming. A reboot of the ROV cleared all faults and normal operation resumed.

I am running a Cerulean Tracker650, which the new ardusub was meant to fix issues with?

See video below of delay in yaw:

Hi @3dMB,

The latest stable ArduSub is 4.7.0, and was released quite recently.

After that was released there was a bug found where Linux-based flight controller boards (like the Navigator) needlessly throttle their communication, which is especially impactful in advanced setups with positioning sensors. That issue has apparently been present for over 11 years, so won’t be possible to just roll back a version to resolve.

A fix has been included in the latest Dev firmware, which you’re welcome to try. In terms of releases, 4.7.1 is currently in beta but does not include the fix (it missed the window for inclusion) - it’s instead expected to land in 4.7.2, likely starting availability in a couple of weeks from now.

Ah yes, that’s the one - have corrected above.

If you refer to this?

If so, that is what I have been running, which shows as v4.7.0(stable).

I am unsure if the issues were from BlueOS update or Arduous update, but the issues were not present before when running 4.5.7 AND BlueOS 1.4.3, with the same hardware.

I am going roll back to 4.5.7 & 1.4.3 as was the last stable combination, then add one at a time. Alas this will take a few weeks now for me to test.

That was the fix, but the custom build you’re referring to was built on top of the 4.7.0 stable (which is why it shows up as 4.7.0, despite not being the actual stable release). The fix has been accepted and merged in to the development branch, so if you install the latest Dev firmware it will show up as 4.8 and will include that fix (but the custom build should be ok too, I believe).

Ok, let us know if you find anything - the behaviour sounds like quite a problematic bug, so it would be great to track down if it’s possible to do so.

I would note that it’s also potentially a Cockpit issue (or an integration issue between the different software components), so that version may be important too.