[WIP] [Plugin] KerbCom Avionics - Analytical engine and RCS thrust balancing

[afranius]

I don't usually write my own solvers (I've written PGS for real-time LCPs, but that's about it), but from using external libraries, I generally find that adding more variables to linearly constrained problems tends to be much faster than switching to nonlinear constraints. For the lower spherical bound, since most engines only gimbal a little, you could probably get a pretty good pyramid approximation for the "floor" of the frustrum (so approximate the hemisphere with a pyramid). That way, the solution is exact at zero gimbal and full gimbal (where it will probably end up most of the time anyway), and is still feasible in the middle (just lower thrust). Anyway, just an idea, good luck

[ZRM]

Thanks for the advice. I think I will try this approach first. However I will need different approximations (like a segment of an n-gon) for VTOL engines that can rotate through a considerable range on one axis.

Also, I think the pyramid-floor would only be exact at zero gimbal and simultaneous full gimbal on both axes (i.e. 5 points total), as the true base of the pyramid has curved edges. I can imagine that full gimbal on one axis but not on the other is in fact one of the most common cases if not the most common case. But the approximation will still probably work adequately.

[Semni]

I seem to recall a mod much like this one. I'll see if I still have the plugin .dll though sadly I fear I don't have the source code.

[ZRM]

I seem to recall a mod much like this one. I'll see if I still have the plugin .dll though sadly I fear I don't have the source code.

Is it Throttle Steering? No disrespect to the author, but it is not very useful for precision manoeuvring, as it effectively gives RCS-like control over engines. And since stock RCS control does not balance thrust at all, it is not very useful since it can't balance a hovering VTOL craft (for example) in an equilibrium state at all.

[ZRM]

Progress Update:

The new solver is now working as expected. What I am surprised by is the performance. While I was developing it, I had Debug.Log calls everywhere to dump the solver state at every opportunity so that I could track down problems. During this process, a simple small CSM with 8 thruster blocks was getting 3-4 FPS. I now know that that low performance was caused purely by the logging. After disabling those calls I have yet to find any vessel that has a noticeable performance drop from stock with this new solver. Even with several hundred RCS ports. And this includes the auto-calibration on every update, effectively calling the solver twice more than the original prototype. Needless to say I am quite pleased with this result. Pleased enough to post about it in this thread. I am not sure whether the multi-threading system is even needed (it is currently not in use). Though I expect some people may notice a performance hit on considerably less powerful machines. For reference I am testing on an i5 2500K at 3.8GHz.

Now I will implement the engine balancing (VTOL) mode. Then I will release version 0.2 (I am skipping Inertia Tensor reimplementation for the time being).

Edited June 18, 2013 by ZRM

[ZRM]

Progress Update:

I have now finally gained control over the individual throttles of engines and added a new interface window for managing engine control settings. Now, in theory, there are no technical hurdles left in the way of implementing engine thrust balancing. Unfortunately I won't be able to work on this project again until Monday, so do not expect any more updates before then.

[evilC]

Unfortunately I won't be able to work on this project again until Monday, so do not expect any more updates before then.

But I want it nowwwwwwwww

Seriously, can't wait for decent VTOL.

Will it cater for a non-central CoG?

eg a VTOL craft carrying a rover - the CoG may be slightly off.

If not, could you maybe add a way to trim the engines so we can alter the balancing ourselves?

One way to do this would be to add an action group - if we anticipate forward/back imbalance, we can add the fore and aft pair of engines to a pair of action groups and trim each pair appropriately.

[ZRM]

But I want it nowwwwwwwww

Seriously, can't wait for decent VTOL.

Will it cater for a non-central CoG?

eg a VTOL craft carrying a rover - the CoG may be slightly off.

If not, could you maybe add a way to trim the engines so we can alter the balancing ourselves?

One way to do this would be to add an action group - if we anticipate forward/back imbalance, we can add the fore and aft pair of engines to a pair of action groups and trim each pair appropriately.

Non-central CoG is the whole point of implementing engine balancing for VTOLs. So yes, it will cater for that, perfectly. No trim required. Automatic support for arbitrary engine number/layout/types with no user configuration. It can be combined with RCS control, e.g. if the VTOL engines cannot induce yaw on the vessel (as is commonly the case for vertical engines), the RCS can be set up to only act for yawing input to complement the VTOL control.

[evilC]

I wouldn't necessarily say "the whole point" - even with a perfectly centered craft, you cannot control a VTOL like it were a VTOL plane - you must use RCS or torque to rotate.

It is, however, the "holy grail". ThrottleSteering was a tantalizing taste, this sounds like an all-you-can-eat buffet

[Fel]

Bit of a question.

You're doing a linear equation solver; and use this each time the player specifies a new thrust vector.

Is it MATHEMATICALLY FEASIBLE to, provided the fueltanks empty as setup, and mono-propellant drains "as such"; could you not create a function that dictates the movement of the CoM until a part gets jettisoned?

Furthermore, using said CoM function, could you then apply the bounds to your solver to extrapolate a function that solves for a particular thrust vector at a given shift in CoM?

And then, based off of a set of vectors (i.e. pitch, roll, yaw), could we thus extrapolate a function that returns approximate values for each thruster without requiring the real-time integrals + matrix operations?

*Plugin looks interesting; I just remain wary of how intensive the math might be on a fairly old system.... and even though I probably lack the experience of applying the maths that I know in order to modify to my specifications; I'm curious if it is even plausible to begin with.

[ZRM]

I wouldn't necessarily say "the whole point" - even with a perfectly centered craft, you cannot control a VTOL like it were a VTOL plane - you must use RCS or torque to rotate.

It is, however, the "holy grail". ThrottleSteering was a tantalizing taste, this sounds like an all-you-can-eat buffet

OK, maybe not "the whole point". But it is a pretty large part of the problem. Being able to solve for that in particular implies you can solve the system in ways that allow proper VTOL control.

[ZRM]

Bit of a question.

You're doing a linear equation solver; and use this each time the player specifies a new thrust vector.

Is it MATHEMATICALLY FEASIBLE to, provided the fueltanks empty as setup, and mono-propellant drains "as such"; could you not create a function that dictates the movement of the CoM until a part gets jettisoned?

Furthermore, using said CoM function, could you then apply the bounds to your solver to extrapolate a function that solves for a particular thrust vector at a given shift in CoM?

And then, based off of a set of vectors (i.e. pitch, roll, yaw), could we thus extrapolate a function that returns approximate values for each thruster without requiring the real-time integrals + matrix operations?

*Plugin looks interesting; I just remain wary of how intensive the math might be on a fairly old system.... and even though I probably lack the experience of applying the maths that I know in order to modify to my specifications; I'm curious if it is even plausible to begin with.

That method may be practically as expensive as if not more expensive than the normal solver. Most of the computation in the solver goes towards satisfying the constraints. You have still got to satisfy these constraints (all 38+ of them on most vessels) when updating your proposed approximation, otherwise the vessel drifts and/or the engines/thrusters cannot fire.

Anyway, the new solver is really quite efficient. I would wager that it is orders of magnitude (read: around a 100x) faster than the currently released version. I would not worry about it potentially being slow on your machine until you actually experience this. You must remember that the old solver was a generic nonlinear iterative approximation solver. The new one is linear and exact and tailored for the thrust balancing problem. It uses a linear amount of memory relative to thruster/engine count.

Edit:

By the way, the solver runs every frame, not just when the input changes, since other variables change every frame, such as CoM and MoI (due to fuel movement and structural flexing), operational status of thrusters/engines, etc.

Edited June 23, 2013 by ZRM

[Fel]

So you're saying that the complexity of the individual equations used in the extrapolation would either require an excessively large amount of computing power at start (which... well... yes...) or still require a significant amount of calculation such that solving it would be faster (I remain somewhat wary on this response; extrapolation and bounds should always be able to simplify a model with an acceptable degree of error.)

Of course, if the equations you are now using are specialized for thrust vector calculations; that would indicate that they are already utilizing said techniques.

*This is mostly over curiosity now; I am glad to hear that the new solver is much faster (the 120fps [which I could never get] down to 15fps on a heavy ended single core test tells me a lot about how quickly each additional RCS port increases the *words that I am saying*)

Edited June 23, 2013 by Fel

[ZRM]

So you're saying that the complexity of the individual equations used in the extrapolation would either require an excessively large amount of computing power at start (which... well... yes...) or still require a significant amount of calculation such that solving it would be faster (I remain somewhat wary on this response; extrapolation and bounds should always be able to simplify a model with an acceptable degree of error.)

Of course, if the equations you are now using are specialized for thrust vector calculations; that would indicate that they are already utilizing said techniques.

As I have mentioned a few posts ago, I am using a modified version of the Simplex method. If you look up the Simplex method and understand it, you will see how straightforward it is in its basic form. The computations are not complex (mostly Gaussian matrix transformations) and only a few iterations are required in most situations, especially so in such a problem as thrust balancing. I have optimised it for this case to reduce memory usage and save on unnecessary computation. It would even lend itself to dynamic parallelism easily, especially if Unity and Mono upgrade to the .NET 4.5 standard (then I can use Parallel.ForEach).

The situation in which I do foresee running approximations between iterations being potentially worth the effort is if I decide to implement a QCQP solver for engine gimballing, which by its nature will likely be much slower than the linear solver. However that is not on the immediate to-do list.

[Fel]

I think you strongly misunderstand my intention. The question there was not on the plugin, but in a mathematical-engineering sense.

Given the parameters of operation, find an equation to model the output based on the bounds of said parameters.

My question was if you were indicating that despite using bounds and interpolation a solver would still be faster than the resultant equation. (Negating how much time it would take to calculate and reduce equation.)

In theory though, that should alway be yes... you can get practically O(1) by using a table (negating memory, and time to construct).

However, if the "swing" of the equations was such that changing 1 parameter by say 1% caused the output to drastically change (increases the complexity of the model, requires a more accurate table, etc)

You listed a method of solve, what I am asking about is a model of the system as a whole.

** I think the question is better stated as "How strong is the 'swing'", ignoring constants (location of the RCS ports, thrust, available thrust vectors), and focusing on the dynamic parameters... does the result "swing" in such a manner that a direct solve is much better than trying to apply a model?

*Again, this is out of curiosity; not "how well the plugin works" or to be misconstrued as an insult of sorts.

Edited June 23, 2013 by Fel

[ZRM]

I think you strongly misunderstand my intention. The question there was not on the plugin, but in a mathematical-engineering sense.

Given the parameters of operation, find an equation to model the output based on the bounds of said parameters.

My question was if you were indicating that despite using bounds and interpolation a solver would still be faster than the resultant equation. (Negating how much time it would take to calculate and reduce equation.)

In theory though, that should alway be yes... you can get practically O(1) by using a table (negating memory, and time to construct).

However, if the "swing" of the equations was such that changing 1 parameter by say 1% caused the output to drastically change (increases the complexity of the model, requires a more accurate table, etc)

You listed a method of solve, what I am asking about is a model of the system as a whole.

** I think the question is better stated as "How strong is the 'swing'", ignoring constants (location of the RCS ports, thrust, available thrust vectors), and focusing on the dynamic parameters... does the result "swing" in such a manner that a direct solve is much better than trying to apply a model?

*Again, this is out of curiosity; not "how well the plugin works" or to be misconstrued as an insult of sorts.

Do not worry, I was not misunderstanding your intention. The method you are suggesting is probably "mathematically feasible", as are a lot of other things. However, practicality is what really matters to the plugin, which is why I chose to discuss the reasons why implementing your idea may not be as effective a use of time as other potential improvements.

What you describe as "swing", is better known in linear optimisation as "sensitivity".

The dynamic parameters include port location and thrust direction, as these can change due to joint flexibility or mechanical movement. Don't forget the CoM and MoI as well.

The function you describe to model the system is not continuous. Add to this that both its input and output are large vectors. Considering as well that the convex region in the n-dimensional space that the thrust values are constrained within does not necessarily have a constant number of vertices, I do not think it would be easy to create a tabular form to represent the function, especially in a reasonable amount of time and space. It may not even be that efficient to evaluate once constructed. But you are welcome to try, if you wish.

You can think of the current Simplex solver as one way of evaluating the function efficiently, without the use of a direct representation. There are many problems in industry and academia where linear optimisation using versions of the Simplex method is employed. If they could instead model the behaviour of the result they are looking for directly (as you suggest), they would probably do that, however they do not. This may suggest that it is prohibitively difficult to do so.

[ZRM]

Progress Update:

Right, VTOL engine thrust balancing is now actually working, albeit without active torque control. This means that all torque on the craft is only supplied by the RCS or command pod reaction wheel. I will now try to add torque control to the engine balancer, and also allow the engine balancer to make use of RCS in the same solver.

I have also realised from my numerous failed attempts that VTOLs are difficult to land without some kind of auto-hover functionality. I will see if I can implement such a feature. Unfortunately the MechJeb translatron and landing autopilot do not seem to be compatible with thrust perpendicular to the control forward axis.

[Photonically]

Progress Update:

I have also realised from my numerous failed attempts that VTOLs are difficult to land without some kind of auto-hover functionality. I will see if I can implement such a feature. Unfortunately the MechJeb translatron and landing autopilot do not seem to be compatible with thrust perpendicular to the control forward axis.

If you do include this feature, would it be able to handle jet engines with (long) warm-up times? Jets are a lot more suitable for VTOLs that don't run out of fuel in 30 seconds flat, but they do throw off Mechjeb's translatron a little too.

[ZRM]

If you do include this feature, would it be able to handle jet engines with (long) warm-up times? Jets are a lot more suitable for VTOLs that don't run out of fuel in 30 seconds flat, but they do throw off Mechjeb's translatron a little too.

Probably. The trick with all jet throttle changes is to do it slowly¹, as the response time on them acts like a low pass filter over the throttle. If I can just provide a setting to control how fast the hover autopilot expects the vessel to be able to change thrust, it should be able to account for this behaviour. I will probably use a PID controller, which should be easy to adapt to this purpose.

[1] as I have learnt from my jet-based VTOL attempts

[earth]

Congrats on what you have done!! It may even make it to stock!!

EDIT : i learnt something today that i wanted to tell you. Its just a gimmick.

Its impossible to actually change the thrust of RCS thrusters, they are either opened or closed. But they are quick to switch between both states and thus thrust can be controlled by triggering the RCS thrusters in a PWM pattern.

Edited June 30, 2013 by earth

[Orphican]

So whats the latest news with this project? Is development still happening?

[ZRM]

Congrats on what you have done!! It may even make it to stock!!

EDIT : i learnt something today that i wanted to tell you. Its just a gimmick.

Its impossible to actually change the thrust of RCS thrusters, they are either opened or closed. But they are quick to switch between both states and thus thrust can be controlled by triggering the RCS thrusters in a PWM pattern.

Well, it actually is possible. And for each individual RCS port independently. I know because I've done it. I replace ModuleRCS at runtime with my own module that controls emitters and forces on RCS thruster blocks.

So whats the latest news with this project? Is development still happening?

Of course. These things take time. If you look to post 42 you will see what I am working on currently.

[ZRM]

Progress Update:

This may seem small, but I have now added differential torque control to the engine balancer, so that you can use differential thrust on the main engines to steer the vessel. Getting this to work correctly while maintaining the desired lifting thrust was not straightforward, however now it works like a charm.

So, now I only have one task to complete before I am happy to release this mod to you all for testing, and that is to improve the UI so that multiple active modes (e.g. one for RCS, one for engines) can be managed more easily and to reduce screen clutter (if two small windows can be called clutter). That shouldn't take long to do, tomorrow. Oh, and I need to get to grips with ModuleManager to add the avionics module to command pods.

Be warned that for the time being the engine balancer only solves using the main engines. This means that if the main engines alone (without their gimbals) are not capable of perfectly maintaining a heading without spinning, the solver will not work, or will apply a very limited amount of thrust. On most vessels with this problem (mainly stack rockets), this problem can be easily rectified by strategic placement of some (e.g. two) small orange radial engines in appropriate places and orientations. They act a bit like RCS for the engine solver. Once I give the engine solver access to pod reaction wheels and RCS this will no longer be a problem and supplementary engines will not be required.

For now, a screenshot. Bear in mind that the GUI will be changing to merge control modes into one list and window. Some of the modes you see there are experiments and will be removed from the release. As you can see there is no tweaking required at all to get the system to work, unlike the previous version. Strength and sensitivity sliders are provided purely for user preference.

Edited July 1, 2013 by ZRM

[sundieta]

In my opinion, this is the most important plugin in development right now. I have been trying for weeks to make a large SSTO spaceplane, and I think that this is the missing piece. I can't wait to see the final product!

[ZRM]

In my opinion, this is the most important plugin in development right now. I have been trying for weeks to make a large SSTO spaceplane, and I think that this is the missing piece. I can't wait to see the final product!

Thank you for the support. Be aware that the next release will not include gimbal control. This is required for balancing vessels with a restricted engine layout, like vessels with all engines linearly aligned, like a conventional rocket or spaceplane. You can get around this by attaching small radial engines in strategic locations and orientations, but I wish to add gimbal control to solve this problem for the following release. This will also allow improved handling for all vessels, including gimbal-assisted roll control on rockets.