[WIP] Infernal Robotics - Next

[Rudolf Meier]

16 minutes ago, ZodiusInfuser said:

Those values in original IR control the internal spring of the joint. By default we only ever used values that meant the spring was at it's extreme (so the servo always matched its target) or at its minimum (so it became uncontrolled). Members did do tested thought of other values and it made things like shock absorbers possible. One idea kcs123 and I discussed was variable elastic actuators, which are special servos IRL that can dynamically adjust their stiffness, hence his suggestion of having the spring values exposed in the VAB (either for all parts or a specific subset)

ok... but then we use those without the limits? and therfor only for uncontrolled 360° joints ...

the problem is this: the spring values... that's clear, those are related to the "targetPosition"... and the damping is related to the current movement. What this means is, that if you apply a force, you can pull/push the joint away from the targetPosition... now, if you allow this, then it's possible (with enough force) to move them over the limits we want for this joint... and since we cannot set those limits on the unity joint itself (as explained in an other post), then... what do we do? ignore it? break the joint when it's moving too far? ... one idea in the old code was to adjust those spring forces while the joint is moving and try to simulate limits like that (but it is almost impossible to get good results from that)... or we'd have to recreate the joint when a scene is reloaded (like this we can somehow "reset" the zero-position and then set the limits... well... not the way we want them, but almost) ... I tryed that, but... I'm not convinced that this is a good idea

the easiest would be if unity would allow limits from -360 to +360 and add also negative limits for translational joints... but... that's not going to happen soon...

[ZodiusInfuser]

Maybe you can have a setting for rotational parts that lets these values be set if no limits are specified in their config, as I see the value of having both controlled and uncontrolled versions (and adjustable ingame). I remember Ziw doing the code you mention and not getting great results, so I doubt having them for translational parts is viable.

[Rudolf Meier]

36 minutes ago, ZodiusInfuser said:

Maybe you can have a setting for rotational parts that lets these values be set if no limits are specified in their config, as I see the value of having both controlled and uncontrolled versions (and adjustable ingame). I remember Ziw doing the code you mention and not getting great results, so I doubt having them for translational parts is viable.

Currently that's the only option I see... because even programing it myself wouldn't work... I cannot read out the applied force to a joint or the current speed... stuff like that... I'm searching other options right now. Maybe stuff like attaching additional joints or whatever. But I don't think that's possible...

[VR_Dev]

What about straight up IR shock absorbers? Doesn't look like any mod currently exists and I think they would be super useful.

I know I would have uses for them.

[Rudolf Meier]

1 minute ago, VR_Dev said:

What about straight up IR shock absorbers? Doesn't look like any mod currently exists and I think they would be super useful.

I'm not sure if they can be made... in unity it should be possible, but in combination with how KSP loads joints this is probably not working... I don't know how they load their robotic wheels (those seem to have dampers too)... maybe I should look at this code... *hmm* ...

[VR_Dev]

4 minutes ago, Rudolf Meier said:

I'm not sure if they can be made... in unity it should be possible, but in combination with how KSP loads joints this is probably not working... I don't know how they load their robotic wheels (those seem to have dampers too)... maybe I should look at this code... *hmm* ...

Couldn't it just be an uncontrolled extender with spring\damping? 

[Rudolf Meier]

6 minutes ago, VR_Dev said:

Couldn't it just be an uncontrolled extender with spring\damping? 

The problem is, when you save/load a sceene with non-relaxed dampers... then it won't work anymore (the "zero"-position is wrong then and you cannot set those). At least not if you don't do anything... and at the moment I don't know what I'd have to do to make them work again (means: to set the "zero"-position).

[VR_Dev]

3 minutes ago, Rudolf Meier said:

The problem is, when you save/load a sceene with non-relaxed dampers... then it won't work anymore (the "zero"-position is wrong then and you cannot set those). At least not if you don't do anything... and at the moment I don't know what I'd have to do to make them work again (means: to set the "zero"-position).

