PakledHostage

I just managed to get the boys up and safely back down again using only a pod, 2 LFTs and a LFE. I admit to having tried and failed at this mission about 3-4 times before I finally got it right, so I attribute the success in part to luck... I used 100% throttle to 110 m/s then ~80% throttle through ~15000 m before advancing again to 100% throttle. I intentionally placed them into a decaying orbit with a ~63.5 km periapsis to save fuel both going up and coming home. They managed about 3 1/2 orbits before re-entry. I\'d calculated that I should be able to get them slowed to survivable impact speed (i.e. less than 10 m/s) if I ramped up the throttle to 100% starting at about 200 m AGL. In the absence of a radar altimeter, I figured my best shot would be if they came down over the ocean. In the end, they came down over land. The engine and two tanks were destroyed in the impact but the pod survived. Reentry after about 3-1/2 orbits PH. Edit: Removed attached screenshots and added links to screenshots on Imgur

Never mind. I just figured it out... I\'ll post the explanation if anyone wants it, but I don\'t have time to make an image of the equation right now. PH. Edit: I\'m adding the aerodynamic drag and density equations discussed in this thread to this post for the benefit of future readers who, like me, require things to be a bit more obvious: In-game aerodynamic drag equation: where: m is the instantaneous total spacecraft mass Cd is the 'mass-weighted average of all the parts\' maximum_drag factors' The 'mass-weighted average of all the parts\' maximum_drag factors' is defined as: where: n is the number of individual components in the stack mj are the individual masses of each of the spacecraft components (from the VAB) Cdj are the individual drag coefficients of the spacecraft components (from the VAB) Kerbin\'s atmospheric density (rho in the drag equation above) can be approximated as: where: Altitude is in metres. And while solving the Goddard problem is FAR beyond my own mathematical abilities, I have benefited from Kosmo-not, Closette, et al\'s efforts in this and related threads. I hope to use these equations to more accurately predict my re-entry trajectories and for planning more precise aerobraking manoeuvres. Thank you all for your excellent work!

OK. You got me there! I admit I didn\'t think of that obvious example... I only noticed Closette\'s description of how to calculate Cd for an assembly: 'For an assembled spacecraft replace the maximum_drag with a mass-weighted average of all the parts\' maximum_drag factors, which usually results in a value of 0.2-0.3.' after I made my last post, but I don\'t know how that method was arrived at. Maybe one of you two can fill the rest of us in? My (apperantly flawed) idea that Cd is not used in the game is based on my own numerical integration of the two 'drop tests' that I described earlier in this thread. As I mentioned above, my model (using the two equations that I posted above, and which are the same equations that you describe) allowed me to make very accurate predictions of the two flight trajectories that I tested. As unlikely as it would have to be, it may be that the 'mass-weighted average' maximum_drag factor for the two (very different) stacks that I tested was 0.2027. This would have made it appear that the Cd term was not used because Cd would have been the same for both my tests as it was for your test. Closette\'s post above claims that the 'mass-weighted average' maximum_drag factor typically ranges between 0.2 and 0.3, so this is a possible explanation. I\'ll trust that that is the case. But please, for the rest of our benefit, can you please explain where using the 'mass-weighted average of all the parts\' maximum_drag factors' comes from? Thanks. PH.

I had another look at the data from my second drop test after reading through the two threads that Closette quoted on page 2 of this thread. It seems that my data actually does agree with your equation and my data also supports your results. The difference can be explained in the relative magnitudes of the our differing Cds. Your Cd = 0.2027 is about 18% of my Cd = 1.1, while my 'density scaling parameter' of 0.0017 is about 17% of your 0.0098. And as to why my second test didn\'t agree with the predicted values, I think I also figured that out. On a hunch, I removed the Cd term from the drag equation, leaving: I then moved your Cd value of 0.2027 into to the density equation by multiplying your 'density scaling parameter' of 0.0098 by 0.2027 to get 0.001986. The game\'s atmospheric density equation is then approximated as: Using these two equations in my spreadsheet, I then compared the predicted altitudes and velocities for the two (very different) ship configurations with the measured values. Both tests showed very good correlation (apoapsis, for example, matched within about 20 m). So, my conclusion is that the Cd terms given in the VAB are not used in the game\'s drag equation. (At least not directly. I know that there is some variation depending on how the craft is oriented relative to the direction of travel, but I only tested cases where the spacecraft was kept oriented straigt up and down by the SAS). Instead, the drag equation seems to be solely a function of density, mass and velocity as given above. Can anyone independently verify this? Maybe we could do a drop test using a modified version of foamyesque\'s FAKOOM lander legs? I had a look to see if I could readily modify them, but it wasn\'t obvious to me how to do it. I\'ll update this post with my plots and data when I get a chance. PH. Edit: Added suggestion on how we could do further systematic testing.

