wumpus

Two years ago rockets didn't get so unstable when the SRBs burned out. It worked better then. Being able to turn off a SRB is just wrong. You might be able to make the thrust near-zero (I think some ICBMs do this. Jettisoning the nozzle is an obvious means but I think the real method is less dramatic), but it will still consume its fuel at the same rate. I think there was a thread that tried to find the means of extinguishing a SRB, and it was amazingly difficult (liquid N2 probably wouldn't do it). I'm pretty sure that most of it comes from replacing the heavy steel casing with carbon fiber or similar (composite might be better for the stresses in question). Technically the Isp doesn't change (since the casing is dry weight) but if you consider the entire thing an engine it still compares well to liquid.

Right now seperatrons appear to work in that function, but only have a vacuum Isp of 154s. Perhaps if they simply bumped that up it would be enough. I'd like to see thrust curves on SRBs, but that sounds like an even more difficult UI problem than a thrust coding problem (since you can change thrusts of other rockets in real time, it can't have *too* many assumptions about fixed thrust. Not sure I'd like to code the UI).

I asked about it a month ago, and apparently the servers still work, they just aren't actively pointing to them. This might be the "old" demo, the one on Steam (I think) was based on 1.0.0, and the one on Squad's site was based on 0.18 (the last they released for free). I might have those backwards, but I suspect that they will only ship one demo based on 1.0.3 now. Most of the information on this board should relate pretty close to the 1.0.0 demo. The 0.18 demo is still quite good, but has some really strange effects: There is a "souposphere": you want your rocket to go straight up for 10,000m, then make a hard right (45 degrees East) turn until apogee is >70,000m. 1.0.0 and later work better with a more realistic pitch progression. There aerodynamic model is silly, parts have drag regardless of position. Experienced rocket designers of this era designed rockets that looked more like pancakes than rockets. 1.0.0 fixes this, although horizontal staging may well be more stable (big rockets get unstable when noodly now). TWR is optimal at 2.0 (throughout the souposphere). This is hardly true on Earth or modern Kerbin (i.e. 1.0.0 and later). There are probably other weird things to discover (and deal with while changing versions) but 0.18 pretty much captures the feel of launching little green men into space just as well as 1.0.0. Have fun whichever version you get.

Don't the thumpers resemble the Delta-IV rockets closely enough? At some point post 1.2 I rechecked the math and noticed that kickers weren't optimal to the point of overshadowing all other SRBs (what I remember easily noticing pre-beta and not changing my rocket designs) and work well enough. To reduce cost, you might stuff 2-3 thumpers on each side-mounted decoupler, but they should work well enough (aerocaps are a hard choice. I think you can add a third thumper for the price of two cheap aero caps).

There are real problems in real life with making 'big ions', but I still suspect that a single part made of clusters is possible. The real solution for ions would be allowing them to work "on rails" with their minimal acceleration. I have no idea if this simply isn't possible or that ions aren't sufficiently popular to warrant such extreme changes to the game (I suspect they would be wildly more popular for probes if they were allowed to work 'in the background', but suspect it isn't worth the serious hackery). Principia gives all vessels 'the ion problem', and I hope whoever is responsible for ions keeps up with whatever principia is doing. Last I heard it was doing well enough to be included in many/most RO/RSS games.

One thing to remember is that mathematically speaking, constants are boring. You can simply replace them with a variable name and proceed to do whatever math you like with them (plus divide without fear that it is a zero [because you wouldn't write down a zero, you'd just remove it]). Once you've finished any algebra and higher math on the equation, then you can either plug your constants into a calculator or do any simple tricks that would speed things up (and since you should have a bunch of constants piled up, there should be more opportunities for tricks). This might be a weird way to learn math, but if it works for you go for it. I remember in my engineering studies, plenty of my classmates had the opposite problem: stick a variable in the equations such that they couldn't mindlessly plug it in a calculator (it was a long time ago) and they panicked. This is a much deeper problem than anything you have. And comments about the mathematical unimportance of constants shouldn't be ignored. Mathematicians are said to have three numbers: "zero, one, many" (no idea if they are the basis for Pterry's Trolls) and smbc has plenty of jokes about physicists rounding constants off to the nearest 10 ("5 is good enough for pi"). This isn't to say that it isn't important to get the constants *right*, but plenty of STEM students get by with letting a calculator handle the all the constants (whether they learned their tables or not). But you certainly need to keep a placekeeper (one that looks and acts like a variable) in your equations, and you have to have your algebra (and to a lesser extent the rest of "calculating math") cold to do so.

