Hooligan Labs

I can't believe how the mod airship fundamentally still works after all these years. Though maybe @JewelShisen has rewritten it entirely by this point. It's brilliant, the way that KSP has structured mods so they can share code. It's not exactly easy to test, but it can be very robust. I hope this spirit lives on in KSP2.

Beautiful photos! I love it! A long time ago, I did make a mod that allowed underwater travel in KSP. It wasn't very good because KSP did not have anything under water, and stuff would simply crash the game under a certain depth. Some time after that, KSP rolled out an update which changed buoyancy and allowed stock subs. But I feel that has been rolled back quietly in some update after that - everything floats again. Not sure of the status now.

That's interesting! Do you think that the explosion at gait start could have been the horizontal velocity of the foot along the ground? It looks like the foot isn't picking itself up off the ground as quickly as before. That may be due to your adjustment where the target position begins below the ground.

Looking forward to this. I would recommend the MIT license then. It is what I used for all my mods. It simply protects the creator from liability. If you want to read more: https://opensource.org/licenses/MIT Cool! I see that I understood some of it wrong though. If you post and update with some comments, I'd be happy to take another look. That's not a cheat, that's smart. Unity has very good and fool-proof rotation, which should be taken advantage of! I'm not sure if I can recommend a specific solution. I just know that your feet should not hit the ground so fast they explode. Seems like a good control to have. I think you worked against yourself by accident! Usually a high D does help reduce velocity, but if the target moves away rapidly then the D actually increases your pursuit speed. I could see this being a little off. Also, I'm pretty sure KSP uses a few complex rotating reference frames so Y isn't guaranteed to be up. It is a little more computationally expensive, but I would recommend a raycast from every mesh point on the foot in the direction of gravity and use the smallest number. If that lags, perhaps do the raycast from the mesh point that has the largest dot product in the direction of gravity from the servo location. I think this is how you find the mesh's verticies at runtime: https://docs.unity3d.com/ScriptReference/MeshCollider-sharedMesh.html By the way, you might still want to put feet at the end of your legs. I bet those engines have a rather small coefficient of friction.

I got some more time to go through @VR_Dev's repo. First, I'd like to say that the more I read, the more impressed I am. There is a lot of interesting code here just to glue together the robot, and the mirror it in KSP! As for your motion, I think that the feet are meant to be lifted or placed by this bit of code. globalPoint.y = ground.position.y; if(limbIK.legMode == RoboticLimbIK.LegMode.Translate) { globalPoint.y -= baseOffset; } I would expect to see more of a snapping motion between these y positions. However, in your video the graphics for targeted location moves smoothly. I think that's the red skeleton. It appears that you are achieving this smooth appearing target motion with RunGait(). At the start of the step, the target is way up in the air and near the foot's starting position. But then it is lerped forward and down to the actual target point on the ground at a speed per second controlled by the factor "limbController.roboticController.walkSpeed". I'm not sure, but there may actually be 3 targets: One that is between the fully lifted foot position and the target position, and then another between the foot and it's immediate target. My guess that the "slam" is being caused by the PID tuning, like VR_Dev mentioned some posts ago. I think the PID values are being set in test.unity as: hipElvPID_P: 1.5 hipElvPID_I: 1 hipElvPID_D: 4 From my PID experience, these are VERY large values for I and D! It's not uncommon to zero out I and D and use P alone because of how much damage those values can do. In my theory, here is what is happening: P (proportional) value simply is factoring the distance from target to actual position. This relationship is linear. There is only a spike in output if there is a distance spike. D (derivative) I (integral) is infamous because it effectively sum of all error over time, which can be horribly unpredictable in practice. It is good for handling error that the other factors can't. For example, a rusty door that is not quite closed may not be handled by P (can't overcome the friction) or D (doesn't care about position). However, the I value would eventually accumulate enough error to increase the force enough to close the door. I think this affects the walking gait like so: At the start of a step, the target is instantly above the foot. This snaps up the P and D values. The foot snaps up in the air. Good behavior. The target moves forward and down. P wants to cause overshoot, but the D factor helps prevent this, as a high closing rate = negative distance over time = a large negative value. Not bad behavior, but the I factor may be slowly increasing this whole time due to small errors between actual and target position. Foot goes to final position. P is of course small as the foot is already very close to the target to trigger this action. However, D is large! An instant change in target is effectively infinite slope! Thus, looking at ControlVariable or PidController, which seems to be called in FixedUpdate of VesselControl, probably the resulting value is 0.05 * 4 / 0.01 = 20! The I factor might not react quickly, but it probably adds to the resulting "slam" and may cause the foot to wiggle once it does reach the ground. Therefore, I have the following recommendations: Replace the PID with a ease-down function when the foot reaches the ground, just for comfort. You could instead have different PID settings for each part of the walk. Maybe even remove having the target snap to the final desired position. Zero out the I value. At least reset its calculation when the foot is about to touch the ground, maybe even the whole time the foot is on the ground. Depends on what you want I to do. Reduce the D value. You may also have to reduce the P value to prevent overshoot. If this reduces walking ability, then you can reduce the walking speed and increase the baseOffset height. Not a great solution but could help. I notice that the D value of the hip rotation is already 0. Because the problem is slamming, not swinging, maybe the rotation P and D could increase while the Elev P and D decrease. A way to test this would be to output the calculated results of the P, I and D factors and see how much they influence your system. If you see that I and D are adding a lot of torque to your servos when the foot goes down then my theory may be correct. Other notes:

