Mad Rocket Scientist

Chrome and firefox with windows 10 seems to work, as well as chrome on android. I hate to ask, but have you tried clearing cache/cookies?

Pretty amazing that a vessel that size doesn't just crash the game. Can it land on planets without an atmosphere? Only 806 billion funds too.

The real question is what counts as a single vehicle. If I weld two tanks together, are they now one vehicle? If I tie a rope between the vessels of an entire navy, is that one vehicle? Can I violate causality with a large enough "military vehicle?" You'd probably see slightly more wars, since there would be less human cost, but I'm not entirely convinced that wars haven't been limited by economics since WWII. Plus, despite the trend of military technology to have fewer and fewer humans in physical danger (less crew, radar, drones) war has still been way less common compared to pre-WWII. I don't know why that is, but I doubt that just a small reduction in the human cost of wars would shift that balance.

Just got nerd-sniped trying to think about how to make that work. I personally don't have much experience with RC servos, but my grandfather flew RC planes and I was always amazed how well they worked. They never needed configuration or calibration and I have never seen one fail. Not only that, modding them for continuous rotation is (relatively) easy. On making a smooth version of the thrust curves: This is the kind of data I have (actually, there are 4 formats, but this is the basics): 0.0070 23.0 0.018 25.0 0.027 20.25 0.066 20.25 0.073 18.5 0.094 20.25 0.112 20.75 0.137 19.75 0.163 21.5 0.202 20.75 0.231 20.75 0.254 22.75 0.27 20.75 0.504 20.0 0.536 18.25 0.607 17.0 0.687 14.75 0.751 14.25 0.84 11.25 0.998 8.25 1.024 8.25 1.248 2.5 1.385 0.0 The number on the left is time, the one on the right is thrust. This data has relatively few points. I've had very little trouble turning this into a bunch of lists, but making a curve function for it is where the challenge is. This is what the data looks like when graphed: First, I pursued bezier curves, with each point as a control point for the bezier curve: As you can see, it smooths the curve, but loses much of the detail. More importantly, I'm not sure if the bezier package I'm using actually supports n-degree curves, since it seems to look that same whether I input any manual degree or automatically calculate the number of degrees from the number of control points (1 per control point). It also seems to break with more than about 50 control points. Then I want for cubic splines, making the function pass through all the points on the original data (here seen overlaid on the original data): This is the most successful, since it preserves all of the original points, and provides an easy to use function for all points on the spline. However, for data that has large areas between points or is noisy, it produces points that are quite far away. Many of the other data sets work much better than this one. In the long run, probably none of this matters too much since this data probably won't match what we actually get from the engines, but should I continue to try to refine the interpolation?

In real life, orbital velocity is much higher than in KSP, so the circularization time is much higher, and it sort of spills over into the ascent. @cubinator, while I'm pretty sure some rockets in real life do use precomputed trajectories, many use Powered Explicit Guidance Ascent System (PEGAS) or a variant thereof. PEGAS can accept any target orbit and compute an optimal trajectory to reach it, and can correct for errors in-flight. Someone made a version of it in KSP here if you're interested in more details: EDIT: See also: The space shuttle PEGAS document: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740004402.pdf

Learning about bezier curves! Did you know they are named after a engineer at Renault in the 60's? https://www.jasondavies.com/animated-bezier/

I'll probably buy this at some point, but I think mods will be what either makes or breaks this game. Procedural and moving parts right out of the gate are pretty cool though. The lack of joint simulation may or may not be a loss. I don't really like the style of the parts though. The engines kind of look like the plastic shells on gas stations and pumps.

http://www.wwwdotcom.com/index.html This website is older than me, and it probably isn't even the original.

I don't know about what budgets (money, mass, time) will be the most important. Two other questions: Is it reasonable to assume that mass flow rate is linearly correlated with thrust? And about 3x3 rotation matrices: do they describe a specific rotation of an object in space at a point in time, or do they describe the act of rotating from one rotational point to another?

I've seen this before, but the price tag has turned me away. Would someone who liked Aurora 4X like this? I don't know if that's me, since I haven't yet put in the time to learn it.

It seems to have been taken down. There's a streamable mirror here: https://streamable.com/161m6

I didn't even know they made microcontrollers that small and cheap. Thanks. Getting more into the specifics: I have a object at rest 10 m above the ground. To simulate its motion, can I do something like this? import numpy as np g0 = np.array([0.0,0.0,-9.81]) position = np.array([0.0,0.0,10]) #does it matter if these are arrays vs. lists? velocity = np.array([0.0,0.0,0.0]) t = 0 dt = 0.01 while position[2] > 0: t += dt position += velocity * dt + 0.5 * g0 *dt * dt #Just stealing this from someone else's implementation of the velocity verlet... velocity += g0 * dt Testing this, I get 0.003 seconds of from sqrt(2*d/9.81) where d = 10. I also get completely shocked that it worked so well.

I'll look more into ring rudders, those sound useful. Buying a premade IMU might be a good idea, it looks like they cost about $15 USD. The tricky bit of landing probably won't be staying upright, but rather controlling horizontal drift. As for the flight computer, one of the people in the group is thinking of using a raspberry pi. Personally, I think an arduino would be adequate, but nothing's set in stone yet. We're actually kind of forced to do a hoverslam/suicide burn since there is no way to control the thrust of the engine. If the engines have tight enough tolerances, then we just have a timing and stability problem as long as the drop height is the same. Otherwise, there is the option of adding smaller engines which the computer can decide to fire or not based on the thrust from the main engine, some kind of thrust termination system (I was personally imagining simply detaching the engine and letting it fly up through the center of the rocket, but some kind of fins that blocked the exhaust could work too), or even jettisoning weight as needed. Adding the smaller engines sort of moves your suggestion of two steps into one step. If we're not able to get consistent enough results with solid engines we'll probably have to move to hybrids. "Landing" at a point in mid-air is almost certainly how we will initially test the rocket. To make our program sound more respectable, we could use a bouncy castle to prevent damage if the parachute doesn't deploy right. EDIT: What kind of mathematical model is recommended for velocity? X, Y, Z velocities stored separately? Vectors?

Then why do I get this funny feeling you have posted this here before?

I'm just about to get my python environment set up. It's actually been a while since I last used it. I think trying to get calls to FAR working will be more effort than just rewriting my own version without any supersonic considerations. The rocket will also likely look like a tube, so there shouldn't be a need for the ability to simulate bricks like FAR can. We will probably end up needing stability control of some kind. Hopefully this sim will make it clear how much and what kind of stability hardware will be needed.

I have 31263 on my current RO install.

I've heard ABS or PLA plastic can work as a fuel, which would mean you could 3d print the fuel grain. I don't know if that works with N2O oxidizer though.

That looks great! Are you using a straight, parabolic approximation, or exact de laval nozzle? I love the idea of using N2O cartridges for mini hybrid engines.

What do you mean there is no such thread? It's just that thread that's been locked since 2013. It exists, it's just locked.

We definitely need active control. This simulation is mostly to determine whether it is possible to use solid engines for this, and to test and debug the control code without blowing things up. Do you mean cm? 2-3 meters is a lot. It also looks like you can improve the accuracy of those by correcting for the speed of sound based on air temp, but I'm hoping accurate enough accelerometers will let us integrate to get our altitude. Initial tests will likely be drop tests rather than using powered ascent, allowing for much more control over where it lands.

Yes, I've heard that their accuracy is surprisingly good though. Probably going to do some tests to determine how variable they are, unless anyone has a source for raw testing data of model engines? TVC is possible with solid engines: https://www.youtube.com/channel/UCILl8ozWuxnFYXIe2svjHhg/featured But if I need to control thrust through the burn duration hybrid engines may be the best option, although pairs of 1/2 A or smaller solid engines may work too. That's really helpful, thanks. Are quaternions overkill for this? I know they avoid gimbal lock, but is that really an issue if you're staying within 10 degrees of vertical throughout the entire flight?

Thanks, that's mostly how I imagined it, but I'm glad to hear that (at a high level at least) I'm not too far off. On delta time: That is just the "fine-ness" of the simulation in time, right? For example, if I had an object moving at 10 m/s, a delta time of 1 second would advance the position of the object by 1 meter every loop cycle, and a delta time of 1/10 of a second would advance the object by 1/10 of a meter every time? And without the requirement of running in real time, like a game, I can just leave that as a constant, or are there more considerations than that? As for concrete examples, I'd like to model a rocket with solid engines, including thrust curves, rotation, gravity, simple aerodynamics, etc. I'd also like to be able to "trick" a control system into thinking it is controlling the rocket, so producing appropriately inaccurate pressure and acceleration values. I want to add later things like specifying the exact location and rotation of the thrust vector relative to the rocket's origin, center of mass shift during flight, momentum effects from moving weights, fins, or landing legs, and multiple engines.

I've been working with a group of people on some model rocketry projects, and I wanted to try simulating retro-propulsive landing with solid engines. As far as I can tell, none of the already available rocket sims have enough control over the design of the rocket (multiple engines, actuators) or allow computer control of the rocket throughout the simulation. While KSP can do this, it doesn't work at small scales, plus I think this would be a fun challenge. Could anyone direct me to some beginner references for physics simulation with computers? I'm familiar with python and javascript, but can work from tutorials designed for other languages. Thanks!

-84 C? Call me when it actually gets cold. Like colder than it normally gets in the antarctic.