K^2

Internally, orbits are going to be defined by the constants of motion, which are the time of periapsis passage (β1 = T), longtitude of ascending node (β2 = Ω), argument of the periapsis (β3 = É), energy (α1 = E), z-component of angular momentum (α2 = Lz), and total angular momentum (α3 = L). The convenience of using these internally is that they are constant for orbit around perfectly spherical mass with no other forces present. And when other forces are acting on the satellite, I only have to account for these in computations, dramatically reducing any errors. There will be methods available to set and grab current values for all of these. Additionally, I'll have methods for setting (when appropriate) or getting some of the related quantities. Semi-major axis (a), eccentricity (e), inclination (i), mean anomaly (M), true anomaly (v), and current radius ®. The last three will be available based on current simulation time (t). If you need references on any of these, there is an article on Wiki on Orbital Elements. I think, my notation is consistent. Because it is convenient to keep time in seconds, and I don't want to bother with dates internally, I propose using Unix Time. So long as it's a double, there should be enough precision. You can assume that you'll be able to just call a function to get any of these. What's irrelevant within simulation, and with which I will certainly not bother for now, are things like orientation of the reference plane and reference direction. For geocentric orbits, reference plane is just equatorial plane, so that part's easy. But reference direction is the first point of Aries, which moves with respect to Earth's surface. So that's going to be important when converting to/from GPS coordinates. Ideally, once that's working, it should be possible to take satellite's trajectory and plot it over the map of the Earth to get something like this. Keep in mind map projection. I see no reason to do anything other than equirectangular, but most of the maps you'd find on-line are Mercator. It's a trivial conversion, either way. Oh, one more thing. Altitude. Like I said above, radius will be computed, since it's relevant internally to how forces are applied, but altitude above MSL will require computing radius at MSL, which varies. It's probably good enough to just use geoid for that, since MSL only varies by a few meters with respect to that. But you'll need to dig up some sort of parameterization for geoid to make that work. If you don't want to bother, I'll probably get to that eventually, since altitude is relevant to drag estimates.

You mean the "contamination" clause? Anything that's going to disintegrate in upper atmosphere upon inevitable re-entry within a year from launch and has zero chance of spreading anywhere does not violate Article IX. There have been a number of satellites with living organisms launched with absolutely no contest. (Edit: There are a number of other regulations based on safety and ehtics of using organisms for scientific research, and they are all fine with use of plants and invertebrates.) Simple centrifugal deployment involves fewer moving parts. Given that budget will be constrained, we need to go with the simplest system.

I found what I was looking for in terms of using constants of motion for central potential as the canonical coordinates of perturbed potential. I'm going to write a 2D proof of concept, verify it in Mathematica, and then make sure that it actually gives me better results than simply integrating coordinates. By the way, just a reminder, all of the coputations should be done in double-precision.

Simple math. Look at where I got 18,000g from. Take a real rocket that can survive higher acceleration, plug in that rocket's length equation, and watch how you still get acceleration that it cannot handle. It's really not that complicated. You cannot accelerate two rockets off each other to required velocity without overloading the structure.

I think, KSP is more of a reflection of latent interest that's there and needs to be reawakened in general public. The game itself won't do it. It's one of the things that helps, but it's not going to be the thing that changes everything. Neither will any other game.

Depends on air speed, exhaust speed, and engines. This particular concept is definitely example of how not to do it, however. But everything about it is flawed from aerodynamics perspective. The 30T lifting capacity they claim is absurd with that fan arrangement as well. The power requirements will be huge, but a bigger problem will be ~140m/s exhaust speeds in hover. You really don't want extreme hurricane wind speeds while trying to load cargo. In horizontal flight, this can be dialed back, but the rear fans are still going to be experiencing much stronger relative wind. And without variable pitch blades, it's not something you can deal with efficiently. And that's on top of poor glide ratio such a configuration will have, bringing back fuel efficiency even further down. I'm pretty sure it's vaporware either way, intended only to siphon investment money.

Oh, we definitely need some bio experts on board for this. It's a big part of why I'm hesitant to settle on any particular design. I just don't know how much requirements can change after the bio expert comes in and says, "Well, this is a waste of time. Here is what you actually should do..."

