PakledHostage

More than any of the planned features, I\'m looking forward to flying missions to other planets. I\'m thinking it\'ll end up being my entertainment for next winter. I like the idea of crew transfer and orbital rendezvous. As for how to get to another planet, there was some good discussion about this topic in the How are we to get to Mars thread a few months ago.

To be honest, I\'m not sure... I would guess that it is because the first stage quickly boosts us to something close to the optimal climb speed that was worked out by Clossette, et al. It does this by about 1000 m altitude at which point it is possible to reduce throttle to about 2/3 and climb at something close to the optimal ascent profile until the fuel runs out. Following staging, the LV-909 then maintains something close to the optimal climb speed profile (albeit a bit on the slow side) the rest of the way to orbit. It is an interesting idea. I guess you\'d run a fuel line down to the LV-T30? I have to admit that I\'ve never actually used fuel lines in any of my designs. My Kerbals are luddites. Maybe you could improve on this design with your own tweaks?

Playing around with the Tsiolkovsky rocket equation, it occurred to me that I could get a stock 1-1/2 LFT rocket into orbit that could also return safely to the surface. I borrowed Kosmo-not\'s idea of using a large LFE in the first stage and a small LFE in the second stage, but placed the large LFT on the upper stage. Interestingly, the delta-V for this stack with a parachute (4875 m/s), is actually greater than the Delta-V for the Pod-2LFT-LFE, without parachute stack (4537 m/s), even though it has 1/2 tank less fuel! This means it is easier and takes less fuel to send our heros on a survivable mission than an almost certainly suicidal one... Here are my screenshots: Splashed down after 1-1/2 trips around Kerbin

