Author Topic: Looking for information on making a TVC system for a vehicle  (Read 937 times)

Offline Derpiesaurus

  • Member
  • Posts: 5
  • Liked: 0
  • Likes Given: 4
Hello,

This is my first post, so I apologise if it's in the wrong place, and the many other things I probably did wrong.. ;D

For a while now I've been trying to control a rocket using thrust vector control (hovering, translating laterally, holding attitude), and while I have (surprisingly) managed to figure out the PID logic behind those three examples, I haven't been able to integrate it reliably into a small test rocket, or a very large/heavy vehicle like Starship.

All the testing / simulations are done in a game called Space Engineers (essentially space minecraft), of which there is a block that allows you to control hinges, rotors, pistons, etc, with C# code, which is what I'm using.


So to get to my actual problem, I haven't been able to figure out how to get my vehicle's mass moment of inertia. Now I should say that I'm just coming back to this project, after about a month of not doing it, so I'm half relearning the concepts, but I am 100% sure I did get stuck, even when I knew it all, so bare with me if I get some stuff wrong, but I'll do my best to explain:

I need the inertia of my vehicle so I can calculate how fast it will turn when x torque is applied to it, and then with that I can predict how much torque I need and when to stop it from doing circles in the air trying to control itself. Just controlling based on the commanded angle - current angle sorta works for smaller vehicles, but Starship sized and heavy vehicles are a big no go with that method. The best tutorial ish thing I found was this video:

(EDIT: Doesn't play at the time I set the link at, so it's about 3:15 into the video that I meant to show)

I am able to get the distance between my TVC mount and my CoM in Space Engineers, but I have no way to reliably rotate the vehicle like shown in the video to calculate the inertia. I know there's a more complicated way of calculating the inertia, which I genuinely don't mind doing/learning, but because I haven't learnt even the actual concepts of the things I don't know, I have no clue what I should learn to be able to calculate it. Especially when it's a complicated shape like Starship (which is my end goal to control). This is essentially what I'm writing this post to look for.

So if anyone knows sorta what I'm trying to get at then I'd really appreciate it if you could suggest some stuff! Or maybe if anyone knows if there's a "beginner's guide to TVC" sorta thing that goes through it all.

Thanks (and sorry again if this is really out of place)!
« Last Edit: 08/12/2022 02:16 am by Derpiesaurus »

Online laszlo

  • Full Member
  • ****
  • Posts: 574
  • Liked: 734
  • Likes Given: 267
The Youtube presenter is essentially using a model of his rocket as an analogue computer to avoid a long computational problem. The computational method, on the other hand, removes the limits imposed by a model letting you use arbitrarily sized objects with arbitrary shapes.

The basic concept is to divide up your object into many smaller sub-objects, calculate each one's MOI and sum them to get the large object's MOI. The more and smaller the sub-objects, the more accurate the result. The limit of the sum as the the objects go to infinity in number and become infinitely small is the exact answer. By now you should have recognized that this is a problem in integral calculus so you can use calculus instead of actually dividing your rocket into an infinite number of infinitely small objects.

Here's a link to a quick introduction on how to do all this https://www.thoughtco.com/moment-of-inertia-formulas-2698806 . It also includes some pre-calculated formulae for various simple shapes. Depending on your overall shape, you could break it down into a collection of simple ones, calculate each one and sum them to get the total.  For example, if your spacecraft looked something like the Discovery from 2001: A Space Odyssey, you could model it as a hollow sphere at the end of a hollow cylinder with a flat plate at the other end, plug in the dimensions and distances for each component, use the formulae to calculate each MOI and then sum them all together to get the spacecraft's total MOI.

This page is just the very simplest introduction. There's a lot more, as googling "calculate moment of inertia" will show, but at least now you should be able to see how to get away from using physical models.

Finally, many CAD programs will calculate the MOI, and many other quantities, for you when you use them to model your object.

Have fun.

Online edzieba

  • Virtual Realist
  • Senior Member
  • *****
  • Posts: 4428
  • United Kingdom
  • Liked: 6461
  • Likes Given: 35
You're going to face the added issue that "Space Engineers" will be using a physics model that does not necessarily match actual real-world physics, and that alternate physics is what you need to be using in your model for control loop tuning. No good tuning your control loop for the real world for an application that is not in the real world.

Offline Derpiesaurus

  • Member
  • Posts: 5
  • Liked: 0
  • Likes Given: 4
By now you should have recognized that this is a problem in integral calculus so you can use calculus instead of actually dividing your rocket into an infinite number of infinitely small objects.