I\'m using the drag coefficient values that are given in the game\'s VAB. I assumed that they were drag areas (CdA), in which case the equation for drag would be: I understood that, in the game\'s simple physics model, the total drag of the spacecraft is just the sum of the individual drag coefficients. Based on that understanding, I used a value of 1.1 for the spacecraft configuration shown in my post above. In the aircraft world, Cd is dimensionless and drag area (CdA) has units of area. The units of Fd in the equation above are force. I was not aware that there are other forms of the aerodynamic drag equation. I will have a look at the other threads listed above. I\'ve been away from the KSP forums for a month or so. I may have missed those other discussions. In the mean time, I ran another test with a different configuration and got different results. Something is obviously wrong with my drag model (or with my interpretation of the drag coefficients given in the game). PH.

Ever the sceptic, I dusted off my old 'off the pad acceleration' spreadsheet and did my own test. I had tried this once before but I\'d failed to get a good fit so I gave up. Now that I know that drag in the game is a function of mass (mass??!!!? okay whatever... [flicks the radioactive cockroach away in disgust]) as well as velocity and drag coefficient, I was able to get quite a good fit. I\'m posting my test results here so that they can be reviewed and given whatever credibility (or lack thereof) that they deserve: I launched the spacraft shown in the image below at 100% throttle, with the SAS turned on. I let it climb until it reached apoapsis and then fell back to Kerbin. I recorded altitude and velocity at roughly 10 second intervals. I also set up an Excel spreadsheet to integrate the accelerations, computing the drag, velocity, acceleration and altitude at each 0.025 second time step. As above, drag was computed as a function of Cd, velocity squared and mass. By my figures: Cd for the stack shown above is 1.1 Initial mass is 7.4 tonnes Thrust is 200 kN I then adjusted the 'density scaling parameter' so that my predictions matched my data. Here\'s a plot showing the resulting altitude vs. time: And here\'s a plot showing the resulting velocity vs. time: The density scaling parameter that resulted in the best fit was 0.0017. This differs quite a bit from the 0.0098 quoted above. Maybe the difference can be accounted for in our differing methods, Kosmo-not? I\'d be interested to see anyone else\'s results. Maybe together we can nail down Kerbin\'s atmospheric properties. The results will be useful for more than just this challenge. PH. PS. I tried to include my spreadsheet as an attachment to this post so that others could play with it but I got a message from the server that it was too big...

