VR_Dev

Haven't checked in a while but finally broke 1k downloads. Happy new year

Still love my f-22, haven't flown it in awhile. It was suffering from a bad aerodynamic graphics glitch last time I tried it. Has that been fixed? I moved on to programing real life quadcopters, but have some ideas to revisit my drone race. https://youtu.be/CmPSX6I0s6U

Hexapod, I can upload the other 2 later. https://kerbalx.com/clown_baby/Hexapod-V8 Trying to get this plugin to work in 1.8.1. The update to Unity 2019 should mean I can implement the job system and remove any remaining lag in this plugin.

MRK VII Armed just passed 1k downloads and the MRK VIII isn't far behind. Thanks to everyone who's tried it.

This is a problem I have been experiencing for a while, however I'm moving them via code. I was just trying to get my plugin working again in 1.81 but if this problem still exists there's no point. Speaking of getting my plugin working in 1.81 with 3.0.2, Im here to ask about what I'm always here to ask about. Still using the IR Wrapper from sequencer. Now the initialization fails with ""[IR Wrapper] Failed to grab ControlGroup Type". When I change "InfernalRobotics_v3.Command.ControlGroup" to "InfernalRobotics_v3.Interfaces.IServoGroup", initialization works, but I get the error "IRWrapper,Error extracting from actualServos: Object reference not set to an instance of an object". Thanks Edit : ok i see Command.ControlGroup was changed to Command.ServoGroup. Still getting "IRWrapper,Error extracting from actualServos: Object reference not set to an instance of an object" though.

Been back at this for a while, but progress has been pretty quick so I haven't posted many updates. Before I was setting the position of the target transitioning across the ground to the percentage that the arc target was at, this was the exact opposite of what i should have been doing. Now the arc position is set to the percentage or average percentage of the other feet on that sides percent completion to the back target. This allows me to actually set the speed I want. Now if you set walk speed to 3 m/s, the hexapod will actually travel 3 m/s. Once all 3 of the arcing feet are at the front position, the gait next step sequence begins. This allows for a relatively consistent speed, without the hexapod coming to a stop in between strides. Probably the biggest change is switching to a consistent arc with a height half the distance of the gait to a completely customizable gait. The hexapod can only move as fast as the arcing feet can reposition themselves to the forward position. A full arc was far too much distance for them to travel, so I have implemented animation graphs which allow you to set the arc path. By greatly decreasing the distance the arcing feet have to travel, the hexapod can now travel faster than it ever has before. This also helps keep the feet from exploding, because I can control when they should be set down, instead of traveling down fast from the peak of the arc. As you can see in the video however, I have yet to figure out steering with this feature. The hexapod can switch on the fly between the old full arc, and the animation graphs, so I figure when the hexapod detects an uneven surface, or obstacles, it can switch back to the high step method. Here is the arc gait in the video, this is also how stride length is set. Steering will have to manipulate these key points to shorten and lengthen the stride. This also allows for uneven stride offsets, but im not sure the advantage of that. Eventually each gait graph should be set independently, but now they are all sharing this one. I also added the ability to set the gait distance from the base servo via script. Before you had to set the servos how you wanted in the hanger, and the gait would be placed at the foot position. Now, as seen in the video, the hexapod starts with its legs as close to the body as possible, then moves them to the desired gate distance. This allows for faster tuning instead of having to go to the hanger and adjust the servos. I can now also set the height above the ground I want the leg bases to be add. This all allows for faster turning. The software in the video is currently up to date in the development branch of my repo. I have this working in KSP 1.6 with IR Next. I have reworked a lot of the base code to allow me to expand this to other mechs. Soon I plan on challenging myself to getting a bipedal mech to walk. The challenge I look forward to here is maintaining the center of balance throughout the gait.

Any chance to shamelessly show my hexipod... I've been back at it for a while but havent posted any updates. Have it working with Next in 1.6 Side note, @Rudolf Meier, I know a lot of the situations are different, but most of these fps issues sound identical to mine.

So you can no longer call MoveTo(pos,speed) every frame, no idea why but that's the problem. Now I do need a solution to continuously set the servo position. Gonna go back to the last working KSP/IR next combo.

Oh sure that makes sense. I usually have it set to 20 where I assume it's clamped? By the way MoveTo(float float) works, it just kills the frame rate

I have to think about all of this and type out my thoughts this weekend. In short my ideal situation would be to have full control of the raw speed. I use a PID to slow it down so I don't need internal controls to avoid overshooting.

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);

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.

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.

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

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) });

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

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.

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

