Hello - we recently switched over to using BlueOS instead of Companion as we were looking to update our firmware for our BlueROV2 and after seeing forum posts about how using BlueOS fixed some issues that people were having (we had lost connection with the ROV, lost manual control, and could not turn off lumens or move all thrusters in manual during a recent day in the field).
We flashed BlueOS onto our Raspberry Pi SD card after formatting the previous software and have been trying to get things set up and usable in BlueOS. As of today, we are unable to turn the ROV on once it’s plugged into a battery. We experienced the following issues immediately leading up to the ROV not turning on:
parameters wouldn’t load when rebooting autopilot
then blueOS page wouldn’t load
updated qgroundcontrol, but had no connection
Now ROV will not turn on (we’ve included videos showing what happens when the battery is plugged in - the big status LED was flashing red at one point which is kind of hard to see in the video):
repeats first 3 beeps when battery is plugged in with some intermittent beeps
lumens keep flashing when battery is plugged in
no voltage on pixhawk power pins 1 and 6
thruster(s) turned on and off at some point without prompting
In the last few days before the ROV failed to turn on, we had connection issues and received the following errors/issues (we reset all parameters and rebooted autopilot at some point):
MYGCS 255 heartbeat lost
unable to update the firmware beyond 4.0.1 (says ‘no data available’)
2nd set of beeps when the battery is plugged in are delayed
live camera view delayed to load and freezing (although we think the freezing could be our computer)
compass calibration does not work (no progress bar in BlueOS but still prompted to calibrate)
no battery voltage indicated on top right in Cockpit
ROV continues to disconnect and reconnect without apparent reason
controller is failing to connect to ROV — cannot arm or control thrusters
We are planning to replace the microUSB to USB cord connecting the Pixhawk and Raspberry Pi. Any ideas as to what’s going on or what to do are greatly appreciated!
Hi @Ingrid -
Sorry for all the issues! The initialization beeps coming constantly sugget that your pixhawk may be damaged, as it is seemingly stuck in a boot loop. If you plug it directly into your computer, you may be able to flash it with ArduSub firmware from QGroundControl directly - if this fails, the hardware is likely faulty - you culd replace or upgrade to a Navigator!
I’ll try and point out some things to try aside from the pixhawk:
What version of BlueOS did you flash? After plugging in the battery, it will take 2-3 minutes for BlueOS to start up before you can access it at 192.168.2.2 or blueos.local, however you must configure your computers IP address on the USB/Ethernet network configuration appropriately (192.168.2.1, 255.255.255.0)
Once you are in BlueOS, you should be able to see the Autopilot Parameters and update the Autopilot Firmware.
Navigate to vehicle setup / configure to load the default parameter set for your vehicle.
You can also use this interface to calibrate the Gyro, Accelerometer, and Compass - make sure QGroundControl is not open when doing so!
The lack of battery voltage display suggests the pixhawk is not communicating, or has not been configured for the type of power sensor connected.
Generally, your issues seem tied to a faulty pixhawk!
Hi @tony-white - thank you for your reply! We really appreciate the help. We are currently attempting to flash Ardusub onto the pixhawk via USB, but are unsure which version our pixhawk is. The options listed are variations of ‘pixhawk - 1m’, ‘pixhawk 1’, and ‘pixhawk 1 BDShot’. We are pretty sure ours is a Pixhawk 1, but aren’t quite sure if it’s BDShot. Is there a way to know for sure before flashing, or will it not make a difference? Thank you again!
Okay, thanks! We flashed the Pixhawk and are still having the same LEDs on the Pixhawk, lumens flashing, and beeping as in the initial videos we posted. We ordered a replacement USB to microUSB that goes between the Pixhawk and Raspberry Pi and are waiting to receive it so we have not replaced it yet. Do you think this is worth doing or can you tell that our Pixhawk is shot?
Hi @Ingrid -
Did the flash complete succesfully? How did the lights behave when plugged directly into your computer - in the same way? If they were normal when connected with a different micro-USB cable, then you may want to try using this cable while you wait for a short RA one to come in. If the connector in the ROV is bad, the pixhawk could be restarting due to a low voltage from a bad connection.
Hi @tony-white yes, the flash completed successfully and the Pixhawk LEDs seemed normal when plugged directly into the computer. We will try to find a different cable to test before the other one arrives and will keep you updated. Thank you so much!
Hi @tony-white! We tried a different USB-microUSB cable and are having the same Pixhawk LEDs light up in the same way as in the initial videos we posted. Is it hopeful that the Pixhawk might be usable since the LEDs were normal when plugged into the computer? Or are there any other potential issues that might be causing this to check before replacing the Pixhawk?
Hi @Ingrid -
That’s very unusual! Have you verified the Raspberry Pi is booting ok, and providing 5V from its USB port? Have you tried connecting the Pixhawk to all of the Pi USB ports? I would suspect the Pixhawk is the likely failed component if everything else is behaving nominally…
Hi @tony-white - we might be having booting issues with the Raspberry Pi as we are getting an occasional flashing red LED (we think for PWR) on the Raspberry Pi when the battery is plugged in, and no green LED (we think for ACT). We didn’t notice any LEDs on the FMU side of things on the Pixhawk when the battery was plugged in (not connected to the computer). We tried all of the open Pi USB ports with no difference, but have not tested to see how much voltage we are getting from the USB port. We are also getting two green LEDs on the Fathom Tether Interface rev2 (one for PWR, one for LINK), but after a few seconds the LINK LED turns off. We plugged the Pixhawk back into the computer directly and I believe got normal LEDs after a few seconds of being plugged in (see video). We also had a message pop up (see photo) when the Pixhawk was plugged into the computer.
Hi @Ingrid -
It would seem your Raspberry Pi is dead
It isn’t providing 5V to the pixhawk, which makes the behavior you witnessed with it restarting occur. Replacing your Pi should fix the problem (and upgrading to a Pi4 may be worth it!!) You should test the voltage powering the pi from the 5V BEC that connects to the GPIO pins before connecting a new Pi, to make sure 5V and not battery voltage (from a failed power supply) is present.
As for the single green light after a period of time on the Fathom-X - this indicates the homeplug module is not able to create an ethernet link across the two wires being used in the tether. Without this connection, your computer won’t be able to connect and control the ROV!
You can use a multimeter in resistance or continuity test mode to check the tether is properly connected:
If you don’t have a low-resistance connection for both terminals, you can try using another tether pair (4 available on standard tether, default is blue/blue white)
Hi @tony-white - that’s good to know, thank you! We tested the voltage on the back of the GPIO pins (each of the two 5V power pins tested with the ground pin) and were getting values above 4, but below 5, so I would assume this means our BEC is all set, correct?
I’m not sure that the multimeters we have work for testing the resistance/continuity of the tether connection. I tested the other tether pairs and still got the same LINK light issue. Do you think the Fathom-X light issue could be caused by the dead Raspberry Pi and replacing the Raspberry Pi will fix it?
Hi @Ingrid -
The 5V BEC should deliver at least 4.9V - if not, it could be part of your issue.
I’ve not come across a multimeter that can’t measure resistance! It should be an easy test to verify that the wires in the tether are connected. If all of them are broken, all of the pairs would not work when tested…
When trying other pairs, did you change the connection both in the ROV and in the topside FXTI?
The Fathom-X not establishing a connection has nothing to do with the status of the Raspberry Pi.
Hi @abuislam - thanks. We tried a different micro-USB to USB cord with unfortunately no change in what we were seeing, but we’re doing some other troubleshooting and are making some progress!
Hi @tony-white - sounds good, we will order a new 5V BEC. Thanks for clarifying that the Raspberry Pi doesn’t have anything to do with the Fathom-X connection issue.
Okay, that’s good to know about multimeters! I wasn’t able to get any reading when following the diagram you sent, however, if I moved one of the probes to the other screw next to it, I would get a reading around 22 Ω using the blue and white tether pair. I don’t know much about resistance testing (if that wasn’t already obvious haha), so is this reading a good sign that those tether pairs are fine? I had only changed the pairs in the topside FXTI and hadn’t changed the connection in the ROV but will do so in the future if troubleshooting with the tether pairs again. Thanks!
Hi @Ingrid -
It sounds like you measured the resistance of one wire in the tether pair - you can move the probes over on both ends to measure the other wire’s resistance, which should be approximately the same (within a few ohms.) If not, this is the issue with your Fathom-X connection, and you should try a different tether pair (moving the connection in the ROV and the FXTI.)
Hi @tony-white - I believe we are doing this correctly now and tested the resistance of both the white and blue wires which were both ~ 22 ohms. Does this mean this tether pair is not the issue? If this isn’t the issue, do you have any other suggestions of what we should try?
Hi @Ingrid -
If you have good connectivity between Fathom-X tether modules via the blue/blue-white tether pair, but still aren’t getting a green link light, then the issue could be with one or both of the Fathom-X modules, or the tether pair.
If trying other tether pairs doesn’t get the link light on (moving in ROV and FXTI topside, with both ROV and FXTI connected to power) than you may need to replace the Fathom-X - typically the ROV side first is the best bet.
Hi @tony-white - we set everything up, plugged in a battery, and had both the PWR and LINK lights stay on for a while, so we are thinking the LINK connection issue is fixed. Not quite sure what was going on - maybe something wasn’t fully seated or simply operator error. We will be ordering a new Raspberry Pi 4 and will reply here with how that goes. Thank you for all of the help so far - it has really been appreciated!
Sounds good @Ingrid -
Note that if the link light does turn off, no connection to the vehicle is expected - it may be on when initially powered, but turn off not long afterwards…