Interesting that this thread was revived today. Coincidentally, I just completed this challenge the other evening and was going to post about it tonight... At least now I won\'t get critcized for necrobumping! What is it with those criticisms anyway? I kind of like the fact that some old threads are dredged up and dusted off from time to time. Often they\'re quite interesting. The drag race to 100 km altitude thread is a good example... But I digress. Anyway, in fairness, it has been a couple of weeks since this thread was current. I got distracted by the Other Planet Orbit - rendevous (and optional return) thread. For anyone who hasn\'t checked that thread out, it is an interesting challenge. Especially the returning to Kerbin part. Back on topic, I planned the trajectory for this mission a little differently than I described in my earlier post in this thread. I planned it so that they\'d re-enter a little more steeply than my earlier plan. I wanted a little margin for error because I wanted to succeed on the first try; I only get one or two chances a week to fly a longer mission. And in the game\'s current incarnation, it doesn\'t seem to be possible to turn your Kerbals into goo or to burn them up during reentry anyway. I flew this challenge real-time. I\'ve found that you end up in a slightly different location when orbits are propagated normally vs. when warping on rails. I have a sneaking suspicion that there\'s a numerical imprecision bug in KSP or one of its supporting libraries because large orbits seem to 'grow' slightly while propagating in 1x or 2x warp. A tiny imprecision the forces acting on the spacecraft could explain this. As I understand it, no forces act on the spacecraft while warping at 5x or above. But I digress once again... The fact of the matter is that the game\'s physics are only so precise, there is a slight difference if you use warp or not, so I stuck to one option: That of not using warp. It worked out and my Kerbals made it home after making a lap of the Mun. Here are my screen shots: Yeah, I\'d scream too! Outbound: Munar flyby: Return: Predicted as 278.5 km at TMI+ 5:34 (actual 288.19 km at TMI+5:30) Kerbol, Kerbin, Mun Predicted at TMI+ 11:23 (actual at TMI+11:24) Taking inspiration from F. Abilleira at JPL\'s 2011 Mars Science Laboratory Mission Design Overview article, I also tried to predict my Kerbonaut\'s reentry location. If a numerical integration is good enough for planning Curiosity\'s mission trajectory, then why can\'t the technique also be accurate enough for Kerbal? (I recently overheard a friend commenting about me to another of my friends that 'I like to do recreational math'. What\'s wrong with that? Everybody\'s got to have a hobby...)

Good idea. I wonder if we couldn\'t also use the target reticle on the nav ball to estimate our angular position relative to Kerbin? It would require a bit of trigonometry but it might be more accurate than eyeballing it? The only problem that I can see with this approach is the low rate of closure. At Kerbin\'s orbital altitude plus or minus 84100 km, you\'re only closing at ±29 m/s. That amounts to only 1 day per Kerbin year... If you\'re 2.5 days behind (about 8.5 degrees of angular displacement), it will take you on the order of 260 days to rendevous. Compare that with about 104 days until rendevous if you were to set yourself up in a 13,108,000 km x 13,534,442 km orbit instead.

It requires fairly precise timing and orbital trim manoeuvres but it is entirely possible to work out with only some simple math. Try setting yourself up with an apsis (either peri or apo) at Kerbin\'s orbital altitude, then watch and record the time that Kerbin passes that apsis. Try to be as accurate as possible. I slow the warp rate progressively down to 5x while watching for the Kerbin Icon to be centred in the PE or AP icon. Compare the time at which Kerbin passes that apsis to the time when you pass it and then adjust your orbital period so that you catch it on the next orbit. For example, if Kerbin is ahead of you by 2.5 days when you reach the apsis, then you\'ll need to adjust your orbit so that it is 2.5 days shorter than Kerbin\'s orbit. If it is too far away to catch up/let it catch you in a single orbit, then divide the difference by two, three or some other integer and then complete that many orbits before it catches you/you catch it. You could use a tool like Wx_Echo\'s 'Orbit Mechanic' mentioned earlier in this thread to determine the required speeds. You have to be fairly accurate though. Kerbin moves the radius of its SOI every 2.5 hours, so ideally you\'ll want to time your arrival at the apsis within that tolerance. You might also be able to catch Kerbin by passing within about 84100 km of its centre of mass on some other trajectory, but that would be harder to set up because you\'d have to be even more accurate about the timing.

I think we\'re talking past each other a bit here... we both seem to agree that it isn\'t the most efficient way to return to Kerbin. His screen shots here suggest that he did it successfully, however. The delta V that I mentioned is needed just to set him up to fall straigt in. I have no idea (and make no claims about) how much he would have used while waiting for Kerbin after that. As you correctly point out, we don\'t know how long he had to hover there waiting for Kerbin.

If this works, it is probably because Kerbol\'s gravity is miniscule at Kerbin\'s orbital altitude. It is only on the order of 0.00634 m/s (0.065% of g) at Kerbin\'s 13.5 million km altitude above Kerbol. If he\'s got the Delta V available to kill on the order of 9-10 thousand m/sec, then he could do that and thereby put himself into a highly elliptical orbit (essentially setting himself up to fall straight in). He would then only have to perform the occasional tiny burn to hold altitude while he waits for Kerbin to come around.

