SpaceX COTS Demo 1 Updates

[Jim]

It wasn't the first time that's happened and it won't be the last so to single out SpaceX isn't exactly fair.  I think that they're entitled to do this their way.  It's their money plus NASA's and NASA seems ok with the way they're going at this point anyway.

No, "NASA" is not ok with it.  Only COTS is ok with the way they are going. Station logistics isn't going to send any high dollar items for awhile, hence Tang, tee shirts and toilet paper can take some higher risks. 

It isn't fair to single out Spacex has the next best thing to slice bread either.

[pathfinder_01]

It wasn't the first time that's happened and it won't be the last so to single out SpaceX isn't exactly fair.  I think that they're entitled to do this their way.  It's their money plus NASA's and NASA seems ok with the way they're going at this point anyway.

No, "NASA" is not ok with it.  Only COTS is ok with the way they are going. Station logistics isn't going to send any high dollar items for awhile, hence Tang, tee shirts and toilet paper can take some higher risks. 

It isn't fair to single out Spacex has the next best thing to slice bread either.

Also low value items like food, water, uniforms are rather important.

[Jim]

It wasn't the first time that's happened and it won't be the last so to single out SpaceX isn't exactly fair.  I think that they're entitled to do this their way.  It's their money plus NASA's and NASA seems ok with the way they're going at this point anyway.

No, "NASA" is not ok with it.  Only COTS is ok with the way they are going. Station logistics isn't going to send any high dollar items for awhile, hence Tang, tee shirts and toilet paper can take some higher risks. 

It isn't fair to single out Spacex has the next best thing to slice bread either.

Also low value items like food, water, uniforms are rather important.

Not on a per launch basis.  A mission failure can be over come easily by flying the next mission.

[pathfinder_01]

Not on a per launch basis.  A mission failure can be over come easily by flying the next mission.

Which is why they are taking the risk with Space X. If it works lots of up side and some possiblity of recovery if it fails.

[Jim]

Not on a per launch basis.  A mission failure can be over come easily by flying the next mission.

Which is why they are taking the risk with Space X. If it works lots of up side and some possiblity of recovery if it fails.

My point is that this is ok with the NASA station community but not the rest of NASA that uses launch vehicles.

[duane]

Sorry just a aviation/space watcher not in the biz here

Seems there is a lot of process engineering bickering going on about Spacex. Just reminder that Nasa HSF is not immune from process failure specifically in regards to two shuttle vehicles and 14 deaths.

Hopefully SpaceX gets to a high level of process maturity where lives will not be risked if they ever commit to a crewed version, and we never lose anymore crews on Nasa human spaceflight missions

Just some $0.02 from a life long space fan!

[mmeijeri]

My point is that this is ok with the NASA station community but not the rest of NASA that uses launch vehicles.

But isn't the point to start with low value cargo to get the bugs out of the system and establish a reliability record before trying manned launches or expensive satellites?

[Comga]

Here's the kmz file (as of Dec 11) converted to a CSV for anyone who's interested.

Thanks hop!
A quick calculation produces

13.1 km average Soyuz distance  from aim point to actual landing
 2.7 km minimum distance   
