RTL crash (again)

[quote=“Leonardthall”]It looks like something physically changed between the two flights on the log. This may have been a slight movement in one of the arms causing the yaw offset John mentioned (I would not be surprised if something is looser than it should be). However, what ever changed was enough to set the copter stability right on the edge. From here anything can make the difference, battery voltage, wind, airspeed, roll or pitch angle, temperature. In your case you had two instances, one in alt hold and one in RTL.
[/quote]
Now this makes sense. All along I’ve been asking why, if the copter was so unstable and on the edge, this condition didn’t show up during my testing? I did check the copter when it landed but I didn’t see anything obvious. It’s a shame I’ve now changed some things as it would have been a great test to do another flight and see if I could trip the same event.

[quote=“Leonardthall”]
I would also suggest that you will make the people helping you feel more appreciated if you spend less time suggesting code problems, or insulting comparisons with other systems, when your mistakes are pointed out.[/quote]
It works both ways Leonard. No one is a bigger fan boy of your work than I am. I’ve spent a lot of time and money supporting this project and your work. I’m not sure what more you expect.

When I ask for support I don’t appreciate being made to feel like I’m in an inquest. I know how trouble shooting works. I actually operate a tech support service which Tridge volunteers efforts to. To tell a user to go read the code when you know damn well I’m not a software engineer or to suggest that I should go learn how to read logs and do basic algebra is insulting and disrespectful. I believe that users deserve more respect than that.

I do read logs and I have worked out a lot by myself. I have enjoyed learning from your contributions and feedback. I never ask for assistance without putting in a lot of time trying to work things out first. I totally respect how busy developers are and the demands they are under.

I only suggested the code might handle things better after listening to how it worked. Tridge did mention to me today that one of the first patches he did was to the stability code which had issues. Is it so unreasonable to ask if it could be developed further? We also know about the barometer issue which thank goodness didn’t catch many people out given it existed in the first release of the Pixhawk. The code is typically the last thing to look at but it’s not perfect and you know that.

I’ve made the suggestion that perhaps the software could warn if the hover rate is too high and putting the copter in to a dangerous situation. There was no response. And personally I’d prefer to have an unstable landing than a stable crash but I understand Jon’s explanation as to why that probably isn’t a good idea. So I was just asking if there might be some way to let the pilot call for more thrust. If not, that’s fine but why give me grief for asking the question?

I also asked Tridge why my hover rate appears so high when the throttle on the Tx doesn’t indicate this. 80% is quite extreme and it just seems so odd that I wouldn’t notice that during previous tests given how much experience I have. So maybe after the first landing a battery came loose? It does behave like this if flown on a single battery. But me saying that the hover rate can’t be that high just gets ignored because there is a graph to show that it was at that rate. Well it might have been at that point at time but do you really think a 7.5 Kg AUW copter with 8 Tiger 4014-11 motors, 15 inch Tiger CF props and two 8Amp batteries is really going to have such a high hover rate? You fly big copters so you know what I’m saying is true. ECalc and Droidworx staff seem to think it’s ok.

So where’s the recognition that I followed your instructions to autotune the copter without load and then adjust manually to my preference? Where’s the comment about how good it was that I tested at length with and without load before putting valuable load on the copter? I did a LOT of things right. Here’s an opportunity for the developers to learn how things can go astray even with a fairly switched on user. BTW, I do have one of the most respected degrees in photography and a degree in computer science. So I find it hard to believe that I don’t have anything to contribute here.

Lastly where is the thanks that I’ve taken on what few people would and worked very hard to demonstrate how advanced this platform is and that it can be used successfully for one of the most demanding roles for multicopters? I could have just whacked a Wookong on it and had a lot of nice videos by now. That is a fact. If it bothers you I can’t help that. No one asked me to this, I just wanted to do whatever I could to contribute without being a software engineer.

If I’m annoying the developers so much I guess it’s time I just move on. It’s sad it didn’t work out and I’m very disappointed I’ll miss out on all the great work you are doing but such is life.

Lastly I would like you to know that I do appreciate your time and feedback. I have always found your explanations a bit easier to follow and more down to earth/logical. We obviously don’t agree about some things but that’s not a huge deal.

