[1.9-1.10] Throttle Controlled Avionics

[Motokid600]

No problem and thank you.

[allista]

Behold! The first variant of the new modular interface.

Comments and suggestions are very welcome!

 

[aluc24]

Hey, @allista , I am now attempting to use TCA with my Shuttle style ascent vehicle, and I have a question. Since the center of mass is off the thrust axis, I have added several more engines so that it would be possible to stay at full thrust, balancing attitude solely through engine gimbals. However, when I set TCA To Orbit autopilot, it doesn't utilize gimbals to their full ranges, but instead, throttles down some of the engines. Obviously, that results in loss of thrust, which is very bad for ascent vehicle.

So, my question, how do I make TCA utilize gimbals first, and throttle down some engines only if gimbals cannot do it alone?

 

P.S. One more question. It seems to me that TCA is horrible at maneuver node burns, because it underestimates the time it will take to make the burn with some of the engines throttled down for balance... Any way to fix this?

Edited January 24, 2017 by aluc24

[Beetlecat]

@allista I love the new interface. having the controls broken out like that can really simplify the experience without losing features. Just splendid!

 

[allista]

4 hours ago, aluc24 said:

Hey, @allista , I am now attempting to use TCA with my Shuttle style ascent vehicle, and I have a question. Since the center of mass is off the thrust axis, I have added several more engines so that it would be possible to stay at full thrust, balancing attitude solely through engine gimbals. However, when I set TCA To Orbit autopilot, it doesn't utilize gimbals to their full ranges, but instead, throttles down some of the engines. Obviously, that results in loss of thrust, which is very bad for ascent vehicle.

So, my question, how do I make TCA utilize gimbals first, and throttle down some engines only if gimbals cannot do it alone?

 

P.S. One more question. It seems to me that TCA is horrible at maneuver node burns, because it underestimates the time it will take to make the burn with some of the engines throttled down for balance... Any way to fix this?

TCA stands for Throttle Controlled Avionics, so it's only natural that it handles engines' throttle to create (or, in your case, to counter) torque. Gimbals are used to some extent, which is calculated from a number of factors; there's no user control over it, nor should it be. As for solution, no magic here -- the only way to achieve full throttle is to create a balanced design. For that TCA have builtin aids in Editor. If you cannot balance the craft, you should allow for some downthrotling by providing larger total thrust. Also, in such case it is important to correctly set the roles of the engines. Again, for that TCA has builtin helper (the Autoconfigure Active Profile button); but you shouldn't rely solely on it.

About maneuvering: I never encountered such problems. Latest versions of TCA use pre-balancing to evaluate actual maximum thrust available for the maneuver, so the calculation TCA makes should be pretty accurate. So, either you're using an old version of TCA, or you have found a bug; in which case I would ask you to share the .craft file of the ship that has problems with maneuver time estimation, along with the list of mods required for that ship. 

1 minute ago, Beetlecat said:

@allista I love the new interface. having the controls broken out like that can really simplify the experience without losing features. Just splendid!

It is such a shame that Unity (at least with the old GUI framework) does not provide the grid layout! 

Thing would look much nicer with it.

[Beetlecat]

1 hour ago, allista said:

It is such a shame that Unity (at least with the old GUI framework) does not provide the grid layout! 

Thing would look much nicer with it.

There was / is a UI framework recently developed -- but maybe it doesn't offer what you're looking for, either. It simply made things look somewhat "modern" (by some visual estimations): 

 

 

[allista]

@aluc24, by the way, have you seen the video on the subject?

 

[aluc24]

36 minutes ago, allista said:

@aluc24, by the way, have you seen the video on the subject?

 

Yeah, I saw it... My shuttle is completely different, though. Thrust is off-axis because there are no powerful engines on shuttle itself, only on the fuel tank. The idea is that at the launch, the thrust of the main engine and gimbals are required to balance the thrust. When SRB's separate, shuttle is unbalanced, but can compensate with aerodynamic surfaces, and by the time there is no air to work with, the fuel levels drop to a point where the craft can be balanced again (by gimbals). It's very complicated, because it requires to control gimbals, thrust, and elevons. I could *almost* fly the ascent manually, except for the launch. Anyway, it proved to be too complicated, so I just built another launcher - two rockets attached to the wings of the shuttle. Lots of struts, but far less complicated to launch.

[allista]

 

1 hour ago, aluc24 said:

Yeah, I saw it... My shuttle is completely different, though. Thrust is off-axis because there are no powerful engines on shuttle itself, only on the fuel tank. The idea is that at the launch, the thrust of the main engine and gimbals are required to balance the thrust. When SRB's separate, shuttle is unbalanced, but can compensate with aerodynamic surfaces, and by the time there is no air to work with, the fuel levels drop to a point where the craft can be balanced again (by gimbals). It's very complicated, because it requires to control gimbals, thrust, and elevons. I could *almost* fly the ascent manually, except for the launch. Anyway, it proved to be too complicated, so I just built another launcher - two rockets attached to the wings of the shuttle. Lots of struts, but far less complicated to launch.

Ahhh, I see! Unfortunately, what you want is not possible: there's no control over gimbals, they act autonomously on each of the engines and neither user nor plugin can force them to turn a nozzle to any particular direction. They only react to pitch-roll-yaw input. The same goes for control surfaces.

Edited January 25, 2017 by allista

[aluc24]

5 minutes ago, allista said:

¿ Question ?

Another important part of the upcoming interface remake is the ability to decide which TCA modules are installed on a particular ship. The problem here is that modules are many, so if I make a button for each, they will probably fill the screen. Obviously, some segregation is required. The simplest will be to use TCA's tech-tree parts, but most of them also represent a single module.

So I ask you to look at the list of tech-tree parts and tell me, which of these would you want to toggle with a single button?

Ahhh, I see! Unfortunately, what you want is not possible: there's no control over gimbals, they act autonomously on each of the engines and neither user nor plugin can force them to turn a nozzle to any particular direction. They only react to pitch-roll-yaw input. The same goes for control surfaces.

That's really unfortunate. But couldn't TCA control pitch-roll-yaw in To Orbit autopilot mode, sames as Mechjeb does? It would allow for TCA to control gimbals too.

[allista]

2 minutes ago, aluc24 said:

That's really unfortunate. But couldn't TCA control pitch-roll-yaw in To Orbit autopilot mode, sames as Mechjeb does? It would allow for TCA to control gimbals too.

It does that.

But first, there's a (not so big) limit to how much torque you can compensate that way, and second, as I said before, it is simply against the core of TCA functionality -- the engine balancing by throttle limiting.

[allista]

¿ Question ?

Another important part of the upcoming interface remake is the ability to decide which TCA modules are installed on a particular ship. The problem here is that modules are many, so if I make a button for each, they will probably fill the screen. Obviously, some segregation is required. The simplest will be to use TCA's tech-tree parts, but most of them also represent a single module.

So I ask you to look at the list of tech-tree parts and tell me, which of these would you want to toggle with a single button?

Edit: reposted this so it is not buried in the conversation.

[Mandella]

I would be all right with grouping according to broad area of usage. For instance close ground flight one menu group, ground to orbital another, orbital maneuvers another. Suborbital is an edge case, but could there be duplication? A control could show up in more than one menu group.

Feature request: Any chance TCA could be adapted for lighter than air vessels?

And a design philosophy question. Where do you see TCA ending and MechJeb beginning? Do you see TCA as a alternate to MechJeb, or do you think that MechJeb will always be the best for interplanetary flight, while TCA is primarily to be used in close proximity to planets and moons?

[allista]

2 hours ago, Mandella said:

I would be all right with grouping according to broad area of usage. For instance close ground flight one menu group, ground to orbital another, orbital maneuvers another. Suborbital is an edge case, but could there be duplication? A control could show up in more than one menu group.

Feature request: Any chance TCA could be adapted for lighter than air vessels?

And a design philosophy question. Where do you see TCA ending and MechJeb beginning? Do you see TCA as a alternate to MechJeb, or do you think that MechJeb will always be the best for interplanetary flight, while TCA is primarily to be used in close proximity to planets and moons?

 

I'm afraid you got me wrong: the question is not how to group in-flight controls (I've already done that, as you can see in the video), the question is how to group TCA Modules to add/remove them to a particular ship at construction time. This is a paradigm shift of a sort: currently all the ships have all TCA Modules you have opened in the Tech Tree. I want to change that, so that you could omit not only some controls, but some functionality. In the prospect, this could even influence the cost of the ship.

 

Don't know about the balloons. Technically, there's nothing preventing from using TCA with them; but to what end?

 

