K^2

@Syntax Hm. I'll take a thorough look in the evening. There's always a chance that I made a mistake somewhere. Can you give me the parameters you've been using, just to make sure I'm reproducing exactly the same thing? I was kind of considering adding a graphical plot of the orbits and the solution, but it seemed way beyond the scope. With debugging considerations in mind, however, it might be worth the extra effort.

The focus is at the origin. The polar form used is r(θ) = a (1 - e²) / (1 + e cos(θ)). So r(θ) is minimal at θ = 0, corresponding to periapsis. This is then cast to Cartesian coordinates, matching θ = 0 to the positive x axis, and keeping the ellipse in the XY plane. The transform components tx and ty are then used to rotate the ellipse in 3D to match orbital elements, keeping the focus at the origin. As an aside, you can quickly convince yourself that r(0) + r(π) = a (1 - e²) / (1 + e) + a (1 - e²) / (1 + e) = a (1 - e) + a (1 + e) = 2a. Or in other words, sum of periapsis and apoapsis is twice the semimajor axis.

@Syntax max2d currently returns just the distance. You can modify that function to return x and y at the same time. These are true anomalies of first and second bodies respextively. You can feed each one in turn to the position function with corresponding parameters if you want the cartesian coordinates. So position(tx1, ty1, a1, e1, x) should do the trick for the first body.

Ion drive is advantageous at high speeds you need to sustain glide in thin atmosphere, and disadvantageous at low speeds of a thick atmo world. Even in the frigid cold of Titan, there are simpler and way more efficient propulsion methods. And battery weight is a huge factor. Conventional propulsion methods on Mars, in contrast, would require very large moving parts on delicate, large wingspan glider. Ion drive actually benefits from large wingspan and rarified gas as medium, and does not add a lot of extra weight to the glider, making it viable despite some loss of efficiency. Mars is about as close as it gets to best case for an ionocraft.

There are demos with flexible wings that are just as silent, but have way better flight characteristics in just about every way. I don't think we'll find any real uses for something like this on Earth. Bill Phill could be right about space exploration. Though, I suspect low density atmospheres, like that of Mars, are a better place for it than Titan.

Kugelblitz or bust!

I wrote it in ES6-ish JS, and I figured I might as well wrap it in HTML so that you have an immediate use case.The HTML portion of this is not compliant with anything, but it should workTM on most browsers. The JS portion can be made a lot cleaner as well, and I didn't bother with variable names that much, but it's functional. Keep in mind that the two optimization functions I've written are not terribly generic. That said, this isn't a terribly generic kind of problem. The input parameters are the standard orbital elements for each of the bodies. Semimajor axis can be specified in whatever units you want, so long as they're the same. The distance reported will be in the same units. AU would be a good choice for Solar System. Eccentricity is just a number in [0, 1) range. The three angles should be in radians. You can add conversion from degrees to radians inside the compute() function, where the values are extracted from input fields, if this makes your life simpler. I used radians because that's what Math library expects. Anyways, just paste this mess into the editor and save it as an .html file. No error checking, so make sure all fields are filled in before you hit the button. Otherwise, should work. Edit: The code's been updated to fix an issue with argument of periapsis, make it more resilient to local maxima, and to add visualization.

It's certainly an upper bound, but not the least upper bound. Most configurations are never going to reach that, even if many will get close to that at some point or another. As an extreme example, more plausible for comets than planets, imagine two orbits with similar inclination that are both highly elliptic, but share argument of periapsis. Their maximum separation will actually be between apoapsis of one and periapsis of another. I agree that sum of the apoapsides is a good starting point. If your com system is capable of handling that, it will handle any distance that is going to arise. But if you're trying to cut corners and scrape by on absolute minimum, you'll have to do more math. And unfortunately, I don't think there is a simple formula. I can write down a general equation for distance between two bodies as function of true anomalies, and I can even give condition for the extreme separation, but actually solving for it? Ugh! In contrast, this is a very simple problem for a computer. You're trying to find argmax of a two variable function which will have just a few local maxima, if any. @Syntax I don't know how good you are with numerical methods / code. If you want, I can write you a script in language of your choice that takes orbital elements as inputs and spits out max separation and relevant parameters for it. If that does you any good, it shouldn't take me more than half an hour to write.

