Jump to content

Hooligan Labs

Members
  • Posts

    481
  • Joined

  • Last visited

Posts posted by Hooligan Labs

  1. 18 minutes ago, Invaderchaos said:

    This mod is exactly what I was looking for! Now I can make the floating Eve base of my dreams!!

    I made this awesome airship with hooligan labs and airpark. I was surprised how smooth EVA’s and switching between ships were, especially with Eve’s gravity! 

    Beautiful photos! I love it! :D

    Quote

    Now all that’s left is for me to find a mod that can let me make underwater bases on Laythe...

    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.

  2. 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.

  3. 2 hours ago, VR_Dev said:

    Next big project is to set the steering PID to adjust stride length to keep it walking in a straight line.

    Looking forward to this. :)

    Quote

    Oh boy I don't think I have a license specified yet. Whichever the free to use one is.

    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

    Quote

    @Hooligan Labs thanks a lot for taking the time to look into my code, and type up such an in depth response. The stuff on the PID was exceptionally helpful. 

    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.

    Quote

    Now I just use a unity cheat to move the target in an arc. I just set the parent of the target at 0, and the target at the back or front position. The I lerp the parents rotation (factoring in walk speed) to get a nice arc that naturally slows as its nearing its target.

    That's not a cheat, that's smart. Unity has very good and fool-proof rotation, which should be taken advantage of!

    Quote

    One other thought about the rotation target is to have the target be slightly above the ground. Then the arm does a full rotation really fast to get to that point, then gently set itself down.

    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. :) 

    Quote

    Pretty embarrassed I pushed those values up. I usually start with .1f,0,0 and move around from there. The high D was just and experiment to see if that would slow the arm enough to keep the foot from exploding.

    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.

    Quote

    So the wrist servo measures all the vertices in all the meshes attached to it, and uses the furthest Y distance to set the contact point.

    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. :) 

  4. 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:

    Spoiler

    In the LimbController (which I think runs on your Unity instance, not KSP) I see "CustomUpdate" where you are calculating ground clearance - looks like you are reading a value directly calculated from within KSP. This is also where you are checking for GroundContact. I could see the ground clearance value being weird. It may be measuring from somewhere inside the part (not the bottom) and it may be measuring to the terrain collider (Kerbin dirt) and not the platform that you are standing on (some collider in the object). However, watching your video, it seems the value is working as intended.

     

  5. 17 hours ago, ZodiusInfuser said:

    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 

    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.

  6. Quote

    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. 

    @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?

     

  7. Unfortunately, I'm not able to find your repo. Where is the link? :D

    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.

  8. 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.

  9. 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. :P 

  10. 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.

  11. 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. :D

  12. 26 minutes ago, colmo said:

    I always did want a floating base in the atmosphere of Eve. @Angel-125's Heisenberg might just do the trick - maybe lash a few of those together...

    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?

  13. 6 minutes ago, SpannerMonkey(smce) said:

    the answer is size 7 nodes for the main hull connections, that'll fix that little issue, if it works for 500 tonne ship hull parts it'll work here too

    That's cool! Node sizes affect break torque? I made this back in beta, before we even had electricity in the game.

    12 minutes ago, SpannerMonkey(smce) said:

    Thanks, i appreciate that coming from the godfather of Kerbal Airships

    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.

  14. 6 minutes ago, JewelShisen said:

    Working on taking down the curse page now.

    As for the cheating thing I think that has to do largely with the fact that the mod doesn't use up any resources at the moment.

    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?

    4 minutes ago, Angel-125 said:

    @Hooligan Labs Nice to see you saying hi!. :) Thanks to you and @JewelShisen, we get to fly airships around. Definitely loads of fun. :)

    :cool:

  15. 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? :)
  16. 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.

  17. 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.

×
×
  • Create New...