Upgraded my BLUEROV2-R3-RP

I bought and built a BlueROV2 3 years ago (Pixhawk controller) and it has the lights, gripper, Ping360 and DVL as optional accessories. I did add an ethernet switch to accommodate the accessories.

I just upgraded it to BlueOS 1.4.2 and ArduSub 4.5.3 and it seemed to all go OK. However …

My computer and controller will no longer control the thrusters, lights or anything else. The video streams in OK to QGroundControl, BlueOS and Copilot without issues, but no commands seem to make it to the ROV. Do I need to do something special? I chose the Heavy configuration and walked through the installation guide, but I’m tearing my hair out now. I’m also getting a message about a AP_Logger() stuck thread in QGC, but that seems secondary to not being able to control anything on the ROV.

Suggestions welcomed.

Hi I have the similar setup.. Heavy Config, Lumen lights, Gripper, Ping360, Ping1D. (no DVL).

I recently upgraded to BlueOs 1.4.2 and Ardusub 4.5.3.
The BlueOS works fine for me, but I had major problems with Ardusub FW.. A lot of warnings and controller function problems.
So I changed the Ardusub version back to v. 4.1.2

Thanks. I just tried to load 4.1.2 and no dice. It’s strange. When I first loaded BlueOS and had NOT upgraded the Ardusub firmware, the ROV was responding (lights dimming, gripper moving), but after the upgrade, I get zero response from anything on the ROV other than incoming video. I wonder if something got bricked?

Hi @dannyallan,

Sorry you’re having some problems with your ROV update.

It’s possible this is relevant, although I’m not sure how the storage on a freestanding flight controller board like a Pixhawk could end up full - maybe you just need to delete some of the DataFlash (.bin) log files on it?

That sounds like maybe the firmware update process for the Pixhawk failed, in which case you no longer have a running autopilot to send commands to and receive telemetry from?

If that’s the case, it should tell you on the autopilot manager page that there’s no valid version running, and the available boards when trying to update should specify that the Pixhawk is in its bootloader mode. If so, please try power cycling the vehicle before attempting to update again, and if that fails multiple times you can try opening the enclosure, disconnecting the Pixhawk, connecting it to your QGC computer directly (via a USB-A to micro-USB cable), and updating through QGC.

1 Like

Thank you Eliot. I will try this out next week. I know that the Autopilot Manager does say there is a valid version (and I’ve switched a few times). It has showed two different boards - both SITL and PX4 BL FMU V2.X as options. I’ve tried both, but it might be that I never got the right combination. Is there a correct type to choose?

When I did the very first Ardusub upgrade, I got a message saying that I needed to explicitly specify SITL and it never completed. However, after this, I did seem to get it going again and I used SITL.

If it still doesn’t work after a few cycles, I’ll take it out of the enclosure and do it directly. I’ll follow up with a report on Sunday/Monday.

(I"m using a very high end SD card so I don’t think it’s IO. BlueOS shows it at less than 50%.)

SITL is a software simulation we’ve included in BlueOS, which can be run for testing purposes, e.g. if you don’t have a flight controller board, or if you don’t want to be using your physical hardware at some point. It won’t run your physical vehicle, so isn’t what you want here.

PX4 BL FMU V2.X is a Pixhawk bootloader, which does indeed indicate that an update attempt has failed, and the Pixhawk is not currently running an autopilot firmware - it’s just waiting for one to be flashed on.

There is a separate SD card inside the Pixhawk, used for storing the autopilot’s internal logs (unrelated to the one in the Raspberry Pi that’s running BlueOS). I believe the autopilot normally handles cycling through those logs if its storage gets full, so that’s normally not an issue, but I believe it’s possible to delete them when the vehicle is connected to QGroundControl, if that’s relevant at some point.

That said, it seems like this isn’t your issue at the moment.

You were correct Eliot. I had to disassemble and flash the Pixhawk directly from QGC, but after I did this, everything worked as expected without errors.

2 Likes