DivisionByZero

Long time no see and lots of updates to explore! I picked up KSP and KSPTOT again recently. I was trying to run a Duna mission with aerobrake maneuver, but the Mission Architect seems to think I'm not going through the atmosphere when my altitude periapsis is only 13km. The MA file is here. Any ideas? EDIT SOLVED: Instead of coasting to Periapsis, I did a coast to True Anomaly of something like -45 degrees. Odd that it didn't realize the periapsis was in the atmoshere.

Ike excursion was successful! More images of the landing at the end of the album: http://imgur.com/a/BAuN2 The Ike landing was interesting in that I didn't make a craft with sufficient TWR to be "comfortable". The lander had 1.5TWR for Ike's surface which is a very small acceleration for the ship, overall. Something like 1 m/s/s. This spooked me and I took a very conservative approach which burned up a lot of fuel. Also, an early simulation I ran wound up lithobraking in the surface, so I was extra careful. Plus, I go down without a pilot so there's no SAS available and this adds to the difficulty. Still, the ship set down with Jenbus and Mitsel Kerman on board - an engineer and scientist. After planting the flag and taking science on the craft, Jenbus got to work assembly the Surface Experiments. Once complete, Mitsel came out and did the job of running the experiments and storing the data. Actually, I ran each twice - once to transmit, and once collected to process in the lab. Ascent was pretty uneventful. I didn't wait long on the surface so the inclination change for rendezvous wasn't horrendous. Plus, dropping the SEP parts on the surface saved weight and I had a little spare delta-v. Even so, I just got fed up with trying to control the craft on manual for the docking, so I halted the ship outside the Duna Explorer, and then eva'd Jebediah over to the ship to do the piloting. All the crew are back safe and sound now. A bit more processing time at Ike, and then it's on to the Duna-portion of the mission.

More images uploaded! See toward the bottom of the Imgur album linked here: http://imgur.com/a/BAuN2 After achieving Ike orbit, it was time to start the major, orbital EVA portion of the mission. This consisted of the assembly of two space probes which were carried to Duna in a large cargo crate near the aft of the ship. Bill Kerman drew the straw and so performed the activity. I had to remind myself how I had designed to two craft. In fact, only one probe was kept in the VAB so I built that one first (the lander). KAS is the main mod that lets you do this sort of thing. The second craft is a long-term magnetic survey probe which will complete a couple of contracts for me around Ike. I assembled the remaining parts and realized I didn't have solar panels for the probe! I had some vague recollection, though, that I had intended to use the panels from somewhere else on the Duna Explorer. So, I grabbed a couple 1x6 PVs from the science module (these were back-ups anyway) and popped them on the probe. There's only enough juice to operate the omni antenna OR the long-range dish. While the Duna Explorer is in the Duna SOI, it isn't a problem using the omni. Later in the mission, though, I'll switch to the dish and communicate directly with Kerbin. The Explorer completed it's high-altitude survey and mapping of Ike and is now at a circular 49km polar orbit. Next step will be landing on the surface!

And now: Duna! http://imgur.com/a/BAuN2 Now that KSP 1.2 is out, I've suffered a mental break and lost interest in my current game, thinking only of moving to 1.2 as fast as possible. I think this happens to me every time there's a new version out. However, this mission was too big to fail! Things were dragging out due to Real Life and the fact that it's a career game, so I have all these other missions going while Jeb and friends snore away the miles to Duna. Instead, I've left the space stations going and decided to just fly through the rest of the Duna mission, just to prove I could. This will still be the first time I manage to put Kerbals on something outside of the Kerbin SOI in a career game (someone keeps releasing new version of KSP that make me abandon games before getting far!). Ok, so new images in the imgur album above - not many. Some beauty shots at Duna and the re-entry. It went exactly as planned, pretty much. I thawed out the crew about 30 days away from the Duna SOI and re-started all the life support and research. Once I hit SOI, I could use Trajectories mod to better plan the aerobrake maneuver. It was initially telling me I'd be left with an apo of only 400km or so, which is definitely too little to hit Ike. I adjusted and it wound up leaving me a 5Mm apo or so. The next maneuver brought my peri up to 3Mm with only 150m/s and this same orbit intercepted Ike. Another 100m/s and I'm in orbit at 470km over Ike at 45 degree inclination. Not quite as perfect as I planned, but pretty good. The scientists are quite busy and only converting about 9.9 sci/day. Next I do something like this, I'm going to fly specific training missions to solar orbit and back to get them up to level 2 before sending on long missions. The processing time is quite an investment and the lab quickly fills up with only 750 data storage available. I have to remind myself how long the mission sits at Duna before the return to Kerbin. It's pretty long as I recall. Also, I launched (after the fact) a ship with extra supplies - especially material kits, which I neglected to pack on the Explorer. I don't think they're needed, but, just in case... I had additional intended to leave the supply ship in orbit for some future colony. Well, maybe that'll work out in my 1.2 game, whenever that starts. I'll post more updates as I get through the mission.

