K^2

Equilibrium point between two planets is unstable. There might be a stable halo orbit, but you definitely can't just put a station in the middle.

Something like that. The main goal is to allow a novice pilot to fly a faithful sim or RC model. When you set the trim on a real aircraft, what that really does is change the neutral position of the controls. Instead, I have the pilot use a control stick that returns to predefined neutral position corresponding to 0 input. The system maps pilot input (-1, 0) to (-1, x) of the control surface and (0, 1) to (x, 1). I use linear mapping for both regions at the moment. So x corresponds to the trimmed neutral position of the surface, and the whole problem is to determine a good value for x for each of the control variables. This leaves the question of what is a good value? I am looking at 3 control surface groups (rudder, elevator, and ailerons) and the throttle. Each one has slightly different requirements, but rudder and ailerons are easy and I have them working flawlessly. All they have to do is make sure your turns are coordinated without pilot having to actually touch the rudder controls. Elevator I found to be the trickiest. Effectively, the airplane should be stable at whatever angle of attack that it happens to be at the moment. Throttle is slightly easier. It should be set to provide enough thrust to offset the drag. In practice, what this means is that if you let go of the controls, you are in level flight (or constant rate turn). If you want to speed up, you pitch down a bit and let go of controls again. If you want to descend, you pull back on the throttle, and letting go of controls will have the aircraft level off again. This should make takeoff, flight, and landing a piece of cake regardless of the aircraft performance. At the same time, if you want to perform a more complicated maneuver, the system provides no additional restriction beyond what the aircraft can do. My initial thought was simply to find values that balance forces and torques at given speed, but what happens is that response never catches up with the system. So say I wanted to slow down a bit. I pull back on the stick and let go. The neutral position tries to balance forces, but there is just enough of the pitching motion left over for it to continue pitching up, slowing down, and eventually stalling. Or vice versa. If I pitch down, I end up leading the aircraft into a dive. In other words, static stability is easy, but I found no easy way to make it dynamically stable. Obviously, I can just capture altitude and air speed when controls become neutral and PID to that until pilot starts moving sticks again, but this feels very unnatural and makes the aircraft feel heavier than it is. I still feel like there is a much better solution, dealing with the actual problem of stability, but I have not been able to come up with anything satisfactory yet.

I can take a list of parameters for each aircraft. These can include any information about aerodynamic configuration and even some performance data. But that doesn't help me with the model as much as you might think. I don't want to just have a model and PID the aircraft to that model. I want the aircraft to respond naturally to input, as it would if it was trimmed to the correct air speed. I just want the trim to happen automatically. The problem is that correct trim will depend on weight distribution, throttle, bank, etc. This isn't something I can just come up with a table of numbers for. I suppose, I can adjust trim based on deviation from the model, which might not trim it quite right when input is applied, but it should converge to properly trimmed flight as input goes to neutral.

Looks like a good read. I'll go through it in more detail when I have a moment. Thank you. The main problem I was having is that I don't have a particular expectation for how the aircraft should behave with applied input. I only have a model for behavior under neutral input. Specifically, I expect zero net torque and zero net force, corresponding to a trimmed flight. So when input is applied, I don't have a reference model to do the adaptation from. But maybe I'm missing something. Or maybe I could fake a reference model that would work for cases with input. I'll look into it. If you have any other reading you can suggest, I'd appreciate it.

I've been trying to implement something like that for flight simulation for a couple of years now. Of course, it's a slightly different problem there. I want the aircraft to maintain altitude and airspeed if no control is applied, but allow for free control if it is. Essentially, I want it to trim itself without the player having to do anything. Hell of a problem. I've had a few almost working solutions, but nothing I've been satisfied with. It's easier for a rocket in vacuum, but still, if you figure out a good implementation, I would love to take a look at it. Precisely what I was trying to get to.

