Project Launch MFD development thread

[C3PO]

C3PO: Is it that the fundamental difference between scripted and and closed loop AP is that the scripted one sets some pitch at some altitude, and that closed loop is actually the "Play" AP ?

Closed loop just means that the controller gets feedback on the result of its output.

PID is a form of closed loop, and PEG is another. IIRC PIDmfd is a controller that compensates for the different inertia/RCSthrust in different craft.

By scripted AP I mean that the user can make a script or plan how the AP behaves. A script can include a closed loop function. The original PEG is scripted even if you can't save/edit the values. You have to set values for the initial launch, the 1'st stage and when the actual PEG algorithm becomes active. I only wish that you had more control over the first part of the ascent using PEGmfd.
REDSHIFT is a great scripted AP with both open and closed loop elements.

 

[Enjo]

BETA release

We've decided to prepare a release, because fully integrating PEG will take Agentgonzo some more time.

I need to prepare docs for a release, and while this is happening, you can give me some feedback about the newest changes, in particular, about their ergonomics - what you think could be done better, even if it means a redesign.

Here's the BETA:
http://www.elwico.pl/~ender-sz/orbiter-pdf/pliki/LaunchMFD-v.1.2-BETA.zip

The newest changes are:
1) New target input box (includes TransX semi-integration)
2) New altitude input box for PEG which itself isn't integrated yet. This is NOT the old Reference Alt.
3) Compass with different views (by Agentgonzo)
Minor:
4) Inclination change by buttons upgraded.
5) Reference Alt removed from user's interface and is fully automatic
6) Code restructuring (joint effort)


Ad 1) New target input box

It looks like this:



you can enter for example:
ISS
- as usual
51.57
- in equatorial frame, as this is the frame that is used for LEO satellites in programs/web pages that I know
64.54 250
- in ecliptic frame, as this is the frame that TransX uses. It's the frame used for interplanetary travels.
The values that you enter here usually come from TransX. I'll refer to this image again:



This TransX view is displayed after setting an Ejection plan and picking a target, and then setting up the transfer (velocities and date, etc.). After doing that, you must return to the first stage.

In this case, you would enter:
101.3 91.2
The proper incl. & LAN values are displayed by TransX after correctly adjusting the Ej. Orientation. The gray line must be placed so that it is some length before your position, when your apoapsis touches the surface of the planet in this projection. You will need to accelerate time to find out when the apoapsis is in place. The redundant distance between your position and the gray line defines your radial distance to the target orbit, thus the Launch Window Time. You know what to do with this time, don't you ? Refer to Launch MFD docs if not.


ad 2) New altitude input box for PEG which itself isn't integrated yet. This is NOT the old Reference Alt.



This is not used for now, but it would be good if somebody tested it. It is the target altitude for PEG algorithm. When you set a target in the previous input box, both the PeA and ApA are automatically set to target's (PeA + ApA)/2 . In the altitude input box, you can change this alt by entering for example:
250
- for PeA = ApA = 250 km (a circular orbit)
230 260
or an equivalence:
260 230
- for an elliptic 230x260 km orbit
a
- for automatic altitude selection. This means a circular orbit 20 km above planet's atmosphere or 50 km above surface for bodies without the atmosphere.

So please tell me if this design fits you. For example a thing to consider would be setting the exact values for PeA and ApA as in automatic alt when you set a target in target input box, and setting the target's (PeA + ApA)/2 deliberately when you enter for eg. "t" in altitude input box (inverse from the current situation). You tell me. I don't perform too many launches.
Also, I made some sanity checks to prevent wrong input. Try to break them for a special reward ! ^_^


Ad 3) Compass with different views (by Agentgonzo)

A compass for vertical launches (like the Shuttles). Selectable with Shift M or MOD button. It has a few views, switchable with VW button. it displays both azimuths when no particular target is selected, or only one otherwise.


Ad 4) Inclination change by buttons upgraded.

When you add or subtract inclination to values beyond the possible values, then the inclination isn't reverted (or left alone), but is set to maximal/minimal possible values +- 0.00001. It has some educational value. Set incl. adj. factor to 10*, then switch on launch compass and have fun with Inclination +, Inclination - buttons, seeing how the compass reacts.


Ad 5) Reference Alt removed from user's interface and is fully automatic

I removed it from user's interface, because I doubt that anybody used it, as the error which is produced by leaving it alone equals to 0.03* for Earth. If you think that you need it, then tell me.


Happy testing !

 

[agentgonzo]

