FleshJeb

My inner aerodynamicist weeps every time I open your KerbalX page.

His is hub-driven--I converted it to piston-driven: https://www.dropbox.com/s/hnnz2j240ff8qcp/Wilesco D-6-FJ-1.craft?dl=0 It has a heck of a time starting and stabilizing in the correct direction. Two things I think would help are a larger radius for the piston attachment, and boosting the startup with the hubs. I tried boosting this one, but it was not successful. Check the two KALs on mine. Math here:

You may want to include this mod as an option for your challenge. It's easy to use, provides timing, and helps my poor brain find the next corner:

I have a bulging disc in my lower back that occasionally prevents me from walking at all. My doctor is also a sports medicine specialist and he handed me a sheet of 20 pilates exercises for decompressing discs. They're extremely effective for acute pain, as well as being preventative. The first 6 of these are ones I have done: https://www.verywellfit.com/learn-pilates-exercises-to-help-decrease-back-pain-2704746 Do 10 reps of those, 3x a day and it will help. I went from not walking to fine in 3 days. It's OK if they hurt a bit, but if one hurts a lot, do fewer or none. If one feels good, do it more. Inflammation is the enemy, so standard anti-inflammatories like ibuprofen or naproxen sodium on a regular schedule until the problem stops. If you're having spasms or cramping, the "shameful secret" among big hairy guys who work for a living is PMS meds like Midol. It's magic, take it and enjoy the pink frilly bottle. No heat, ice only. I made that mistake ONCE.

Oh, I misunderstood the perspective. I thought that was a cabin a few km up. That’s a BIG building.

A) That’s a skyhook. B) I’m pretty sure you want it moving west to east.

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.

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.

Yes, I noticed the part separation. Was too busy enjoying the new toys to document it

I feel you in the rotor expansion, but I like the challenge and the self-governing aspect. I think I may also have figured a way to mitigate it better. (Need to test tomorrow). In any case, I think you’re using too much rotor for that craft/blade arrangement. I’ve easily gotten 400kn out of one large rotor at 200 RPM (slight expansion). You can either limit the RPM or go to the next smaller rotor and be fine. Secondly, as I keep reminding people, KSP has terrible lift-to-drag ratios (10:1 wings). You probably need 3x the blade area that would seem to make sense in real life. The extra mass and drag will further help limit your RPM and thus your expansion. If you want to retain real life aesthetics, clip the blades together. Great find on the throttle BTW.

Is this your way of trying to get me to rig that thing as an actual helicopter? (PM me about it) Major obstacles: 1) I’m frightened of non-coax. (If I do that, it’s getting a Fenestron) 2) I want it to still do Mach 3. (I think I can enclose the rotor assembly in a fairing that will be ok)

Ah, that’s educational, thank you. I thought that was an AVC screen. AVC used to phone home with quite a bit more information. I just verified, and that was fixed. Still, I don’t need my mods hitting up a third party server every time I launch KSP. Software engineers need to be beaten with sticks until that kind of behavior is very clearly opt-in only.

I’ve been under the impression that strutting or autostrutting across the moving portion of a robotic part prevents movement, unless it’s strutted to something that can move identically. You can strut from the base portion of the part freely. @5thHorseman any new discoveries? So far, I’ve been able to brace my tilt-rotor pods by placing a u-joint (servo and two hinges) and a piston on the main craft, and a u-joint on the pod. I place them facing each other, and run a conventional strut between.

When in doubt, delete all DLLs related to AVC (and miniAVC). They’re both useless pains in the butt. They’re also basically spyware (which was a big controversy a few years ago).

Let’s see if I can draw on a phone with ASCII | = a fixed point on the craft. O = a rotor. All have their bases to the left. = = the closed portion of a piston. - = the extended portion. b = a docking port facing right. d = a docking port offset and flipped so that it’s facing left. Side view: |OO d |O===---b Pretend both assemblies are on the same axis. There are blades on the 2nd and 3rd rotors. The 2nd rotor is set to the reverse of the other two. IIRC, this was showing 780kN on the test bench with two * 6 Big S Elevon 2. (65kN * 12) Now that I know more, I’m sure it can be run with two * 8 blades. Of note, you can retract the piston after the docking and the ports stay docked. You can try various things with the piston to add tension or compression to the system, and that helps get rid of the wobblies. I was going to try something similar with struts, but I had a bunch of other pieces in the way, and wanted a solution that wasn’t dependent on line of sight.

