lushr

A log is still produced even though no crash occurs; the file is called KSP.log and resides in the KSP directory. It does not matter that no crash or visible error occurs, the log file is produced by every single run of the game. Without it, it's impossible to know what's actually going on in your FAR install.

This is referring to the cross section visualization used to evaluate rate of change of cross section for supersonic aircraft. It shows a graph along the aircraft's length. This is different than the static analysis graphs, which aren't shown in the 3D viewport. It's probably easier to just rewrite the shader for the cross section visualization, not least because KWT doesn't visualize the cross sectional area (since stock aero doesn't care about it). I have a few PRs to fix bugs in the simulation functionality that things like Trajectories and weirder kRPC systems use, on this topic.

Is it possible to save out the tables of values this mod computes? It'd be very useful for designing, tuning, and debugging aerodynamic guidance and control systems.

Is there a way to directly control rocket gimbal and control surface activation on a per-part basis? I'm implementing a control system that needs to produce independent inputs to the engine and the aerodynamic controls, but can't figure out if there's an interface to do so.

It's kind of hard to tell, but I think so? The main issue for me is that I can't use them to attain aerodynamic stability, since their lift appears to be basically zero. This is largely a problem for me because I'm trying to use them to do model predictive guidance for a Falcon 9-like first stage, and without aerodynamic stability the trajectory propagation will diverge (since it doesn't have a closed-loop controller fighting the instability). I'm currently using stock fins, though their control effectiveness leaves a lot to be desired and they cause the vehicle to be aerodyanamically unstable on ascent. At some point, I'll probably make a ModuleManager config to switch them over to the legacy FAR aero model and patch the mod to work with that. I've tracked down a few citations for modelling aerodynamic lift and drag of grid fins (which are weird! Odd stuff happens to them when they go supersonic, since the leading edge shocks interact inside the fins). Would they be of interest/help for picking the right coefficients for the mod?

Thanks very much for the help, it sounds like the best shot is for me to try to use the legacy FAR part modules to model the grid fin as a straight fin. From a quick skim of Kretzschmar and Burkhalter 1998, using a long straight fin model of the same area and width should be ABOUT right for the subsonic regime before the grid structure induces choking through interactions of bow shocks. This should even work fairly well with the existing voxelization of the grid fin, since they tend to induce higher drag (though only in the transonic regime and above and while at low AoA, technically) than flat fins. Does this seem like a reasonable approach? I wanted to avoid this, since it means I have to rewrite bits of the DLL that KRE uses, but it seems inevitable at this point...

On 1.3.1, I'm having some issues with Kerbal Reusability Expansion and FAR. I've asked on the KRE thread, and noone there seems to know how to solve this problem. The issue is that the grid fins don't appear to be acting as fins, and their effect on stability and center of lift is very similar to that of a flat plate of similar shape, size, and position. Using a Kerbal 1.3.1 install with only FAR and KRE installed, we have the following characteristics for a flat plate: Compared to a KRE grid fin: For comparison, here's a stock AV-T1: My strong suspicion is that the tiny little fins that make up the grid are too thin for the voxels to pick them up accurately, a hypothesis which seems to be confirmed by the debug visualization of the parts. I would very much like to use the grid fins and FAR together, but I'm not precisely sure how to fix this. I have a few ideas: The voxel grid could be reduced in size somehow, but this could have performance problems. The grid fins could be excluded from the voxel aerodynamic system and use some kind of arbitrary value forces. Moreover, I'm not sure how to implement either of these practically, and I don't even know if this really is an issue.

I'm having some issues with the grid fins and FAR (note: using 1.3.1 still). Neither appear to meaningfully effect Cm, dCm/AoA, or the position of the center of lift in comparison to a flat panel of similar size. For example, vs. For comparison, here's a stock AV-T1: I *think* what's happening is that the grid fins are being approximated by the voxel-based aero model, but the voxel grid size is too coarse to discover the holes between their constituent fins. To evaluate this hypothesis, here is the debug voxel display of all three evaluated aerodynamic surfaces: Something rather strange is going on with the grid fin compared to the traditional control surface and panel, though what precisely is not clear, and it's clearly much more holey than the flat panel. Are there any ideas for how to fix this?

That's really cool! I've implemented a closely related algorithm using Michael Szmuk et al's follow-on work to G-FOLD that is a true free final time approach, avoiding the golden section search for time of flight. Here's a demonstration video.

