Hooligan Labs

Members
  • Content Count

    478
  • Joined

  • Last visited

Community Reputation

70 Excellent

About Hooligan Labs

  • Rank
    Cosmic Captain

Contact Methods

  • Website URL http://www.hooliganlabs.com

Profile Information

  • Location Michigan
  • Interests Making stuff in Unity... Also autonomous cars.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hooligan Labs

    [WIP] Unity Editor Plugin

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

    [WIP] Unity Editor Plugin

    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:
  3. Hooligan Labs

    [WIP] Unity Editor Plugin

    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.
  4. Hooligan Labs

    [WIP] Unity Editor Plugin

    @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?
  5. Hooligan Labs

    [WIP] Unity Editor Plugin

    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.
  6. Hooligan Labs

    [WIP] Unity Editor Plugin

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

    [WIP] Unity Editor Plugin

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

    [WIP] Infernal Robotics - Next

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

    [WIP] Unity Editor Plugin

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

    [WIP] Unity Editor Plugin

    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.
  11. Hooligan Labs

    [WIP] Unity Editor Plugin

    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.
  12. Hooligan Labs

    [Airships in 1.3] HooliganLabs Mods

    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.
  13. Hooligan Labs

    [Airships in 1.3] HooliganLabs Mods

    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.
  14. Hooligan Labs

    [Airships in 1.3] HooliganLabs Mods

    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?
  15. Hooligan Labs

    [0.24] - Magic Smoke Industries DevHelper v0.6

    Hooray! I'll try it