Arrowstar

Something I've wanted to do for a while in KSPTOT now is have the ability to model solar radiation pressure (SRP) in Launch Vehicle Designer. This has two applications. First, for those interested in long term Kerbin station keeping problems, SRP is a major perturbation to your orbit. Second, assuming you have a solar sail large enough to make a difference, solar radiation can be used for orbit raising or orbit lowering maneuvers in solar orbit. (I think it can also be used for plane changes if you steer correctly!) This new functionality will be available in the next pre-release of KSPTOT. There are two models of SRP in LVD. The first is the "spherical" model. This model assumes your spacecraft is a sphere with a fixed area facing the Sun regardless of attitude. The material used has a fixed coefficient of reflectivity. The reference solar flux and solar flux reference distance refer to the power per meter squared emitted from the Sun at some arbitrary reference distance from the Sun. For our real solar system, that's 1367 W/m^2 at 1 AU. In the only major solar sail mod I could find, the same reference solar flux was approximately used at Kerbin's SMA distance from Kerbol. The second SRP model is a solar sail model. This model works by applying solar radiation pressure to a flat plate that is oriented in some way w.r.t. the Sun. Notice there are now three coefficients, one each for the three difference ways light can interact with your surface. Absorption does exactly what it sounds like and all the momentum from the light simply transfers directly to the vehicle. Specular and diffuse reflection of light are what allow a solar sail to perform orbit raising/lowering maneuvers because, unlike pure absorption, they transmit some force in the direction of the solar sail's normal vector (the direction out of the plane of the sail). You can set your initial solar radiation pressure model from the Edit Initial State menu accessible from the main LVD window (Scenario -> Edit Initial State). There's a new button available for this. There's also a new event action to let users modify their SRP properties in the middle of a mission, say to model solar sail deployment or retraction. I can't leave without a shot of the new system in action. Here's a solar sail craft in low solar orbit using SRP to raise its orbit, perhaps to head to Moho. That's all I've got for now! Any questions or thoughts?

Great, no worries. The next version of KSPTOT is going ship with a spherical harmonics gravity model system and I just wanted to make sure I had grabbed all the coefficients for any stock celestial bodies, if they existed. Since they don't, that makes my life easy. Thanks!

@FreeThinker, could you share here what the power output of Kerbol is that you're using for computing the solar radiation pressure on a solar sail? I've dug through the source code a bit but I can't seem to find anything.

Sort of along these same lines, does anyone know if Principia ships with a non-spherical gravity model for the various stock KSP bodies?

Coming soon to Launch Vehicle Designer (LVD): non-spherical (or "higher order") gravity modeling. If anyone's familiar with the EGM96 or EGM2008 Earth gravity models, this will let you implement those to get realistic gravitational motion at, for example, geostationary orbit. It was pretty easy to implement and definitely works! This image is the longitude time history of a vehicle in geostationary orbit around Earth over the course of about 14 Earth days or so.

Oh, the physics can absolutely be predicted, not a problem. The problem is that the system is extremely sensitive to the assumptions you make. If you assume that your maneuvers are all impulsive, then error creeps in because in reality they do take a finite, non-zero amount of time to execute. The fact that you hit Eve's SoI with that assumption means that the error was actually pretty small. Remember, you're basically trying to make one bullet flyby near another bullet at millions of kilometers away and moving many kilometers per second. What you were able to achieve with impulsive maneuvers is not a failure, it's a success of the impulsive delta-v assumption! If you want to get more accuracy out of the LVD tool, it can absolutely be done. (See this video for me flying a powered ascent from the Mun's surface to orbit using nothing but LVD's steering and a kOS script as controls). But then you pay the cost for that accuracy: you need to get your mass modeling right, you need to get your engine thrust and Isp right, and you need to execute the maneuver in KSP exactly as you execute it in LVD. If you can do all that, like I showed the video, then LVD can pretty much fly your vehicle wherever you want, however you want, exactly as you want!

You really would think this would be easy, yep lol. It does make me kinda happy that it's just as much of a pain in KSP as it is in real life though!

As a professional astrodynamicist, not only can I confirm this, but we also spend forever getting our engine and mass models perfect so we actually get the accuracy we need. Mass modeling in particular is almost as much work as the trajectory design problem lol, but making sure that your vehicle's mass is modeled correctly and making sure that that engine models (thrust and specific impulse, especially for start up and shutdown transients) are accurate is hugely important to actually getting the vehicle to where you want it to be.

That's probably as accurate as you can expect to be with impulsive delta v all the way from Kerbin. For more accuracy, you need to model the mass and engine of the spacecraft and use finite duration burns. You just can't achieve it with the impulsive delta v manuevers.

To be clear, did you figure it out?

In the sequential events list box, select the event whose maneuver you want to upload, then right click it and select "Upload Impulsive Delta-V Action to KSP."