Cheers.

I am not here to tell you how good you are. I am here to tell you what you are doing wrong. This IS an inquest to find out why your copter failed and it was requested by you!

Any developers first thought is to find software bugs because that is the biggest risk to the community. Most of the time the problems are caused by relatively obvious user errors and our attention turns to providing suggestions about what could cause the problems we see in the logs.

In your case you:
You didn’t wire your motors up correctly.
Based on our discussion I believe you have misaligned motors.
Based on our discussion I believe misalignment happened in a simple land and takeoff suggesting that you have not tightened all the arms sufficiently.
You didn’t follow my instructions on autotune (despite your assertion otherwise). I can tell this because roll and pitch rate pids are identical. You obviously changed your rate values.
You have not set your Throttle Mid or even aware of what your copter is hovering at. This is the most basic of log analysis and you say you have made an effort to understand the logs.

All these are beginner mistakes, not mistakes made by an experienced user on such a potentially dangerous copter. I would rate your copter as not flight worthy! And I would say you are lucky you still have it, no matter what flight controller you put on it.

Based on your hardware description and assuming 6s batteries I eCalc tells me you to hover between 75% and 85%. Surprise surprise, that is what we see in your logs. This makes me think you aren’t using eCalc properly.

I realise that you think you are constructive and helpful. I think you have an aggressive tone and think that your problems are more important than others because you spent more money. Then you waste time by telling us why we can’t be right instead of looking for why we are seeing what we are telling you we are seeing.

And where do you get off thinking I should be grateful because you used Arducopter on your expensive frame. All I see is someone that is likely to crash his expensive copter into a crowd of people then blame Arducopter because he isn’t willing to take responsibility for his own mistakes.

I help a crapload of people on these forums with problems just like yours. You take upwards of 10 x my time when compared to the average user fixing the same problem. This is because you are making very simple mistakes and because of your attitude and your resistance to any suggestion that you messed up!

Good luck with your Wookong!

I’m glad you have been so up front with me. Thanks. I wish you would have had this discussion with me much earlier as it would have saved me a lot of time/money and you a lot of frustration. I would have been happy to talk with you directly. I’d encourage you to work on your communication skills a bit.

I think your personal statements about me are quite uncalled for especially in a public forum. You have no evidence that I’ll crash a copter in to a crowd and to say that is horrible. I’ve put a lot of effort in to promoting safety and contributing to the RC community.

I’ve already had a chat with the manufacturer of my equipment and come up with a good alternative that doesn’t involve DJI thank goodness. 5 min setup, overnight delivery and all the features I need. Gets great reviews from users as flying super smooth and is sold at a good price. The time I save in not having to endlessly tune it, reading logs and having these discussions will be well spent on producing work. It gets the results as well. Lots of pros use it so I think it will be a good fit for me.

So in a funny way it’s all worked out OK for both of us. Good luck with your project. I think it’s great for planes and autonomous fight. Quite an impressive accomplishment. Just not right for me with my use of multicopters right now.

Cheers.

Just curious which system you ended up with? I’m gonna guess at Hoverfly?

As to the question of why didn’t you see the instability when flying manually, it only showed up in an auto-mode, the reason is because the auto modes can “poke” the stability controller a bit. It can ask for roll and pitch rather sharply sometimes. More sharply than a good pilot would. This can upset the stability controller. It’s not to say that the autopilot is the cause of the problem, again, it just reveals the problem that was always there. Even if you’re the smoothest pilot in the world, you were just one gust of wind away from having a problem. In fact, even in manual modes, I can see that the stability is not great. There are many places where there are bulk attitude control problems.

The reason the “stability patch” was created as it is now is simple: What is the biggest threat to copters? Crashing into the ground. How do you avoid crashing into the ground? You need vertical thrust. You can only achieve vertical thrust, if the copter is level. Therefore, we chose to prioritize levelling control, over pure throttle. If you have access to full throttle, but you’re upside down, that won’t help you avoid the ground. Obviously this was a compromise decision. But it does work very well when the copter is otherwise setup properly.

