[Solved] Erratic motors

So I am slowly progressing on my Navio2 build.

I am using the R7008SB receiver with SBUS.

I have calibrated my radio successfully in Mission Planer. Values go from 1094 to 1934.

I have calibrated my ESCs individually and throttle works nicely.

When I plug in my ESCs to the navio and plug the LiPo, motors begin to run erratically. They seem to start and stop randomly and go at random speeds - and the throttle on the transmitter is still at 0%.

Performing the motor test in Mission Planer blinks the led red and blue, but the motors continue to be erratic. Only way to stop the motors is to either kill arducopter on the rpi2, or unplug the lipo.

This is not my video, my symptoms are more of less like this Quadcopter motor erratic - YouTube.

Do you have an idea what I could be overlooking?

@pierig

Could you please say what ESCs do you use exactly?

Is “All at once calibration” applicable to them?

Hi George,

These are called Spider 30A Opto ESCs. They use SimonK firmware.
On the packaging I can read 2-6Lipo, 600Hz Refresh rate.
It seems they are manufactured by www.ztwoem.com.

I have another ESC and motor combination I will try today (DJI opto 30A + motor from a F550 kit)

Did you supply power to the servo rail? You OPTO ESCs need power from Navio side for the optocoupler to work.

Yes Indeed, I have a 5V BEC (castle creations), Plugged into the last connector of the rail. I also have the RPI2 plugged in with micro usb. Behaviour is exactly the same with and without power to the servo rail.

Can you post a picture of your setup?

receiver in PPMSB
motor 5 in pin5
5v bec in pin 14

RPI2 boots fine with bec only as power source.

Can you set APM to logging when disarmed and publish a log?

Do you by any chance have a scope to check the PWM signals?

Do you have any other ESCs to check with?

When you say logging, you mean apm.log on the RPI2 (I am using mavproxy) or do you mean in Mission Planer?

Unfortunately I don’t have an oscilloscope.

Yes I have DJI opto 30ESCs that I will try sometime today.

So I just tried the DJI ESC and motor, and the behavior is slightly different, but still problematic.

The motor doesn’t spin unarmed and at 0% throttle.

However, when I do a motor test, the motor doesn’t spin at a constant speed and skips.

I put the dataflash log here:

http://expirebox.com/download/0f9c48d4447a70bb0b16dbbb70ac4936.html

I erased dataflash logs, rebooted rpi2, launched motor test and downloaded this file via mavlink.

Something else that is weird is that:

pin1 = Motor B
pin2 = Motor E
pin3 = Motor F
pin4 = Motor C
pin5 = Motor A
pin6 = Motor D

I’m not sure if this is normal

So I just tried randomly changing a setting in Mission Planner parameters.

I put ESC Update Speed at 50Hz, and it seems it’s working with the DJi ESC!
I’ll try the other ESC now.

Works nicely now! Am I the only one that needs to set that param to 50Hz, or did I miss something in the docs?? Is there a side effect of making this change?
It seems my problem is solved!

I know this type of problem well from the smaller racing quads. First of all the default APM settings have two strong (low) a low pass filter on the INS_ACCEL_FILTER and INS_GYRO_FILTER (the old name was a single INS_MPU6K_FILTER for which you may historically find such articles/issues documented). This defaults to 20 (Hz) but should be increased to 42 or 98 to correct the wobbling. For example on smaller 250 frames with Afro ESCs this setting is essential to get any kind of stability.

Secondly I personally found that the RC_SPEED parameter (the one I guess you set down from 490Hz to 50Hz) needs to be an exact multiple of the native ESC speed. My Afro ESCs have a native update speed of 1000 Hz so 490 Hz RC_SPEED just doesn’t fit. Changing it to the 50, 100 or 250 helped a lot even without the filter setting.

You want the highest update speed for ESCs for performance, so best find a solution where you don’t have to change RC_SPEED. If the filter settings don’t work then you should look at the ESC settings in the firmware flash tool and turn off anything like “brake” mode (but be careful to avoid any really advanced parameters as messing with the power control settings has a warning that damage can occur). I’m just talking about checking the basic user settings and the usability options of the advanced settings.

Depending on the flash tool (I use RapidFlash from Google Play store) you can also fix the RC low/upper range here and disable RC calibration to prevent APM from messing-up your ranges (I found that occurred on the latest APM release when testing the new calibration function).

Now regarding these ZTW Spider ESCs I think I can help there too, or have the same problem to solve. I just built a new quad with the ZTW motor & ESC combos (ESC built into the bottom of the motors) and have the same issue which is massively reduced by the filter settings but does not go away. That has BLHeli firmware though. So I’ll be checking out ZTW issues now and hope to solve this problem and share the result in case it’s the same issue you have. It could be ZTW specific, perhaps something to do with their OneShot support or just a timing issue of the current firmware version.

Your ESC will only update at 50Hz, which will degrade stabilization performance. Can you try at which frequency your ESCs will stop working?

At 59Hz they still work, and at 60Hz the erratic behaviour occurs again.

I don’t have an oscilloscope, but I do have an arduino. Maybe I can read frequency and duty cycle with it.
I’ll see what google has to offer.

So I found this arduino sketch seems it’s able to read pwm frequency, but I don’t know how reliable it is.
If you want try it out, it’s here

Here are some values with RC_SPEED at 50Hz

pulsetime(us) = 1098.50, pd_us(us) = 19987.50, pulseFreq(Hz) = 50.03
pulsetime(us) = 1098.00, pd_us(us) = 19987.50, pulseFreq(Hz) = 50.03
pulsetime(us) = 1098.00, pd_us(us) = 19987.50, pulseFreq(Hz) = 50.03
pulsetime(us) = 1098.50, pd_us(us) = 19987.00, pulseFreq(Hz) = 50.03
pulsetime(us) = 1098.00, pd_us(us) = 19988.00, pulseFreq(Hz) = 50.03
pulsetime(us) = 1098.50, pd_us(us) = 19987.00, pulseFreq(Hz) = 50.03
pulsetime(us) = 1098.00, pd_us(us) = 19987.50, pulseFreq(Hz) = 50.03
pulsetime(us) = 1100.00, pd_us(us) = 19987.00, pulseFreq(Hz) = 50.03
pulsetime(us) = 1098.50, pd_us(us) = 19987.50, pulseFreq(Hz) = 50.03

Next I change RC_SPEED to 100Hz and restart arducopter.

pulsetime(us) = 1098.50, pd_us(us) = 5696.50, pulseFreq(Hz) = 175.55
pulsetime(us) = 1098.50, pd_us(us) = 7755.00, pulseFreq(Hz) = 128.95
pulsetime(us) = 1098.00, pd_us(us) = 8329.00, pulseFreq(Hz) = 120.06
pulsetime(us) = 1098.50, pd_us(us) = 6659.50, pulseFreq(Hz) = 150.16
pulsetime(us) = 1091.50, pd_us(us) = 5095.00, pulseFreq(Hz) = 196.27
pulsetime(us) = 1098.50, pd_us(us) = 9987.50, pulseFreq(Hz) = 100.13
pulsetime(us) = 1604.00, pd_us(us) = 9994.00, pulseFreq(Hz) = 100.06
pulsetime(us) = 1098.00, pd_us(us) = 8275.50, pulseFreq(Hz) = 120.84
pulsetime(us) = 1098.50, pd_us(us) = 5304.00, pulseFreq(Hz) = 188.54
pulsetime(us) = 1098.00, pd_us(us) = 6705.00, pulseFreq(Hz) = 149.14
pulsetime(us) = 1098.50, pd_us(us) = 9395.00, pulseFreq(Hz) = 106.44
pulsetime(us) = 1098.00, pd_us(us) = 9324.00, pulseFreq(Hz) = 107.25
pulsetime(us) = 1098.50, pd_us(us) = 3398.50, pulseFreq(Hz) = 294.25

So it seems I far away from 100Hz.
If I stop arducopter then I get proper frequency reading:

pulsetime(us) = 1098.50, pd_us(us) = 9994.00, pulseFreq(Hz) = 100.06
pulsetime(us) = 1099.50, pd_us(us) = 9994.50, pulseFreq(Hz) = 100.06
pulsetime(us) = 1098.50, pd_us(us) = 9994.00, pulseFreq(Hz) = 100.06
pulsetime(us) = 1098.50, pd_us(us) = 9994.00, pulseFreq(Hz) = 100.06
pulsetime(us) = 1098.00, pd_us(us) = 9994.50, pulseFreq(Hz) = 100.06
pulsetime(us) = 1098.50, pd_us(us) = 9994.00, pulseFreq(Hz) = 100.06
pulsetime(us) = 1098.50, pd_us(us) = 9994.00, pulseFreq(Hz) = 100.06
pulsetime(us) = 1098.00, pd_us(us) = 9994.50, pulseFreq(Hz) = 100.06
pulsetime(us) = 1094.00, pd_us(us) = 9998.50, pulseFreq(Hz) = 100.01
pulsetime(us) = 1098.50, pd_us(us) = 9989.50, pulseFreq(Hz) = 100.11
pulsetime(us) = 1098.00, pd_us(us) = 9994.50, pulseFreq(Hz) = 100.06
pulsetime(us) = 1098.50, pd_us(us) = 9994.00, pulseFreq(Hz) = 100.06
pulsetime(us) = 1098.50, pd_us(us) = 9994.00, pulseFreq(Hz) = 100.06

I can repeat this for many different frequency values I set in RC_SPEED. It seems that when arducopter is running, the PWM signal is not good.

This fixed my problem:

The key setting which made the most improvement was “Enable PWM output” (was just OneShot by default!) and disabling the “PWM output dither”. These defaults appears to be bad for ZTW ESCs, very bad!

The other change was to turn down the motor timing, but this is specific to each motor so high or low is not better, medium should work for most.

I’m also going to try turning off dampening and leave PWM frequency at the standard high. Unless you are FPV racing (less likely with Navio/bigger drones) “motor brake” (called damping in BLHeli) is unnecessary and sounds like it’s stressing the motors: - YouTube

By the way this incompatibility (more the other way around actually as OneShot is still relatively new) is because DIY Drones didn’t implement OneShot support (in fact they didn’t even acknowledge it had any benefit for a while). Please “encourage” them here: OneShot PWM output for new ESCs · Issue #1825 · ArduPilot/ardupilot · GitHub