Save damping value to a text file OnDestroy?

[Rudolf Meier]

9 minutes ago, VR_Dev said:

Save damping value to a text file OnDestroy?

That's not the problem... the problem is, that after loading, the current (compressed) state is loaded as "initial-zero" point (as relaxed) ... and then it compresses again from this point (e.g. due to the weight of a rover) and shift's further until it's out of the limits. And this behaviour is part of unity/ksp that cannot be changed that easily... maybe I can figure out a way to work around this problem.

Edited February 20, 2018 by Rudolf Meier

[VR_Dev]

24 minutes ago, Rudolf Meier said:

That's not the problem... the problem is, that after loading, the current (compressed) state is loaded as "initial-zero" point (as relaxed) ... and then it compresses again from this point (e.g. due to the weight of a rover) and shift's further until it's out of the limits. And this behaviour is part of unity/ksp that cannot be changed that easily... maybe I can figure out a way to work around this problem.

yeah ok I got it now I think. So at first launch it compresses itself to the correct position, but if you go to the space center and back to the vessel the compressed state becomes the new default. Do you know if it is specifically built in Unity or custom Ksp that controls this behavior?

I'm pretty excited for this idea now. It would be amazing to have some damping when placing a mech foot on the ground. Right now the servo speed PID is the only thing that slows the foot down as it gets close to the surface. Too fast and the foot part just explodes on contact. But a suspension part between the knee and the foot to dampen the impact. That opens up a whole new world of performance.

[Rudolf Meier]

1 hour ago, VR_Dev said:

Do you know if it is specifically built in Unity or custom Ksp that controls this behavior?

That's unity... you cannot set the default values. They are set when you create the joint (or set the axis) to the current value. So, if you want to set it to -1 you have to destroy the joint or move it, then recrate or set the axis and move back... stuff like that... most of the time it ends in huge problems. But maybe it's still possible...

The wheels of KSP seem to do this... I'll try to find out how they do it...

Edited February 20, 2018 by Rudolf Meier

[kcs123]

3 hours ago, Rudolf Meier said:

 

the problem is this: the spring values... that's clear, those are related to the "targetPosition"... and the damping is related to the current movement. What this means is, that if you apply a force, you can pull/push the joint away from the targetPosition... now, if you allow this, then it's possible (with enough force) to move them over the limits we want for this joint... and since we cannot set those limits on the unity joint itself (as explained in an other post), then... what do we do? ignore it? break the joint when it's moving too far? ... one idea in the old code was to adjust those spring forces while the joint is moving and try to simulate limits like that (but it is almost impossible to get good results from that)... or we'd have to recreate the joint when a scene is reloaded (like this we can somehow "reset" the zero-position and then set the limits... well... not the way we want them, but almost) ... I tryed that, but... I'm not convinced that this is a good idea

the easiest would be if unity would allow limits from -360 to +360 and add also negative limits for translational joints... but... that's not going to happen soon...

Zodiusinfuser already covered it, why I asked for request to expose those values to VAB, in flight scene on rigtht click menu. So far we know it can work on rotational free moving parts. It should be allowed for free moving parts to exceed limits -360 to +360 due to game engine limits, as much as unity game engine "see" that. However, we might set limit values in part config file in different way. Let say, we set limit of movement from 0 to 300 degree and from 0 to -300 degree for inverse movement.

Inside allowed limits of movement, values for spring and damper are linear like it is set in config file or trough right click menu. As soon as limit is exceeded, joint spring forces become exponentially stronger. Hopefully, strong enough to produce feeling like it is colided on something.
I wrote some thoughts how it might be possible to do it in following posts from one that I linked earlier:

Quote

To get around of that issue, would be possible to change how "jointSpring" and "jointDamping" behave in game ? As much as I was able to understand trough observation in game and in config file, those numbers are linear coefficient that are passe dto KSP game engine. Would be possible to make it non linear trough IR plugin ? For example, when offset from setpoint is within range of movement, spring and damping forces are linear, like it is now, but when limit is exceeded, it start to be exponentially stronger, trough function