Not directly, but there was the Economy of Design challenge. Through a combination of calculations to predict when to start my pre-landing burn and a lot of luck, I managed to get a (1) Pod-2LFT-LFE stack into orbit and safely back down again (total of 2 tanks). I also recall reading about Kosmo-not managing to get a (2) two stage Pod-small LFT-small LFE-decoupler-LFT-LFE stack (total of 1-1/2 tanks) into orbit. And I seem to remember that there was a group who worked to get a (3) Pod-small LFT, LFT, small LFE stack (total of 1-1/2 tanks) into orbit using MechJeb. By my figures, stack (1) has a Delta-V of 4537 m/s, stack (2) has a Delta-V of 4716 m/s and stack (3) has a Delta-V of 5627 m/s. (If I\'m wrong about any of this, I\'m sure someone will be quick to correct me...) Maybe your optimisation efforts could be applied to a new challenge to get the lowest Delta-V rocket into orbit? Adding a parachute to stack (1) decreases the Delta-V to 4291 m/s. I have always wondered if it would be possible to get that stack into orbit but I haven\'t managed it. Maybe you can do it?

Thanks and sorry about the duplicate thread. I\'m glad to see that my numbers agree with yours and UmbralRaptor\'s.

I\'ve been away for the weekend so I don\'t know if anyone else has done this calculation yet. But I just did a search to see if anyone has posted a mass and radius for Minmus and I didn\'t find anything. I\'ll go ahead and post my numbers: Mass: 4.233 x 10^19 kg Nominal (“Sea Levelâ€) Radius: 60.00 km Also, during my search, I noticed that there is still no Wiki page for Minmus and the Kerbin page still needs to be updated to reflect the fact that Kerbin now has two moons. I\'d have done it myself but the page is locked for anyone other than administrators. Anyways, I got these two values by flying a probe to Minmus and recording data for three different orbits. I then used the data to solve two equations (the 2-body equation for orbital velocity as a function of orbital radius, periapsis and apoapsis distance, plus the 2-body equation for orbital period as a function of periapsis and apoapsis distance) in the two unknowns (mass and radius). The results for the three tests agreed to within four significant digits. I have further verified the numbers by using them to successfully plan orbital manoeuvres and these values also predict a Minmus SOI radius of 2712 km (i.e. 2652 km altitude on the altitude display). I\'m pretty sure the numbers are accurate but I\'d be happy to see a comparison of my numbers with anyone else\'s.

Coincidentally, I am currently reading a book by Neil F. Comins titled 'What if the Earth had two Moons?' It describes 10 scenarios for alternate 'Earths'. One of those scenarios is the title scenario. Given that the title scenario is now appropriate to Kerbin, I thought I\'d give the book a plug and share one of the predictions from the book: The Mun and Minmus will eventually collide. Gravitational effects will cause the Mun\'s orbit to become more elliptical and tidal effects will cause it to spiral outwards over billions of years. The Mun\'s orbit will eventually intercept Minmus\'. When the collision finally happens, the Mun will approach Minmus from behind. One or both of the moons may even crack open prior to the collision. The collision will appear to occur in slow motion as viewed from Kerbin. To paraphrase Comins, Kerbals on the side of Kerbin facing their moon\'s can 'prepare a jug of their favorite libations, set up a comfy chair and watch the first phases of the event over a period of hours.' Unfortunately for our Kerbals, debris from the impact will fly in all directions including towards Kerbin. The resulting impact events on Kerbin will probably cause mass extinctions. Eventually, the debris from the collision of the two moons will coalesce into one moon. Debris that wasn\'t blown out of the Kerbin system or into a collision course with Kerbin would at first form a significant ring around Kerbin. 'Within a few years, the densest part of the ring would clump together due to its own gravitational attraction and due to relatively slow collisions between its pieces.' A single moon would grow as it collected more and more of what used to be the Mun and Minmus. 'Eventually this new moon would absorb the remaining ring debris and a new era in the life of [Kerbin] would begin.'

What can I say? I\'m confident that you\'ve landed on the highest equatorial mountain on the Mun. Kerbalmanjero? The twin peaks of Kerbalmanjero? The elevation in your first screenshot agrees within 14 metres of my measurement. I\'d say that this is pretty good considering that the measurement positions aren\'t identical (through no fault of your own). The position that I gave above for the highest measured point was rounded to the first decimal place. The precise position that I measured from orbit is located 154 metres away from your location on a heading of 105°. This could easily account for the 14 metre difference. And for anyone who\'s interested, my radar altimeter works by emitting five 'rays', fanned out in a ±40° arc under the orbiting spacecraft. I use the quaternion rotation identity to rotate the local 'down' vector about the spacecraft\'s velocity vector to orient the sensor rays. I sample at about 2 Hz, which corresponds to about 250 metres between sets of samples at typical orbital speeds. Unfortunately, the probe also has to orbit very close to the Munar surface for the radar to get valid returns, so the horizontal resolution is limited. Even using the fan technique, this means that the probe can only really measure directly below itself while passing over the highest peaks. Obviously the resolution can only be so good with this system, so I\'m not surprised that it didn\'t detect the higher point that you found located just west of my highest measured position. So what you\'re saying is you had to take over manual control and land manually to avoid a large boulder field? Looks like you might also have only had about 20 seconds of fuel left when you touched down... Zephram 'Neil' Kerman.

Awesome! Thanks for posting the screen shot. I\'m curious if you have enough fuel to fly 11 km? Your screenshot shows you at 133° 03\' W, 0°15\'S. My radar detected slightly higher peaks (2855 m) at 130°12\'W, 0°54\'N. By my figures that is 10.8 km away from your present location on a heading of 68°.

Constraining my search to between 1°N and 1°S, I get a maximum altitude of about 2855 m at roughly 130°12\'W, 0°54\'N. I got this number from the same data set that I used to make the map below. I\'d be interested to see a screen shot showing the terrain elevation at that location if someone wants to land there.

For comparison, I modified my mapping application to represent altitude in a gray scale rather than the colour scale that I used to make the maps that I posted above. Your map appears to use an Equidistant Cylindrical Projection so I also used that projection for my comparison map. The colour maps that I posted above, on the other hand, use polar stereographic and Mercator Projection. These two projections have less severe distortion than the Equidistant Cylindrical Projection, especially near the poles. The colour also increases the altitude resolution because gray scales are limited to a resolution of just 256. My maps have some slight artefacts that result from my altitude interpolation algorithm (I will work on improving the algorithm), but otherwise the two maps seem to be very comparable.

Impressive! I won\'t be beating that record. I\'ll just resign myself to last place in the turtle derby.

I think it is a good idea but maybe make it more specific? I posted a variation on this challenge a few months ago but not very many people participated. Maybe you can come up with a better idea than mine that increases the appeal?

I don\'t have a problem with that. In fact, you\'ve already got my source code for my radar altimetry module. I\'m also happy to make my data set available. The only issue is that it is quite large (upwards of 48 Mb) even in its binary format, so I hate to think how big it would be in .CSV format. I have over 2 million data points, but I can write a little application to convert that data into CSV format. I would just need to find a website where I could upload the converted file. PH.

Cool but I’m curious at what latitude? The Sun can already be seen to rise in the SW from an airliner on a generic mid-day, mid-winter flight from Europe to the NW coast of N. America (i.e. London or Frankfurt to Seattle, Vancouver, etc). Here on Earth you just need to cross more than 15° of longitude per hour to catch the Sun. Sub-sonic speeds are sufficient for that at high latitudes. I’ve seen it happen many times myself.

The transfer from 150 km up to 2868 km only takes about 1 hour and 25 minutes from PE to AP. I used the rest of the time en route between Checkpoint 1 and 2 to measure my spacecraft’s angular displacement from checkpoint 2 and to calculate the timing of my burn based on that angular displacement. The only tricky part (and this is why I used numerical integration to plan this burn) is that the angular position of the spacecraft\'s periapsis precesses eastward by about 7.3 degrees during the burn. (The amount of this precession varies depending on the thrust-to-mass ratio of the spacecraft so it won’t be the same for you.) This has to be taken into account because even just 0.1 degrees of angular displacement error at Checkpoint 2\'s altitude equals over 5 km of separation. For the rendezvous itself, I set my AP about 1 km higher than Checkpoint 2 to give myself a bit more 'hang time' at AP, then timed my circularisation burn to begin when Checkpoint 2 was about 8 km away. It was closing at about 400 m/s but a little grade 10 physics allowed me to work out that if I started my burn when it was about 8 km away, I\'d be up to the requisite 1009 m/s by the time Checkpoint 2 was nearing its closest approach. The calculations worked and it was just over 2 km way when I finished circularising my orbit at 2868 km. As for the transfer to the Mun, I waited until the Mun was 86 degrees ahead of my spacecraft at my altitude of 2868 km then boosted my AP to about 13300 km. (I timed this burn by recording the time that the Mun rose over Kerbin then calculating the time required from that instant until I was 86 degrees behind the Mun.) This burn results, upon crossing into the Mun\'s SOI, in a prograde hyperbolic trajectory with Munar PE of about 70 km.

Nice work and congratulations! Looks like you made up all of your time on the return to Kerbin and finish line rendezvous. My time to Waypoint 3 was 15 minutes faster than yours, but I then took over 10 hours to get from there back to Kerbin to rendezvous with the finish line.

Since (I\'m paraphrasing here) '4 shalt thou not count', should we also not have a rule five? After all, 'Five is right out'. In all seriousness though, if we\'re going to do this and make it 'official', then I think that the major features on the Mun and Kerbin should be named by some sort of poll. Names should also be tasteful. Naming rights to small features like mountains, depressions and small craters could be claimed by landing there but battles will inevitably occur if someone jumps in and claims naming rights to one of the major features. Should we define 'major feature' as any feature that is visible from a given orbital altitude? And while I\'m posting, I\'ll include links to my draft Munar topographical maps. I understand that another series of maps was created by a group of collaborators using the ISA RAM Satellite mapping module, but I haven\'t seen the results. I don\'t know what projections or resolutions they used in making their maps, but I could write an application to fuse the data from my radar mapping sensor with that of the ISA RAM mapping module (my data is binary, I believe theirs is ASCII text). For what it is worth, I used Polar Stereographic projection for the polar regions (50°N-90°N and 50°S-90°S) and Mercator projection for the mid-latitudes (75°S - 75°N). Also, for what it is worth, my Mercator I and Mercator II mapping Munar mapping missions found a maximum terrain elevation of 3315 m located near 70°06\'N, 52°18\'E in a region of mountains that I would like to call the 'Mercator Highlands'. The Mercator II probe found a minimum terrain elevation of 34 m in a prominent crater located near 8°12\'N, 35°42\'E.

After reading your response to my PM (thanks for that), I understand what you are getting at. What you told me there isn\'t clear from your post above though. What you are saying is that MechJeb orients the spacecraft perpendicular to its velocity vector throughout the burn. This causes the spacecraft to move in an approximately circular arc during the burn. (I say approximately because the ship\'s velocity is not constant along the undisturbed hyperbolic trajectory.) There is no effect on the magnitude of the ship\'s velocity (only the direction) as a result, and the specific orbital energy is unchanged. That being said, my point still stands. You are expending 80 m/s Delta-V to change the ship\'s direction of travel and including that 80 m/s in the results for the one case, but you are not including any Delta-V for mid-course corrections in the other case. Had the TMI burn for the two cases been executed slightly differently however, this 80 m/s Delta-V burn could have been eliminated. As I said in my post above, it is possible to achieve a Munar periapsis of 5 km through careful planning of the TMI burn. It is also possible to plan a Munar impact trajectory that starts from the same Kerbin orbit but that requires only very slightly different timing and/or Delta-V at the time of the TMI burn. As a result, I don\'t think it is an appropriate comparison to penalise one case with the Delta-V of a mid-course correction and not the other. The mid-course correction burn should either be ignored or averaged between the two cases.

While I agree with your conclusion that a low Pe landing is more efficient, I don\'t think you\'re making a fair comparison in your test. As I\'m sure you know, there are an infinite number of hyperbolic trajectories about the Mun that have a speed of 381 m/s at an altitude of 2000 km. The special case where Pe is 5 km is only one of those. When you make a burn to change that hyperbolic trajectory into a radial one, you are adding energy and the tests are no longer equivalent. We\'d really need to compare orbits that have the same initial specific orbital energy. Given that it is possible with careful planning to target your Munar Pe merely by adjusting the timing of your TMI burn (or at most with miniscule differences in TMI Delta-V), I don’t think it is fair to include significant mid-course orbital corrections in your comparison.

Yes! Thanks for all your work putting it together. It was one of the best that I\'ve done. It was a bit of a marathon challenge but that added to the enjoyment. Between all of calculations, manoeuvring and real-life distractions, it took me most of a week to finish. But that added to the enjoyment; it introduced a level of anxiety where, after all the work you\'ve done, you don\'t want to screw up the next stage of the mission. As for a suggestion for future challenges? What about a 'scramble'? So far, most of us have concentrated on getting around the main race course, while ignoring the bonus waypoints. What if you were to put up waypoints in a variety of orbital inclinations and altitudes (maybe even one or two in elliptical orbits) and let players decide which order to do them in? The only condition would be that they\'d have to rendezvous with all of them before returning to the finish. Maybe also keep it to three or four waypoints?

Well here\'s my entry. I managed 1 day, 2 hours, 14 minutes and 53 seconds with my 'Ker-Blue I' rocket. I used the 'Lite' persistence file because my computer isn\'t powerful enough to load the waypoint rings of the standard file and still maintain any sort of useable frame rate. I think I could have shaved a bit more time if I\'d dropped back down to low Kerbin orbit after Waypoint 2 to fly my trans-munar insertion from there. As it was, I had to wait about 4 hours between rendezvousing with Waypoint 2 and my TMI. I also could have shaved a few minutes getting to Waypoint 1 if I\'d launched right way rather than fiddling around taking screen shots. And it sounds like I used a different method than the rest of you for planning my orbital transfers. I used patched conics when planning my TMI and TKI burns, and I used very slightly eccentric parking orbits (i.e. circular ± about 0.5 km - just enough so that the PE and AP icons don\'t wiggle) to time my transfers from those parking orbits to the three waypoints. To do this, I recorded the times that the target and my spacecraft transited the major axis (i.e. when the PE, AP and target or spacecraft were lined up). I then calculated the time of my burns so that I\'d intercept my target at apoapsis/periapsis. The standard 2-body equations were all I needed for planning rendezvous with all but waypoint 2. I used numerical integration when planning my transfer to Waypoint 2 because the angular error introduced as a result of the non-instantaneous delta-V is significant. I expected that I\'d have to resort to trial and error (or a time consuming intermediate orbit) for this transfer if I assumed instantaneous delta-V. Here are my screen shots: [img width=800 height=590] http://i.imgur.com/zx2U0.png Edit: Fixed a broken link to first screen shot.

I agree. I don\'t like to use the automated controls. I don\'t even use SAS or ASAS on my rockets unless a stage has some quirk that makes it difficult to hand fly. By my own personal standards, I consider it something of a design flaw if I need to add automated controls to make my rockets flyable. I also enjoy the challenge of making do with the existing instrumentation. You can do a lot with just the navball and map view. You just need to use the information that they provide to do your own calculations. I enjoy that challenge. While I\'m no longer an engineering student (I graduated to the 'real world' long ago), I find that I miss the academic stimulation of university. For me, KSP provides a learning opportunity and a technical challenge that keeps me hooked. Tools like MechJeb or better instruments would diminish that for me. PH.

I was initially excited about this challenge, but I couldn’t get through it without lagging out my system. I tried it a couple of weeks ago and managed to get as far as the geosynchronous waypoint, but my little netbook doesn\'t have the horsepower for this challenge. My frame rate drops to ~0.5 Hz when I get close to the waypoints... Any chance of creating a variation of your challenge for those of us running slower PCs? Or am I just an anomaly?

Well, the Kerbal equivalent of the Canadian Space Agency (we\'ve got lots of ambition but only limited funding) has managed to beg/borrow/steal some processing time on a faster computer over the past couple of weeks, and I\'m proud to announce the successful completion of the Mercator I mission to map the Mun. I designed a custom terrain elevation measurement radar and loaded it into a Silisko Industries\' Probodobodyne Sensor Pack, then assembled the Mercator I probe using more Probodobodyne parts. I then flew the Mercator I probe on a mission to collect terrain elevation data from three different orbital inclinations (60°, 75° and 90°) over the course of about 5 days in orbit (about 10 days real-time). During that time, I developed an application to process and map the data: Link to full size map image The map above was generated by interpolating the raw data shown below: I\'m confident that the interpolation algorithm yields reasonably accurate results. During development of the mapping application, I tested my interpolation algorithm by interpolating the pixels in the middle image below to generate the image on the right. (Note that I interpolated altitudes rather than colours to generate the map.) The image on the left is the reference image. The closer the image on the right matches the image on the left, the better the interpolation algorithm is working: There is still some room for improvement in the interpolation algorithm and there are also still some voids in the raw data. I plan to fly another mission to fill in more of the data voids and I am experimenting with better interpolation methods as well. While I\'m at it, I will also revise the mapping application to generate a few other map projections. In its current incarnation, the mapping software generates an equidistant cylindrical projection map, but there are other projections that are more appropriate for different regions of the Mun\'s surface (like a polar stereographic projection for the poles). In recognition of this mission, I would like to propose to the Kerbal Geographic Society that the Munar highlands located near 70° 06\'N, 52° 18\'E be named the 'Mercator Highlands'. The Mercator I probe detected peaks as high as 3315 m in that region. PH. Edit: Corrected a typo.