Unable to Spin M200 motor – ESC Auto-Disarms After Moving Slider (Blue Robotics M200 + Basic ESC + ArduSub)

Blue Robotics Products Thrusters and Motors
,
1

Hello everyone,

I’m working on an autonomous UUV using Blue Robotics M200 motor with theie Basic ESC, running the ArduSubversion of ArduPilot. My companion computer is a Raspberry Pi 5 running BlueOS, and I use QGroundControl as the ground control station. I’m trying to get basic motor actuation working, but I’ve run into a problem: the ESC arms, I can move the motor slider (either in QGC or the BlueOS web interface, but the motor immediately returns to neutral and then after a few seconds the ESC auto-disarms. Hoping someone here might help me debug what I’m missing.

More details below in case they are useful.

Setup & What’s Known to Be Working

  • Motor: Blue Robotics M200

  • ESC: Blue Robotics Basic ESC

  • Flight controller: Orange Cube + with CubePilot carrier board

  • Firmware: ArduSub (version 4.5.5)

  • OS: BlueOS (version 1.4.2) on Raspberry Pi 5

  • GCS: QGroundControl (version 4.2.8) on a mac

  • Connection: Via BlueOS / web interface, using the motor sliders in the web UI.

What does work:

  1. I can see telemetry data from IMUs and other internal sensors and these appear to function normally.

  2. I can arm the ESC through the interface.

  3. The correct amount of motor sliders appear active / blue in the BlueOS web interface.

What’s Not Working

  • When I move the slider away from neutral, the motor does not spin. On release of the slider, it immediately snaps (or otherwise returns) back to neutral.

  • After a few seconds of being armed (or after attempting slider movement), the ESC auto-disarms.

My Objective

  • Fully autonomous underwater missions: navigating between waypoints, etc., with reliable motor control.

  • Motor must be able to be actuated from ground control via ArduSub without manual intervention (once setup, connect, arm, move/throttle, etc.).

What I Have Considered Could Be Going On

Here are hypotheses I’m exploring:

  • Signal / PWM issues: Maybe the ESC is not seeing a valid or stable neutral (1500 µs) signal for long enough, so it arms, sees movement, then returns to neutral, then disarms.

  • ESC firmware / direction / bidirectionality: Perhaps the ESC needs bidirectional firmware or configuration that matches what ArduSub expects.

  • Failsafe / Safety / Arming Checks: There may be safety/arming checks or failsafe rules in ArduSub / BlueOS that are immediately tripping, causing an auto-disarm when certain parameters aren’t met (voltage, RC input, signal stability, etc.).

  • Parameter misconfiguration: Some PWM limits, arming timeouts, PWM trim, etc., may be set too strictly or incorrectly, causing signal to default back or disarm.

  • Frame / motor mapping issues: If the motor output channel isn’t correct or mapped properly, or if direction is misconfigured, the system might interpret ‘movement’ incorrectly and throw it back.

Thanks in advance — happy to share specific firmware version numbers, parameter dumps, or photos of wiring if that helps clarify.

2

Hi @Subsurface

Welcome to the forums!

What channel do you have the ESC connected to on the Navigator output? Is the white wire oriented to be on the signal side?

We’ve not tested the Orange Cube much, and not at all with a Raspberry Pi 5….

The current latest stable version of ArduSub is 4.5.6, it fixes some issues with 4.5.5 related to servo outputs…

Have you loaded default parameters for a BlueROV2, or configured your vehicle frame type parameter?

Fully autonomous missions may be a challenge, as you won’t have Lua script control with that autopilot option. Do you plan to have a payload that provides position to the autopilot, like a DVL or USBL/LBL? A position source is necessary for autonomous missions…

If you’re using the Basic ESC, it is indeed bidirectional!

Does the motor respond if you connect the GCS, arm the vehicle, and move the joysticks? You may find Cockpit a much more modern and customizable option than QGC… Calibrating your motion sensors or disabling those failsafes may be necessary to get the vehicle to arm and stay armed!

3

Tony, thanks for the info.

I am running PWM signals from the CubePilot’s MAINOUT1 port with only the white (signal, top) and black (ground, bottom) wires connected to the ESC (the CubePilot’s power comes from the USB or POWER1 input).

As a sanity check, I verified that the battery → Basic ESC → M200 motor chain works by driving it directly from an RPi Zero. The sequence was PWM 1500 µs (neutral) for 2s, 1700 µs for 2s, 1500 µs for 2s, then stop command. Interestingly, the first time I ran the script the ESC armed late and the motor didn’t spin, but when I ran it again immediately after, it worked exactly as expected. Is that typical behavior when arming a Basic ESC?

I don’t yet have a DVL integrated. From your note, am I correct that a position source (DVL, USBL/LBL, etc.) is required for ArduSub’s autonomous mission set to actually execute? If the autopilot refuses to run motors without it, that could explain my current symptom. Also, can this be disabled?

I have noticed the CubePilot frequently boots into bootloader/booster mode, and sometimes refuses to return to normal operation. That may also be contributing here. Given my focus on reliable fully autonomous missions, do you have a recommendation for a flight controller that’s been well-tested with ArduSub? Integrated sensors like those in the Cube are convenient, but motor reliability is critical for me.

On the software side: I began with the basic parameter set and tuned from there, but I will try loading the BlueROV2 defaults as you suggest and see if that clears things up.

Finally, on the GCS: I’ve been using QGroundControl because of its maturity, cross-platform stability, and established integration with ArduSub. I haven’t tried Cockpit yet — if it offers better functionality, I’m open to switching or at least testing it alongside QGC.

Thanks again for all the help!!

4

Hi @Subsurface -

It should not take sending the 1500µs signal multiple times to arm the BlueESC. I suspect something wonky is going on, perhaps with your wiring or code for that test?

ArduSub will refuse to go into Auto mode if it has no position source, that is correct. There is no way around this, but you could still operate as an AUV in Alt_hold mode with a Lua script commanding pilot input based off of some other source. Of course, with your Pixhawk Lua scripts aren’t an option as previously mentioned…Currently only the Navigator + Pi + ArduSub/ArduRover support Lua scripts- however the autopilot code is actually executed onboard the Pi, and not the Navigator daughter board!

I had assumed you were trying to operate your vehicle in manual mode. If you set it to Auto mode and then try and arm, and no position source is present, I believe it will disarm immediately.

Cockpit is also completely cross platform, open-source, and considerably easier to add custom functionality too. Of course with an AUV, you won’t have a link to the vehicle to use it with (unless you’re keeping a tether connected?)