Extra mass does not improve efficiency. By itself, it makes it worse. Aluminum is added because it releases a lot of energy when oxidized. That energy allows the fuel to burn hotter, increasing velocity of some lighter molecules in the exhaust. This increases the overall ISP of the rocket. Adding uranium would make your SRB perform way worse. All it will do is steal the thermal energy away from the light compounds which are the ones that give you the most thrust.

First, lets look at response to initial velocity, which is what ASAS is really meant to deal with. Suppose, we want to hold x = 0, x' = 0. Instead, when ASAS is tripped, we start out with x(0) = 0, x'(0) = v0. All the L1-optimal controller has to do is kill the velocity. This requires kv0 of fuel for some k. Of course, unless the thrust is infinite, this will result in some deviation to be corrected, which will require a bit of extra fuel if you want it in finite time. I'll look at that in just a moment. PID will follow x'' + 2ξÉ0x' + É0²x = 0. And since solution to L2 problem is critical damping, ξ = 1. Solution to the above IVP is x(t) = v0t exp(-tÉ0). If we integrate ||x''(t)||, we get (2+e²)/e² v0. (Piecewise integration is left as exercise for the reader.) In other words, total fuel consumption is going to be roughly 1.27 kv0, which is, as promised, only worse by a factor of a constant. Now, lets suppose that we simply want to restore from a deviation. Suppose, x'(0) = 0, but x(0) = d. In principle, L1-optimal controller can recover from this using no fuel at all. But that's not useful, as that takes an infinite amount of time. Instead, lets require characteristic time of Ä so that x(Ä) is at most 2d/e. For L1-optimization, this really means that total recovery time is eÄ/(e-2) and, ignoring limitations of finite acceleration, the total fuel required is 2k(e-2)/(eÄ), or roughly 0.53kd/Ä. This time, PID responds with d (1+tÉ0) exp(-tÉ0), where É0 = 1/Ä. This gives total fuel consumption of 2kd/(eÄ) or roughly 0.74kd/Ä. Again, the consumption is higher by a constant factor. And since in both cases fuel requirement goes to zero as deviation goes to zero, for any finite epsilon there is a value for d which makes the difference between the two less than epsilon. So all in all, PID will consume 39% more fuel for a given deviation in attitude and 27% more fuel for a given deviation in angular velocity. This is not all together insignificant, but either one is far, far better than what ASAS is doing right now. And while, yes, a well-programmed L1-optimal controller can work better than PID, I'm not sure it's worth the trouble, when simply tuning PID will improve things a whole lot.

Due to conservation of momentum, if you want to change your velocity in empty space, you have to eject something. Whatever you eject is the propellant. It can be rocket exhaust, stream of ions from an ion drive, light from the photon drive, or even the wrench you decided to sacrifice to try and get yourself back to the ship you accidentally drifted away from. There is no such thing as propulsion without propellant, and the quantity of propellant you need for any particular velocity adjustment depends on the ISP of your chosen propulsion method. Fuel is any consumable that provides your propulsion system with energy. The fuel can be chemical, nuclear, or even anti-matter fuel. Or you can have no fuel at all. For example, if you are using a solar-powered ion drive. Bipropellant fuels of conventional chemical rockets are the main source of confusion with these concepts. For starters, your fuel is your propellant. The same stuff you burn for energy, after undergoing a chemical reaction, becomes the stuff you eject to comply with conservation of momentum. Worse yet, bipropellant fuel consists of two components, one of which we usually call fuel and the other oxidizer. So the term "fuel" can mean either the individual compound or the combination of the two depending on context. In either case, fuel is either all or part of your propellant supply. So in general, fuel and propellant aren't the same thing. But for most of the real world rockets it is, so the terms might end up being used interchangeably in many discussions.

That is absolutely clearly wrong. As you said yourself, for a large enough epsilon, almost any controller will work well enough within the entire state space. In other words, for any patch of state space around the target, I can find an epsilon large enough so that PID gives me a solution that is within epsilon of the L1 optimal. If I reduce the patch around the target, I can get away with a smaller epsilon. The epsilon clearly goes to zero as the size of the patch goes to zero. That means that for any given epsilon, I can find a finite patch, including a very small epsilon. The only thing that isn't smooth about the L1 case is the time profile of the output. In all other respects, it is well behaved, and therefore, linearizable. I'm not suggesting we ignore it. I'm suggesting we consider it and we find it insignificant. Compared to the fuel ASAS is going to burn through for attitude hold, the small overhead for initial correction is pretty much irrelevant. PID isn't going to perform immeasurably worse than a proper L1 controller. It will perform worse by some factor. (Would you like me to show the math?) In the grand scheme of things, PID will perform almost as well. Except that you can't have a steep change in reference attitude. Once you turn on ASAS, your current attitude becomes your reference. That means that your initial condition already has correct orientation. Just not necessarily the correct derivative. Which is no longer linear. Of course you do. Say your reference is almost pi from current attitude and you are rotating rapidly away from reference. Should you be trying to slow that rotation down? Of course not. You are much better off continuing with rotation you already have, rotating past pi, and wrapping around to reference. Linear controller cannot handle that sort of thing. That's why periodic state space automatically means a non-linear controller if you want to handle general case.

Arbitrary epsilon. Means you are free to pick epsilon as small as you like, and I can still find a patch of deviations where a PID controller will operate within that epsilon of L1 optimum. The patch might be very small, depending on how strict you are with the epsilon, but in practical sense, so long as you only need to maintain the attitude, PID controller is good enough. But that's a completely different problem. We are talking stock ASAS here. Not an auto-pilot solution. Yes, you occasionally end up with ASAS having to fix a large deviation from course if, for example, you had RCS turned off and then you turned it back on. But this isn't really what ASAS is meant for. It is meant to maintain attitude, which means that if deviation is great, there is a more serious problem. And for small deviation we are back to not needing anything other than PID. Rotational problem over principal axis with constant moment of inertia is still not linear. It's a problem with periodic condition. It cannot be linear by very definition. To get a linear problem you must assume that deviation never increases past pi. If you want to consider here the most general case, where desired state vector can change suddenly, you cannot guarantee that, and your controller must be capable of looking after the periodic condition. Of course, if you agree with me that ASAS is never meant to do any of that, and it's only meant to look after small deviations, then we are back to a linear problem. Moreover, for small deviations, even if you aren't aligned with the principal axis and your moment of inertia tensor changes in time, the problem is almost linear. (Infinitesimal rotation operators commute, unlike finite rotations.) It seems like that would cost you the maximum torque you could apply. I'd use SVD method to get the input vector of RCS thrust values from desired output vector of net torque/force. Again, this optimizes fuel in L2 sense, but if we are going to use it with a PID controller, that's precisely what you want.

For this sort of thing, definitely look for a reflector (Newtonian). Beyond that, I'm afraid I can't help much.

You can chose Kd to give you critical dampening. That gives you optimal L2 efficiency, which as I've explained earlier, is as close as you are going to get to optimal fuel efficiency with PID. And what do you mean you can't account for authority? You compute the moment of inertia and you compute the torques from thrusters. Then you can get optimal input vector with an SVD.

NOX is not a bad alternative, yes. But availability varies by country. In the States, it's relatively easy to get from car mod shops, as it's used for the nitrous boost. In some places, however, it is outlawed for that very same reason.

Kryten, you wouldn't use pumps for a 400N engine. You should take a look at how the anti-aircraft missiles have been designed. They have roughly the same design parameters. Relatively small, high thrust-to-weight ratio. The liquid fuel ones have always used pressurized pumps to keep the rocket light and less likely to fail.

There is a way to derive all three terms based on ship's moment of inertia (roughly proportional to ML² of the ship) and desired response time. I can do a write-up, if you guys are interested.

