DROMOMAN - modular arm parts for Infernal Robotics

[miracmert]

Did you get the late's update plugin from magicsmoke ? had that happen once just need to update mods but don't remember what 1 it was but my guess is magicsmoke plugin.

Yep, newest version is being used and there is no problem with the parts from magicsmoke. Only the parts of nothke have the problem being loaded to my KSP.

[nothke]

Yep, newest version is being used and there is no problem with the parts from magicsmoke. Only the parts of nothke have the problem being loaded to my KSP.

What?? I hear this for the first time.. So they are not listed in database? (alt+F12 > database > textures)

[miracmert]

What?? I hear this for the first time.. So they are not listed in database? (alt+F12 > database > textures)

Just figured out that active texture management mod somehow blocked your textures. I deleted the mod, actually I thought I deleted it couple weeks ago hehe. So that problem is solved now, my new problem is that servos are turning in the wrong direction. They are turning horizontally instead of vertically. I think it was mentioned here before though, so I'm going to check that.

[NoMrBond]

Just figured out that active texture management mod somehow blocked your textures. I deleted the mod, actually I thought I deleted it couple weeks ago hehe. So that problem is solved now, my new problem is that servos are turning in the wrong direction. They are turning horizontally instead of vertically. I think it was mentioned here before though, so I'm going to check that.

You should probably let bray89 know about that in the A.T.M. thread so they can include a DROMOMAN.tcfg with the correct arguments as part of the default install package

[nothke]

So that problem is solved now, my new problem is that servos are turning in the wrong direction. They are turning horizontally instead of vertically. I think it was mentioned here before though, so I'm going to check that.

This issue was present in build 1, if you have build 2 it should be a problem. At least not in my KSP

[Crater]

No matter what I did, KSP was never able to load textures of the models in the pack, not showing up any parts in the VAB screen as a result. I realized that it only happens in nothke's mods. 6s tubes also don't show up because their model is not recognized by KSP. Any idea?

If you are still having problems with 6S Stowage Parts, can I ask if you have renamed the installation folder? I just wonder if you've created something like

GameData\Nothke\

and put a folder in there for each of his mods? Because if you do that, then the game can't find the models unless you also edit the part config files to reflect the new paths.

[miracmert]

This issue was present in build 1, if you have build 2 it should be a problem. At least not in my KSP

Unfortunately I have the problem in build 2 I will try to change the rotating axis in part.cfg so maybe that'll do it.

If you are still having problems with 6S Stowage Parts, can I ask if you have renamed the installation folder? I just wonder if you've created something like

GameData\Nothke\

and put a folder in there for each of his mods? Because if you do that, then the game can't find the models unless you also edit the part config files to reflect the new paths.

Thanks, the problem was caused by Active Texture Compressor mod

[lyndonguitar]

So this is not compatible with texture compressor mod?

[miracmert]

So this is not compatible with texture compressor mod?

At least not for me

[Crater]

So this is not compatible with texture compressor mod?

At least not for me

Works fine with it here (which I why I offered the alternative suggestion above).

I have this, and I use the aggressive ATM to keep memory down, and I've not seen any issues with any of the parts (yet )

[bigdad84]

I made a small arm for my station (front right). Anytime I still dock a "dragon" capsule to it or something and try manipulating it, it moves my station more than the capsule.

EDIT: They're currently set at 5, but I moved the arm as slow as 0.1 and it didn't make a bit of difference.

[LawnDartLeo]

What mod includes a functioning end effector/grip... or does the end link automagically function as the same?

EDIT: Never mind.... KAS winch.

Edited February 11, 2014 by LawnDartLeo

[Proot]

So this is not compatible with texture compressor mod?

Yes, it is. You only need the proper .tcfg file in your BoulderCo folder (texture compressor folder). I made my own, you can use it:

Make a .txt file named nothke_DROMOMAN (UTF-8 codification) with one of this contents, save it and rename it as "nothke_DROMOMAN.tcfg" and it's done.

Version 1 (soft memory saving):

config_enabled = true

Version 2 (hard memory saving, worst look):

config_enabled = true
OVERRIDES
{
    nothke_DROMOMAN/arm_linrothub/.*
    {
        compress = true
        mipmaps = false
        scale = 2
        max_size = 0
    }
    nothke_DROMOMAN/arm_radrothub/.*
    {
        compress = true
        mipmaps = false
        scale = 2
        max_size = 0
    }
    nothke_DROMOMAN/arm_rotact/.*
    {
        compress = true
        mipmaps = false
        scale = 2
        max_size = 0
    }
    nothke_DROMOMAN/hublet/.*
    {
        compress = true
        mipmaps = false
        scale = 2
        max_size = 0
    }
    nothke_DROMOMAN/limb2m/.*
    {
        compress = true
        mipmaps = false
        scale = 2
        max_size = 0
    }
    nothke_DROMOMAN/limb3m/.*
    {
        compress = true
        mipmaps = false
        scale = 2
        max_size = 0
    }
    nothke_DROMOMAN/limb075m/.*
    {
        compress = true
        mipmaps = false
        scale = 2
        max_size = 0
    }
}

