[WIP] Infernal Robotics - Next

[Rudolf Meier]

15 minutes ago, ZodiusInfuser said:

Maybe @pellinor can weigh in here (if they are still around), as they were the original coder for IR's control system. Maybe there is some way the system can be modified?

...

The system would have to be split into 2 parts. It's not generally hard to do. It only needs some new classes and interfaces... I took the old idea and left it like it was. But maybe I should change this in a future version.

I would need to split up the interpolator into 2 classes and add an interface for some kind of "direct input" ... where you can say what you want. E.g. not "MoveTo and stop there" but "MoveTo and I don't care about the end-speed"... which will then of course cause an overshooting of the position... or a "MoveTo and don't be faster than speed x when reaching the position" ?? here the questions start to come in...  

As far as I have seen, KAL-1000 doesn't care about the speed... it only commands the positions and the joints try to get there as fast as possible... I don't know if DLC robotics handles the "overshooting" in this case... maybe... but maybe DLC robotics isn't a good comparison, because they move too fast in my opinion

Edited July 12, 2019 by Rudolf Meier

[ZodiusInfuser]

2 minutes ago, Rudolf Meier said:

The system would have to be split into 2 parts. It's not generally hard to do. It only needs some new classes and interfaces... I took the old idea and left it like it was. But maybe I should change this in a future version.

Well the current system works well for what most players need it to do, so I wouldn't suggest changing it. It seems with this and KAL we have these few edge cases that want more low-level access to the servo movement. Been as though Control Mode is becoming part of the regular servo mode, that means we have the Cyan colour free for an "Advanced" or "External" mode. Think of this like how IRL smart servos have RC PWM mode (Servo Mode), continuous rotation (Rotor Mode), and serial control: https://www.robotshop.com/info/wiki/lynxmotion/view/lynxmotion-smart-servo/

[Rudolf Meier]

Sure, but the main question remains... what's the interface you want? MoveTo(targetPosition, maxTargetSpeed) ?? or MoveTo(targetPosition, maxOvershooting) ?? ... is this useful?

[ZodiusInfuser]

6 minutes ago, Rudolf Meier said:

Sure, but the main question remains... what's the interface you want? MoveTo(targetPosition, maxTargetSpeed) ?? or MoveTo(targetPosition, maxOvershooting) ?? ... is this useful?

I imagine @VR_Dev would know better but I would say the former. Internally I would say it should operate pretty similar to this: https://docs.odriverobotics.com/control , which is the control loop for the ODrive, a pretty expensive servo system that I have seen used in many robots. Depends on what part of the underlying joint is changed, (i.e. is it rotation or rotation rate).

[pellinor]

1 hour ago, ZodiusInfuser said:

Maybe @pellinor can weigh in here (if they are still around), as they were the original coder for IR's control system. Maybe there is some way the system can be modified?

A servo could run in two modes:

1) It once gets a target and then autonomously moves there, such that the trajectory respects the limits (range, speed, acceleration) and comes to a stop at the target. This process is what I call interpolation.

2) Some other device does the interpolation, and sends a position to the servo at every physics tick. The servo moves to this position without trying to stop there. It may enforce its limits, or leave that to the other device and just blindly copy the position.

When I wrote the interpolator, we built the interface for mode 1 because that was the most straightforward use of a servo. It is totally possible to add the other mode too. The simplest way would be to bypass the interpolator and overwrite the servo position each tick.

[Rudolf Meier]

16 minutes ago, pellinor said:

The simplest way would be to bypass the interpolator and overwrite the servo position each tick.

Yes, but enforcing the limits is currently done in the interpolator... I'd need to split this up. And we need another interface... not just "MoveTo" but... if I take your idea which I like ... something like "MoveStep" or "DirectMove" or whatever and you put in the next position which the joint will move into ignoring all speed and braking times (except for those we cannot ignore because of limits) ... maybe that's the way to do it... I think I like it

... and, how do we interpret the slider and KAL-1000 inputs? MoveTo or DirectMove?  ... KAL maybe DirectMove, while the slider.. I think that's a "MoveTo"

... which will make everything much more complex for users. Because we would need 2 input axis then.

Edited July 12, 2019 by Rudolf Meier

[pellinor]

Just now, Rudolf Meier said:

Yes, but enforcing the limits is currently done in the interpolator... I'd need to split this up. And we need another interface... not just "MoveTo" but... if I take your idea which I like ... something like "MoveStep" or "DirectMove" or whatever and you put in the next position which the joint will move into ignoring all speed and braking times (except for those we cannot ignore because of limits) ... maybe that's the way to do... I think I like it

Yes, if you want to check the limits, probably a second interpolator variant is the the way to go. The interface is supposed to provide a moving target and the servo tries to follow that target in real time.

[Rudolf Meier]

2 minutes ago, pellinor said:

Yes, if you want to check the limits, probably a second interpolator variant is the the way to go. The interface is supposed to provide a moving target and the servo tries to follow that target in real time.

