![](https://forum.kerbalspaceprogram.com/uploads/set_resources_17/84c1e40ea0e759e3f1505eb1788ddf3c_pattern.png)
![](https://forum.kerbalspaceprogram.com/uploads/set_resources_17/84c1e40ea0e759e3f1505eb1788ddf3c_default_photo.png)
Yourself
Members-
Posts
134 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Yourself
-
Advanced solid rockets.
Yourself replied to Galane's topic in KSP1 Suggestions & Development Discussion
Unless the SRB was an end-burner type. An end burning rocket has roughly a constant thrust and the burn time is proportional to length. -
Any Aerospace Engineers or AE students here?
Yourself replied to AE_student's topic in Science & Spaceflight
I actually have my Bachelor's in aerospace and did most of a Master's but never finished it. I currently work as a software engineer for a company that makes flight simulators, but I will likely be going off to work at Google for a while in a couple months (or more than likely not, flight simulation is way cooler). It's a long and complicated story. -
The issue with Newton's laws here is actually a pretty subtle one. Technically he applied it correctly by virtue of the fact that he included the thrust as T. Another way of looking at it is to consider the rocket as a variable mass system where the only forces applied to it are gravity and aerodynamic drag. The thrust force is kind of a fictitious force that arises due to the fact that the rocket is ejecting mass. So, the completely proper statement of Newton's second law that you're probably thinking of would go something like this: dp/dt = -m g - 0.5 * àA Cd v |v| ( technically the form given above was only correct for positive velocities, v |v| gives v² but with a sign, so it also works if the rocket goes down, not a really relevant in this analysis but I figured I bring it up anyway) It turns out that for a system that's ejecting mass at some velocity relative to its center of mass, Vr, we get this: dp/dt = m dv/dt - Vr dm/dt In the case of a rocket, Vr is the exhaust velocity and we define Vr dm/dt to be[/be] the thrust produced by the rocket. Putting the above equations together we get this: m dv/dt - Vr dm/dt = -m g - 0.5 * àA Cd v |v| m dv/dt = Vr dm/dt - m g - 0.5 * àΑ Cd v |v| In the equation by tavert the Vr dm/dt term has simply been called T for thrust. I'm not sure what you mean by your question about accelerating reference frames. The reference frame chosen here is that of the ground, it is non-accelerating. It doesn't really matter what reference frame we pick, but picking an accelerating reference frame is usually pretty inconvenient. Inertial reference frames are much easier to deal with since the laws of physics are typically more naturally expressed in inertial frames.
-
I'm with this suggestion. I always envisioned that you'd have simulated runs which could be reverted or restarted because they're simulations and then you'd go off and do the actual flight. I like this because it gives some motivation for planning failure modes, but doesn't throw you under the bus by never giving you the chance to actually test them. I also kind of like the idea that you could start in Mun orbit (or any planet), but only after you've sent satellites to measure its properties (like gravitational strength and what-not). Maybe you'd be allowed to start at any planet initially but the estimates of gravity wouldn't be accurate. In any case I like the idea of there being some motivation to science the hell out of planets.
-
How to divide by zero (100% real)
Yourself replied to AncientAstronaut's topic in Science & Spaceflight
I think that just reinforces my statement that it is his greatest talent. -
Also in translation mode the default keybinding has the direction of IK differentl from JL. J and L attempt to move your spacecraft in the direction you're pressing, whereas I and K do the opposite (K will thrust in the upwards direction). I don't have a problem with it being backwards, but I do have a problem with it being inconsistent.
-
How to divide by zero (100% real)
Yourself replied to AncientAstronaut's topic in Science & Spaceflight
Division by zero in the real numbers is undefined, end of story. It's not because no one's been clever enough to come up with a way to do it, it's because we've defined division such that it's not possible, period. Want to see division by zero? Use the real projective line. That permits division by 0 (but not 0/0). As for the video: This guy is not a math genius, he hasn't the faintest idea what he's doing. I'm surprised he made it past middle school algebra. From what I can tell his greatest talent is being able to write upside-down. -
Quick question on Normal force VS Acceleration
Yourself replied to aftershockzap's topic in Science & Spaceflight
What technically causes the damage is a high stress compressive travelling through the materials. Objects don't being accelerating instantaneously when a force is applied to them, it takes time for that information to propagate through materials to the rest of the object. As a result you have different parts of each object accelerating at different rates and the interface between these different rates of acceleration is a wave. -
Oh, but it's actually so much more fun than that. There isn't just one way to interpret an infinite series. We don't have to limit ourselves to saying that an infinite series is the limit of its partial sums, we can do so many different things. This always kind of reminds me of how we came up with complex numbers. We had polynomials that had no roots, which feels like something's just kind of missing, so we invented the complex numbers to fill those out. The same kind of thing is happening here. We have infinite sums that aren't convergent and so don't really have any sort of meaningful value. But we can extend our methods of computing infinite sums to "complete" these. Of course at this point you kind of have to ask yourself what it really means to have an infinite sum.
-
Docking Alignment on Navball
Yourself replied to KwirkyJ's topic in KSP1 Suggestions & Development Discussion
No, it doesn't just tile anything. Typically when docking you point everything in the north-south direction, because that's orbit normal and anti-normal (so it doesn't change throughout your orbit, whereas the radial/anti-radial and prograde/retrograde directions rotate as you move through your orbit). The problem is, there's no clear indication on the navball of the normal direction except in equatorial orbits (and to a slightly more limited extent in polar orbits as well). In an equatorial orbit, pointing north along the horizon on the navball is orbit normal. If you're in an inclined orbit, there is no one reference spot on the navball for orbit normal, you kind of have to guess by watching very closely for when the prograde and retrograde markers switch sides (this can be tricky because they're mostly hidden by the edges of the navball). For example, you can't simply aim 30 degrees east of north if you're in an orbit that's inclined 30 degrees from equatorial. There's exactly two spots in your orbit where orbit ±normal will be 30 degrees from north and that's at the ascending and descending nodes and at one node you'll be pointing east of north and the other will have you pointing west of north. In between those points your normal direction will swing through north or south. I mentioned polar orbits earlier and that's because they're a somewhat degenerate case here. Their reference direction flips from east to west and vice versa each time you cross a pole, so orientation is workable there, but it gets wonky at the poles. The problem I have with this is it makes things more difficult than it needs to be. For example, when I'm building a space station I usually launch up that 6-sided hub first. If I have to line my docking ports up with orbit normal (which as I pointed out above is not always trivial to find), then there's 3 different orientations I have to put the station in to attach the various pieces. Having to reorient all my docking spacecraft because the interface is lacking a basic feature isn't really that fun. I disagree with it being too crowded since there's only 2 things on it when you're docking and the goal in this case would be getting them all lined up (which kind of reduces it to one "thing" on the navball when your alignment is good). And, the typical docking procedure would be to first line up the direction you're pointing with the orientation marker, so most of the time it's not something you really have to pay attention to. But putting that aside I'm reminded of previous suggestions to have the navball horizon align itself with the target docking port. I feel that's a bit confusing (and I would argue that it might even be an easy thing to miss), but it does avoid the "3 things" complaint. The problem with using a marker on the edge is that it's only capable of displaying one rotational degree of freedom and, in order to dock, you need at minimum two rotational degrees of freedom to line up with the docking port axis; 3 would be nice so we could get the roll stuff lined up as well, but strictly speaking it's not necessary to do that to dock successfully (and it's also not what we're talking about). A marker at the edge would be fine for doing the roll orientation, but you don't need that to dock. You do need to line up with the docking axis, which is where the whole orbit normal thing comes from: it's a convenient axis that's invariant throughout the orbit, so rather than actually aligning the spacecraft with one another, we actually align them with some other axis. That said, aligning things with orbit normal also requires that you be able to control the target vessel and, while that's usually the case, I think it's an unnecessary limitation. Maybe I want to go rescue a dead probe or something -
How does this plant do this?
Yourself replied to Custard Donut (In Space)'s topic in Science & Spaceflight
I think this is a common misunderstanding of what "survival of the fittest" actually is. It's not about who produces the most reproductively fit individuals. If a group of humans can out-perform another group by helping one another, then that is more fit, even if, individually, each human in that first group is less reproductively fit. Like, one example I always like to go to are eusocial animals like ants. In a given ant colony almost none of the ants are capable of reproduction. Yet ants are a wildly successful species (just ask anyone who's ever tried to get rid of them). Similar things happen with all social animals. Our reproductive fitness comes from the fact that we are not loners. We share the burden of living among one another, which allows members of the group to specialize at certain tasks making them more effective, which makes the group as a whole more effective. In your case of people being color blind, so what if they're color blind? If they can get by with limited color vision then it's obviously not that much of a detriment, is it? And there's still lots of things color blind people can do that help our group fitness. So part of the problem with your idea of natural selection here is that your imposing your own values on it. Natural selection doesn't have values. It doesn't care what you think would be better. If color blindness doesn't significantly affect reproductive success, then natural selection won't select against it. Trying to imagine that it would "normally" select against it is misleading. There actually are situations where it would be advantageous to be color blind. For example, consider some animal that has a pattern on its skin that helps it blend in with its surroundings. The pattern of color splotches normally makes it difficult for someone with color vision to see, because their eyes can distinguish between the different colors of the pattern. Someone who's color blind may not be able to distinguish those colors very well and so the animal might actually be more visible to them because they see what looks like a solid color in the shape of a dangerous animal. This can also go the other way too, there are sometimes colors that color blind people can distinguish that people with normal color vision cannot. -
Docking Alignment on Navball
Yourself replied to KwirkyJ's topic in KSP1 Suggestions & Development Discussion
If you're not in an equatorial orbit, there is no "right way". It may also be a huge pain to re-orient the target. Overall having an orientation indicator on the Navball is way simpler and way easier to deal with. The way I envision it is that there would be another indicator on the Navball that, if you were to point towards it, your docking port would be oriented properly for the target. This has the added bonus that if the orientation indicator and existing bearing indicator are lined up, then you're perfectly lined up to dock. -
To be specific it's so time warping doesn't introduce larger errors into the trajectories (and additionally doesn't take significantly more computational power). It has pretty much nothing to do with memory.
-
Practically speaking, yes. It takes energy to remove electrons and then it takes energy to contain the Xenon ions so that they don't go ripping electrons off of anything else.
-
Double Slit and Observer Effect - Possible to test at home?
Yourself replied to Albert VDS's topic in Science & Spaceflight
I'd probably point them to this: http://simple.wikipedia.org/wiki/Electron Yes, it's real, but it's not magic, and it's not because quantum particles have or are affected by "consciousness", which is what this particular video implies (and that implication is much stronger when taken within the context in which it's presented, in that movie I mentioned). -
Double Slit and Observer Effect - Possible to test at home?
Yourself replied to Albert VDS's topic in Science & Spaceflight
I actually really hate this video because its conclusions are misleading. For example, it sets up that an electron is "like a tiny marble". Well, it's not. That's part of what this whole experiment demonstrates: that our notions of "particles" and "waves" don't really work that well at the quantum level. Electrons (and really everything) are neither particles nor are they waves, they are something which exhibits properties of both of those things. They have the discreteness of particles, but the interference properties of waves. We humans simply don't have a good intuitive model for what stuff actually is. We definitely now have fantastic mathematical models, but the intuitive models are still stuck at "particle" or "wave", because that seems to really be what our minds understand. But that's not even what bugs me the most about the video, I could easily forgive that. What really bothers me is that they make it seem like electrons "decide to act" in a particular way based on whether it's being observed. The electron's not "aware" of anything, least of all being watched. Most of the issue comes about because the detection apparatus has to interact with the electron to detect it. It's not like at the macro scale where you can set up a camera somewhere which passively detects light that the object. If you want to watch a single electron you're necessarily going to interfere with it. Observation is most certainly not some kind of psychic force that changes the way the world works. Although this clip is from a movie that kind of has that premise and it was most certainly not well received by scientists. It won't work with a flashlight because a flashlight doesn't produce coherent light. You might be able to do it with a laser pointer, but you'd have some difficulty with the setup to show the wave-particle duality. First you'd need to dim the laser to the point that it only emits one photon at a time, otherwise you're just demonstrating wave interference. You'd also have some difficulty detecting one photon at a time with paper. Additionally, the slits in the double slit experiment should be smaller than the wavelength of the waves passing through them, otherwise you're going to get secondary diffraction effects. Now, if you want to get into the stuff that's really weird: http://en.wikipedia.org/wiki/Delayed_choice_quantum_eraser -
And, except in a few circumstances, knowing how far into the orbit you are as a fraction of the total orbit doesn't actually tell you where you are. If you want to know where you actually are (the true anomaly), you're going to end up using the mean anomaly as it's currently defined (see below). There's really no way around that. Okay, but why do we need to do that? If I'm computing the mean anomaly, it's because I intend to use it to compute the eccentric anomaly (and ultimately the true anomaly), so I don't much care what it's actual value is. Not everything needs to represent a physical quantity in a natural way. Consider also that the mean anomaly can be used with hyperbolic orbits as well, which don't have an orbital period at all. However, they still have a mean motion: n = sqrt( μ / (-a)³ ) and, thus, the mean anomaly is still given by M = n t (more generally we can define the mean motion for any orbit with e != 1 to simply be n = sqrt( μ / |a|³ )). In this case, I end up solving for a different form of the eccentric anomaly: M = e sinh(F) - F From which I can get the true anomaly via: cosh(F) = ( e + cos(θ) ) / ( 1 + e cos(θ) ) Or, solving for cos(θ): cos(θ) = ( e - cosh(F) ) / ( e cosh(F) - 1 ) Normalizing the mean anomaly here would definitely be useless because it doesn't represent the fraction of an orbital period, because the orbital period is undefined. The current definition of the mean motion is simply the most natural definition. Because then iteratively solving Kepler's equation will have extra terms in it, terms that typically aren't necessary. For example, the typical iterative solution using Newton's method ends up looking like this: E[n+1] = E[n] - ( E[n] - e cos( E[n] ) - M ) / ( 1 - e cos( E[n] ) ) Introducing that normalization factor modifies this slightly: E[n+1] = E[n] - ( E[n] - e cos( E[n] ) - 2 À Mbar ) / ( 1 - e cos( E[n] ) ) That multiplication by 2 À is largely unnecessary. Basically you end up taking the normalized mean anomaly and putting it right back into the typical form regardless. From a numerical standpoint this is undesirable since the extra operations can introduce errors.
-
Because that normalization factor is going to leak out somewhere. In this case, it alters Kepler's equation: Mbar = ( E - e * sin(E) ) / ( 2 À ) You're also missing that the equation for the mean motion looks like this: n = sqrt( μ / a³ ) This is because the orbital period already has a 2À in it: P = 2 À sqrt( a³ / μ ) So actually computing the mean motion in the range 0-2À doesn't really involve ever using À at all: M = t sqrt( μ / a³ ) So I would be able to compute the eccentric anomaly without ever having to deal with a À term in any of my equations. I have heard of it and I think it's stupid. This article adequately sums up why I think that: http://www.thepimanifesto.com/
-
There is no analytical solution to the equation*, so iterative methods are typical for solving it. The method you've given, which is fixed-point iteration, will converge reasonably quickly (likely 100 iterations will put you far past the precision of most floating point types) if it does converge (which it will so long as e < 1; it can also converge if e >=1, but not all the time). You can immediately knock one iteration off of your loop by starting with t = m rather than 0. Other common methods for solving this equation is to use Newton's method (which is technically still fixed-point iteration, but we change the form of the function to hopefully get better convergence rates) on f(t) = t - m - e * sin(t), which yields the following scheme: f'(t) = 1 - e * cos(t) t[n+1] = t[n] - f(t[n]) / f'(t[n]) = t[n] - (t[n] - M - e * sin(t[n])) / (1 - e * cos(t[n])) Or, in a slightly more readable code form: t = m; for( int j = 0; j < 100; ++j ) t -= ( t - m - e * sin(t) ) / ( 1 - e * cos( t ) ); This will actually converge very quickly, again 100 iterations is likely not necessary. In fact 7 iterations should be sufficient for e < 0.5. If e is near 1 things will get worse, but I never saw it take more than about 35 iterations to get within machine precision. Ideally your loop would look more like this: t0 = 0; t1 = m; epsilon = 1e-15; j = 0; while( abs( t1 - t0 ) > epsilon && j < 100 ) { t0 = t1; t1 -= ( t1 - m - e * sin(t1) ) / ( 1 - e * cos(t1) ); ++j; } *NOTE: Strictly speaking there kind of is an analytical solution for it, but you'll get it in terms of a Taylor series. I'm not sure that this gives any computational advantages; the standard iterative approaches may still be quicker to compute to the desired accuracy.
-
Also keep in mind that if you got two objects in matching orbits, the relative velocity between them would not be 0 unless they were right on top of each other. For example if your satellites were in the same orbit but directly opposite one another, the relative velocity between them would be twice orbital velocity. For example, if you and your target are in perfectly circular orbits at an altitude of 100 km above Kerbin and your target is 10 km away, the relative velocity between you will be about 32 m/s.
-
Why is orbital debris such a concern?
Yourself replied to Voyager55's topic in Science & Spaceflight
Also not all orbits have the same inclination. Inclination is really what makes it a big deal. If the inclination of two objects differs by just one degree in LEO, the relative velocity between them at the collision point will be about 130 m/s. Now consider that the ISS has an orbital inclination of 51.6°. Anything in a similar equatorial orbit (with inclination 0°) will have a relative velocity of about 6.7 km/s.