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

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.

I don’t have a good answer other than, we never got around to it, because it was less important than the auto-throttle/collective modes.

Heli should have a mini state-machine to handle the resetting of yaw. It is only activated when it’s first armed. Once it makes it out of it, it doesn’t go back.

Hello,

Is the main problem fixed in version 3.4.6? I found this “bug” last year and published it on github but without any answer:

I found this problem during a flight with this machine:

Not so funny in the air :-).

Greetings
Fabian