[WIP][1.7.1][BG] SlaveDriver v0.1: Robotic limbs made simple.

[Snark]

What it does

• Adds the ability to "slave" one robotic servo to another.  When you change the master's target angle, it automatically adjusts the slave's angle accordingly.
• Automatically takes care of updating the slave's traverse speed and damping, too.
• Locking the master will lock all its slaves, too. Lock an entire limb with one click!
• Can slave as many servos as desired to one master.
• Can toggle a hinge's "slaved" status on/off, either in the editor or in flight scene.
• Super simple UI makes it a breeze to set up complicated robotic limb motions that are controlled from a single hinge.  Easy to toggle hinges in and out of slave mode as needed.
• Simplifies working with the KAL-1000, too!  Now you only need one track per master; the slaves take care of themselves.

A picture's worth a thousand words:

Download from github
License: CC-BY-NC-ND 4.0
Source code

[NOTE:  Requires Breaking Ground expansion.  It won't actually hurt anything if you install without Breaking Ground being installed... but it won't do anything for you, either.]

 

Development status

SlaveDriver is currently in pre-release status.  It's functional and (I believe) reasonably "safe", both to run and to uninstall after use.  It's fully playable, you can grab it now if you like. 

However, it still has some rough edges, known issues (see discussion below), and not-yet-implemented features, which is why I'm calling it WIP.  Use at your own risk.

 

How to install

Unzip the contents of "GameData" to your GameData folder, same as with most mods. (Note, includes ModuleManager.)

 

Why would anyone want this?

The Breaking Ground expansion introduces a variety of robotic parts.  These are great fun to play with, but I've found it tedious to set up multi-jointed robotic limbs, because every single joint has to be set up independently.  This means a few things:

• It's very awkward and tedious to build and design a multi-jointed limb in the vehicle editor.
• Trying to get multiple joints coordinated properly requires doing a bunch of tedious math to correctly coordinate all the various traverse speeds, damping values, etc. with the angle ranges, and any time you touch any one of these, you have to do the math all over again.
• If you want to use the KAL-1000 to control a complex sequence, every single joint needs a separate control track, and keeping those synchronized is a nightmare-- not just to set up in the first place, but to maintain when you need to tweak things.  Which you will.  A lot.  Because robotics requires a lot of tweaking.

SlaveDriver does one very simple thing that I find highly useful, by allowing me to reduce the number of "degrees of freedom" of a collection of joints, thus greatly simplifying the build-and-control process.

 

How do I use it?

The UI is as simple as can be:

• When you place a hinge on your craft, SlaveDriver automatically analyzes its "parent part" hierarchy, from the hinge up to the vessel's root part.  This is fully automatic, no action needed on your part.
• If it doesn't find any hinges along that path... it means that there isn't any potential "master" to use, so it decides it can't do anything and leaves the stock UI alone.  (Note the right-click window at right, in the above image.  That hinge is mounted to the root part, can't be a slave because there's no viable candidate for a master, so its UI looks standard.)
• If it does find anything, then it adds a "Slave to <part name>" button at the bottom, like this:

By default, it doesn't change the behavior-- everything is "un-slaved" and behaves as normal by default.  But if you want to put it into "slave mode", just click that button.

When you do that, the UI for the part changes.  Note the right-click menu for the "elbow" hinge in the above illustration, at top left.  Several controls are now missing:  you can't set the target angle, the traverse rate, the damping, or lock/unlock it.  That's because as long as it's a slave, all of those are controlled automatically by its master.  You can still see what the values are, though:  it adds some display fields to show their values.

The above example shows a robotic limb with six hinges in it:  one at the "shoulder", two at the "elbow", and three fingers hinged at the "wrist".  All of the lower five are slaved to the shoulder.

 

Planned features and known issues

This is still a work in progress.  Here's the current status:

Planned features

