Dear BR Community,
I recently had a total communication loss to my BR2 while diving in ‘depth hold’ mode and pulling the ROV out of the water with ‘depth hold’ active was not fun.
I was wondering if anybody figured out how to activate a safety mechanism that disarm the ROV or turn the depth hold mode off when communication is lost with QGC? I tried to use the pilot input safety trigger with a 90 second threshold but it doesn’t seem to work.
Thanks,
Cosimo
Our BR2 disarms when coms are lost …
My RR2 disarms, and starts to slowly ascend to the surface (slightly positive buoyancy) with loss of comms. Check the Safety settings.
Guys thank you for the reply. I am still having the same issue. If I pull the usb cable from my laptop with the BR2 in depth hold mode, it will stay in depth-hold mode. I have activated both the Heartbeat Alarm and Pilot Input Alarm in the safety settings and restarted QGC but didn’t change anything. Does your BR2 disarm when you pull the USB cable from your laptop?
Thanks!
@Portoferraio Please post a screenshot of what your safety page looks like. It should look like this with default parameters loaded:
Hi, we have a similar Problem. When disconnecting the tether from Surface PC the BlueROV2 won’t disarm!
Safety settings are the same as in your screenshot. We have upgraded to latest Firmware 4.0.3 and reset all configuration parameters to default but the issue persists.
Can you tell as please what else we could try?
Best Regards
Chris
I’m testing a disconnection here with companion v0.0.26 and ardusub v4.0.3. The failsafe is working as expected.
For anyone who can reproduce this issue, please post a parameter file, and a copy of the settings at http://192.168.2.2:2770/mavproxy. Here’s mine:
@jwalser
I am in a team with Chris,
here are the screenshots from the Safety Setup:
(I am a new user and can only upload one media per post but the safety setup is the same as the one in @jwalser picture)
and the Mavproxy Setup:
Also here is the link to the parameter file in my one drive:
Hi @jreich, welcome to the forum 
Your parameters and settings seem to match what @jwalser was asking, except that you’re currently on ArduSub 4.0.2.
Would you be able to install companion 0.0.26 and ArduSub 4.0.3 and then upload a dataflash log after reproducing the issue? Assuming the issue is still happening, it could also be useful if you’re able to provide a dataflash log for ArduSub 4.0.2, and possibly also a different version of companion (maybe do 4.0.2 first since you’re already on it).
Hi Eliot,
thanks for welcoming to the forum.
I tried both Ardusub Versions, 4.0.2 and 4.0.3 with companion 0.0.26 and was able to reproduce the issue. The flash logs are in my public onedrive folder (link from last post).
I also tried downgrading the companion image to 0.0.22 and reproduced the error with Ardusubversion 4.0.3.
Thanks for any further help.
Hi @jreich, thanks for those logs. I’ve raised this as an issue on the ArduPilot github:
and asked @jwalser and the rest of our software team to review it.
@jreich please run the ROV for a minute, then retrieve the file located at /tmp/telemetry.tlog (it is erased when you remove power from the ROV). You can use the file browser web interface at http://192.168.2.2:7777 to download the file from the ROV.
We are not able to reproduce this behavior here, the failsafe is apparently working as expected. It seems that there is some source of mavlink heartbeats on the ROV itself, that we are not expecting to be there. Please tell me what sort of sensors or attachments your ROV is fitted with. Have you added any of your own equipment like a brushless gimbal or smart battery? Or are you running your own programs on the raspberry Pi?
Hi Jacob,
@jreich and I have experienced the issue on the real ROV first. Our only modification is that we have added a small 3-port network switch inside so that the raspberry’s ethernet connection goes through that and not directly to the tether interface. Also the switch is powered from one of the Raspberry 's USB ports. I have uploaded a picture of this setup and the additional telemetry log file you required to the OneDrive Folder @jreich shared above.
For debugging and testing of different software versions (companion + ardusub) we have actually used a “BlueROV dummy” consisting of only an original Pixhawk 1 from BlueRobotics + standard Raspberry 3B; with no sensors etc. On this setup, we have reproduced the issue for the different software versions as previously discussed. We have uploaded a webui.log from the companion of this setup (unfortunately we couldn’t obtain the telemetry.log here, for some reason the /tmp/ directory stays empty).
@cbusse1 and @jreich Please send me a private message to arrange a time to troubleshoot this together, if I can dig around on your system which is demonstrating the issue, that will help.
To update those reading this thread @here,
@cbusse1 helped uncover that the Companion Computer software has been interfering with the heartbeat failsafe function. This problem was presented when testing without a joystick connected.
The problem was not apparent and there was difficulty in reproducing it because in almost every case, a joystick will be connected when operating the ROV, and the pilot input failsafe will trigger despite the issue with the heartbeat failsafe.
An update for the Companion Computer software to fix the issue is in the works.
@Portoferraio you mention that you set the pilot input failsafe timeout to 90 seconds, this means that the rov will not disarm until 90 seconds after the pilot has lost control. You should reduce it, our default/recommended setting is 3 seconds.
