Starboard Motor Spins Slower Than Port After Successful Programming & Calibration


We have successfully programmed and calibrated the motors, but the motor on the starboard side spins slower. Meaning that it maxes out at lower rpms than port and comes to a stop faster. Any idea what could cause this?


Hi Daniel:

Here are a couple of things to check first:

- If you spin the motors by hand, is it harder to spin the starboard motor?

- In handling the motors and installing them, sometimes some of the leadwire strands break, which can cause the motor to run slower. To check for this, measure the resistance of the motor windings from the DB-25 connector. For each motor, measure the resistance from A-B, B-C, and A-C. You should get equal values for each measurement, and each motor should be approximately the same. Does the starboard motor measure higher?

- Before doing the next step, I'd try recalibrating the ESCs one more time, and also carefully examining all the solder joints around the ESCs, making sure that there are no shorts.

- Finally, you can try swapping ESCs between the motors. Unfortunately this requires some soldering. What you could do is swap the port-starboard wiring at the DB-25 connector, re-power the unit, and then see if the starboard motor is still slow, or whether the slow motor is now the port one. If it's the port one, then there's an issue with the ESC.

Let us know how this works out.



Thank you for your reply, Walt.

We have reprogrammed the ESCs a few times since your reply and now all of the motors are spinning at the same velocity…without commands. Once all of the motors were spinning at the same velocity, after they were calibrated, they all spun, and continued to spin until we switched the ESCs off. We check the programming every time before re-programming and nothing ever changes, but behavior does.
We have had some success with issues by rolling back the softwear to the previous version of the BeagleBone softwear by flashing it from an SD card, then flashing the most recent version.
We have just identified another symptom as well. We spun the motors by hand and the had the same resistance. As we were trying to test the resistance in the motors with it connected to a bench power supply, we noticed that the starboard motor has more resistance to manual spin and produces a low volume beep every time the magnets pass over the windings. Does this point to a motor issue, ESC issue, control board issue, or power issue?


Hey Daniel, what version ROV and software are you using?


We are using 2.5.1-39. This probably won’t sound good any way I try to say it:
since it has been over a month with no reply to this post, I opened a support request, #412. That was the evening of February the 18th, but have yet to hear back. Is the 24-48hr response time only valid for weekdays?


Sorry that support did not get back to you yet. Want to confirm:

Did you perhaps mean March 18th? That is what I see in the support desk logs.

Yes, that is weekday coverage.

But back to the problem at hand. Unfortunately my best guess at this point it that you were fighting with a broken calibration process. There is a bug as noted in this post OpenROV-ROV-Suite 2.5.1 Final Errants regarding the motors not being able to go in reverse. If the bug happens when your trying to calibrate the motor you wont’ actually get the full range that the sliders in the diagnostic screen were reporting. The behavior you reported is consistent with this bug.

The quick workaround is to enter and exist the diagnostic screen using the arrow in the top left of the diagnostic page to close the diagnostic window. Then go back in and try calibrating the motor. This has a good chance of resolving the issue and I would try this first.

The latest BETA software has a fix for the issue that would eliminate needing the work around. If you do choose to install the BETA, be sure to update your firmware from the settings menu so that the software and firmware are in sync before going through the calibration steps.



Thank you for taking the time to attend to this personally. The quick
work-around did not work. We are, right now, installing the beta image
30.0.0 and updating the firmware, as well as testing the ESCs. I will
respond with the results of our tests later this evening.




The new beta software and firmware have not resolved the issue.
Unfortunately, they are exhibiting the same behaviors prior to the
install. These are the behaviors of the motors and controls as of now:

All behavior directions are taken from the rear-ward-looking direction for
starboard and port motors and top-down direction for vertical motor. Clock
wise (CW) and counter-clock wise (CCW)

Up Arrow: Spins Starboard CCW and Port motor CCW, resultant direction: turn
to starboard

Down Arrow: Spins only Starboard motor CW, resultant direction: turn to
port; If last direction key was left arrow, then both motors spin with
Starboard CW and Port CW

Left Arrow: Spins Starboard motor CCW and Port motor CW, resultant
direction: reverse

Right Arrow: Spins Starboard motor CW and Port motor CCW, resultant
direction: forward

Shift: Ascend, spins vertical motor CW (correct)

Ctrl: Descend, spins vertical motor CCW (correct)

I hope you can make sense out of this. Let me know if you have any



Hey @Daniel3

Just confirming a couple things:

  • Did you re-install the firmware after loading the Beta code?
  • Did you run through the calibration routine after installing the Beta?
  • Are the motors still running without any keyboard input? Seems like the answer is no but want to confirm.

Given your most recent update on the status, it seems like one of the motor’s simply needs to be reversed. The motors direction is dependent on how the leads get soldiered on to the motor. Since it can vary we have an option in the Diagnostics menu to reverse a motor. If forward turn starboard then the starboard motor is probably the one that needs to be reversed.



We did re-install the firmware after the beta.
We re-calibrated after that.
The motors are not running without keyboard input.
We will change the direction of the starboard motor to see if that works.
What concerns me is that unless the Left Arrow key is pressed first, only
the starboard motor spins.

Looking back at my account of the test yesterday, it is glaringly obvious
that the starboard motor is just reversed in its polarity. I think what
kept us from seeing that is the past two months of “chasing ghosts” and
going pretty far down the rabbit’s hole to solve our problems, which were
not static. For instance, the starboard motor was spinning slower than the
port motor. This seems to have bee solved by adjusting the “Brake Force” on
the port motor until they spun at the same speed and
accelerated/decelerated at the same rate.

I’ll get back to you about the results of switching the direction of the
starboard motor.




The directional switch of the Starboard motor sis not work. We have rolled
back to the latest “stable” release of the software. We did more logic
testing and noticed that Pin D8 on the Arduino board (where the starboard
motor ESC connects) does not produce a PWM signal lower than 1.502 ms. The
Port motor on Pin D6 (Port motor pins on the Arduino) produces the full
range of signals. What does this mean? It sounds like one of the boards is
not generating the proper signal either due to a fault on the board or in
the software. Since the problem has persisted no matter what software
version we’ve used, I’m inclined to think that there is an issue with the