Today I finally pinpointed the issue I have been having with the standalone Cockpit program. Cockpit seems to work fine up until the DVL is activated, then cockpit effectively stops working.
I recorded the screen with my phone (quality is a bit crap) but does document the issue.
https://youtu.be/HaeBak72wFE
DVL is a Cerulean Tracker 650 which works absolutely fine in QGC.
Hopefully thereâs an easy solutionâŠI just ordered a Tracker 650 a few days agoâŠ
Hi @3dMB -
This is an easy fix! You are using DVL software that is NOT intended for use with the Tracker 650, but a no longer offered product.
Check the documentation for proper setup - I like this DVL because it doesnât require an extension, and âjust worksâ ! You can install Cerulean Tracker (windows only unfortunately) software to monitor the DVL, update the firmware, and even fuse position estimates with their ROVL system.
Iâve found no issues with Cockpit and the Tracker 650 DVL, and been working on methods for measuring drift so operating it for long periods. Definitely update to version 1.6, the standalone version brings a couple advantages with respect to video recordings (now in a Cockpit folder in your home folder once processed, without having to download) as well as update prompts from within the program.
Itâs also worth noting that Edge is not a supported browser for BlueOS or Cockpit - please use Chrome for the best results!
thanks Tony, I shall try the Tracker standalone software and come back to you.
With the Cerulean DVL BlueOS application, do you know if I can still set location with the map then switch to the desktop app without any issues? I ask as the desktop software seems to only allow for typing in Lat/Long.
Hi @3dMB -
Yes, completely uninstall the extension you have for the DVL-75. It and its map cannot be usedâŠ
Unfortunately, setting position is only accomplished with the Cerulean Tracker app via lat/long coordinate, yes, not by clicking on a map. If you need a map, both google earth and google maps let you get the coordinates for a point!
Interestingly this does solve a limited amount of issues.
Uninstalling CeruleanDVL BlueOS Add-on does allow for Cockpit to function more reliably while having the DVL telemetry within Cockpit with mini-widgets - this is until I send the location data to the ROV. Using the desktop Cerulean Tracker program to send the coordinates to the ROV causes Cockpit to lose connection completely and Cockpit does not recover. Cockpit seems to work (almost) fine upto that point.
I say âalmostâ above as I have had other issues with cockpit where Ill be moving the ROV then suddenly on camera it looks like the tether has snagged by the camera raising, what has actually happened is that Cockpit has lost control connection and the thruster instantly stop, drag then causes the effect. Note that video remains throughout both situations above, it is the control side that is affected.
Surftrack - This is the next thing I have had issues with. Having not inputted the location with Cerulean Tracker (so cockpit seemed to be behaving), I initiated Surftrack (all setup as per instruction using the simple version that is included in Cockpit), the ROV is happily moving along at around 2m altitude then the ROV loses altitude and nearly hits the bottom, I compensate with âupâ on the thrusters back to altitude, then it loses altitude again and hits the silt at a fast vertical speed. I went back to depth hold after this. I donât have a video recording of the incident, I do however have the photogrammetry image data which is in the following video with 45 degree oblique and nadir images captured 1s apart. I used the Surftrak Fixit extension before launch and everything showed good. The only thing I see different between the Surftrak fixit and my setup is that Surftrak states Waterlinked DVL, I have Cerulean DVL. As they both supply data to MavLink I assumed them to be them to both be fine. Is the Cerulean not good with Surftrack?
The Surftrak crash images can be found here: https://youtu.be/gH3z541wCTU
Hi @3dMB -
SurfTrack and Cockpit shoudl work flawlessly with the Cerulean Tracker 650 - I have been testing it extensively, firsthand!
Iâve not encountered your issue with Cockpit losing control - I would guess something is going wrong with however youâre sending position to the vehicle. Can you elaborate what youâre doing there? No NMEA injector is necessary. What version of Cerulean Tracker are you using? 2024-10-24 is the latest version - itâs good to make sure your DVL firmware is fully up to date as well.
How do you use Cerulean Tracker to send coordinates?
If the tracker loses altitude estimate, SurfTrack does seem to have a bug that will cause a crash with the bottom - Iâve witnessed this with several different vehicles, using both the Ping sonar for altitude as well as a DVL A50.
SurfTrack is a ArduSub feature, not specific to Cockpit.
Can you also share a screenshot of how your Autopilot serial ports are configured? This can be found under Autopilot Firmware.
Hi Tony,
I am using Cerulean Tracker 2024-10-24. The output tab is setup exactly the same as your screen grab.
I am sending coordinates from the DVL Command Window âDVL Positionâ section as shown below (note that the ROV is not connected at time of screengrab, hence boxes are not populated with info)
I am not using a ROVL so am using pure dead reckoning. As recommended by you above, I used google maps to gain lat/long info, I then paste said info into the DVL position box, then click âset DVL positionâ. The console shows that it in turn sends command SET-POSITION followed by the pasted lat/long data. The map in QGC/Cockpit then changes and shows the correct location.
I tried setting location both before and after launching the ROV but ultimately both scenarios made cockpit lose control. Quitting Cockpit and booting up QGC regained control immediately.
Serial port configuration, I will screen grab this tomorrow.
Hi @3dMB -
As I suspected, there is one key difference in how Iâm using the Tracker650 and how you are - I have setup Serial2 to receive the data, and you are perhaps using the NMEA injector?
The documentation notes:
ArduSub is very complicated and does some unintuitive things. If you send NMEA-formatted GPS position information to ArduSub, it will disable the ability to use position hold and dead reckoning based on DVL inputs. NMEA data could come from a GPS on the same network, or it might come from CeruleanTracker if you fail to turn off NMEA outputs as described here.
Please disable any NMEA injectors you have setup, and put the following line in the Serial2 entry above.
udpin:0.0.0.0:27000
Then, make sure Serial 2 protocol is set to GPS under Autopilot parameters, and that no other Serial#_function is set to GPS.
I think whatâs been happening is the ArduSub system is disabling things when the position information is sent. Have you used position hold flight mode with the DVL active yet, and had good results? I honestly have been getting more value from that then relying on geographic position coordinatesâŠ
Thanks Tony, alas most of what you have said means nothing to me.
I have the DVL plugged into the ethernet switch. I have set the ardusub parameters as per Cerulean setup instructions.
I am sending the location lat/long through Tracker as detailed above.
I do not know what you mean by âNMEA outputsâ or âinjectorsâ or how to disable them.
Tomorrow I shall try entering âudpin:0.0.0.0:27000â into Serial2. Assume this is merely typed into the serial2 dropdown box as seen in the screen grab?
I have used position hold with some success (in QGC), during recovery I will have the ROV close to quay, enable position hold while I reel in excess tether - the ROV keeps location.
Inputting position coordinates means I can see my track on the map so when scanning I know where I have been. It also means I can avoid known snags.
Tony, you will see in the screen grabs that Serials 3 & 4 protocols are set to GPS - what should I change them to, please?
The first time I launched today, Cockpit was absolutely fine while going through surface checks, then as soon as the ROV hit the water, Cockpit lost control. I then recorded the next effort on my phone as in the following linked video (apologies for the portrait video, it was the only way I could prop the phone). In the video you will see that the ROV is fine on the surface, then when it hits the water it continues to work up until I try ot change mode, then it noses up and loses control. Moving to QGC and full control is regained.
https://youtu.be/W2ete3ot1wU
Hi Marcus -
Thanks for the video!
The vehicle refusing to go into position hold mode indicates the autopilot is not receiving data correctly from the DVL. This is likely because serial 3 & 4 are set to GPS - as stated, only one serial#_function should be set to this, the others should be set to disabled / none.
Your video also seems to pause more than I would expect. Are you running a different unit than the standard low-light USB camera? Running a bandwidth test, checking the tether signal quality with the tether diagnostics extensions, and turning on the âstats for nerdsâ under the video widget settings (Cockpit â edit interface â gear icon next to video widget in upper left) may help us tell what is going on to cause that.
Was this test performed with the udpin line pasted into serial2 under the Autopilot Firmware menu? Itâs important to click save after doing thisâŠ
Thanks Tony.
I will next be in the water on Thursday or Friday.
I shall change Serial 3 & 4 to disables/none.
I am running the standard camera, however, I also had a Mirrorless DSLR testing over Virtual Here as per your suggestion a while back - this no doubt will be causing the lag - I will however add said widget next time.
This test was performed with the udpin pasted into Serial2.
Hi @tony-white, back on the bench today implementing the steps you provided above. The udpin⊠line in the serial ports kills the DVL & Tracker app. Please see recording:
Another screen grab below showing the âstats for nerdsâ with and without the EOS running g through Virtualhere
