Jump to content

Devnote Tuesday: I ain't getting on no plane!


SQUAD

Recommended Posts

5 hours ago, TiktaalikDreaming said:

Awesome.  That should assist long wobbly rockets somewhat.

Or at least reduce the need to set a central part as the root.  And take away the guess work of which part would be a good choice.  All great news for those of us who build really large wobble rockets and constantly forget to set the root part.  :-)

You'd think so, but @Claw explained to me that the effect is actually quite minor, alas.

Link to comment
Share on other sites

21 minutes ago, NathanKell said:

You'd think so, but @Claw explained to me that the effect is actually quite minor, alas.

It's fairly clearly a driver for the oscillations.  But usually only after said oscillations have started, so there's clearly more.  There's the time resolution issues (inherent in all numerical simulations) which are essentially not something that can be permanently solved.  Just fudged to greater or lesser accuracy.

Link to comment
Share on other sites

On August 11, 2016 at 0:01 PM, Alshain said:

Well if you are expecting the impossible, then the game shouldn't have been made.

No.  A slightly more in depth AntennaRange is being implemented in the game.  It's no where near the level of RemoteTech.

So if I understand correctly, you need a antenna with high enough range to transmit data?

Link to comment
Share on other sites

43 minutes ago, FlyingCola said:

So if I understand correctly, you need a antenna with high enough range to transmit data?

Basically yet, but as I said it's a bit more in-depth than that.  This is of course based on my understanding of the descriptions I've been reading since before 1.1, don't take it as absolute fact.  However, it would seem that there will be occlusion like RT and unlike AntennaRange (i.e. planets and moons will block transmission) and there will be some difference between relay and transmission antennas, if I understand right.  There will be no directional antennas, or signal delay, or flight computer, and there will be a magic invisible ground station network so you do not have to set up satellites or ground stations around Kerbin like you do in RemoteTech.

Overall, if RemoteTech is advanced mode and AntennaRange is Easy mode, this system will end up being a moderate mode.

EDIT: Correction, I guess AntennaRange does have occlusion, I was under the impression it did not.

Edited by Alshain
Link to comment
Share on other sites

1 hour ago, Alshain said:

Basically yet, but as I said it's a bit more in-depth than that.  This is of course based on my understanding of the descriptions I've been reading since before 1.1, don't take it as absolute fact.  However, it would seem that there will be occlusion like RT and unlike AntennaRange (i.e. planets and moons will block transmission) and there will be some difference between relay and transmission antennas, if I understand right.  There will be no directional antennas, or signal delay, or flight computer, and there will be a magic invisible ground station network so you do not have to set up satellites or ground stations around Kerbin like you do in RemoteTech.

Overall, if RemoteTech is advanced mode and AntennaRange is Easy mode, this system will end up being a moderate mode.

EDIT: Correction, I guess AntennaRange does have occlusion, I was under the impression it did not.

Thanks.

 

So, i don't have to put up a relay system!! Yay!!

Link to comment
Share on other sites

13 minutes ago, FlyingCola said:

Thanks.

 

So, i don't have to put up a relay system!! Yay!!

Not necessarily.  The ground stations on Kerbin mean you don't need a relay in orbit of Kerbin as long as you are below the Mun.  However occlusion means you will need a relay to prevent blackouts around any other planet or moon.  Even the Mun itself will need a relay to reach the back side of it.  Since it is tidally locked, the back side of the Mun never sees Kerbin, so presumably any unmanned rover on that side would need communications via relays.  Furthermore if you are outside the Mun, there is at least one object capable of obstructing your view to Kerbin, depending on where you are, maybe more.

Keep in mind it is also supposed to be optional, so if you just don't want it at all you can turn it off at the start of a career.

Edited by Alshain
Link to comment
Share on other sites

1 hour ago, Alshain said:

Not necessarily.  The ground stations on Kerbin mean you don't need a relay in orbit of Kerbin as long as you are below the Mun.  However occlusion means you will need a relay to prevent blackouts around any other planet or moon.  Even the Mun itself will need a relay to reach the back side of it.  Since it is tidally locked, the back side of the Mun never sees Kerbin, so presumably any unmanned rover on that side would need communications via relays.  Furthermore if you are outside the Mun, there is at least one object capable of obstructing your view to Kerbin, depending on where you are, maybe more.

Keep in mind it is also supposed to be optional, so if you just don't want it at all you can turn it off at the start of a career.

Ok. I was talking about a kkerbon orbital relay. Like in RemoteTech. Anyways, thanks for the clarifications, really helps!! Thanks! Can't wait until the next update!!

Link to comment
Share on other sites

