K^2

Hah. Good idea, I'll have to try it. (It'd be easy to cheat this in, but where is the fun in that?)

No idea. Though, there are a couple of places where thrust vector differs significantly from velocity vector, so I think this wouldn't work well in FAR. I'd have to take a look at FAR model and take it into account to get a somewhat different profile. As it is, this is just for vanilla drag. Hm. It has no problem getting "infinite" thrust off the pad, to quickly build up to terminal velocity. Shouldn't it work the same way for hmax by your logic? The other thing is that rocket is directed to burn mostly down at the top. So it might make sense for throttle to ease off. It seems that situation here is similar to a landing burn, where you start burning towards the planet/moon initially in the beginning. (Constant altitude descent method.) Indeed, there should be. I'll edit it in.

Just an interview presentation. I ended up taking a different offer, so no, I'm not affiliated with Havok in any way. Depends on how precise you want to be. Also, on the way things are inter-connected. If we ignore struts, the way things are connected in KSP, you can get away with deformation tensor per part for a very good approximation. You'd need a custom shader to go along with that, but it's easy enough even under Unity. Struts would then simply have to be whatever length they need to be to connect the two points. That can lead to silly-looking things under extreme stress, but presumably, parts will fail before that happens.

The recent discussion on optimal ascent problem has reminded me that I saw some interesting ways of dealing with optimization problems in finance that I wanted to try out. I've put together some basic Mathematica code as a proof of concept, and actually got nice results out of it that I wanted to share. The idea behind optimal policy approach is that you start out with policy function, which is the desired outputs based on current state. In case of rocket's ascent in KSP, the outputs are going to be the thrust and attitude of the rocket, while the state will be the altitude and horizontal and vertical velocities. Once we have a policy function, we can compute state evolution, from which we can compute an integral that we wish to optimize. Again, in KSP we would compute trajectory the rocket follows under given policy, and use it to estimate delta-V required to reach orbit. Once we have that, we can vary the policy function to try and optimize the result. There are two major obstacles in doing this in KSP. First, we have three input variables and two output variables. That is a huge space of available policy functions. Second is the fact that we need to establish boundary conditions, which is tricky as stated. Fortunately, both of these are resolved if we re-formulate the problem. Instead of looking at velocity as the state, we'll consider it to be the desired output. After all, for a given ascent profile, there will be a unique horizontal and vertical velocity for each altitude, and thrust can be computed from the way these vary with altitude. Final obstacle is the fact that we are dealing with a continuous range of variables. The simple solution is to use parametrized polynomial approximations and then the search space for optimization consists only of the parameters. Lets start with the 1D problem of vertical ascent, which we know analytic solution to, and state it explicitly. Given altitude h, we wish to find optimal ascent velocity v(h) that is most fuel efficient. In other words, we wish to minimize integral over T(t)dt, where T is thrust and t is time. We shall now compute the necessary thrust in units of rocket mass. T(t) = g + k(h) v² + dv/dt Here, k(h) is drag coefficient, k(h) = k0e-h/H for some scale height H. Now we shall take dv/dt using chain rule. dv/dt = (∂v/∂h)(dh/dt) I shall denote ∂v/∂h as v'(h), and, of course, dh/dt = v(h). T(h) = g + k0e-h/Hv²(h) + v'(h)v(h) Of course, we are interested in integral over T(t)dt, but noting that dt = dh/v(h), we can re-write it as an integral (T(h)/v(h))dh, which we can integrate over having only the policy function v(h) at hand. Finally, we need to specify the parametrized form for v(h). For simplicity, I've used Legendre polynomials, Ln(x). v(x) = v0 + (vmax - v0)(a L3(x) + b L5(x) + c L7(x) + (1 - a - b - c)L1(x)) This means that velocity will vary from v0 to vmax for x = h/hmax from 0 to 1. Since this is to serve as a proof of concept, we'll assume that v0 and vmax are the terminal velocities at h = 0 and h = hmax respectively. If the approach is valid, minimizing integral of T(t)dt with respect to parameters a, b, c should produce terminal velocity curve as the policy function. And, of course, it does. The result of optimization is in gray, while the terminal velocity plot is in green. Now, for a more useful problem. The policy is replaced with a pair of functions vx(h) and vy(h). The thrust function T(h) is far more complex, but is derived in the similar way. The integral we optimize is still (T(h)/vy(h))dh. But the best part is our ability to set initial and final velocities. At h = 0, both vx and vy are zero. At h = 80km, vy is zero, while vx is orbital. Please note, I did ignore Coriolis force and rotation of the planet. Other parameters are set to Kerbin from sea level. The parametrization for vx(h) is very similar to v(h) above. In fact, it's the same, with v0 = 0. Parametrization for vy is way more complex, because I needed an asymmetric function with zeros at both ends. I'm not going to go through all of the results and potential problems, mostly because I want to build a finished version that accounts for all of KSP physics first, but I do have a rough result for the ascent profile. This is the angle of rocket's velocity with respect to horizon from sea level to the 80km orbit. As expected, it is 90° off the pad, and 0° in orbit. The gravity turn does, in fact, begin immediately, but it is more gradual than some people have suggested. Of course, the TWR for this ascent peaks at roughly 3:1. I have not considered caps on thrust yet. The great thing about this approach is that it is light weight enough to be used on the fly. Once I have all the gremlins worked out and have it working with thrust cap and variable ISP, it'd be nice to see if this can be written into a plugin that does automatic ascents in KSP.