Bad idea. Pure CO2 is toxic to most modern plants. There are probably some algae that can process pure CO2, but not higher plants, which will be of interest here. The container needs to be filled with typical air-like mixture. Probably a bit on the humid side. We could run it a bit CO2-rich, but I don't know if that'd be most productive in terms of data utility. Running Earth-like CO2 concentrations will allow us both a better comparison to control on Earth and data closer to conditions in which someone might use plants for oxygen regeneration on an orbital station.

Loading screens are a product of technological progress, not the other way around. NES and earlier cartridge games didn't have one, since RAM wasn't used to hold resources. Only state variables. Many of the early PC games didn't really need one either. Loading screens emerged as games and technology running them got more complex.

The 25m was the length used to compute acceleration. If you reduce length, you increase required acceleration by the same factor, so the total stress on the structure remains constant. This is NOT the case of square/cubed law. This is a constant relationship. No matter what length you make the structure, you can't get materials that can withstand acceleration required for two rockets to accelerate off each other. Yes, if instead of two rockets you have rocket and a long rail/barrel, it's a different discussion. But it's not what we're talking about.

For starters, all of this will be wrong, because by 0.5c, you are dealing with relativity. But ignoring relativity, ta = vt / a. Then you can use the tt to be whatever you need to get the total distance traveled.

Are any of these 25m long? You can have individual components that survive this acceleration, but the structure isn't going to take this.

Take pure equatorial launch. That's 465m/s of surface velocity, and lets take 1.5km/s for atmo/gravity losses. You need about 8km/s to launch to a 400km LEO. So the total delta-V is about 9km/s. Direct launch to GTO is about 10.3 km/s. So that's 11.3km/s of delta-V. LEO Falcon 9 v1.1 mass ratio is 38.5. With delta-V of 9km/s, that gives us effective ISP of 251s. GTO mass ratio of v1.1 is 104.3. With delta-V of 11.3 km/s, that gives us effective ISP of 248s. Given that I've used less precision in my math above, both of these numbers are equal. Falcon 9 is equally effective in reaching LEO and GTO.

I was thinking of having one face of the cube open, to expose the pressurized vessel to sun-light. Glass should block most of the UV, so you'd get natural sunlight for 45 minutes out of an orbit.

In principle, two is doable, and three is pushing it. But I don't think we need that. The spin axis will be pointed towards the Sun, which means that all four panels will be at 100% illumination. That's more that most cubesats ever need. In fact, with this in mind, we might not even need four full panels.

Agreed. But I think we should get some more specs down. Naturally, internals won't matter, but we need to be absolutely set on experiment and know power requirements before we know what sort of panel arrangement to use, for example. Cube + panel arrangement will give the most obvious features of the sat. I like the idea that someone put forward earlier of having four side panels that open up due to centrifugal force once the sat spins up. That would give the sat a very nice look, and would be easy enough to replicate in KSP. Once we have CAD-ed parts, we can export these into KSP parts and make it look almost perfect. That + Sol mod should make for a great publicity video.

OpenGL is a bit finicky on Windows. Also, shader support on DirectX is better, and I have some working Earth-rendering code based on data from NASA. But it's more important to get non-visual aspects of it right. I think, it's going to be easiest to simulate everything on the level of physical elements. I'll look into it in a bit more detail, but there is a lot of code like converting GPS coordinates to and from orbital elements and time, etc. Things you need for interfacing with the simulation that aren't necessarily visual. That would probably be a better place to start. And if it has to run from command line for now, that's fine. So long as you can do things like query current location of the sat, tell the time to advance, query again, etc. There are two parts to it. One is for torques and rotation. That's pure Euler mechanics. There is nothing fancy there. The integration needs to be decent, but the sat will need to be able to correct for any drifts, so small numerical errors here aren't a big deal. The second part is satellite's motion around the Earth. That stuff will be derived from Hamiltonian mechanics, yes, but by the time things like drag forces enter (or thrust, if we get to that), it will be just a set of differential equations to integrate. Now, this part's tricky, because we want to guarantee that integration isn't the weak link. There are also two options here. I can either simulate Newtonian physics + corrections from gravity treated as inertial forces. (That's what KSP does, but I'll have corrections due to non-spherical Earth in there, plus, much better integration routines.) Or I can convert real forces on the sat to be taken into account in differential equations for orbital elements. I think, the later is more precise, because a lot of "hard" integration is actually the analytical solution for classical orbit + perturbations. So I feel like numerical errors will be much easier to control. But I'll have to read some orbital mechanics texts to refresh my mind on it. In either case, the first step will be testing pure physics part against data from a real satellite. And yes, I agree with Mazon Del. We won't know how long this will take until we're well into development, and have some hardware specs to play with. But basics we can probably put together soon-ish.

