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

[ZRM]

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.

Hmmm, that sounds problematic. Are there any exceptions in the logs relating to this, or any messages printed by the plugin?

[ZRM]

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.

I have been thinking about this problem for a while, and I have concluded that a custom autopilot will be required, at least for hovering. Manual landing guidance may still be necessary, but at least the hardest part (touching down) would be solved. As mentioned in a previous post I will be focussing on auto-hover after the next release. Also, since the small perpendicular engines will no longer be required due to gimbal support you should have more success with MechJeb.

[aquilux]

Could you make your code report to mechjeb the correct thrust? Would it be possible to trick mechjeb into thinking your code was the only engine and report to it what characteristics you wanted it to see?

[ZRM]

Could you make your code report to mechjeb the correct thrust? Would it be possible to trick mechjeb into thinking your code was the only engine and report to it what characteristics you wanted it to see?

As I mentioned in my previous post this may be a non-issue once the new version with gimbal support is released - since the solver will be able to make full use of every engine most of the time its behaviour will be closer to what MechJeb expects. However it may be possible to trick MechJeb if necessary, though it is not a high priority right now.

[mizo]

By the way, I reproduced the hang again today. It happened with a small lander with a non-optimal rcs configuration. Four rcs 4-pack around the center of mass. The lander had a really tight profile where it was balanced pretty reasonably in the entire range between full fuel and no fuel. I guess there was not much point really on running the rcs balancer on this craft, but I wanted to see if it fared well, but alas it hanged as soon as I hit the 'RCS linear priority control button', and 'Enable RCS control' wasn't even activated! No error logs related to this fault were produced.

The game hanged up pretty well, had to kill it on task manager using the keyboard only, because clicking anywhere with the mouse would bring the hanged game into focus instead.

[ZRM]

By the way, I reproduced the hang again today. It happened with a small lander with a non-optimal rcs configuration. Four rcs 4-pack around the center of mass. The lander had a really tight profile where it was balanced pretty reasonably in the entire range between full fuel and no fuel. I guess there was not much point really on running the rcs balancer on this craft, but I wanted to see if it fared well, but alas it hanged as soon as I hit the 'RCS linear priority control button', and 'Enable RCS control' wasn't even activated! No error logs related to this fault were produced.

The game hanged up pretty well, had to kill it on task manager using the keyboard only, because clicking anywhere with the mouse would bring the hanged game into focus instead.

The current release does not support vessels with RCS blocks placed only in a single plane around the COM. Unless they are positioned perfectly around the COM (which is impossible due to fuel flow and the flexing of joints etc.) the system is not solvable. Chances are the solver did not figure out that it was not solvable and got stuck in a loop. This problem will not occur in the new version for two reasons:

• The control modes now make use of reaction wheels, making pretty much any vessel solvable, as long as the reaction wheels are powered.
  
• I have integrated a stable natively-coded solver that reportedly is impossible to hang.
  

[mizo]

Yeah, I did not report this problem initially because I figured it was a problem in your simplex solver code, and you said you were ditching it anyway for the next release.

I just recently also realized that the rcs pack I was using on some other craft had one of it's rcs ports missing from their model, so that probably explains the other instances of this hang I experienced.

By the way, I wonder, how complicated would it be to modify your code so that it does not attempt to solve for dimensions which give too few degrees of freedom to begin with?

For example, in the hover case with only engines pointing straight down, it would ignore roll and solve it only for pitch/yaw and forward motion.

[japa]

Nah, obviously in this case it should fully shut off all engines if you attempt to roll the ship.

More seriously, though, the solver now uses the reaction wheels, so it will be able to find a solution just fine.

What I'm wondering, though, is how it decides what direction is forward, so to speak, and if there's a way to easily change it. Like, suppose I make a VTOL jet, with the main engines pointing towards the back, and smaller hover engines pointing downwards. It'd be nice to be able to smoothly rise up, and then fly forward, without changing the ship orientation.

[ZRM]

Yeah, I did not report this problem initially because I figured it was a problem in your simplex solver code, and you said you were ditching it anyway for the next release.

I just recently also realized that the rcs pack I was using on some other craft had one of it's rcs ports missing from their model, so that probably explains the other instances of this hang I experienced.

By the way, I wonder, how complicated would it be to modify your code so that it does not attempt to solve for dimensions which give too few degrees of freedom to begin with?

For example, in the hover case with only engines pointing straight down, it would ignore roll and solve it only for pitch/yaw and forward motion.

Unfortunately, the only way I know of to figure out the degrees of freedom, and more importantly which degrees of freedom are available, is to apply a solver to the system. So effectively the work is being potentially tripled depending on what you need to check to determine the DOF. Plus this problem is sort of a non-issue, as most crafts will have powered reaction wheels, and if you really do have a craft with limited degrees of freedom you're not going to be able fly it very well either, even if it is solved, due to the lack of control from the missing "freedom".