I'm having a bit of trouble understanding the drag and lift coefficient values for spherical spacecraft. For example, the following vessel, made using a Procedural Parts fillet tank made spherical: Since the vessel is completely spherical, I would not expect any dependence of the Cl or Cd on angle of attack. However, the chart shows a quite substantial dependence, which seems a bit odd (and, for due diligence, this vessel only consists of the tank so the CoM is centered on the tank's center). To check if this is a problem with Procedural Parts, I've done this again for a few different spherical fuel tanks, including the hydrogen tank from cryogenic tanks: Here's two PP nose cones back to back, which approximate a sphere: Cm dependence on AoA is better, but Cd still changes dramatically as a function of AoA. For the purposes of building an trajectory guidance system incrementally, I'm looking for a part that allows me to ignore Cl and Cd dependence on AoA, which in turn allows pointing without having to worry too hard about aerodynamic forces (only dependent on speed). A sphere would seem to satisfy this requirement, since it's perfectly symmetric along all axes, but FAR seems to indicate that all of the sphere-like-shapes I can produce still have lift and drag coefficients that are dependent on AoA. Is there a part that would let me conceal all the internal parts away from airflow while giving AoA-independent drag and lift coefficients?

I got my landing controller working on the Mun, thanks for the help! Warning, spoilers, I needed things to target.

Under 64 bit KSP on Windows, kRPC 0.4.1 fails to launch with this log: [ERR 20:38:16.581] ADDON BINDER: Cannot resolve assembly: KRPC.IO.Ports, Culture=neutral, PublicKeyToken=null [ERR 20:38:16.582] ADDON BINDER: Cannot resolve assembly: KRPC.IO.Ports, Culture=neutral, PublicKeyToken=null [ERR 20:38:16.589] AssemblyLoader: Exception loading 'KRPC': System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded. at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool) at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 at AssemblyLoader.LoadAssemblies () [0x00000] in <filename unknown>:0 Additional information about this exception: System.TypeLoadException: Could not load type 'KRPC.Server.SerialIO.ByteClient' from assembly 'KRPC, Version=0.4.1.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type 'KRPC.Server.SerialIO.ByteServer' from assembly 'KRPC, Version=0.4.1.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type 'KRPC.Server.SerialIO.ByteStream' from assembly 'KRPC, Version=0.4.1.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type '<>c__Iterator0' from assembly 'KRPC, Version=0.4.1.0, Culture=neutral, PublicKeyToken=null'. It looks like the KRPC.IO.Ports DLL didn't make it into the package, which is causing it to not launch. I can get kRPC to launch again by compiling and adding the KRPC.IO.Ports DLL from the other repository.

Quick question: how is the field return_is_nullable in procedures interpreted? Does the return of a nullable method not appear in the return value list at all, or is its value simply empty with some hole value left behind?

The new format for types is great! I was working on implementing a client in Julia (having a Python layer in between me and kRPC was getting overly annoying), and that solves one of my biggest headaches (parsing the type strings). Thank you very much!

Nothing that reflection can't fix - Trajectories was calling into FAR with it for years, no reason kRPC can't either, though it would probably be a good idea to submit a matching PR to the FAR repo to expose that functionality publically in the future. For this, it should be more than fast enough, especially considering the overhead in the wire protocol. For my application, it's fine if it can only be used in an editor scene, since the aerodynamics of the vehicle are assumed to be constant during the guidance phase, so precomputing the parameters and then saving to be used later is absolutely fine. However, you're right, it would be nice to get it working in the flight scene too, so that the system can adapt to things moving/exploding.

That would be really nice - I found the internal endpoint in FAR that would be needed, here, which would be enough (sweep each along the relevant axis). If it's too annoying to add, I could probably submit a PR.

I was wondering, is there a convenient way to extract drag and lift coefficients as a function of angle of attack and velocity via kRPC when using FAR? I'm working on implementing Ping Lu's paper Nonlinear Trajectory Tracking Guidance with Application to a Launch Vehicle, which uses cubic spline fits to Cl and Cd vs. AoA and Mach to model aerodynamic effects, and would like to be able to derive this automatically.

On this topic, I got my quaternion-based attitude controller (Wie, Weiss, and Araposthathis) working, which works fairly well but my tuning of it isn't very good. It does let me do a 3D translation autopilot in a vertically-aligned gravitational field, though, which the built in one had trouble with due to the singularity. I can post a video or two if interested, but as mentioned before, my tuning is garbage.