Further to my last post, here\'s some screen shots of a mission I flew recently. I didn\'t meet the objectives of this challenge but I thought that people might be interested anyway. On the pad. I\'m using my Kerballo 8 stack with the minor addition of an extra decoupler below the RCS tank at the top. Climb to orbit Decoupling following post interplanetary orbit insertion burn Orbital trim maneuver of +4.8 m/s upon crossing Kerbin\'s SOI into inter-planetary space reslted in this orbit about Kerbol Periapsis (here I did another orbital trim maneouver adding +0.1 m/s to raise my apoapsis by about 1000 km. Approaching Kerbin rendevous after 212 days in space. I sized my orbit so that my spacecraft would complete 3 orbits in 5 hours less time than it took Kerbin to complete 2 orbits of Kerbol. This put me just slightly out in front of Kerbin as I neared Kerbol apoapsis, with Kerbin closing at aprox 1500 m/s. Re-entering Kerbin\'s SOI, I had to use about 1/3 of my RCS tank to lower my Kerbin Periapsis to 10 km for aerobraking. My initial Kerbin Periapsis upon entering Kerbin\'s SOI was about 11000 km. I probably could have been more accurate if I had a better estimate of Kerbol\'s mass. As it is, my orbit about Kerbol was about 60 minutes quicker than expected, so I ended up about 5.5 hours ahead of Kerbin at apoapsis, rather than the planned 2.5 hours. Jettisoning my trusty RCS tank and nozzles prior to re-entry Final descent

I haven\'t had a chance to look at your 'Orbit Mechanic' calculator so I don\'t know what you\'ve done so far, but I think the challenge with developing something that handles interplanetary transfers within a planet\'s SOI will be developing the user interface. As you obviously already know, effective transfers initiated from within a planet\'s SOI require accurate timing so that your spacecraft not only ends up going the right speed, but also the right direction. Myself, I use a sort of 'celestial navigation' technique where I position my spacecraft into a circular orbit at an altitude that results in Kerbol or the Mun rising/setting at some useful angle relative to Kerbin / the Mun\'s orbital trajectory. I then time my pre-calculated burns off that reference. In interplanetary space, I use the time that Kerbin / my spacecraft passes periapsis / apoapsis to determine how much of an orbital adjustment I need to make to rendezvous correctly. For calculating the actual burns, I use a MathCAD spreadsheet and a home-brew numerical model, but neither can be said to be user friendly because I end up having to manually enter a lot of parameters... I admire people who can create intuitive user interfaces. Hats off to you for offering to take it on! Feel free to let me know if you want another set of hands to help out with the development. I might be able to port some of the work that I have already done to your project.

