ZodiusInfuser

It is. As for its placement in the tech tree, I would have to check but I imagine it was just an arbitrary position that unlocks with some of the other advanced robotics parts. Well this does not actually dock two craft together, but rather links them like a magnet would (can also link two parts of the same craft). So I don't see why multiple would not work, although I think saving and loading breaks the link so the other craft would just fall off.

If you're doing a Career save then it should be under Meta Materials. Even if you've already unlocked that you may have to pop back in and select the specific part for it to be added to your game. Should appear under the Utility tab when added though. No, that comment about rails wasn't in reference to your post, I was just teasing some new parts that will be coming to an update soon What version if IR Next are you running? Maybe try the newest release as that seemed to fix some of the claw issues TarTi was having: https://github.com/meirumeiru/InfernalRobotics/releases/tag/v3.0.0-beta5p In general though, using the claw and docking ports with robotics is a bad idea and can cause the Kracken to show up as you have encountered. Will be interesting to see how Squad have dealt with that in the upcoming DLC.

*cough* rails

If you are wanting to move objects around without the problems of double docking, maybe look into this mod: I did the model so it will fit right in with IR Next, but you will need a lock part on both ends unlike the claw. Edit: I notice it doesn't say it's for KSP 1.7 in the title though. Maybe it works but I will poke the creator and find out.

You tease

Yes, get this version:

Note that I have not done a thorough testing pass of it yet (Ziw used to hate it when I did that previously but it did find a lot of bugs!)

Quite possibly, or they have actually spent the time and written new code for it. Also, I see a piston I did not spot in my previous view of the teaser images, so that covers the essentials for what KSP players new to robotics would want. So that's how IR should be pitched, for those players wanting more, not just in terms of parts but depth of control too. And if it turns out their system is better than IR in every way (because it's developed with game engine knowledge) then I guess I'll be porting the Model Rework over to it

I am really curious how all of this will look and work . Have you taken any inspiration from the existing robotics mods out there? May be tempted to adapt the IR Rework parts to support it if the right functionality is there.

I've just seen the news about the new DLC having robotics parts: Does anyone know about how they work (both from a user perspective and under the hood)? Wondering if they took any inspiration from IR at all for this, or went their own way. Also I only see two robotics parts in their teaser pictures (see their imgur album for the other picture). The Pivotron fits with their big trusses, and the rotatron looks like a 0.625m part, so don't fully overlap with what IR and the Rework offers. P.S. Hi btw

Glad to see this out in the wild! If anyone's interested, I modelled the lock after this IRL locking mechanism I developed during my PhD, but swapped out the latches for electro-permanent magnets.

Hey! I realise this isn't my thread, but just thought I'd show you my Unity walking sim progress since I last posted here.

I believe that's what VR_Dev was doing, yes. What I've been showing is a 3 step gait, with 2 legs moving at a time, and I'm currently testing a 5 step gait on a 10 legged robot. KurtE was basically the expert for hexapods back in the day, so it doesn't surprise me the code is well commented. That code file in particular is for an Arduino board variant called Botboarduino, so I imagine a lot of it is the way it is to get around the 16Mhz clock speed of the microcontroller, and lack of a floating point unit. It being C rather than C++ is likely because the Arduino IDE doesn't make it clear that many of these chips do actually support C++. This is why I personally use Visual Studio for programming all my Arduino projects. Hexapods, or rather any walker with more than 4 legs are what are called statically stable, meaning that if the control software were to lock up at any time, the robot would not fall over. You are right about my irl hexapod not being "rigid", and has comically collapsed due to loss of motor power before . (vid of hexapod here if you haven't seen it) For Infernal Robotics though, I believe those hold their position even if no power is provided. PID is not something I've explored yet on hardware, as all servos contain the Proportional part of PID, and don't typically let you read their angle to implement the other two parameters in software. Will be interesting to hear what you find out

Oh yes, they're great for debugging! The actual calculations are all done relative to the body (sphere), so I then when move the body in world space the paths should be smooth with no sudden jumps or sliding. Code isn't available yet, but I would like to get something out there this month. Actually, I am hoping it will lead to a more dynamic walk cycle with some legs taking multiple strides for every one of another leg, and the ability to change gait whilst walking. But we'll have to see. My learning journey for hexapods was from the old Lynxmotion forums, back when I built my own IRL hexapod. They were a company that sold walker kits, with various people making code to get them moving. Here's one relevant webpage: http://www.lynxmotion.com/images/html/proj102.htm The general thing to know is that there's actually two separate problems to deal with, the Inverse Kinematics of calculating the joint angles needed to have the end point of the leg align to a target position, then moving those target positions in such a way that produces a smooth motion. Currently what I have shown only deals with the latter, whereas VR_Dev is exploring both.

