Not sure if I have an issue or not but thought it might be smart to check before flying. Finally getting around to installing Pixhawk 2 with 3.5.3 In stabilize throttle appears too aggressive under 50%. With Alt Hold and Pos Hold I get no response until throttle goes above 50%. Only difference in copter is the Pixhawk 2 with this firmware (had Pix 1 with 3.3.3 prior). Using all the same parameters with exception of changing mot_spin_arm and mot_spin_min to the new values. Hoping Arducopter didn’t go the DJI path - maybe I simply screwed up some parameter value?
What you do mean you get no response until above 50% in alt hold and pos hold? That’s how those modes have always worked. Center stick holds altitude. Above middle climbs, Below middle descends.
Regarding throttle output in stabilize, set parameter HOVER_LEARN for 2 (learn and save). I will automatically set the appropriate hover throttle value. And the throttle scaling across the entire range will then be much better.
Did you recal the radio, end points when you swapped the new fc in. Or is this a new just similar build?
Sorry, I did not mean inflight but on ground - take off. Pretty sure I remember having more authority over throttle upon taking off - not only in stabilize but auto modes as well. Maybe my brain has turned to mud?
I have the same behavior as @jamescooper1
My MOT_SPIN_ARM is 0.0 and MOT_SPIN_MIN is 0.15
So I have my copter disabled on the ground and want to take off in AltHold mode. Here are my steps:
- Throttle to minimum, switch to AltHold
- Push safety button and arm (no motor spin becasue of MOT_SPIN_ARM is zero)
- Increase throttle stick smoothly: 10%…20%…40% - Nothing… Motors are not starts.
- After throttle above 50% - motors starts and copter takes off.
I mean it looks weird that motors not spinning at MOT_SPIN_MIN value right after throttle stick above minimum value.
And what happens if you lower the throttle below 50% in flight? Do the motors stop again? If you have the motor parameters correct, then that sounds like an ESC calibration issue.
@Pedals2Paddles no, in flight everything works correct, even at zero throttle stick copter just descends with predefined velocity.
This is the case is only on take-off.
It is everytime a little bit scary I would say: you increases your throttle and nothing happens. And you think - what is wrong? did I forget to arm? Or is something broken?
Hello, and relax
in my opinion its a common behavior because in the AltHold middle stick means no climb. Below middle position alt decrease.
Try the same in stab mode
greetings
As Roland says, I believe this behavior is intended. In altitude-controlled modes (e.g., alt hold, loiter, pos hold, etc.), the throttle stick commands a climb rate, rather than a throttle or power setting. When you’re on the ground, a stick below the half-stick deadzone will keep the motors at MOT_SPIN_ARM until you raise the stick above the deadzone, where the FC will then attempt to match the commanded climb rate by increasing throttle.
If you want the motors to spin while armed on the ground, set MOT_SPIN_ARM to > 0. MOT_SPIN_MIN is used as a minimum motor throttle when the copter is in flight and shouldn’t come into play when you’re on the ground. If you want the motors to respond to the throttle stick below the deadzone while landed, I think you will need to use a non altitude-controlled mode.
I honestly don’t recall if this is the same behavior as Copter 3.3, so it might be different than what you’re used to.
Thanks, Rick. I believe you are correct. I am not concerned about the throttle while airborne, but have always liked the “spool up” no matter what mode I am in upon takeoff. With this new release, I think that has been eliminated and only available on stabilize mode. All I was looking for on the post was confirmation that 3.5 has this throttle behavior built in (dead zone) unlike 3.3 - wanted to be sure it wasn’t a parameter set improperly during setup.
There is still a spool up but only through the dead zone rather than from minimum to top of the dead zone.
This was done to give better feedback from to the user that they are in the dead zone and the aircraft is about to take off. There was also a safety issue we needed to address too if I remember correctly.
Thanks, Leonard. That clarifies the behavior.