Board index FlightGear Development Spaceflight

LEO targeting

Discussion about development and usage of spacecraft

Re: LEO targeting

Postby Ad106 » Thu Oct 29, 2020 1:29 pm

GinGin,

Thanks for your time, after a few missed steps I've got something to work.

So next, lets take an example of the Shuttle_insertion scenario. Do I need to edit the config file with the state vectors / launch site lat long/ land site lat long? Presumable I'd need to wait till post-MECO in order to export my specific State Vector? What about editing the values for the PEG-4 solution. Are they a starting point for an iteration or something? How important are the initial values? I guess I need to specify H at least.

Many thanks

I confirm I've got a recent Dev version of the Shuttle. I think it's your unofficial one, with the more correct PFD and fonts.
Ad106
 
Posts: 7
Joined: Thu Oct 29, 2020 10:11 am

Re: LEO targeting

Postby GinGin » Thu Oct 29, 2020 10:52 pm

I confirm I've got a recent Dev version of the Shuttle. I think it's your unofficial one, with the more correct PFD and fonts


Not unofficial, just the main dev repository.


Do I need to edit the config file with the state vectors / launch site lat long/ land site lat long? Presumable I'd need to wait till post-MECO in order to export my specific State Vector?


Indeed, you have to wait after MECO to export it.
I also do it 10 mn before TIG, to be sure to have a stable Orbit once past the lower atmosphere layer where drag is still quite present ( below 80 Nm)



Are they a starting point for an iteration or something?


Yes, the parameters I gave you ( which are the real one use for a normal insertion)
If you change the mission file with a different MECO altitude, flight path angle etc, those parameters might differ quite a bit.
You can play around the Theta angle to start with.

I guess I need to specify H at least.


Indeed. You need to specify what will be the height of your future apsis.
For entry though, 65.8 Nm ( 400 000 feet) is the good value ie. Entry Interface height.
GinGin
 
Posts: 1150
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: LEO targeting

Postby Ad106 » Fri Oct 30, 2020 11:27 am

Thanks,

I've been able to play around with the inputs to generate some nice OMS-1 and OMS-2 PEG-4 burns. It's pretty easy once it clicks, works well. Cheers.
Ad106
 
Posts: 7
Joined: Thu Oct 29, 2020 10:11 am

Re: LEO targeting

Postby GinGin » Fri Oct 30, 2020 3:16 pm

Perfect :)
Leo Tool is really a useful and powerful tool, allowing much more iterations than the in sim peg 4 ( 30 max without code modification)
Last edited by Johan G on Fri Oct 30, 2020 5:51 pm, edited 1 time in total.
Reason: Please do not quite the entire preceding post.
GinGin
 
Posts: 1150
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: LEO targeting

Postby Ad106 » Fri Oct 30, 2020 10:25 pm

Cool, I’m still not having 100% success though. Working out the time setting and transfer angles for OMS-2 is proving frustrating. Theta T of approx 340 and a time equivalent to APOGEE often gives weird results, like -150 PERIGEE or no result at all. Not sure what’s going on there.

Also, am I right in saying the end result/input is always going to be a PEG-7 input? If my Leo PEG-4 works, entering the data into Manoeuvre Exec generates a unconverging result. So you end up just entering the PEG-7 dV figures anyway, a result you could get with trial and error and monitoring the avionics predictions....what’s the real advantage of PEG-4 in our sim?
Last edited by Johan G on Sat Oct 31, 2020 4:32 am, edited 1 time in total.
Reason: Please do not quite the entire preceding post.
Ad106
 
Posts: 7
Joined: Thu Oct 29, 2020 10:11 am

Re: LEO targeting

Postby Thorsten » Sat Oct 31, 2020 6:27 am

what’s the real advantage of PEG-4 in our sim?


None - running a dedicated binary is faster and allows more iterations and is hence more accurate than running a full Shuttle simulation in the background plus a computation thread.