I've got as far as I can get at the moment in getting a non-flicker HUD working. Short story, I can't. :-(

See http://orbiter-forum.com/showthread.php?t=1335

 

[agentgonzo]

OK, come quite a way with the HUD. In short, it works and is far more intuitive for the Launch Compass than the MFD.

 

[computerex]

Wow, excellent. When is it being released? :beach:

 

[agentgonzo]

Not sure. Enjo's in charge of releases.

I've also incorporated the PEG pitch-prediction into it now and have been testing it a bit. It works well (very well in fact, I targetted a 150x200 orbit and flew it to get to about 150.1x199.7). There are a few things to sort on this side of things, as the PEG algorithm doesn't always give you an answer. I plan on creating a more basic prediction programme for when PEG doesn't give an answer. The PEG pitch-prediction and azimuth targets are now displayed as a flight-director cross on the HUD too :-D

 

[Enjo]

Excellent work! Thanks!

Wow, excellent. When is it being released? :beach:

Right after I catch up with real life work, do some testing, then prepare the docs.

 

[Andy44]

Wow! So far from my little TI calculator program and my original request for a launch compass! Happy to have been remotely connected to anything this cool.

Autopilots are neat, but Orbiter is all about flying things yourself. Real astronauts don't get to stear their launch vehicles except in rare, extreme emergencies which have never occurred, but Orbinauts can, and do, and you guys are giving us the tools and instruments we need for a seat-of-the-pants launch. Nice work. The HUD compass was what I had dreamed of originally, but I thought it was too ambitious. Glad to see you prove me wrong.

 

[Zachstar]

Have yall considered launch profiles for lower stages using config or XML files? So that the MFD PEG can take over on the upper stage?

 

[Enjo]

What I dislike about the XML approach is that it requires that I keep up with ship releases, and that I write an another XML with every new release, and I can't expect vessel developers to write those XMLs. On the other hand, it turns out that Kwan's idea that you described to me is a great one (checking which engines that are currently running are the strongest and assume them as main acceleration contributors). It would only need to be modified a bit, ie. to prevent assuming overpowered RCSs in some ships as main engines, as you pointed out, I could be checking if the engines are in every of the RCS group. Also I'd need to add the main engines to the currently max powered engines. Imagine how it's done with the Shuttle - SRBs are the dominant sources, but the main engines still give that 3.5 m/s^2 which also needs to be taken into account.

 

[Zachstar]

You could always use a fallback profile and let the MFD look for "clues" that tell it what fallback profile has the best chance to get the craft into Orbit.

Fallback 1: Stage Upon Stage: the fallback of fallbacks assumes all stages burn at equal rates and times.

Fallback 2: 2 Stage LEO: Your everyday power first stage and cruise 2nd stage. If you got more than 2 boosters on the first stage than likely this is the case.

Fallback 3: Weak 2 stage: This is what happens when flights like the ATV happen. I honestly do not know what clues to look for as this is likely one that has to be manually selected.

Fallback 4: 3 stage LEO: If this is the case than the 3rd stage is likely full of fuel on a weaker engine and likely has a destination outside LEO later in the mission. Again I can't find any clues.

Heck now that I think about it how about just having it a manual selection for fallbacks that the user can select?

 

[agentgonzo]

An XML pitch programme could be implemented (basic pitch vs altitude schedule). I agree with Enjo that it would require regenerating XML files with new ships and releases, but that could be left to the users. LaunchMFD could be released with the ability to read the XML files and an example file, but the user would be responsible for generating them. There have been a few people saying that they would like the ability to tweak the launch profile and this would enable them to do this.

 

[agentgonzo]

Some general musings on the subject of PEG and pitch programmes:
Currently PEG is single stage only. I'm treating PEG as a black box as it's complicated and not something that I want to get into.
I suggest that the upcoming release of LaunchMFD stays as SSTO and we worry about multiple STO for future versions.
PEG currently uses the main engines only for getting the thrust. This is OK for the time being as it generally doesn't start working until you're quite high, by which time staging has occurred and you're on the last stage anyway. I'll need to look into the Kwan ideas mentioned above later on to take into account SRBs etc.

How Kwan's original PEG autopilot worked was that you had essentially 2 stages.
Stage 1) Pitchover - Pitch down at a constant rate from the starting pitch (either vertical in shuttle or ~70° or whatever in DG) to a user input pitch at a set time after launch. This time normally coincided with SRB sep or staging as that's where the thrust changed.
Stage 2) Use PEG.
The ideal pitch for transition from stage 1 to stage 2 (PEG) is the target that PEG would output so you don't have a discontinuity in the pitch at staging. This doesn't sit well with me because it was found out by trial and error. The general idea of stage one being a constant rate pitchover still hangs good with me though, but it would be nice if it calculated the transition automatically. The time can be found easily (assuming identification of the boosters is done correctly) as it's when those specific engines run out of fuel or at a set altitude (maybe calculated from a specific atmospheric pressure) for SSTO craft. There is mention in the PEG algorithm that this can be found using functionals, but I don't have the time to get back into understanding functionals and implementing this (it's too long since university). I could use a trial-and-error approach to this upon initialisation or launch and that is where my current thinking is lying. For this to work, I'd need to get the future values of alt and velocity at staging for the initial values in PEG. This can be done with numerical methods and has the advantage that with more work, it could take into account atmospheric drag and the increasing thrust of the engines at lower pressures.

Three-or-more stage-to-orbit is another can of worms unless you treat rocket stages 1 and 2 as the pitchover (first pitch stage) and only use PEG on the final rocket stage.

 

[Zachstar]

Yes I think sticking with SSTO for the next version is a good idea. It will allow more time to research what needs to be done for profiles.

as for 3-4 stage to LEO launchers. Well obviously PEG starts on the last stage in the LEO burn no? Otherwise you have to tell PEG that there is a stage up there and from what I am understanding... That will not work.

Yes that means a more complicated XML file but then again these are not simple launchers!

Heck just being able to use use this MFD on the DeltaGlider is giving me reason to cheer!

If I may suggest some test subjects for testing?

SSTO

[ame="http://www.orbithangar.com/searchid.php?ID=1882"]SASSTO v1.0[/ame]
[ame="http://www.orbithangar.com/searchid.php?ID=1074"]Deltaglider EX[/ame]

Multistage

[ame="http://www.orbithangar.com/searchid.php?ID=2523"]KSLV-1[/ame]
[ame="http://www.orbithangar.com/searchid.php?ID=2395"]t\Space CXV[/ame]
[ame="http://www.orbithangar.com/searchid.php?ID=2301"]Walrus LV + Mystic[/ame]
[ame="http://www.orbithangar.com/searchid.php?ID=1957"]NASA VSE SC v1.0[/ame] (For the third stage part)
Also AMSO may still be able to be used for testing (Saturn V a good test article for 3 stage LEO testing)

 

[Urwumpe]

You can use PEG also for immediate stages, when you define the targets for the stages correctly - which is pretty hard work.

PEG as it is only has two limits: No atmosphere and nearly orbital speeds. It can otherwise calculate ideal solutions, which rely on lithobraking.

The Shuttle for example can't use pure PEG for RTLS.

 

[Enjo]

We are almost ready for a release. The docs are prepared, the .dll has been thoroughly tested, what's left to do are some minor tweaks, that Agentgonzo might want to make.

 

[agentgonzo]

I fancy updating the HUD now that I have a little time to play with LaunchMFD again. What do people think will be good additions to the HUD? I don't want to clutter up the HUD too much (am thinking of reducing the HUD compass down to 2 rings for this reason - what are people's opinions on this?)

