Jump to content

Programming Starship (work in progress)


Recommended Posts

Posted (edited)

Hello all! Will make it quick:

* Programmer by trade (but completely unrelated to spaceflight)
* Absolutely fascinated by the tvc and flaps control of starship
* But absolutely no idea how this could be achieved in code
* But spaceflight noob
* But  ksp noob

Took the last year to gradually learn how to control starship using my own plugin written in C#.
The video above shows my current progress. Ascent, flop, descent, flip work roughly. Landing left.
Full code can be found here: https://github.com/xgleich1/starship

Would like to describe my yourney from the beginning  and in detail once this post is approved and if you are interested.
Could contain hints on how the real flight software potentially could look like.
Example: How can you make  sure that you can yaw/roll/pitch at the same time with the flaps?

Finally and most importantly: Big thanks to ksp and the whole ksp community, without you I could have never done this. Special mentions:

-> For providing the means to find a starship vehicle for a complete builder noob

-> Documentation which helped a lot while coding

-> For teaching the basics in making a plugin

https://spacedock.info/mod/2643/Kerbal Telemetry
-> For being an awesome reference on how things could be done with a plugin

Edited by Ferranis
Link to comment
Share on other sites

Way more complex than anything I've ever done in KSP. You should send this to SpaceX. If you can make it work in the game I imagine you have the skills to make it work in the real world, so maybe they'd give you a job. :)

Link to comment
Share on other sites

Posted (edited)

Step 1, Control The General Throttle

Initial consideration: How to even start with this?

Two things must be possible: Starship needs to be controlled via code and it must roughly adhere to physics.
Building an own graphics and physics engine is out of the question. Luckily I heard of MechJeb and that ksp
is pretty accurate physics-wise.

Learning the very basics of plugin development via the wiki was next. Even though the wiki is good this
was a lot of trial and error, not helped by plugin-development being done in C# (never programmed in C#).

