Unusual swashplate behavior using AC 3.4.5 in ACRO with full cyclic input

Rob you do use a lot of words to say very little.

The amazement is how poor your understanding of control is and how poor your memory is. Just set the ATC_ANG_XXX parameters to 0 and knock yourself out. If you have trouble with drifting attitude just increase the I term. Just be careful because you don’t have any attitude control…

Yeh, heli don’t care about the error limit in roll and pitch. We get it Rob but you go ahead and demonstrate that in 10 more pages of crap.

Not true, it just requires more tuning. A rate only tuning has the advantage of simplicity and it is helpful for tuning the rate loops. The trick is using a much higher I term. I would say that rate-only controllers have the advantage in freestyle but in racing a well tuned rate controller with attitude stabilisation (not leveling) enables the pilot to push harder into the edges of performance.

This is why I was considering reintroducing the Rate only ACRO controller.

I am not but I will do my best to support Randy and Tridge who have been doing a great job cleaning Heli up and bringing it up to speed with the other frames. It is about time it got the attention and support it deserves. We will need a lot of support and feedback from the users (whining complaining and foot stomping isn’t support and feedback).

Yep, me too. And this is something I think we need to address. I just object to using this to justify a bunch of incoherent and time waisting babble.Rob has become the user that motivates Dev’s to ignore problems rather than address them. This is where help from users like yourself makes a big difference. So thanks.

So the idea is to calculate the maximum rate request we can give without saturating the outputs, then the maximum angle error this represents. We would then move the ghost to that angle. The cool thing about this is when you get a large rate like when the tail whips around this will make the ghost sit close to the real aircraft. But then when it slows it will open up again. So I hope you get the best of both worlds. Small bounce back after a whip around, no limit on the resistance to disturbance.

On the pre-arm behavior. Could you go through in detail what inputs you give and exactly what you expect to see. I would also like to hear how you relate these inputs and outputs back to the rate controller. It would also be good to hear your whole take off procedure and each individual stage the heli goes through in your mind.

Thanks

From what I saw on all FBL system I’ve experienced, moving cyclic stick will move the swash proportionally like passthrough. when stick is released, swash gradually returns to level with heli (not ground). If you pick up the heli tilt it them stop, the swash tries to fight then gradually returns to level even if the heli is upside down (not touching transmitter). You can expect a lot of people to expect these behaviours.
Asking this on heli forum (Helifreak?) sounds like a good idea.

I don’t know what the current code is doing. This is my wild guess. Please correct me if I’m wrong.
PID controller in rate mode, the error is the difference in angle (degree) between the ghost and real.
IMO the error must be difference in angular velocity (degree per sec) between real and desired rate. Where Center stick = 0 deg/sec desired rate and Full stick deflection = XXX deg/sec.
And that there is no need for accelerometer at all for rate mode, the controller has no idea where the ground is.

Leonard,
Please keep your thoughts regarding others to yourself. I don’t care to be involved in that part of this discussion. Which by the way I feel both you and Rob are being very unprofessional. Respectfully disagree and leave it at that.

I like this idea. Will the max requested rate be modified by the pilots input? So that the pilot and the request from the controller could not exceed the max available output?

During pre-arm in Acro and stabilize mode,
when the pilot makes a stick input the swashplate should move in the direction of the pilot’s input. With full stick input in any direction no matter how long it is held the swashplate should remain tilted in that direction. Anytime the stick is returned to center, the swashplate should return to level for Acro and in the case of stabilize mode tilted according to the angle of the aircraft as described below. In acro mode, if the pilot tilts the aircraft in any direction the swashplate should respond tilting opposite the direction and proportional to the angular rate at which the pilot tilted the aircraft. So if the aircraft is tilted 30 deg left wind down and there is no angular rate then the swashplate should be level relative to the aircraft. In stabilize mode, when the pilot tilts the aircraft, the swashplate should tilt away from the direction the pilot tilted the aircraft proportional to the angle at which the pilot tilted the aircraft.

I want to retract this statement. In stabilize mode, I think the integrator is causing the issue with the aircraft wanting to excessively tilt on takeoff. I think the atttitude controller is fine. Now in Acro, I think both the integrator and the attitude controller tracking the ghost aircraft while one the ground is an issue.
That’s all I have time for now. I will write about my start up procedures later today.

This is demonstrably false. There’s no point discussing this matter further. Clearly you will just make up Alternative Facts and refuse to answer technical questions that you can’t talk your way out of.

Again, I don’t know the specifics of the code that well. But from a pilot’s standpoint playing with settings, I have pretty much figured out that this is true.

I think the attitude controller seems to work ok for the most part. But I have noticed that the heli seems more “locked in” after it gets flying than it is after takeoff in Stabilize, and then switch to Loiter in hover. If you fly it about a bit in Stabilize before switching to Loiter it seems to be better. So my mode of operation has become to take off in Stabilize, switch to Alt Hold so I only have correct drift in the wind while setting up my payload, then go to Auto, and don’t use Loiter until later after the flight is done. I know this is not an Acro issue pertinent to this thread, but it is something I have noticed for UAV flight.

You are right. Attempting to support heli and sort out the initalisation issues and helis miss-use of the attitude controllers is taking too much time and making me look unprofessional. I will let the other devs do all that and give heli a wide birth for a while.

I have a couple of issues I can sort out when I have time that will benifit all frames. To be quiet frank I dont think i care right now.

All pull requests welcome.