22 hours ago, TiktaalikDreaming said:

It's fairly clearly a driver for the oscillations.  But usually only after said oscillations have started, so there's clearly more.

Angular velocity doesn't actually factor very heavily into the calculations.

The reason why bendy ships are such a hassle has to do with the control point location in relation to the main axis of the ship. If the ship is really rigid, the control point is never moving in relation to the main axis of the ship. When the ship is bendy and the control point is away from the Center of Mass, it starts bouncing around and the controller has a problem because it's getting inaccurate errors. What I mean by that is the angular difference between where the ship is pointing and where the controller thinks the ship is pointing is not stable, because there is a constantly changing difference between the main axis of the ship and where the probe core is pointing.

So imagine it this way. You have a long bendy ship with a probe core at the tip, but the ship is currently just sitting there. This is sort of like a "resting axis" where everything is all lined up in it's natural position. There's no difference in relative position from the control point (the probe core) to the Center of Mass (COM) of the ship.

Now lets say that the ship is trying to Stability Assist and is slightly off it's target. The controller knows it has to correct a few degrees and gives that input. The reaction wheels or RCS react, but the ship bends. The control point overshoots the target orientation, so the controller says "oh, that was too much" and backs off. The problem is that the "resting axis" of the ship hasn't actually made it to the target yet. So as the ship unbends, it snaps back past the target again and undershoots. So the controller tries again, and the same result occurs. If the ship has just the right amount of bendy, it can become "resonant." Which means the bending response 180 degrees out of phase with the controller input. The harder the controller tries, the worse the result.

This situation is fixable buy toning down the controller a bit. The flip side to that is that the controller would then never take full advantage of a ship that isn't bendy. Non-bendy ships would then appear under-responsive and sluggish. Airplanes don't want to keep their nose up. Space ships can wobble around a bit. And any ship that's somewhat marginally stable would become unstable because the controller doesn't push the ship hard enough to maintain stability. I personally prefer a really tight controller, so that it sort of "sticks" where ever I put it. But that doesn't provide the best response for ships that aren't fairly rigid.

Other ways to fix this are by giving any of the torque providers a ramp up function, so they aren't ON and OFF (here's all the control I can muster, INSTANTLY!). Flight controls already do this. Reaction wheels and gimbals can be set up this way as well, which can help the situation.

 

In my bug fixes, I put in a slider that allows the user to somewhat control the responsiveness of the controller. So if a ship is bendy, the user can manually turn down the controller a bit so that it's not so over reactive. If they need more authority, they can turn up the controller a bit. The difficult part is automating this process so that it can adjust on the fly without actually knowing anything about the ship, which is always the goal of stock.

 

PID controllers are quite flexible, but they are tricky to tune if the system itself isn't well known. For KSP, bendy ships represent the most randomized variable the controller has to deal with. In the real world, the structural characteristics of an airplane (or other system) are fully modeled and fed into the system. For less high performance applications, the controller can go through a tuning period where it can learn about the system it's controlling (and is also given engineering input). KSP doesn't quite have that luxury. And even if it did learn the ship completely, any regular mission starts burning off fuel or decoupling some part, which instantly changes the structural properties of the ship.

Link to comment
Share on other sites

16 minutes ago, Claw said:

Angular velocity doesn't actually factor very heavily into the calculations.

The reason why bendy ships are such a hassle has to do with the control point location in relation to the main axis of the ship. If the ship is really rigid, the control point is never moving in relation to the main axis of the ship. When the ship is bendy and the control point is away from the Center of Mass, it starts bouncing around and the controller has a problem because it's getting inaccurate errors. What I mean by that is the angular difference between where the ship is pointing and where the controller thinks the ship is pointing is not stable, because there is a constantly changing difference between the main axis of the ship and where the probe core is pointing.

So imagine it this way. You have a long bendy ship with a probe core at the tip, but the ship is currently just sitting there. This is sort of like a "resting axis" where everything is all lined up in it's natural position. There's no difference in relative position from the control point (the probe core) to the Center of Mass (COM) of the ship.

Now lets say that the ship is trying to Stability Assist and is slightly off it's target. The controller knows it has to correct a few degrees and gives that input. The reaction wheels or RCS react, but the ship bends. The control point overshoots the target orientation, so the controller says "oh, that was too much" and backs off. The problem is that the "resting axis" of the ship hasn't actually made it to the target yet. So as the ship unbends, it snaps back past the target again and undershoots. So the controller tries again, and the same result occurs. If the ship has just the right amount of bendy, it can become "resonant." Which means the bending response 180 degrees out of phase with the controller input. The harder the controller tries, the worse the result.