I was thinking that some kind of display of time to MECO would be useful. Any ideas on that? I was thinking some graphical indication next to the flight director. Give me your ideas people!

 

[Enjo]

Here's a remedy for VESSEL(1) ships, that don't display the Flight Director on HUD: a 2D indicator (pitch, yaw) in the MFD area:

I still have to do the same for the Launch Compass operation mode

 

[agentgonzo]

Just added some code for off-plane correction (so that you can get both the inclination and the LAN correct at MECO).

It seems to be working quite nicely. A few things to iron out before committing the code, but from some initial tests, it's pretty good. Can launch straight into a 0.00° RInc orbit without any further burns after MECO.

It get's a bit funny if you are too far off-plane when you launch, but I'll sort that out in a bit.

Edit: Hmm, that's pretty good. a Rinc of 0.005° is an orbital corridor only about 7km wide at the ISS's altitude!

 

[mjessick]

I would like to suggest that the terminology change to call PEG etc. guidance algorithms (American English language practice, AFAIK) tasked with determining the trajectory to fly (and often the rocket's thrust attitude and thrust setting, etc. to fly it) and reserve "flight control algorithm" or perhaps "autopilot" for the algorithm tasked with orienting the vehicle to that commanded attitude.

An autopilot is a very limited concept historically used for partial state control of an aircraft, and more recently evolved into fuller flight management capabilities. Autopilots are always closed loop since they deal with the attitude which can diverge quickly if not carefully controlled. The paradigm and history is they started out controlling part of the attitude only and added more and more functions over time for large aircraft.

Saying autopilot this and autopilot that as discussed here is kind of jarring to me (a guidance guy).