You wouldn't have wobble. Just static stress. You compute forces required to keep the object rigid. In a real rocket, these forces are the various kinds of stress in the parts. These stresses correspond to part deformation. If there is a lot of deformation, you see the structure bend. KSP's simulation is similar. Parts themselves don't deform, but they shift relative to each other as if if they did, because joints have a bit of a slack to them. In a rigid body approach, you assume that deformations are zero. You still have corresponding stress, but the structure doesn't bend under it. This isn't quite as realistic, but if the real rocket bends enough for it to be visually obvious, something went horribly wrong. So for a game, it really wouldn't be a problem to simply always display the structure as if it is perfectly rigid. This has additional benefit. Because the structure doesn't actually bend, you don't end up with various induced oscillations due to PID and thruster behavior. So essentially, you've just killed all of the sources of resonance. So while the model you use isn't as realistic in terms of physics, it gives you result that's much closer to what a well-engineered rocket should behave is. The way you compute constraint forces is by solving a constrained dynamics problem. In general, the problem is difficult, but so long as you deal with it to first order and use tricks like singular value decomposition, it's very manageable, and actually takes up less resources than simulation KSP uses. I've given a talk on that at Havok a couple of months back, actually.

I'm a bit busy with a move right now. I can get the sim done pretty fast, but I need at least a couple of days of mostly uninterrupted free time. I don't think I'll have time to do this properly until early September, but if an opportunity comes up to do this sooner, I will.

Yes, any large structure will wobble. Ever been at the top of the skyscraper on a windy day? There is nothing you can do to stop it completely. What you can do is prevent resonances, because that's the way such oscillations can build up to exceed structural strength. Happened to some bridges in the part. Happens to rocket engines all the time while they are being developed. Problem for rocket overall as well. But it's the sort of problem that can be solved. In KSP, there are two problems. First, devs decided to use Unity's joint system to hold things together. That wasn't necessary, as one can use rigid physics to simulate the rocket, and it would fly like a single solid object. And yes, you can still compute stress on a structure like that, and still waste fewer resources than KSP does. And while yes, there is some realism to how KSP rockets behave, and real rocket would behave much in the same way if engineers building it didn't think it through, with real world rockets we have way more control over how the structure is built, down to which materials are used where, as well as in how the rocket is controlled. This is the second part of the problem. KSP uses a very simple algorithm to keep the orientation of the rocket consistent. It's a modification of the PID algorithm. While it's possible to tune a PID algorithm to play nice with your structure, the PID parameters in the game are fairly generic. That means that oscillations induced by the PID can hit a resonance with one of the normal modes of your structure, and the whole thing will fly to hell no matter how many struts you put in. Anyways, these are some of the major differences. In short, yes, KSP physics is pretty realistic with regards to wobble, but because we don't have the right tools for fighting it, it would actually be more realistic overall to go with a rigid body physics and get rid of the wobble all together. But hey, it's a game, and this is one of the game's challenges, intended or not.

Weight is still very important for airliners. Short regional hops aren't usually so bad. But long range flights operate effectively on rocket formula, and a considerable fraction of their takeoff weight is fuel.

