Predictable autopilot AI for a physics-based spaceship moving on a 2D plane

Started by
14 comments, last by emirtaessss 9 months, 3 weeks ago

Good day to you all!

I'm trying to implement a physics-based movement of a space ship on a 2D plane. The space ship has 3 degrees of freedom achieved with 8 thrusters: forward- and backward-facing, to the both sides and paired rotational left and right (rotational thrusters do not affect lateral movement). Each of the thrusters apply force that results in the ship having acceleration. Each of the forward, backward, side and rotational thrusters are independent and differ in force they apply. The ship, despite being in a medium without resistance, has a maximum translational and angular velocity. My task is to implement the ship to move following the time-optimal trajectory and stop at the target location.

With only translation, the implementation is easy - calculate the deceleration distance, accelerate until this distance to target, then decelerate.

When adding rotation, maximum acceleration on the axes changes. The most basic approach I could come up with is adding velocity vector to target while eliminating any velocity vector away from it. It could happen that the optimal strategy would be to accelerate until maximum speed, turn around, then decelerate using the main thruster.

Apart from the [steering behaviours](http://www.red3d.com/cwr/steer/gdc99/), are there any frameworks, SDKs, engines, open-source projects, articles I can use either as a reference or to educate myself on how to best approach solving the problem? I would greatly appreciate any tips!

Thanks!

Advertisement

matskosan said:
With only translation, the implementation is easy - calculate the deceleration distance, accelerate until this distance to target, then decelerate.

I use this same approach for both angular and linear motion. Usually i try to keep acceleration constant, so the problem definition is target position, desired velocity at the target, current velocity, constant acc, constant decel. Then we can calculate the point in time when we need to switch from acceleration to deceleration to hit the target at desired velocity. Works for 6 dof the same way as for 1 dof.

But i see in your case the orientation also affects the direction of linear acceleration, and i can't commend on that.
I assume for space travel the planning reduces to the ideal trajectory to the target minimizing fuel, utilizing gravity of planets or moons.
Orientation can be likely ignored to calculate the trajectory, and after that the slight adjustments to keep ship orientation aligned to ideal trajectory are negligible.
Or in other words: Angular control seems more about error correction but usually isn't part of the control problem itself.

But it's not clear if that's the kind of problem you try to solve. Makes sense for solar system space travel planning and simulation, but not so much for space battle action / strategy games, i guess.
Maybe you want to give some examples of specific problems you have, otherwise it's hard to propose solutions to unknown problems. (But just saying - i doubt i could help even then, but others might.)

You certainly want to control position, but do you want to control the velocity and/or angle when you reach checkpoints or to optimize over different velocities and angles? Do you want to control angular velocity (e.g. to spin fast and spray unaimed weapon fire in all directions) and/or facing of the ship?

Omae Wa Mou Shindeiru

JoeJ said:

matskosan said:
With only translation, the implementation is easy - calculate the deceleration distance, accelerate until this distance to target, then decelerate.

I use this same approach for both angular and linear motion. Usually i try to keep acceleration constant, so the problem definition is target position, desired velocity at the target, current velocity, constant acc, constant decel. Then we can calculate the point in time when we need to switch from acceleration to deceleration to hit the target at desired velocity. Works for 6 dof the same way as for 1 dof.

But i see in your case the orientation also affects the direction of linear acceleration, and i can't commend on that.
I assume for space travel the planning reduces to the ideal trajectory to the target minimizing fuel, utilizing gravity of planets or moons.
Orientation can be likely ignored to calculate the trajectory, and after that the slight adjustments to keep ship orientation aligned to ideal trajectory are negligible.
Or in other words: Angular control seems more about error correction but usually isn't part of the control problem itself.

But it's not clear if that's the kind of problem you try to solve. Makes sense for solar system space travel planning and simulation, but not so much for space battle action / strategy games, i guess.
Maybe you want to give some examples of specific problems you have, otherwise it's hard to propose solutions to unknown problems. (But just saying - i doubt i could help even then, but others might.)

The specific problem is just that, as described in the original post - the ship that can aceelerate and rotate, with variying forward/backward/side accelerations, being able to reliably arrive at the target destination in a minimum possible time.

I'm trying to solve a more “local space” movement for now - the interplanetary travel is not out of the question, but is something for the future. I'm trying to create tactilal battles movement with predictable ship controls. Fuel weight is definitely not among the variables I would like to consider for movement calculations. Orientation is improtant both for combat (with ships having front and side facing weapons) and movement (front-facing thrusters are weaker than back-facing, and side-facing are the weakest). The action should evoke carrier movement, The Expanse, or Battlestar Galactica. There are other variables, such as decreased maneuverability on high speeds, but this is also for the later time when I am able to understand how to implent the simplest system…

@LorenzoGatti Eventually I would like to control velocities (both translational and angular) and orientation. For starters, maybe it would be simpler to have the implementation that controls just the position?

If you want physics-based movement, then you need some kind of control system to abstract that part from the navigation, same as in real vehicles (quadcopter drones are an example). You need something like a PID controller to adjust the thrusters dynamically so that the ship has the right speed and orientation.

There should be 3 modules:

  • Global planner that does A* or something like that to plan a complete path to the final goal position. This path is made up of a series of intermediate goal positions. This module produces the next intermediate goal that is fed into the next module.
  • Local motion planner that chooses the current high-level heading and speed that will reach an intermediate goal position. If your ships are non-holonomic (can't move in any direction i.e. like a car) then you have to do extra work here to control steering.
  • PID controller to translate high-level desired motion into low-level thruster values. This may not be simple because you have multiple thrusters that interact, so it might involve solving a small system of equations.

I wouldn't focus on doing it in a “minimum possible time”, that's too difficult a problem. Physics-based movement is already challenging enough. Start with the local planning, and just kinematic control over vehicles (set velocities directly), then add the PID controller and finally global planner.

matskosan said:
the ship that can aceelerate and rotate, with variying forward/backward/side accelerations, being able to reliably arrive at the target destination in a minimum possible time.

I have some naive idea, which might be a start, but surely predictable at least:

The red arrow is the current velocity and position, the green arrow is target vel and pos.

To construct a trajectory you could use a Bezier curve.
1st and 4th control points are start and target pos, 2nd is start + start vel * k, 3rd is target pos + target vel * -k

k is some constant, of which i have no idea how to get it. Obviously it should be 1 to match velocities, but not sure if a Bezier spline is a proper way to represent physics at all.

Once the trajectory is calculated, following it wouldn't be hard.
Maybe you figure out a way to formulate an optimization problem, so an iterative approach could minimize the needed time.
Maybe you get some equation to describe the whole problem along the way, and you could use tools like Mathematica to find a closed form solution, which might exist or not.

I guess some people already tried to solve this before. Maybe NASA papers… : )

JoeJ said:
Maybe NASA papers… : )

My guess is that NASA is optimizing more for fuel usage than minimum time, so they are determining how to reduce the time that rockets are fired to get somewhere. This is why they use gravity of planets to increase speed by “slingshot” maneuvers, and also choose launch date precisely so that the planets are in the right places to do this.

I think it would be simpler and more flexible to use exponential smoothing to slowly change the speed and heading angle to the target values, than to use Bezier curves.

Hehe, NASA optimizes for fuel, Musk optimizes for time. Cuz he's a gamer and gets all the gov $$$ NASA might want \:D/

Hi @Aressera, thanks for your suggestions! I have already briefly tried a PID-based approach - it worked quite well for the orientation, but I got stuck when implementing the position control. Also there was an opinion that since all the variables of the system are known, its inputs can be calculated directly and PIDs are not necessary. Perhaps, I should have tried harder with the PIDs? I like your suggestion with controling the velocity directly, but in that case the problem collapses to the one where orientation is constant or acceleration is equal on all axes, and it is simple to solve.

I also have looked through some control theory / NASA papers and started to refresh my math and optimal control theory knowledge, but… this will take some time to make it right and be confident about it.

This topic is closed to new replies.

Advertisement