Wrong thursters turning when testing PWM outputs

I’m currently in the process of upgrading an old BlueROV2 with new RPi4 and Navigator, in addition to many other upgrades and changes (Cobalt connectors used instead of penetrators on all external cables).

The RPi4 uses the SD card provided with the Navigator. The setup has successfully booted for the first time with BlueOS and Cockpit running nicely “out of the box”.

As part of the bring up of the upgraded BlueROV2, I’m testing that the various components are working as expected and are observing a very strange behaviour with two of the thrusters.

When running the thrusters through the Vehicle Setup screen in BlueOS, thrusters 1,2,3 and 5 are running as expected.

However, when testing thruster 4, thruster 6 is spinning up. This can be a case of mistakenly having swapped 4 and 6, but the head scratcher is that when testing thruster 6, thruster 5 is spinning!

Note that thruster 5 is working correctly when testing it, so this is most likely a configuration/software issue and not a wiring issue.

But I don’t know how to attack this issue to fix it…

Hi Kjetil!
That is a peculiar issue - our software team will definitely see if they can replicate and find whatever bug may be present.

In the meantime, you may want to check how the QGroundControl motor setup page reacts in comparison, to see if it is an issue specific to BlueOS interface or the vehicle configuration / Ardusub.
Thanks for sharing!

1 Like

Thanks for the reply.

I have tested more and discovered something strange that I need to look into tomorrow when I’m not (so) tired.

When I plug out/in thruster 4 from the Navigator it seems like thruster 6 is (also) beeping when booting up the esc.

When I then plug out/in thruster 6 there is no boot up sound from the ESC.

I wonder if I might have mixed up some of the 3 wires from the escs to these two thrusters? I will check tomorrow and report back.

The wiring from the Cobalt connectors is a mess since I didn’t want to cut the wires to proper lengths due to wanting to retain the flexibility of potentially reusing the Cobalt connectors for other purposes later. This means that I can easily have made the mistake of mixing up some of the thruster wires…

@tony-white:
I was finally able to test the setup properly and found out that the thruster 4 and 6 were mixed up. This has now been fixed.

Current status:
-All ESCs/thrusters tested successfully using Motor 1 (pin1) on the Navigator to test them
-Motor (pin) 1-6 on the Navigator correctly maps to thruster 1-6
-If Motor 5 or 6 is tested, both thrusters spin up (although only one of them is being tested and should spin up)
-I can run thruster 6 when Motor 5 is tested while the PWM cable to ESC 5 is disconnected, and likewise run thruster 5 when Motor 6 is tested with the ESC 6 is disconnected

This more or less concludes that it has to be a software issue.

Hi @kjetilei -
It may indeed be a software bug. Can you confirm this happens both in the BlueOS motor test page as well as the QGroundControl motor test page?
Does the ROV operate normally?
I assume you’ve traced the motor wires to each ESC and there are no mixups there…

The behaviour is the same in QGroundControl as in BlueOS.

I still have the ROV on the bench - awaiting all tests to pass, but besides the thruster 5 and 6 always operating together it seems to be working normally.

The thrusters are connected correct to the ESCs and the ESC pwm cables to the Navigator, meaning that Motor X in BlueOS controls Thruster X on the BlueROV. The only thing not working as expected is the fact that thrusters 5 and 6 are both triggered by input from either motor 5 or 6.

Hi @kjetilei,

Can you check parameters SERVO5_FUNCTION and SERVO6_FUNCTION?

Also, checking continuity between the signal pins on channel 5 and 6 could be interesting.

@williangalvani:
Thanks a lot for your suggestions! The servo function parameters were correct.
But there is continuity between pwm on pin 5 and 6, so identified the issue.

I can’t understand how I forgot to test for it (since I had the multimeter out).

I assume I’ll have to contact the supplier of the Navigator (JM Robotics)?

1 Like

I have arranged with JM Robotics for the Navigator to be replaced (great service from them - as always).

Wile Im waiting I got curious and tested to see if I could just remap the output to the news PWM pins (7).

It worked nicely, but the test interface inBlueOS is behaving a bit weird, where I test Motor 6 but the output shows on Motor 7.

I got my itch scratched so are good for now :slight_smile: