Newtonian Calculations

[mockingking]

Let's say I have two spacecraft in...well, space. They have thrusters, RCS and a good lot of fuel for both. They're moving at a modest relative velocity, possibly with one or both of them accelerating a bit in whatever direction.

Assuming they want to rotate to point their ships' noses at the other as quickly as possible, I suppose they would fire their RCS at full force to get some rotation going, then apply torque in the opposite direction from a certain point onward.

How would the captain of one such vessel calculate whether that point at which the RCS thrust needs to be reversed has been reached?

Thanks for any help!

[maccollo]

At the same thrust, it will take the same amount of time and degrees rotated to stop as it took to accelerate to that point.

If you wanted to rotate 90 degrees as fast as possible you would rotate 45 degrees and then flip it.

Not much of a calculation really =P

[-Velocity-]

To most quickly flip your nose around, and say, your nose had to move 120 degrees, then you would fire the RCS continuously for the first 60 degrees in the direction to build up rotation, and then fire the RCS continuously for the last 60 degrees in the direction opposite your rotation to kill your rotation.

[mockingking]

Alright, thanks for the input. Let's expand.

We now have strong relative velocity to start with, and both craft are subject to random bursts of acceleration - using any sort of pre-planned schedule won't do any good. Instead, we need to actually do some math to find out whether we should still accelerate the rotation towards the target or reverse it, based on our angular velocity and the thrust available.

Gentlemen

Edited January 2, 2014 by mockingking

[BlackBicycle]

Not sure what you are getting to. Any maneuver like that (supposing you want it to be done as quickly as possible) is half the rotation full thrust there, the second half full thrust in the opposite (to stop the rotation).

Am I missing something, or are you just f... erm... messing with us?

[K^2]

At the same thrust, it will take the same amount of time and degrees rotated to stop as it took to accelerate to that point.

In a perfect world, yes. In the real world, axis of rotation will probably tumble, and you'll end up with a different RCS orientation than you started out with, requiring a different amount of RCS thrust to stop moving. That's even if you started out with a nice symmetry in RCS port arrangement, which isn't a guarantee. Result is that it can take more or less time and fuel to stop rotation than it took to start it, depending on how things align.

Rotation optimization problems in 3D are actually crazy difficult, because rotations are cyclic, do not commute, and axis of rotation rarely coincides with principal axes. Fortunately, an approximate solution is almost always good enough, and these are easy enough to crank out.

[mockingking]

Not sure what you are getting to. Any maneuver like that (supposing you want it to be done as quickly as possible) is half the rotation full thrust there, the second half full thrust in the opposite (to stop the rotation).

Am I missing something, or are you just f... erm... messing with us?

Rest assured, nothing is further from my mind than mucking with the people I'm trying to get to help me!

Think of moving targets. If you plan a rotation (or a zero-zero intercept) in advance, but the target accelerates in whatever fashion, then by the time your manoeuvre is finished your target's position will no longer correspond to your heading (or new position). This necessitates the real-time calculation of the point of turnover from acceleration to deceleration, unless one tolerates a degree of inefficiency o.O

[tavert]

So you're saying you're trying to track a moving target in an optimal way? Sounds like you want to write an estimator (some form of Kalman filter) using as many past and current measurements of the target as you can get, along with a best-approximation model of the target's dynamics, and a best-guess prediction of its future acceleration (which might just be zero, if you don't have any better idea). Then you want to solve a constrained finite-horizon optimization problem to reach the target in a way that minimizes a weighted combination of time to intercept and fuel use, subject to a model of your dynamics, sensor measurements, and estimation/prediction of the target's dynamics. Assuming you have enough computational power to solve this optimization problem in real time, you repeat this process every time you obtain new sensor measurements of the target, updating your predictions accordingly. This is known as receding horizon or model predictive control.

Edited January 3, 2014 by tavert

[K^2]

Assuming you have enough computational power to solve this optimization problem in real time, you repeat this process every time you obtain new sensor measurements of the target, updating your predictions accordingly. This is known as receding horizon or model predictive control.

I found that in most problems of this type, the optimization algorithm is iterative, and you can put a filter update and optimization iteration into the same loop. That way, you get continuous tracking without major overhead.

So for the most basic example, write functional you want to optimize, get the latest position/velocity, run Kalman update, run a single step of Gauss-Newton on the input vector and functional to be optimized, rinse, repeat. (P.S. I've written something like this for Wires in GMod to fire tracking missiles at other players on the server, albeit, with a simpler filter and just a simple Newton algorithm step. Was fun.)

But I have a feeling that all of this is a bit overwhelming for the OP. I'd recommend starting with something much simpler.

Edited January 3, 2014 by K^2

[mockingking]

True enough, this all seems awfully complicated for what I thought to be a fairly simple problem.

Is there really no more compact way of calculating *during the turning process* whether the ship needs to switch to deceleration in order to avoid overshooting?

[tavert]

I found that in most problems of this type, the optimization algorithm is iterative, and you can put a filter update and optimization iteration into the same loop. That way, you get continuous tracking without major overhead.

So for the most basic example, write functional you want to optimize, get the latest position/velocity, run Kalman update, run a single step of Gauss-Newton on the input vector and functional to be optimized, rinse, repeat. (P.S. I've written something like this for Wires in GMod to fire tracking missiles at other players on the server, albeit, with a simpler filter and just a simple Newton algorithm step. Was fun.)

Yeah, do as many optimization iterations as your computational power and sensor sampling time allows. It becomes considerably more difficult to get provable guarantees of feasibility and strict descent for a single iteration when your control inputs and/or states need to satisfy hard constraints. The constrained optimization algorithms that converge most reliably and in the fewest number of iterations are unfortunately the ones where intermediate iterates are infeasible. Most people do an unconstrained optimization and just saturate the results, but you're very lucky if your problem is simple enough for that to actually be the right thing to do in the presence of constraints.

But I have a feeling that all of this is a bit overwhelming for the OP. I'd recommend starting with something much simpler.

Simple problems are so much less interesting...

[K^2]

Is there really no more compact way of calculating *during the turning process* whether the ship needs to switch to deceleration in order to avoid overshooting?

There are many simple ways to get a turn without overshooting. Difficulties start when you want it to be optimal in some sense.

For simple maneuvers, you can use PID, for example. That's what KSP uses for ASAS. It's not great for rotations, but you can figure out the right coefficients to make sure you never overshoot. If target is moving, you can also have PID work in a rotating frame where it's roughly stationary. It's far from perfect, but it's simple, and it's enough in a lot of applications.