Thanks very much for sharing your thoughts Shawn. I’m a little bit shy of auto-tune after this first attempt, but at least I am now aware to take a much closer look at the solution and my knowledge of the parameters is developing!
Yep there is a thicker-than-I’d-like USB cable hanging out the side of the Pixhawk in Y. I’m impressed you spotted that Some of the other cables might be tugging on it too. I’ll see if I can improve that.
I’ll also do some tests on the CG and motors 5 and 6. The copter is almost in it’s final configuration now so it’s worth paying finer attention to the balance.
Thanks folks. I enabled FF and most of the parameter changes Shawn suggested (I haven’t altered ATC_THR_MIX_MAN or the ACCZ parameters yet) and had a good flight. This copter has been an effort, first starting with PX4 when I first got the Pixhawk, switching to Ardupilot, discovering the motors + battery were inadequate, bigger props, smaller props, new motors and battery, bad autotune params… with many rebuilds along the way.
It’s an all 3D printed hexacopter, mostly of my design, with Z-offset overlapping 14" props.
It’s been fun and I’ve been learning lots. I’m looking forward to some further tweaks of the attitude control and developing some flight confidence in it.
This will be the the cause of some of the vibration. FFT of this hovering pre-filter would be interesting, I see you have the dynamic notch filter configured.
I did some work on a very large quad (30") with overlapping props and while vibration was an issue it was manageable. But they were turning relatively slow…
So I fixed up the balance and got the vibration to a workable level (still waiting on new props) and ran an autotune on all three axes. I switched autotune off then back on to test the new parameters and it flew very nicely.
However that’s also what happened last time, but then when I next tried to take off it crashed, we presume because of the extremely low gains that were found by autotune (convolved with a not yet resolved mystery about why it works okay during the pilot test but not after a restart).
Well it has once again determined similarly low gains. Any thoughts on this autotune solution before I either fly it or ditch it? Thanks!
For what it’s worth - I had done this earlier last month and switching in and out of autotune didn’t test the new PIDs. New PIDs were only used after I landed and launched again.
Yea, don’t bother trying this. When Auto Tune completes make no mode changes, land and disarm. If you don’t like the Auto Tuned parameters on the next flight reset them to where they were before Auto Tune and proceed from there.
The immediate issue was that the battery discharge doesn’t live up to the promises made by the specification and the voltage drop under high throttle was causing quite evident problems. Thankfully there was a large margin of excess lift and I was able to scale back the maximum spin (noting it hovers at 0.17).
It won’t fly without limiting the throttle to something that the battery can deliver. But even with this limit in place there should be ample headroom - it hovers at 31% of this throttle limit.
But yes maybe something, somewhere isn’t correctly dealing with one of my settings, like this or the reduced aggression or something. I’ve spent the evening looking through the autotune… I haven’t found the answer yet but at the moment I wouldn’t think it is the spin_max - the motor code abstracts that limit away.
// converts desired thrust to linearized actuator output in a range of 0~1
float AP_MotorsMulticopter::thrust_to_actuator(float thrust_in)
{
thrust_in = constrain_float(thrust_in, 0.0f, 1.0f);
return _spin_min + (_spin_max - _spin_min) * apply_thrust_curve_and_volt_scaling(thrust_in);
}
Nothing unique about that. I have a few quads that have high thrust to weight. One has a MOT_THST_HOVER value of .125. My daily flyer/test mule 13" is at .195 when it’s unloaded with the smaller 6S battery.
Yep - sorry I wasn’t claiming it was somehow special, just that there is still plenty of lift margin even with the MOT_SPIN_MAX=0.55.
As you pointed out on a different thread, the previous incarnation of this copter with different props, motors and battery had a 0.72 hover!
OK. But this parameter is to set the top of the motor/esc range above where it produces no additional thrust. So I’m not sure what’s happening with other parameters. Linearization for example (MOT_THST_EXPO). Just conjecture but that large quad with the overlapping prop application I mentioned above; the guy was trying that because he had that thing on his back as boost power for para sailing. I think it caused problems with Auto Tune and he set it back to default. Or higher than he had it anyway, don’t recall exactly.
It’s a bit odd, without this limit in place, the effects of the battery discharge limit are quite dramatic even with the instantaneous ebbs and flows of dynamic control when launching/hovering, otherwise MOT_BAT_CURR_MAX would be an obvious route. However that prevents sustained discharge beyond a limit, over ~5 seconds, so it won’t do what I need.
Actually looking at the code the, AP_MotorsMulticopter::get_current_limit_max_throttle will clip the requested throttle to ensure the voltage will not drop below MOT_BAT_VOLT_MIN, based on an estimate of the battery internal resistance. I do already have that set (19.8V) but it’s potentially another path to explore.
Edit: Actually this also uses the time constant, but I didn’t realise the code worked to keep the voltage>the minimum in addition to complying with the specified current limit. Nice!
Some of the other cables might be tugging on it too. I’ll see if I can improve that.