@Brikoleur Agreed. If anything, the rotors are too powerful. It’s all about blade area. I’m doing great with non-contra-rotating tilt rotor craft. Getting between 50-65kN per blade when using 6 to 8 BigS elevon blades per rotor at around 220 RPM. My crappy 50ton test bed “zeppelin” (no wings) craft got forward speeds above 50m/s with the props set to 75 deg above horizon, and blade pitch of 15. The big issue is that KSP wings have a much lower lift to drag ratio than real ones. We need about 3x the wing area that we think we would. @AngrybobH That asymmetric lift problem is a bear. I’m sticking with pairs of rotors (contra or non contra) for that reason. If you do ever need more power, I found you can run a piston with a docking port through the rotors and hook them together coaxially (MH inflatable ports work too). I managed to hook a third rotor to a contra prop assembly, with two sets of blades evenly splitting the power from all 3 rotors.

From the Making History DLC.

@HB Stratos I got it to work with the piston. It doesn't keep position in the editor, but it runs pretty well on the runway. If I were to build something like this for myself, I would dock the loop together--Either with a docking port on a piston, or a Making History inflatable docking port. I've tried both, and they work great. @Triop

If you mount it on hinges, you can control yaw and roll as well.

He didn't. Some weird strut interaction is doing it. Triop, ya shoulda used a docking port somewhere! On his request, I switched it from rotor-driven to piston-driven. I only knew the value of the extension at the 6 o'clock position (1.97m). I couldn't disassemble it, because the root part of the craft is the flywheel rotor. First, I measured components using the piston extension value and my eyeball. The largest piston, when closed, is 2.21m. The radius of the attachment point was 0.83m (not shown). Then I drafted it in AutoCAD and found the extension lengths at eight points around the circle. It's not just a simple sine wave because of the geometry. Then I plugged the values into the KAL while holding the rotation speed as a constant, so the 8 points are evenly separated in time. It runs fairly well after the first few seconds. The RPMs vary between 55 and 65 (goal 60). You might choose to run your reciprocating engine with connecting rods that are BG pistons affixed to hinges on the cylinder head. They can drive the crankshaft. If you do, you'll need to use my method above to get the timing right.

AWESOME I was hoping it would. Who are you, and what have you done with Tri0p?!? :rofl: The Panther is 3 EC/s dry and 5 EC/s wet. The Whiplash is 5. You could run the wheel at half-throttle. I was wrong about it being a perfect sine wave. I forgot about the geometry of the piston. The piston at the 12 o'clock and 6 o'clock positions will be longer than just the average of the 3 o'clock and 9 o'clock. You can temporarily drive the wheel with a servo to read the piston extensions at 0, 90, 180, 270 degrees. I made up some dimensions and drafted it in AutoCAD. The keyframe graph will more closely resemble the below. Note that the dots in the middle (38.5649) are slightly above the midpont (37.5).

For the most part. I think I've run into a few exceptions (Wheesley?). I read somewhere that eyeballing the visual centroid of the model is the best bet. Mostly consistent. The experiment I did with that Claw above was originally in a straight-sided 1.25m fairing. I had it very clearly inside, and it was still dragging. What I've read elsewhere is that at least 50% of the visual model should be in (the Claw is rather fat). I suspect it's not quite that complex, but there might be a bit of a fudge-factor for size. I suppose the real test would be trying to obscure an orange tank in a 1.25m fairing. (I have a Work In Progress that's four Mk3 fuselages that I want to obscure with a 3.75+m fairing, so I'll find out soon.)

Your keyframes should look exactly like a sine wave. You probably want to find the longest and shortest extensions of the piston and extrapolate from there. Just run the flywheel rotor at a really slow speed while having the right-click menu for the piston open. You probably want at least 4 keyframes: mid, long, mid, short. I think your flywheel is relatively light. Perhaps a second layer of gold plate, or some ore tanks on the inner circumference? Note that mine has the piston driving horizontally, with an additional hinge and connecting rod going to the wheel. Mine has a counterweight on the back side of the flywheel (white arc over window) to balance the weight of the piston attachment point. You might want to rip the wheel off and balance the CoM right through the rotation axis. That Whiplash in the firebox is an inspired choice. Are you also running a Juno in the smokestack? Put together, that's 6 EC/s, and I think the piston only uses 8 EC/s max. That's because you're a filthy spammer.

Steam engine, secretly powered by fuel cells. It looks really good, and I love how you did the pipe. The fact that you're powering the flywheel and not the piston makes my eye twitch though. If you need another reference, I've sat and stared at this for many hours in real life. Photo is linked to some dude's Flickr, with history and specifications listed.

Only if they retract into a cargo bay, service bay, or fairing. You only have to get them about halfway in though. For instance: