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

[ZRM]

Progress Update:

All features that I planned for this release are now implemented and working properly (AFAIK), except the help system, which is not yet implemented. I am going to include a system where if the user clicks on a 'Help' button in the corner of the settings window, the window goes into "help mode", where each individual button or element in the interface is augmented with a small "?" button next to it. Another window will also appear, and it will contain the help info for the feature related to whichever "?" button was last clicked. I hope this is going to be an adequate aid for inexperienced or non-technical users that do not understand the technical terms in the interface or the current abilities of the plugin. I do not want the release thread to be bloated with "What does _ mean?", "How do I _?", "Why does it _?", "Why can't I _?" questions. That would make it more difficult to spot the useful feedback.

[ZRM]

New Release! Click here to go to the release thread.

[PrivateFlip]

Thought I post this here.

Been playing with the engine auto trim which seems to be working okay if you add a few of those perpendicular engines but it doesn't seem to need these engines in flight to balance an asymmetrical craft. I'm guessing your solver does need these engines to be there to start its computation. Is it not possible to, after determine that all engines are facing backward (based on the weighted average direction of all engines) to make up some dummy engines in the other directions for the solver to work with. Of course only for the auto trim mode as for most users of this mode the primary aim will to balance the main thrust?

I think this might be an easy fix as it seems it should be able to perform fine without the engines. Actually tried it without those engines and besides the hampering thrust, switching between "nominal" "non feasible" and "internal error 1" it does give a balanced thrust while using an imbalanced craft (until it turns by an inch then the engines cut out). So maybe if it could ignore they weren't there by making up some engines it would perform as desired for this particular mode.

Also noticed that sometimes on auto trim mode it will kick in some of these perpendicular engines in one direction. These engines will then stay on albeit on a low thrust. Cutting the engines and the throttling up again stops it. Happened twice, can't reproduce it at will, have no idea why it happens, but maybe its relevant to you.

Edited July 4, 2013 by PrivateFlip

[ZRM]

Thought I post this here.

Been playing with the engine auto trim which seems to be working okay if you add a few of those perpendicular engines but it doesn't seem to need these engines in flight to balance an asymmetrical craft. I'm guessing your solver does need these engines to be there to start its computation. Is it not possible to, after determine that all engines are facing backward (based on the weighted average direction of all engines) to make up some dummy engines in the other directions for the solver to work with. Of course only for the auto trim mode as for most users of this mode the primary aim will to balance the main thrust?

I think this might be an easy fix as it seems it should be able to perform fine without the engines. Actually tried it without those engines and besides the hampering thrust, switching between "nominal" "non feasible" and "internal error 1" it does give a balanced thrust while using an imbalanced craft (until it turns by an inch then the engines cut out). So maybe if it could ignore they weren't there by making up some engines it would perform as desired for this particular mode.

Also noticed that sometimes on auto trim mode it will kick in some of these perpendicular engines in one direction. These engines will then stay on albeit on a low thrust. Cutting the engines and the throttling up again stops it. Happened twice, can't reproduce it at will, have no idea why it happens, but maybe its relevant to you.

You sort of have the wrong idea about how the solver works. Firstly, it is stateless in the sense that it does not use prior computation to determine the next set of thrusts. Any variations in thrust that give an impression of using prior state is in fact due to the oscillations and flexing of your vessel. In your example, the solver requires the perpendicular secondary engines in order to compensate for flexing in the vessel causing non-perfect directions of the main engines. If you find the solver status is flicking between "nominal" and other states, this means that flexing in your vessel is causing it to temporarily become unsolvable. Fix this by adding or enabling perpendicular secondary small radial engines.

The problems you are experiencing will not exist at all once I add gimbal support, which gives engines much greater room for compensating for flexing and imperfect configurations. You will then not require any perpendicular secondary engines. It could even work with just one engine. So this is what I am focussing on to solve the problem, instead of hacking around it using dummy engines.

[PrivateFlip]

