2 Motors Run Slower

In a HEX config, motors 6 and 4 (3DR order) run slower than the other 4 almost tipping over backwards.
Calibrated the ESCs several times but no change.

Flies great though, if I take off aggressively.
But it tends to fly back to me due to the two slower motors.
I have performed auto trim and no change either.

Any ideas?

Logs would be good to evaluate correctly

Sorry about that, here it is:
1 12-31-1999 6-02-58 PM.bin (1.4 MB)

Double check your CofG and also try 2 new props on motors 6 & 4 and/or the motors directly opposite.

Results took a strange turn.
I had loaded 3.4.2 for a test when it was requested I post a log.
I reloaded 3.3.3 and motors 6 & 4 were turning fast/ normal.
But as I raised the throttle slowly, it started to tip towards the front right.
Now motors 5 & 1 are turning slower.
Went on to test 3.4.2, came back to 3.3.3 and now motors 6 & 4 are slower again
And I get this with the Mission Planner Auto Analisys: “Test: Motor Balance = WARN - Motor channel averages = [1343, 1446, 1406, 1401, 1356, 1442]
Average motor output = 1399”

Do yourself a favor and use Copter 3.4 latest release, and calibrate from the start. Is it a PixHawk or a variant ??

Pixhawk 2.4.8
And I cannot go to 3.4.2
I have had really screwy results there on all 3 of my PixHawk based craft.
a 450, 550 and this 680

Look for my other issues posted without resolve.

The only common issue I can see in this and the other issues you’ve raised, is the hardware you’re using.
Are you sure that that PixHawk variant is ok ?

Yes sir, the preferred “budget PixHawk” used and recommended by the RC Groups “CX-20 Cheerson Auto Pathfinder” thread users.
Once they burn out the knowledge of the CX-20, they build their own APM based quads/ hex and octos.
They stick around guiding newbees.

No problem with “budget” hardware as long it behaves “normally”. I have one of the PixHawk Lites and have recommended it to several “budget” tight friends, but YMMV.
The log you posted above has a few things that I have never seen and “should not” behave like that when following the code, so the debugging follows to the hw :slight_smile:

Exactly!
I came to PixHawk because my APM2.8 would not immediately cut motors on touchdown with any automated landing mode/ command.
Then, not only did the PixHawk not fix the issue I originally purchased it for…it added issues.
But, everything I am seeing, no one has seen before.
Even ones that have purchased within the same batch of 2.4.8

Are you taking off in PosHold or Loiter?

Stabilize, slow enough to see the motors in question spin slowly.

Your RCout (outputs to ESCs) seem almost linear in their values, some are consistently low, others higher. From your log one part looks like this:

Ch1 doesn’t increase much at all, Ch5 next lowest, 4 & 3 higher and 6 & 2 highest. So it is a bit odd. Why, I don’t know but I’m guessing it’s something in your setup. The graphs seem to eliminate something wrong with your hardware.

Can you post your parameter file here?

The first part of the log files has the parameters

Of course. Thanks.

There are so many params that have changed from the default that it’s hard to pin anything down.
Some things I noticed is no compass declination, safety button is disabled, circle radius = 0, compass learn is off, compass_use is off, (how can you not use a compass on a multirotor), battery failsafe voltage is set to 12.7V, how did you get that value?
Compassmot is set but you’re not using a compass, GPS is set to None, is this a racing hex?
And a big one: INS_USE is 0, so what IMU is being used?

Best thing to start fresh with all default params and go from there, with so many things changed there’s no knowing how the flight controller will react.

The parameters and some of their values did point me to a possible hw issue. The GPS absence might not be important in Stab.

@Graham_Dyer ,
In the order of the questions:
Compass declination is my bad, no idea it was off.

I learned with the APM2.8 - hate the PixHawk safety button.

Circle radius is 0 because I am an avid automated mission pilot. Circle Radius can now be controlled by the radius param with the Loiter_Turns command. However, if you have a value in the Circle Radius param and place a value in the radius for the loiter_turns command, the two are added together.

The issue might have changed for the compass learn but CX-20 thread on RCGroups said to keep it off. Yes a CX-20 is much different than a build but that thread has gone on to not only support CX-20 flyers but multi rotor builds with APM based FCs too.

Compass use is indeed on.

Battery V of 12.7 failsafe comes from months of trial and error of finding where 78% used is on a 5200mAh 4S battery.

GPS is on as well as INS_USE.
Matter of fact, INS_USE and INS_USE2 both = 1

Ok, interesting… I just compared your parameters to my multirotor (stock params except for tuning) and those mentioned were the ones that I found that were not the same from your logfile.

I still think you need to start again with standard params including accelerometer calibration, and then change the things you want like Circle Radius, tuning, etc. You can save your param file, start fresh and compare to see what you want to change. With so many changed parameters it’ll be very hard to pin down a cause for your problem as some parameters affect others in different ways.

I still think it’s not hardware as the outputs from the FC to the motors differ so much but I could be wrong. It looks like it’s trying to take off on a 30° slope.

Interesting that 12.7v is the value that shows when 78% is used, that’s 3.1V per cell, mine has NO power left at 3.25v per cell as it’s already hit the voltage cliff. Maybe it’s just a calibration/hardware difference.

GPS might be ON, but Copter thinks otherwise…