TCA vs MechJeb: the question was asked countless times. As I see it, the mods are too different to compete. For instance, MJ has an excellent maneuver planner that I will not even try to reimplement. What for, if I can always use MJ to plot the course and TCA to execute maneuvers? Docking autopilot, DeltaV calculator, rover autopilot... MJ has so many features that are so complex and work so well that it will be the plane stupid to remake them instead of using.

Where TCA ends? I'm not sure; there's no business plan nor technical project. There are some ideas that pop up into my mind, and many more ideas that you give me here on the forum. There are two baselines though:

First thing that I try to achieve with TCA in general is to allow the user to focus on creating meaningful ship designs that will "just work" instead of forcing them to carefully place each part only to discover that the ship is not balanced enough and trying, and retrying... I mean, every modern airplane, or even a simple drone have enough programming built in to make its handling easy. Why KSP spacecrafts should differ? As my math teacher once told me: "You need to solve simple things (like quadratic inequalities) instantly and automatically, otherwise you will never be able to get to any interesting stuff." So I want TCA to solve low-level control problems, so that users (me included) could spend their imagination and intellect on more interesting and challenging things.

Second, I'm interested in programming complex behaviours and use TCA (its autopilots) as a playground. I play KSP (oh well, let's be honest, I don't play anymore, only test things) and encounter a task that is hard and complex (like landing) but that could obviously be automated because I myself already learned how to do it. So I go and "teach" the code to do it for me. The big difference between my "exercises" and MJ is that MJ uses "first calculate, then execute" approach, while I employ constant self-correction which brings these autopilots closer to AI (but not quite, mind you!).

I apologise for the excess verbosity, but I hope I have answered your question.

Edited January 25, 2017 by allista

[allista]

Introducing Developer Builds!

From now on I will publish developer builds in my Dropbox.

The builds are compiled with DEBUG flag and are marked by automatic build number (the last number in version string).

I cannot promise any particular release rates, but these builds will be coming much more often than normal releases.

They will also contain all the latest features. For instance, current build contains many bugfixes and the new interface.

Obviously, these should not be considered stable and should not be used for your main game!

But if you want to help the project, you are very welcome to play with them, test them, break them and tell me all about it! 

 

Seriously, folks, I need you!  Even if I had the time to test everything, I know the system too well and subconsciously evade most of the bugs  

 

[allista]

Yet another question:

Should a ship with some modules not installed because they were still locked in the Tech Tree at construction time...

1. receive an OTA update as soon as these modules are unlocked?
2. stay as it is, because modules are more than just pieces of software and require additional electronic components?

This is purely gameplay choice, no technical limitations involved.

[Mandella]

On 1/25/2017 at 1:31 PM, allista said:

 

I'm afraid you got me wrong: the question is not how to group in-flight controls (I've already done that, as you can see in the video), the question is how to group TCA Modules to add/remove them to a particular ship at construction time. This is a paradigm shift of a sort: currently all the ships have all TCA Modules you have opened in the Tech Tree. I want to change that, so that you could omit not only some controls, but some functionality. In the prospect, this could even influence the cost of the ship.

 

Don't know about the balloons. Technically, there's nothing preventing from using TCA with them; but to what end?

 

TCA vs MechJeb: the question was asked countless times. As I see it, the mods are too different to compete. For instance, MJ has an excellent maneuver planner that I will not even try to reimplement. What for, if I can always use MJ to plot the course and TCA to execute maneuvers? Docking autopilot, DeltaV calculator, rover autopilot... MJ has so many features that are so complex and work so well that it will be the plane stupid to remake them instead of using.

Where TCA ends? I'm not sure; there's no business plan nor technical project. There are some ideas that pop up into my mind, and many more ideas that you give me here on the forum. There are two baselines though:

First thing that I try to achieve with TCA in general is to allow the user to focus on creating meaningful ship designs that will "just work" instead of forcing them to carefully place each part only to discover that the ship is not balanced enough and trying, and retrying... I mean, every modern airplane, or even a simple drone have enough programming built in to make its handling easy. Why KSP spacecrafts should differ? As my math teacher once told me: "You need to solve simple things (like quadratic inequalities) instantly and automatically, otherwise you will never be able to get to any interesting stuff." So I want TCA to solve low-level control problems, so that users (me included) could spend their imagination and intellect on more interesting and challenging things.