Any page that ends with controlling a robot with a Wiimote is a good page. It seems that you both are working on a 2 step gait system, where 3 sets of legs alternate stance-swing-stance-swing. I followed a few links from this page and ended up at this page, which I feel has some well commented code on walking gaits (even if it's not obvious from the file name) https://github.com/KurtE/BBD_SSC32_PS2/blob/39cd7a77ea5bd72fa1afd03654c08ff82466f766/BBD_SSC32_PS2.ino If this is what the hexapod community is used to then I could see something like Unity being a big help. That is a lot of intense C code, servo trickery and mental coordinate conversion without abstraction! I do see the benefit of working on these hexapods. Good stability seems possible with gaits calculated by linear algebra. Is it correct that your systems are not "rigid" and without power the robot would collapse to the ground? If so, is all the dampening through PID, and that is enough for the robot to not visibly stagger or sway? Hope to have time to look through more of the technical information soon.

@ZodiusInfuser I do like the graphical interface you have here, must help a lot for debugging paths. Is your code also available for us to look at? It would seem to me that this would make for a more rigid walking cycle, but maybe I just need to see how you did it. It seems you two have a shared understanding of hexapod walking. Can you recommend where I can read up on the technical aspects? And it looks like VR_Dev's code creates a PID controller from IR to walk?

Unfortunately, I'm not able to find your repo. Where is the link? My guess is that you should control the foot "touchdown" by velocity. Each KSP part has a certain velocity impact which it can take, above that it explodes. Multiply that speed by a safety factor and it should be good. I'm not sure where you are getting "servo.HostPart.GroundPosition", but in my experience these special APIs can be meant for a very specific purpose and eventually break as new KSP versions come out. Your target position looks good. If you need a better estimate of distance, I would recommend a simple Physics.Raycast in the direction of gravity (which moves because KSP is way more realistic than most games). Here is some pseudocode of how I imagine the touchdown could work. // This is only intended for right before the foot touches the ground, assuming the foot is travelling in the right direction. A dot product or angle comparison between the intended travel direction and actual travel direction may be good as a sanity check. float V_max; // Fastest speed that we can safetly touch the ground float V_min; // We can go faster than this float V_now; // Current velocity magnitude of part. KSP's API or base Unity code should work equally well, since they are the same for physics in the immediate location. if (V_now > V_min) { // Going faster than needed? if (V_now > V_max) return; // Speed is fine servoSlowDown(); // Too fast, apply torque in direction slowing the foot } else { // Going way slower than needed servoSpeedUp(); // Increase speed that the foot is being lowered } A quick P control on the velocity may be enough to know how much extra torque to apply. If this results in jerky movement (especially in different gravities), I would recommend calculating the desired torque by calculating leg weight and by considering leg distance.

Wow, we now have people who do TA mods here? This thread just gets more awesome.

Yes, KSP is unique in that it simulates interplanetary rocket construction and travel at real time or faster. The physics are surprisingly accurate too. There is a good reason why NASA officially supports this game. KSP is made with a game engine called Unity, which is like a 3D modeling program fully integrated with Visual Studio. A lot of physics is available free out of the box. This makes it easy to have code manipulate objects realistically. Tying KSP and robotics together makes sense because our community is mega nerdy and totally supports it.

This not only an amazing mod, but also the resulting software is amazing. Professional engineering software can't do what this can do.

I hate to say it, but a big reason why I stopped modding KSP was because it took less time to write a whole game prototype from scratch in Unity than to make a simple KSP plugin. I did a quick search and this is the dev tool I was referring too. Maybe it still works! https://kerbal.curseforge.com/projects/magic-smoke-industries-devhelper-v0-4?gameCategorySlug=ksp-mods&projectID=221289

That is a good point, Stone Blue. Having to restart KSP when deving is time consuming. Maybe VR_Dev has a wizardry for this, but I doubt you can change what KSP compiles after you start the run. What makes the plugins and mods work is so cool that Squad hired the guy who invented it. Feedback into the KSP runtime may be limited. Probably could throttle engines, turn the ship, etc. It would need a mod like TweakScale to go deep into the system and expose its variables. I could see it working in the other direction -> you could have a Unity environment where you run tests based on the output from an active KSP game. Like a "hardware in the loop" test. In the meantime, there are mods out there that skip the start screen and do little things to improve dev workflow. The best would be if Squad released a Unity sandbox that was just like KSP, but that is too much to ask.

Hello @VR_Dev, I have to say something because this work is very interesting. I was looking at the KSP forums for about the first time in a... year? I found your YouTube videos with tech like Leap Motion very interesting since I work with ARcore and the like. I have KSP to thank for this, because I learned OOP and Unity by doing an airship mod years ago. Also, your progress with the walking robot looks very impressive. I have a number of projects I started to create a walking robot like this in Unity, but have not come close to the level of that you've been able to achieve by hooking it up to KSP with IK like this. Are you still working on this project? I see you invited others to try building their own robots.

Not sure what's going on with this license thing, but it is weird. I actually had my original mod taken down years ago because I didn't want to put any restrictions on it at all. Eventually we agreed to put the MIT license on it which is super permissive. I take it Curse has some additional license on it? Well, as the original author, I hope this remains very easy for all to access.

Hi, I originally wrote the submarine mod before they changed water physics to be more realistic. I would recommend another mod that has updated since. I think those links would work, and Scott Manley or similar may have videos demonstrating if you search YouTube.

The way they now allow for in flight saving makes something like that so much easier. I've built floating colonies on Jool (see my bungee jumping video) but it required wired use of anchors and ships would mysteriously disappear often. I heard your IVA may want to be looked at? Is the model posted somewhere?

Hooray! I'll try it

That's cool! Node sizes affect break torque? I made this back in beta, before we even had electricity in the game. It goes further back than that! I got the original code and models from someone doing a simple and ultimately totally broken blimp thing. And he got his code from some original brilliant Unity programmer... I actually learned to use open source and object oriented programming by making this mod. I helped a bit with Firespitter when it started. He always blew me away with how he made great models and textures so simply. Glad he got a chance to work on the KSP team.

Nice. The resource thing is a bit cheats, even though I argued it was fine years ago. I think what makes it more cheaty though is how I always set the break away strength of the airship parts very high. So it could be used when parachutes wouldn't work. Is that still true?

Very cool. If the airship mod is doing fine maybe I'll try to fit a different mod in. I'm making progress on a physics-based walking mech thing, but I'll probably need help to do integration into KSP in any reasonable amount of time.

That is a nice airship, Spanner! Glad to see new textures going onto the airships. It's weird to come back years later and see most things look the same! I'd just like to add a few comments of my own, from poking around the internet about this mod... Maybe take down the Curse page? It's still the top result for KSP airships, and it's confusing if you are no longer using it. The next result after that is something like "Is the airship mod cheating"? Which is probably a lot my fault, but has that ever been addressed?

Hello everyone, esp. Jewel! I see the reports of this mod being dead are greatly exaggerated.

Yep it's me. You can check my profile for the lots of old posts I have. Sorry, didn't know it was still running. I got a message on Youtube to fix the mod, and when I Googled it there were many comments (especially on Curse) that it was dead. Now that I opened the Spacedock page on my laptop I see under information that it was updated just last month. My bad.

I got into contact with the people updating the airship mod. Here's the link to the real page. My original post follows... Hello, I think I fixed my account. I'm Hooligan Labs who made the Airship mod and others long ago. I'll have some time over the holidays and I heard that the Airship mod was broken. Is Jewel still here? Is there an interest in having me fix the Airship mod? I would probably throw in some features and updates as well.