There's a lot more, as googling "calculate moment of inertia" will show

This is essentially what I'm after, thank you! Although I was thinking of mentioning calculus, since it's what I got stuck on when I last tried to solve this problem, and that specific example of cutting up the shapes into smaller ones is one that I found, I was REALLY unsure if I was remembering correctly. I don't know anything about calculus except pretty much the one phrase people use to explain it. But I'm more than happy to learn it, and learning things is 80% of why I'm doing this project!

You're going to face the added issue that "Space Engineers" will be using a physics model that does not necessarily match actual real-world physics, and that alternate physics is what you need to be using in your model for control loop tuning. No good tuning your control loop for the real world for an application that is not in the real world.

The game has relatively good physics by default, but I also have mods that add wind and atmospheric effects (allowing for lift, etc), so although those mods and the base game won't be as good as a billion dollar simulator, or the real world for that matter, it's at least based on the real world. So yes, in a way Space Engineers limits me, but my vehicle still has dimensions, mass and inertia, which all plays a part in figuring out how to control it. Pretty much everything used in the real world should at least provide decent information and clues towards making something in Space Engineers, I reckon at least.

Online edzieba

  • Virtual Realist
  • Senior Member
  • *****
  • Posts: 4428
  • United Kingdom
  • Liked: 6461
  • Likes Given: 35