force * exp(range)

or if that would not be enough then 10^rangefunction could be used, or something like that. It would not ultimatelly prevent parts to move, but if force is strong enough, it could behave like parts are collided, while they actually were not collided. Some kind of hacky way to get around of game engine limits.

Some other ideas were also poping up as I write this post. If I have understand properly how extendratron is created, it have two joints. One joint attached to craft that is fixed and to one part of mesh, while other can be translated and have second part of mesh. On that translated part you can attach some other parts of craft. So, I come up with idea, if it is possible to create extendratron with three joints instead of just two ?

First joint would be fixed with fixed part of mesh, it is connected to second fixed joint. After that joint comes joint and mesh that can be translated. What IR plugin should do is, when it is time to translate joint (trough user input), it disable middle fixed joint (it's forces) and after that translate movable joint. Once translation is done, it re-enable middle joint again. That middle joint should always be on fixed position relative to first, unmovable joint.

Now fun part may be possible. To make only that middle joint with spring flexible forces. Joint at outher end of extendratron should have stiff joint as much as possible.
From game engine side of view, it would act as two fixed parts attached together, while you as user can see only one.

Can something like that work ? You will be always able to know where outher joints need to be, they should not be able to drift anywhere where they should not be able to do, while they would still have some kind of "magnetic" spring connection between.

Thinking of it more, would be possible to create such mesh with 3 joints ? It should be short and wide enough, though, to be able to hide any possible misalignment of two moving parts.

For now, in first beta version of mod it would be enough to have additional variables in part config file:

• jointSpringDampingExposed - true/false  - to allow user to change value in VAB and maybe in flight scene too
• nullPoint  - 0 degree in above example or angle where jointSpring/Damping are equal, or resting point
• rotateMinForce and rotateMaxForce - not true limit, but point where jointSpring force start to rise exponentially

It might not be possible to prevent strange behaviour in all situations, where part rotaqte above desired limits, but it can help a lot if used properly.
Currently with only adjusting spring and damping values it is possible to set how far some part can move, on picture below, tubes are placed horizontally in SPH and since one tube is larger and heavier it fall down and rotate free moving rotatron. However, it does not get to 90 degree of rotation due to spring joint forces:

While currently is not possible to have true limits of movement, it might become after releasing of additional WIP mod:

With that one it might be even possible to create linear shock absorbers, but for now it will be of huge help if you can just expose required things to right click menu. That will allow more experiments and future development while not breaking anything that we know that works for sure. Proper mesh parts and gamebalancing can be done later down the road of development.

 

[kcs123]

Just additional note/reminder, as there is still minor issues with IR GUIs and clicktroughs. In case that some of those old issues still exist, new mod from linuxgamer may help with it:

 

 

[Ziw]

I fiddled with jointSpring and jointDamping in a separate branch of IR. Major problem is the way KSP saves the state of the parts in the ship when you change scenes/load ship. In order to make IR springy joints you'd have to go really deep into ship loading routines and override positions of adjacent parts, otherwise you'll get the infamous "IR part drift" on save/reload. I tried that but it introduced even more bugs, but you are welcome to try.

I tried reading the code, but all comments are in German, so I cannot understand them.Feel free to ask about UI parts, they look intimidating at first, but actually quite simple once you figure them out.

[VR_Dev]

4 hours ago, Rudolf Meier said:

ok... but then we use those without the limits? and therfor only for uncontrolled 360° joints ...

the problem is this: the spring values... that's clear, those are related to the "targetPosition"... and the damping is related to the current movement. What this means is, that if you apply a force, you can pull/push the joint away from the targetPosition... now, if you allow this, then it's possible (with enough force) to move them over the limits we want for this joint... and since we cannot set those limits on the unity joint itself (as explained in an other post), then... what do we do? ignore it? break the joint when it's moving too far? ... one idea in the old code was to adjust those spring forces while the joint is moving and try to simulate limits like that (but it is almost impossible to get good results from that)... or we'd have to recreate the joint when a scene is reloaded (like this we can somehow "reset" the zero-position and then set the limits... well... not the way we want them, but almost) ... I tryed that, but... I'm not convinced that this is a good idea

the easiest would be if unity would allow limits from -360 to +360 and add also negative limits for translational joints... but... that's not going to happen soon...

Why not just destroy the part when an outside force pushes it past its limit? That's what would happen in real life anyway. It would just mean you have one more realistic thing to consider when engineering robotic structures.

Edit:

Right after i posted this I realized if the limit where 60 and the servo were at 60, any tiny force would break it, which isn't what we want. I was only considering if the servo were at 30, and something forced it 30 degrees past its limit.

13 minutes ago, Ziw said:

I fiddled with jointSpring and jointDamping in a separate branch of IR. Major problem is the way KSP saves the state of the parts in the ship when you change scenes/load ship. In order to make IR springy joints you'd have to go really deep into ship loading routines and override positions of adjacent parts, otherwise you'll get the infamous "IR part drift" on save/reload. I tried that but it introduced even more bugs, but you are welcome to try.

I tried reading the code, but all comments are in German, so I cannot understand them.Feel free to ask about UI parts, they look intimidating at first, but actually quite simple once you figure them out.

The more I learn about the springy joints the more I understand why they don't exist yet. I'm committed to trying to figure it out though. Unfortunately I think the only option is to mess with the loading sequence however.

Maybe the moduleLandingGear is the key. Having trouble finding documentation though. Also I'm curious as to their loading behavior. I'll take a look tonight how landing gear/wheels react on a flight state reload.

Edited February 20, 2018 by VR_Dev

[Rudolf Meier]

ok... I can tell you how they do it... they don't use unity's joints... they are doing it by hand... suspensionCompression is calculated from the vessel mass and the ground-hits and things like that...

we could do this too... but that's not done in 5 minutes... could be an interesting project, but I don't know if I'd like to do it now... I think that's something for a little bit later in the project, since my first goal was to build IR without the problems we had in the past... extending the capabilities comes later

... oh no... wait... they do use JointSprings. *hmm* ... and somehow they can set the ... *hmm* ... sorry... I've to investigate this further... :-) I'll be back with more info later...

ah... that's what I did misinterpret... they use the unity's WheelCollider and those do have a spring/suspention thing built in... they don't use ConfigurableJoint's for this

Edited February 20, 2018 by Rudolf Meier

[VR_Dev]

23 minutes ago, Rudolf Meier said:

ok... I can tell you how they do it... they don't use unity's joints... they are doing it by hand... suspensionCompression is calculated from the vessel mass and the ground-hits and things like that...

we could do this too... but that's not done in 5 minutes... could be an interesting project, but I don't know if I'd like to do it now... I think that's something for a little bit later in the project, since my first goal was to build IR without the problems we had in the past... extending the capabilities comes later

Yeah that's definitely how it should be done.

Didn't mean to start a whole suspension discussion. I assumed they fell under the Unity Joint umbrella and would be pretty straightforward to implement in this project.  You stick with IR and I can look into suspension.

Edited February 20, 2018 by VR_Dev

[Rudolf Meier]

3 hours ago, Ziw said:

I fiddled with jointSpring and jointDamping in a separate branch of IR. Major problem is the way KSP saves the state of the parts in the ship when you change scenes/load ship. In order to make IR springy joints you'd have to go really deep into ship loading routines and override positions of adjacent parts, otherwise you'll get the infamous "IR part drift" on save/reload. I tried that but it introduced even more bugs, but you are welcome to try.

I tried reading the code, but all comments are in German, so I cannot understand them.Feel free to ask about UI parts, they look intimidating at first, but actually quite simple once you figure them out.

You are right about the save/load. The only way it could work is to destroy and recreate every joint when it is not loaded in the correct orientation (at least the only I found) ... but it's difficult. You have to destroy it, rotate the part, re-create and re-rotate the part. And even then you cannot have other limits than from 3° to 177° (positive and negative) ... I don't like the idea. It's a lot of work for almost no result.

About the code... yup... part's are in german. But those are mostly for the IK-tests I'm doing. The "normal" code is almost free of german comments and I'm cleaning this even further now... I will release another version soon... there are still a lot of little bugs (e.g. you can move the servos without electric power and stuff like that).

 

[Rudolf Meier]

Darn! ... now that you said it's impossible to build that I want to do it... limits for non controlled joints and shock absorbers...

[kcs123]

3 hours ago, Rudolf Meier said:

Darn! ... now that you said it's impossible to build that I want to do it... limits for non controlled joints and shock absorbers...

Hmm, I did some testing when you said that parts drift and you are right. But from my observation in game it is not too bad.
What i did is that I created craft with free rotate rotatron, but with some force on jointSpring and dampers. Part is rotated 2-3 degree due to uneven weight of parts attached on left and right side of rotatron. I saved and reloaded game.

After reloading, parts on crafts seems to be in exact position as I saved, except that rotatron shows 2X more degree of rotation than it is saved. It's not issue for free rotating parts as those don't have any limits, so that kind of thing is hard to notice in game that some bug is present.

Anyhow, I was able to fix that trough existing button on right click menu that @Ziw created some time ago "Reattach Fixed Mesh". It didn't produce any wild behaviour on craft (parts moving/jumping due to spring forces or something similar). After that, rotatron in question showed again proper 2-3 degree offset as it was when I saved game for first time.

So, while not ultimate solution, some workaround might be possible. Again, it might be good to have additional variable in part config file to do following only on certain parts that is safe to do:

• after loading check for parts that have variable "ForceReattachingFixedMesh" to true
• exacute piece of code from button "Reattach Fixed Mesh" only on those parts to set proper nullpoint position
• let the game engine physics do the rest of stuff

Another possible solution might be observed after @whale_2 publish his WIP mod, to enable collision on certain craft parts. In video he already showed that part drifting issue is solved with his mod by locking certain parts.

Hope that my rantling is of some help, not much more I'm able to do right now.

[Vince_K]

 

I do not know the modding but maybe it can help. there is a motor module in ksp. why not make two pieces that move together instead of one?

 

 

[Rudolf Meier]

I was testing my new joint and... when you set the spring force to extreme values (1e38) then you can destroy the sun :-)

 