This situation is fixable buy toning down the controller a bit. The flip side to that is that the controller would then never take full advantage of a ship that isn't bendy. Non-bendy ships would then appear under-responsive and sluggish. Airplanes don't want to keep their nose up. Space ships can wobble around a bit. And any ship that's somewhat marginally stable would become unstable because the controller doesn't push the ship hard enough to maintain stability. I personally prefer a really tight controller, so that it sort of "sticks" where ever I put it. But that doesn't provide the best response for ships that aren't fairly rigid.

Other ways to fix this are by giving any of the torque providers a ramp up function, so they aren't ON and OFF (here's all the control I can muster, INSTANTLY!). Flight controls already do this. Reaction wheels and gimbals can be set up this way as well, which can help the situation.

 

In my bug fixes, I put in a slider that allows the user to somewhat control the responsiveness of the controller. So if a ship is bendy, the user can manually turn down the controller a bit so that it's not so over reactive. If they need more authority, they can turn up the controller a bit. The difficult part is automating this process so that it can adjust on the fly without actually knowing anything about the ship, which is always the goal of stock.

 

PID controllers are quite flexible, but they are tricky to tune if the system itself isn't well known. For KSP, bendy ships represent the most randomized variable the controller has to deal with. In the real world, the structural characteristics of an airplane (or other system) are fully modeled and fed into the system. For less high performance applications, the controller can go through a tuning period where it can learn about the system it's controlling (and is also given engineering input). KSP doesn't quite have that luxury. And even if it did learn the ship completely, any regular mission starts burning off fuel or decoupling some part, which instantly changes the structural properties of the ship.

Ah, good point.  I was conflating angular momentum with orientation.  And thinking in regards to an averaged orientation, which would remove the need for rooted central parts.  But of course, angular velocity/momentum is rate of change, not the actual vector feeding into the under-damped control functions.  In some ways, I imagine if the PID controller is taking into account angular velocity, this could, at times, help or hinder stability, but it's clearly not what I was thinking of in my prior comments.

Just thinking this through some more, if the craft's RCS (in general) had a user configurable slider for total RCS thrust percentage that applied to changing orientation but not translation, then the user could do some tuning. 

Mod idea....   :-)

Link to comment
Share on other sites

As a former engineering student, the Tacoma Narrows bridge is used as a classic case of resonance.

Edit: Let me rephrase that, after Alshain's smartS remark: When I was an engineering student, the Tacoma Narrows bridge was used as a classic case of resonance.

Edited by StrandedonEarth
Link to comment
Share on other sites

46 minutes ago, StrandedonEarth said:

As a former engineering student, the Tacoma Narrows bridge is used as a classic case of resonance.

Yeah, the video gets shown to everyone in Engineering courses.  I can't remember the name though as after, they then went on to talk about a local bridge that developed serious wobbles, unfortunately without nice film evidence.  So film of Tacoma Narrows, and numbers from Brisbane's Victoria bridge.  I imagine that plays out the same in any town/city that had a wobbly bridge. 

Link to comment
Share on other sites

9 hours ago, Claw said:

...

PID controllers are quite flexible, but they are tricky to tune if the system itself isn't well known. For KSP, bendy ships represent the most randomized variable the controller has to deal with. In the real world, the structural characteristics of an airplane (or other system) are fully modeled and fed into the system. For less high performance applications, the controller can go through a tuning period where it can learn about the system it's controlling (and is also given engineering input). KSP doesn't quite have that luxury. And even if it did learn the ship completely, any regular mission starts burning off fuel or decoupling some part, which instantly changes the structural properties of the ship.

You can also use the control deviation for continues manipulation of the P-fragment. The more deviation, the more aggressive the controller. The less, well...

But you have to take care of self-amplifying effect. And a minimum count of the proportional fragment in case the deviation goes to zero.

I had satisfying results when I used it several times to optimize Pressure controllers which ruled Speed controlled Pumps.

Hope that's worth an experiment.

Link to comment
Share on other sites

I've been playing KSP for a few years now and I'm always excited for the new patches.  However, has Squad ever made anything official about the graphics?  I know they've undergone changes over the years but with projects like Scatterer and EVE I'm sort of surprised a bigger effort hasn't been made to improve the planets.  Early on we got experimental terrain scatters, ie: trees and rocks, but since then, as far as I can tell, Squad has been completely Mum sans some part updates.

