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