Devnote Tuesday: I ain't getting on no plane!

[TiktaalikDreaming]

14 minutes ago, Claw said:

If you have this final stage by itself (or a stock facsimile) I can give it a run here. If it's non-stock, a picture might do.

Not quite exactly what I was talking about for staging (it's been a while since I've done that), but certainly leads to gittery over-correction, the ascent module of the NAR MEM (http://forum.kerbalspaceprogram.com/index.php?/topic/134450-wip-north-american-rockwell-mars-excursion-module/)

It's a half tonne (dry) control pod with RCS slightly stronger than stock stuck out on arms that make it absurdly over controlly.  Using it as an example as it's a single part and it always does the vibrating jiggle.  I'd give it less RCS power, but it uses that for docking.  But it's magnified by the RCS position for orientation control.

I'm happy just to wait and see though.

 

[StrandedonEarth]

49 minutes ago, TiktaalikDreaming said:

I've built many a final stage that has a lot of RCS to enable control over earlier stages, and once free of that extra mass, it has a Tacoma Narrows Bridge moment and burns through all it's mono.

I tend to put a set of vernors near the engines on my earlier stages, to help orient the vessel for circularization and transfer burns

[OHara]

On 8/13/2016 at 7:22 PM, Claw said:

If the ship is really rigid, the control point is never moving in relation to the main axis of the ship. When the ship is bendy and the control point is away from the Center of Mass, it starts bouncing around and the controller has a problem because it's getting inaccurate errors. What I mean by that is the angular difference between where the ship is pointing and where the controller thinks the ship is pointing is not stable, because there is a constantly changing difference between the main axis of the ship and where the probe core is pointing.

Oh! good.  The control point is the important part, when distinct from the root part. (I just did an experiment in 1.1.3 to confirm my understanding.)   That is what I had implicitly assumed, but NathanKell's earlier post said 'root part' and I took that literally.

There isn't much physical basis to expect that the mass-weighted average angular orientation would be a particularly good control input. I was going to warn that mass-weighting might cause problems, but haven't come up with an example yet so held my tongue. You could argue that the angular momentum divided by moment of inertia would be a measure of rotation that ignores all wobbling within the structure, but this is more complicated as
Sum{mass * distance_to_rotation_axis² * rotation_velocity_about_axis} / Sum{ mass * distance_to_rotation_axis² }
which is a different computation for each axis; Those Sums might be practical to do over every part, but really should be over every atom.   The signal from the wobble should cancel out in that sum, but I wouldn't recommend that approach.  

Having the orientation-senors in the "control from here" part (as KSP does now, as I interpret my experiment) makes sense, and gives players a way to take realistic steps to improve their wobbly spacecraft -- choosing the right "control from here" part in conjunction with enabling the more helpful actuators.

As you describe, if there is a resonance (a shape of wobble) in which the actuator moves one way, and the sensor moves the opposite way, a simple controller will drive that resonance as soon as its gain overcomes the natural damping.  I always try to remind the mechanical engineers of this, lest the control engineer come back with "the system has an unfavorable pole-zero constellation" for which they always suggest an over-complicated solution.

The mass-weighted rotation dumbs-down KSP somewhat, and makes me wonder how the Kerbals mounted rotation-sensing gyros on every single part.

Keep, at least as an option, the motion sensors in the control-from-here part, and you'll have the side-effect of building good intuition in the next generation of engineers (making my future life easier).

Edited August 15, 2016 by OHara
searching for "wobble" "control-from-here", I see KSP has been building good intuition -- but not everyone enjoyed the intuition-building experience

[richfiles]

I was really hoping to see the ability to add maneuver nodes while a probe is in communication range, and have the option to auto burn, even when coms are out of range or occluded. Basic probe cores might only be capable of a single planned maneuver node, and you might have to pre-orient the probe for the burn. Higher tier probe cores might support two or more maneuver nodes, and have the ability to self orient to the next node using reaction wheels. Early intermediate probes might only be capable of orienting to the attitudes they naturally support (prograde / retrograde only for an early probe, for example). A later probe might add support for radial or normal vectors. High end probes would have unlimited pre-planned maneuver nodes, and would be capable of orienting to a node. All probes would support a blind initial burn, based on pre-orienting the probe before coms loss.

All maneuvers would have to be set up in coms range. Maneuvers would not be able to be changed, added, or deleted once coms are lost.

I really was hoping to see such a feature. While it would technically be a flight computer... It'd function entirely within the scope of the maneuver node system, and already be a thing people understand. The only difference is auto execution, and changes only being allowed when in coms range. Still have hopes...