Fly by complete! The Imgur album is updated with a few more images: http://imgur.com/a/wPEiw The mission was pretty successful. The flyby maneuver, though, was really fast! Only a couple hours after entering the Duna SOI did I get to Duna periapsis with the Ike flyby in between. I had to use RemoteTech to get the near-space science timed correctly and it mostly worked. The battery drain during transmission really knocked out a lot of information I would have otherwise gained. There will still be work for my manned Duna mission to do, I suppose. I had an unexpected treat that I captured in the screenshots: Ike was providing an eclipses on Duna when I entered the SOI. I hadn't thought about this, but there it was as I got closer. Pretty neat - made me appreciate the game again. Not enough delta-v to catch an encounter with Jool, unfortunately. I only have about 388 m/s on-board. Instead, I set up a theoretical maneuver at apoapsis that will get me the Jool encounter in a mere 23 years. lol. Even though apoapsis is still within the orbit of Sarnus, I don't think the antenna that was put on the probe can make it. No matter, I'll have long since sent Kerbals to Jool by then. I better have sent them, I think. We'll see.

Testing of RemoteTech + DeepFreeze interactions were completed 15 days ago. Jebediah bravely volunteered to be put on ice while the remaining scientists went on space walk. The onboard computer was instructed to thaw Jeb and it worked flawlessly. The ship remained on course with the three remaining Kerbals: Jebediah, Mitsel and Bob performing regular duties. The two scientists still had data to work through from Kerbin orbit and provided quite a load for mission control after another 20 days. Jeb had to guide a minor course correction as the mission control integrator seemed to be drifting once again. However, 49 days into the mission it was decided to freeze the rest of the crew for the remainder of the journey to Duna. The on-board computer was again programmed to thaw the crew, but now it was given 200 days to wait. The radio antenna remains on target to provide telemetry, but, in theory, it's already programmed into the computer. Duna encounter is in 230 days, so there is some leeway in case anything goes wrong (but what could go wrong?). With no one left awake, life support functions were shut down in the lab and hab ring and the agroponics function was halted in the nom-o-matic. And now the wait...

see if this link to a google sheet works: https://docs.google.com/spreadsheets/d/15SWRYC6XQXzcBqlk2b9ZWbuMsdfncGk0xy0jArgaCXs/edit?usp=sharing sorry for the delay, I actually wanted to see about some estimates for the thing to give you an idea. The calculation is based around an estimated delta-V for an aerobrake maneuver that I found in this PDF set of slides: https://solarsystem.nasa.gov/docs/5_Forget_Aerobraking_Equation.pdf There's an analytical formula that I used there, but for something as aggressive as the typical KSP maneuver, and something with more computational horsepower such as KSPTOT, you could make a more accurate calculation. Anyway, what the spreadsheet does is assume a spacecraft on a hyperbolic trajectory approaching Kerbin. The SMA is fixed and then the radius of periapsis is changed. From the variable periapsis, the atmospheric properties of the planet and the ballistic coefficient of the vessel, one can calculate everything needed in the result by Forget. This is the one plot in the google spreadsheet which will be called figure 1. The velocities for an orbit just inside the SOI can be calculated for the given periapsis - for the spreadsheet I just used a rough value for convenience. Similarly, an orbital velocity for something that doesn't leave the atmosphere can be calculated. These give the limiting delta-Vs of the maneuver for capture vs. burning up. Those two values would be used to solve for limiting values of periapsis based on the results shown in figure 1. For instance, I would calculate a range of allowable peripasis between 27.5 and 35km altitudes to achieve capture but not be trapped in the atmosphere. With this knowledge, the user could pick target constraints for the periapsis more intelligently. Also, you might pass this information to the optimizer if you *know* the user is requesting an aerobrake/capture maneuver. The main point is to provide more intelligent constraints to the user/program for aerobrake maneuvers.