I actually did not assume the solver is stateful, although I can see how my use of the term switching could give this idea. Although i did not know about the flexing, I did notice the module was not functioning at some points when those engines weren't there and assumed the engines were at those moments in some way required to compute a solution as your response seems to confirm. Hence my suggestion for dummy engines to allow a solution to be computed, because in my simple user experience only throttling up and down the main engines would be enough to balance the craft.

But if gimbal support solves all of this and more, like flying a space shuttle with a giant tank under its belly after shedding its boosters, I understand you don't want to cut corners.

[neoquietus]

A possible bug in the RCS balancer. No other mods installed, using the Steam Linux version of KSP. In short, a linear RCS thrust is still resulting in an angular rotation, although much less quickly than without the balancer. It seems to get worse as the objects gets lighter, so maybe something is not recalculating the weight correctly?

[ZRM]

I actually did not assume the solver is stateful, although I can see how my use of the term switching could give this idea. Although i did not know about the flexing, I did notice the module was not functioning at some points when those engines weren't there and assumed the engines were at those moments in some way required to compute a solution as your response seems to confirm. Hence my suggestion for dummy engines to allow a solution to be computed, because in my simple user experience only throttling up and down the main engines would be enough to balance the craft.

But if gimbal support solves all of this and more, like flying a space shuttle with a giant tank under its belly after shedding its boosters, I understand you don't want to cut corners.

Okay, sorry I misunderstood you. I think I must have just misread your post in general, not the switching bit, as I can't see now how I came to that conclusion.

Yes, the gimbal support really will be almost revolutionary. With the space shuttle example, it should be able to automatically use gimbaling to not only account for the external fuel tank, but also to roll the vessel, which stock gimbal control does not allow due to the uniform motion of every gimbal. In general, it will also make rockets much easier to control and able to follow flight guidance systems like MechJeb much more accurately. For example, it should be able to easily counter top heavy instability, as well as inaccurate flight due to wobbly rocket syndrome.

[PrivateFlip]

In one of your previous post you also mentioned adding torque control to the engine balancer. If torque control is added would having only torque in combination a linear engines setup which don't have gimbal be enough to compute a solution, or would gimbal engines always be a requirement for a linear setup?

I understand what advantages gimbal would give in combination with this mod. This is just a what if question.

[ZRM]

In one of your previous post you also mentioned adding torque control to the engine balancer. If torque control is added would having only torque in combination a linear engines setup which don't have gimbal be enough to compute a solution, or would gimbal engines always be a requirement for a linear setup?

Torque control is included, as you can see from the sliders in the Engine Auto-Trim mode for configuring it. However it is not enough to balance a linear set up without gimbal support, as it has no control over rotation around the axis that all the engines are pointing in. For a VTOL, this is the yaw axis. Hence the need to tilt your engines to ensure that it can balance every axis.

[ZRM]

A possible bug in the RCS balancer. No other mods installed, using the Steam Linux version of KSP. In short, a linear RCS thrust is still resulting in an angular rotation, although much less quickly than without the balancer. It seems to get worse as the objects gets lighter, so maybe something is not recalculating the weight correctly?

Hmmm. I have been noticing this as well, especially on lighter craft. I think it might be an inaccuracy in the Centre of Mass calculation, as it affects both the engine and RCS balancers. Please could you post your craft file - it looks like a good example for testing any fixes I may try.

Edit: Never mind, I have made a suitable test vehicle. And, after some testing, I suspect that the problem may in fact be related to the force integrator used by PhysX, though I am not sure. For the time being, it seems that this problem only noticeably affects very light vehicles, regardless of the thrust-to-weight ratio, so you will just have to take this into account and use ASAS with light vehicles. This should work well due to the differential thrust control.

Edited July 6, 2013 by ZRM

[ZRM]

Progress Update:

On the way to adding gimbal support to the solver, I have added a more sensible replacement for stock gimbal control. Since I have had to replace the control of gimbals entirely, I had to come up with a default behaviour for gimbals that does not rely on a vessel-wide coordinated solver-based control mode. I could not bring myself to use the stock behaviour so I have come up with, IMO, a much better behaviour. Its main advantages over the stock behaviour are that:

• gimbals react correctly to roll control so that off-axis engines can produce torque around the axis of a rocket.
  
