Problem Need help adjusting a PID

[icedown]

I'm working on an autopilot for the G42-200. I've got quite a bit of it done, but I've been working on one part for several days and just can't get it to work right.

Here is the way it is supposed to work.
Start from basic KSC15 scenario, fire it up and push full power - AB.
At 105m/s it will pitch the nose up to 9deg and hold it there until 50m high.
At 10m it will retract the gear.

At 50m it switches to maintain a 3deg climb(pitch - AoA = 3deg). It holds this until it reaches 200m/s.

Once it reaches 200m/s it pitches up to maintain 200m/s + 10m/s/1km. It holds this until it reaches mach 0.75.

It holds mach 0.75 until it reaches 10km then switches to follow the equation I put in the calculationMFD for acceleration through mach 1 and up to T3.

This is where I'm having the problem. I can't seem to get the PID settings right to hold climb correctly. I'm looking to see if someone can help me get these settings right.

Once you open the MFD up it shows the settings for the altitude phase of the flight. You can change these using the 3 buttons on the right side (Kp, Ki, Kd). None of the other work, and changes do not take affect until you reach the altitude phase of the ascent. At the bottom of the MFD you can see the altitude that is has calculated to be at for the given speed once you reach the altitude phase. The error given to the pid controller is required altitude - present altitude, adjusted for 1 sec in the future.

Here is the dll.
G42AutoAscentMFD

There are a couple bugs in it. You can reload a current state but for some reason it crashes when restarting from the KSC15 scenario.

Also, tell me what you think of the ascent profile. This is the one that uses the least fuel that I've tried so far but I've mainly been trying to line out the altitude phase and haven't tried to many different ascents.

 

[icedown]

Ok, After much :beathead: and almost a :compbash: I figured out my problem. My look ahead calculations were fluctuating way to much at the step speed. I eliminated those and everything flies nicely now. It can now calculate and fly a launch heading based on inclination and altitude or target.

In the process of tracking down the bug with restarting the scenario I realized how the MFD create/destroy actually worked and completely rewrote my code to handle multiple vessels. I have everything working good now up to T3. But I still have one slight problem. If I compile in debug mode, I have no issues. When I compile in release, though, I get a access violation reading location. It points to stack location in G422.dll. It happens as soon as I try to open my MFD. Any idea what might be causing it?

Also, any suggestions as to how to fly the last part of the ascent, from T3 to orbit? How can I find the most fuel efficient climb for this part of the flight?

 

[Moach]

whoa - how did i ever miss this thread? :blink:

maybe it was because i was outta town for most of the last two weeks :hmm:



anyways - this is great - i'm gonna try it out first thing once i get home -- if anything, we could work this out cooperatively and have it installed as part of the actual ship, if that's ok with you, of course :thumbup:


i gather i have to expedite the release of WIP-4... even if short of some more obvious features i hoped to have included, there are a number of flight performance tweaks that would have efforts like this seriously hampered if kept under wraps


so i think i'll have it updated, so at least things of this nature can be developed with the proper flight dynamics - and save us a ton of headache up ahead

 

[icedown]

Here is an updated version. The config screen is still all that works right in the interface so far. It's still compiled in debug due to I haven't figured out what is causing the CTD in release upon opening. T3+ still isn't set up yet either. Here is the sequence I use to get to T3. This will be part of the notifications later.

Startup:
Open G42AAMFD and set target, invert heading as needed for southern departure. Hit exec to save values, exec again to start autopilot.
Fire up the turbines and got to full throttle, no AB required.

Climbout:
At 105m/s it will begin to pitch up, once positive climb is established retract gear. I usually close the visor here as well. It will turn to heading and began to climb.

Mach 0.80:
Retract canard

Mach 0.85:
Engage full AB.

Mach 1.55:
Disable AB
open ramcaster door
start fuel pump
open ramcaster throttle to 60%.

Mach 1.75:
Engage Ramcaster
shutdown turbines
increase ramcaster throttle to 100%
switch turbines to internal.


Mach 3.5:
Switch wings to HPC

Mach 4.5
Switch Ramcaster mode to High

Mach 14:
Enable RCS
start oxygen feed to turbines
Open primary throttle to 25%

Mach 15.5:
Engage turbine start
Once turbines are running, shutdown and close ramcaster.
full throttle
shutdown autopilot
Manual flight for orbital insertion.

This has been putting me about 2.5deg offplane for the iss from the launch to ISS scenario.

Any feedback is appreciated.

http://www.icedown.net/G42-AutoAscentMFD.dll

 

[RaR76]

Great idea! Now if I can get something to switch all the switches in the G42 I can take a snooze on ascent! :lol:

About the PID: I'm not sure where you stand with the PID issue. I noticed from your calcmfd script that you were just using one PID.

I've read somewhere on here (can't remember where, think Wishbone wrote it) that it's generally good to have a PID for simple tasks like pitch, then another PID to modify the setvalue for pitch. I also read the more complex PIDs should adjust the output value less often to allow for the simpler PIDs to reduce error. For calcmfd, someone would have to do something fancy with math (mod(sim_time) or something) to implement the timing.

About the stack error: here's my release command lines:

C/C++
/I"..\..\include" /Zi /nologo /W3 /WX- /Ox /Ob2 /Oi /Ot /Oy- /D "WIN32" /D "_WINDOWS" /D "_VC80_UPGRADE=0x0600" /D "_WINDLL" /D "_MBCS" /GF /Gm- /EHsc /MT /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Fp".\Release/MFDTemplate.pch" /Fa".\Release/" /Fo".\Release/" /Fd".\Release/" /Gd /analyze- /errorReport:queue 

linker:
/OUT:"..\..\..\Modules\Plugin/CalculationMFD.dll" /INCREMENTAL /NOLOGO /DLL "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" "dinput8.lib" "dxguid.lib" "winmm.lib" "comctl32.lib" /NODEFAULTLIB:"msvcirt.lib" /NODEFAULTLIB:"msvcrt.lib" /MANIFEST /ManifestFile:"CalculationMFD.dll.intermediate.manifest" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /PDB:".\Release/MFDTemplate.pdb" /PGD:"D:\Games\Orbiter2010\Orbitersdk\samples\CalculationMFD\CalculationMFD.pgd" /TLBID:1 /DYNAMICBASE:NO /IMPLIB:".\Release/MFDTemplate.lib" /MACHINE:X86 /ERRORREPORT:QUEUE

You wouldn't need "dinput8.lib" "dxguid.lib" "winmm.lib" as that's for direct input. I'm actually wondering why winspool.lib is there - isn't that for printing? lol

 

[icedown]

I have my PID problem lined out. In the calcmfd I used a predictive setup to help the PID be ahead of changes. When I worked it into my dll though, the steps come so fast that doing predictive calculations on a step by step basis caused way to much fluctuation in the error. I found though, due to the small step, the look ahead was not needed due to it was able to react fast enough with out it.

And on the error, what would cause a ctd to happen in release but not in debug?

 

[RaR76]

I'm guessing something different in your debug build vs your release build - other than debug info. Perhaps optimization is causing problems?

 

[eddievhfan1984]

Personally, I find that the AoA that gets you maximum lift-to-drag ratio is the most efficient climb profile. If you wanna do the whole 250 KIAS below 10 000 feet (130 m/s below 3050 m) limit, then there's that, but max L/D also keeps you in the safe flight regime for the ramcaster. AoA for that is about 3.6°, and you want to keep that constant, even during transonic and such.