Great to see this being taken over from Ziw and Rudolf! I remember us having big plans for this back in the day (and IR itself) but real life got in the way so the state machine functionality was the last feature that got implemented. I could do him a custom banner image too if he really wants . I still have all the old IR logo and UI assets in svg format after all.

Ah cool that you're developing your own gait sequencer, and it's interesting how different our approaches are. In mine the gait sequencer is abstracted from physical coordinates, so rather than giving it positions I give it stride start and end times for a looping cycle. This allows me to compute a line/arc for each leg to follow, and scale the length and time-step of the gait accordingly, ensuring that all steps stay within the capsule outlines I define on the ground (can be circles too). So far this has worked pretty well, letting me change the user input on the fly (as my second tweet shows). Of course there is no physical or simulated robot yet so there may be factors I have yet to consider, so we'll have to see. Terrain adaptation works though, which is nice. Thanks for putting your code up! Once I have something of mine up I will take a look. I imagine much of your IK stuff will be very useful! What license you using?

I don't do any more unfortunately, but back in the day I was involved in all sorts of things for the game! You can see some of the things on my old site, which is still live: http://id.tauniverse.com/ In fact my profile picture on here is the icon of a custom unit I made. A walker of course

Hey @VR_Dev, Cool to see you revisiting this! I know you worked on your own walking algorithm and terrain adaptation in the past for this, but I don't suppose you're interested in exploring other options? I remember you saying previously that the bridge part was the thing that interested you most. The reason I ask is because I've recently been porting and updating some old walking code over to Unity to test out before porting to Arduino for my IRL Hexapod, and thought it could be good for KSP too. I've actually been working on this code for the past 15 years in various forms and programming languages, with the first versions being scripts for walking units in the video game Total Annihilation. You can see gifs of two units from the game below. Incidentally these were taken by someone who's recreating the game engine, so used them to verify the script parser worked. Then there was this attempt in C# + XNA I did 10 years ago: Since then I've been rethinking the system and making notes but only in the last month have I had the urge to try the code. You can see various gifs below (forgive them in being tweets). Note that I am not interested in the inverse kinematics at this stage, but rather the trajectory planning of the leg target coordinates. Also the big thing with this is that it's not specific to 6 legs. Here's a test I did with 10, but I don't think there's any real upper limit. Hope to put this code up on github sometime this month. Cheers!

Talk about jumping in at the deep end! Some of the algorithms involved in getting hexapods walking can be very complex, so I hope they provide you with a code base to get you started! If you really do not know what KSP is, then the tl:dr is, it's a physics-based space simulation game. One of it's big features is the ability to support mods, so mods like Infernal Robotics add moving parts to the game, making it great for re-creating unmanned space missions, but also for testing our mechanical concepts without forking out all the money on parts first. Having built my own hexapod IRL I am very aware of how expensive that can get! @VR_Dev 's project attempts to use KSP and Infernal Robotics as both the user interface for creating contraptions and the physics engine for simulating them, but with the control being by a completely separate application. I'm sure he can elaborate on any specifics you may have.

My vote would be for 1.4.1 only, however I understand that people can still download the old version through the beta's tab in Steam.

Ah okay, apologies. As you were.

Are these just scales your testing? Because for the rework parts at least those scales were chosen for specific reasons and should be kept.

In a way he is, although myself, Ziw and Sirkut do have some involvement in design decisions. What has been discussed so far is that once IR Next has had time to prove itself, it will be merged back in to the main IR distribution as IR 3.0.

Given that the Making History Expansion is coming out next week, I suspect most modders will be waiting for that to see if a KSP 1.4.1 drops with it too. So I would suggest holding off with a 1.4 release until after the expansion is out. Of course, that won't change the unity version so testing now is a good idea. Personally, I'm quite interested to see how all this model / texture switching / theme stuff works. After all, it would be very easy to create alternate themes for the rework parts given their "I can't do texturing, so here's solid colours instead" style

This. Don't spread the direct link. If you must share something then share the forum post for the link instead.