Absolutely. When building a home-made rocket, your assumption should be that it will explode. And that it can happen at any time. Do not use metal parts. They generate shrapnel. Do not be anywhere near the launch pad or intended flight trajectory. Make sure you can take shelter if it deviates from intended trajectory. Make sure that anyone within range knows to do the same. Property damage and fire hazard should also be kept in mind. Most importantly, if you don't have a lot of rocketry experience, I suggest finding someone who can help you at every stage, at least with some advice.

C++. And yeah, this would go faster as a team effort. I suppose, I can start writing short snippets of computational/physics critical code if you want to jump onto writing interface etc. Ideally, I'd like to split the integration into the core code that's completely platform independent, and which we can turn into a DLL that can run on anything, and the shell with various UI, logging, et cetera, which would be written for a specific platform. That way, for example, if I'll want to do rendering with DirectX running the same simulation, it'd be easy to do.

I love Kalman Filters. Let me know if you want any help with the filtering algorithm.

Usually, if your limiting factor is weight and complexity, you forego the pump all together, and use a pressure-fed system. Some liquid fuel SAMs are built that way, because they need to be inexpensive, light, and reliable. By the point where pressure feed isn't sufficient for your rocket, you are really worried about performance, and you have to go with a turbo pump.

You don't need anomaly. If you know your angular velocity and distance, you know your angular momentum. If you know your linear velocity and distance, you know your energy. Knowing energy and angular momentum gives you the apsides.

He means that the energy requirement increases quadratically, and consequently, the amount of fuel you need is also quadratic with velocity. There isn't really anything new with this kind of idea. The advantage of a rocket is that you can have reasonable acceleration. Transfer to the Moon from low Earth orbit takes something like 3km/s. If you wish to accelerate a 25m rocket over its length to that speed, you need acceleration of 18,000G. Not only is this impossible to survive, there exist no materials allowing you to build a rocket that can survive that acceleration. As pointed out above, the idea of using a long rail to accelerate the ship is well known. Ideally, you fix the rail onto something massive, like a moon. But for a single launch, you can just use the rail as a reaction system. But we are talking about hundreds of kilometers of rail for a typical launch. It's not something we are going to be able to do practically for a very long time. But if you really want to try and submit this paper, to practice publishing if nothing else, try arXiv. They don't require peer review, and will accept almost anything. Of course, it also means that nobody is going to take it seriously that you have an arXiv publication. (Though, arXiv is used by a lot of serious scientists to allow free access to their work.)

TWR starts off infinite, drops to a value of approximately 2 during early ascent, but then climbs to a bit past 3 as the rocket settles into gravity turn. Once well into gravity turn, TWR starts to drop again. It's somewhere between 1 and 2 through most of the ascent. I think I'll have to go full Lagrange on the max throttle. I can't think of any good way to enforce the limit other than doing formal constraint. So the integral will be [T(h)/(ISP(h)vy(h)) + λ(h)(T(h) - Tmax)]dh. And I'll just have to solve for λ(h) at every integration point.

Not for the 2D case. In the 2D case, vertical velocity is precisely zero both at sea level and at target altitude. Which is precisely what you want from an ascent that takes you to circular orbit. Thrust is still extremely large at takeoff. And that's precisely because initial velocity is zero. In vertical ascent case, it's well known that thrust needs to be infinite to bring up ascent velocity to terminal instantly, thereafter settling on TWR of 2:1. The results I'm getting agree with that. Rocket blasts straight up, achieves terminal velocity, then starts to pitch over to initiate gravity turn. P.S. Lets forget all the terms that obviously aren't going to contribute to an infinite result. Ty(h) = v'(h)v(h). Yes, v(h) goes to zero as h goes to zero. But v'(h) can, and does, diverge. Precisely at zero, the result is actually undefined. But there is a limit. And lim Ty(h) as h goes to 0 can be zero, finite, or infinite. In this particular case, it does happen to diverge to infinity. At h very small, but above zero, I get a numerical result that's finite, but very large.