I first created my numerical model as a restricted three body model (one where only the parent body and natural satellite have significant masses; the spacecraft\'s mass is assumed to be zero) and later added an option to enable a 'KSP' mode. In the KSP mode, only Kerbin\'s gravity affects the spacecraft while it is outside the Mun\'s SOI. I then 'turn off' Kerbin\'s gravitational effects and “turn on†the Mun’s once the spacecraft enters the Mun\'s SOI. I have compared the two models and found them to be similar, but with a few notable caveats and exceptions. I posted a plot in another thread that compares free-return trajectories in the two models. http://kerbalspaceprogram.com/forum/index.php?topic=4615.msg54462#msg54462 Unfortunately, direct comparison of the two models is difficult. Not only because the Mun and Kerbin\'s gravity do slightly affect the spacecraft whether it is inside or outside the the Munar SOI (the SOI only defines the region where one body\'s gravity dominates), but also because there\'s a notable inconsitency in the Mun\'s orbital speed in the game. There is an equation that calculates the speed of a satellite of significant mass orbiting its parent body in the restricted circular three body case. That equation predicts that a satellite having the Mun\'s mass and orbiting a parent body with Kerbin\'s mass in a circular orbit of 12000 km radius, should be moving at 547.4 m/sec not the 542.5 m/sec used in the game. My three body model independently corroborates the 547.5 m/sec value, but the 4.9 m/s difference makes it impossible to directly compare the two models because the Mun is in a different place at a given time in one model vs. the other. In my 'KSP' 3-body model, I artificially restrict the Mun\'s speed and position to move in a 12000 km radius circle 'on rails' at 542.5 m/s, so that it more correctly reflects the game\'s physics. This was a relatively easy change to implement once I had the restricted three body model working. I used the “KSP†3 body model to calculate the trajectories I described earlier in this thread. I hope this helps.

Cool.

Thanks. But my question/challenge was whether it could be done with all standard parts? I haven\'t managed it myself because, as I said above, I used Nova\'s decoupler to minimize mass. And as you point out, it looks like the guy who made the video used Nova\'s decoupler too. I will try again with the standard decoupler, but I suspect it will take some precise flying to successfully achieve orbit. Maybe someone else is interested in taking on the challenge too?

Reading one of the threads over in the General Discussion side got me thinking 'what is the smallest rocket, made from standard parts, that can achieve orbit and still return to the surface?' I\'ve tried a few flights and have managed to get a LFE, 3 LFT, decoupler, capsule, chute assembly into a 75.3 km x 75.6 km orbit. But I can\'t claim it as the smallest standard part rocket because I used Nova\'s decoupler with its mass of only 0.25 (compared to 0.8 for the standard decoupler). Here are some screen shots of my 'proof of concept' rocket. I kept it up there for about 4 hours until I could splash it down in daylight in the ocean off the KSC: Is the 0.55 tonne difference in mass between the two decouplers enough to make the difference between being able to achive orbit and not? Maybe someone who\'s a better pilot than I am can do it?

I was intrigued by this problem so I ran some numbers. It turns out that you are quite right, rdfox, even though it isn\'t as sensitive a problem in KSP as it sounds like it is in the real world. I found that a difference in speed of plus or minus 1.3 m/s, post TMI burn, was enough to make the difference between being too high for re-entry and re-entering too steeply ... Here\'s a plot showing the two cases I tried. Both cases were for the spacecraft configuration shown below, with 100% full LFT and 100% full RCS tank at the start of the TMI burn, and orbiting in a circular orbit at 152.0 km. In both cases, the burn would start the instant that the centre of the Mun\'s disk is on the horizon, and would use only 33% throttle. All of this is critical because the starting fuel mass, throttle setting, starting altitude and TMI burn location affect the rate of acceleration and the resulting trajectory\'s orientation relative to the Mun. If you were to nail the 89.4 second burn, you\'d expect to end up in a 153.3 km x 13550 km orbit that would set you up for a 240 km high Munar periapsis once you transitioned into the Mun\'s SOI. Your return trajectory would intercept Kerbin\'s atmosphere (I\'m defining the atmospheric boundary somewhat arbitrarily as 48 km) with an angle of 21 degrees below the horizon. If you keep your heading centred in the prograde recticle throughout the TMI burn, your post TMI burn speed should be 2971.5 m/s at an altitude of 159.1 km. Similar precision flying the 89.3 second burn would find you in a 153.3 km x 13280 km orbit, set up for a 189 km high Munar periapsis. In this case though, your return trajectory would only take you within 112 km of Kerbin. MECO would be at 2970.2 m/s. That\'s a difference of only 1.3 m/s between the two cases. I\'ve used the numerical model that I used for these calculations to plan four different missions (my Kerballo 8, 10 and 11, plus a mission to geo-synchronous orbit directly over the KSC), and I\'ve found it to be accurate. The main limitation is my flying ability. If anyone wants to try flying these trajectories, I\'d recommend setting your throttle to 33% before activating the TMI stage. That way you get the throttle setting you need just by hitting the space bar. I\'d also recommend retarding the throttle at 2965 m/s in the 89.3 second burn case and at 2966 m/s in the 89.4 second burn case. By the time you get the throttle down, you\'ll be within a m/s or two of the intended speed. I usually trim my orbit post-TMI burn using the RCS. It usually doesn\'t require more than a couple of m/s delta V to achieve the correct apoapsis. I\'ll try flying these profiles myself too, but I probably won\'t have time for a couple of weeks. Somehow I seem to have more time for calculating trajectories and planning flights than I do for flying... PH