Autotune:0...Ground:2

3689567378?profile=originalMy first official foray into 3.1 has not gone well, and so far, Gravity - and his mistress, the hard frozen ground - are winning 2:Nil.

Both bird were flying fine on 3.0.1. There have been no physical changes. The Disco even flew ok on 3.1, pre-autotune, although I still can't seem to find the source of the vibes.

The Disco started autotune no problem, and you could physically see roll getting tighter and tighter. Pitched started, and that looked good too. I was getting excited. Right up the moment it totally flipped out of control, Belly bounced off the tarmac, and proceeded to freak out some more and self-destructing. Logs are attached, and apart from less than satisfactory vibes, no idea why it freaked out. All physical connections were tight even after the crash, and there were no loose screws or bolts. The new 3.1 engine readings look weird btw...something in there, maybe?2014-01-12%2008-25.log2014-01-12%2008-25.log.gpx

3689567595?profile=original

So I moved onto the quad, which was even more bizzare. It tried to do a fly away the moment I flicked autotune. So I flicked out, but it now went into failsafe RTL. Broke RTL into loiter, and it freaked out again. Realising this was not a route to safe flight, I went back to stabilise, and discovered I had lost all yaw control. Then I made a mistake - instead of just putting it straight down in stablise, I flicked manual RTL, and boom - all motors stop. Stabilise again, but I was too late. Wish I had the logs for that one, but I think the logs are corrupted - it fails at the same point very shortly after starting the download. As mentioned - It was running sweet in 3.0.1...Compassmot: 0%, Vibes well within +/-5, etc. Only thing changed was the upgrade to 3.1.

2 freakouts in Autotuine on 2 aircraft in the same morning session. Both were flying well previously. Methinks I'll stick to the manual PID method, until my confidence is restored...

Amazingly, both are now phyisically repaired already. Disco ready to fly, and I'm doing a ground up, factory-fresh install on the Quad. The fog has come though, so visibility down to 20m. I had a lot of flight activity planned, but it ended up being a frustrating - and short - weekend's flying :-(

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Developer

    Hi Euan, i'm sorry for your double crash!
    Read here: this is what I wrote a few days ago, follow the "drone-discuss" list, you can save your quad... ;-)


    Cheers, Marco

  • One interesting possibility is if the acceleration limiter that I'm working on would prevent the problem. If the problem is that at the moment of switching for AT to Stab, the Stab controllers gives a massive spike on the output, then if we implement the acceleration limit such that it softens this, it would help.

    Still, seems like it's only avoid the problem rather than solving it.  

  • Are t-motor 2216-11's still considered pancake motors? That's what was attached to these RCtimer ESC's.

    I run some MN3508-29's (which I definitely consider to be "pancake") on the quad, but I've never opted for simonk on these, for exactly the reasons you state.

  • @Crashpilot, so why don't you just go buy DJI then?

    At least Euan got his parts back, that doesn't happen when the Naza fails. ;)

    Euan: interesting observation about those connectors.  I had once hacked some ESC's I had, soldered barrel plugs right to the board as DJI does.  But I quickly realized that this is a foolish thing to do.  Any stress on the leads results in horrible loading on the solder pads of the ESC, and they are quite likely to break off if they're a cold solder, or tear off the solder pads if they're soldered well.

    I have a digital servo tester which allows me to make step-function changes to the output, this would probably be a good way to test it.

    My pet theory on what causes the loss of sync on the SimonK with pancake motors, is that the SimonK will instantly apply a load to the motor, and it causes the motor to accelerate faster than the timing system can measure.

    Now, if we can just get some purpose built, quadcopter ESCs with better and easier management of timing to better mate them with motor and prop combos.  (3DR do you have anything in the works??)

    Well, why not just use standard ESC's?  They do work just fine.  My H8 used the Quattro ESC's with standard firmware, and it was very very stable.  

  • Developer

    yeh, I am sure the repeated tests done by autotune combined with the higher stab gains work the ESC's quiet hard and is directly responsible for taking them over the edge.

    It is surprising though because the two tests autotune does two tests. It asks for 20 degrees per second rate and then it asks for a step change in angle of 20 degrees. So the tests are pretty small and reasonable. So all I can conclude is that autotune is hitting a sweet spot of bad. I also don't see the problem early in Autotune so I suspect that heat is building up  or some other thing getting gradually worse each test and the esc doesn't have time to recover.

    It would be nice to find a way to avoid this problem but I can't see how this is possible as the tests are already very conservative.

  • So short version: my RCtimers are probably not the required quality level needed for AT, and I have retired them to the parts bin for use in a future project.
  • Wow, go to bed and it all kicks off! :-)

    Re: ESC's - I think my stats speak for themselves - all rigs with tmotor/multistar ESCs': 0 ESC-related failures. RCTimer failures:3*. One just magic smoked, one's middle motor connector "desoldered" itself, and now we have this glitchy one in AT.

    *I did some bench tests on the "front left" ESC using a spare motor - absolutely no glitching, but how to replicate AT on the bench? Lots of snap loads? This is what I did.

    I also always over spec my ESC's by at least 10A (if motor/prop combo peaks at 20A, I use 30A), I use OPTO's where possible and they all ran factory settings (apart from setting the throttle limits).
  • Developer
    Crash you have absolutely no idea what you are talking about!


    Phillip, I completely agree with your Simon k statments but was broadly putting that into not matching the Esc to motor category.
    As for the only in autotune statment I agree with that to but every single event I have seen in auto tune happens immediately after the test in the stabilise phase, using the stabilise controllers.

    I am replying on my phone so this reply is a quickie.
  • Yeah piecing bits together is also frustrating. The total time of manual tune vs Autotune+crash+repair+wait on parts makes manual tune a breeze. Lets face it: A feature that crashes a copter with ease that is better build than average Joes' copter and stucks yaw axis is simply trash by any standards - no way to sweettalk out of that. If that is a most tested  "quality feature" then goodnight Arcucopter team your "rival" Dji is already having a party on your autotune - I guess.

This reply was deleted.