• The mod currently enables slave mode for all of Breaking Ground's hinges (two square hinges, three alligator hinges).
• It does not currently support rotational servos, though I plan to add that feature in an upcoming release.
• It does not support rotors, nor do I plan to (the feature doesn't really make sense for them).
• Pistons are not supported either.  Uncertain whether I'll do those or not-- there are some interesting design issues to work out.
• I'll likely add an "invert" button to go with the slave button, i.e. slave is at min angle when master is at max, and vice versa.  For now you can accomplish the same effect on a square hinge by just rotating the hinge 180 degrees about its axis, but that won't work for the alligators.

Known issues

• The most important problem is a doozy:  If you wiggle the hinges around a lot in the editor, then parts start to "drift" away from the hinges that they're attached to.
  • This bug can be worked around if you're careful, but it's annoying as hell; this one bug is the thing that's stopping me from calling this a "release".
  • If you see something that looks like this, that's what you're running up against.
  • I believe this is a bug in KSP itself, not my mod.  Sounds like it may be the same issue mentioned here.
  • If I'm right that it's a KSP bug, then hopefully they'll fix this soon. 
  • Doesn't affect vessels in the flight scene; appears to be purely an issue with the editor.
• If you have a slave's UI window open when you toggle the "locked" status on the master, the the slave's UI window gets messed up.  This is only cosmetic; if you close and re-open the slave's UI, the problem fixes itself.
• The display of the "locked" status on the slave's UI says "true" or "false" rather than "yes" and "no".

Bug reports (other than the above-mentioned issues) and feature suggestions welcome!  Hope folks have fun with this. 

[4x4cheesecake]

Nice, this is going to be good

Less fiddling around with the controls and more time for actually doing stuff^^

[Jesusthebird]

Omg ive been furiously trying to play with these parts since its release...its sooo freaking complicated!!! I revel in the glory of rome!!...ahem..i meen this mod!

One thing that I wonder...could the new UI/kal1000 sequencer adopt IR parts. I think it would be super dope to see IR parts works with the kal1000 sequencer.

A question for the IR thread for sure..maybe ill pop in and say hi over there

[Mikki]

I submit to our new robotic overlords.  

[ZodiusInfuser]

18 minutes ago, Jesusthebird said:

One thing that I wonder...could the new UI/kal1000 sequencer adopt IR parts. I think it would be super dope to see IR parts works with the kal1000 sequencer.

We have a version we're testing for this now, basically adds a Target Position slider to all IR parts. I wonder if SlaveDriver could work for them too?

[Beetlecat]

Again, even before I could see the author (I get forum posts via a news aggregator) -- I knew this had to be from you, @Snark!

Clever, stellar, simple (in concept), and useful!

[Superfluous J]

Awesome. Can't wait to playtest this. And by playtest I mean play with

[Snark]

5 hours ago, ZodiusInfuser said:

I wonder if SlaveDriver could work for them too?

Almost certainly not.  SlaveDriver is joined at the hip to the Breaking Ground robotic classes (e.g. BaseServo, ModuleRoboticServoHinge, etc.)  So unless IR is implemented in terms of those (which I'm guessing it almost certainly isn't), it simply won't work.

5 hours ago, Jesusthebird said:

One thing that I wonder...could the new UI/kal1000 sequencer adopt IR parts. I think it would be super dope to see IR parts works with the kal1000 sequencer.

A question for the IR thread for sure..maybe ill pop in and say hi over there

The KAL-1000 will work with any part that implements axis groups, and axis groups are super easy to support in a mod.  So I imagine it would be very easy for the IR folks to support that.

However... just a gentle reminder that anything about IR is completely off topic in this thread, because this thread is about this mod and not about robotics in general.  And this mod almost certainly won't work, at all, with IR. 

 

[Klapaucius]

This is a great idea.

Is there a way (or will there be) a way to offset the motion the timing of the motion from parent to slave so that you can have a repeated motion in sequence, such as when you have legs on a walker?

 

I think this solution of yours should be an update to the stock DLC.  The controller is really good, but it could use some workflow improvements--things that are standard to keyframe editors (which the controller is almost certainly based on) in programs like Adobe Premiere.  I started a thread on that here.

 

[Snark]

9 hours ago, Klapaucius said:

Is there a way (or will there be) a way to offset the motion the timing of the motion from parent to slave so that you can have a repeated motion in sequence, such as when you have legs on a walker?
 

No, that's pretty solidly in the "not gonna happen" category.

Time sequence editing is complicated, and that's not something I'm prepared to take on.

Besides, as far as I'm concerned, that's exactly what the KAL-1000 is for. No point in reinventing that particular wheel. And in fact, I view SlaveDriver as being complementary to the KAL-1000. With SlaveDriver in place, setting up a walk cycle (or whatever) will hopefully become simpler by eliminating the need for redundant "clone" tracks.

Even with SlaveDriver along for the ride, I'll confess that I find the KAL-1000 tedious to work with for compound motions, but as far as I'm concerned, the right solution to that problem is to give the track editor a reasonable suite of track-at-a-time editing tools (e.g. invert, reverse, scale, phase shift, etc.) But adding anything like that would be Squad's job, not mine.

[FleshJeb]

Is this perhaps a step on the road to adding forward or inverse kinematics functions? One of the significant challenges is high degrees of freedom.

Last week I started working on a KRPC program to control robotics parts, and calculate the range of motion of each. The final goal being to automatically drive an arm-mounted docking port onto another. It’s probably beyond me, but it’s a fun exercise.

It looks like Squad already has code for this, because all the video I’ve seen of the scanning arms looks like it’s driving the head of the arms from an arbitrary location to a point at some offset to the center of the ground objects.

[Snark]

8 hours ago, FleshJeb said:

Is this perhaps a step on the road to adding forward or inverse kinematics functions? One of the significant challenges is high degrees of freedom.

IK would certainly be super cool... but it would be a great big enormous gnarly hairy piece of work, to the point that I'm not even slightly tempted to take it on.

Not only is solving the IK problem for a generalized robotic limb a knotty problem in itself, but allowing the user to set it up how they want would require substantial UI design as well.

Seriously never gonna happen, at least not from me.

8 hours ago, FleshJeb said:

It looks like Squad already has code for this, because all the video I’ve seen of the scanning arms looks like it’s driving the head of the arms from an arbitrary location to a point at some offset to the center of the ground objects.

Perhaps, but bear in mind that they have several constraints there that enormously simplify the problem, compared with a general solution for arbitrary limbs. They have a simple arm of fixed physical design, used for solving a specific gameplay scenario.

[RealKerbal3x]

How the heck did I miss this? My deployable robotic claw doesn't need to have unmotorised hinges swinging about anymore!

@Snark You are a utility mod-making machine! Thanks again for your work.

[FleshJeb]

2 hours ago, Snark said:

IK would certainly be super cool... but it would be a great big enormous gnarly hairy piece of work, to the point that I'm not even slightly tempted to take it on.

Not only is solving the IK problem for a generalized robotic limb a knotty problem in itself, but allowing the user to set it up how they want would require substantial UI design as well.

I got the impression that IK boils down to a lot of matrix algebra. Not my strong suit.

However, IK is for optimizing movement or energy usage. I just want it to get there somehow. I think that’s an easier, iterative problem. Start with the least significant joint, get the end as close as possible, repeat for the next joints. Keep iterating. Possibly amenable to some PID control.

I realize the Squad solution is an extremely limited case, but I’m proposing a more brute force “moar boosters” solution. Minimizing the vector or rotation difference at each step is fairly easy (I need to brush up on the math), and if it gets stuck (errors not decreasing), run the joints in reverse. The bonus is that I think it would be much less computationally expensive to catch a moving target (drifting spaceship).

Player input would be limited to controlling from a docking port, selecting a target docking port, and hitting a “go” button.

Sorry for krapping up the thread. If you’d like to discuss further, feel free to PM.

[Snark]

4 hours ago, FleshJeb said:

I got the impression that IK boils down to a lot of matrix algebra. Not my strong suit.

The math ain't the problem.  Math, I can do.

4 hours ago, FleshJeb said:

However, IK is for optimizing movement or energy usage. I just want it to get there somehow.

No, IK at its simplest really is just about "just get it there somehow", and that's hard, that's what I am attempting to convey to you.

4 hours ago, FleshJeb said:

Start with the least significant joint, get the end as close as possible, repeat for the next joints. Keep iterating. Possibly amenable to some PID control.

I realize the Squad solution is an extremely limited case, but I’m proposing a more brute force “moar boosters” solution. Minimizing the vector or rotation difference at each step is fairly easy (I need to brush up on the math), and if it gets stuck (errors not decreasing), run the joints in reverse. The bonus is that I think it would be much less computationally expensive to catch a moving target (drifting spaceship).

Player input would be limited to controlling from a docking port, selecting a target docking port, and hitting a “go” button. 

Dude.  Look.  I'm a valedictorian physics major and am very comfortable with complex math.  I know how this stuff works.  That's not the problem.  If it were simply a bit of tricky math, or even merely kinda tedious, I wouldn't have spoken in such absolute not-gonna-happen terms.

Getting something to work via programming is not the same thing as simply understanding the principles "on paper".  It just isn't.

Lengthy spittle-flecked rant in spoiler, mainly because having spent the last few decades of my adult life as a professional software developer, hearing anyone who isn't a professional developer make an innocent, well-meaning comment along the lines of "well, here's <idea>, that should be simple to code" happens to trigger me hard. 

Spoiler

Do you have any idea how many hours of work it took me just to get this simple mod working?  We're talking hour after hour after damn hour of endless iterations of "damn, now that doesn't work, okay, twiddle this logic over here, now try the whole shebang over again". 

This whole mod's basic concept so far is a single line of basic algebra.  Paraphrased,

slaveAngle = slaveMin + (slaveMax - slaveMin) * (masterAngle - masterMin) / (masterMax - masterMin);

...simple, huh?  Took me dozens of hours to get it all working.  And that's for doing something dead simple.  (And to be clear:  that's not because I'm a fumblethumbs at programming, 'coz I'm not.  And it wasn't a surprise, either-- I've been coding for decades, and modding KSP for four years, and I had a pretty realistic idea going into it how much time this was likely to take.)

When programming, the devil's in the details.

4 hours ago, FleshJeb said:

Possibly amenable to some PID control.

Really?

As simple as that?

Do you remember all the years of the stock KSP game where telling SAS to hold (or any other orientation) was vulnerable to irritating overshoots, oscillations, etc. because they didn't have great PID tuning?  It was a serious game annoyance that was really intrusive to the player experience all the time and it took a team of dedicated, paid, full-time programmers many KSP iterations before they got around to fixing that.  Because automatic PID tuning for arbitrary dynamic complex systems is really goddamn hard.

Yes, I could probably do it to some degree; I certainly have the right skills and background.  I'm really good at math, I'm a dab hand at physics, and I've been a professional software engineer for a quarter century.  But solving that problem and doing it well enough for me to be willing to ship it (including massive amounts of debugging) would involve huge time commitments, we're talking many times what I've put into this mod so far, and this is a part-time hobby for me and I have a day job.

And the PID-tuning problem is just one aspect of the overall programming problem to produce a mod like you've suggested.

A robotics IK mod with good PID tuning would be hundreds of hours of my time, at least.  Am simply not going to go there, ever.  I don't have that kind of time. Do not want.

 But it all boils down to "it's harder than you think.  Really."

And to be clear, I'm not yelling at you, @FleshJeb.  Your idea is a good one, I'm glad you suggested it, I like to encourage suggestions, and it's not your fault that it's not obvious to the casual observer that this would be way, way, way more work for me than is apparent to the untrained eye.  It's also not your fault that I don't happen to have hundreds of hours to spare on such a problem.

Just... when I said "no" rather than "maybe", I really honestly meant "no".  Not. Gonna. Happen. 

(And hey, I could be wrong.  It has been known to happen.  Maybe I'm really, really wrong and it's only several dozen hours of work instead of the several hundred that I'm pretty sure would be needed.  Even in that case the answer would be no, because, first, I don't care enough about such a feature to invest even just a dozen hours into it, and, second, I'm definitely not willing to sink a few dozen hours into it in order to find out whether it's actually several hundred.  IK is such a juicy morsel that I'm sure lots of people will want it.  And if enough people want it badly enough, eventually someone will step up and do it.  But that someone will not be me.)

[Klapaucius]

It just occurred to me that Squad could do exactly what your mod does in the controller itself. There are a couple of ways to do this:

 

In After Effects, sequences (or compositions, as they are called in AE) can be "nested" or in AE also "precomposed". 

 

https://helpwiki.evergreen.edu/wiki/index.php/Precomposing/_Nesting_Compositions_-_After_Effects

 

Another option would be to take another tool from After Effects, parenting. This allows you to create a layer with certain effects--say a motion effect, and then you can take several other layers (text, image etc.) and make them "children" of the parent layer, thus assigning the effects of the parent to all the children.

 

 

[Snark]

22 hours ago, Klapaucius said:

It just occurred to me that Squad could do exactly what your mod does in the controller itself.

Perhaps, but that would then require using the controller.  Don't get me wrong, I love the KAL-1000 like a brother, but it's not needed for this simple scenario and I like the simple "click this one button and everything just magically works" aspect of this mod, not least because it doesn't require adding any extraneous parts.

[KallangoVerde]

Did I arrive too late or is this still being developed ??

[Snark]

Just now, KallangoVerde said:

Did I arrive too late or is this still being developed ??

I'm still around, but have kinda been neglecting this.    No new developments since I last posted a couple of years ago.  As far as I know the mod should still work on current KSP, but I haven't tested it lately so I can't guarantee that.  If you happen to find out one way or the other, let us know?

[KallangoVerde]

22 minutes ago, Snark said:

Eu ainda estou por aí, mas meio que negligenciei isso.    Não há novidades desde a última vez que postei há alguns anos. Pelo que eu sei, o mod ainda deve funcionar no KSP atual, mas não o testei recentemente, então não posso garantir isso. Se você descobrir de uma forma ou de outra, nos avise.

Great to hear that ... I'm going to test it today!