You can have the definitions of rocket parts given relative to arbitrary origin and include CoM relative to that origin. But for run-time, I would move all relevant coordinates to be relative to CoM, so that CoM is your origin. Having CoM at (0, 0, 0) makes a lot of math WAY easier. For starters, locations of your engine CoTs are your moment arms for torque. If you do this, the entire state of your rocket is given by these 6 vectors, all in world coordinates: Orientation of Rocket's X axis. Orientation of Rocket's Y axis. Orientation of Rocket's Z axis. CoM location. CoM velocity. Angular momentum. If you look up how transformation matrices are done in video games (there tends to be more good literature on that than simulations), 1.-4. basically give you the rows of the matrix that transforms vectors in rocket's coordinate system to world coordinate system. (The last column of the 4x4 matrix is always going to be [0, 0, 0, 1], and is sometimes omitted from being recorded for that reason.) Alternatively, you can split translation and rotation. In which case, 1.-3. give you the 3 rows of the 3x3 rotation matrix. Since you aren't writing for performance, whichever way makes more sense to you is good enough. The update rules for the 3 axes are pretty straight forward. dX/dt = ω x X, and same for Y and Z. Of course, numerical errors will cause norms and relative orientations to drift. So after each step it's useful to renormalize all 3 axes and ensure that they are mutually orthogonal. (E.g, you could just set Z = X x Y, then X = Y x Z. There are cleaner ways, but this will probably do.) The only thing that's missing is ability to transform back from world coordinate system back to rocket's. And you do that by inverting the transform matrix. In general, inverting a 4x4 matrix is a bit of work, but transform matrices are special. The rotational part is an SO(3) matrix, and they are Unitary. So to compute inverse of the rotation 3x3 matrix, just transpose it! The translation bit, 4th row, is only slightly trickier. You negate it, and then using the inverse rotation you've just derived, transform it from world space to rocket's space. And just to save you a bit of confusion, I've used DirectX convention of writing transformation as x' = x M, where M is transformation matrix, x is vector before transformation ans x' is the same vector after. If you prefer to multiply vectors from the right, so that x' = M x, then switch the words "row' and 'column' everywhere in the above text, and the math will still work.

It matters a little. Possibly not enough, but you might as well try to get it as close as possible. For a real rocket engine, this is a complicated question, because the pressure from exhaust is distributed between combustion chamber and nozzle bell. Fortunately, most hobby rocket engines don't produce high enough exhaust velocity to warrant a bell, so you can basically ignore the nozzle. The CoT for these should be at the top of the combustion cavity. That's not going to be quite the top of the motor, since even if you're using one without ejection charge, there will still be a plug at the top. It's going to vary from motor to motor, but about a centimeter down from the top of the plug is going to put you in the ball park. CoT should, ideally, be centered on the axis of symmetry. But this is another thing you might want to add a slight variation to in your models just to make sure that the real world doesn't ruin your model. After all, hobby motors aren't made to that high of a spec. You might want to vary direction of thrust very slightly as well for the same reason. You probably don't need to model an overall effective CoT. You could, but it's probably going to be easier just to apply forces and torques from each one individually. To compute net force, you don't need to worry about CoT at all. You just add thrust vectors from all engines and you have net thrust. For net torque, compute torque vectors from each engine individually, then add them together just like you did with thrust. For each engine, you need to compute the arm, which is CoT coordinate minus rocket's CoM coordinate, call that r. Then torque = r x F for each engine. In terms of recomputing CoT positions as the rocket rotates, you can either apply the transformation matrix to each arm before multiplying, or you can use the fact that net torque transforms the same way. So you can do your torque computations in the rocket's coordinate system, and then rotate it to world coordinates using rocket's rotation matrix. The angular momentum EoM: dL/dt = net torque, works in world coordinates, so you definitely want to have net torque in world coordinates before you do angular momentum update. Once you have updated angular momentum, you need to compute angular velocity by using rocket's moment of inertia tensor, which is in rocket's coordinate system! So you'll have to either rotate angular momentum to rocket's or rotate moment of inertia tensor to world (keeping in mind that you can rotate principal axes like you do any other vector) and use angular velocity in world coordinates to update rotation matrix. Yeah, the rotation bit is quite convoluted, but if you can keep it straight which quantities are preserved in which coordinate system, you should be fine. P.S. If trying to derive Verlet or RK for rotation is too much, you can probably get away with just using Forward Euler method for the rotation part. I've done that in some simulations before, and I can't say I've noticed much difference. Fortunately, most of the types of situations which make FE bad for CoM update just don't arise with rotations all that often.

Excessive current through motor's coils will cause it to overheat, but current is proportional to torque, so effectively, if you don't plan to exceed max torque, you're fine. And the reason you might want a boost for it is that as motor RPM goes up, so does back EMF of the coils. So you get lower current at the same applied voltage. You can boost the voltage in several ways, but that still increases load on battery, and that's where you can bring in supercaps. So yeah, completely viable. And you can even use regenerative braking to recharge them, so it need not be a one time boost.

In places I've seen these in US, they've been pretty shy with people, but they get aggressive when they think they can get in and get out before anyone even sees them. And they're usually right! On a few occasions I've had food go missing, with the last thing I'd see being a brown blur with black stripes disappearing into the bushes.

I think that's a good chunk of it. European squirrels are a lot more shy with humans, in my experience. I've never seen one closer than on a tree branch five meters off the ground, hiding behind the trunk from me as if I still pose some sort of a danger. In contrast, squirrels in N.A. tend to feel pretty comfortable looking for food 3 meters from a person, unless said person starts moving towards them. And that's in suburbs. In some of the more touristy places, where people feed them, they tend to get almost as shameless as pigeons. I've had one come up to me in Boston, and when I squatted to take a closer look, it actually grabbed my hand to see if I have any food for it. Once it saw no food, it got disappointed and left. Can't picture European squirrel pull something like that. That said, in some parts of USA (e.g. Midwest, parts of Cali), Canadian black squirrels seem to be pushing out the gray locals. That seems to be just stronger territorial aggressiveness, though, rather than any special interaction with humans. Unless there is some more subtle adaptation that I'm not aware of.

North American squirrel: European squirrel: So it's not just the squirrel behavior, but entirely different imagery one gets when thinking about squirrels in America vs Europe, especially Eastern Europe.

I can think of a bunch of potential problems with using a sonar on a rocket. There are optical range-finders with 3m+ range. That ought to be better. Lower latency, fewer problems with noise, etc.

Absolutely. Some of the modern digital servos can get a little fancy, but Pulse Width Modulation, which is standard for analog servos, is almost universally supported even by these. PWM is almost trivial to produce, as you just have to turn output pin on and off with the right timing. Duration of the pulse determines the angle the servo will hold. That's it. No fancy code or hardware drivers necessary.

*shrug* No argument in general, but the smallest servos I've worked with just happen to be 9g each as well, and you'll want at least two of these, plus a power pack to keep them running. So you're probably looking at something like 30g and $20+ of hardware before you consider MCU. That still doesn't make cost and weight of Pi Zero trivial, but certainly blunts the impact of going with something smaller. Anyways, without more details, "It depends," is probably the most that can be said, yeah.

It's not just matter of "shown". There is a no-communication theorem that proves that no information can be sent via entanglement. It can, however, be used to "augment" a classical channel. So if you have a way to send classical information, you can use entanglement to send quantum information instead. See quantum teleportation for details.

Seems risky. Your print quality has to be top notch. The kind of cracks I get occasionally in my prints would cause a hybrid engine to over-pressure for sure.

For a simple control loop? Absolutely. But with Pi, you can also be managing video recording and live telemetry (via WiFi if you get Zero W version). Not to mention that you're basically running a full OS, so you can write your control scripts in anything you want, and use full debug suit without having to worry about compiling/assembling code for a particular MCU, and worrying about op counts and memory overhead. Granted, later tends to become moot with modern MCUs, but even then, debugging in viva can be troublesome. Doesn't change the fact that it's overkill, of course, but I also see little reason not to go overkill. Pi Zero is cheap, light enough for anything bigger than an A engine, and very easy to use even for somebody with no experience with programming and flashing MCU. I never tried ATTiny, but I've used to be all about PIC MCUs myself. Tiny, cheap, come in variety of models and packages for every job. But I'm starting to lean more and more towards just dropping a Pi Zero in and having the same tools available as if I was working with a PC. Call it lazy, but for $10 and 9g, I don't mind being lazy. Also, I don't insist that it's the right solution. Just that the fact that it's overkill doesn't make it the wrong solution. @Mad Rocket Scientist That code looks good. Your dt is 0.01 seconds, so that's as precise as you're going to get your answer. You can try reducing dt further, and you should get closer and closer to the analytical result, but whether you need to will depend on precision you actually need from your system.

I've been vague about numerical methods, because there are just a whole lot of methods and techniques that can be relevant, depending on approach, so it'd take me hours to do a proper write up. But if you'll have specific questions, I can probably refer you to specific algorithms that might be helpful.

You can think of it that way in Special Relativity. In General Relativity, you can go FTL. In fact, most of the universe is receding from us faster than light. GR is a bit more complicated. Your first sentence is backwards. Rest mass is the invariant, so that's still in use. And it's not that relativistic mass doesn't make sense. It really does, and a lot of what we call rest mass is actually dynamic at subatomic level. But most modern equations, when they have 'm' in them, refer to rest mass, as that's a more fundamental quantity. So a modern physicist wouldn't write E = mc2. The equation would correctly be written as E2 = (pc)2 + (mc2)2

Pi Zero is definitely viable, and will give you some advantages if you want to get fancy. It's heavier than a stripped-down Arduino, but actually lighter than some devboards I've seen. You don't want to drag them around as 3 different variables. That's a pain. Use numpy. It provides +/- operator overloads that will let you add two arrays as vectors. (Otherwise, tuples and arrays default to treating + as concatenation.) import numpy as np a = np.array([1, 2, 3]) b = np.array([4, 5, 6]) print (a + b) Moreover, you can do np.cross(a, b) to do cross products, and np.dot(a, b) to do scalar products. So that's basically all of your vector math right there. Numpy will also do matrix products for you. It's a pretty good library for handling all kinds of tensor-like data.

In principle? Yes. You can work out the relevant cross-section of the target, convert it into a volume in the space of orbital elements, and then see where different burn times put you in that volume. There's probably a first-order formula in there somewhere, but it's still not going to be pretty, and I wouldn't want to try and work it out by hand. In contrast, consider throwing a computer at it. Just simulate transfers with different burn times, and see whether you still hit the target. Way better precision and much easier to implement. If you aren't planning to hover, yeah. If you're going in the way Apollo 11 did, without knowing if your LZ is safe, and having to traverse the surface looking for alternative, then it becomes significant. The key is that once you are well bellow orbital speed, the amount of fuel you need is just proportional to amount of time you're staying off the ground. It doesn't matter if you're in level hover, or slowly descending, or even going up and down. Gravity transfers momentum to your ship at a constant rate, and it has to be dumped as engine exhaust or you won't like the landing. An extra second of operation is probably negligible compared to your total. If you plan to extend your descent by a minute, you'll have to have a minute-worth of hover of fuel. Or precisely g * T in dV budget. Yeah, if you're well-positioned, you just drop periapsis over LZ. The dV is just the difference between orbital velocity of your original orbit - sqrt(μ/r), and the speed at apoapsis of the eliptical orbit - sqrt(2μ/(R+r)) * sqrt(R/r). Here r is your orbit's radius, and R is body's radius. I'm sure there's a number, but I don't see any way of deriving it algebraically. The integral is quite ugly. But again, it's no trouble integrating numerically for any given body. The math for actually computing dV from low circular orbit to landing can be done in an Excel sheet, if you don't want to take time writing actual code for some reason.

A ring rudder tends to work pretty good with model rockets. The ring is bellow nozzle and around the flow. Not being inserted into flow reduces need for fancy materials, and it tends to have enough authority for anything you'd use it for. From there, a simple PID loop should keep the rocket stable, but your overall solution is likely to be way more complex. If you just needed stabilization, I'd grab ready built drone control system, but since you'll probably need to control way more parameters, you'll need an MCU anyways (PIC, Arduino, etc.) and a serious IMU. Fortunately, later are plentiful for drones and helis, so you can get a good one cheap. Then you'd write your own PID loop along with everything else you need.