[VR_Dev]

Did some simple tests with ModuleWheelSuspension. Duplicated a wheel and took out everything but that module. Also gave it two attachment nodes. Hard to tell if it's working though. Maybe it isn't designed to use with nodes, or I don't fully understand the module settings.

Seems like the model just needs a suspensionTransformName in the mesh. This is the documentation. Seems like they already have the re-load situation figured out. 

https://kerbalspaceprogram.com/api/class_module_wheels_1_1_module_wheel_suspension.html#ac0274b5c097adaa599a366a0240fb8e8

Edited February 21, 2018 by VR_Dev

[Rudolf Meier]

5 hours ago, Rudolf Meier said:

Darn! ... now that you said it's impossible to build that I want to do it... limits for non controlled joints and shock absorbers...

ok... the uncontrolled joint with limits seems to be way easier to build than I thought... this morning, when I was drinking my coffee, I had an idea and... I first thought "that's too easy, that cannot work" ... but, I tried and... works! ... perfectly

... now, the spring-stuff... that's something I'd have to look at. But at least we do have limits now.

I'm now preparing the next alpha-release...

Edited February 21, 2018 by Rudolf Meier

[Rudolf Meier]

"rotational shock absorber" do work as well... *hmm* should also be no problem to build translational ones I guess...

anyway... I will show you those things in the next upload...