... the only problem: If I use the axis property -> KAL feeds it -> fine... user clicks on slider to jump from 0 to 88 -> then the servo moves to 98 and comes back to 88 because it doesn't know where the input came from.

So I need 2 axis properties... and the modder would have to use the right one... maybe this works. My only question here is, wheter or not there is other default ui's in ksp that allow you to use the axis properties. Because if yes, then I don't have a problem with it, but players (non programmers) may get confused when there is a "position-axis" and a "directposition-axis"... but still, I don't see other options here

[VR_Dev]

35 minutes ago, pellinor said:

A servo could run in two modes:

1) It once gets a target and then autonomously moves there, such that the trajectory respects the limits (range, speed, acceleration) and comes to a stop at the target. This process is what I call interpolation.

2) Some other device does the interpolation, and sends a position to the servo at every physics tick. The servo moves to this position without trying to stop there. It may enforce its limits, or leave that to the other device and just blindly copy the position.

When I wrote the interpolator, we built the interface for mode 1 because that was the most straightforward use of a servo. It is totally possible to add the other mode too. The simplest way would be to bypass the interpolator and overwrite the servo position each tick.

 

2 hours ago, ZodiusInfuser said:

I imagine @VR_Dev would know better but I would say the former. Internally I would say it should operate pretty similar to this: https://docs.odriverobotics.com/control , which is the control loop for the ODrive, a pretty expensive servo system that I have seen used in many robots. Depends on what part of the underlying joint is changed, (i.e. is it rotation or rotation rate).

I have to think about all of this and type out my thoughts this weekend. In short my ideal situation would be to have full control of the raw speed. I use a PID to slow it down so I don't need internal controls to avoid overshooting. 

Edited July 12, 2019 by VR_Dev

[ZodiusInfuser]

38 minutes ago, pellinor said:

A servo could run in two modes...

Hey Pellinor! Nice to see you here, wasn't sure if you were around

6 minutes ago, Rudolf Meier said:

... the only problem: If I use the axis property -> KAL feeds it -> fine... user clicks on slider to jump from 0 to 88 -> then the servo moves to 98 and comes back to 88 because it doesn't know where the input came from.

Why would it jump up to 98 then back to 88?

My thought on this is that we have a second interpolator that is simpler than the current one, with a target and a linear speed. When the speed is low the joint will move smoothly towards the target but also adapt to sudden changes in input. If the speed is high though then the function effectively becomes the suggested DirectMove. Now how you have two interpolators interact is another matter...

[Rudolf Meier]

6 minutes ago, ZodiusInfuser said:

Why would it jump up to 98 then back to 88?

If it interprets the input as if it came from KAL-1000... then it must expect that there will be additional inputs performing a slow down towards the intended target. But this will never come, so the last input "88 as fast as possible" is still active and will remain active until it's reached... then the system detects "ups... what now?" ... and will maybe re-interpret it as "MoveTo"... or it could also say -> "Move forever" or until limit is reached...

Moving to 98 is just an example (10 braking distance)

By the way... setting the acceleration to a very high number would allow to use the servo with almost raw input.

Edited July 12, 2019 by Rudolf Meier

[VR_Dev]

1 hour ago, Rudolf Meier said:

By the way... setting the acceleration to a very high number would allow to use the servo with almost raw input.

Oh sure that makes sense. I usually have it set to 20 where I assume it's clamped?

By the way MoveTo(float float) works, it just kills the frame rate

[ZodiusInfuser]

1 minute ago, VR_Dev said:

Oh sure that makes sense. I usually have it set to 20 where I assume it's clamped?

By the way MoveTo(float float) works, it just kills the frame rate

Think the limit is a setting in the part configs, rather than a hard code limit. No idea about the frame rate problem though.

[VR_Dev]

So you can no longer call MoveTo(pos,speed) every frame, no idea why but that's the problem. Now I do need a solution to continuously set the servo position. Gonna go back to the last working KSP/IR next combo.

[RYU AZUKU99]

How much of this mod has changed?? It has been a long time since I messed with IR and I'm noticing that my game lags out crazy hard when moving more than 1 robotic part in the editor at the same time. That never used to happen with older versions of IR. Using the parts outside of the editor has virtually no effect on performance(at least with the craft in the video) at least.

Mods being used:

Atmospheric autopilot, kerbal joint reinforcement, IR Next, Mechjeb2, SuperfluousNodes, Trajectories, Tweakscale, VesselMover.

Edited July 13, 2019 by RYU AZUKU99
adding mod list for potential compatibility issue

[Rudolf Meier]

7 hours ago, RYU AZUKU99 said:

How much of this mod has changed??

Almost everything, compared to "old IR". And in 3.0.2 I'm testing a new symmetry mode. What you describe may happen in symmetry in the editor. If, then it's just in this special configuration

8 hours ago, VR_Dev said:

So you can no longer call MoveTo(pos,speed) every frame, no idea why but that's the problem. Now I do need a solution to continuously set the servo position. Gonna go back to the last working KSP/IR next combo.

I don't know why this should be a problem... if not in symmetry. With symmetry there could be some problems (it's new).

The calculations done in the background aren't that complicated I think, but it is of course much more complicated than in the classic IR, because of all those correction values used and needed.

[RYU AZUKU99]

5 hours ago, Rudolf Meier said:

Almost everything, compared to "old IR". And in 3.0.2 I'm testing a new symmetry mode. What you describe may happen in symmetry in the editor. If, then it's just in this special configuration

Doesn't just happen in symmetry mode, exact same thing happens when you move more than one individual part in the editor at the same time. I have 6 different parts not using symmetry and I get the same effect.

[Kerbalistic]

Is this supposed to mean it works with KSP version 1.7.2< or 1.7.2>  (1.7.2 and above, or 1.7.2 and below)?

 

[kcs123]

14 hours ago, Kerbalistic said:

Is this supposed to mean it works with KSP version 1.7.2< or 1.7.2>  (1.7.2 and above, or 1.7.2 and below)?

 

It means works with KSP 1.7.2 and KSP 1.7.3 and with very high probability to work with any future KSP version that is not released yet.
It should work fine with any new KSP version greater than 1.7.3 as long as SQUAD don't make some really significant changes in API (the way how game allows moders to change parts and other behaviour of KSP game itself).

[Kerbalistic]

I'm having an issue where the Force setting on the robotic parts decrease everytime I load the machine onto the world, to the point where it reaches the minimum in about 3 launches and I have to set it up again.

6 hours ago, kcs123 said:

It means works with KSP 1.7.2 and KSP 1.7.3 and with very high probability to work with any future KSP version that is not released yet.
It should work fine with any new KSP version greater than 1.7.3 as long as SQUAD don't make some really significant changes in API (the way how game allows moders to change parts and other behaviour of KSP game itself).

Oh and I managed to solve the issue that caused the question (dumb installation mistake, it was stupid) so ignore that

[Rudolf Meier]

18 hours ago, Kerbalistic said:

I'm having an issue where the Force setting on the robotic parts decrease everytime I load the machine onto the world, to the point where it reaches the minimum in about 3 launches and I have to set it up again.

Oh and I managed to solve the issue that caused the question (dumb installation mistake, it was stupid) so ignore that

thanks, I will check that...

[Svevlad]

 

Does anyone have a problem with IR parts in combination with KAL? I am experiencing a big framedrop for all creations every time I try to animate them in KAL. It becomes a big pain if you have some complex IR robotics creations. Everything works ok if you move them via IR editor but just as you try to animate those parts in KAL the frame drops even as you move curves

[Rudolf Meier]

40 minutes ago, Svevlad said:

Does anyone have a problem with IR parts in combination with KAL? I am experiencing a big framedrop for all creations every time I try to animate them in KAL. It becomes a big pain if you have some complex IR robotics creations. Everything works ok if you move them via IR editor but just as you try to animate those parts in KAL the frame drops even as you move curves

Does this also happen with dlc parts? ... currently I cannot imagine where this effect could come from. Except, from the calculation of the correction when resetting the target position in every frame. ... but it's hard to imagine that this causes a big drop in framerates. It's not that complicated...

... but maybe I can still improve it a bit. If it's not KAL itself. I think we have to do some tests before I can say more...

[Kerbalistic]

On 7/27/2019 at 1:01 PM, Rudolf Meier said:

thanks, I will check that...

Thank you. I currently have BDA, NavHud, Physics Range Extender, Tweak_Scale, VesselMover, ClickThroughBlocker and ToolbarControl installed. It's not a lot and, as far as I know, they don't have a history of interfering with other mods. (all of this is being used in 1.7.3)

I'll test it out without any other mods installed though, just to make sure im being competent. I can post the craft file too if for some reason that'd be helpfull (I doubt it would help given that you have much more knowledge in absolutely everything about this mod and a simple craft wouldnt give you any more insight)

However, out of all the other mods, Infernal Robotics is the one I have least experience on (I am trying to get into it after years not properly trying it out), so I could be a complete dumbass and be doing something wrong.

[madindehead]

23 hours ago, Svevlad said:

 

Does anyone have a problem with IR parts in combination with KAL? I am experiencing a big framedrop for all creations every time I try to animate them in KAL. It becomes a big pain if you have some complex IR robotics creations. Everything works ok if you move them via IR editor but just as you try to animate those parts in KAL the frame drops even as you move curves

I have insane frame drop when moving parts with the IR Editor Window. I found a little satellite with IR parts and just testing it in the VAB I see a frame drop from 130 FPS to around 6-20 FPS when moving the parts.

Something else I wanted to ask: Are there any good videos of people building stuff with IR or any good craft files using IR parts? I can't find a lot out there and it's the one addon I have the least experience with. All the robotics stuff really. 

Edited July 29, 2019 by madindehead