That is what I did
This is fun!
I did find a good general (and 3 dimensional) solution, so I don't really need to pursue this any further.
T5 M-Drive distance limit
- Thread starter sudnadja
- Start date
That is what I did
This is fun!
I did find a good general (and 3 dimensional) solution, so I don't really need to pursue this any further.
Panzerkraken
SOC-7
Think of the additional fun complexity involved in using multiple bodies' 100D areas in order to gain additional acceleration. It also makes for an interesting bit of a "space trucker" setting, where you have a somewhat predictable route that vessels will be taking in order to maximize their time; or if someone is trying to be stealthy, they can cruise along with just their M*.01 rate.
Having to calculate a change over from xG's ot xG.01 sounds nifty and all that, mind sharing the calculation since it's not T=2*Sqrt(dist/Msec) at that point?
And yes, I'm serious. If the game requires higher level math to solve I may as well have something to learn from, my math courses are long behind me. Baby steps are good here.
And yes, I'm serious. If the game requires higher level math to solve I may as well have something to learn from, my math courses are long behind me. Baby steps are good here.
Well, I think it's going to have to involve calculus to do it properly. Since the drive loses capacity as it leaves the gravity influence.
I don't know what the rate of decline is, but it's not "6G to 1000D then 0.01G at 1000.00000001D".
I can't even say my calculus fu is weak -- it's non-existent. Never quite took to calculus.
If you posted an integration or derivative to solve, I could google my way through and solve it. But how to apply either to a problem, is beyond me.
Panzerkraken
SOC-7
I did some googly-fu and the calculation of gravitic force comes to play pretty quickly. Since the reactionless drives are based on the local gravitic force to generate their acceleration, then there would be a relative basis of available thrust to the force of gravity affecting the craft.
One of the NASA 'for middle school students' lessons (which were the ones I felt qualified to read) mentioned that to reduce the perceived force of gravity to one millionth of a g, you would have to be at a distance of 6.37 Mkm. Since the radius of earth is 6378 km, that's a fair approximation of the 1000D mark. If available acceleration drops to .001G at 1000D, then you could say it drops by E-1 (for instance 3g becomes .3g) at each 10R until the acceleration becomes negligible.
Since that's all within the Earth SOI. While in Earth's SOI, you're also in Sol's SOI, just past the Solar 100D limit (6.95 x10^7km), so you'd be at .1 acceleration unless you headed back in-system a ways to pick up that Solar acceleration. Moving outsystem, you'd find yourself at the 1000D limit at 4.63AU (6.95 x10^10km), and you'd be forced to either rely on the speed you picked up in the inner system, or continue accelerating at .001 until you closed in with another significant body (probably Jupiter). I think in that situation there would be a significant effort to use the maximum thrust and possibly some atmosphere braking to bleed of your V while in the Jupiter SOI, if that was your final destination, or the opposite if you were going to one of the other major SOIs in the outer system.
Anyway, the overall (to me) seems that the math is pretty straightforward, since F (the perceived force of gravity) is directly relative to r (the radius of the m(1) body in the sphere of influence), and A(s) (the ship's acceleration using an M drive) seems to be directly related to F. You pick up a nice, predictable decline in available acceleration as you get further from a particular SOI. Of course, that wouldn't follow through with the RAW, since it doesn't mention .1 or .01g, it just drops to .001, but hey, we all do what we have to do.
In a related note, that gives a great reason to have NAFAL or HEPLAR on your craft even after TL10+
One of the NASA 'for middle school students' lessons (which were the ones I felt qualified to read) mentioned that to reduce the perceived force of gravity to one millionth of a g, you would have to be at a distance of 6.37 Mkm. Since the radius of earth is 6378 km, that's a fair approximation of the 1000D mark. If available acceleration drops to .001G at 1000D, then you could say it drops by E-1 (for instance 3g becomes .3g) at each 10R until the acceleration becomes negligible.
Since that's all within the Earth SOI. While in Earth's SOI, you're also in Sol's SOI, just past the Solar 100D limit (6.95 x10^7km), so you'd be at .1 acceleration unless you headed back in-system a ways to pick up that Solar acceleration. Moving outsystem, you'd find yourself at the 1000D limit at 4.63AU (6.95 x10^10km), and you'd be forced to either rely on the speed you picked up in the inner system, or continue accelerating at .001 until you closed in with another significant body (probably Jupiter). I think in that situation there would be a significant effort to use the maximum thrust and possibly some atmosphere braking to bleed of your V while in the Jupiter SOI, if that was your final destination, or the opposite if you were going to one of the other major SOIs in the outer system.
Anyway, the overall (to me) seems that the math is pretty straightforward, since F (the perceived force of gravity) is directly relative to r (the radius of the m(1) body in the sphere of influence), and A(s) (the ship's acceleration using an M drive) seems to be directly related to F. You pick up a nice, predictable decline in available acceleration as you get further from a particular SOI. Of course, that wouldn't follow through with the RAW, since it doesn't mention .1 or .01g, it just drops to .001, but hey, we all do what we have to do.
In a related note, that gives a great reason to have NAFAL or HEPLAR on your craft even after TL10+
Last edited:
Condottiere
SOC-14 5K
You could complicate it and have a gradual loss of performance the greater the distance from a gravitational well, rather than a sudden drop off.
mike wightman
SOC-14 10K
If you have a gradual change to your m-drive rating then you will need calculus to solve your maneuver profile.
The plateau method keeps the equations within the realms of SUVAT.
The plateau method keeps the equations within the realms of SUVAT.
Panzerkraken
SOC-7
I agree. And the granularity of the plateaus should be based on the comfort level of the group; for instance the system I outlined above would be best for a single-system game as opposed to one where you're just popping in to fuel up before jumping to the next one.
If the group is happy with doing MATLAB/JPL software level maneuver planning, then they can, and you can reverse-engineer the data required for them. I wandered down that rabbit hole at one point and regretted it a bit.
I haven't see a simple (or any for that matter) solution to even a two body intercept problem while under constant acceleration. Much less complicated by gravity.
And by the two body intercept, I simply mean you have one body moving along a vector at a constant velocity, the other is Someplace else with an M-Drive with X acceleration, "what direction do I point the ship, how long do I burn, how long do I coast, and how long do I decelerate". And with an M-Drive, we can skip the coasting part. With M-Drives and their huge acceleration (yes, 1G is huge), you can mostly fudge things.
You can point your ship at jupiter, get a guesstimate, take that time, advance jupiter that far along its orbit, and take another guesstimate. That course should get you well within manual control.
That's simple intercept. Not matching vectors (different problem), nor, intercept when as you get closer to the other body, it starts pulling on you.
The only way I've managed to solve it is dynamically through simulation, and the results of that are ugly enough, but it seems to work (I actually achieve orbit, but it's not stable).
Arguably, all docking and matching today is done manually. They mission plan the main trip, but when it gets close, they adjust and compensate. Though I must say, the path the comet probe took to match the comet is just incredible.
And by the two body intercept, I simply mean you have one body moving along a vector at a constant velocity, the other is Someplace else with an M-Drive with X acceleration, "what direction do I point the ship, how long do I burn, how long do I coast, and how long do I decelerate". And with an M-Drive, we can skip the coasting part. With M-Drives and their huge acceleration (yes, 1G is huge), you can mostly fudge things.
You can point your ship at jupiter, get a guesstimate, take that time, advance jupiter that far along its orbit, and take another guesstimate. That course should get you well within manual control.
That's simple intercept. Not matching vectors (different problem), nor, intercept when as you get closer to the other body, it starts pulling on you.
The only way I've managed to solve it is dynamically through simulation, and the results of that are ugly enough, but it seems to work (I actually achieve orbit, but it's not stable).
Arguably, all docking and matching today is done manually. They mission plan the main trip, but when it gets close, they adjust and compensate. Though I must say, the path the comet probe took to match the comet is just incredible.
A few of those cases are variants of Lambert's Problem, various kinds of ODE BVPs (boundary value problems). An earth-comet intercept is almost certainly going to be found as either a single BVP or a large set of segmented BVPs. A good introductory text on this is "Spacecraft Trajectory Optimization" and "Modern Astrodnamics" by Wiesel will get you into the appropriate spirit of orbital motion. You can plug the equations into a CAS and likely get a fairly good solution for a single transfer or intercept (for example, an Earth-Jupiter transfer here: https://youtu.be/apnDxaDOQrw ).
What do you mean that you achieve orbit but that it isn't stable?
And in practice, Traveller isn't a very good forum for this, and it seems that Traveller is trying to move away from even vector movement to a more one-dimensional approach to spaceflight ("how far is it away?"). As someone pointed out, most people view Traveller as a game rather than as a vehicle to learn about or practice astrodynamics or astronomy. I wish I could delete the entire thread, Traveller is not set up to be and will never be a hard core physics-oriented game.
Traveller being what it is, it probably shouldn't even bother with detailed system creation. The original UWP + is there a gas giant in the system is probably enough for story telling purposes. Thus, jump jockey remains a fine profession.
mike wightman
SOC-14 10K
Some of us do enjoy the detail though, and like to incorporate it into some of our games (note not all the time lol), so keep the discussion going 
Over the years I have learned an awful lot about orbital mechanics, delta V budgets etc so that I could run near future Traveller campaigns at the TL 8-9-10 range with no magic gravitic maneuver drive, just handwavium fusion rockets and nuclear powered plasma and ion engines and the like. The hours and days I have spent at the Atomic Rockets site probably add up to a sizable chunk of my free time
Traveller definitely inspired me to learn physics and maths.
Over the years I have learned an awful lot about orbital mechanics, delta V budgets etc so that I could run near future Traveller campaigns at the TL 8-9-10 range with no magic gravitic maneuver drive, just handwavium fusion rockets and nuclear powered plasma and ion engines and the like. The hours and days I have spent at the Atomic Rockets site probably add up to a sizable chunk of my free time
Traveller definitely inspired me to learn physics and maths.
As Mike Wightman said, some of us enjoy adding a level of detail to our Traveller games. I'm very glad that one participant in a thread, even the thread starter, cannot delete the whole thread and discussion.
:CoW: I'm even more glad that you are not in charge of deciding what is "probably enough for storytelling purposes" in any Traveller game but your own!The problem is that the vast majority (and I am by no means an expert on it) of the techniques to perform these calculations are based on things coasting. Setting their orbit, riding it out, and correcting it at the end. i.e. transfer orbits. Specifically designed to minimize energy and delta V use. To be energy efficient orbits.
M-Drives don't care. They are point and shoot. M-Drives say "I see your Hohmann Transfer Orbit and raise you 2G's of acceleration for as long and I blinking want." "You think I have time for 'low energy'? Heck, Son, I have a business to run -- I'm not going out in to space to float around. Turn and burn, baby, turn and burn. Light those suckers up, Scotty. Find the Turbo button and hold it down!"
So, like I said, I haven't seen anyone (and I've asked on physics and math forums every now and then) that has come up with a technique to solve the equations involved to burn a rocket half way, turn around, burn it again to decel, and arrive where you want to be.
Consider.
Earth to Jupiter: 588MKm. We will assume that Jupiter is at 0 degrees when oriented to the earth for this experiment. And we'll assume a 10m/s^2 acceleration drive ("1G"), for assorted values of "1" and "G".
d = 1/2 at^2 thus t = sqrt(2d/a).
We need to burn to 294MKm, then turn, and decel another 294Mkm.
t = sqrt(294,000,000,000m * 2 / 10m/s^2) = 242487s = 67.35hrs
That gets us to the halfway point. double it for the full trip: 134.7hrs. This puts us at Jupiters orbit, due "west" of Earth (at least where Earth was when we started). But, of course, Jupiter, being rude, has moved on and is not waiting for us.
Jupiters orbit: 778Mkm, which we will crassly assume is a perfect circle.
Jupiter's orbital velocity: 13.1km/s.
Jupiter's complete orbit is pi*r^2 = 3.14159 * 778Mkm^2 = 1901544Mkm
Velocity * trip time: 13.1km/s * 242487s = 3176578km.
So, by the time you show up, following this naive course, Jupiter has moved 3.2MKm away from where your ship is at, which stands now parked, with a velocity of 0.
Now, honestly for a 1G drive, 3Mkm is nothing. Doing the same math, we'd end up with a trip of 35776s, or, basically, 10 hours. So, fly for 134.7hrs, when you get there, correct and fly for another 10. This is silly of course.
Now, if at the start of the show, the ship turned 0.00006(!!) deg counter clockwise, leading Jupiter a wee bit, they would more or less end up on top of Jupiter with much less than a 10 hour catch up at the end.
Planets move a lot, they're fast. Ships are faster.
But none of this accounts for either the Sun's gravity slowing the ships initial progress, or Jupiters gravity pulling it in at the end. I have no idea how much impact they have on the trip.
You can see that if you solve the base problem, use that to get an initial time estimate. Then bracket it on the other end "well, if I want to go where it's going to be, how long would THAT take". A couple of rounds of estimating and correction, and you can almost figure it out. But I'd like the math to be more deterministic that continual, informed guess until it's close.
Ideally, I'd want 4 results. Heading, duration of acceleration (I don't know if this needs to a fraction of maximum acceleration) for boost phase, duration of a coast phase, and duration of deceleration for the arrival phase. (that way the math can be used for TNE where burning the motor for 140 hours solid isn't practical).
I have tried different techniques for this. I did a genetic algorithm once, taking in to account Earth, Sun, and Jupiter. And, I got it the point that I was arriving at Jupiter, but I couldn't get the velocity down, and the course, well, let's just say it wasn't the most efficient. Had a few more bends and turns than I liked.
Well, the way the simulation was written, it wasn't designed to actually stabilize the orbit. But the simulation effective "flew" the ship around the planet (and by flew, I mean is was actively accelerating and decelerating constantly to keep the ship in place).
But getting there, it was pretty good. It was constantly adjusting it's heading and burn. Burned pretty solid heading up, got a bit before halfway before it turned around and started the decel burn. You could see it lighting the motor and coasting. It was basically constantly flying, figuring out where it was, and correcting over and over.
"Spacecraft Trajectory Optimization" does deal with that situation (that of continuous thrust), as solar-electric drive engines of today do have to deal with the same thing. There is not an analytic solution for it, the methods they present are non-linear optimization ones.
PyKEP and other tools out there have built in solvers, but many of them make the assumption that they're operating within our solar system.
PyKEP and other tools out there have built in solvers, but many of them make the assumption that they're operating within our solar system.
Here, for example, I have a non-coasting, continuous thrust example:
and even entered orbit at the destination:
It's not done as a closed-form solution though, of course, position estimates of the target on arrival are iterated on (basically a newton-rhapson system) until precision is high enough and then a thrust vector is decided. The ship is in either acceleration or deceleration mode depending on if its kinetic energy + potential acceleration energy > potential deceleration energy relative to the planet at that point. It needs some tuning, but it works within Mathematica's NDSolve.
Can you show how you went about doing this?
A direct flight is the simple case:
And results in a direct intercept of the gas giant, despite it having moved about 58 planetary radii along its orbit since the flight started:
The problem more efficiently stated is that you want your ship, at some point, to match the position and velocity of the target planet (or a planned orbit around the target planet), or that you want the same point in configuration space. For that method, I aim at the position of the planet while potential energy > kinetic energy, and then aim at the velocity vector (relative to the ship's velocity vector) of the planet when kinetic energy > potential energy, resulting in an appropriate turnover point:
This results in a zero (or nearly zero) velocity intercept.
The first method works well as a missile guidance system as well, for approximating TL6 level missile intercept intelligence.
Computing the direction of thrust vector is part of the summation of gravitational forces (that's the Sum[ ] part) in this Newtonian system. I also have a Hamiltonian system that I need to retrofit this into.