I know they don't want to make anyone's game run poorly, but I'd still like to see some more advanced graphical options.  EVE is amazing for what it is, but Scatterer is far to buggy to be considered viable for everyday play and just like we eventually got better aerodynamics and buoyancy, I'd really love to see stock clouds and atmospheric scattering.  Not to mention the Mun, as far as I recall, is the only celestial body to ever receive it's own custom effect ( craters ).  There's just so much untapped potential on the artistic front, I'd love to hear about the solar system being enhanced as well as the gameplay.

Edited by Hyomoto
Link to comment
Share on other sites

13 minutes ago, Hyomoto said:

I've been playing KSP for a few years now and I'm always excited for the new patches.  However, has Squad ever made anything official about the graphics?  I know they've undergone changes over the years but with projects like Scatterer and EVE I'm sort of surprised a bigger effort hasn't been made to improve the planets.  Early on we got experimental terrain scatters, ie: trees and rocks, but since then, as far as I can tell, Squad has been completely Mum sans some part updates.

I know they don't want to make anyone's game run poorly, but I'd still like to see some more advanced graphical options.  EVE is amazing for what it is, but Scatterer is far to buggy to be considered viable for everyday play and just like we eventually got better aerodynamics and buoyancy, I'd really love to see stock clouds and atmospheric scattering.  Not to mention the Mun, as far as I recall, is the only celestial body to ever receive it's own custom effect ( craters ).  There's just so much untapped potential on the artistic front, I'd love to hear about the solar system being enhanced as well as the gameplay.

Mun has gotten procedural terain, this was back in 0.19 or 0.20. 
It should be posible to add on other bodies too, 

Link to comment
Share on other sites

17 hours ago, TiktaalikDreaming said:

regards to an averaged orientation

Average orientation was actually attempted in a certain mod. After discussions, I found out that average orientation didn't really help too much either. Some arms of the vessel may bend pro-turn (because they have the torque applied to them) while other parts bend anti-turn (because they don't have torque applied). In that case, there's zero change to the average orientation (or less change than is really happening).

 

8 hours ago, fangschuss said:

You can also use the control deviation for continues manipulation of the P-fragment. The more deviation, the more aggressive the controller. The less, well...

That's already inherently how a PID works. The further from the set point it is, the more aggressive it corrects, without dynamically changing the PID factors.

What has changed recently (i.e. not released yet) is that the PID factors now scale for control authority and moment of inertia. If the ship has lots of control authority and little MOI, it will scale down the PID factors so it isn't correcting so aggressively (crazy, jittery ships). What has been done, however, is that there is some logic that calms down the PID after it's nearly arrived at the target (which is maybe the same thing that you are saying). So that when it's very (very) close to the target, it stops reacting so harshly, but still reacts (so as to not sit happy at several degrees from the target). I've set that up for all three factors (P, I, and D) but they all scale in different ways to help offset some of the other intrinsic characteristics with KSP vessels.

It's not going to be perfect, but it should (ideally) be much better than it was.

Link to comment
Share on other sites

22 minutes ago, Claw said:

Average orientation was actually attempted in a certain mod. After discussions, I found out that average orientation didn't really help too much either. Some arms of the vessel may bend pro-turn (because they have the torque applied to them) while other parts bend anti-turn (because they don't have torque applied). In that case, there's zero change to the average orientation (or less change than is really happening).

 

That's already inherently how a PID works. The further from the set point it is, the more aggressive it corrects, without dynamically changing the PID factors.

What has changed recently (i.e. not released yet) is that the PID factors now scale for control authority and moment of inertia. If the ship has lots of control authority and little MOI, it will scale down the PID factors so it isn't correcting so aggressively (crazy, jittery ships). What has been done, however, is that there is some logic that calms down the PID after it's nearly arrived at the target (which is maybe the same thing that you are saying). So that when it's very (very) close to the target, it stops reacting so harshly, but still reacts (so as to not sit happy at several degrees from the target). I've set that up for all three factors (P, I, and D) but they all scale in different ways to help offset some of the other intrinsic characteristics with KSP vessels.

It's not going to be perfect, but it should (ideally) be much better than it was.

Averaged orientation was at best, only ever going to be a mild step in approximations.  Basically only achieving the same effect as you'd get with rooting a centralish part, except with less control.

Great to hear about the scaled responses.  I've built many a final stage that has a lot of RCS to enable control over earlier stages, and once free of that extra mass, it has a Tacoma Narrows Bridge moment and burns through all it's mono.  It should theoretically help with the long bendy toy rockets too.  I'll be interested to see how a Nexus performs.  :-)

Link to comment
Share on other sites

13 minutes ago, TiktaalikDreaming said:

I've built many a final stage that has a lot of RCS to enable control over earlier stages

If you have this final stage by itself (or a stock facsimile) I can give it a run here. If it's non-stock, a picture might do.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...