It’s not fair to say that Arducopter is not suited for large professional camera ships. There are quite a few people using them for that purpose. But, the Arducopter system isn’t for everybody. Some people are willing to trade off adjustability and flexibility in the name of simplicity. And that’s fine. There’s a market for either approach, just as there is a market for both Android phones and Apple phones.

Not a compromise, a necessity.

Choosing to also prioritize 100pwm of yaw control is a compromise, but chances are most users will crash if their copter starts spinning anyway.

I decided to put my Wookong on the octocopter. I just need to get on with things and I fly/work with others using that system so it’s just less variables to deal with. I haven’t done much with it yet other than a quick test flight as I’m waiting for some larger props to give me that extra margin recommended in this thread.

I also replaced a Pixhawk on my hexacopter to test a XAircraft SuperX. Interestingly enough it’s not working at all. We are still trying to work out what the issue is. But the support has been fantastic.

Is there any possibility that I ran in to this bug?

“Warning #1: BUG found in stability patch which can cause all motors to go to minimum if there are simultaneously very high throttle, roll and pitch commands. The problem is rare but most details will be posted on when exactly it can occur. A release candidate which fixes the issue, AC3.1.3-rc1, is available through the Mission Planner’s Beta Firmwares link.”

Sounds similar.

Nope, no evidence of that bug that I can see. That bug is characterized by a high demanded throttle in producing an extremely low (<50%) throttle out. This doesn’t occur in your log, except possibly for one or two single-sample transients that I can see. The issues with your copter were as stated: underpowered (too little throttle margin to safely fly with a motor out even in perfect conditions), unstable gains, twisted arm(s), and swapped motors (halving your yaw authority, causing the stability patch to do double effort to offset the error from twisted arm(s)).

Thanks for that. Appreciate your time.

Please don’t take this as argumentative. I’m just curious.

I did check the arms and they weren’t twisted. It’s next to impossible to do that on a Droidworx frame. However, it it easy to twist a motor and have it out of alignment which is the same effect as the pins they use for alignment are designed to break in a crash to prevent greater damage. If you don’t check the motors after a crash you can get caught out by that. It’s fairly easy to detect though and easy to see the effect in flight.

I didn’t give a lot of weight to the swapped motors as there was a comment that being a coax and having the top and bottom swapped wouldn’t be a large factor. Would having the top and bottom motor swapped on a coax really half the yaw authority? Wish I knew more about code as I’d love to have a better understanding of how things work. I envy you in that.

I should also mention that I don’t think that motor swap was there in the previous 2 incidents of the three. I changed a motor out after the second incident and obviously got it wrong. Should have double checked/tested it.

I increased the prop size to give me a bit more thrust and it’s flying very well now. I did change the flight controller but I am still using the APM on a couple of copters and I’ll be putting the Pixhawk on my Techpod if I ever get time to build it.

Please don’t take this as argumentative. I’m just curious.

I did check the arms and they weren’t twisted. It’s next to impossible to do that on a Droidworx frame. However, it it easy to twist a motor and have it out of alignment which is the same effect as the pins they use for alignment are designed to break in a crash to prevent greater damage. If you don’t check the motors after a crash you can get caught out by that. It’s fairly easy to detect though and easy to see the effect in flight.[/quote]
Something had to have produced that large yaw offset.

That’s really a physical thing, not a code thing: a yaw demand changes the distribution of throttle between CW and CCW motors.

No swapped motors:
Yaw demand: 100 pwm
CW motors: 1550, 1550, 1550, 1550, avg 1550
CCW motors: 1450, 1450, 1450, 1450, avg 1450
Difference between avg CW and CCW: 100[/code]

[code]One motor swapped:
Yaw demand: 100pwm
CW motors: 1550, 1550, 1550, 1450, avg 1525
CCW motors: 1450, 1450, 1450, 1550, avg 1475
Difference between avg CW and CCW: 50

So you can see, for a given yaw demand, the result will be half the torque if you swap one motor between the CW group and the CCW group.

[quote=“jschall”]
So you can see, for a given yaw demand, the result will be half the torque if you swap one motor between the CW group and the CCW group.[/quote]
Very interesting, thanks for that explanation.