Even with modern computers, solving a proper optimization problem for a real space ship ascent is a nightmare. Two decades ago, this was plain impossible. I think it's probably a case of "close enough for gov't work," combined with tradition arising from where it was best they could do. Keep in mind, all I can test with Euler-Lagrange is if solution is optimal or not. I couldn't tell you how much fuel it actually costs you compared to optimal. In case of KSP, I know it's not much, because there isn't that much variation between an Ok ascent and great ascent to begin with. I suspect, that might be a case with rocket launches as well, and they might just be trying to go for something that's easier to compute, giving fewer places for things to go wrong, as well as something that has worked for decades. P.S. Don't underestimate tradition in aeronautical design. I don't know how much of that they have in rocket design, but there are a number of features of modern airliners that are known to be sub-optimal, and yet they persist purely out of tradition. For example, the forward sweep of the tail stabilizers has been known to give better performance for a very long time. Yet there are very few airplanes like that.

0.1atm is 1m of water. And OP said adapted up to 40atm. So it's not a problem.

You seem to be confusing evolutionary changes, which will take tens, if not hundreds of thousands of years, with changes that happen to a single individual due to the lack of stress on the body. We don't know for sure how much zero gravity effects fetal development, but assuming there are no serious, irreversible problems there, a person who is born and lives in zero-G environment would be no different than the one who simply spent too much time there. Which does generally mean bone density loss and partial atrophy of some muscles. Without conditioning, such a person would not be able to survive in 1G environment. But this will be the case for the next generation, and the one after, with no difference. It won't matter if you have first generation of zero-G inhabitants or the tenth. Over thousands of generations, you can start seeing evolutionary adaptations. But this assumes that there will be evolutionary pressure. If everyone is well cared for, and various zero-G discomforts don't result in mortality, then there will not be much change. If there are survival pressures, then that depends on exactly what they are.

Awesome. What CAD software do you use? And is there a free/inexpensive alternative to start working with? I would like to have ability to design pats in CAD, which would be ready for printing/millilng, but also be able to export them both for use in physics simulation and rendering. If CAD software has ability to build a tessellated version of the part and export it into something import-friendly, like the .obj, that would be ideal. Given a tessellation of a part with constant density, I can easily compute its moments of inertia, and rendering is obviously a snap. Then I can just use something like a simple XML file to "assemble" the parts for the simulation. Alternatively, I can work with CAD files all the way, but that's going to be a lot more work. Still, it will save a lot of time and tears later.

sgt_flyer, an optimal trajectory meets first order optimal conditions. Back when I was starting to try and design an optimal path for KSP analytically, I've checked a few empirical ideas for optimal ascent, and "pitch over" was one of them. I can tell you that it does not make for an optimal gravity turn. It's close, but not optimal. (Specifically, simulation of a pitch-over ascent does not yield action which satisfies Euler-Lagrange equations.) It might very well be, "Best one can do without doing complicated math," but it's not optimal.

Filling suit with liquid might be enough to offset gravity. There hasn't been too much research on it, but indication is that it helps. No guarantees, but that's the best we can do.

Yeah, I think it's been suggested. It'd probably go over better with Solar System mod, so that it shows an actual Earth bellow. But other than that, for publicity stuff, I think it'd be great to get it done in KSP. We need to have some basic design ready for someone to model the sat for the game, though. It needs to be crystal clear that KSP isn't what we're using for simulation, though.

A number of us have been working on cracking this optimization problem at least for KSP. There have been some decent numerical results. I was able to derive analytical solutions for certain stages of ascent, but not the whole thing. But there is nothing even close to a formula for the whole thing. For early ascent, prior to gravity turn, ascent at terminal velocity gives you most altitude gain for fuel consumed. (That's an exact solution if you ignore ISP variations. There is an exact solution that includes ISP variations, but it's complicated.) Late in the gravity turn, when you are flying balls to the wall, there is an exact solution for the trajectory as well. But it's the transition from vertical ascent into gravity turn that's critical, and there is no analytical solution there. Starting with these two, however, you can use numerical methods to patch the early gravity turn phase. I was able to use simulated annealing to get semi-descent results. And I know some people used numerical optimization packages to get really good ascent profiles. Unfortunately, that's the sort of computation that has to be done for the specific rocket configuration, and it takes a while. If you really want to optimize ascent for a specific design with specific payload. It's doable. But it's not something you can build into, for example, an on-the-fly module for the game. It actually kind of is, because small variations often result in escape or re-entry. But it's far from impossible if you know what you are doing and have some patience, yes.