• gimbals work correctly if they are placed above the centre of mass, instead of working against you like stock gimballing.
  

And all of this is in approximately 20 lines of simple vector maths per gimbal per update. It is beyond me why this is not the stock behaviour. Of course, this has no control over the thrust of engines, so it does not balance the vessel as such, but at least all vessels will fly in roughly the expected direction and respond well to ASAS and MechJeb.

This behaviour is now active by default when KCA is installed on a vessel, since so far I have yet to find a situation where stock gimballing works better. It is only disabled when a control mode that uses gimbals is active.

I have not released this yet, as I am focussing on adding proper gimbal support to the solver.

[ZRM]

Progress Update:

Gimbal support is more or less working now, however the constraints are proving difficult for the current solver to handle in some situations. It works well with a gimbal range on each engine of approximately 10° or more, but a range of 5° for example makes the solution space so very narrow between the constraints that the solver cannot find a solution, due to floating point inaccuracy and the solver being relatively numerically unstable. I may have to invest some time in rescaling the variables so that the constraints are not so difficult to satisfy numerically, since most engines have a gimbal range of 1°.

There is also a new solver I have made that is faster and more accurate and works very well in test cases approximately 99.9% of the time, but sometimes it gets stuck in a loop, hanging KSP. This means you get on average approximately 10 seconds before the game hangs after starting a balancing mode. Not ideal. Once I fix that problem this solver should be much more suited to difficult constraints like gimbals.

[ZRM]

Progress Update:

After struggling to get my inadequate, inefficient and unstable home-made solver to work correctly, I had this great idea - use an open source industrial-strength native solver via P/Invoke instead. Previously I had dismissed this idea due to potential cross-platform compatibility issues, but now I realise that it's better to have something that works on at least one platform, than something that doesn't work at all, right? I have ideas for getting this to work on mac and linux in the medium term. I just need to make sure that Mono looks in the right place for native DLLs.

So now I am using lp_solve, a brilliant and very fast native © solver with an excellent C# wrapper, and it is working almost perfectly, and extremely quickly. All the gimbals are pointing the correct direction almost all of the time, with no lag, hangs or Internal Error 01s at all. I have a few more things to attend to before release of the next version for testing, such as a peculiar bug that makes engine nozzles disappear temporarily, plus I want to add "reaction wheel" support using the existing KSP 0.20 mechanisms (i.e. command pod torque). Reaction wheel support will make the RCS modes in particular much more lenient - you should be able to get away with just a ring of 4 RCS blocks on your CSMs, for example.

[aquilux]

I was going to suggest as a solution to "hampered thrust", that you could maybe take the final engine throttle settings and if none of them reach 100%, scale them all up until at least one does. That way you get the most thrust while not going past what the other engines can counter for.

[ZRM]

I was going to suggest as a solution to "hampered thrust", that you could maybe take the final engine throttle settings and if none of them reach 100%, scale them all up until at least one does. That way you get the most thrust while not going past what the other engines can counter for.

Sorry, I'm not sure which problem you are talking about exactly. Please could you link to and/or quote whichever post I mentioned this in?

[japa]

First of all, I love the idea of this mod, but I have a question:

Would it be possible, using this, to use a system like this, with enough thrusters pointing in the right directions, use primary engines instead of RCS thrusters for maneuvering? This can be useful for extremely large ships for which RCS is a bit weak.

[mizo]

First of all, I love the idea of this mod, but I have a question:

Would it be possible, using this, to use a system like this, with enough thrusters pointing in the right directions, use primary engines instead of RCS thrusters for maneuvering? This can be useful for extremely large ships for which RCS is a bit weak.

That would be nice, but currently there is no way to do this if you want to maneuver without also translating forward, since you have to apply some throttle for it to do anything.

I don't know if ZRM can modify the plugin so that it would control the attitude even with throttle completely off.

[ZRM]

First of all, I love the idea of this mod, but I have a question:

Would it be possible, using this, to use a system like this, with enough thrusters pointing in the right directions, use primary engines instead of RCS thrusters for maneuvering? This can be useful for extremely large ships for which RCS is a bit weak.

