I am proposing modified swashplate behavior anytime the aircraft is disarmed and then when it is armed prior to the first time the motor runup is complete. This swashplate behavior is for acro, stabilize, and althold flight modes.
Background
Back in June, @Leonardthall started a discussion in the Trad Heli group to talk about attitude controller requirements. The quote below was where I think we landed as a starting point.
Behavior description
ACRO
Unarmed: ghost locked to current attitude and I terms zeroed
Armed, prior to first time rotor runup complete: ghost locked to current attitude and I terms zeroed
Armed, initial rotor runup complete: ghost released and I term released (reverts to current swashplate behavior)
STABILIZE/ALTHOLD:
Unarmed: I terms zeroed
Armed, prior to first time rotor runup complete: I terms zeroed
Armed, initial rotor runup complete:d: I term released (reverts to current swashplate behavior)
Here are the links to my commits on Chris Olson’s fork of ardupilot swash behavior commits
While my proposal is not exactly what Leonard details above, I believe it to be a good start. I think once the rotors are turning, the pilot will immediately see the aircraft response and will not make inputs that will cause harm to the aircraft. This also relies on the integrator leak limit being set appropriately. By not starting the modified behaviors again until after the aircraft is disarmed, it protects the user when conducting autorotations. We can discuss other triggers for the initial reversion back to normal swashplate. It was brought up that the acro trainer mode could be affected so I proposed the reversion happen the first time the motors are started. It was also proposed that it could occur on the takeoff flag with collective greater than H_COL_MID.
So I’m putting this out on the development team forum to get feedback and find a way forward to incorporate changes.
Thanks Bill!
I think your changes are nice and simple, and do fix a real problem with ground testing of helis.
Another approach that we’ve discussed in email is to instead limit the angular difference between the target attitude and the current attitude. For example, that limit could be very small (or even zero?) when disarmed, and could increase smoothly as the runup is happening.
I think we could implement this with a new quaternion function:
void Quaternion::limit_angle_difference(const Quaternion &q, float angle_limit_rad);
where angle_limit_rad would be very low when disarmed, and rise when armed to some limit.
I think I could probably work out how to make that function, otherwise Paul or Leonard could do it quickly I think.
The main advantages I see of the angular limit approach are:
when ground testing the pilot sees the same basic maths happening with their swash as happens in flight (just a smaller angular limit)
it prevents a (possibly theoretical, possibly real) possibility of control inversion in flight in cases of extreme rate demands beyond what the vehicle can achieve
it may prevent control inversion in a case like auto-rotation where control authority is greatly limited
it gives us a way to smoothly go from rotor off to rotor at full speed with no jump in control approach
The same smooth approach could be used on the integrator too - we could limit the integrator between zero with rotor off to the leak-limit when rotor is at full speed, rising linearly during the runup.
Tridge,
Leonard spent a lot of time discussing desired swashplate response during different phases (prearm, armed, landed and armed, flying) in the Trad Heli discussion forum. I realize that I was one of the people voicing my opinion but this was Leonard’s suggested way forward.
As far as limiting the ghost while landed, I don’t agree with this approach for addressing the swashplate behaviors in different phases of flight. I believe that this ghost limit is needed in flight because it doesn’t allow the ghost to run away in situations of uncontrolled flight, whatever the reason, when the pilot is trying to regain control. It keeps the ghost relatively close so when control is regained the ghost can resume tracking the desired attitude.
What I’ve proposed provides a smooth transition. @ChrisOlson has flown these changes and can comment but from what he reported, there were no adverse reactions by the aircraft.
releasing the integrator provides a smooth buildup. I have seen the ramp in of integrator in manned implementations and it works but I don’t see any drawback to what is proposed.
Hi Bill,
If your the preferred approach for you and Chris is the simple one you have done patches for and you are happy with the flight characteristics then we should go ahead with a PR for that. It certainly does have the big advantage that it is simple enough that we can probably get it into a 3.5.x point release, which is a big plus.
We could always look at the quaternion limit separately after that if we decide its worthwhile.
There are a couple of other small patches in the ArduHeli branch from Chris that would be worth bringing in too (eg. accelZ default change). Would you like to cherry-pick those into a PR, or would you like me to do it, or will Chris do it?
Cheers, Tridge
@tridge feel free to cherry-pick what you think might be useful to get into Copter
The only adverse reaction I experienced was taking off before the runup timer was complete. As tridge and I discussed on Mumble, that is an outside case as pilots should not be doing that in the first place. And it is unlikely an inexperienced pilot would be taking off in Acro flight mode.
The only adverse thing that happens taking off before the runup timer is done with its count is that the heli is rate-control only and the ghost is locked at the takeoff attitude. A few seconds later the desired function of the Acro Trainer feature set the pilot has selected “kicks in” when the runup timer expires. Frankly, unless the pilot knows what to look for he/she likely wouldn’t even realize the ghost is momentarily locked. You have to pull the logs and look at them to see it.
So I think the advantages of being able to do normal pre-arm checks, and not getting an inadvertent tip on takeoff because the ghost was moved during pre-flight checks, far outweighs the one adverse effect I found in testing it. And that one effect mentioned above can only happen in a situation where the pilot is pushing the limits of a dangerous takeoff in the first place, without the head at full speed yet.
I did not find any adverse effects, other than mentioned, with Acro Trainer set to 0, 1 or 2. With the stock code the strange swashplate behavior still happens with Acro Trainer set to 1. It is not quite the same because it doesn’t do it in pitch for some reason. But it still does it. With Acro Trainer set to 2 I could not get the ghost to rotate and make the swash snap back and forth. With the patch applied, it’s “fixed” in all cases.
If anyone else wants to test this I have some current builds with all the patches I have been flying and testing on my Google Drive here - select the ArduHeli_3.5.3 firmware for either Pixhawk (-v2) or Pixhawk 2 (-v3): https://drive.google.com/open?id=0B5oLpNzxih4tUGFwc2NCNVB4dFU
Note the firmware will identify itself as ArduHeli V3.5.3 in your ground station so you know you are not flying an official release of Copter 3.5.3.
Chris, thanks for the pointing out that our. I didn’t mean to misrepresent your findings. [quote=“tridge, post:5, topic:22463”]
f your the preferred approach for you and Chris is the simple one you have done patches for and you are happy with the flight characteristics then we should go ahead with a PR for that. It certainly does have the big advantage that it is simple enough that we can probably get it into a 3.5.x point release, which is a big plus.
[/quote]
Tridge, I think I want to look into changing the trigger as I posted above to ensure the ghost is free before takeoff. This should also help with the acro trainer mode. I don’t expect it to take long to find a more appropriate trigger. What is the expected timing for the next release of copter?
Thanks,
Bill
That is really for Randy to say, but I think it would be fine to wait a few days to get the changes done. If you think it will take a week or two then we should probably go with what has already been tested and improve it later.
Thanks very much for your work on this!
Cheers, Tridge
Tridge,
I’m glad I can help out. My going in approach would be to link it to the motor interlock so as to avoid issues with pilots taking off before the timer is up. It should also avoid issues with the acro trainer modes. That’s a pretty easy fix. The ones that require a little more testing would be using takeoff flag or some combination of that with the collective. I’ll collaborate with Chris and anyone else that wants to try it. But the first option won’t take long to test.
Bill, just do a commit to the swash_behavior branch on ArduHeli, I’ll do a build from that branch and test it. If it’s satisfactory I’ll merge it into the ArduHeli-3.0 branch for long-term testing with all the other changes combined.
Chris,
I just changed the trigger to motor interlock and pushed it to my swash_behavior branch.
So once you engage the motors the modified swash behaviors will stop and won’t start again until the aircraft is disarmed. I think this should be suitable and it keeps from causing any issues if the pilot decides to take off before the runup timer is complete.
Thanks in advance for testing this. I will try to look at it tomorrow if time and weather permit.
I flew the swash_behavior branch today and I am satisfied with it finally. Using the motor interlock raised is a much better trigger. Once the rotors are turning there is normal cyclic response as the main rotor starts producing lift, no matter if the pilot takes off early. And it does not matter what ACRO_TRAINER mode is used. Much better than using the runup timer. And swash behavior is normal for pre-flight/pre-arm checks.
I would say you could possibly squash those commits into a PR from your fork, Bill, as I think that one is a “go”.
@tridge we changed our branch structure so our master is our current development branch for ArduHeli. And I submitted a PR for the ACCEL_Z_P change and a minor comment fix I found going thru the code:
@tridge looking at the pull request I submitted, it says that it failed the build checks. I’m not sure why my change to the attitude controller would have failed to build. What do I need to do to fix this and get the pull request moving forward?
Thanks
Bill
@tridge looking at the pull request I submitted, it says that it failed
the build checks. I’m not sure why my change to the attitude controller
would have failed to build. What do I need to do to fix this and get the
pull request moving forward?
Looks like someone retried it. Looks to be passing now.