Ascent Trajectory

[thammond]

I recently launched the Explorer 1 historical addon using the built in autopilot. I noticed that the orbit I ended up in using the autopilot was much lower than what the historical Explorer 1 orbit actually was.

This got me to thinking how do you determine a launch trajectory for something like the JunoI/Exporer 1 rocket/satellite for orbiter? Trial and error, MFD (note Launch MFD doesn't seem like it would be too useful because it does not support multistage rockets), tables, spreadsheet, software, other?

Also curious on how they determined the trajectory in real life for something like the Explorer 1 back in the late 50's vs how they would do it today. Guessing there were a whole lot more high level math calculations done by hand in the 50's vs computer software to do it today.

I did quite a bit of searching both on this forum and on the internet, but didn't find any good answers to the above questions.

 

[N_Molson]

Well, in Orbiter trial-and-error is always a solution, however it can be a bit time-consuming when you fine-tune an ascent profile (given it takes nearly 10 minutes to get in orbit).

Needless to say, even x10 time warp will severely affect an ascent trajectory. There are a lot of course adjustments, and the atmospheric parameters are the kind of things that require as frequent updates as possible.

In real life yes, they had squads of elite mathematicians equipped with conversion rules, pen and paper. That was pretty much the 50's technology. Even in the late 60's pen-and-paper was widely used (see Apollo 13). But in the 50's, it was also a lot of real life trial-and-error. All the failures they had with Vanguard and others Juno I (aka "Jupiter-C")/Explorer precursors helped to collect data and refine the mathematical models.

 

[francisdrake]

I once read a book on early rockets. It was mentioned that Wernher von Braun's team used basically the same guidance that was developed for the German V2-rocket during the war.

This rocket was steered, not guided. That means, it performed a predetermined sequence of maneuvers using a simple intertial platform and a timer. There was no feedback how the rocket was actually performing. Every rocket-shot had quite some randomness in it, regarding wind or burn chamber perfomance.

Now guessing:
The commands could have been like this:
- Counter any roll movement.
- Keep the launch azimuth. If deviating, steer back to this azimuth.
- At time 'x' aim for an elevation of 'y' degrees. Repeat.
- At time 'z' cut off the engine.

For Explorer 1 only the Redstone booster was guided. Stages 2, 3, 4 were spin stabilzed solid rockets, which did not allow any steering. I guess the stages over-perfomed, so the actually achieved orbit was higher than intended.

 

[Urwumpe]

Yes, a lot of the abilities of the GNC systems of early spacecraft had been limited by the available technology. Rockets often had only the ability to follow a simple "constant pitch rate for a period of time" way of guidance.

In case of Explorer 1, the orbit was pretty much intentional (though unguided and thus also uncontrolled with large error margins). It was meant to investigate the Van Allen Belts and had to reach them, as predicted by the theories of Van Allen.

 

[thammond]

It would be interesting to find out what that pitch program was for Explorer 1 and plug that into the autopilot in Orbiter. I wonder if it is published anywhere.

---------- Post added at 10:15 PM ---------- Previous post was at 09:59 PM ----------

I ran across a photo on the internet of about 30 women who supposedly did all the hand calculations for Explorer 1 orbital trajectory calculations.

http://imgur.com/gallery/T36Ms

 

[Urwumpe]

I ran across a photo on the internet of about 30 women who supposedly did all the hand calculations for Explorer 1 orbital trajectory calculations.

Yes, by slide rules. Similar number crunching was also done for the Manhattan project. Computers had not been that widespread in that era.

 

[thammond]

I may have found a free software package that may be helpful in determining an optimal ascent trajectory other than trial and error in orbiter. Its called Zoom. I'm going to input the Explorer 1 data into it to see what I get from it. it looks pretty detailed so it may take me a bit to figure out how to use it

Has anyone ever heard or used it? If so any feedback about it?

For anyone interested, here is a link to the web site for the Zoom software.

http://trajectorysolution.com/index.html

 

[Urwumpe]

I may have found a free software package that may be helpful in determining an optimal ascent trajectory other than trial and error in orbiter. Its called Zoom. I'm going to input the Explorer 1 data into it to see what I get from it. it looks pretty detailed so it may take me a bit to figure out how to use it

Has anyone ever heard or used it? If so any feedback about it?

For anyone interested, here is a link to the web site for the Zoom software.

http://trajectorysolution.com/index.html

Never heard of it, but the description of the software looks like the developer never heard of common design patterns like worker threads. So, it could be a good tool engineering wise, robust, but "with a lot of character."

Like most GNU tools.

 

[Enjo]

Never heard of it, but the description of the software looks like the developer never heard of common design patterns like worker threads. So, it could be a good tool engineering wise, robust, but "with a lot of character."

Like most GNU tools.

Sad but true, but still I like to look on poorly written tools as a good reference for a unit test - covered, well designed project.

This got me to thinking how do you determine a launch trajectory for something like the JunoI/Exporer 1 rocket/satellite for orbiter? Trial and error, MFD (note Launch MFD doesn't seem like it would be too useful because it does not support multistage rockets), tables, spreadsheet, software, other?

Once you get the pitch program from the Zoom app somehow, you may use it in Launch MFD, leveraging the MFD's azimuthal guidance.

 

[Col_Klonk]

For Earth (You can adjust this for lunar objects)

Turn ratio is 1 degree per 1000m altitude. (or automated to atmospheric profile - lunars have default heights?)
Once at 90 Km, stay horizontal and accelerate to Orbit.
Depending on your rocket you should reach circular orbit anywhere between 150-300Km.
Push for 300Km parking orbit.. then go higher.
:thumbup:

I've started making a automated profile in KSP.. with Real Solar System, Realism Overhaul + KOS (program your own profile) mods.
This is a method test bench (thanks to KOS) before converting to Orbiter, which I think will be easier, as KSP is full of 'funnies'
Anyway here's the vid..
It's also about testing a Bit-Banging, pressure fed, motor method.. if you can hang on a bit
https://www.dropbox.com/s/y161cjojfop9k40/PolarOrbitwithKOS.mp4?dl=0(53MB)

 

[thammond]

Thanks Col, I'm currently away from home through the weekend with bad wifi, so I'll watch the link when I get back.

Note, I'm trying to recreate the historical Explorer 1 orbit which is something like 315 x 2250 km. Also from what I understand the 2nd stage was started via ground control at apogee of 1st stage. But once started it could not be stopped and the 3rd and 4th stages started as soon as the previous stage ended.

Thus the goal of the 1st stage will be to follow a trajectory that will end up with a apogee of about 315 km.


Sent from my iPhone using Tapatalk

 

[boogabooga]

It's not just the trajectory.

You have to make sure that all of the dry masses, fuel masses, thrusts, and ISPs (via "burn time") are really correct for each stage.

P.S.- that ZOOM looks interesting. Very interesting.

 

[thammond]

Yes, I took an initial look at the ini file and the parameters look suspect to me. For example I remember (don't have access now) the 2nd stage in the ini file only had 8 engines while the real 2nd stage has 11. Also the 3rd and 4th stages appear to be one in the same in the addon.

Not sure if that is because of limitations in Obiter, the addon was made for 2005 version, and if so did the author make proper adjustments to compensate. I will look at that in more detail.


Sent from my iPad using Tapatalk

 

[Urwumpe]

Yes, I took an initial look at the ini file and the parameters look suspect to me. For example I remember (don't have access now) the 2nd stage in the ini file only had 8 engines while the real 2nd stage has 11. Also the 3rd and 4th stages appear to be one in the same in the addon.

11 engines are correct for the second stage, but I am not sure if the add-on also correctly includes that the instrument section was separated from the first stage and moved the second stage to the correct attitude during the long coast phase before second stage fired.

 

[thammond]

Yes the addon does have the instrument section modeled, and it does orient the tub section before dropping off. As for checking the mass of each section, I would assume the instrument section mass would be considered part of the 1st stage in the data I have found online.


Sent from my iPad using Tapatalk

 

[boogabooga]

Also the 3rd and 4th stages appear to be one in the same in the addon.

Be careful because IIRC, the Explorer 1 itself was the fourth stage. So the "fourth stage" might really be the payload.

This kind of launch vehicle architecture is a little strange by modern standards.

 

[thammond]

The 4th stage in the historical Explorer 1 satellite has 1 built in engine that did not separate from satellite after it burnt out.

The 3rd stage had 3 engines, and the 2nd stage had 11.

As for the addon. As I said the add on only has 8 engines in the 2nd stage. I will need to check if the addon developer made an adjustment to make the 8 engines equivalent to the 11 on the historical 2nd stage.

What I'm not sure about is how the addon handles the 3rd and 4th stages. The cfg/ini file has 1 engine defined each for the 3 and 4th stages. There does not appear to be a separate 3rd stage in the addon. After the 2nd stage separates, it looks like just the last stage with satellite with 1 engine. However there is something that separates from the rocket while the engine is running. I suspect it is some mass loss between the 3rd and 4th stage to get the mass correct.


Sent from my iPad using Tapatalk

 

[thammond]

Looking through the ini file regarding masses, thrusts, burn times, etc. The thrust for each stage are about 20% higher than what data I could find. I suspect that was to try and balance an inefficient and not historically accurate autopilot guidance program. However as I stated previously the addon is still has a considerably lower Apogee/Perigee than the historical Explorer 1 satellite.

As for some of the other parameters, I'm not sure how accurate they are as there are some items in the ini file that confused me.

So I have been thinking about various options to get the orbit closer to historical.

1) Use scenario editor shortly after the last stage burnout to adjust the orbital parameters to the historical parameters. I don't really want to do it this way, but quick and simple.

2) Adjust the guidance file and/or the thrusts of the various stages of the addon in a trial and error fashion to get a closer to historical orbit. Better than option 1 and simple enough to do, but could be long tedious process.

3) Create my own addon. I have thought about learning how to make an addon and making an updated Explorer 1 addon might be a good place to start. I don't have any experience in meshing, textures or coding so everything would be brand new to me, but would like to give this a shot.

I do have CAD (SolidWorks) experience and some old programming experience (FORTRAN and PASCAL in college). But have not done any meshing, textures, or coding in Orbiter. Serching through the forum and looking at various tutorials, I think Multistage 2015 may be a good place to start.

Any thoughts, ideas, suggestions, or tutorials to get me pointed in the right direction.

 

[Urwumpe]

Searching through the forum and looking at various tutorials, I think Multistage 2015 may be a good place to start.

Any thoughts, ideas, suggestions, or tutorials to get me pointed in the right direction.

I would recommend taking a closer look at Velcro.

[ame="http://www.orbithangar.com/searchid.php?ID=3388"]Velcro Rockets v1.11[/ame]

Making a DLL for this one would also not be a terribly hard thing, the Jupiter-C is a fairly simple launcher, the guidance scheme is primitive. the only complex thing for this one was the ground support equipment, which was much more relying on manual labour than modern ones.

 

[thammond]

Ok I think that I may try making this in Multistage and Velcro to learn both. And then follow up with coding a dll at some point.

I did by the way find a little more data about the actual flight profile of the Explorer 1 rocket. Not sure if the info I found was planned or actual, but I suspect it was planned profile.

At the end of the 1st stage burnout the pitch of the rocket pitch was 40 deg, the altitude was about 100 km, and it was about 50 nm downrange. It then coasted for 247 seconds to an Apogee altitude of 360 km and was downrange about 350 nm before firing the 2nd-4th stages.