(PEG-4 in-sim also has a bug which I haven't found the time to fix which makes it fail to converge at all under some conditions).

Basically it is there in-sim because it is there in reality, but like in reality it's not the best option - mission control provides the best option (trial and error is generally a poor option and hence not used in reality).
Thorsten
 
Posts: 11765
Joined: Mon Nov 02, 2009 8:33 am

Re: LEO targeting

Postby GinGin » Sat Oct 31, 2020 10:11 am

Theta T of approx 340


If you stick to the normal mission parameters for the dev version, stick around theta of 315° with a TIG around 38 mn.

Also, am I right in saying the end result/input is always going to be a PEG-7 input?


Yes.
It always shows speed to be gained in the LVLH frame if the guidance converges ( in FG +Z axis is upward radial// +X prograde )

Page 4 of the following topic, I explained how it will show when you calculate PEG4 in sim
https://forum.flightgear.org/viewtopic.php?f=87&t=37429&start=45


.what’s the real advantage of PEG-4 in our sim


To not export the state vector, but like said Thorsten, our MCC LEO tool is much more powerful and "tune able"

If you want to increase iterations in the sim, you can change a line of code in the following file:

Nasal/orbital_targeting.nas
Line 1441

Code: Select all
me.peg4_fit_iterations > 30


Replace 30 by the number of iterations you want ( I put 200)


But really better to stick with the external tool.
GinGin
 
Posts: 1150
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: LEO targeting

Postby Ad106 » Sat Oct 31, 2020 12:34 pm

Thorsten wrote in Sat Oct 31, 2020 6:27 am:
Basically it is there in-sim because it is there in reality, but like in reality it's not the best option - mission control provides the best option (trial and error is generally a poor option and hence not used in reality).



Ok, just so I understand how it works in reality.... Will MCC provide the solution in terms of 3x PEG-7 dV targets, or will it upload a set of workable PEG-4? Sorry it this had been answered before. I guess what I'm asking is whether or not the avionics has the ability to interpret and burn the PEG-4 values, or does it need to work with a simple set of PEG-7? (I think the latter)

If the avionics only thinks in terms of PEG-7, doesn't this negate the 'closed loop' idea of the PEG-4? My understanding was that in PEG-4 the burn will be active until a set of parameters (H, TT) is achieved instead of blindly burning through a set dV figures....or have I miss understood something fundamental about PEG-4?

If this is the case, presumably the real avionics have the ability to work through many more iterations, even if it's mostly used as a backup.

Out of interest, in reality do the up-links from MCC digitally auto-populate the DPS page, or would they be communicated by voice to be input manually? maybe both....
Ad106
 
Posts: 7
Joined: Thu Oct 29, 2020 10:11 am

Re: LEO targeting

Postby Thorsten » Sat Oct 31, 2020 12:39 pm

If the avionics only thinks in terms of PEG-7, doesn't this negate the 'closed loop' idea of the PEG-4? My understanding was that in PEG-4 the burn will be active until a set of parameters (H, TT) is achieved instead of blindly burning through a set dV figures....or have I miss understood something fundamental about PEG-4?


Which avionics - the real or the FG one? The real does what you say, the simulated one does not.
Thorsten
 
Posts: 11765
Joined: Mon Nov 02, 2009 8:33 am

Re: LEO targeting

Postby GinGin » Sat Oct 31, 2020 3:31 pm

@Ad106:

In reality for OMS 1 and 2 plus all the AOA targets, datas were already loaded.

They were then updated by ground uplink ( data link)
PEG 4 value are then automatically entered ( or by crew), and lead to a converging solution ( as it was crosschecked with on ground computers) with PEG 7 output


For Deorbit burn, IMU were aligned shorlty before, plus a ground uplink for a fresh state vector.
Plus the peg 4 target uploaded from ground like for Orbit insertion
GinGin
 
Posts: 1150
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: LEO targeting

Postby GinGin » Mon Nov 02, 2020 1:51 pm

@Ad106:

An example of "in Sim " PEG 4

Normal Launch with the iss.xml mission profile.

In red, TIG in accordance with next Apogee ( MET plus TTA)

Theta at 325, I tweaked around 315 to have the lowest radial speed possible ( DVz), to avoid changing the orbit shape and our current Apogee /targeted Perigee
We can see that in purple ( 6ft/s of radial speed vs 460 of prograde speed /// Current burn Apsis almost equal to future Perigee)

In blue, the output of the PEG4 computation.
We wanted an apogee of 300 Nm.
We can cross check that quickly.

Height to be gained is (300-41) = 259 Nm
We multiply that by 1.8 ( rule of thumb // 1.8ft/s of prograde velocity gained equals 1Nm of height )
Hence Dvx = 466 ft/s, vs 460 from peg 4 guidance.
Solution is coherent

Image



Post burn values satisfactory

Image
GinGin
 
Posts: 1150
Joined: Wed Jul 05, 2017 10:41 am
Location: Paris
Callsign: Gingin

Re: LEO targeting

Postby Ad106 » Mon Nov 02, 2020 6:16 pm

@GinGin

Thanks for those examples. I'll have to find time to experiment with them at some point.

I'm tempted to try some TAL aborts later this week, but need to thoroughly read up on it first.
Ad106
 
Posts: 7
Joined: Thu Oct 29, 2020 10:11 am

Re: LEO targeting

Postby Thorsten » Mon Nov 02, 2020 7:00 pm

So, to clarify - there's no closed loop PEG-4 implemented in-sim, the PEG-4 algorithm does the same thing LEO targeting does, i.e. generates a set of PEG-7 targets. Conceptually both in-sim PEG-4 and LEO targeting PEG-4 are the same, however the latter has already a bugfix which prevents some situations from not converging and is generally faster.

The idea is that LEO targeting is equivalent to MCC, so you use the tool for mission planning and analysis just as the ground crew would.

The way the sim is organized there's no particular point in letting the sim solve PEG-4, though in many cases - as GinGin has illustrated - it will provide a valid solution - but you get the same result if you just upload externally calculated PEG-7 targets.

However, the in-sim Lambert solver for rendezvous is preferable over the external tool, as it has precise knowledge of the approximations used in-sim for the orbits of orbital targets, so if you aim for ISS the avionics generally works pretty well to provide the numbers you need.
Thorsten
 
Posts: 11765
Joined: Mon Nov 02, 2009 8:33 am

Previous

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 1 guest