At~20 seconds you see the first what I would consider tilting too far (baring in mind the level camera the angle seems too great, and far different to the previous), losing quite some altitude, after the second time I rise up ‘just in case’ and it then tipped too far to be able to recover before it hit the (thankfully soft) mud and bounced over on landing, despite full throttle to climb out. The log file shows that 1000 throttle was output to correct for the altitude loss at the end, but I can’t see why this is needed, this Hex isn’t overloaded, and the wind wasn’t too high. My main question is: Is the fault that it’s somehow underpowered, too windy, the AC tilting too far during the autotune, or something else?
Before the comments come in here are some key points:
Autotune mode in althold
Wind~10mph gust
F550 @1.9kg AUW (DJI state up to 2.4kg)
Standard DJI motors/props/ESCs
Brushless gimbal for GoPro
I estimate 550 for throttle to hover
This is a classic esc sync problem. However, this is the first time I have seen it on non-SimonK esc’s.
You had 3 incidents. I suspect that you only lost 1 esc on the first 2 but on the third you lost 2 esc’s and the copter went over. The reason you appeared to not loose power is because you didn’t have all the motors going and the rest were working overtime to make up for the lost motor/s.
Could you tell us if you have reflashed your esc’s and exactly what motor and prop setup you are running.
I had an almost identical situation happen with a Droidworx hexacopter last week. I didn’t report it as I put it down to too much wind. I repeated the process on a totally still day and the Auto Tune worked great.
[quote=“Leonardthall”]Hi ronhogwarts,
This is a classic esc sync problem. However, this is the first time I have seen it on non-SimonK esc’s.
[/quote]
That’s interesting as I am using HobbyKing blue series ESCs reflashed with SimonK on the copter that had an almost identical crash. Fortunately it wasn’t that high at the time and landed in some tall soft grass so the only damage was one broken prop.
This is a classic esc sync problem. However, this is the first time I have seen it on non-SimonK esc’s.
You had 3 incidents. I suspect that you only lost 1 esc on the first 2 but on the third you lost 2 esc’s and the copter went over. The reason you appeared to not loose power is because you didn’t have all the motors going and the rest were working overtime to make up for the lost motor/s.
Could you tell us if you have reflashed your esc’s and exactly what motor and prop setup you are running.[/quote]
I am using 3s 5Ah LiPo with DJI 1038 props (10 inch by 3.8 pitch) with DJI 2212/920kv motors and DJI 30A OPTO multirotor ESCs all stock. It has never had this problem before as a quad, I recently bought two identical ESCs, props, motors to convert F450 quad to F550 hex, and that is what crashed. I am using the Arducopter 3.1 stable release as I was testing the wizard on mission planner. I’m worried flying it again will have the same problem, and I don’t get why this is an issue now and has never shown before. I hope there is a simple answer. From what I’ve heard the only potential workaround is to be ready to flip to acro and try to autotune in dead calm conditions?
Acro won’t help you recover from this type of problem and if autotune can cause the problem, flying is stabilise will also do the same thing if you fly it hard enough. My shake down flights are MUCH more grueling than autotune by a long shot! We have actually always, and regularly, had esc sync issues that have caused crashes. Autotune tends to repeatedly do maneuvers that can cause autotune and therefore a copter that is prone to this issues generally noticed it much quicker now. Previously a pilot may fly conservatively enough to not cause the problem for a long time before a little aggressive flying or gusty weather finally show the problem.
The alternative to using autotune is to do stick to manual tuning. When we release 3.2 we intend to do a few things that may help.
Acro won’t help you recover from this type of problem and if autotune can cause the problem, flying is stabilise will also do the same thing if you fly it hard enough. My shake down flights are MUCH more grueling than autotune by a long shot! We have actually always, and regularly, had esc sync issues that have caused crashes. Autotune tends to repeatedly do maneuvers that can cause autotune and therefore a copter that is prone to this issues generally noticed it much quicker now. Previously a pilot may fly conservatively enough to not cause the problem for a long time before a little aggressive flying or gusty weather finally show the problem.
The alternative to using autotune is to do stick to manual tuning. When we release 3.2 we intend to do a few things that may help.[/quote]
Thanks for the advice, I’ll try manual tuning for now then. Do you fly a quad or hex on those ‘shake down flights’, and which ESCs with what firmware do you use/recommend? Do you have a rough timescale for Arducopter 3.2 release, are we talking a few months, end of the year?
Hi,
I do my shakedown flights on every frame I fly (I enjoy thrashing the crap out of a frame). I am currently building 2, 5 to 10 kg hex’s, with 18 inch props and I will do the same with that.
I am not sure when 3.2 will be out but I would be surprised if a beta release isn’t made before the end of March. This will have some major changes so I expect it to be a slow release.
Yes, this bug was probably a contributing factor to it rolling too far and the initial acceleration down and it is possible that it was the entire cause. However, your logs don’t have motor outputs logged so we can’t know for sure. You are flying stock pids so you shouldn’t been in any significant danger of hitting this particular problem.
My gut feeling is this bug has been exaggerating what should have been very minor events for a while now.
Hello, this is mainly for those who have this issue and find this post, I have just found that the DJI OPTO ESCs e.g. 30A have a maximum of 450Hz update rate: wiki.dji.com/en/index.php/ESC
However the Arducopter firmware is set by default to 490 Hz, so this could be the issue I was having, I wonder if setting the rate for these ESCs down to 450 Hz would solve the issue?