Second, I'm interested in programming complex behaviours and use TCA (its autopilots) as a playground. I play KSP (oh well, let's be honest, I don't play anymore, only test things) and encounter a task that is hard and complex (like landing) but that could obviously be automated because I myself already learned how to do it. So I go and "teach" the code to do it for me. The big difference between my "exercises" and MJ is that MJ uses "first calculate, then execute" approach, while I employ constant self-correction which brings these autopilots closer to AI (but not quite, mind you!).

I apologise for the excess verbosity, but I hope I have answered your question.

Sorry for misunderstanding. I haven't watched the video (limited bandwidth here so I have to schedule multimedia for off hours) so I didn't see that. As for your actual query, well, all of them? It looks like you've already divided up the components logically in the tech tree, so I could see requiring each one to be an individual choice on assembly. Are you going to require the Modules to be "physical?" Or will they stay as an added feature of any control core?

As for the updates -- well if TCA becomes a physical module (or series of modules) that must be installed then it should not automatically update. If it is still contained in any control unit then OTA updates would be logical.

Ahem.. Lighter than air is not just for balloons. 

and

They are fully controllable VTOLs that have the added advantage of just floating if you trim them right, so you'd use TCA for the same ends as any other aircraft. The problem is that, at least as far as Heisenberg's is concerned, there seems to already be an additional autopilot in place to handle buoyancy and trim, and at least in my quick testing it conflicted rather decisively with TCA.

Although the more I think about it, the more I see I shouldn't have brought it up, since the flight controls are so different than a regular heavier than air craft, so no worries.

Thanks for the paragraphs on your design philosophy. That is actually exactly what I was looking for, and found it most interesting.

[allista]

12 hours ago, Mandella said:

Sorry for misunderstanding. I haven't watched the video (limited bandwidth here so I have to schedule multimedia for off hours) so I didn't see that. As for your actual query, well, all of them? It looks like you've already divided up the components logically in the tech tree, so I could see requiring each one to be an individual choice on assembly. Are you going to require the Modules to be "physical?" Or will they stay as an added feature of any control core?

As for the updates -- well if TCA becomes a physical module (or series of modules) that must be installed then it should not automatically update. If it is still contained in any control unit then OTA updates would be logical.

Ahem.. Lighter than air is not just for balloons. 

They are fully controllable VTOLs that have the added advantage of just floating if you trim them right, so you'd use TCA for the same ends as any other aircraft. The problem is that, at least as far as Heisenberg's is concerned, there seems to already be an additional autopilot in place to handle buoyancy and trim, and at least in my quick testing it conflicted rather decisively with TCA.

Although the more I think about it, the more I see I shouldn't have brought it up, since the flight controls are so different than a regular heavier than air craft, so no worries.

Thanks for the paragraphs on your design philosophy. That is actually exactly what I was looking for, and found it most interesting.

Updates: yes, I see your point; but then allowing selection of modules only in editor also breaks that logic. I'm not making TCA a physical part, nor lock it to any particular control part of a ship (distributed computer systems rock ). So what, does this mean OTA updates AND in-flight module selection? And I was so hoping to add something to the gameplay  Oh well...

Edit: on the other hand, I could always say that OTA updates of ship computers are too dangerous and forbid them by policy 

BTW, a separate difficult problem is the UI for module selection. Because modules have their dependencies the whole lot of them are actually a directed graph. But I have only rows/columns of buttons to handle them 

 

Yea, I know about these mods I used "balloons" as a joke generalized term, sorry 

Edited January 27, 2017 by allista

[LordCorsair]

Are there any other requirements for this mod other than module manager ? I was trying this on a fresh install with only module manager  v2.7.7 tweak scale v2.3.4 and and kerbal joint reinforcement v3.3.1

I am running the newest version of ksp just downloaded to day off steam and tca v 3.3.4

this is my first time using this mod and i seem to be missing something?

i cant figure how to enable TCA ?  the TCA manual says "TCA should be functional  on all vessels " but all the comand pods and probe cores say "TCA Unavailable" 

I have been playing kerbal for about a year now and i still feel dumb some times

the mod looks great bythe way I watched all the videos and read the manual. 

 

[allista]

1 hour ago, LordCorsair said:

Are there any other requirements for this mod other than module manager ? I was trying this on a fresh install with only module manager  v2.7.7 tweak scale v2.3.4 and and kerbal joint reinforcement v3.3.1

I am running the newest version of ksp just downloaded to day off steam and tca v 3.3.4

this is my first time using this mod and i seem to be missing something?