The main takeaway was how to integrate a plugin into ksp, which is to create a PartModule
(current iteration: https://github.com/xgleich1/starship/blob/master/Starship/FlightComputer.cs)
and to integrate it into a Part (current iteration: https://github.com/xgleich1/starship/blob/master/meta/Integration/navLight1.cfg)
which then can be added to the vessel.

With this knowledge I build (with lot's of trial and error!) the code to control the general throttle. Which is the same as when you throttle ingame.
To no ones surprise this leads to a crash, since there is no gimbaling yet.

Insights which might be applicable to the real thing:

* Without gimbaling starship crashes shortly after liftof f [snip]
* You have to lock the flaps in deployed position. Flaps back make the ship very instable, especially in pitch

Edited by Vanamonde
Mind the language, please.
Link to comment
Share on other sites

Step 2, Control The Engines Throttle

The goal for this project is to be as close to reality as possible. Meaning we have to control everything fine grained and can't rely
on the convenience ksp provides for us. In this step it was the throttling of the engines. Each of the three engines need to be throttled individually.

Already existing ksp plugins helped tremendously and showed me how to first find the engine in code via vessel.FindPartModulesImplementing<ModuleEngines>()
and then to individually throttle them via engine.useEngineResponseTime = true (current iteration: https://github.com/xgleich1/starship/blob/master/Starship/Control/Throttle/Main/MainEnginesThrottleControl.cs).

Difficult was to find the right code abstraction for the engine control, meaning I want the low level details of the control as far away as possible from my "business logic" of controlling starship.
This helps to make the business logic clear and easily testable, since you don't have to meddle with low level details and potentially untestable classes from ksp.

The result is shown in the video above. A single engine is throttled to the max. You have to be careful though, when you throttle more than the max it just explodes!

Insights which might be applicable to the real thing:

Link to comment
Share on other sites

Posted (edited)

Step 3, Control The Ascent Naively

Continuing the goal to control everything as fine grained as possible with gimbaling the engines. Sadly, I could not meet this goal here.
There seems to be no way to gimbal each engine individually with code, you have to simulate player inputs and let ksp figure out how to gimbal in response.

After figuring this out I used simulated player inputs to build a very naive control algorithm: Steer a fixed amount left when starship steers right and vice versa
in all directions (with other words, not even proportional control, where you steer in relation to the deviation). Unsurprisingly the ship becomes unstable very fast.

Here one of the most complicated problems started: How to figure out the attitude of starship (its current yaw/roll/pitch). I tried nearly every solution
out there in other plugins, but neither gave me the values I want: signed and independent yaw/roll/pitch. At the end I settled with using the angular velocity
ksp provides and from there calculating the current yaw/roll/pitch in degrees (current itetation: https://github.com/xgleich1/starship/blob/master/Starship/Sensor/Attitude/AttitudeSensor.cs).
This seems to be good enough for the current flight path.

Insights which might be applicable to the real thing:


I tried to gimbal each engine individually by putting them on hinges...


Edited by Ferranis
Link to comment
Share on other sites

Step 4, Control The Ascent Proportionally

The goal in this step was to have a stable ascent, meaning no change in yaw/roll/pitch.

To achieve those I used the simplest regulator, since I did not know much about regulators and even less about their math:
A proportional regulator. Today the regulator got to a point of being  a full blown PID regulator
(current iteration: https://github.com/xgleich1/starship/blob/master/Starship/Flight/Regulator/PidRegulator.cs),
but this was the beginning.

A proportional regulator does the following: If there is a very small deviation from the flight path - gimbal only a small amount,
if there is a big deviation, gimbal a large amount. This is achieved by multiplying the current flight path error with a fixed
constant. For example: Error = 10 degrees * fixed constant = 0.1 -> 1% gimbal. The constant was derived by trial and error.
Going too less results in the error never vanishing and going too much makes the ship swing wildly, since the gimbaling overcorrects.

Insights which might be applicable to the real thing:

- The ascent of starship can be controlled by a very simple proportional controller, if you don't have large interfering forces, like engine outs or wind.

Link to comment
Share on other sites

  • 4 weeks later...
  • 4 weeks later...
  • 2 weeks later...

Step 5, Control The Belly Flop Naively

The goal in this step was to bring starship into belly flop position.

To achieve this, I first build the infrastructure to control the flaps. For "finding" them in code, KSP provides a method  which
allows searching for all vessel-parts which implement so called modules.  A flap implements a ModuleRoboticServoHinge, for example.

Once found, I extracted the minimum and maximum angle of the hinges. With them it was possible to deploy the hinge to my linking,
which is as a percentage (example: deploy flaps 50%). Deploying as a percentage allows changing of the minimum and maximum angle
in the vab, without changes in the code. The absolute deployed angle might change, but 50% is always 50%:

private static void ActuateFlap(ModuleRoboticServoHinge flap, float deployPercent)
    var minimumAngle = flap.softMinMaxAngles.x;
    var maximumAngle = flap.softMinMaxAngles.y;

    var deployedAngle = (maximumAngle - minimumAngle) * deployPercent;

    flap.targetAngle = minimumAngle + deployedAngle;

The full code to find and control the flaps can be found here:

It's used to retract the aft flaps when flipping and to deploy them in a centered position afterwards.
In the next step this position will be the starting point to achieve a controlled descent by moving the flaps.

Finally, I used the engines to gimbal violently for a second or so to rotate starship into belly flop position.  RCS firings, like on the real thing, were not needed in KSP.
In these cases I follow the strict rule to only build what I really need (and I have barely the skill to do what is needed :D).

Insights which might be applicable to the real thing:

- When the flaps are not fully deployed on ascent we get a very unstable flight. Especially in yaw, as far as I remember.  Complicated aerodynamics, for sure
- When the front flaps are not fully deployed when flipping we get a very unstable flip. Especially in roll, as far as I remember.
   Front flaps fully deployed, aft flaps fully retracted seems to be naturally stable
- Rotating starship into belly flop position is very hard when the aft flaps are not retracted. They seem to "push" starship back into vertical
- The gimbaling for the belly flop is deceptively simple. It is literally: Max pitch gimbal for a second. No fine grained gimbal regulation needed

Edited by Ferranis
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...