ArduSub V3.5 Beta Testing

ArduSub 3.5 is ready for beta testing!

A recent daily build of QGroundControl is required for use with ArduSub 3.5. Scroll down this page to find daily build download links. We will continue shipping the BlueROV2 with ArduSub 3.4 until another stable build of QGroundControl is released.

There are many updates and new features available in 3.5, the release notes are available here.

If you would like to test the 3.5 beta firmware, please follow the instructions here and select the Beta version. Please report any feedback or issues here.

I ask that any beta testers save a parameter file before and after the upgrade so that I may verify that the parameter upgrade process goes smoothly. Please upload the two parameter files here after you have upgraded. If you are currently running stable version 3.4, then you should not have to make any changes to your parameters after upgrading. If your current version is 3.4-dev, then your parameters will be over-written during the upgrade.

Had a pretty good run in the North Atlantic this morning with 3.5rc1. The vehicle responded well to the controls. Stabilize/Depth Hold modes were very good. I did notice, however, that during Stabilize, and Depth Hold modes, the Starboard thruster had a lot more power when changing depths at full (50% gain) stick. It would roll a fair amount. I forgot to check how they were in Manual Mode. I’ll run it again tomorrow and try.

I lost some travel on the servos. (camera tilt, and aux3 (ch.11) compared to release 3.4.

After the upgrade, I had to re-map the three Modes (Manual, Stabilize, Depth Hold) to the appropriate buttons on the joystick, and set the in Aux input for the Leak Detect board.

Still struggling with camera focus. Everything is slightly out of focus when submerged…but that’s not a software thing.


Thanks for continuing to improve this already-great package!

A comment/request on the behavior upon depth sensor malfunction, in 3.5 beta release notes: “Add failsafe for depth sensor malfunction, vehicle will automatically enter MANUAL mode when depth sensor malfunctions.”

We had a depth sensor malfunction, but were still able to conduct operations because we could still use STABILIZE mode to maintain heading lock. MANUAL would not work for us in that scenario. It’s unclear whether a bad sensor under 3.5 would continuously push us back into MANUAL, from any mode, or only from DEPTH HOLD? Is there a need to default to MANUAL, or could you default to STABILIZE instead?


It will only push you out of modes that require the depth sensor, it will always enter Manual mode at this time. I will make stabilize an option for the default fallback, great thought. Manual and Stabilize do not require the depth sensor.

I am curious about your experience where Manual was not working. Can you describe the situation with more details please?


Sorry, what I meant was that using Manual mode wouldn’t meet our needs (because we were relying on Stabilize for heading lock). Manual mode was “working” properly the way it’s supposed to.

Thanks for adding a default option.

I’m having difficulties increasing servo travel with V3.5rc1.

I use an aux output to control an external servo (for a gripper). In V3.4 I had it mapped it to Lights2. With V3.5rc1, same mapping, the servo travel becomes limited. The gripper does not open/close fully. I can’t seem to find the parameter setting to increase the range. I also tried to map a joystick button to one of the new servo functions, but I can’t find where to map that to an Aux output on the Pix.


Look at SERVOn_MIN and MAX parameters for the output limit adjustments. The servo functions are hard-coded to aux outputs 1-3 (SERVO9-11).

Thank-You Jacob!

Mapping servo_1_enc/dec to a couple joystick buttons, and adjusting the Min/Max of SERVO9 fixed the issue.