We need simulation as a design tool. If you have a full RCS package, you can design control software around any CoM and moment of inertia tensor you end up with. But if you want to rely on magnetic torque, these are very important factors. I can tell you right away that orientation of principal axes will be critical. But I couldn't tell you without simulation how well that will play with shifting center of pressure on solar panels. Torque is one thing, but if you get an unexpected tumble, it could be really bad. So I'd hold off on actual physical layout. We should definitely be talking about what components are actually needed. So far, I have penned down main board with CPU, additional memory, GPS chip, and amps/drivers for any sensor/actuators; 6 square coils, one for each side, to provide magnetic torque; two cameras, one forward looking, one for the experiment; transceiver, probably an S-band; solar panels and a small battery; and a bunch of sensors. We can probably use off-the-shelf thermistors for board/frame temperature, some accelerometers to get rough values on rotation, magnetometers for rough orientation, and maybe some light sensors for sun/horizon detection etc. And, of course, depending on experiment, there could be a whole host of additional sensors. Precise temperature, pressure, humidity, oxygen, CO2, etc. There is a lot of room for improvement in each category, however. And that's going to be the hard part of designing things. If you can think of anything I'm missing, let me know. But this should do for basic operations. The design will mostly include figuring out which of the above will be on the main board, and which we will wire, putting together a frame to hold it all together, and lots of testing for just about everything. It'd be nice to try and build a frame in a comparatively inexpensive way, because I'd like to drop a few mockups from different height and record damage vs acceleration experienced on impact by accelerometers. (Accelerometers and off-the-shelf CPU/MPU to do the readings are cheap enough to sacrifice.) I have been looking at some 3D printers, but I still haven't looked up how reliable 3D printed plastics would be in space. On the other hand, it's just the thing for mockups and rapid prototyping. So hopefully, by winter, we'll have that option for testing things. Oh, and you've mentioned organizational aspects at some point. I'm looking into ways of getting everything more organized.

No idea. And I'm sure that it's something that's going to be very different from vehicle to vehicle. I think the best we can do is get maximum acceleration due to vibration from the launch providers, and make sure the cube can survive that. As well as making sure there aren't any nasty resonances. The later would have to be simply tested for. And yeah, I can get at least some base results quickly and start the thread with some numbers, etc.

For LEO, you don't really need NASA-grade precision, and I'd be more comfortable working with my own code. It's not really all that complicated, either. The equations of motion for the orbital elements with reference ellipsoid are known. So are the reference ellipsoid parameters for Earth, and it's going to be easy to add all of the other relevant forces as well. Just leaves integration, which I can do using an implicit method and a short enough time step to be almost perfect. Shouldn't be worse than what they used during cold war for ICBMs, and I call that good enough. I can check my results against NASA tools and/or orbital elements of a satellite that's already up there.

I have no idea where you got that 8,000km figure, but it's silly. At just 3G, you need less than 1,000km. Launch loop doesn't have to be equatorial, either. It's with chemical rockets every few m/s count. With launch loop, extra 400m/s isn't a huge deal. But hey, that's just one example. The big picture is that we either figure out how to make launch to orbit cheap and routine, or we are screwed as a civilization. There aren't any alternatives. Right now, launch loop looks like the most plausible of known options. And we'd need several at different latitudes and in different countries to make access to LEO convenient. We might figure out a different way to do this. But whether we find a way to push off the ground, or find a very cheap way to do reaction drives for space launches, we will need to be able to launch to orbit from multiple locations around the world at a reasonable price. And that means reasonably priced suborbital flight as a consequence. Maybe we won't get there. Then we'll suffocate on this planet and become extinct sooner or later. And that's a good enough reason to try in my books. And if economical interest in suborbital flight is going to be the thing that helps us get over that barrier, so much the better.