Another interesting idea, maybe: Add a feature to MA or somewhere that can provide a scan in periapsis radius during an aerobrake maneuver. The scan or calculation determined, from the current trajectory information, what the minimum and maximum periapsis radii are such that the ship remains in the atmosphere or escapes the SOI of the body. In other words, something that tells the player the range of "successful" aerobrakes. I thought of this while trying to re-optimize my current mission and having the optimizer have great difficulty in keeping me either in SOI or outside of my current mission profile which might be too aggressive. Optimizer takes a while and I had to manually edit the constraints on the periapsis until I finally got it to a happy place. Since I fly without mech-jeb, though, knowing what range I can work with would be really helpful, certainly the maximum periapsis for capture within the SOI. I'd suggest the following implementation: project the current trajectory to the SOI change, then apply a radial shift (i.e. keep constant inclination) so as to scan through the possible radii without changing too many variables. Even coupling this to a graphical output showing post-aerobrake apoapsis vs periapsis radius would be hella cool.

That's basically the process. I used the fictitious UT and dummy setup because I was making sure I could make the launch window which was tight, but this is it. It would be a nifty feature for folks who want to/have to split a burn a whole bunch. I had six burns because I was moving 140 t on a single poodle and needed 1000 m/s total. It adds up as more and more orbits go out even past Mun.

Example: I use the opening tool - porkchop plotter thingy - to calculate the most efficient burn to Duna. This burn has a specific departure date and angle associated with it for peak efficiency. I put this info into mission architect and re-optimize the burn so it actually hits the target SOI. If I then ask it to split the maneuver into 6, say, burns, then there are now 5 more orbits of increasing length. Now, however, the actual time of departure (i.e. when a hyperbolic orbit is achieved on the final burn) is on the 6th orbit which is potentially days after the originally calculated. Now, my departure date is not as efficient as it could be. Consider instead, what I did on my last mission plan: I got a departure for Duna at optimal time. On a previous MA run, I took this and split the maneuver into 6 burns and then manually calculated the increment in time needed. I then made a new MA run, but this time, I added a dummy coast step that added the exact change in UT to compensate the 6 burn split I planned ahead. I then kept this in, input the optimum burn and re-optimized to actually hit Duna. I then split the maneuver and deleted the dummy coast step. Now I was departing Kerbin much closer to the optimum time for departure and re-optimizing the final delta-V maneuver required very little change. What I'm suggesting is that you put some option in to do all that calculation and change the initial UT to a lower value if the user wants because I had to keep track of a bunch of stuff to do what I did. Maybe I'm just slow on some option you already have, but it came to mind. Also: the option to split on time and your UI look great!

I was away from my computer for a while but now I'm back. I had some suggested features for you to add after working on a mission for Duna. The Split-maneuver tool in Mission Architect could use some love. One feature that might be cool is to have an "equal time" option. Because of propellant usage on previous burns, the same delta-V can be obtained with a shorter burn. In the standard, identical splitting, this means later burns require less clock time. There is already the manual method for redistribution, but having an automatic calculation to this effect could be helpful. At least in 1.5.4, the splitting tool did not adjust the burn time to account for new orbital periods added as a result of multiple burns. For large numbers of extra burns, there are a number of added orbits before actually leaving the original central body. As a result, previous calculations for things like true anomaly at burn from the porkchop plot tool need to be re-optimized. Alternatively, for the given delta-V splitting, the "added" orbit time can be added in but the initial burn time moved to an earlier UT to retain the original exit information. I had to do this manually just now with a dummy splitting "wait" period that was deleted after I split-up the maneuver. There might be some others, but I'll have to remember them later.

