Hi @3dMB -
Sorry I haven’t had a chance to compare your parameters to my own that work fine with Cerulean DVL.
It is possible to reset to default parameters from the BlueOS Vehicle Setup page (configure → parmaters) - you may want to backup to preserve your thruster directions and sensor calibrations first!
Today I put the ROV back in. I was running the most current version of cockpit. I have restored default parameters - except the parameters that Cerulean suggest in the Tracker 650 setup. I enabled position hold mode and the ROV went charging into a quayside - certainly not a position holding pattern…
Hi @3dMB -
Without a log file / knowledge of what versions of software you’re using it’s hard to provide much in the way of troubleshooting advice!! The .BIN log file, found under Autopilot Logs in BlueOS will contain the parameters you’re using.
If you reset to default parameters, you may need to calibrate your compass/accelerometer/gyro before any automatic navigation will work. If you’ve setup all your autopilot parameters per Cerulean’s documentation, and calibrated the ROV, things should just work! Have you made any change to default IP addresses?
Hi @tony-white, today I put the ROV back in for DVL testing (which I am consulting Cerulean), running cockpit. Before the dive I updated to the latest version of cockpit 1.15.2. Part way into the dive I put the ROV in manual control mode and just left it be - to show the DVL messages. Shortly into the manual control period, cockpit lost control “MYGCS 255 Heartbeat lost”. I was unable to regain control using Cockpit and the ROV sank. Failing the ability to regain control I opened QGC which happily took control.
I am also using the most up to date BlueOS and Ardusub - all checked before the dive.
I happened to be screen recording for the dive HERE - at just after 7mins in, the control loss detailed above occurred.
The parameters are all as stock due to new install - except the parameters stated on the Cerulean page - all sensors have been recalibrated since new install.
Hey Marcus! Could you get us the BlueOS logs from that dive? They will probably explain what happened.
Hi @rafael.lehmkuhl - according to the modified times it should be one of these two.
00059-2025-05-24_09-03-51.tlog (690.7 KB)
00061-2025-05-24_09-05-45.tlog (4.6 MB)
@rafael.lehmkuhl my bad - try this:
system_logs.zip (8.9 MB)
Thanks @3dMB! I can see an automatic restart on the autopilot manager happening at 14:30 UTC. Do you remember if the time matches your tests? It indicated something went wrong with the autopilot process and it tried to recover.
@rafael.lehmkuhl - no, according to the screen record, the issue happened at 10:13 BST (09:13 GMT/UTC)
@3dMB I couldn’t find any clear problem in the logs. I will ask for help from @tony-white and @williangalvani on that since they have DVLs and know better about their behavior.
In the meantime, I’m adding some new debug tools in Cockpit so you can know what Cockpit is sending/receiving, and also what the mavlink router is exchanging. This way we can better know where the problem is.
@rafael.lehmkuhl Just a thought, how does the Pi/Navigator update time for the log? Does it set it automatically down the tether from the topside computer or does it need an internet connection? If the latter, the restart you spoke of at 14:30 could be the same event. If the former, then the time displayed on the topside computer is definitely the time the event occurred.