I tend to agree, but I really think we should talk to some bio people. Because at this point, we still don't know what we can actually do, and what type of experiment wouldn't be a total waste of time. I like propulsion ideas because it's something I can understand, and where I can gauge feasibility fairly well. Unfortunately, so far, the safe, doable experiments are boring, and interesting experiments, like teather, are very complex mechanically, meaning that it's very unlikely that we'll be able to pull them off with the first run. That's the main reason I lean towards bio experiment. But I'm still looking at propulsion options. In any case, I think next stage should be simulation. I've realized that I'm not entirely sure what the requirements for various missions are going to be, so I'm not sure how to properly budget solar panels, etc. This is the sort of thing that can be resolved with simulation. I'll write a simple orbital elements integrator that assumes reference ellipsoid for Earth gravity and supports things like magneto-torque simulators. I can make it work with off-the-shelf 8051 emulators, so that software can be tested on the same platform. Edit: I'll set up a GitHub repo for it as soon as I have some basics down. I'll definitely want someone else to look over the mathy parts of the code to make sure I didn't leave anything out.

It's not about energy. If you could shoot a suborbital out of a cannon, it'd be really cheap. I've done a rough estimate, and LAX to JFK (Los Angeles to New York, about 4,000km) requires mass ratio of 1.35 under glide ratio of 7 and ISP of 3,000s at mach 2. These are the rough numbers for a Concorde. In practice, it's a bit more due to takeoff and landing. But this is a good baseline. In contrast, the same suborbital trajectory requires ground velocity of 5.4km/s (e = 0.72). Add 1.5km/s for atmosphere, and you need 6.9km/s for the launch. Even with LH2/LOX rocket, that still gives you mass ratio of 4.8. So that's really expensive. But only because we're using a rocket to accelerate the suborbital craft. Using, say, a launch loop, the same suborbital flight can be done for peanuts. 5.4km/s is just 4kWh / kg. In contrast, the 0.35kg of kerosene above would yield 3.9kWh / kg. So with a launch loop or similar tech, suborbital flights suddenly become quite competitive. Of course, that only makes sense if you are going to be building a launch loop for orbital launches anyways.

Yes, that might be useful, but as Rakaydos points out, it'd probably be better to have a new thread for it. This one was fishing for ideas. I think we are ready to do hard planning for basic mission, and that requires a different introduction with some more specifics. I'll need some time to go through this thread once more time, pull everything back together, and maybe get a few more ideas on components. I'll start the new thread once all of this is in order.

First things first. Such events are predicted to happen. A neutron star with sufficient angular momentum can be past the gravitational collapse limit for a static object. And they do slow down because they lose a lot of energy due to electromagnetic and gravitational radiation. When it slows down sufficiently, it will collapse in an event known as blitzar. We do have observations of events that match blitzar hypothesis, but no confirmation yet that this is the actual cause. Next part is slightly more complicated, but the key is to understand that while location for event horizon is defined only by the mass, angular momentum, and charge of the black hole, it's not until well into collapse that the horizon appears. The collapse starts simply because gravitational forces overcome various sources of repulsion in matter. Before the event horizon forms, could you spin the object back up to revert collapse? In principle, yes. At least, partially. The hard question, one which I don't have an answer to, is what happens to matter that has already become more compact than neutron matter. There could be some intermediate states, such as quark or strange matter. Whether these will remain as such, expand back to neutron matter, or continue to collapse, I don't know. This could lead to any number of outcomes from most of the star collapsing anyway, to it exploding instead. Of course, since there is no plausible way to supply required angular momentum anyways, this is purely academic. Completely separate is the question of what happens if we supply angular momentum once the black hole has formed. At first, not much interesting happens. You will, of course, have a Kerr black hole, which has a more interesting event horizon structure than Schwarzschild black hole, but real black holes are already going to have angular momentum and will already have that feature to some extent. There is, however, an extreme amount of angular momentum that a Kerr black hole can hold and still be a black hole. As the angular momentum increases, the size of the event horizon shrinks, until at some point, it goes away completely. Such an overextreme Kerr solution becomes a naked singularity. What happens from there is not known. Kerr solutions are known not to be stable in the interior of a black hole or in the naked singularity case. But what that means is subject of some debate. There could be another solution for overextreme angular momentum, which still includes an event horizon. Or there might be one that truly does present a naked singularity. Or the singularity itself can be unstable, emitting all or part of its energy to shed excess angular momentum. Note that this can happen without violations of cosmic censor in a way similar to black hole evaporation. In any case, it's clear that you will not be able to reverse the collapse once you have a black hole. But it might be possible to destroy a black hole by making it spin too fast or create a new, completely different kind of object.

Something like that.