The game has relatively good physics by default, but I also have mods that add wind and atmospheric effects (allowing for lift, etc), so although those mods and the base game won't be as good as a billion dollar simulator, or the real world for that matter, it's at least based on the real world. So yes, in a way Space Engineers limits me, but my vehicle still has dimensions, mass and inertia, which all plays a part in figuring out how to control it. Pretty much everything used in the real world should at least provide decent information and clues towards making something in Space Engineers, I reckon at least.
Game physics engines can be incredibly far from actual physics without being immediately obvious, and lack many fundamental features like friction (to make an analogy, game physics engines today are to real physics what the N64's graphics were to modern path tracing engines). e.g. the engine could decide any rigidly joined objects are perfectly rigid and homogenous, and instead of calculating moment of inertia just sum the total masses and consider the object a point mass at the assemblage's geometric centre and use a fixed term for MoI. You'll find lots of shortcuts taken with linear terms used in place of non-linear ones, variables replaced with fixed values, etc. Physics models are far harder than they first appear, and are why programs like Orbiter can model orbital mechanics well enough to match actual missions, but placing an object onto the surface of a planet will occasionally have it spontaneously bounce up into the air of their own accord due to rigid body contact issues.
As I understand it, the physics engine used is exceptionally basic and the stock game does not even support off-axis thrust (all thrust regardless of engine location is assumed to be applied through the centre of mass and torque is always 0), so thrust vectoring as you desire to implement is not possible without modding.

Offline Derpiesaurus

  • Member
  • Posts: 5
  • Liked: 0
  • Likes Given: 4
Game physics engines can be incredibly far from actual physics without being immediately obvious, and lack many fundamental features like friction (to make an analogy, game physics engines today are to real physics what the N64's graphics were to modern path tracing engines). e.g. the engine could decide any rigidly joined objects are perfectly rigid and homogenous, and instead of calculating moment of inertia just sum the total masses and consider the object a point mass at the assemblage's geometric centre and use a fixed term for MoI. You'll find lots of shortcuts taken with linear terms used in place of non-linear ones, variables replaced with fixed values, etc. Physics models are far harder than they first appear, and are why programs like Orbiter can model orbital mechanics well enough to match actual missions, but placing an object onto the surface of a planet will occasionally have it spontaneously bounce up into the air of their own accord due to rigid body contact issues.
As I understand it, the physics engine used is exceptionally basic and the stock game does not even support off-axis thrust (all thrust regardless of engine location is assumed to be applied through the centre of mass and torque is always 0), so thrust vectoring as you desire to implement is not possible without modding.

Yeah I do also have a mod that applies thrust at the CoM of the thruster, I believe? Haven't looked at it in a while but it does allow for TVC. One thing I just realised I should say, is that what I'm doing in Space Engineers is my end goal, I don't have any plans of simulating a launch in SE and then replicating it in real life, so that might play an important role in deciding whether or not it's simulated realistically enough. Since, as long as I can control a vehicle using thrusters in SE, I'm happy. And from my attempts, the only limitation appears to be my knowledge of calculus and trigonometry, for doing that.

That is a good point though, and I would definitely look for something that is specifically made for simulating vehicles and the like, rather than a game, if I was going to launch a real thing (it does sort of make me wonder how close something like KSP is to a proper simulation, since that too is a game, and people seem to say it's quite accurate).

Offline Barley

  • Full Member
  • ****
  • Posts: 605
  • Liked: 379
  • Likes Given: 208
IIUC Space Engineers uses a voxel based model.  Summing over all the voxels in your model should be roughly the same as integrating to calculate the total moment of inertia of your model.  This could be considered a variety of finite element analysis.

You may also be able to "experiment" in the virtual world.  Put your model in free fall (orbit) and apply a known angular impulse and then watch and measure how fast it spins.   This is the analog of measuring the mass of your model by applying a known impulse and seeing how fast it goes.   The easiest way to apply a known angular impulse is to add a small pair of thrusters with known thrust and duration.




Offline Derpiesaurus

  • Member
  • Posts: 5
  • Liked: 0
  • Likes Given: 4
IIUC Space Engineers uses a voxel based model.  Summing over all the voxels in your model should be roughly the same as integrating to calculate the total moment of inertia of your model.  This could be considered a variety of finite element analysis.

You may also be able to "experiment" in the virtual world.  Put your model in free fall (orbit) and apply a known angular impulse and then watch and measure how fast it spins.   This is the analog of measuring the mass of your model by applying a known impulse and seeing how fast it goes.   The easiest way to apply a known angular impulse is to add a small pair of thrusters with known thrust and duration.

This sounds like a much easier way, and yes SE is voxel based. I partially understand how I would go about doing your second suggestion, not too sure of the Maths behind it, but I'm sure I could figure out what to search up, but the first suggestion (the one I preferably would want to use because it would hopefully remove user error) I don't really know where to start. Could you elaborate on "Summing over all the voxels", do you mean adding up all the volume and mass of the voxels to get some number (even then I'm not sure what I'd do)? Essentially, explain like I'm 5, if that's possible? :P
« Last Edit: 08/12/2022 02:08 am by Derpiesaurus »

Online edzieba

  • Virtual Realist
  • Senior Member
  • *****
  • Posts: 4428
  • United Kingdom
  • Liked: 6461
  • Likes Given: 35
Since a mod is being used to allow for off-axis thrust, and the system only needs to work within the game engine and not outside of it: contact the mod author and ask what physics model they are using to calculate applied torque. It may be that MoI is not even involved in their physics model so calculating it can be skipped.

Offline Derpiesaurus

  • Member
  • Posts: 5
  • Liked: 0
  • Likes Given: 4
Since a mod is being used to allow for off-axis thrust, and the system only needs to work within the game engine and not outside of it: contact the mod author and ask what physics model they are using to calculate applied torque. It may be that MoI is not even involved in their physics model so calculating it can be skipped.

I just left a comment on Steam asking how the mod calculates the applied torque. Though, I'm a bit stuck at why that information would help? Wouldn't I still need to calculate the MoI and torque so my own program can predict where I need to move the thrusters to stop where I want to be? I currently just get the torque from a calculation based on gimbal angle, moment arm, etc, using trigonometry; but I don't know how else I'd be able to predict how fast I could stop (given x torque) without knowing the MoI?

Online edzieba

  • Virtual Realist
  • Senior Member
  • *****
  • Posts: 4428
  • United Kingdom
  • Liked: 6461
  • Likes Given: 35
Since a mod is being used to allow for off-axis thrust, and the system only needs to work within the game engine and not outside of it: contact the mod author and ask what physics model they are using to calculate applied torque. It may be that MoI is not even involved in their physics model so calculating it can be skipped.

I just left a comment on Steam asking how the mod calculates the applied torque. Though, I'm a bit stuck at why that information would help? Wouldn't I still need to calculate the MoI and torque so my own program can predict where I need to move the thrusters to stop where I want to be? I currently just get the torque from a calculation based on gimbal angle, moment arm, etc, using trigonometry; but I don't know how else I'd be able to predict how fast I could stop (given x torque) without knowing the MoI?
Because there is no guarantee whatever physics model the mod author used includes the MoI at all. For example, given the very basic physics engine used a simple linear function of total mass, thruster distance from CoM and thruster force could be being used without consideration for MoI. The control lay you write for your thruster needs to take into account the physics model the mod author is using, not real-world physics.

Tags:
 

Advertisement NovaTech
Advertisement SkyTale Software GmbH
Advertisement Northrop Grumman
Advertisement
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
1