After a month-long vacation away from my computer, I'm back and can finally provide this update. http://imgur.com/a/BAuN2 The ship is assembled after quite some travails. I've also completed the new mission plan in KSPTOT-MA including the new vessel mass and as much of the aerodynamics as I can get without direct simulation of Duna. I'll update the post about the KSPTOT work shortly. For now I wanted to put up the album. Assembly was not super difficult. The main thing about moving the front-part of the core instead of undocking and moving the drive section over is that most of the weight is in the fuel, so moving the core meant moving a bit less mass around. The other thing about going in this direction is that I had the RCS balanced for the entire ship, overall. So moving a smaller mass with unbalanced thrusters was better than moving a bigger mass with the same. Especially since the drive section didn't have any on-board RCS tanks and I would have had to use KAS to put some on. If you read the image descriptions in the album, they're all pretty self-explanatory. I did get the whole thing assembled in orbit a few K-days before the start of the trans-Duna burns, but I had to shell out for accelerated assembly in KCT. It's worth it! I'll put images up of the KSPTOT-MA plan soon. In order to avoid a 10-minute burn that would almost certainly be wildly inefficient, I used the MA features to split the maneuver into 6 equal burns. The first burn is 1 minute, 55s long, and then each one is a little shorter since mass is being removed from the vessel but the thrust is constant. I had to sort through how to adjust the burn-time for the first burn since now there are 6 orbital periods of different lengths to account for, but in the end the overall delta-V to hit Duna is not much different than in the single, idealized burn. KSPTOT-MA says I should employ a 21km aerobrake maneuver to catch me into an orbit near Ike's. That'll be fun! EDIT: Added the images from Mission Architect to the album as well as the first burn to Duna and the final approach orbit at Duna, projected from just outside of Kerbin's SOI. All the burns are conducted manually since I don't use MechJeb. The trick I used to making things match with KSPTOT was to make sure I matched the SMA as closely as I could achieve. The burns in KSPTOT are timed to periapsis and are expecting a certain SMA for the orbital period, so I made sure to match this. Inclination and eccentricy varied out at the 3rd digit, but I got SMA correct to about 5 or 6 digits. Even so, time-warps and the Kerbin SOI mucked things up a bit so I had to do a couple of correction burns and small adjustments (9 and 13m/s correction burns) but I was always very close. Precise Node helped catch exactly the right maneuver adjustments.

Edit fail. Just go to the next post - sorry for the double post!

Are the OPM planet sizes and orbits both at 4x or just the orbits?

I've been playing KSP on and off for several years now but I don't think I've ever actually had a career game long enough to send Kerbals to another planet. Finally, this will change. It's probably helped by the fact that I went pretty easy on the difficulty and gave myself big science and funds! I will chronicle some of the process here. I am using USI-LS (and other USI such as Kolonization), DeepFreeze Continued, Near Future, Remote Tech, Kerbal Construction Time and several others. Planning is being done with the Kerbal Trajectory Optimization Tool Mission Architect (KSPTOT MA). The interesting intersection of mods is that a mission to Duna requires a lot of time there and back again if you don't want dead and/or grumpy kerbals. Launch windows are also critical since my location in the tech tree is just before unlocking nuclear or other advanced propulsion available in Near Future Propulsion. KCT also makes for the need to plan in advance since you can't just strike up ships at a whim. Initial planning was conducted with the KSPTOT MA to get two things: approximate delta-V requirement and approximate life support time requirement. Aerocaptures are planned at Duna and Kerbin to save. The minimum seemed to be 2.2km/s if I didn't do any visits to Ike and back and got everything perfect. The time required seemed to be 2yr 250dy (kerbal days) total. Some images from the initial MA plan are in the album below. I have just finished the ship and split it into three launches. When complete it will be 163.6 tons (64.6 dry). To avoid requiring a lot of supplies or getting too close to margins, I will freeze the kerbals with a pair of cryopods that can also double as life-boats. Total Delta-V is 3.19km/s which should cover some visits to Ike and the like. The intended crew is 1 pilot, 2 engineers and 2 scientists. The ship also features two probes that will be assembled in-flight. One is a long-term orbiter for Ike/Duna and the other is a lander for Duna. A larger lander is included for exploration of Ike. I had to pay in a bunch of money to accelerate the construction. This should let me catch the early launch window. However, I did determine that if my budget is 1000m/s, I could have a window as large as 25 days large to initiate the transfer to Duna. It would be better to catch the low-delta-v trajectory, though. All launches were conducted with a standard, 2.5m launch platform that was originally developed to conduct Minmus landings. Reuse of components has a benefit of reducing construction time when you use KCT. I'm at the point where I have to rebuild the mission in KSPTOT MA now that the design is finalized. I'll post updates as it comes. I hope you enjoy the albums.