It (1MW) is also about (slightly less than) 2 top of the line Tesla-S cars (1MW=1341h half that is 670hp) put together. A V2 had 3MW turbines*. It is very, very, hard to beat a turbine when you need a specific amount of power delivered from a compact size (and they are remarkably efficient, at least at high power levels), but at least the output shaft is a turbine. * this is from one of my previous posts. I don't know where it came from originally, but probably a poorly source web page.

If they aren't loudly crowing about reuse, I'd assume single use rockets. Single use batteries can be made somewhat lighter than rechargeable ones, so I'd expect they can't be recharged (not to mention an expected highly abusive load). - note: This was the "received wisdom" before LiFePO4 batteries came out. These newer batteries likely output more power than the old single use Li-ion single use champs and I have no idea if there is any reason to build a single use LiFePO4 battery.

Odd, that was the original plan. I'm guessing that there isn't a realistic way to tie two 747s together like that.

Empty Earth fuel/oxidizer fuel tanks are much lighter than Kerbal ones. I've heard that their fuel+oxidizer mass/to empty tank mass is higher than that of a coke can (which in turn is an impressive feat of finite analysis. Coke cans are about 1/3 the weight of 3-4 decades ago). In a liquid fueled rocket, decreasing TWR from 1.5 to 1.1 implies more than 30% more fuel, which typically offsets the huge gravity losses you will get (well, maybe not. The Saturn V had a TWR of 1.15, and used unbelievable amounts of fuel just to clear the launch tower. I'd hate to think of the cost of TWR=1.10). With solid rockets, things are more limited by aero forces (although shuttle launches were limited to not crushing astronauts with their own weight) and most of this goes out the window.

You are basically assuming that a high-TWR takes a heavy engine. Typically most high TWR craft have entirely solid first stages thrust is really dependent on the geometry of the cross section of your SRB, and doesn't require a fancy, heavy, engine. With liquid engines, adding more fuel (barely) increases delta-v at the cost of TWR, so often the TWR is pretty low as they eke the last bits of delta-v out of the liquid engines. With SRBs, adding more fuel also increases thrust, so TWR really is limited by geometry, aero forces, and g forces on your rocket (that thing isn't light to start with, and you expect it to support how much additional weight thanks to each g-force?). Judging from ICBM design, optimal TWR can be pretty high for suborbital designs. Since aero losses should be more significant in orbital trajectories, I'd expect optimal TWR to orbit to be as least as high as with ICBMs. The *huge* catch is that often liquid designs fit the goal better than SRBs (especially when you don't want to risk your spacecraft exploding. SRBs are famous for that). Liquid rockets almost always have other issues that make 1<TWR<2, and typically under 1.5. I think the space shuttle was around 1.5 (and limited to around 3 or so by geometric tricks), but that was probably to limit g-forces on the SSMEs (and astronauts, but I suspect even more the SSMEs). Come to think of it, I'm really curious why the shuttle didn't use a constant acceleration under SRBs.

My understanding is that this plane is expected to fly pretty slow, much slower (probably half of) the 747 it is based on. I suspect this has more to do with flutter avoidance than engine power. They are probably using multiple strategies to avoid flutter, but I certainly wouldn't want to be on the first flight (more thanks to corners cut than any one thing). Does anyone know the hours on the engines? That is, if stratolaunch goes bankrupt, can we be nearly certain that the engines will be pillaged and the rest of the craft thrown away (although someone could buy it and attach even older engines). At this point, I doubt that anyone would take the plane for free. The cost of developing a rocket for it is just too high (and there is no point for multiple pegasus launches, that couldn't be taken seriously).

