[WIP] Infernal Robotics - Next

[WhyAmILikeThis]

5 hours ago, Rudolf Meier said:

And beside the possible incompatibility with the KSP version it is also possible to see such behaviour if you didn't first remove the folders of KJR before installing the new one. We had situations in the past when users ended up with 2 KJR dlls installed. This then showed similar problems.

I am running KJR 3.3.3, and the 3.0.0 beta version of IR. I used that one cause the file name said "for 1.3.1." As for the duplicate KJR thing, I have a nasty habit of letting windows overwrite like files when I update, so it's possible something slipped through and is wrecking everything. I appreciate y'all's help!

[Rudolf Meier]

2 minutes ago, WhyAmILikeThis said:

I am running KJR 3.3.3, and the 3.0.0 beta version of IR.

This won't work at all... I don't recommend those beta version. Some of them contain experimental code and only the release is really a good versoin. And KJR 3.3.3 is none of my KJRs. It doesn't work with IR at all. I recommend to do an upgrade to at least 1.4 and use the latest KJR Next and IR Next.

For those who don't know why there is this "not before 1.4" requirement. It's because 1.4 did get a new version of Unity. That's a big difference and why support can only be provided for 1.4 and later.

[WhyAmILikeThis]

Just now, Rudolf Meier said:

This won't work at all... I don't recommend those beta version. Some of them contain experimental code and only the release is really a good versoin. And KJR 3.3.3 is none of my KJRs. It doesn't work with IR at all. I recommend to do an upgrade to at least 1.4 and use the latest KJR Next and IR Next.

For those who don't know why there is this "not before 1.4" requirement. It's because 1.4 did get a new version of Unity. That's a big difference and why support can only be provided for 1.4 and later.

Oh oh. Okay. I was afraid the problem was going something like that. Oh well. I was hoping moving stuff in my 1.3.1 game but that's ok. I was rebuilding my mod collection for 1.7.2 anyway. Anyway thanks for your help! IR has always been one of my favorite mods and I love what you've done with it. Keep it up!

[Masoneus]

6 hours ago, Rudolf Meier said:

And beside the possible incompatibility with the KSP version it is also possible to see such behaviour if you didn't first remove the folders of KJR before installing the new one. We had situations in the past when users ended up with 2 KJR dlls installed. This then showed similar problems.

Speaking of KJR, I'm pretty sure that I don't have it installed...do I need to install it to make IRN more stable? Had a ship with about 25 IR parts and it made the game super laggy.

[Rudolf Meier]

24 minutes ago, Masoneus said:

Speaking of KJR, I'm pretty sure that I don't have it installed...do I need to install it to make IRN more stable? Had a ship with about 25 IR parts and it made the game super laggy.

I think KJR Next is always a good thing to install. I personally think, that playing KSP without KJR is almost impossible. And, sure it adds some load to the game. But that's what autostruts would do too and you need at least one of those things to play the game (it's so unstable otherwise). And the advantage of KJR Next is, that it's an automatic way of stabilizing things and also a very  optimized way of doing it.