That would be nice, but currently there is no way to do this if you want to maneuver without also translating forward, since you have to apply some throttle for it to do anything.

I don't know if ZRM can modify the plugin so that it would control the attitude even with throttle completely off.

I think japa means using primary engines that are placed around the vessel in a similar way to RCS thrusters (i.e. pointing in every direction). In which case it is certainly possible, and in fact it is already in the current release in a restricted form - Engine Linear Mode. Angular control would be very straightforward to add; it is just not in the current release.

Anyway, Progress Update:

I have modified the development version of the plugin to work with 0.21. Reaction Wheel control is now working, and the RCS mode will now work with pretty much any RCS layout you can think of, as long as you have at least one powered Reaction Wheel on the vessel. This means you can have compact command modules with only three or four RCS thruster blocks just around the COM and it will solve the system perfectly, since the reaction wheel gives the solver leeway when calculating RCS port thrusts.

I am now working on consolidating the control systems into a one-size-fits-all control mode. This means that for the most part one mode will work for every vessel in every situation. This makes it much more likely that a similar system makes it to stock. The idea is that if the vessel is throttled up, the mode is in a "guidance" state, where it only tries to balance the attitude of the vessel using available control effectors (RCS, wheels, engines) while thrusting with the main engines in the desired direction. If the throttle is at zero the vessel is then in a "manoeuvring" state, where RCS and reaction wheels balance translation and rotation exactly, instead of just rotation.

Once the "combined" control mode is working properly I will focus on SRB support, possibly including support for the Advanced SRB mod once it is updated for 0.21. Then the plugin should in theory be good enough to release. After that I will focus on adding a VTOL auto-hover behaviour using a PID controller.

BTW, how are people finding the behaviour of the current release of the plugin in 0.21? I have not actually tested that version with 0.21, and in theory it should be compatible.

Edited July 27, 2013 by ZRM

[japa]

My gaming rig died, so I haven't been able to test yet, but I will as soon as I can.

[japa]

Okay, I have tested the current version on 0.21, and it seems to work, though there's math errors and everything shuts off if I try turning while hovering. I don't know if that's normal or not.

Also linear mode doesn't appear to work at all. No matter what direction I try pressing, it reports no solution possible.

[ZRM]

Okay, I have tested the current version on 0.21, and it seems to work, though there's math errors and everything shuts off if I try turning while hovering. I don't know if that's normal or not.

That depends on whether you set up your engines correctly. You must ensure that VTOL engines are tilted away from each other in every axis. The example craft should work fine.

Also linear mode doesn't appear to work at all. No matter what direction I try pressing, it reports no solution possible.

That is entirely normal on crafts not designed to use linear mode, like VTOLs. Linear mode is effectively an RCS-style solver for engines, so for it to work you must have engines distributed around the craft pointing in various directions. It's only use really is for very heavy orbital vessels.

From what you're telling me it sounds like the plugin is not broken.

[japa]

Okay, awesome. Glad to be of help, also can't wait to try the next version.

Now I just have to learn to design my ships around this.

[mizo]

Yeah, the current version works fine in 0.21 at least for the engine control modes. RCS modes seem to work but the game hangs completely not long after I enable it.

[mizo]

By the way, what really get's screwed by this plugin are the various plugins that depend on estimating how much main engine thrust you have, like engineer and mechjeb vessel info. They really don't like engines pointing directions other than straight down.

Also, another related issue is that, even if the bulk of your engines are pointing straight down, with only a few puny ones giving you roll authority, mechjeb landing autopilot does not account for the afflicted control losses, it assumes that all engines are running at the power of thrust specified, and so it massively overestimates how much thrust it has control over.

It seems that the autopilot runs pretty much open loop, and it's pretty aggressive in it's attempt to be delta-v efficient, and needless to say it has disastrous results.

[ZRM]

Okay, awesome. Glad to be of help, also can't wait to try the next version.

Now I just have to learn to design my ships around this.

On a related note, the next version will not impose anywhere near as many design constraints - no tilting required, since it uses gimbals and reaction wheels.