While I'm sure Cassini took full advantage of modern computing and understanding of gravity, both Voyagers were almost certainly navigating by patched conics. But the real issue in "telling a probe what to do" are deeper than what even more experienced engineers might suspect. On another site I've read reports/blogs of an engineer responsible for maintaining gyroscopic lock on a probe (solar telescope? I forget), and I suspect the process is derived from Naval command. Probably the biggest issue is that "telling [probe] what to do" only happens during those brief periods when you have a slot on the deep space network to turn the big antennas on your spacecraft. Once you've targeted the thing, you have to begin communication. As you might expect, this can be nail biting as you need a response from you craft, and then whatever commands needed to operate (I think the descriptions I got were for a probe no further than Earth-Sun Lagrange points, or Earth-Moon ones. I doubt they allow dead time on the deep space network for the two hour communication delay to/from Saturn). Cassini operators have a certain advantage in that they will plunge it into Saturn before it dies. For most other probes, expect a long, drawn out process of getting communication, attempting to recover, and finally complete inability to affect the thing as it finally dies (recovering a probe isn't for newbies. You need to come up with the right answer before your communication window closes and it might be as obscure as SCE to AUX). Probe communication can get pretty deep as well. I think either Reed-Solomon error correction was invented after Voyager left, or was too new to be included or verified. I doubt we could have received all the data we got without it, much less continue to track the probe with the original ECC. Somebody had to write the new code in Mel-level assembler (for what had to be one of the most primitive CPUs of all time, check the year and power requirements). A bug in the code would end communication on board and thus couldn't be fixed, but this was done more than once.

If you think there's an issue storing liquid methane, you won't like the design of the James Webb telescope at all (it will die if it can't keep *helium* liquid). Other space telescopes have been built around limited helium (kept cold by evaporation) lifespans. Note that this implies that you can use a heatpump to pump heat into your radiators with a net cooling effect on your cold side (otherwise there is *no* way that liquid helium would stay liquid).

Even without Kerbal Engineer, the SRB parts should say how long they burn, and the engines should say what their fuel flow is. Multiply the numbers together and you have the fuel you need. Put enough fuel tanks to supply that on the SRBs and you will have the right amount of fuel and oxidizer. And this method means that there's absolutely no reason to throttle your liquid engine while the SRB is carrying you to orbit, so the fuel rate should be right (I think that is true for 1.0.2, if you can still launch with terriers (inefficiently) it might not be. Don't expect any information you see on the fora to be accurate for 1.0.2).

I can't imagine it matters, unless plans slipped out that mentioned that weaponized targeting systems were already on board. Certainly satellites such as Skylab and Kosmos 954 could be considered weapons when they came crashing down, but that hardly violated the ABM treaty (I'm less sure of the general treaty that is even signed by the North Koreans). Ok, I don't think *those* satellites could have their landing zones altered, but I think other treaties *demand* such satellites produced now have controlled reentering. I'm happier with controlled attacks on the Indian Ocean than dealing with Kessel syndrome.

While I can't take the "easy" seriously, I can't believe that I don't remember fuel (well, oxidizer) cross-feeding coming up in this thread. Most of the reasons I'm aware of crossfeeding not being used involve the pickiness of turbopumps (as noted above, just building them is hard enough. Although I'm shocked silly that crossfeeding *restartable* pump-fed engines is such a problem, perhaps the start/stop sequence keeps them off long enough to lose all efficiency gained from the crossfeeding). Of course there will be issues in that during the entire "changing between oxidizer tanks" output pressure *never* drops to the point that the flames/pressure/heat return back through the oxidizer plumbing, but it is presumably worth it to have oxidizer cross-feeding (or both fuel and oxidizer if using both).

Ah. Now I understand what the OP was saying, and it is an interesting possibility. The data I saw didn't go into vibrations, variations, nor anything you might need to even stabilize a single engine. Their stabilization solution was "launch at 5g or more", something that in KSP will quickly lock the rocket in position and remove all instability (including all player control). I have if KSP is being remotely accurate, but I assume this works for their models. If you wanted a cluster of lower stages, I'd recommend welding a bunch of steel-tubed lower engines together along with some means of dampening any vibration harmonics thus created (unless you really wanted aluminum and were willing to deal with the welding requirements). I don't think anyone has mentioned the necessity of launch clamps (that can take >6g thrust, natch), something I've never heard of on amature rocket design. Not to mention launchpad issues with >6g thrust pouring out until you release the clamps. Using carbon pressure containers and single engines outside the atmosphere appear to reduce the problem as much as possible (although guidance is still an issue. Possibly as much an ITAR/legal one as a physical/technical one). I'd assume at least a third stage (mostly a scaled down second stage, or more likely vice versa) especially with the heavy subsystem a cluster might require. I'd expect that a cluster of SRBs shouldn't have the same issues of liquid clusters: they aren't high precision equipment and as long as their steel pressure containers don't shake apart should continue functioning fine. Of course, stabilization is much more of an issue (any guesses how well spin stabilization works against having different thrusts offset from your center of mass?). Even if the "launch over 5g" does wonders for the stabilization, that really sounds like a solution for sounding rockets. Getting a rocket to follow a proper pitchover ("gravity turn" to KSP players) at 5g (presumably the thrust decreases as mass decreases, I didn't see any options mentioned or such things on the faq) is likely impossible (that's the whole point of the acceleration: to keep the thing in a straight line). The second stage may require a wildly more complicated guidance system to pull off a "KSP pre-release souposphere" move to fly horizontally as it flies out of the atmosphere. - Note: I'm not a mechanical or aeronautical engineer and my gut feeling is not only likely wrong in the above, it sounds like there is plenty of experimental data to conclude that SRB clusters are a bad idea. Unfortunately since such things are pretty much all "null data", I'm not sure how much of them are published (I'd expect to see them in abandoned 'in progress' rocket blogs if anywhere). While the whole cluster idea appears highly controversial, I suspect the replacement SRB core in a 'lightweight [carbon] pressure container' idea might be a great one. In the "amature thread to orbit", the final stage is a "SRB kicker", which seems to be an afterthought. Multiple (single engine per stage) stages made this way could replace the "kicker" and greatly reduce the rest of the delta-v needed. Although adding high thrust SRBs at the first stage to increase thrust (while using pressure fed liquid rockets for guidance) might be appealing, it also looks like burnout and release give far too many ways to destroy such a rocket.