10.1 km  Standard deviation (although StDev is not an ideal measure for what's probably a Poisson distribution )

So Dragon, on its first flight, is staid to have come back with one third the offset of the most accurate Soyuz flight, and 6% of the average offset.

A blind Rocky-the-Flying-Squirrel? 
"Watch me pull a rabbit out of my hat!"

[Lars_J]

Wow, that really puts the accuracy into perspective.

What is the median and standard deviation?

[Ronsmytheiii]

Not on a per launch basis.  A mission failure can be over come easily by flying the next mission.

Which is why they are taking the risk with Space X. If it works lots of up side and some possiblity of recovery if it fails.

They arent "taking the risk" with spaceX, OSC has another contract.  If they really were, then there would not be another contract.

[beancounter]

Not on a per launch basis.  A mission failure can be over come easily by flying the next mission.

Which is why they are taking the risk with Space X. If it works lots of up side and some possiblity of recovery if it fails.

My point is that this is ok with the NASA station community but not the rest of NASA that uses launch vehicles.

My point is that NASA does it's business in a certain way and SpaceX has chosen to undertake it's business in another way.  SpaceX being in 'business' with limited funds accepts certain risks as being part of their business which NASA being government funded does not or apparently not because as another poster has pointed out (and something I thought didn't necessarily need pointing out) they have not been immune to failures.
We may see SpaceX change their approaches but probably not since these wouldn't necesssarily be in the public arena.  I would say that the truth will be in their continued success or otherwise with NASA and other customers.

[Robotbeat]

Wow, that really puts the accuracy into perspective.

What is the median and standard deviation?

Well, it does seem that their existing system does better than Soyuz (if the 800m is correct), which doesn't sound too impossible if you have, say, an improved gyro with less drift (for instance) or use GPS in addition to the gyro.

Remember, the terminal rocket guidance system would have to adjust for windage anyways, so it doesn't seem impossible to me that they could land accurately. Not at all.

[wintermuted]

Not to beat the "process discussion" horse to death, but I think there are 2 factors which haven't been mentioned here that contribute to their ability to act quickly when a problem occurs: the relative newness of the company, and their level of vertical integration.  When they saw the cracks in the nozzle, they probably could have had everyone that ever worked on the design in a conference room within 5 minutes.  Because of the "newness" it's less likely that the employees associated with a particular part have retired or moved on. 

On top of that, they also all work directly for SpaceX and not a sub-contractor.  Imagine if the nozzle was designed and built by an outside vendor, and SpaceX had to call them up and say "Hey is it okay to fly this with cracks, or can we maybe trim it down?".   There's very little reason an outside vendor would suggest anything other than replacing it with a new one - they have no motivation to assume any more risk, and a big motive to sell another nozzle.

[cuddihy]

Not to beat the "process discussion" horse to death, but I think there are 2 factors which haven't been mentioned here that contribute to their ability to act quickly when a problem occurs: the relative newness of the company, and their level of vertical integration.  When they saw the cracks in the nozzle, they probably could have had everyone that ever worked on the design in a conference room within 5 minutes.  Because of the "newness" it's less likely that the employees associated with a particular part have retired or moved on. 

On top of that, they also all work directly for SpaceX and not a sub-contractor.  Imagine if the nozzle was designed and built by an outside vendor, and SpaceX had to call them up and say "Hey is it okay to fly this with cracks, or can we maybe trim it down?".   There's very little reason an outside vendor would suggest anything other than replacing it with a new one - they have no motivation to assume any more risk, and a big motive to sell another nozzle.

I think these are excellent points that go to the heart of what the disagreement is about. Nasa's QA and processes are built around two assumptions common in DoD and government: 1. That no one is irreplaceable--I.e. That processes have to work so that anyone "sufficiently knowledgeable" can do them and get the exact same output. And 2. That decisions made today will have unforeseen consequences tomorrow, processes are built to work inbasically every conceivable "reasonable" set of starting conditions. Great, except those are very expensive overburden on the system.

SpaceX does not follow these assumptions, and we will see how that works out over the long haul.

[Jim]

I think these are excellent points that go to the heart of what the disagreement is about. Nasa's QA and processes are built around two assumptions common in DoD and government: 1. That no one is irreplaceable--I.e. That processes have to work so that anyone "sufficiently knowledgeable" can do them and get the exact same output. And 2. That decisions made today will have unforeseen consequences tomorrow, processes are built to work inbasically every conceivable "reasonable" set of starting conditions. Great, except those are very expensive overburden on the system.

SpaceX does not follow these assumptions, and we will see how that works out over the long haul.

That will be the downfall and the start of increased costs.  People have to be replaced

[simcosmos]

I. Falcon9-Dragon COTS Demo1: Performance and Trajectory Reconstruction (?)

Like Ed Kyle (on the next link), I have also been trying to 'reverse calculate' the numbers of the recent COTS Demo 1 F9-Dragon flight:

http://forum.nasaspaceflight.com/index.php?topic=23516.msg669446#msg669446

Such virtual reconstruction is not an immediate thing to do, despite there is a press kit as well some information available at SpaceX's site and despite there is a very cool live recorded video of the flight.

Due to the work-in-progress going on at SpaceX, there are a number of input parameters which are either scattered, not-final / uncertain or unknown and which have impact on any try at an analysis. On top of that, and in what relates to this specific COTS D1 flight, there was also the second stage nozzle fix (adding yet another layer of uncertainty for upper stage engine 'simulation').


Moving on: I think that might be on a (preliminary) path that might very roughly replicate SpaceX's COTS D1  performance / trajectory... At least it looks very cool when running the simulation (in Orbiter Space Flight Simulator) side-by-side with the SpaceX recorded video: with one or another deviation, the main ascent events seem to be +/- well synchronized with the live video (ignition sequence, liftoff, mach1, maxQ, staging, aero-covers jettison, rough velocity calls vs altitude vs time)...

... Have kind of built two main families of input assumptions: the differences between such two families are on stage dry masses, engine parameters for first and second stage, Dragon mass (capsule + prop + trunk + sats + nose cover) and also on some things related with selected parts of the ascent profile (pitch commands).

In one case I achieved something like 300 x 287 km / 34.63 inc. with cutoff at apogee... on another case / on another separated 'family' of input parameters - and related virtual telemetry output - achieved something like 309 x 281km, 34.45 inc, with cutoff at perigee...). This while protecting for upper stage performance to achieve ~11000 km apogee (post Dragon Capsule and post cubesats jettison).


All this might probably deserve its own thread (?), if someone also wishes to further discuss a number of input parameters and virtual telemetry outputs in order to try to better understand SpaceX's COTS D1 flight (and perhaps also in order to build some 'predictive' simulation background for COTS Demo 2?).

For the moment would like to ask if someone beyond me (and apparently Ed Kyle) also made a little of informal / independent technical brainstorm about SpaceX's COTS Demo 1 flight (?)



II. In particular – and to start - I would be mostly interested on reading further comments related with the Falcon9 upper stage engine (thrust / ISP for the 'shaved' engine):

II.a) On one of the numerical sets of  preliminary simulations here, I have assumed an ISP of ~328s for such upper stage engine.