i cant figure how to enable TCA ?  the TCA manual says "TCA should be functional  on all vessels " but all the comand pods and probe cores say "TCA Unavailable" 

I have been playing kerbal for about a year now and i still feel dumb some times

the mod looks great bythe way I watched all the videos and read the manual. 

Just to clarify: you are playing a career game, right?

If so, have you purchased TCA subsystem and modules in R&D?

If you have, it's a serious bug, and I need to see the output_log.txt file.

If not, it's still a bug, because the status page in the manual should indicate that, instead of saying that all is right.

One other thing: do you have the GameData/000_AT_Utils folder? It's part of TCA, so if you don't, reinstall the mod from SpaceDock (you can find the link in the OP, or a few pages back).

[LordCorsair]

1 hour ago, allista said:

Just to clarify: you are playing a career game, right?

If so, have you purchased TCA subsystem and modules in R&D?

If you have, it's a serious bug, and I need to see the output_log.txt file.

If not, it's still a bug, because the status page in the manual should indicate that, instead of saying that all is right.

One other thing: do you have the GameData/000_AT_Utils folder? It's part of TCA, so if you don't, reinstall the mod from SpaceDock (you can find the link in the OP, or a few pages back).

Sorry i didnt respond I uninstalled and reinstalled KSP deleted my save data and re started the game. I am not sure what the bug was ? maybe it was something in my old game data it seems to be working now .. Sorry to be a problem . some one else had a problem with the old tool bar ? so IDK 

https://www.dropbox.com/s/4lnatxcrm7f1yzi/output_log.txt?dl=0

[astropithicus]

Hey allista, me again, I reinstalled TCA and MM and made sure about AT-Utils and it's working, but now I have serious lag in the game. Editor, flight, you name it. I also have MJ (latest ver(I hope)) so maybe I just don't have enough processer or memory available.  BTW I am in sandbox, not career. I believe I have also been the victim of the ass kraken, most of my ships won't load.

 

[allista]

14 hours ago, astropithicus said:

Hey allista, me again, I reinstalled TCA and MM and made sure about AT-Utils and it's working, but now I have serious lag in the game. Editor, flight, you name it. I also have MJ (latest ver(I hope)) so maybe I just don't have enough processer or memory available.  BTW I am in sandbox, not career. I believe I have also been the victim of the ass kraken, most of my ships won't load.

I doubt TCA or MJ (or together) could be limited by any modern (raed < 10 years old) CPU or RAM amount. Unity is fast, my code is pretty lightweight and optimized, MJ's, I'm sure, also is.

What could cause serious lag is something that spamming exceptions into the log. In that case everything will stutter frequently on I/O-wait, while the logfile is flushed. Ships that don't load are also indicative of some serious problems within KSP installation. So I would check the Unity logs (output_log.txt or Player.log, depending on OS) and GameData for something hideous.

[allista]

TCA v3.4.0 for KSP 1.2.2 (2017.02.06)

ChangeLog:

Spoiler

• User Interface Overhaul
  • Controls were split up into Tabs and Floating Windows
  • As a result, the main TCA window became much smaller
• TCA Modules Selection
  • Now you can select which TCA modules will be installed on you ship during construction (in VAB/SPH)
  • This may considerably decrease the amounts of controls you see in TCA window
  • But OTA updates were disabled for safty reasons. In-flight upgrades of ship's mainframe are now considered too risky!
• Added the new [T+ rV-] attitude cue that targets ship's engines so that continious thrust will propell the ship towards the target while correcting any lateral drift. Very usefull for approaches from a distance.
• Added Smart Engines switch to Engine Profile to set S.E. mode when profile is activated.
• Corrected logic of the Approach stage of Rendezvous autopilot to make it safe to approach huge targes (like asteroids).
• Orbital autopilots are now not available when there's only Maneuver engines onboard.
• Many bugfixes.

 

[hab136]

Does TCA handle non-linear throttles, where for example increasing the throttle from 0-70% only increases thrust from 0-10%, but increasing the throttle from 70-100% increases the throttle from 10-100%?

 

(Kerbal Atomics + Near Future Electrical + optional KerbalAtomicsNFE.cfg patch makes all the nuclear engines have the above throttle/thrust curve)

This is different from jet engines, which simply take time to spin up, but 70% throttle = 70% thrust (eventually).

The non-linear throttle confuses MechJeb's landing guidance and it tends to crash, so I currently land manually with a series of burns at 100%.