So... I highly recommend it (but only KJR Next... the other versions don't have a great support for moving parts and are overall... not that optimized).

[nmc]

On 7/3/2019 at 8:16 PM, ZodiusInfuser said:

Following up on the structural hub stuff from the other week, I think I have created a complete collection of Hex Hubs.

I have a question though. Do you want to be able to surface attach these parts to others or have them purely be node attach? The reason I ask is because I plan to use the stock variant system for them and it has a bug (or missing feature) where when changing variants it won't change the surface attachment point. This means I have have to separate some of the parts out based on the surface attach height (all those in the bottom right), in addition to separating by the number of nodes. I imagine using the B9MeshSwitch would avoid this issue but after discussion with Rudolf it was agreed that IR should have no hard dependencies on other mods.

Also, usual question of too many / not enough? I started imagining bridges and other A-frame structures being made with them so the variant count snowballed a bit  

Nice work!

 

I am against surface attachment for these parts, even without knowing about the bug you mentioned. Also, that's quite enough parts for me, thanks!

[ZodiusInfuser]

17 hours ago, nmc said:

Nice work!

I am against surface attachment for these parts, even without knowing about the bug you mentioned. Also, that's quite enough parts for me, thanks!

Thanks! I think surface attachment is something I will have to try out in-game, as at least for the cubic hubs I can see it being useful (but they wouldn't suffer from this bug anyway so it's a non-issue there).

In the meantime I looped back to ActiveStruts. For those not familiar, ActiveStruts was a mod (kottabos video here: https://www.youtube.com/watch?v=ryIGnlaan_k) that IR acquired many years ago, that let you create struts in flight. As you can imagine this proved quite useful for robotics. Anyway, for various reasons the mod was removed from IR but now me and Rudolf are looking to bring it back, this time with whole new models!

The biggest task with these new models was to make them more realistic, so I endeavoured to based them on as many real-world mechanisms and technologies as possible (the rigid strut itself is based on this https://www.youtube.com/watch?v=O56oBIwEtp0). Let me go through the parts you see:

• On the right we have two magnet-based ActiveStruts, which have a fixed angle and can extend up to 3m. These would be the most basic in terms of tech tree access (and cheapest).
• In the middle we have two anchor-based (aka microspines) ActiveStruts, which will be aim-able in a given range and can extend up to 5m. The anchor would theoretically allow them to attach to the ground and asteroids. These would be the most advanced in terms of tech tree access.
• The left three parts are latch-based ActiveStruts, which will be able to automatically track their assigned receptacle part (far left) and can extend up to 5m. This would offer the strongest connection to reward players for pre-planning their builds with the receptacles included, for example if you know the retracted and deployed states of a craft. Here you can see an example connection: 

So, that's our plans for returning ActiveStruts to IR. No ETA on this as there is much coding and part configuring still to do, but the models themselves are close to final so I thought I'd share

Edit: For reference, this is what the old part offering was:

Edited July 9, 2019 by ZodiusInfuser

[PriusMann]

Quote

Quote

help i just downloaded the 1.7.2 ir-next parts and i opened my game it has the parts filter but in it doesnt contain a single robotic part what am i doing wrong?!?!?!

 

 

[ZodiusInfuser]

On 7/9/2019 at 1:25 PM, PriusMann said:

 

Usually that is because the files were installed incorrectly. You should have a MagicSmokeIndustries folder within KSP/GameData, the same folder where Squad and SquadExpansion are. If you have a Gamedata folder inside KSP/GameData then you need to move its content out and put it in the higher one.

[VR_Dev]

hey @Rudolf Meier, I dont think you are officially supporting the IRWrapper anymore but I'm curious if you could help me out. My robotics plugin is built on that and I know kOS is too. A couple updates ago "InfernalRobotics_v3.Command.ControlGroup" changed to "InfernalRobotics_v3.Command.ServoGroup". 

I updated this in the IRWrapper.InitWrapper() which works, but I get this error when I call IControlGroup.Servos:

"[LOG 13:07:12.903] 7/10/2019 1:07:12 PM,MemoryBridgeServer-IRWrapper,Error extracting from actualServos: Object reference not set to an instance of an object"

Curious if you could give me some insight, or point me in the right direction. Thanks

Edited July 10, 2019 by VR_Dev

[Rudolf Meier]

10 minutes ago, VR_Dev said:

hey @Rudolf Meier, I dont think you are officially supporting the IRWrapper anymore ...

no, it is still supported... does the code not work from https://github.com/meirumeiru/IR-Sequencer?? inside there you should find the API that should work with the latest version... if not, then I'd have to fix that

[VR_Dev]

13 minutes ago, Rudolf Meier said:

no, it is still supported... does the code not work from https://github.com/meirumeiru/IR-Sequencer?? inside there you should find the API that should work with the latest version... if not, then I'd have to fix that

Thanks for the help, didn't know to look there, unfortunately now InitWrapper is failing with :

"[LOG 14:01:42.705] 7/10/2019 2:01:42 PM,MemoryBridgeServer-IRWrapper,[IR Wrapper] Failed to grab MotorGroup Type"

I'm using 3.0.2 and I do see the IMotor.cs file in Interfaces, which matches  "if (t.FullName == "InfernalRobotics_v3.Interfaces.IMotor") { IRMotorType = t; }" in InitWrapper(). So I'm not sure why its failing.

 

[Rudolf Meier]

1 hour ago, VR_Dev said:

Thanks for the help, didn't know to look there, unfortunately now InitWrapper is failing with :

"[LOG 14:01:42.705] 7/10/2019 2:01:42 PM,MemoryBridgeServer-IRWrapper,[IR Wrapper] Failed to grab MotorGroup Type"

I'm using 3.0.2 and I do see the IMotor.cs file in Interfaces, which matches  "if (t.FullName == "InfernalRobotics_v3.Interfaces.IMotor") { IRMotorType = t; }" in InitWrapper(). So I'm not sure why its failing.

 

there is an IMotor and IMotorGroup... it's not the same... the problem is, that they (IMotorGroup and IServoGroup) are not in the "Command" namespace but in "Interfaces" ... that's wrong, I should fix that

Edited July 10, 2019 by Rudolf Meier

[VR_Dev]

On 7/10/2019 at 3:10 PM, Rudolf Meier said:

there is an IMotor and IMotorGroup... it's not the same... the problem is, that they (IMotorGroup and IServoGroup) are not in the "Command" namespace but in "Interfaces" ... that's wrong, I should fix that

ok, so I actually misread the error, I thought it was failing on IMotor but it was failing on IMotorGroup. Once I change that and IServoGroup to the Interfaces namespace, (as well as some other naming convention changes "Speed") the wrapper successfully initiates. 

Now I get a null reference on IServo.Position. I assume this has something to do with the differences between IServo and IMotor in the plugin, and IServo not even having a Position value.

Edit : hmm but IServo inherits from IMotor, now I'm really confused

Edited July 12, 2019 by VR_Dev

[VR_Dev]

So I got my mod to work by changing this line, but the framerate tanks even with just a couple servos in the scene. Been doing some testing and im 95% sure its not on my end. Nothing of mine has changed and there are no errors being thrown. Seems like a silent reflection error in the wrapper.

 positionProperty = IRServoType.GetProperty("Position"); 

to

 positionProperty = IRMotorType.GetProperty("Position"); 

My confusion continues.

Edit : Yeah its failing silently on IServo.MoveTo(float pos, float speed).  FindMethods() seems to be correct though

 moveToMethod = IRMotorType.GetMethod("MoveTo", new[] { typeof(float), typeof(float) });

Edited July 12, 2019 by VR_Dev

[Rudolf Meier]

4 hours ago, VR_Dev said:

 positionProperty = IRServoType.GetProperty("Position"); 

there's an important thing to notice... there is a "commandedPosition" and a "Position" ... what you want to use is the "commandedPosition" (and "commandedSpeed"). those values are those that you can see in the UI of IR, while the others are the real positions (but they're much more unstable and only meant for other purposes... if you're mod is really aware of this difference)

[VR_Dev]

6 hours ago, Rudolf Meier said:

there's an important thing to notice... there is a "commandedPosition" and a "Position" ... what you want to use is the "commandedPosition" (and "commandedSpeed"). those values are those that you can see in the UI of IR, while the others are the real positions (but they're much more unstable and only meant for other purposes... if you're mod is really aware of this difference)

Sure, my understanding is "Position" is where the servo actually is, and "CommandPosition" it is set to be at. When there is ground contact with an IR limb the servo is very rarely at the position it is set to, which is why Position is useful to me. I need to know where the limb actually is. I'm also setting the speed of the servo based on where the servo actually is. If my code thinks the servo is actually in the right position, the speed will be set incorrectly. Either way I might just switch to using raw rotation of the joint anyway.

I dont think this solves my new problem anyway. You may have not seen the edit but something is broken in IServo.MoveTo(float pos, float speed). Thats the next thing I need to figure out

[Rudolf Meier]

2 minutes ago, VR_Dev said:

Sure, my understanding is "Position" is where the servo actually is, and "CommandPosition" it is set to be at. When there is ground contact with an IR limb the servo is very rarely at the position it is set to, which is why Position is useful to me. I need to know where the limb actually is. I'm also setting the speed of the servo based on where the servo actually is. If my code thinks the servo is actually in the right position, the speed will be set incorrectly. Either way I might just switch to using raw rotation of the joint anyway.

I dont think this solves my new problem anyway. You may have not seen the edit but something is broken in IServo.MoveTo(float pos, float speed). Thats the next thing I need to figure out

Yes, but it's not meant to be used like that. If commandedPosition is e.g. 33° and it is on position 32.85°, then it is because of a too heavy load and the system will try to go to 33° until it reaches this position. So if you now send a command to go to 34.5° because you think you can then reach 33°, that's very dangerous and puts unneeded stress on the system. You should let the system try to reach the position and not try to "correct an error with an other error" ...

[ZodiusInfuser]

Maybe this would warrant a different control system then? For things like inverse kinematics, VR_Dev's walking, and even the sub/object tracker, having the ability to set a new commanded position every fixedUpdate and them perform any relevant feedback loop would be particularly useful. After all real life servos usually only have a proportional loop (maybe a full PID if they're smart servos).

[VR_Dev]

2 hours ago, Rudolf Meier said:

Yes, but it's not meant to be used like that. If commandedPosition is e.g. 33° and it is on position 32.85°, then it is because of a too heavy load and the system will try to go to 33° until it reaches this position. So if you now send a command to go to 34.5° because you think you can then reach 33°, that's very dangerous and puts unneeded stress on the system. You should let the system try to reach the position and not try to "correct an error with an other error" ...

 

1 hour ago, ZodiusInfuser said:

Maybe this would warrant a different control system then? For things like inverse kinematics, VR_Dev's walking, and even the sub/object tracker, having the ability to set a new commanded position every fixedUpdate and them perform any relevant feedback loop would be particularly useful. After all real life servos usually only have a proportional loop (maybe a full PID if they're smart servos).

thanks Rudolf that is really helpful information that should benefit my project greatly. However I don't set the servo to 34.5 to try and force it from 32.85 to 33, i set the servo to 34.5 because the limb is meant to move constantly. I use the speed and acceleration to try and force it to what it is set to.  (I should probably start using the force though, I was just never quite sure what what force did)

Which is why I agree that a solution to set the servos every fixed update would be useful though. I understand this may be a lot of extra work though.

Edited July 12, 2019 by VR_Dev

[Rudolf Meier]

15 minutes ago, VR_Dev said:

Which is why I agree that a solution to set the servos every fixed update would be useful though. I understand this may be a lot of extra work though.

The problem here is, that this would be an external controller for the movement and this is somewhat against the idea that we have implemented. It's a bit the same situation with the KAL-1000. If I would accept the commands just like they are set, then it could be that we run into a situation in which for example the joint won't be able to stop before reaching its limits. That's one problem... the second one is, when you often do an update, the system tries not to get faster than a specific speed so that it can stop at the position you commanded. E.g. if you want to move from 0 to 12 and you command 0.2, 0.4, 0.6, 0.8... then the system will look at the acceleration possible and never go to a full speed, because it always thinks it has to stop after the next 0.2 step. If you want a smooth movement, you should command position 12 and speed e.g. 0.4 if you want this speed to be reached while moving. Then it accelerates to 0.4 as fast as possible, moves until e.g. 11.55 so that it has enough time to decelerate and then it stops at 12.

[VR_Dev]

34 minutes ago, Rudolf Meier said:

The problem here is, that this would be an external controller for the movement and this is somewhat against the idea that we have implemented. It's a bit the same situation with the KAL-1000. If I would accept the commands just like they are set, then it could be that we run into a situation in which for example the joint won't be able to stop before reaching its limits. That's one problem... the second one is, when you often do an update, the system tries not to get faster than a specific speed so that it can stop at the position you commanded. E.g. if you want to move from 0 to 12 and you command 0.2, 0.4, 0.6, 0.8... then the system will look at the acceleration possible and never go to a full speed, because it always thinks it has to stop after the next 0.2 step. If you want a smooth movement, you should command position 12 and speed e.g. 0.4 if you want this speed to be reached while moving. Then it accelerates to 0.4 as fast as possible, moves until e.g. 11.55 so that it has enough time to decelerate and then it stops at 12.

Sure, this is something I have been considering for a long time. I have attempted to use only 3 points in the gait, a front ground position, back ground position, and arc height position, but for reasons I cant remember I decided this way was working better (it also looks cooler in my unity window with one leg following the other, so maybe that was it), but I totally understand the downside of setting the position to intermediate positions between the final position.

I will take all of these things into consideration once I get up and running, which MoveTo is preventing me from.

Edited July 12, 2019 by VR_Dev

[Rudolf Meier]

38 minutes ago, VR_Dev said:

I will take all of these things into consideration once I get up and running, which MoveTo is preventing me from.

did you look at the interfaces-files to see if something changed? ... I changed quite a bit from the last beta to the release... and the api files are not fully up to date

[VR_Dev]

20 minutes ago, Rudolf Meier said:

did you look at the interfaces-files to see if something changed? ... I changed quite a bit from the last beta to the release... and the api files are not fully up to date

moveToMethod = IRMotorType.GetMethod("MoveTo", new[] { typeof(float), typeof(float) });

This is the call and it matches the InfernalRobotics_v3.Interfaces.IMotor.MoveTo(float position, float speed);

[ZodiusInfuser]

1 hour ago, Rudolf Meier said:

The problem here is, that this would be an external controller for the movement and this is somewhat against the idea that we have implemented. It's a bit the same situation with the KAL-1000. If I would accept the commands just like they are set, then it could be that we run into a situation in which for example the joint won't be able to stop before reaching its limits. That's one problem... the second one is, when you often do an update, the system tries not to get faster than a specific speed so that it can stop at the position you commanded

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?

1 hour ago, Rudolf Meier said:

E.g. if you want to move from 0 to 12 and you command 0.2, 0.4, 0.6, 0.8... then the system will look at the acceleration possible and never go to a full speed, because it always thinks it has to stop after the next 0.2 step. If you want a smooth movement, you should command position 12 and speed e.g. 0.4 if you want this speed to be reached while moving. Then it accelerates to 0.4 as fast as possible, moves until e.g. 11.55 so that it has enough time to decelerate and then it stops at 12.

The point I would like to add here is that the reason you would want to set a position every update is because you A) do not know that 12 is your end position ahead of time due to the dynamic nature of the movement system you are trying to implement (i.e. you only know at this point in time it should be at 7 for example), and B) maybe 12 is where you want to go but because of whatever IK algorithm is being used, and the connectivity of the joints, a linear motion in space may not translate to a linear rotation rate (i.e. maybe you want to go 1, 2,6,9,11,12). These are situations I have personally encountered with both with IRL robotics and this thing below that we have talked privately about before. Also your own IK thing will encounter problem B.