Thrusters Spin When Armed

I’ve looked through other posts with the same issue but have not found a solution that works. I have a stock setup BlueROV2 Heavy that uses a stock pixhawk and Blue ESCs. A couple of thrusters spin slowly in a couple of second bursts as soon as I arm in manual mode. Right now, that is thrusters 2 & 3 but that doesn’t seem to be consistent. I have also seen thrusters 1 & 3 spin when armed. I have run the calibration of my Logitech F310 controller and correctly configured the directions of my thrusters. Not sure it matters but I am running BlueOS firmware on the latest version. I’m using QGC V4.1.4.

Your help is most appreciated!

Hi @hube268,

The main potential sources for that which I can think of are:

  • Physical joystick deadband is larger than calibrated for, so the motors are receiving a non-neutral signal without you pushing the joystick
    • should be detectable by seeing non-neutral signals (not 1500µs pulse-duration) for the affected motors in the SERVO_OUTPUT_RAW message in QGC’s MAVLink Inspector while the relevant joystick is released
    • should be fixable doing deadband calibration in QGC
  • Relative clock inaccuracies between the Pixhawk and the ESC(s)
    • detectable by thrusters rotating while the relevant outputs are set to 1500µs
    • in theory this should be fixable by adjusting the output trim (and extent) values via the firmware parameters
      • ArduSub does not currently support changing the trims, but it should be possible to implement via some refactoring (since the relevant parameters are already available, they’re just not being used)
    • alternatively, the Pixhawk timings can be checked by measuring with an oscilloscope
      • if this is the cause, it should be fixable with a replacement flight controller
    • if the Pixhawk outputs are not the issue then the ESC inputs most likely are
      • which should be fixable by replacing the misbehaving ESCs
  • Electrical noise / cross-talk causing a signal on one wire without the relevant output being commanded to that value
    • this seems unlikely to me, purely because the accepted signal range is reasonably specific, so it would be hard for this to appear with any kind of consistency
    • should technically be detectable with an oscilloscope, but it may be challenging to do so
    • “fixing” would require increasing electrical isolation and/or insulation of the affected signal wire(s) from the source(s) of noise

Thanks @EliotBR. I did figure out the issue today. It was just a bad controller. I bought a new Logitech controller and it fixed the issue without any additional modification. I do appreciate your detailed response and I think this will certainly help someone else with the same problem. Thanks!

1 Like