Hi Forum! I’m having quite a number of problems with my BlueROV2, making operation underwater a pain in the ass. My guess is that all these issues are symptoms of the same problem.
Take for example our last sequence of dives. The first one started with all the sensors (bar30, BR temperature sensor and ping2 sonar) working fine. Reaching -18m depth, the bar30 sensor reboots and adds -10m (video1).
Following that same dive, connection with the ROV is lost for approximately 5 seconds (which is concerning on its own). Once control was regained, the Ping2 readings became erratic (video2). I’m aware that ping2 readings can give incorrect output at close range, but I find it unusual that this behavior appeared right after a connection malfunction with the ROV.
In a following dive, connection with the ROV was lost again, and the bar30 sensor rebooted, outputting a 0m depth reading while being at -20m (video3).
In a subsequent dive, the BR temperature sensor suddenly stopped providing any readings (video4).
While preparing the ROV for the dives, I received the following message: “PreArm: Internal errors 0x80000 l:403 i2c_isr. The vehicle has failed a pre-arm check. In order to arm the vehicle, resolve the failure.” After disconnecting and reconnecting the battery, the message disappeared. I also frequently get “AKF IMU forced reset” messages.
I’m fairly confident that the sensors themselves are not the issue. I have two possible causes in mind, but they’re based on gut feeling.
Could the camera be the problem here? My CPU is overloaded (image1) due to the camera. I followed the Technical Bulletin 12, and the resistors seemed to be in good shape, but can’t tell for sure (I have photos of it in this post). When changing the camera tilt, I sometimes loose connection with the ROV (camera freezes and the image turns gray).
Maybe there’s something wrong with my rpi3b/pixhawk? I’m planning to upgrade to the rpi4 and navigator, but I’d like to know if the problem originates here or somewhere else.
I already checked the wiring, and everything seems to be in place. Any suggestions??
Sorry for the frustrations. The bar30 is not actually resetting to 0, the autopilot itself is restarting and using the pressure value at start up as 0 depth- so something may be going wrong with the pixhawk itself! Generally I’d suspect the 5v UBEC, especially given the age of your system. That error you received also seems related to sensor communications issues. Do the autopilot resets correspond to driving vehicle hard?
If the video stream is consistent than your camera is likely ok.
If your ping sonar is mounted to the bottom of the vehicle it is likely considerably closer than 1 foot to the bottom, leading to the erratic readings. Monitoring the output with Ping View or the beta Ping viewer next extension should confirm this (in the waterfall.)
You don’t mention what version of blueOS you’re using? Updating to a navigator and newer pi should definitely help things! In the meantime, performing additional compass and accelerometer and gyroscope calibrations may help with your ahrs errors.
Hi @tony-white , thanks for such a quick response.
Is there any way I could check this?
Not necessarily. It can happen while driving hard, but also at other times. For example, the first time it happenned, I was just reaching the bottom at 25% gain.
The video stream is generally consistent, except when I change the tilt vigorously, which can trigger a disconnection with the ROV (it also stops the recording of the video in QGC).
You can verify the UBEC is outputting 5V with a multimeter.
Do you lose telemetry as well as video when moving the tilt rapidly? It’s likely only the video stream is stopping, which would stop recording in QGC or Cockpit. Ensuring that the wire to the cable is routed to have slack at the full extent of tilt is important.
Updating to the current stable, 1.4.2 BlueOS would be good to do!
The UBEC is outputting 5.10 V. Telemetry continues to function even when the video feed cuts out, and I believe the camera cable has sufficient slack.
We went out again with the ROV. Using the first battery, the camera feed and recording remained uninterrupted, although no sensor data was being output. After switching to a different battery, the camera frequently lost connection, and starting a recording would immediately trigger a disconnection. After disconnecting and reconnecting that same battery, the issue occurred much less frequently. These problems do not seem to be related to hard driving of the ROV.
Maybe something related with the I2C Bus Splitter?
The USB camera does not communicate with I2C, so even if you’re using a bus splitter (that could cause issues with long wires and your pressure sensor), that should not affect the camera.
I don’t think the swapping of the battery was related, but more likely the internal temperature / pressure of the vehicle is affecting things - checking the health of the resistors called out in Technical Bulletin 12 with a multimeter will let you see if your camera has been damaged - that’s typically the only reason for inconsistent video stream performance…
Hi, sorry for the late reply. I’ve checked the resistors, and I’m not sure if those values are OK (see photo below). If they are indeed damaged, it would explain the inconsistent video stream. I’d like to take this opportunity to ask about camera choices to replace our current one. We know about the standard Low-Light HD USB Camera and are very happy with it’s performance, but I’ve read that 4k camera choices with zoom are a thing, and we wouldn’t mind improving our system if it’s worth it. I have a lot of research to do, but another opinion is always welcomed. Would the CPU usage on the RPi 3B go through the roof? My system is already taxed, and I imagine a higher-resolution camera would be even more demanding.
Even if the camera is failing (which it seems to be), I have no idea why my sensors aren’t working. I’m using a bus splitter, and I know that having long wires doesn’t help. Could there be an issue with the bus splitter’s power supply? Is there any way to check this?
As the Technical Bulletin details, those resistors should be measuring 100k! Contact support (report a problem with a product) with an order # for a replacement.
Blue Robotics is hard at work on a 4k camera option, but it will be an IP camera so won’t impact your CPU usage. It’s not yet available! I’m not aware of any good 4k options in the meantime…. you would need a small USB webcam that supports UVC / H264.
If possible, shorting your I2C wires to their default lengths, and eliminating the bus splitter, should help with the communications issues you’re having. I2C isn’t really meant for long wires at all!