Note: on the press kit the upper stage ISP was given at 336s... on SpaceX's site, the ISP is expected at 342s (for the 'blockII' engine variant?); as a side note, the max. ISP of the first stage engines was simulated between 294s and 304s (depending of specific set of assumptions).

So, as a starting point, I roughly assume that, on COTS D1 flight, the upper stage engine ISP was higher than 304s and lower than 336s... I then 'chose' two numbers (328s and also a lower value) for each main family set of assumptions.


II.b) Regarding upper stage thrust, assumed here ~411.5 kN (on one set of assumptions, per the official COTS D1 press kit)... but would like to ask if someone has any observation regarding eventual throttling procedures on COTS D1 upper stage portion of the flight... although there aren't any calls for that on the video (?) (by the way, yes, I have simulated MECO1 and MECO2 for the first stage). 

This 'thrust' question, together with the ISP question, is also related with the total propellants amount assumed for the upper stage... (depending of family of assumptions - and interaction with other parameters - I have assumed from ~40400 kg up to 43200 kg or so...).


As noted in the start, this attempt to reconstruct SpaceX's COTS1 flight is not trivial due to both the specificity around such flight (such as the nozzle 'fix', a probably light Dragon configuration, etc) as well due to some key parameters being unknown... although some things could be kind of extrapolated by crossing available information (and using the ascent video).

Thanks,
António

[martin hegedus]

I. Falcon9-Dragon COTS Demo1: Performance and Trajectory Reconstruction (?)

...

All this might probably deserve its own thread (?), if someone also wishes to further discuss a number of input parameters and virtual telemetry outputs in order to try to better understand SpaceX's COTS D1 flight (and perhaps also in order to build some 'predictive' simulation background for COTS Demo 2?).

For the moment would like to ask if someone beyond me (and apparently Ed Kyle) also made a little of informal / independent technical brainstorm about SpaceX's COTS Demo 1 flight (?)

