Board index FlightGear Development Aircraft Autopilot and route manager

Why does this calculation not work

Designing a stable autopilot is one of the hardest things. Need help?

Why does this calculation not work

Postby Octal450 » Sun Jun 14, 2020 2:18 pm

Hi,
In attempt to rework Speed by Pitch control without integrator, (because you have to sometimes chase it in flight director manual flight),I try this physics function which outputs a V/S demand.

Code: Select all
            <expression>
                <div>
                    <product>
                        <property>/instrumentation/airspeed-indicator/true-speed-kt</property>
                        <value>101.26859142607174</value> <!-- FPM to Knot -->
                        <dif>
                            <product>
                                <property>/fdm/jsbsim/forces/fbx-prop-lbs</property>
                                <cos>
                                    <property>/fdm/jsbsim/aero/alpha-rad</property>
                                </cos>
                            </product>
                            <product>
                                <property>/fdm/jsbsim/forces/fwx-aero-lbs</property>
                                <sum>
                                    <value>1</value>
                                    <product>
                                        <property>/it-autoflight/internal/kts-error</property>
                                        <value>0.1</value>
                                    </product>
                                </sum>
                            </product>
                        </dif>
                    </product>
                    <property>/fdm/jsbsim/inertia/weight-lbs</property>
                </div>
            </expression>


It works good, but there is a problem. In Climb, it is a few knots to slow, and in Descent, its a few knots to fast. (1-3). This error is worst at high True Airspeed, and least at low True Airspeed. My question is , why that is? Perhaps is it because aero drag is multiply by qbar and this is using true speed?