Right. And because LOX is denser than kerosene, it does actually work out to about 210ml of LOX for 100ml of kerosene to get the desired 3:1 ratio. Controlling such flow ratios, on the other hand, is not going to be exactly easy. These fluids will also have different viscosity, so getting flow rate from given pressure differential is not going to be exactly trivial. I wonder if there is some feedback mechanism you could design that would automatically ensure fuel-rich mixture... Electronic control is always an option, but you'd need some rather interesting sensors to figure out exactly what's going on with the mixture. There are flow rate sensors on the market, but they are typically designed for completely different purposes. At the end of the day, you are probably looking at a trial and error approach.

I understand the whole L1/L2 difference, but it's really most relevant for big corrections. For a small enough correction, a controller that optimizes an L2 integral will optimize the L1 integral of the same quantity to within a desired epsilon. That's why I'm saying the PID is nearly optimal for what it needs to do. Most of the time, it only needs to make small adjustments. If your attitude is 90° off what you told ASAS to hold, you probably have bigger problems right now. Similarly, control of the rotation of a rigid body is not a linear problem even if you are optimizing an L2 quantity. But again, it is only non-linear for large deviations. For small deviations, it is perfectly linear. So a PID controller should still be very good at optimizing fuel use for small corrections. The other big issue is that right now the PID controller applies the same input on all the thrusters. That means it wastes a lot of fuel on accelerating the CoM, which it isn't meant to do. There should be a zero net force constraint on the input space. That's really the first thing I'd solve. It would improve fuel consumption and make docking easier.

Black hole doesn't work as a gravitational attractor. It's a far more complicated object. Still, simulating small amount of matter traveling near a single black hole is relatively easy. You use the known solution for the metric and then it's only slightly more complicated than doing ordinary orbital mechanics. It's still a bit more complicated because you are doing things in 4D and there are some extra issues with numerical integration. But it's straight forward enough. On the other hand, if you have multiple black holes or something really heavy falling into one, the problem becomes very, very complex. Not only do you have to solve for motion of everything, but you have to solve for metric that is caused by all of the stuff moving around. Equations for metric are non-linear tensor equations, so solving them precisely is tricky and takes up a lot of memory and computing power.

It should be very close. RP-1 will give you a slightly better ISP, but it makes very little difference for fuel mixture. Though, I'd definitely recommend seeing if you can get some Jet-A. It's not quite RP-1, but it's better than your typical technical uses kerosene. 3:1 LOX to fuel is just slightly fuel rich, so it sounds about right. One more reason to run slightly fuel rich is because it will help prevent the metal in the combustion chamber from burning away. If you run oxidizer rich, that will be a serious problem. If you run balanced, it can still be a bit of a problem, because you'll never have perfect mixing. P.S. This thread is also making me think about building a small rocket engine. I'd probably go smaller, though.

Hence the "nearly optimal". Point is, I don't think a more advanced controller is needed. The real issue is that KSP's PID controller has the one size fits all parameters. If parameters are going to be computed for each ship, it should be good enough.

Actually a PID with critical damping is near optimal for fuel efficiency. Of course, that's provided that you also have a way to balance thrusters. I have illustrated elsewhere, probably in a thread that got "eaten", how to compute optimal I and D terms. I can also go over a balancing scheme. I probably should sit down and write an ASAS module for KSP. I've done something very similar for missile guidance system for Garry's Mod. I had intercept missiles lead and hit most targets without any problems using all the same controls available to a rocket in KSP.

Yeah, aluminum is pretty easy to melt. That's why the airplane's frame is built of aluminum, but engines aren't. Alloys are always easier to melt than any component as well, so that makes it even worse. Personally, I'd go with steel combustion chamber and a carbon nozzle. (You can buy a carbon crucible and grind it to the right shape. You can find these for under $10 around here.) Failing that, make everything out of steel. It will still burn through, but hopefully you'll have time to run the thing. Where are you getting the 1.5 ratio from? Are you by any chance using the molar ratio here? Kerosene is pretty close to a (-CH2-)n, which does burn with oxygen at 2:3 ratio. But that means the mass ratio is going to be something like 14:48. You need almost 3x the LOX by weight as you do kerosene. LOX is a bit denser, though. So by volume, you are looking at something closer to 18:42. Still more than 2x the difference. I might be wrong here, though. The above numbers come from stoichiometry. It is possible that it is not optimal for a rocket engine. (Though, I can't think why it would be so.) Do you have a source for the 1.5 ratio? Other ratios will burn cooler, but it will also give you a lower ISP. In other words, you'll waste more fuel to get the same thrust. Might not be a big deal, though, and depending on materials you settle for, it might be worth it to run mixture a bit fuel rich just to avoid burning through the combustion chamber.

