BlueROV2 Heavy - Gripper not working - no PWM output for Gripper

Blue Robotics Software BlueOS
1

Hi all,

I’m having problems getting the gripper to work on the bluerov sub.

I was asked to check out the gripper on a bluerov2 as it had stopped working. The short story is all hardware has been checked and tested, and it definitely seems to be a software/config issue.

The slightly longer story is that I now have the rov and 2 rasp Pis and 2 Navigator boards, all are working and all exhibit the same behaviour.

Software:-

Fresh download of BlueOS 1.4.2 written to SD card

Setup wifi on BlueOS (manual setup dns to make it see internet - solution I found on this forum somewhere!)

run wizard for heavy config.

Ardusub updated to 4.5.5

Under vehicle setup tab Gripper is shown as Channel 11, under PWM outputs tab Output 11 shows Gripper, but 0 in output.

Controls are correctly setup in cockpit and channels 13 lights, and 16 camera mount work as expected and show outputs in the PWM outputs tab.

Checking with an oscilloscope I can see pwm signals on 13 and 16. I have used the navigator assistant to prove that all channels on the navigator pwm are working properly including 9,10 and 11. I have reconfigured for 9 and 10 with the same result - no trace of any signal on the pins.

After a reboot of the system and re-checking the various config pages, I see that under the vehicle setup - pwm outputs page output 11 now shows EPM instead of Gripper. This behaviour seems to be consistent and has happened several times now.

I don’t know what EPM is, but maybe there is a conflict somehow with the gripper setup.

Hopefully I’m just missing something, but I’ve hit this many times and in varying ways and the only way to get a fully working rov has been to roll all software back a long way (when I did that, the gripper worked fine so no problem there either!)

All help and ideas gratefully received!

2

Hey! I had the same experience. Also after rebooting the Output 11 had a label called ‘EPM’ instead of ‘Gripper’. I couldn’t fix it, so I downgraded back to 4.5.3!

3

Thanks Sietse - helps to know I’m not going completely nuts.

Here is what I have just tried:-

fresh install Blueos 1.4.2
boot
setup wifi + dns
reboot
check ardusub version and set to 4.5.3
run wizard - Heavy ROV2
check ardusub version - it had auto updated to 4.5.5
Roll ardusub back to 4.5.3
vehicle setup - gripper not configured
go to PWM Outputs - set channel 11 to gripper
back to overview - gripper still not configured
reboot
vehicle setup - gripper not configured
PWM Outputs - Output 11 - EPM - Gripper has disappeared from options.

fresh install Blueos 1.4.2
boot
No internet connection - no wizard
check ardusub version - 4.5.3
vehicle setup - gripper not configured
PWM Outputs - Output 11 showing EPM
setup wifi + dns
reboot
vehicle setup - gripper not configured
PWM Outputs - Output 11 showing Disabled
Gripper not in options

What version of BlueOS did you have working with Ardusub 4.5.3?

4

Hi @jopple -

@sietse is correct - version 4.5.5 changes some things about the way the gripper is configured, so upgrading from 4.5.3 “breaks” your Gripper configuration. We’ll be updating the documentation and default parameters to accommodate these changes very soon!

5

Hi Tony,

thanks for the reply and looking forward to the updated documentation.

In the mean time, what is the working configuration? As you can see above I have tried BlueOS 1.4.2 with Ardusub 4.5.3 but I am yet to get the gripper going. What am I missing?

6

Hi @jopple -

If running 1.4.2 with Ardusub 4.5.3 the standard instructions apply!

7

I have just checked a couple more times from scratch, and following the instructions does not result in a fully working machine.

There are three outputs I’m concerned about, those being the lights, the gripper and the camera tilt. Following the instructions results in the gripper working but not the camera mount. Trying the wizard results in the gripper not working.

I have now found the workaround to get those all working together, but it is not by following the instructions.

I also noticed along the way that once I had previously enabled pirate mode, it has persisted through all of the full reloads I have done so I looked at the cookies that are being stored on the browser. What other data is held in the cookies that persists?

Is the automatic firmware upgrade that happened that I highlighted in an earlier post the shape of things to come - firmware upgrades occurring without the knowledge or consent of the operator? I don’t want to get a machine setup correctly on the bench to then find that on deployment something fails on the machine due to a silent update?

8

Hi @jopple,

Sorry for the confusion here. There was a recent ArduSub release that isn’t yet in sync with our other software or setup instructions, which is causing the issue you had with your gripper. That’s on us, and we’re adjusting release processes to avoid similar situations slipping through the cracks again in future.

I’m not well-versed in which code is saving cookies, but my understanding is that most (if not all) of BlueOS’s persistent data is stored on the vehicle rather than in the browser. If there is browser-specific configuration then I suppose it would be these settings.

I’m not sure what you’re referring to here - none of our software updates automatically, the most we currently do is notify of when there’s a new version of something available (and even that isn’t available for the full software stack yet).

When BlueOS is first installed on a system the startup wizard does provide an option to install the latest stable autopilot firmware for the selected vehicle type, but that step (or the entire wizard) can be skipped (e.g. if you’re adding BlueOS to an existing setup that you’re otherwise happy with).

Fair enough - we don’t want that either!

1 Like
9

Hi,

I have the exact same problem. I bought a second Raspberry Pi and a second navigator, but the Gripper still doesn’t work on pins 9, 10, or 11, neither with Cockpit nor with QGroundControl.

I know the Gripper works because I managed to get it functioning on pin 16 with the camera tilt control (I had an emergency situation where I needed to retrieve a CTD at a depth of 110 meters).

I also tried downgrading ArduSub and BlueOS, but I can’t remember which versions I attempted.

After reading Eliot’s recommendation, I will attempt to downgrade Ardusub.

At least it’s reassuring to know I’m not the only one experiencing this issue.

thanks,

10

Hi @Guillaumeee -
The better solution may actually be to update ArduSub to the latest version, 4.5.6, and configure the Gripper to use an output channel you have it connected to as an Actuator - you are no longer limited to using 9,10,11 - as explained here. It no longer needs to be set as disabled, which can be a bit confusing when configuring an active output!

1 Like
11

Hi Guillaume,

My working solution was:-

BlueOS 1.4.2

Ardusub 4.5.3

Run wizard and set for heavy configuration

Then:-

parameters - standard -
GRIP GRIP_ENABLE change from Disable to Enable
MNT MNT1_TYP from none to Servo

reboot
parameters - standard -
GRIP GRIP_TYPE change from None to Servo
reboot

This has worked on two units since I had problems.

Hope this helps.

12

Hi @jopple -
The GRPI_ENABLE and GRIP_TYPE parameters don’t do anything, on both ArduSub 4.5.3 and 4.5.6!

In versions prior to 4.5.5, outputs 9,10 and 11 correspond to QGC/Cockpits Servo 1,2,3, and confusingly those PWM output channels need to be set to disabled for this connection to function.

With ArduSub 4.5.5+, we introduce the Actuator output type, letting users use any of the available channels for output control.

The reason your approach likely fixes things is the loading of default parameters!