...

Thanks,
António

I'm interested in learning more, contributing 2 cents here and there, and seeing where this goes.  I figure this would be like the "NASA model building thread," but geared towards numerical modeling.  I don't think the thread will advance very fast, but that is OK.

[simcosmos]

I. Falcon9-Dragon COTS Demo1: Performance and Trajectory Reconstruction (?)

...

All this might probably deserve its own thread (?), if someone also wishes to further discuss a number of input parameters and virtual telemetry outputs in order to try to better understand SpaceX's COTS D1 flight (and perhaps also in order to build some 'predictive' simulation background for COTS Demo 2?).

For the moment would like to ask if someone beyond me (and apparently Ed Kyle) also made a little of informal / independent technical brainstorm about SpaceX's COTS Demo 1 flight (?)

...

Thanks,
António

I'm interested in learning more, contributing 2 cents here and there, and seeing where this goes.  I figure this would be like the "NASA model building thread," but geared towards numerical modeling.  I don't think the thread will advance very fast, but that is OK.

*BUMP*

Thanks for the reply Martin!

I. It seems to be like you wrote, there does not seem to exist a very active (forum) interest about what I have proposed and, in the end, it might result on a slow thread because:

a) as 'traditional' of me on those kind of threads, I like to explicitly reference the starting assumptions as well properly reference / link to source data (else there isn't a minimum of standardization for others to follow or comment the assumptions and results)...

b)  there is also the added difficulty expressed on the previous post: there are a number of numerical inputs which aren't clearly or readily available from SpaceX... This would then require educated guesses and crossing pieces of scattered information with no guarantee that the simulation would represent well enough (always depending of constraints and objectives) the real hardware (unless someone from SpaceX would like to participate with a few hints).


Both of the above means extra time and dedication to prepare and share public information under the form of clear and organized as possible written posts. Only to give an example, I currently see a number of posts on NSF forums about Falcon9, Falcon9 eventual evolution paths and about Dragon spacecraft current and eventual future capabilities... On my opinion, it would perhaps be nice to have some numerical standardization (and confirmation) of a few of the assumptions being made before trying to extrapolate into more 'advanced' scenarios.


Summing up, from this side, I might then probably continue to research and document this (Falcon9 + Dragon specifications / mission capabilities / eventual evolution) on a more private way (with related simulation work) before sharing those musings on a more public way, mostly because anticipate (at least is the impression that have, when comparing with some past interventions on other threads) that I would probably be (one of) the main contributor(s) of such eventual thread (and if that would be the case, then would need  extra time to properly prepare and 'study' things...).


II. Only as reference, a few of the topics being 'researched' here are:

- virtual reconstruction of SpaceX COTS Demo1 flight (launcher properties, trajectory, mission procedures – including release of cubesats – and, last but not least, Dragon  capsule properties for such specific flight)...

- another topic being studied is Falcon9 'block1' vs 'block2' expected properties vs 'full' cargo Dragon  vs crewed Dragon spacecraft vs mission modes (probably including a comparison between a standard LAS design and an integrated abort system for Dragon)...

- yet another topic of interest is related with the study of Falcon9 first stage recovery, in particular when comparing the virtual apogee preliminary 'results' of the past Demo1 flight with other assumptions...

- there are also a number of extra topics related with such custom musings, research, study, simulations... but again, that would require extra time (and might be matter of an eventual future thread, if opening it at all).   


III. Meanwhile, I hope it is OK if I attach a short video with a clumsy preview of some of the performance / trajectory simulation work done here about SpaceX Falcon9-Dragon COTS Demo1 (the video has been made a few minutes ago but the performance files already have quite a few days... although haven't returned to them yet).

I have used older 3D models from an already existing Orbiter addon (Space-X launchers and Dragon v0.58 by 'Glider' / 'MajorTom') but have updated the 3D models materials properties and textures  (not sure if will make my own 3D models, at least for the rocket) as well have seriously revised (fresh start) the performance / trajectory implementation accordingly to my implementation methodologies, using Vinka's generic dlls)...

As also previously noted, the objective is to replicate the recent flight as best as possible so that can then hopefully have a more solid simulation departure point to adapt for eventual future SpaceX COTS demo flights (and other hardware evolution musings)...

To keep the video short, will only upload the ascent part that goes from MECO1, MECO2, staging, upper stage ignition to aero covers jettison: things are not perfectly 'coded' yet (still a lot of stuff to tweak / improve on the input parameters and ascent guidance file), neither perfectly synchronized, but it might still be interesting to see, despite the lack of careful script / edition an despite the final encoding compression factor, to keep the file size down (original video capture of the simulator session was at 800x600... I could use the same source files to produce a video with an higher resolution but that would take ~19MB... if someone from SpaceX wishes, just for fun, to have this preliminary video on such slightly higher resolution, feel free to PM).

Thanks,
António 

[TimL]

Antonio,

I think this is a great endeavor but without a little more ascent data, you have to rely on too much speculation. I'm having trouble trying to determining if the weight of the dragon is 4,300 without the trunk attached or with the trunk attached. A lot of SpaceX's literature is a little vague on this, but it makes a big difference on performance profiles. Most of the Orbiter add-ons are all over the place on values, not to mentions the config files are a nightmare with a lot of typos and incorrect directory pointers.

TimL

[martin hegedus]

I. It seems to be like you wrote, there does not seem to exist a very active (forum) interest about what I have proposed and, in the end, it might result on a slow thread because:

I do think there is an interest in regards to seeing the results and discussing them intellectually.  However, in regards to generating the technical information to the fidelity you (and I) seem to be interested in, some ingredient seems, to me, to be missing (outside of a small set of individuals).  The desire is out there.  The technical skill is out there.  But ..., I just can't put my finger on it.

b)  there is also the added difficulty expressed on the previous post: there are a number of numerical inputs which aren't clearly or readily available from SpaceX... This would then require educated guesses and crossing pieces of scattered information with no guarantee that the simulation would represent well enough (always depending of constraints and objectives) the real hardware (unless someone from SpaceX would like to participate with a few hints).

True.  That is just the way it is and needs to be accepted to keep moving.

Both of the above means extra time and dedication to prepare and share public information under the form of clear and organized as possible written posts. Only to give an example, I currently see a number of posts on NSF forums about Falcon9, Falcon9 eventual evolution paths and about Dragon spacecraft current and eventual future capabilities... On my opinion, it would perhaps be nice to have some numerical standardization (and confirmation) of a few of the assumptions being made before trying to extrapolate into more 'advanced' scenarios.

LOL, oh I wish that would come to pass.  But I don't think that will happen, at least to the extent you are wishing for.  And maybe the format of this forum doesn't facilitate that.  It would be nice to have a cheat sheet where people could easily go and get current up to date data rather than digging through posts.  Maybe two threads could be created, one would only contain numerical data and pure analysis and the other would contain discussion.

Summing up, from this side, I might then probably continue to research and document this (Falcon9 + Dragon specifications / mission capabilities / eventual evolution) on a more private way (with related simulation work) before sharing those musings on a more public way, mostly because anticipate (at least is the impression that have, when comparing with some past interventions on other threads) that I would probably be (one of) the main contributor(s) of such eventual thread (and if that would be the case, then would need  extra time to properly prepare and 'study' things...).

I would encourage to be as public as possible, even if something isn't ready for prime time.  I would also discourage PMing.  This way everyone knows what is going on and if someone needs to put a stop to something or moderate where things are going, then they can.  For example, a while back when discussing trajectory optimization codes Chuck mentioned that it would be nice to have hooks in it for Monte Carlo simulations.  And, I agree, it would be cool to have that to be able to model environmental effects such as winds at altitude.  And it is not difficult to do.  However, it also puts such an analysis methodology clearly in the realm of targeting, and that is a no-no.

III. Meanwhile, I hope it is OK if I attach a short video

Thanks,
António 

Thanks.  Next up, I need to find a wmv viewer for my Linux box.

Edit:  Go for it, start the thread.