Okay, after looking at your screenshots I do think we're running into the limitations of the "Zero Radius SOI" assumption. As I said, MFMS does not model the fact that Kerbin or Eve have finite sized spheres of influence, and this can and will have a noticeable impact on the solution. MFMS was designed for quick studies of the multi-gravity assist trade space and not for higher fidelity dynamics simulation (which you'll need LVD for, as I previously mentioned). I think at this point you're just running into the limits of the tool. If you'd like, you can get a bit more fidelity by importing your MFMS sim into LVD very easily: In MFMS, click the Save Results to File for LVD button. Select a name and location to save the file and save it. Open up Launch Vehicle Designer from the main KSPTOT GUI. In LVD, File -> New Mission Plan from MFMS Output Optimization -> Optimize Mission to get all the various bits of the trajectory to line up. The result from the optimization in LVD will be a continuous mission plan with higher fidelity that you can use in KSP. You can get even more fidelity out of it if you put in your vehicle's masses, stages, tank information, engine information, etc, and then convert the impulsive delta-v to finite burns. That's an advanced step, though, so one thing at a time. Let me know if you have any questions!

Okay thanks. What happens if you adjust the time of the maneuver a bit forwards or backwards? Keep in mind that MFMS is using a zero radius SOI assumption for Kerbin, so the timing may need a bit of tuning to work in KSP's finite radius SOI simulation. EDIT: Okay, so I tried it myself in KSP. When I put in your initial orbit exactly and then uploaded the maneuver node, it was close but not perfect. However, I noticed that when I removed the node, did some time warping, and then re-uploaded the node, it was way off. At this point something has probably shifted with the underlying orbit, which is why things went wrong. Not having the correct RAAN (LAN), argument of periapsis, and inclination can really throw off the way the maneuver works, even if they're only off by a bit. The only solution to your problem is to reoptimize your departure closer to your departure date, or to import the simulation into Launch Vehicle Designer (LVD), which can handle a higher fidelity dynamics model with real finite SOI sizes. There's a much bigger learning curve to using LVD, though, but it can definitely accurately model your spacecraft's very well.

There's a few things possibly going on. First, you need to make sure that your initial orbit around Kerbin is exactly what it is in KSP. If it's any different, you won't get a good answer. Second, when you go to upload the maneuver, you need to make sure that your departure burn is given relative to universal time and not the periapsis time. If it's not, that'll mess things up too. Can you provide provide screenshots of the MFMS window after you get a solution, the upload maneuver window with the maneuver filled in, and the KSP window where you're seeing things fly off into space (with the current time in the game shown)? I can tell me with all that. Thanks!

The new build of KSPTOT with the fix for the Multi-flyby Maneuver Sequencer (MFMS) window size issue is now online. Please go re-download KSPTOT from the original post, and let me know if you have any questions. Thanks!

Yes and no. There's no way to do it in the UI, but I can tell from your image that the bodies.ini file has the "bodycolor" entry for each body set to gray. You can change this to change the color of the orbits. You can find acceptable options for that field in the bodies.ini here: https://www.mathworks.com/help/matlab/ref/colormap.html#inputarg_map. Note that the actual color that shows up will be the average of the color map colors shown on that webpage. You will also need to restart KSPTOT to get those colors to load. Let me know if you have questions or if you need help with any of this! You're not the first person to run into this. I was going to wait until I had something more substantial to push out to rebuild KSPTOT, but since multiple people are having the issue, I'm building a new build of the application with the fix this morning. I'll have a fixed new build out soon and I'll put a note here when it's done.

Yes, you can! You'll need to create a custom bodies.ini file and load it into KSPTOT. The easiest way to do this is to open KSPTOT, then start KSP and get to the launch pad like you were going to fly a rocket. Go back to KSPTOT, and in the File menu, you'll see an option for creating a bodies.ini file. Push the button and tell KSPTOT where to save it. Then just load it in KSPTOT by going back to the File menu, selecting the option to load a bodies.ini file, and select the file you just created. Let me know if you have any questions!

As has been mentioned, KSPTOT can model N-body orbits. You'll need to use Launch Vehicle Designer (LVD) to do your trajectory design work. Please let me know if you have any questions. There's a bit of a learning curve to LVD, but I'm always happy to help!

I've resolved the issue by making a few containers scrollable. I'm not sure when I'm going to rebuild KSPTOT, but this will be in the next release!

Thanks for sharing. Can you tell me what your screen resolution is?

It's not a bug per se, it's a product of the fact that the mission optimizer window is modal, meaning that it prevents users from interacting with other windows until it is closed. This has never been an issue for me but I can see how it might be. I'll consider changing my approach here to make the optimizer window non-modal, thus allowing users to interact with the LVD window in a limited fashion (minimzing, etc). I still don't want users to interact with anything else until the optimizer is finished, though.

No problem! This one was easy thankfully. Happy orbiting!

Thanks for the video, that was super helpful. I've implemented what I'm hoping is a fix. Can you go ahead and redownload the Linux build from the first post and tell me if the bug persists?

Thanks for the report. Can you walk me through the steps to reproduce this?

Glad to hear it!