Edited February 18, 2014 by Proot

[lyndonguitar]

okay thanks proot

[PlonioFludrasco]

Great mod, but you should add the "TechRequired" line in the part.cfg file to make your parts unlockable in career mode.

[Mecripp]

Great mod, but you should add the "TechRequired" line in the part.cfg file to make your parts unlockable in career mode.

If you would look at the part cfg you will see it as TechRequired if you don't you may need to update.

[Helix935]

Hi all! ZodiusInfuser's IR model rework reminded me that I have some unused models that I was intending to put in the pack update. I just never finished the texture work. A little late but yeah, I'm working on them =)

Here you can see the pitch joint, inline and at 90 degrees, and also an offset pitch joint inline and at full rotation.

can't wait for this

[DoctorCruz]

Great mod, helps a lot!

[Climberfx]

Yeah, inverse kinematics is something desperately needed for robotic arms to be any useful. Right now it takes half an hour to do a simple task since you control each joint. But inverse kinematics is I think hard to simulate with n-joint arms.. But I did not yet get this much in robotics (or maths) to know that =(

I have the formulas for Inverse Kinematics on After Effects Expressions, is another language, but is close to human understanding, so with you please, i can show you.

It may help on future implementations.

[Camacha]

I have the formulas for Inverse Kinematics on After Effects Expressions, is another language, but is close to human understanding, so with you please, i can show you.

It may help on future implementations.

I would love to implement those myself with the help of kOS.

[Climberfx]

I would love to implement those myself with the help of kOS.

In After Effects it is in 2d. But i believe you can study the mathematical solution and apply the same in 3D. Is all based on Pitagora's trigonometry. and because the arms in ik work based on 2D flexions, and only one rotation to resemble the 3d position, it will solve the problem easy.

[Rybec]

Unfortunately it's a little more complicated than that for this application.....

Conceptually, you are correct. You could rotate the root directly towards the target (the only change needed to go 3d) and apply the trig to get exact values for the pitch of the root and the angle of the elbow. You then interpolate the current joint rotations with the ones spat out by the trig and slowly move the arm over, use a separate solver for the wrist and hey presto. But this only works with two-segment arms, and only if the joints on those arms have no rotational limits. It's a very inexpensive (computationally) way to handle two-segment arms but with a system like this you need something that can handle any number of joints. The main problem stems from the fact that the trig is deterministic; you feed it variables, it runs hard math on them, and spits out an answer. Invert a variable and it flips the direction of the elbow, because there are only two possible solutions for any 2-segment arm of that type...

...But add a third segment and the solutions become infinite. Especially if a joint has more than one degree of freedom. As such, an iterative approach seeking target-minimization is required.

Several years ago I was looking at IK systems for n-joint chains and had a quaternion-based mockup running in Garry's Mod. The basic idea is for each joint it would figure out which direction on each axis would move the end effector closer to the target. It also spat out exact values for what angle would get it closest from the current total-state of the arm, but of course each joint was only allowed to move a little at a time before evaluating the next joint.

I had implemented joint limits but hadn't figured out how to make the solver aware of those limits yet.

Without the solver being aware of and avoiding the joint limits, it is very easy for the arm to end up bending over backwards and trying to reach the target while bound up on itself. It's kinda funny to watch, but not so much when it's plowing into your space station while doing it. (another limitation of the two-segment solution; it doesn't NEED to worry about joint limits because the elbow cannot ever overextend)

I no longer have the code I was working on, but everything I was doing was based off an old Game Developer Magazine article: "Making Kine more Flexible" by Jeff Lander. I can't seem to find a proper direct link but the first google result will get you to a copy of the PDF hosted by Carnegie Melon. In particular, the "Cyclic-Coordinate Descent" method described therein. It even has code examples that could be used with a little modification ( my own implementation was practically line-for-line verbatim, I just used a quaternion-based existing function as a shortcut instead of matrices). You can also look up anything referencing that article; you will likely find more advanced systems you can virtually drop into place; even a solver capable of handling variable-length segments for telescoping arms. Implementing the code in the article as-is can produce the joint-lockup problem described above, but that article is from 1998 and I guarantee there are more recent articles available that produce better solvers.

All this said, if you're looking for just a simple kOS solution for a two-segment arm with an end effector, the after-effects expression is perfectly viable as long as you offset the desired position of the wrist to account for your needed end effector rotation. The end effector just needs to point parallel to the target.

[Galane]

@Rybec google OpenRave IKfast

[Climberfx]

Rybec, i would use an spline in arc to control the multi joints possibilities, and have a separate control for high and spread. Or even an angle for that arc.

The arc would control the amount angle on each joint until the "target". The only limits that you would apply is to not overlap itself.

[rottielover]

Does anyone have a ModuleManager config to add these to the tech tree?

EDIT: Here you go: http://forum.kerbalspaceprogram.com/threads/26116-0-23-V1-5-6-Cabana-Corp-Research-Development-03-02-14

Edited March 30, 2014 by rottielover