The problem is that I need the entire inertia tensor matrix, which is a not-particularly-nice-in-the-general-case 3x3 matrix. While I could transform the (three) torque vectors to the vessel frame from my guidance frame and back, that's an additional 6 RPC calls per iteration I would rather avoid. If I can get a vessel to guidance frame transformation matrix, then all I have to do is multiply the inertia tensor by the vessel to guidance frame matrix, and then I have an inertia tensor in terms of the guidance frame. Since I constructed the guidance frame, and can relate the vessel frame to the guidance frame with a rotation matrix based on the vessel's attitude, it's not an ideal solution (very complicated and application-specific, for one).

Is it possible to get the transformation matrix to convert from one frame to another? Since I ran into issues with singularities in the default KRPC AutoPilot (need to apply forces close to the vertical axis), I've been working on implementing Wie, Weiss, and Araposthathis 1988's quaternion attitude controller, as well as a LQR attitude controller, both of which need the inertia tensor, which comes by default in the vessel frame (which doesn't work very well for attitude control...). I could implement what I need by deriving a rotation matrix from the vessel's pointing angle (since I know the relation between the frame axes), but this is somewhat of a kludge.

@artwhaley Thank you for the help, I've been away from KSP (and will be so for a few more days), so haven't been able to do more poking at it. I've tried setting it with both heading and pitch (computed from the 3D vector) and with the vector itself, with similar results. The reference frame being used is a landing-site relative one, computed such that X is up, Y is east, and Z is north. My plan (once I get back to KSP) is most likely to implement my own attitude controller, I've been looking for an excuse to do some PID control theory, and this is ideal.

I can send you the code, though it's written largely in Julia (with a dependency on MOSEK, a commercial SOCP solver), so I'm not sure it'll be helpful for you. Let me know if you want it. By not well behaved, I mean "suddenly snapping back and forth between pointing straight up and the direction I'm commanding." To illustrate this, here is a video of the behaviour in question: The relevant section starts at around 31 seconds. The short white line appearing behind the vehicle is the commanded direction, which should be compared to the actual direction of the vehicle. Additionally, here is a plot of AutoPilot.error in the video, with the X-axis being seconds and the Y-axis being degrees error: You can see that the controller is exhibiting very anomalous behaviour that is not typical of PID loops, and I'm not sure what could be causing it. In extremis, I can implement my own attitude controller, but would rather avoid doing so.

As a quick follow up to my earlier post, I'm now having some issues with the AutoPilot attitude controller. It seems to get "stuck" pointing straight up, despite the direction being properly set (as indicated by the angular error, which can exceed 90 degrees). I'm feeding it with a guidance loop running at 30Hz, with a unit vector that's relatively well behaved. Any ideas what I'm doing wrong?

That's a really good idea - I'll give it a shot. Unfortunately, the optimization approaches don't really let you specify uncertainty - it's an all-or-nothing job. So far, I've been working on a solution based on what was flown on Masten Aerospace's Xombie back when they were validating it for Mars EDL, which is to have a simple P controller working to restore the pre-planned trajectory. The Xombie system also used a different terminal descent controller, that I haven't duplicated (though flying the last few meters manually is quite easy, at least when the system errors high and doesn't smash into the ground first). So far, my approach works well enough to crash within 50-100m of the desired landing site, and my main hope is that by tuning a PD/PID makeup controller I can hold the trajectory to within the landing leg's tolerances. I may also try to build the terminal descent autopilot that just cancels horizontal velocity and pulls the vertical velocity to within reasonable tolerances, which should at the very least reduce the number of explosions.

I'm working on doing hoverslam-style landing using a convex optimization trajectory generation approach, based on Blackmore and Szmuk et al's work. In this approach, a solver is used to compute the optimal trajectory from the initial position to the landing site (which is what takes the 0.5s), and then the autopilot just follows the precomputed thrust level and direction, at least in an ideal system. This is quite sensitive to where it's started up, because uncertainties in the initial state will cause the final landing site to be off by that same amount. In vacuum, just waiting for the solver is fine, because it's easy to project the state of the vehicle. Right now, I'm working on a Mun lander, which uses RK4 integration forward 4 seconds to the beginning of the optimized trajectory, which also accounts for the time needed to reorient and ullage. However, this approach breaks down in two scenarios: I eventually want to do SpaceX style landings with this script - which means that the system needs to work inside the atmosphere. I can't numerically integrate with sufficient accuracy atmospherically. Ideally, I would be able to re-run the optimizer as the vehicle is flying the old trajectory, further reducing final dispersion. However, again, numerically integrating this is quite tricky in this scenario. For this application, either manually unpausing or waiting for kRPC to get back to it would be fine, as long as game time isn't passing while the solver is running. Thank you very much for the help!