Sorry for the delay but I'm currently on vacation. I'm just using the wrapper from the old IR plugin and it works just fine. Pull it out of my repo and you should be good to go.

Another update. I was having such a hard time with foot explosions I was ready to give up for a while, but I made one change which helped it drastically. I was lerping the rotation of the gait to try and slow the foot as it was approaching its target. Then on top of that I tried to manually control the speed for various points in the arc gait. I don't know if it was the combination of those two things or what, but when I switched the rotation to a constant speed I saw dramatic improvements. I do slow the target point rotation at the beginning and end of the stride. I was finding the foot exploded just as often when it was being picked up off the ground as when it was being placed upon it. Now I have a fixed constant speed when setting the foot down, or lifting it off the ground. The walk speed is only applied to the rotation between lift up and put down. Now the arc speed sets the whole gait. The translate target position is set based on the % completed of the arc stride. So if the rotation/arc stride is at 40%, the translate across the ground target will be at 40%. This happens for the three feet on left and right. If there is only one translate foot on a side and two rotating strides, the translate will use the average % of the two rotating strides. Since the rot stride now slows as it approaches the ground, the translate stride also slows as it approaches its target. To keep the craft moving, as soon as the rot target starts to slow, the translate target begins moving on its own at a designated speed. It also has the freedom to move past its target so hopefully the leg is still moving backwards as it is lifted off the ground. Steering is still in play, but this new gate works really well keeping it straight. Fixed ground clearance from foot. Having trouble with grass/runway in terms of tuning. Grass/terrain slows everything way down, but don't know how to distinguish between the two. Layer names prob. Did this real quick, ask if you really want any clarifications, may add more as i think about it.

Got my hexapod/robotics project back up in ksp 1.6 using this mod instead of stock infernal robotics. Everything seems to be working well, could use higher servo speeds though...

Hey, still working on this but having a lot of trouble with foot explosions. I now have KSP telling me when the foot explodes, so I can auto pause the unity controller and debug the values at the time of explosion. I have several new additions to the algorithm that seem promising, but I need to solve the foot explosions. I'm at the point I may just turn up the ground tolerance on the foot parts. Real life mechs wouldn't use delicate air intakes as their feet. Random assortment of thoughts and improvements I've made since my last post. Foot explosions are really slowing me down. I assume the velocity used for ground collision is taken straight from RigidBody.velocity? I have been monitoring this on the foot, and even at the slow speed I'm walking it reaches velocities of 20+. (Explodes on contact > 7) My new thought is to use the velocity error to set the pids (when heading towards the ground) , but not sure how that would work. Again, may just turn up foot crash tolerance, I want to see how fast i can make this thing move, but need strong feet. Also tried turning acceleration down with little to no improvement. I have changed the walking algorithm pretty dramatically. Used to wait for all 6 feet to be in position but now whenever the 3 arc-ing feet are in position at the front of the gate, the new cycle begins. The feet that are translating backwards across the ground have no target, they are lifted off the ground as soon as the other 3 feet are ready to begin translating, no matter where they are. This can cause problems if the translate speed is to slow, then it just takes these tiny steps. I need some kind of algorithm to set translate speed based on how far the other three legs have to arc. In the video above the translate speed is fast enough that the legs are hitting their targets and stopping, ideally they would still be moving when its time to start the next cycle. The gait targets are now asymmetrical. The front and back target used to be the same, half the stride length in each direction. but now the back point is further away from the center. The goal of this being the three feet that are translating should never stop(unless they are going to hit the let behind them), allowing for continuous motion. I now lerp the position of the gait up and down to take into account legbase height. This offered a huge improvement. Kind of abandoned servo PIDs, right now servo speed is just set to 20. I slow the IK target leg down when approaching the ground. Video above has steering working, but not really featured. My old videos adjust to stay in a straight line, but now I can change the target direction to get the hexapod to turn. Thanks I'll update the repo with the license. I never use global Y, just the vessel's Y. That many raycasts would slow KSP way down. MeshColliders proved a global point to the closest given point, so I ask the collider what is the closest point to the planet, and now that's what I use. I also base all the calculations off that changing point, which gives better results. You can see the contact point drawn in game. The engines were tucked away in the legs so the aero intake is still the only thing coming in contact with the ground. I removed a them and the top of the foot because i was having such a hard time with foot explosions. This is great, thanks for posting. Even more complex with more legs. I hadn't even considered translating directly left or right, that would be an interesting thing to try. I need to turn in place first. https://github.com/carter-james89/KSP-Unity-Editor-Plugin/tree/master/Ships (You may need to download the whole repo then just pull the craft file out) Unfortunately KOS isn't going to work out of the box, but you can use KOS to control servos. So this could be adapted if you really wanted.

Hey guys I really appreciate all the insight in this thread. This week has been super busy at work so I haven't had time to keep up with all the questions. Also haven't had much time to put into the hexapod, but I do have it looking more like its old self though. Just like the first time around tuning is equally as important as the walking algorithm itself. The major improvements came from shortening up the stride length, and not changing targets til the foot has ground contact (Calculated from raycast). Also adding some more weight. Next big project is to set the steering PID to adjust stride length to keep it walking in a straight line. Even if you don't understand any of the code there is also lots of design options that could be testing for advantages/disadvantages. You can alter the design of the craft(including the legs) pretty substantially and the code will still work. I'm also in the process of making it easier to tune. In this video I have also added engines back into the feet. My plan is for this to fly as well, so the weight needs to be taken into account. I definitely need to implement something with more control over the speed of the two strides. I go into this more below. Oh boy I don't think I have a license specified yet. Whichever the free to use one is. PID controllers are used to control the speed of each servo based on the error between the mirror (ksp servo) and IK servo. A PID is also used to adjust the stride length to keep it walking in a straight line(not implemented yet). I go into it further below. Yeah the IK is sound, now its time to dive into the gait improvements. Yeah I have a two step gait, with 3 legs translating backwards while the other three arc forward to the target position. @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. The code above actually adjusts the target IK point to get the base of the arm at the correct height. If the base is .5m below its target, the IK target gets placed .5m below the ground, so the arm will push itself up trying to get to the below ground target. You can see in some of my old videos how I can control the height and angle of the body by adjusting these base targets. You can see here I was only doing that when the foot was translating across the ground, but now it will adjust its height when it is at its target position as well. Part of the snapping problem is when the target snapped from 0m above the ground to -.5m below the ground. It would probably be better to lerp this as well. If you are referring to the box that is above the start position of the foot, that is left over from trying to use a target for the arc rotation. 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. The built in slow down of lerp doesn't seem to slow the foot enough however. I think the next step is to control the speed of the arc manually so that i can adjust when and by how much it slows as it gets closer to its target. This gets into what @ZodiusInfuser was saying about the time step. Right now I just try to manually adjust the speed of the rotation and translate so that the two groups of feet hit their target at the same time, but it would be much better to calculate the distance of both the straight line and arc, and set the speed accordingly, taking into account the slow down required on the rotation. 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. 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 still don't have a super clear understanding of PID tuning (your explanation def helps) but I don't think I'm half bad. My f-22 racers use a bunch of them. So the PID loops are only controlling the speed of the servos, there is no PID that affects the gait (except for steering which shortens the gait as needed for turning. That isn't working in this version yet). Each servo has a PID which sets the speed according to the error between the mirror servo (KSP) and the IK leg servo. Mirror and IK arms are identical in the unity editor, the one lagging behind is always the mirror. I could just set the servo speed at max, but its nice to have the damping so it doesn't overshoot at the peak of the arc. The servos PID values should be different for the rotate and translate stride however. As I mentioned above, the gait probably has the most room for improvement, and I have a couple of different things to try. I'll definitely try out some of your suggestions. This is a problem I need to fix in the new System. If you watch the old videos, I used a sensor part to tell the system "this is the foot", and I shot a raycast straight down from that position to calculate ground clearance. The raycast ignored Parts and only looked for the layer that KSP considers the ground. In the new system I wanted the arm to calculate its endpoint automatically. 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. This worked really well, except for sometimes that point clips below the ground mesh and the value is wrong. Now I use the same raycast, but from the servo transform. Then I set the ground(white plane) that distance below the identical servo in Unity. I calculate the clearance by subtracting the clearance from the servo to the foot position from the servo to the ground position. This works ok but is definitely worse, especially on a gradient. This def needs to be improved. This is the api call that used to work as well. Not having any luck with it now though. bool GroundContact Whether this part is currently in contact with the solid surface of a CelestialBody.

https://github.com/carter-james89/KSP-Unity-Editor-Plugin alpha 6 - activates IK alpha 7 - begin walking Must be focused on Unity game window