Leonard, I’m sorry to hear that. I thought your idea regarding how the attitude controller would handle tail blowout was a good one and wanted to hear more about it. I have some ideas on how to implement my thoughts on initialization and will submit a pull request when I have a workable solution. Thanks for your time and good technical discussion.

I think the tail blow out solution will work well for heli and a number of other frames. I also intend to add the rate only controller from copter 2.7 days back to enable some core pid development and with a larger I term I think it will work well. So some heli pilots may prefer that. That structure may also facilitate some acro development and I may also add Robs original integration of rate error acro consept in as an example. Some people may even port their favorite cleanflight acro so we can do more back to back comparisons to see what we can learn from them.

The thing to keep on mind is the attitude controller has been set up to be very flexible. There are three different places i could add the tail blow out stuff. Each location has different consequences for the varios aircraft and flight modes. I will have to think about it very carefully and chat to Randy and others before I make a decision.

On the initalisation stuff. Look at copter. We have a start up process that lets us manipulate the controllers throughout the arming, take off, landing, dissarming process. Heli has something similar but may be harder to follow. The tricky bit is understanding under what conditions you can get a change in state command from the main code. Heli has a massive amont of flexibility to define the start up behavior, again the tricky bit is getting to some sort of consensus from the users as to what that should be. Then you need to work out what is possible and try to get some consensus given the practical restrictions and limitations. That is what i was trying to do here. I hope you can do a better job.

Good luck an i look forward to seeing what you come up with.

Thanks for the insight on your plan. It will be interesting to be able to compare the different controllers for acro. [quote=“Leonardthall, post:110, topic:15658”]
The thing to keep on mind is the attitude controller has been set up to be very flexible. There are three different places i could add the tail blow out stuff. Each location has different consequences for the varios aircraft and flight modes. I will have to think about it very carefully and chat to Randy and others before I make a decision.
[/quote]

Like I’ve said before, I’m sure it is very challenging to accommodate all of the various frames. I know that a lot of thought has to go behind making changes especially if you want to maintain the flexibility. [quote=“Leonardthall, post:110, topic:15658”]
On the initalisation stuff. Look at copter. We have a start up process that lets us manipulate the controllers throughout the arming, take off, landing, dissarming process. Heli has something similar but may be harder to follow.
[/quote]
Yes, I’ve been trying to understand the multicopter approach. Is most of this covered in the control_stabilize or control_acro files? I can see the arming/disarming logic in there which uses the set_throttle_out_unstabilize and set_throttle_out methods but I’m not sure I’m seeing the takeoff/landing logic. If I’m missing some key files to look at, I’d appreciate if you could point them out.
Thanks!

Don’t forget to look at all the AP_Motors files as that’s all tied up in there too. Keep in mind that in many cases those objects are polymorphic, and you’ll see that Helicopter has a specific implementation that reacts to the commands differently.

A big part of the difference between the frames and the way they initialize, or don’t, is explained there.

You will see in Heli_Control_Acro that there is method to reset the yaw target before arming. What’s needed is something similar for Roll/Pitch.

great idea! I think that would work well for acro to keep the ghost aircraft from getting away from the real aircraft while on the ground. For now, I think I will use your leaky I to handle the integrator while it is on the ground.
Thank!

Why is the land complete flag cleared in the stabilize_run or acro_run? Isn’t that handled by the landing detector? it seems premature to clear the landing flag just because you are armed for multirotor and armed, runup complete and throttle non zero for heli.

It was the best guess we had that we have taken off. Perhaps something could be done better, maybe check altitude, etc. But that’s what we’ve been doing and it works reasonably well. Always room for improvement though.

I actually had to look this up, as that flag setting isn’t done in the flight mode files in 3.3, it was running in the landing detector. It was moved there for 3.4. I haven’t had time to see who/what/why/when and what the knock-on effects are.

I suspect that the auto throttle/collective modes like Alt-Hold and up are now doing a better job of guestimating when they have taken off, and this check was moved into Acro and Stabilize as nothing new or better had been developed yet.

I looked back at some of my flights with 3.3 and yes it does a good job of determining takeoff/landing. I was running the SITL with AC 3.4 looking at this for air/ground transition behavior and noticed that once the aircraft is armed the land_complete flag is bouncing back and forth continuously until the aircraft takes off. I didn’t see that in my aircraft log with AC 3.3 and I didn’t do many flights with 3.4. I still go back to asking why the flight mode has anything to do with the landing detector. I would be curious to know if this is being seen on actual flights and just not a sim’ism.

Hmmm… that definitely needs looking into.

Also, is it a helicopter only issue, or does it affect multirotors too.

@ChrisOlson I know you have been flying 3.4. Could you make a log from your most recent flight available? I’m curious to see if this behavior with the land_complete flag is occurring.
@Rob_Lefebvre I will use SITL to look at copter and see if it displays the same behavior for a multirotor.

Bill, here is a BIN from a short hover test this morning, flying 3.4
https://drive.google.com/open?id=0B5oLpNzxih4tbWdyOHhQMVI1WkE

@ChrisOlson thanks for the file. It did not show the same behavior. I also looked at the multirotor in the SITL and it also did not show this behavior. I will have to investigate further to see why the SITL showed this for Heli

@Rob_Lefebvre and @rmackay9 I was looking at the code for each of the non-manual flight modes (alt hold, loiter…). Except for the manual modes (stabilize and acro) it appears a state machine approach is used where by takeoff, flying, landing states are identified and a CASE statement is used to address the control for each of these states. Is there a reason this wasn’t followed for the manual modes. I see this in both the multirotor and heli manual flight modes. I would think this would still be applicable to the manual modes if not only to handling air ground transition issues.