I already tried:
- Using /fdm/jsbsim/velocities/vtrue-kts for true speed instead of ASI
- Accounting for V/S refernece errors (/velocities/vertical-speed-fps doesn't agree with VSI in GPS that i use, or VSI instrument), and this produced a delta of about -73fpm, which had absolutely no affect on this issue
- Bad number for FPM to Knot - The factor can be adjusted by 20 in either direction and the difference in speed is only a few knots. So its not that, and in fact trying to fix it with that, or the sum of 1 lower down results in fine behavior at that speed, but then if you switch from climb to descent, or vice versa, or change your airspeed target the number is wrong again.
- V/S control system is too slow - nope, its not that. My V/S control system is accurate within 15fpm most of the time. I tested this out on Soitanen's 737 to see if my implementation was at fault, and the problem is actually worse on his than mine by 1-2 kts, which I tracked down to his V/S control system being less accurate/fast than mine.
- Another point of proof that it is NOT the V/S reference or airspeed is because the polarity switches. If those were at fault, it would always be slightly high or slightly low. But the polarity of the error changes when the polarity of the commanded V/S does (in descent, its too fast, in climb its too slow).

I have heard from real pilots that the speed on pitch is bang on in calm weather, and if you set 250, you will get 250 on the indicators, so this is not acceptable for me. In addition, I question Soitanen's correctness about using this anyways, as I know for a fact the real plane does not know the exact number of DRAG and THRUST (fwx) that is has. That would be impossible. So if anyone has another idea on how to implement speed on pitch without an integrator, that would be nice to hear. Otherwise I may end up reverting to an integrator system and just making it enough that hopefully manual following FD problems are as minimal as possible.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), A320-family, Secret (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4635
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 10 x64

Re: Why does this calculation not work

Postby GinGin » Sun Jun 14, 2020 5:10 pm

Hey Josh , I don’t know exactly for the 320 .
But on 737, when you are in level flight , and you go level change aka open climb, speed is never at 1 kt close when thrust transitions from 60 pour-cent do full climb thrust and pitch goes from level flight ( 2/3 degrees to 7 to 10 degrees ).
It takes like minimum 10 seconds ish to settle down to correct speed and pitch .

What are the max speed exceedance you observe and how long it takes to settle down to correct climb / pitch values ?
GinGin
 
Posts: 1028
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: Why does this calculation not work

Postby Octal450 » Sun Jun 14, 2020 6:16 pm

Hi GinGin,
That's not what I'm talking about, at all. I am aware that its not perfectly center. I mean you can wait for 5 minutes if you want, this calculation is giving 1-2kts off. Did you not read what I wrote?
Obviously the A/P cannot perfectly do it as the throttle, it will move. But the important part is that it does actually settle to the correct amount which it does not in Soitanen's 737-800 nor my implementation using this same physics equation.

https://prnt.sc/szlyzt

Here you can see its stabilized at 248, not 250. Why?
But this calculation is definitely not possible IRL. The plane DOES NOT know his drag and thrust so perfectly. So I don't even think its a good solution.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), A320-family, Secret (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4635
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 10 x64

Re: Why does this calculation not work

Postby danielHL » Sun Jun 14, 2020 6:41 pm

One stupid question (I don't know the plane, the behavior, or your implementation): why do you need to calculate it from parameters that aren't available IRL? Is it still part of a feedback control loop? This is exactly their purpose and a well designed control loop should have no problem getting the deviation to zero...
danielHL / GVA0387 / D-FMPW / (UA83DAN)
danielHL
 
Posts: 140
Joined: Fri May 02, 2014 6:23 pm
Callsign: UA83DAN, GVA0387
Version: git
OS: Linux

Re: Why does this calculation not work

Postby Octal450 » Sun Jun 14, 2020 6:49 pm

@DanielHL
Well I scrap the calculation anyways. Unrealistic. Looks like my original conclusion in 2017 still stands.

And no, there is no feedback. Same with soitanens. I was suggested years ago to use this calculation instead of my feedback loop but I decided against. Finally after wanting to resolve minor issues to make it behavior right, I realized I might as well take a crack at removing the FD chase problem. I will explain what I mean.

The problem here is that in order to work with feedback, I need integrator. However, integrator makes the flight director terrible to follow (trust me, any single plane in FG where Integrators drive anything on the flight directors, you have to chase them. Its horrid) so I was trying to abolish integrator. But it looks like that is not possible, so I'll simply need to design a control loop that is the least "chasey" behavior on the FD.

My previous loop wasn't that bad to follow, but sometimes it did need to be chased slightly as any integrator needs. So I will have to figure out another solution.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), A320-family, Secret (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4635
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 10 x64

Re: Why does this calculation not work

Postby Thorsten » Mon Jun 15, 2020 9:53 am

I believe you may be discarding an integrator needlessly. It's a tried and tested way to remove small residual errors and it can be as invasive as you need it.

For instance, you can use a trigger to only let the integrator work if the remaining error is sufficiently small so that it never tries to handle large errors and leaves those to the PD part, and you can of course change the coefficient to make it act fast or slow dependent on how fast your feedback loop reacts.

It would seem easier to me to use feedback rather than to try a closed computation which is likely to be inaccurate at some level anyway.
Thorsten
 
Posts: 11620
Joined: Mon Nov 02, 2009 8:33 am

Re: Why does this calculation not work

Postby Octal450 » Mon Jun 15, 2020 2:26 pm

Hi,
But that's not what happens in the real plane. The real plane gives you the FD bar on the PFD, which perfectly guides you. The AP simply follow the bar. If it's integrating, you will always have a bit of chasing goin on unless I do some magic. We'll see.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), A320-family, Secret (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4635
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 10 x64

Re: Why does this calculation not work

Postby danielHL » Mon Jun 15, 2020 5:44 pm

And this is exactly why control theory is one f*ing hard science. All approximations that we in flightgear do - I guess your very excellent IT-Autoflight can be included - is just four separate control channels that boil down to more or less PID. Multi-dimensional control-theory where all 4 axes (pitch, roll, yaw and thrust) are connected with each other is extremely hard. And one problem for the chasing might well be the interference between the "pitch for VS" and the "constant throttle" controller. If they are separate there's bound to be small overshoots and/or oscillations.
danielHL / GVA0387 / D-FMPW / (UA83DAN)
danielHL
 
Posts: 140
Joined: Fri May 02, 2014 6:23 pm
Callsign: UA83DAN, GVA0387
Version: git
OS: Linux

Re: Why does this calculation not work

Postby Octal450 » Mon Jun 15, 2020 6:04 pm

Hi,
Well this is really just a problem with speed by pitch. Everywhere else I solved it already.

The pitch for V/S controller is not used for FlightDirector.

No, its not that, on Autopilot its 100% stable. let me example you.

If I am at 150kts, and the target is 160kts. Then the flight direction command bar goes down. I limit the delta VS to 2500fpm. So it will probably command -2500fpm from current FPM to accelerate. Now lets see I really rapidly accelerate and the I'm at 160kts. But I did super fast without following the bar, now the error is near 0, and thus little to no integration occurs, and the bar is wrongly commanding maybe -1000fpm from current FPM. Now the only way to center the bar, is if I chase the bar down, then it'll go back up.

Point being - if you follow the bar precisely, like the Autopilot would, it acts great. Otherwise, it goes in a weird place. That is due to the nature of integrators.

So I will design a new control loop for it using rate based control because using this technique I got great control in pitch and roll.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), A320-family, Secret (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4635
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 10 x64

Re: Why does this calculation not work

Postby Thorsten » Mon Jun 15, 2020 6:15 pm

But that's not what happens in the real plane. The real plane gives you the FD bar on the PFD, which perfectly guides you.


Let's say I doubt that an open loop system achieves anything 'perfectly' in real life by correctly pre-computing all you need. Reality tends to be messier than that.

Point being - if you follow the bar precisely, like the Autopilot would, it acts great. Otherwise, it goes in a weird place. That is due to the nature of integrators.


That's my point - it doesn't have to be, because you can switch the integrator off via a trigger if you're not following it precisely, so it never goes to a weird place.
Thorsten
 
Posts: 11620
Joined: Mon Nov 02, 2009 8:33 am

Re: Why does this calculation not work

Postby Octal450 » Mon Jun 15, 2020 6:26 pm

Thorsten wrote in Mon Jun 15, 2020 6:15 pm:Let's say I doubt that an open loop system achieves anything 'perfectly' in real life by correctly pre-computing all you need. Reality tends to be messier than that.

Yep, that's why I don't like that equation.

Thorsten wrote in Mon Jun 15, 2020 6:15 pm:That's my point - it doesn't have to be, because you can switch the integrator off via a trigger if you're not following it precisely, so it never goes to a weird place.

Then it doesn't work because the VS demand will be 0 when the error is 0. So that's why I'm looking at designing new control system rate based solutions as 0 rate with 0 error is ok.

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), A320-family, Secret (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4635
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 10 x64

Re: Why does this calculation not work

Postby Thorsten » Tue Jun 16, 2020 6:14 am

Well - yes.

I believe the key idea is to have a system that produces small errors without an integrator and then use the integrator only to zero these small residual errors. I completely agree that having the integrator run into large values or to use the integrator as the main control structure is an exceedingly bad idea.

But your pre-computation augmented by an integrator might work rather well. If you have 1-2 kt error and switch the integrator on when the error < 2.5 kt, it won't probably do much in manual mode unless you're already very close, then it'll null the rest.
Thorsten
 
Posts: 11620
Joined: Mon Nov 02, 2009 8:33 am

Re: Why does this calculation not work

Postby Octal450 » Tue Jun 16, 2020 6:06 pm

Yes, I am playing around with those 2 as possible solutions as an option as well.

Thanks for all the inputs, guys!

Kind Regards,
Josh
What I do: Flight Dynamics, Systems, Canvas Displays, Autoflight, FlyByWire, Cockpit Animations
Aircraft I currently develop: MD-11 (Mainly), A320-family, Secret (Quality over Quantity)

My GitHub|MD-11 and ITAF Dev Discord|Airbus Dev Discord
User avatar
Octal450
 
Posts: 4635
Joined: Tue Oct 06, 2015 12:51 pm
Callsign: WTF411/Octal
Version: next
OS: Windows 10 x64

Re: Why does this calculation not work

Postby portreekid » Fri Jun 26, 2020 5:35 am

Thorsten wrote in Tue Jun 16, 2020 6:14 am:I believe the key idea is to have a system that produces small errors without an integrator and then use the integrator only to zero these small residual errors. I completely agree that having the integrator run into large values or to use the integrator as the main control structure is an exceedingly bad idea.


Thanks for bringing back the memories of hours of control technology (Regeltechnik). It would have been more exciting to have learned it on the example of a Flightgear Autopilot than on some paper ;-) Bit like these competitions in bridge building.
portreekid
 
Posts: 426
Joined: Tue Jan 14, 2014 3:36 pm
Location: Dresden
Version: 3.0
OS: Windows 7


Return to Autopilot and route manager

Who is online

Users browsing this forum: No registered users and 1 guest