Right, at 14 bar, kerosene, and 400N, I wouldn't even bother with the bell. Get the nozzle diameter for desired thrust at your desired pressure and just regulate flow rate with tank pressure. Should be a simple enough build and you won't have to worry about overpressure. Though, it can still resonate and explode, so don't let your guard down. As far as maintaining tank pressure, you are looking at a flow rate upwards of 130g/s. That's 100g/s (~90ml/s) of LOX and this will soak up about 20kJ of heat if you let it boil. So heating tanks is probably a no go. You'll have to pressurize them with an inert gas instead, as someone has suggested earlier in the thread. Now, for pressurizing tanks, nitrogen liquefies before oxygen does, so it's not going to work in the LOX tank. You are pretty much limited to a light nobble gas. Helium's expensive, but you should be able to get away with something like neon, which is cheaper. Kerosene tank, of course, can be pressurized with nitrogen gas, but it might be easier to use the same gas for both. The only tricky part is maintaining the desired pressure in tanks. The best way to go about it is having a small, high pressure tank with the inert gas and use a regulator to reduce it to 14 bar, or whatever. First stage regulator for Scuba will typically give you something in the 5-10 bar range. You might be able to adjust one of these to go up to 15 bar. A used regulator can be bought for very reasonable prices on-line. I've seen entire octo sets for under $40. I'd never recommend buying something like that for diving, but for an amateur rocket engine it's still probably going to end up the safest part of your rocket. Edit: You are way past melting point for 6061 T-6. You are looking at nearly 3,000°C under optimal mixing ratio. This particular alloy will melt at around 600°C. You should consider other materials.

For a small rocket, I would go with a blowtorch design. Tanks are heated up by the engine and generate their own pressure. Of course, you need tanks that can actually hold 14 bar, then, but for LOX you probably want that anyways. BP temperature at 14 bar is quite reasonable for both. Make sure you have relief valves, though, or you might have serious problems. And I hope you are good with thermodynamics. This thing is not easy to design to make sure it can maintain the pressure at correct flow rates nor exceed the maximum pressure. Then again, if you don't know how to do these things, you probably shouldn't be building a liquid fuel engine either. These things tend to explode for very similar reasons. The more classical solution is a centrifugal pump, but these things don't scale down very well. Also, heavy, pressurized tank is a much greater disadvantage for a large rocket. So pumps make sense there. For a small rocket, it's more trouble than it is worth, generally. If you do go with pressurized fuel, you might also consider switching over to liquid propane. The main reason Kerosene was used in V2, etc., is because it is liquid at ambient pressure. You don't need that feature with pressurized tanks. If you do end up actually building this thing, make sure you have a proper bunker for testing and that you can fire it up and kill the fuel flow remotely. If you actually get the sustained burn, the main failure mode for a rocket is a catastrophic explosion. And liquid rocket means metal parts that become shrapnel. This means you can't be just standing a few meters away or have a bit of plywood in between. That won't protect you. If you have nothing you can use as a proper bunker, at very least, dig out a ditch and make sure there is no line of sight from the engine to you, any other person, any houses, etc. If you need to watch it, get a web cam set up nearby, or something.

It's not measured directly. Yet, if there was any ionizing radiation, you'd expect to see evidence of ionization, like high concentrations of H2 near the surface. On the contrary, we see even lower levels than expected.