[Solved] Erratic motors

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: https://youtu.be/QiAJkl_Opxk

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: https://github.com/diydrones/ardupilot/issues/1825

But what I am trying to point at with the readings I got from the arduino, is that the PWM signals on the Navio aren’t “clean”.
Since I have the exact same problem with the DJi 30A opto ESC (which are fairly common), it seems to indicate this as well.

Hi Sebastian,
[edit] (Never mind - I just found your separate post)
[/edit]
I quickly read your post yesterday - I don’t remember exactly what you did do RC6. Can you post that information back when you have a moment? I would try it as well shortly.

It seems some incorrect settings for the “gimbal settings” were the cause of my issue.
I’ve now completely disabled all gimbal settings, and I am ready steady pulse frequencies with my arduino. Now I just need to test with a motor, but I will only do that next week end.

I do not think you set something wrong, there must be a bug in the code for the RC coprocessor.
One of the features of the Navio2 board should be to support different PWM frequencies on the output pins. The Navio+ only supported one frequency for all pins, so it was not possible to use anlog servos with Arducopter for example.

Yeah, seems like there’s something wrong with frequencies. We’ll look into it.

@mikhailavkhimenia

Any update on this?

Whenever I enable an RC10_FUNCTION or RC11_FUNCTION it seems to cause the problem. I was trying mode 29 for my landing gear. As soon as I enable either, my motors go crazy.

I have to set rc_speed=50hz, restart arducopter, and then my motors behave normally.

For now I can’t use the landing gear or a camera gimbal.