marcnesium-iv

Thank you all very much for your input! I'll try it in the next days as I'm quite busy right now. Edit: It seems the main problem was the mining equipment not directly attached to the convert-o-tron, as mentioned by bewing. Thanks again for the help!

Hi everyone, I'm currently trying to do a manned mission to Eve and back. My lander (see picture below) is a simple asparagus rocket on top of some sort of launch platform. Below the platform was a rover attached which is not shown on the picture. In order to safe mass my plan was to bring an empty ascent rocket and fill it up using some ISRU equipment on the launch platform while the rover collects some science. However, the ISRU equipment does not seem to work. In particular my setup consists of: 2 x Drill-O-Matic 2 x Convert-O-Tron 125 2 x Radial holding tanks (on the vertical beams below the Convert-O-Tron's) Radiators, batteries and solar panels The fuel was then supposed to be transported into the 1st stage of my asparagus staging via the fuel duct and from there transported successively to the inner stages. First question: Can this fuel transport work in principle? The Drill-O-Matic's show an ore rate of 0.01/s which seems pretty small, but the ore tanks don't fill above a few mg (yes, mg). The Convert-O-Tron's display "inactive". As you can already see, I have a few mods installed (game version 1.8.1) - most notably for this problem are KSPI-E and SCANsat. The SCANsat scans of Eve show not really much ore overall, but the region where I landed should have an ore concentration of ~1%. Does it just take really long to mine the necessary ore or am I missing something else here? Thanks already for your help!

Thanks for your input! engine.max_thrust seems to be independent from the throttle. But, as you expected, I can confirm now that toggling the engine is instantaneous-- at least in most cases. Sometimes (in my case 3 times out of 50) it takes one tick to activate the engine. So for my code I'll use your method. What I also noticed is that the throttle lever animation is not completely locked to the actual throttle. When I did my previous measurements (throttle 0.0 -> 1.0 -> 0.0) the lever would go only up to 50% and then down to zero.

Thanks for your replies! I should have been more specific: I only look at rocket engines right now. In the meantime I also realized that I should be able to actually measure the time it takes using a small KRPC script. The script waits until I click a button. It then sets the throttle to 1.0 and waits until it actually is 1.0. Finally, it prints the time difference to the console. Here is the code: This time difference is always 60 ms! I guess this is exactly 3 physics ticks as the in-game time ut() increases in steps of 20 ms. Is this plausible to you?

I'm trying to code a precise script using the KRPC API and was wondering (as the title says) if there is any throttle ramp-up time? So how long does it take from setting the throttle to 1 to actually having that throttle? I guess at maximum it is on the scale of a few physics ticks but at mun orbital speed a tick are already 20 m.

I would not have thought that it was possible to decrease the computation time much more. Today I simulated over 30 suicide burns and optimized the parameters. I'm now at 5 seconds computational time! As I promised I also made a video of one of these landings. In the beginning my lander is in a circular 40 km orbit with a inclination of 15° around Mun. My script is not capable of landing at a specific site as this would include another optimization step. So you have to perform your own deorbit burn. As you can see I chose a comparably flat descent trajectory, however, any trajectory should be fine as long as it is suborbital. And of course you should have enough time left to slow down. Then I started the script in the console. The output shows how the optimizing algorithm is converging. "t_burn" (the time until the start of the suicide burn) is changed until the "altitude" (at the end of the suicide burn) is slightly positive. In my script I set an offset of 20 m, but for larger ships this should also be larger. After 4.6 seconds the calculations are finished and we get the parameters of the final trajectory. The ship orientates itself and warps to 10 seconds before engine ignition (or t_burn-10). The SAS is set to retrograde (relative to surface!) and we wait for the burn. Well... and then comes the burn. About 20 m above ground we reach close to zero velocity and the MechJeb untargeted-landing autopilot is activated for the last few meters. If you compare the console output of the calculated coordinates ("final coordinates") and the actual landing coordinates, we see that we are pretty much where we expect to be. Hope you liked it!

UPDATE The calculations now take less than 1 minute! I had two ideas this morning and just implemented them. The calculations are now much faster and in the order of 45 seconds. Unfortunately, the calculations are not that precise anymore and I don't know why but I'll look into it. I'll also try to make a video in the next days so you get an idea what it looks like. Since the calculations are now that fast I can use my script as a live autopilot without pausing the game.

Hello everyone! I'm a casual KSP player and new to this forum. Recently I finished a project which I wanted to share with you. So I saw one of those graceful Falcon 9 booster landings and thought about doing the same in KSP. I stumbled across calculations for the simplified version of a vertical suicide burn but that was not satisfying to me. Basically, it's just simple mechanics so that problem cannot be that hard, right? Turns out it is also not that easy. After a week I was finally convinced that there is no easy analytical solution, but I had an idea on how to tackle that problem. I found the mod KRPC which gives me the possibility to control KSP with a Python script. And in that Python script I can do all the unholy things I need for a suicide burn... What my program does is to evaluate the equations of motion (EOM) of a rocket burning retrograde in a gravitational field numerically. This works pretty good and in the end the autopilot stops my rocket 10 m above the ground within a few meters of the predicted landing site. However, this comes at a cost: The calculations take about 5 min. Unfortunately, Python is not the most efficient programming language but the only one I'm proficient in. But it works! And if you want to try it for yourself here is the code: https://github.com/marcnesium-iv/SuicideBurnAutopilot It requires Python 2.7, the Python packages numpy, scipy and krpc, and the KSP mods KRPC and MechJeb2. It should also be fairly easy to translate the code to Python 3.x -- just change print and xrange. Actually I hope that some of you will test it because there are still some minor bugs in it (no critical ones) and it's not that much tested. I wrote a small paragraph about the usage on the github page. The code should also be understandable since I left quite some comments in there. The basic algorithm looks like this: The EOM first describes a coasting phase until the time t_burn and then the suicide burn. The scipy.integrate.solve_ivp function evaluates the EOM for a given t_burn until either the rocket crashes into the planet or it slows down to zero. scipy.optimize.minimize now tries to optimize t_burn, so the rocket stops at the end of the burn right at the surface. The main bottlenecks are the functions which determine the velocity and the altitude as both have to use KRPC functions which prevents me from using efficient numpy stuff. As I already said: It works but is not very efficient. If you have any ideas on how to speed this algorithm up, please let me know! Also all other kinds of feedback is very much appreciated. :)