Nah, obviously in this case it should fully shut off all engines if you attempt to roll the ship.

"Computer - do a barrel roll."

Computer: "Negative - shutting down main engines."

More seriously, though, the solver now uses the reaction wheels, so it will be able to find a solution just fine.

What I'm wondering, though, is how it decides what direction is forward, so to speak, and if there's a way to easily change it. Like, suppose I make a VTOL jet, with the main engines pointing towards the back, and smaller hover engines pointing downwards. It'd be nice to be able to smoothly rise up, and then fly forward, without changing the ship orientation.

Currently "forward" is determined by the weighted average of the directions of all active engines. This is not ideal in some cases, such as the one you describe, but it works for many other vessel types, including VTOLs with rotating engines. I am investigating other ways of determining the thrust direction, such as using the navball direction, or using the navball direction interpolated with the direction of gravity, which may work in your case.

[mizo]

Well, one aspect of this plugin I like is giving a step towards doing away with the silly situation of having those reaction wheels for everything.

The current plugin already allows for performing a mun landing without any use of reaction wheels or RCS during powered flight, which I think is pretty great.

The only issues are lack of gimballing and problems regarding reliability, esp regarding what japa said, the solver reaching an invalid state and making all engines go off.

[japa]

Yeah, Navball direction and direction of gravity would seem to be the two main directions anybody would care about, I thin, at least while on the ground. Perhaps a separate control for each? Depending on what you have planned for hover-mode, you could either take over the linear control keys or use separate ones, to increase or decrease the desired hover altitude, while the regular throttle control controls the throttle in the direction of the navball. This way you can press whatever key to get off the ground, and rise to the height you want, and when you leave it, the solver will have the engines just strong enough to counteract gravity, and keep it steady, while you point it in the direction you want to go, and press forward.

[ZRM]

Well, one aspect of this plugin I like is giving a step towards doing away with the silly situation of having those reaction wheels for everything.

The current plugin already allows for performing a mun landing without any use of reaction wheels or RCS during powered flight, which I think is pretty great.

The only issues are lack of gimballing and problems regarding reliability, esp regarding what japa said, the solver reaching an invalid state and making all engines go off.

The new gimbal support should be just what you are after then, as this too gives the solver enough leeway to cope with most situations, like flying a lander without RCS or reaction wheels. Note that you must have at least two engines to allow this, otherwise there is no way of controlling the roll axis.

Edited July 29, 2013 by ZRM

[ZRM]

Yeah, Navball direction and direction of gravity would seem to be the two main directions anybody would care about, I thin, at least while on the ground. Perhaps a separate control for each? Depending on what you have planned for hover-mode, you could either take over the linear control keys or use separate ones, to increase or decrease the desired hover altitude, while the regular throttle control controls the throttle in the direction of the navball. This way you can press whatever key to get off the ground, and rise to the height you want, and when you leave it, the solver will have the engines just strong enough to counteract gravity, and keep it steady, while you point it in the direction you want to go, and press forward.

I think that will work very well, using the existing H/N keys. I will look into this after the next release, along with the auto-hover. What is really needed now is a good selection of parts for creating VTOLs - large angled radial engines, moving engines, mounts, asymmetrical structural sections etc. Almost all parts in KSP, including mods, are forced to stay rotationally symmetrical. Once I get this plugin polished more creative designs should be possible, as well as much larger lander craft that extend horizontally instead of vertically.

[japa]

as well as much larger lander craft that extend horizontally instead of vertically.

Why hello there:

This is my first, and so-far only, interplanetary lander, and it is downright hard to land, but still possible, with stock.

[mizo]

Unfortunately, the only way I know of to figure out the degrees of freedom, and more importantly which degrees of freedom are available, is to apply a solver to the system. So effectively the work is being potentially tripled depending on what you need to check to determine the DOF. Plus this problem is sort of a non-issue, as most crafts will have powered reaction wheels, and if you really do have a craft with limited degrees of freedom you're not going to be able fly it very well either, even if it is solved, due to the lack of control from the missing "freedom".

Yeah, well, I think your current implementation of resolving every frame might be too heavy handed, and tbh I don't see much point in it.

I am very skeptical you might be able to solve the current wobble problems with it.

I think the solution might have to be in the direction of doing some structural analysis and/or empirical evaluation to find resonance peaks, and then to avoid those frequencies in the flight computer in the first place, maybe by notch filtering them out for instance.

So you might be revisiting that in the future, in which case solving the system 100 times during startup is peanuts compared to every frame

Edited July 29, 2013 by mizo

[ZRM]

Why hello there:

image

This is my first, and so-far only, interplanetary lander, and it is downright hard to land, but still possible, with stock.

I did mean much larger than that, and asymmetrical, e.g. an entire Mun base constructed in orbit, however that is quite a nice looking mobile lander. How good is it at returning to orbit? How do you keep it powered? I think I saw something of a similar nature (weight distribution-wise) by someone who made a very well done Mars Constellation-style mission. For your very first interplanetary lander I personally would have tried something a bit smaller and simpler, and probably on Duna.