While it certainly would be more challenging, it also would pretty much eliminate dramatic rescue missions unless you had something like the "rescue shuttle on a different pad" system that NASA used at the very end of the Shuttle era (and even then only work for LKO missions). I think that rescue missions are a great (if completely unrealistic) part of KSP and don't think they should be sacrificed to make certain mistakes more punishing. Mod all you want, but I think Squad is wise to remember it is first and foremost a game.

"Innocent of engineering" largely depends on the discipline of engineering. KSP appears to fit well with an iterative design process. Engineers of any discipline should be able to analyze each design without actually building it (civil and chemical engineers being extreme examples) while KSP prefers a more experimental process. I pointed out that KSP players in charge of NASA would kill all the astronaut corps in a few launches, but it should also be obvious that the KSP design process would also kill even Apollo level budgets (and Mercury/Gemini/Apollo used a more iterative design process thanks to engineering practices of the time and computers only slowly being developed at the same time) by building too many failed rockets and changing them too significantly. Changing an engine type is prohibitively expensive. Demo players might have a much better "could be converted to early rockets" type of design than anything with recent releases that allow picking from a huge variety of engine types (although this ignores the necessity of "mad science contraptions" that these lack or parts require). KSP does teach some basics of what a good design is, but not only does KSP encourage avoiding engineering, Squad actively prevents it by requiring mods to see even basics like delta-v. Obviously this wouldn't stop a real engineering approach as you would need to calculate so much other stuff with the same data that adding the rocket equation would be the easiest equation to add. KSP, being a game, also concentrates on the easiest aspects of spaceflight. If NASA developed a "rocket science teaching tool" (to train actual rocket scientists, not a propaganda tool) it would probably concentrate on turbopumps and slowly expand to the various plumbing that feeds/are fed by them and completely abstract everything that KSP does. The economics of KSP are also a joke. Spacex could only afford to launch 3 unpaid falcon1s before closing up shop without proof of being able to launch a bird. Compared to any realistic budget, KSP has unlimited funds. I'd expect NASA and ULA pay at least a billion to design each engine, and then another billion to design the rocket (and hundreds of millions to build a rocket with absolutely no changes from the last, and don't even ask about the cost of Space Shuttle reuse). In KSP, Falcon Heavy is two alt-clicks from Falcon 9. IRL, Falcon Heavy took years and probably hundreds of millions of dollars (and we don't even know if the first will get into orbit). I suspect a better analogy to KSP and rocket science is Guitar Hero to music. Each might be great fun, and they might inspire you to try to do the "real thing", but what they teach you is only a tiny sliver of what you need to know while taking care of the rest for you. Much of the game works by hiding how huge that gulf is. And while RO/RSS might replace much of the "little green men" bits of KSP for historically accurate rockets, don't assume that it significantly changes the rocket science. To use a "KSP level" example, I'm pretty sure you don't even have to deal with pogo. Finally, while KSP might not teach everything about rocket science, it would be complete folly to ignore what it does teach. Since 2011, the best way to start to learn rocket science has been to start with KSP. While those 'little LEGO blocks' might require intense study and practice to learn how to build them, KSP at least gives you a great deal of insight on exactly what they have to perform and why. It gives a great foundation and overview of what needs to work and where. Finally it teaches the basics of design, although its methods are obviously much more applicable to fields more like software and less like civil or chemical engineering or even "entire rocket design".

We would have also blown up several hundred human astronauts because we insist on launching rockets that are impossible to survive. - unless you've found a way to "revert to launch" that NASA hasn't found.

If you have any performance data from these rockets, it shouldn't be a terribly big deal (although vibration data might be much harder to get). My kerbal instincts would be to tie them together and simply fire the bottom stack for testing (and this is exactly what NASA did in the early years), but since it is the first stage I'm guessing it would blow your budget. The next best test would be to find the biggest model rocket engines you can find (the pinned "amature orbital thread" includes a few links to potential large model rocket engines, but there really wouldn't be any need for high Isp for a first stage test - you would just add more ballast to simulate higher stages) and see if fins can keep it stable. I'd doubt trying to mix spin stabilization and active aero controls will work , but would at least try an exhaustive literature search and more than a little simulation. Those are likely the easiest tools to stabilize this sort of thing. I really think that tying a set of "D-type" model rocket engines will tell you a lot more about what will happen than an equal time spend analyzing the final design. Of course, that isn't claiming that the scaling factors of such tiny things are remotely accurate, just that the full-scale analysis is that hard. I'd want to have fully controlled 1/10th (or higher if their are off the shelf engines available) scale models before I was confident that this design would work (Ideally I'd launch with full scale and dummy upper stages, but the cost might be prohibitive). [edit: looks like people have made it here and given up. Presumably you either need larger carbon-contained SRBs or more reliable manufacturing. Judging by the "SRBs explode" comments that fill shuttle-bashing threads, I expect that "reliable manufacturing" of SRBs is an unsolved problem that has an absolute ton of money already thrown at it (US ICBM manufacture).] Depends on the accuracy. While RADAR can supply mm and below accuracy, FM radio runs in the meter range. All you really need is to measure the phase difference between signals producing nothing but carrier signals. I'm having trouble seeing what type of guidance super strypi had: Wiki claims "SPARK also known as strypi" uses spin stabilization (no guidance) on stage 1, and guidance on stages 2-3, another (not configured) website leaves a search blurb claiming "no complex guidance". I'd recommend avoiding overthinking the guidance (unless you are strapping multiple rockets together horizontally as the OP claims is "easy", then you have real guidance/stabilization issues). Another problem with complex guidance is ITAR rules: not only do US regulators take potential missile development seriously, doing so while North Korea is likely shopping around for missile improvements seems especially iffy.

Are you supplying the $15M? Super Strypi failed thanks to a motor failure, something that only has been claimed as "easy" by the guy who started this thread. Duckduckgo sees a site that appears to be related to Super Strypi "http://www.rocket.com/super-strypi", but it appears to not be configured. The search blurb states "... without a complex guidance system", so I wouldn't count on them using a full blown guidance system either (although I would look for any kind of off the shelf system for that kind of money, and then check to see what resolution a wiimote has).

Does it have to be based on inertia? I'd expect that using radio guides (checking phase changes of a few locked signals on the ground) would be good enough for the first crucial bits (especially while still in the atmosphere and avionics will still work). If you leave the atmosphere at the right angle (I suspect you need it to the right minute if not second), I'd expect spin stablizing to be enough. It should also be easy enough for arbitrary accuracy, although you might need a second array at sea (you will eventually have a big blob of plasma pointed at the launch site, for any distance away from the launch site). Putting the guidance system below the final stage was a common trick. I know Vanguard managed to do it successfully (and I don't think guidance was the cause of earlier Vanguard failures). Not sure if avionics is enough.

So does the autopilot writes its own software? Or do humans?