I’ve just downloaded the latest log (from my hard crash flight, crash when autotuning) from the controller.
I don’t realy know, where to start analyzing the log, so I’ve uploaded the Vibration graph. I can see this hard Vibration at the end of the flight. But I don’t know, whether this was the reason for my crash. There are also some markers indicating a crash and low battery. Are these the reasons for the crash?
Let me know, if another parameter from the log would be more helpful, than the vibration graph.
//Edit1: Added Vibrations 3.3 graph
What are the differences between “vibrations” and “vibrations 3.3”?
//Edit2:
I took a look at a previous flight with trying to autotune (also a missleading attempt with a not-so-hard crash at the end). There were no battery errors in the log. See the log below
You need to post the actual logs, so we can look at them. It sounds very much like you’re getting ESC desync - it’s mostly commonly seen in autotune because autotune commands sudden movements that trigger the desyncs. Do you have active braking/damping light set in the esc firmware? That’s the most common cause, first thing is to ensure that’s turned off. However it’s very uncommon to get desyncs in such a small/highkv motor. What size props are you turning?
Log File C:\Program Files (x86)\Mission Planner\logs\QUADROTOR\1\2018-03-11 17-53-49.log
Size (kb) 2798.86328125
No of lines 33681
Duration 0:04:48
Vehicletype ArduCopter
Firmware Version V3.5.2
Firmware Hash 62a12357
Hardware Type
Free Mem 0
Skipped Lines 0
Test: Autotune = UNKNOWN - [?] Autotune 5763-24270
Test: Brownout = GOOD -
Test: Compass = FAIL - Large change in mag_field (116.09%)
Max mag field length (662.62) > recommended (550.00)
Test: Dupe Log Data = GOOD -
Test: Empty = GOOD -
Test: Event/Failsafe = FAIL - ERRs found: FLT_MODE FS_BATT CRASH
Test: GPS = GOOD -
Test: IMU Mismatch = NA -
Test: Motor Balance = GOOD - Motor channel averages = [1467, 1504, 1513, 1524]
Average motor output = 1502
Difference between min and max motor averages = 57
Test: NaNs = GOOD -
Test: OpticalFlow = FAIL - FAIL: no optical flow data
Test: Parameters = FAIL - ‘THR_MIN’ not found
Test: PM = GOOD -
Test: Pitch/Roll = UNKNOWN - 'BarAlt’
Test: Thrust = GOOD -
Test: VCC = UNKNOWN - ‘POWR’
What I can say is, that there aren’t any bad Parameters…except the compass. But I don’t think this had an impact on the autotune.
Oh and FLT_MODE FS_BATT CRASH …what does that mean?
“Actual logs” means either the .log or the .bin file that is time stamped for a particular flight.
The text you posted is a dump from running a log file through Auto Analysis.
The “10” in 1045 means the prop is 10" long.
The “45” in 1045 means the prop has a “pitch” or blade angle of attack that will move the prop 4.5" for every revolution.
The only way to examine/change any BLHeli settings is to connect the ESC to either an Arduino, or connect the ESCs to a CleanFlight/BetaFlight/iNav compatible flight controller and use BLHeli Suite.
Do you think, this was the reason for crashing?
I’m not sure about it. Because i had the issues of tilting during autotune in other flights, where the Logs don’t show this Parameter / Error.
So are my props the right ones for my Motors? They came together, so I thought, they might fit.
I have an Arduino at home, so I will take a look at the ESC Settings.
Do you recommend to turn off Active Breaking / Damping, when it is activated? I think I read somethin of active breaking feature, when buying my ESCs.
What I recommend is that you go back and read the entire Wiki from start to finish so can get the big picture. When you go through Initial Setup > Mandatory Hardware, DO NOT SKIP ANY STEPS. Then go to Initial Setup > Optional hardware and configure the power module.
Second, for an aircraft as large as your 450, using BLHeli serves no useful purpose. The purpose of BLHeli firmware is to provide RACERS with the kind of throttle response and ESC/motor performance they need to win races. Oneshot support was added to ArduCopter to support the PixRacer.
Ditch the BLHeli ESCs and get some plain old ESCs. DO NOT GET ESCs with SimonK firmware. SimonK is a half step between generic and BLHeli and its outdated. I use Hobbywing parts like the X-Rotor 40A OPTOs I have on my Tarot 680 Pro Hex and my stretched Tarot 650 Sport Quad. For “smaller” aircraft I use either Hobbywing Platinum Pro 30A OPTOs, or Hobbywing Pentium 30A with 2A BEC.
Post the log. Nobody here can help you until you post the log.
They’re probably fine, I was just making sure you weren’t using ridiculously large props for the motors that might be causing problems
Yes, turn it off. Get your craft flying 100% with basic settings, then you can experiment with ‘nice’ extras like active braking.
Nothing wrong with BLHeli, it’s not just for racers, you just have to be careful of some of the settings. I don’t think oneshot had anything to do with pixracer - it works on other FCs and pixracer works with normal PWM. Agree with you on hobbywing ESCs, they’re fantastic.
Right, I have BLHeli firmware ESC’s (BLHeli and BLHeli_S) running on all my multirotors small to large with Pixracers and Pixhawks. All are set for Oneshot 125 in Arducopter and working well.Agree, the Hobbywing ESC I have in my Rover is bombproof.
What you think and what I know are two entirely different things. Adding Oneshot support to ArduCopter was all about PixRacer because NO ONE ELSE NEEDS IT. Go back through the AC3.x.x blogs and you can read all about it.
Here’s another clue for ya: OneShot, was created LONG before PixRacer, and for those FCs that can talk to BlHeli ESCs, if you use a receiver that does not support PPM, S.Bus, iBus, or any other serial protocol, you must configure the ESC input signals to be PWM which TURNS BLHELI OFF. BTDT. Maybe you should read up on BLHeli, CleanFlight, BetaFlight, and iNav, too…
As for Oneshot and larger aircraft, BLHeli ESCs choke, blow chunks and desync:
This is identical to the behavior I got using DYS XM20A ESCs with BlHeli 14.1 firmware connected to 5010-530Kv motors swinging 1555 CF props on 4S.
For any one else coming across this with a quizzical eye, this is incorrect information. BLHeli has had a few bugs that cause desync in it’s history, along with pretty much any ESC firmware, but both BLHeli and oneshot work fine with larger aircraft. I have hundreds of hours on lowkv motors with large props on blheli and oneshot, as have lots of others. Just be careful of your settings and test well. Always turn active braking off.
Fine, you believe what you want. I have a racer that loves BlHeli, and three other aircraft that don’t. I’m not about to risk several thousand dollars to run something that is of no use to me.
Why have you got the ESC BEC connected to the flight controller? I believe you should almost never do that.
The good news is there doesn’t seem to be any indication of ESC desync or propulsion failure from these logs. It does look like it all goes a bit squiffy immediately after autotune starts. Does the copter fly in stabilize OK, with sharp attitude changes? You need a reasonable manual tune before you attempt autotune. It looks like the autotune commands a sudden movement and the controller can’t cope with this, possibly due to poor initial tuning.
On the emlid documents for navio2 i’ve read about power redundancy (controller gets power, even if the primary power source stops working), this sounds resonable for me. Also the ESCs have 3 wires, so I’m carefully cutting a wire, when i don’T exatly know, what i’m doing.
To be honest, I don’t really get it, why I should NOT connect these extra cables :D…Maybe you can sort things out for me…Thank you.
Okay, thank you for taking a look at my logs. Maybe you can say, where to look for sync issues in the logs.
At my very first try to lift of, my copter was totally not flyable. It wobbled extremly and it was not possible to climb a few centimeters. So I changed the PIDs and after that I was able to fly for several minutes. I even climed around 15 meters or something like that without any Problem.
But it was not that sable as I expected (Saw some cool videos). So I thought autotune would be the way to got.
Would it help to lower the aggressiveness of the autotune as it is described here?
Have a look at this thread for a clear indication of a desync:
Sure you can try to reduce the aggressiveness to start with, but you’re much better off getting a half-decent manual tune first. Don’t try autotune before you can fly in stabilize with sharp movements, without losing control. Here’s a good way of doing it: http://ardupilot.org/copter/docs/ac_rollpitchtuning.html
So.
I’ve did a Second attempt. New frame (s500) and new controllers (hobbywing x-rotor).
Everything fine Now. Copter flies pretty stable with Standard parameters. I think some fine Tuning is still necessary, but for now it looks great.
I don’t know the exact reasons for my crashs earlier. Maybe a mix of different Things:D
