Arrowstar

Honestly at this point, you're not going to be able to use Lambert solvers with any sort of real accuracy I think. You can try your method though, and if you do, please report back the results to share, as I'm interested in seeing how well it does work. I suspect the reality of the situation, though, is that you would have to eliminate the zero-radius SoI assumption and propagate the orbits through the patched conics directly, which is what the high fidelity tools in KSPTOT do. This is not an easy task. Also note that I don't think there's an in-between: you either always make that assumption or you always don't. I can't see how you'd get around it any other way. Using a Lambert solver inherently involves the zero-radius SoI assumption, so if you use it, you're already locked in to the downsides of that approach as far as I can tell. Or so I think. Feel free to prove me wrong.

In KSP, you can see a variety of solar panel parts that sport an "electric charge rate" type of parameter. This presumably shows the amount of electrical power generated by the panel when it's facing the sun. However, for many years now, we have known that KSP models its solar panels' output using an inverse square law w.r.t. the distance to the Sun. What I'm after is how KSP uses this in a config file: chargeRate = 24.4 to get to the actual EC/s output rate that the panel produces in the game. What is that mathematical relationship? Presumably it involves some sort of relationship between distance to the Sun, the angle between the panel's normal vector and vector to the Sun, and a constant which gives the shown charge rate at the reference distance (I think Kerbin's orbit SMA from the Sun). Can anyone help me? @NathanKell, you've had some great insight into KSP math models before, any ideas here? Thanks, all! EDIT: I don't suppose it works something like this? ec_rate = ec_rate_ref * 1/(r/r_ref)^2 * cos(theta) where ec_rate => actual solar panel charge rate ec_rate_ref => the reference charging rate in the part's config file r => the distance from the Sun that the spacecraft is r_ref => the distance from the Sun at which the ec_rate is equal to the ec_rate_ref; probably Kerbin's orbit SMA theta => the angle between the solar panel normal vector and the Sun vector

Oh, KSPTOTConnect. Yeah, it hasn't changed much in some time, so it should still be fine.

Got it. I did get it working with the "bleeding edge" Kopernicus. If anyone's interested, I was able to pull in the data from JNSQ (via KSP) and use my KSPTOT tool to find a great little Kerbin -> Eve -> Jool -> Nara flyby. It only uses 2.9 km/s and all of the gravity assists are unpowered. Hyperbolic Departure & Flyby Orbits --------------------------------------------- Hyperbolic Departure Orbit from Kerbin --------------------------------------------- Semi-major Axis = -4021.4399 km Eccentricity = 1.198511108 Inclination = 8.2797 deg Right Ascension of AN = 215.3993 deg Argument of Periapse = 354.9401 deg --------------------- Out. Hyp. Vel. Vect Rt. Asc. = -2.8182 deg Out. Hyp. Vel. Vect Declin. = 5.1443 deg Out. Hyp. Vel. Magnitude = 2.498558536 km/s --------------------------------------------- Inbound Hyperbolic Flyby Orbit to Eve --------------------------------------------- Semi-major Axis = -2087.2051 km Eccentricity = 2.010954481 Inclination = 168.9757 deg Right Ascension of AN = 12.1982 deg Argument of Periapse = 324.5845 deg Periapse Radius = 2110.0694 km --------------------------------------------- Outbound Hyperbolic Flyby Orbit from Eve --------------------------------------------- Semi-major Axis = -987.1344 km Eccentricity = 3.1376 Inclination = 168.9757 deg Right Ascension of AN = 12.1982 deg Argument of Periapse = 324.5846 deg Periapse Radius = 2110.0694 km --------------------- Out. Hyp. Vel. Vect Rt. Asc. = -60.6737 deg Out. Hyp. Vel. Vect Declin. = 10.5466 deg Out. Hyp. Vel. Magnitude = 7.645221576 km/s --------------------------------------------- Inbound Hyperbolic Flyby Orbit to Jool --------------------------------------------- Semi-major Axis = -62839.5722 km Eccentricity = 2.200294697 Inclination = 13.6415 deg Right Ascension of AN = 122.1091 deg Argument of Periapse = 129.6825 deg Periapse Radius = 75426.0053 km --------------------------------------------- Outbound Hyperbolic Flyby Orbit from Jool --------------------------------------------- Semi-major Axis = -62840.4247 km Eccentricity = 2.2003 Inclination = 13.6415 deg Right Ascension of AN = 122.1091 deg Argument of Periapse = 129.6825 deg Periapse Radius = 75426.0053 km --------------------- Out. Hyp. Vel. Vect Rt. Asc. = 8.2224 deg Out. Hyp. Vel. Vect Declin. = -12.5115 deg Out. Hyp. Vel. Magnitude = 5.640082898 km/s --------------------------------------------- Inbound Hyperbolic Orbit to Nara --------------------------------------------- Inb. Hyp. Vel. Vect Rt. Asc. = 59.6511 deg Inb. Hyp. Vel. Vect Declin. = -13.3272 deg Inb. Hyp. Vel. Magnitude = 4.6289 km/s Sun-Centric Transfer Orbits --------------------------------------------- Phase 1 Transfer Orbit (Kerbin -> Eve) --------------------------------------------- Semi-major Axis = 29227173.1798 km Eccentricity = 0.286657863 Inclination = 1.0070 deg Right Ascension of AN = 66.5339 deg Argument of Periapse = 193.1326 deg Period = 10838383.9464 sec Departure True Anomaly = 166.8674 deg Arrival True Anomaly = 267.1952 deg Num. Full Revs Prior to Arrival = 0.0000 --------------------------------------------- Phase 2 Transfer Orbit (Eve -> Jool) --------------------------------------------- Semi-major Axis = 140199741.3939 km Eccentricity = 0.815187301 Inclination = 2.4896 deg Right Ascension of AN = 143.4282 deg Argument of Periapse = 50.0880 deg Period = 113868901.5437 sec Departure True Anomaly = 333.3668 deg Arrival True Anomaly = 157.2567 deg Num. Full Revs Prior to Arrival = 0.0000 --------------------------------------------- Phase 3 Transfer Orbit (Jool -> Nara) --------------------------------------------- Semi-major Axis = -648287756.6610 km Eccentricity = 1.221163277 Inclination = 7.2566 deg Right Ascension of AN = 161.7338 deg Argument of Periapse = 132.9588 deg Departure True Anomaly = 56.1299 deg Arrival True Anomaly = 134.8628 deg Num. Full Revs Prior to Arrival = 0.0000 --------------------------------------------- Kerbin Departure Date = Year 9, Day 216 04:04:18.800 (270878658.8002 sec UT) Eve Arrival Date = Year 9, Day 265 19:10:57.736 (275166657.7356 sec UT) Jool Arrival Date = Year 10, Day 175 12:09:55.288 (298901395.2880 sec UT) Nara Arrival Date = Year 23, Day 239 15:06:59.843 (714409619.8433 sec UT) --------------------------------------------- Total Mission Duration = 14 Years, 23 Days 11:02:41.043 DV Maneuver Information --------------------------------------------- Burn Information to Depart Kerbin --------------------------------------------- Total Delta-V = 2.8973 km/s Prograde Delta-V = 2608.9367 m/s Orbit Normal Delta-V = 1194.8611 m/s Radial Delta-V = 399.7847 m/s --------------------- Burn True Anomaly = 215.3993 deg --------------------------------------------- Burn Information to Depart Eve --------------------------------------------- Total Delta-V = 0.0000 km/s Prograde Delta-V = -0.0205 m/s Orbit Normal Delta-V = -0.0058 m/s Radial Delta-V = -0.0097 m/s --------------------- Burn True Anomaly = 0.0000 deg --------------------------------------------- Burn Information to Depart Jool --------------------------------------------- Total Delta-V = 0.0000 km/s Prograde Delta-V = -0.0234 m/s Orbit Normal Delta-V = -0.0000 m/s Radial Delta-V = 0.0000 m/s --------------------- Burn True Anomaly = 0.0000 deg --------------------------------------------- Total Mission Delta-V = 2.8973 km/s

Thanks, I'll take a look. Is that why Nyan Cat flies around the screen if you use a 1.9.1 built of Kopernicus?

I think I'm missing something, guys. I've got a clean install of KSP 1.10 with nothing but Kopernicus 1.9.1-6 and JNSQ 0.9 installed, but I'm not seeing any new celestial bodies in the solar system. Am I doing something wrong? Is there something I can look for in the KSP log file?

I'm not sure what you mean? What is the KSP companion?

No problem! I'm glad we got it going. The weird error you found is something extremely intermittent that only occurs rarely with some people. I've never been able to get to the bottom of it. Anyway, let me know if you have any questions about using KSPTOT!

Please try the pre-release below and tell me if that works for you or not. Thanks! -------------------------------------- Hi everyone! Today I've built the KSPTOT v1.6.6 pre-release 8. Here's the change log: LVD: New derivative and integral calculations for all quantities. Can be plotted in Graphical Analysis and used as constraints and objective functions. All numeric textboxes in KSPTOT now support more complex math functionality, including exponents, square roots, trig functions, and logs. Some LVD bugs were squashed that impacted lesser used systems. Please let me know if you find any bugs. Thanks! You could try the solution here. Basically delete this folder: C:\Users\[username]\AppData\Local\Temp\[username]\mcrCache[version] Just delete all mcrCache folders if you have multiple ones. This might work for you too.

This exactly, please. In other news, I have a new feature to announce for the math nerds out there: general derivatives and integrals in Launch Vehicle Designer! Oftentimes in spacecraft mission design, we are interested not in a particular quantity but in its derivative or integral. For example, we might be interested in the pitch rate of our vehicle, not the pitch angle itself. Or we might be interested in the range rate to another spacecraft for docking purposes, not our actual range. That's where these come in. You can compute the derivative or integral of any quantity available to be computed in Launch Vehicle Designer with this system. They work exactly like Extrema, too, which means that derivatives and integrals can be used as constraints for optimization and can be output to a plot or text file in Graphical Analysis. Here's an example of what you end up with when you try this out. I set up a simple, low Kerbin orbit case and took the derivative of x-position and the integral of x velocity. In theory, these should match the x velocity and the x position, respectively. Here are the results. Notice how the velocity plot (upper right) and the x position derivative (lower left) plot match? That's the derivative at work. Also note how the shape of the x-position plot (upper left) and the x velocity plot (lower right) are the same, just shifted. Why are they shifted? Because definite integrals need an offset, and KSPTOT has no way of knowing what that offset should be, so it defaults to 0.0. These derivative and integral items are created on the Launch Vehicle menu, "Edit Calculus Calculations." This feature will be coming in the next pre-release, so stay tuned!

You could do this in KSPTOT's Launch Vehicle Designer with some ease I think: Create a ground object at the point you want to overfly; Set up your initial state, an initial coast, an impulsive delta-v maneuver, and another post-delta-v coast; Set up a maximum "extrema" for ground object elevation to the point in (1); Set up a constraint that that extrema needs to be 90 degrees at the end of the second coast; Run the optimizer. I can't think of an analytical way to do what you're asking, I think it might need to be optimized out in all but the simplest cases. That's just my thought, let me know if you have any questions. EDIT: Yup, just tried it. This is very easy in KSPTOT LVD. Red line is the pre-burn orbit and the grey line is the post-burn orbit. The trajectory is viewed in the body-fixed frame, meaning that the surface of Kerbin is stationary and the orbit is plotted against that. You see the grey line passing over the red marker, which is the ground object I randomly put down on the surface (this could be your landing site or whatever). Let me know if you have any questions.

Just a minor update for next pre-release: all numeric text boxes in KSPTOT should now be able to handle more complex mathematical operations. Basic trig functions, exponents (using "^" symbol), square roots (using "sqrt()" function), and logarithms are supported, as are the constants PI (3.14159...) and eps (representation of the numeric precision of your computer, usually around 1E-16). Parenthesis are now also supported. I also found an fixed a few UI bugs with the GUIs that allow for Universal Elements that have existed through PR7, and those fixes will be coming next PR too.

Multi-Flyby Maneuver Sequencer should be an easy way to get what you want then.

If you're using the flybys to get out there, the multi-flyby maneuver sequencer would be fine for a quick initial analysis. Otherwise, either Mission Architect or Launch Vehicle Designer, both of which solve general trajectory design problems, would work great, though the learning curve can be a bit steep on those two.

I talked to the MathWorks today and they confirmed it was a known issue. They put in an enhancement request for me on my behalf, but I think that's as far as it'll go for now. Best I can do is to create a user setting allowing for the transparency to be adjusted by the user so that anti-aliasing gets enabled or disabled. EDIT: I added that edge transparency view option and rebuilt the application. I've re-uploaded PR7 with the new feature.

I know what the issue is. When I enabled edge transparency for the celestial body spheres, for some reason that broke the anti-aliasing and turns it off. I haven't found a work around yet, but you can imagine that's pretty frustrating. It might be a bug or limitation in this version of MATLAB, it certainly seems that way. I'll keep digging. EDIT: I just tried on my work computer using the latest version of MATLAB and it's still an issue. This is definitely an internal bug with using surface edge transparency and anti-aliasing.

Well drat. I honestly don't know then. Only that and the "Graphics Smoothing" option could have any impact to the way things are rendered, but I've played with Graphics Smoothing and it has no effect here.

Alright, here is KSPTOT v1.6.6 pre-release 7. Here's the change log: LVD: Added ground objects, which allow users to model stations and vehicles that primarily exist on or move relative to the surface of a celestial body. The view settings also allow rendering these ground objects in the display window, and ground track and line of sight can also be viewed. Graphical analysis tasks allow you to plot ground object quantities over time. MA/LVD: Updated line of sight calculations (again), this time they should finally be right. MA/LVD: Added the ability to change the renderer between OpenGL and Painters.

Alright, added to MA too.

Wait, this is happening in MA? That makes no sense, because I haven't touched anything in MA between the past two builds that I can recall lol. I honestly don't get what's going on, but I'll try to figure it out.

Done, it's in the view settings dialog of LVD, under the profile description text box. Set to OpenGL for faster rendering and Painters for (what I hope is) the style you had before.

As far as I can tell, the difference is that MATLAB is now using OpenGL as the render instead of the built-in "painters" renderer (which, admittedly, is far, far slower). Switching to painters gave the look you showed before but at the cost of a lot of performance. Not sure there's anything I can do about this one (in this version of MATLAB, anyway).

Did the old figure rendering not? I haven't touched anything in that regard, and honestly, I'm not sure how much control MATLAB gives me over rendering at that level anyway. Are you seeing something different? Yeah, this probably isn't a bad idea. (EDIT: Done for both MA and LVD, will be in next pre-release, which is coming today.)

@Drew Kerman All of the ground station stuff we've been looking at has inspired me to add something similar to Launch Vehicle Designer. I wanted to do a bit more than what I had done for Mission Architect though, so I worked on improving that functionality for LVD. Instead of "ground stations" we now have "ground objects" in LVD. What's a ground object? Literally anything that spends most of its time near the surface of a body. Could be an antenna, could be a rover, and could be an aircraft. Yes, those latter two move, and the new code handles that! It's pretty slick. Here's the new input UI for LVD's ground objects, available under Launch Vehicle -> Edit Ground Objects menu. On the left, you'll see the typical big list of ground objects that you've created for your case. On the right, you can edit the details for each object. A name, description, and which celestial body the object is located on it all there, as usual. There's more, though. You see the waypoints? You can now define points on the surface of the body that your object moves between, as well as the duration spent traveling between each waypoint. Waypoints are defined by latitude, longitude, and altitude, as is usual. The distance over ground from the selected waypoint to the next waypoint is shown, as well. You can have an unlimited amount of waypoints and they can be rearranged with the arrow keys, again as is usual for many LVD listboxes. Ground objects can exist in one of two ways: either limited existence between times, or for all time. The time at which a ground object "pops" into existence is the initial time shown in the UI, but if the "extrapolate times" box is checked, then the initial time is only used for computing where the ground object is at any given time, and the ground object will exist for all times. Additionally, ground objects with multiple waypoints can either loop through them and track along them backwards and forwards. Looping is enabled by checking the "Loop Ground Object Track" box and tracing forwards and backwards is enabled by unchecking that box. Ground objects can have a custom marker symbol color and shape, and their ground tracks can also have a custom color and line style. The view options have been updated to allow for ground objects to be displays, for their tracks to be displayed, and for line of sight to be displayed from the ground object to the spacecraft being modeled. Here's what that looks like in practice. Future work involves creating some graphical analysis tasks for ground object to s/c elevation, ground object to s/c azimuth, ground object line of sight, and distance from ground object to s/c. What do you think?

Sweet, my math is finally right.