-
Posts
1,039 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by VR_Dev
-
@ZodiusInfuser hey thanks for all the cool examples. The bridge works pretty well now so I actually came back to this project hoping to focus solely on making the hexapod as advanced as possible. Part of that being it's gait. Looking back on the old videos I'm actually amazed how fast I got this thing moving. I have rebuilt the gait system to be more reliable as well as built in a simple gait sequencer. You can now add target positions to a gait list and have the hexapod execute them. If the new position is in front of the current(relative to the vessel) the foot will arc to the new position. If the new position is behind the current, it will translate across the ground. Pretty much exactly like the example you posted above. groupLeft.limb0.AddGaitTarget(groupLeft.limb0.limbIK.pointBack); groupLeft.limb0.AddGaitTarget(groupLeft.limb0.limbIK.pointFront); groupLeft.limb0.RunGait(); The problem I am currently experiencing is having the foot explode on ground contact. I solved this in Gen 1 by using a PID controller to control the speed for each individual servo. By setting a high D value the servos would slow as they got to their target. A main difference between the old and new gait is that I now use lerp to move the target position, so the target position itself slows as it gets to its destination. I thought this would be even better than the old gait where the target moved with a constant speed, but that doesn't seem to be the case. The problem here is the leg will switch from an arc to translate when the actual foot position gets within .1m of the target position. When that happens the foot is still above the ground, so it comes in slowly, the target changes, and it then slams into the ground. In translate mode I also adjust the gait y position to get the hip/base of the arm to the proper height. So as soon as the mode switches, the new target may be under the ground, which doesn't help with the exploding feet. I tried getting servo.HostPart.GroundPosition to know when the foot is actually on the ground, but it only returns false (I may be doing this wrong still, because I've gotten it to work before.) I am now keeping the repo up to date so anyone can take a crack at adjusting my code or implementing your own. The repo has the code for the KSP plugin, the Unity project, the hexapod ship, and the GameData folder. You should only need IR next to make it work. Basically there is a RoboticController class. This has two groups of LegControllers. A LegController class contains both references to the RoboticLimbIK and RoboticLimbMirror classes, which control the Ik and KSP mirror leg. If you really want to take a crack at it let me know and i can explain in more detail. This is a project I do in what freetime I have, so the code could be cleaned up and streamlined(also some comments might help). Right now everything is basically in prototype form.
-
I appreciate the help but I actually got it to work by using the IRWrapper from the IR sequencer instead of from kOS. (Which may even be identical to the old one, not sure). When I left this project I was in the process of trying to rig any IR arm with IK, which I think is still possible, but pretty ambitious. First off I'm just going to get the hexapod up and running, then go from there. There is a jerky-ness to the servos that wasn't there before, not sure if its an IR Next issue or something in my IK code.
-
So I'm trying to get this project up and running again in 1.6. Unfortunately IR doesn't work in 1.6, so I have committed to switching to IR next. It looks like I can use the IR Wrapper in the same way (because kOS does), but it is failing with the error. [LOG 19:40:32.595] 1/12/2019 7:40:32 PM,MemoryBridgeServer-IR3Wrapper,[IR3 Wrapper] Failed to grab Mechanism Type If anyone has gotten the wrapper to work with IR next in 1.6 please let me know. I'm still working on getting the plugin to work without IR so it could still be useful without robotics. @Stone Blue & @Hooligan Labs were curious about the workflow. Essentially you can use : MemoryBridge.GetVector3(); MemoryBridge.SetVector3(); Get/SetFloat, Get/SetBool to get and set any variable I have included in the API (Most of vessel and some other classes). If you want to send custom values, you need to compile a plugin that provides the variable you are looking for. //Server side in a custom dll Update() { //Set a value to be read by Unity Client MemoryBridge.SetVector3("Custom String Name", Vessel.GetObtVelocity()); //Get a value from Unity Client and apply it in game Vessel.FlightCTRLState.Roll = MemoryBridge.GetFloat("Custom Throttle String"); } //Client side (Unity) Update(){ //Get the orbital velocity from KSP var orbitVel = MemoryBridge.GetVector3("Custom String Name"); //Set throttle based on some custom code like a PID //You can test code here quickly without having to reload KSP each time MemoryBridge.SetFloat("Custom Throttle String", calculatedThrottle); } Edit : and for anyone curious about my earlier post. I have my quadcopter autopilot at a pretty good place, which is why I'm returning to this project. Still needs a lot of PID tuning so if someone is good at that and has 70 bucks to buy a DJI Tello let me know.
-
Tried this but it is failing with : [LOG 19:40:32.595] 1/12/2019 7:40:32 PM,MemoryBridgeServer-IR3Wrapper,[IR3 Wrapper] Failed to grab Mechanism Type Any help would be appreciated.
-
I'm trying to replicate my f-22 racers irl. First step is tracking. https://tellopilots.com/threads/unity-controller-for-tello-3d-tracking-tello-simulator-flight-stick-support.2288/
-
hey @Stone Blue and @Hooligan Labs, I am still working on this, but it has been sidelined for my new project. I'll respond to all your questions later today. With the end goal being automated flying, something like this.
-
I can now auto rig any design with a skeleton based on this simple naming structure. The servos group themselves based on angle axis, regardless of the random way they are positioned by the user. If anyone wants to see their creations loaded up you can organize/name the limbs, and send them my way. Next is figuring out auto -generated IK, then I'd be happy to help incorporate it into the mod if you're interested Rudolf.
-
I can now auto generate a skeleton on any IK structure based on this simple naming convention. The limb has to be its own group, which includes "ik" somewhere in the title. The base (1st) joint needs to include "base", and the last joint needs to include "wrist". Anything you want to skip, and any extentrons need to include "skip". Feel free to rig up your mechs and send them my way for testing. These skeletons are auto generated, and the servos grouped by their pivot axis. The sections with the same color will move the leg along the same axis. I have also taken rotation into account, so servos that are 180 of their group will be adjusted.This is all the groundwork needed to attempt autogenerating the IK.
-
Couple videos testing my new KSP Unity editor plugin. Second video is incorporating the autopilot from the video above.
-
Imagine if you could tweak those values from the unity editor...
-
totm june 2018 Work-in-Progress [WIP] Design Thread
VR_Dev replied to GusTurbo's topic in KSP1 The Spacecraft Exchange
This thread has me reminiscent of my old f-16 https://gfycat.com/DefinitiveFittingHamadryad Follow up to my hexapod. Wanted to make something walk on all fours, with the option for upright locomotion. Finally happy with the design, so its time to make it walk and fly. -
Hey man, glad to see all is going well with the Mod. I've been super busy with the groundwork for my mech project, but am finally getting back into construction. I downloaded the latest beta and am going to build my new mech with your parts. My biggest request for IR right now is for joints that have a range larger than 180 degrees. Right now there is only one part that can do this, and it's not very compact. I'm also curious if you've done any research into multiaxis joints, or was that a dead end? I'm gonna take a look at the source code over the long weekend so I have a better understanding of if this is possible or not. Are there any plans for new models?
-
Still hard at work at this. Didn't have much to show on the bridge rework but I've finally optimized it to be as fast as possible, and have begun adding features into the platform. First off is the autopilot from my f-22 drone race. (https://www.youtube.com/watch?v=HEbhV4tjA8E&t=27s). You can input raw steering data or have it match a target. My joystick has never worked in KSP but now I am able to use it through unity. This video is raw control, but soon you will be able to position the second target vessel, and have the real one match its rotation. GenerateCamera() will automatically place a camera in the ksp scene and a render texture in the unity scene. You can also move the camera in unity and it will move in ksp. Render textures can now be sent at 60fps as well. Still need to remove the UI layers from the created camera however. This will be necessary to control the bots in VR, and still see whats happening in the game. As shown in the examples above I can also send the meshes over the bridge to unity. This will be helpful for a visual reference on top of the line skeletons. I have to figure out a way to get the manipulated IR components to look correct however. My next big project is writing a component that will automatically map any IR arm, and automatically calculate it's IK. This will most likely not be easy, but I believe it is doable, and would be the most useful feature to other people. I plan on rebuilding the hexapod with this system, but am also trying to build this. I want a mech that can walk, as well as have VTOL short to medium range capabilities. Also seems like a good stepping stone towards an upright, bidepal mech.
-
Trying to build this. Got an ok start. If any mech builders wanna take a crack at it I'll credit you in all the walking videos. Def want the engines included. https://www.dropbox.com/s/prmmdwlvy8wsp7y/GorillaMech 4.craft?dl=0
-
Damn dude that thing is slick. Really solid IR skeleton which will work well fully rigged. Also like some of the clipping joints you created. As I'll explain below I've taken a step back form the robotics to rework the bridge, but when I get back at it I'll give yours a test. Yeah dude I hear ya. Everything in this thread right now has the robotics and memory files intertwined. It is also using my old custom process hack. Now that I can get memory files to work in ksp, I am building the whole thing from scratch as two separate projects. The independent memory mapped bridge, and the robotics on top of that. What I am in the process of building are two dlls, one server and one client, that will allow anyone to use this system. I am working hard to make it as easy as possible for people to use by requiring no up front initialization. If I recall correctly in kRPC, you have to declare the variables you want to use at start, which was kind of annoying. Using my method all you have to do is call ReadValue(string Key), and WriteValue(string key, float/vector3 value), and you will be able to access the value from the editor, or a stand alone application. I also plan to build the camera stream feature into the bridge. So it's a giant step back but a huge step forward. Once I get the Memory Mapped plugin working, I will return to the robotics. As for the other questions, it just needs the standard unity editor now, but like I said, it will be supported in stand alone applications just like kRPC, no download now but soon, it the new system will be open and documented, and it should be 1.4 compatible there is nothing limiting it to a certain a ksp version. On a completely separate note looks like someone beat me to native KSP VR. https://www.reddit.com/r/KerbalSpaceProgram/comments/87m019/you_cant_check_the_staging_with_vr/
-
If you take two legs off the hexapod the script automatically switches to quadrapod mode. The leg shape will still be a little dif then an ATAT though. That probably needs a code rework. Tons of people have made walking ATATs though. Check out youtube
-
Wanted to start a thread to host the craft for my project, and try to keep craft design and mod dev separate. I know nothing about hexapods so the design has lots of room for improvement. Also need a rocket to carry it to other worlds. If your curious about the technique behind the bridge, the thread is here. If you want to try the walking program, know a little about Unity, and have a decent PC, hit me up. Hexapod https://kerbalx.com/VR_Dev/VR_Dev-Hexapod [BDA][Surface Lights] [TweakScale] [IR Rework] Bidedal [Soon]
-
I don't really have time to write out all the details right now but I got memory files to work between .net 3.4 and 4. While I thought my process trick was pretty clever, this is insanely faster. Here is a render texture captured in ksp, displayed in the unity editor at 20-30 fps. If I limit the texture display frame rate the ksp frame rate improves, but the Unity render texture frame rate drops, which is fine for now. Essentially I have to rebuild the whole system based around the new memory bridge. But I'm going to try and make it a releasable platform for people to use. This was the main problem in my project. Now that I have this figured out I'm gonna build some crazy stuff.
-
Holy sht I just saw the 1.4 changelog. It claims Unity was updated to 2017. That means I should be able to use memory mapped files in ksp without my third party process. Also makes in game VR much more attainable. If they updated the .net version this could be huge. Edit: Got super excited about this but turns out I was wrong. I knew that would be a huge change but figured all the old mods would still compile in a newer .net version Edit again: Confused cause this code tells me ksp is targeting 4.0, but mmap files don't work still. RegistryKey installed_versions = Registry.LocalMachine.OpenSubKey(@"SOFTWARE\Microsoft\NET Framework Setup\NDP"); string[] version_names = installed_versions.GetSubKeyNames(); //version names start with 'v', eg, 'v3.5' which needs to be trimmed off before conversion double Framework = Convert.ToDouble(version_names[version_names.Length - 1].Remove(0, 1), CultureInfo.InvariantCulture); int SP = Convert.ToInt32(installed_versions.OpenSubKey(version_names[version_names.Length - 1]).GetValue("SP", 0));
-
Awesome. Glad to see you getting back at it. I can help with any IK you want to incorporate.
-
Thanks for the hot tip. Haven't even started on the real thing yet so I'll have to hold onto that. The terrain adaptation is actually super easy, gait generation is the tough part for me, so I'd be down to trade secrets. I sent you a pm about the project files. Thanks dude, the friction is surprisingly ok, but I've def had that problem in the past. I've played with adding wheel modules to parts to try and increase their friction but I've never been really able to make it work. I haven't been working on this project lately because I am in the process of moving to a new apartment. What free time I can manage has been going to this guy lately.
-
totm june 2018 Work-in-Progress [WIP] Design Thread
VR_Dev replied to GusTurbo's topic in KSP1 The Spacecraft Exchange
-
So I can rig blender models, then deform them via script in Unity. But the spring would be quite a difficult challenge I think to compress it without altering the diameter of the spring. Something like this could be the solution. Also I don't need IR to control any animations, just the bone transforms themselves. Edit : Found a tutorial for spring rigging, if we wanna go that way.
-
My vote is new models. Like you said it will be a much better visual representation of what the parts do. And with big spring shocks we could start making some mad max stuff up in here.
-
Did some simple tests with ModuleWheelSuspension. Duplicated a wheel and took out everything but that module. Also gave it two attachment nodes. Hard to tell if it's working though. Maybe it isn't designed to use with nodes, or I don't fully understand the module settings. Seems like the model just needs a suspensionTransformName in the mesh. This is the documentation. Seems like they already have the re-load situation figured out. https://kerbalspaceprogram.com/api/class_module_wheels_1_1_module_wheel_suspension.html#ac0274b5c097adaa599a366a0240fb8e8