Edit: I see the gigantor panels now.

Edited July 29, 2013 by ZRM

[ZRM]

Yeah, well, I think your current implementation of resolving every frame might be too heavy handed, and tbh I don't see much point in it.

I am very skeptical you might be able to solve the current wobble problems with it.

I think the solution might have to be in the direction of doing some structural analysis and/or empirical evaluation to find resonance peaks, and then to avoid those frequencies in the flight computer in the first place, maybe by notch filtering them out for instance.

So you might be revisiting that in the future, in which case solving the system 100 times during startup is peanuts compared to every frame

The native solver I am using now is very fast, and as a bonus it uses the last solution where possible as a starting point for the next one. This has two benefits - even better performance, and wobbling is practically eradicated, since the wobbling I have encountered is caused by the temporally varying thrusts due to there being multiple solutions to the problem, so starting from the previous solution makes the result more stable by picking the new solution closest to the previous one.

I am reluctant to analyse the system at startup since factors that affect flight such as structural flexing, other mechanical movement and fuel usage/flow could significantly change the characteristics of the vessel during flight. I will prefer refining the current solution for the time being.

[japa]

Unfortunately, it doesn't really have any capability to get back into orbit.

[ZRM]

Unfortunately, it doesn't really have any capability to get back into orbit.

Here's the first one I did in 0.20 - designed to be a no-fuss, in-out flying visit to Duna:

It attaches directly to the end of a CSM consisting of a probe on a hitchhiker module (+ essentials) via the senior docking port on the top. No wobble at all during the flight.

It uses one non-stock part (the tank), but that is purely for aesthetic reasons, and could easily be replaced. Plenty of fuel for landing and returning to the CSM.

/Temporary off-topic topic.

Edited July 29, 2013 by ZRM

[mizo]

Here is the one I did, though it uses some parts from NP and KW:

The docking port is from bobcat ind.

It has a very low CoG, and it survives pretty rough landings with some horizontal speed.

[mizo]

The native solver I am using now is very fast, and as a bonus it uses the last solution where possible as a starting point for the next one. This has two benefits - even better performance, and wobbling is practically eradicated, since the wobbling I have encountered is caused by the temporally varying thrusts due to there being multiple solutions to the problem, so starting from the previous solution makes the result more stable by picking the new solution closest to the previous one.

I am reluctant to analyse the system at startup since factors that affect flight such as structural flexing, other mechanical movement and fuel usage/flow could significantly change the characteristics of the vessel during flight. I will prefer refining the current solution for the time being.

I see. Well I did not realize you were encountering wobble caused by your code itself. I was talking more in general about SAS and mechjeb autopilot induced wobble.

But still, I think structural flexing shouldn't matter much, I mean I suspect there should have too much wobble for it to mean anything.

About the shifting CoM I agree it's a problem, but how hard for example would it be to solve the system with CoM being another free variable?

[ZRM]

I see. Well I did not realize you were encountering wobble caused by your code itself. I was talking more in general about SAS and mechjeb autopilot induced wobble.

But still, I think structural flexing shouldn't matter much, I mean I suspect there should have too much wobble for it to mean anything.

About the shifting CoM I agree it's a problem, but how hard for example would it be to solve the system with CoM being another free variable?

All wobble caused by SAS and MechJeb is nothing to do with me, hence the attempt on my part to figure out what you meant by wobble. It is not my fault if a PID controller I have no control over overcompensates.

I am now not sure which problem you are trying to solve. What exactly are you suggesting? You mention solving the system at least once per update, and my current solution requires use of the solver at most 4 times per update, with negligible performance impact. COM already is a free variable in the current solution.

[mizo]

I think I misunderstood you then. I thought you were proposing a solution where you would somehow actively dampen the SAS oscillations.

Anyway the main problem I see with solving the system every update is with regards reliability.

With it being done once per startup, and ignoring structural flexing altogether, you get a sense how the ship handles from launch, and there is not much variation there, and chances of something then going wrong deep into the mission are low.

Now doing that every update and accounting for strut flexing introduces a lot of unknowns and possibilities of failure there.

For example you might be introducing new paths of positive feedback. Or also depending on a combination of user input, attitude, flexing and/or damage to the ship, it can fail to solve the system and that then leads to loss of control.

[helldiver]

This MOD is absolutely necessary for the Kerbin Orbiter I'm working on.

I'd been wanting an FCS (Flight Control System) like the real shuttles have for a while. SAS, ASAS, Avionics haven't really worked too well. Your mod seems to be exactly what I needed.

Would it be alright if I incorporated into the Avionics part of the Kerbin Shuttle?

How does your mod work? Is it loaded on a part? Or is it a DLL, or?

[japa]

Right now it's a DLL that gets attached to most of the stock command pods. probably a better solution would be to make a dedicated part for it, but that's not there yet.