[PART, 1.0.2] Anatid Robotics / MuMech - MechJeb - Autopilot - Historical thread

[BigD145]

Learn to do it the old fashioned way. It's not that hard. Maneuver nodes work well.

[AndreyATGB]

What you do is wait for it to be in the SOI and launch in the same, or close inclination. If the inclination difference is big, more than a say 5-10 degrees, then burn prograde at one of the nodes and bring the apoapsis around the orbit of the asteroid. You then add a second node and fix the inclination with it, now you can change the time of the first one so that you have a relatively close approach (same side of the planet basically) and tune it from there. It should be easy because at such an elliptical orbit, tiny changes in the apoapsis will severely affect your closest approach. It really isn't that difficult.

[Kaa253]

... It just whiffs right on by. Any new advice?

After you plot and execute the MJ fine tune to intercept then you need to use MechJeb's Maneuver Planner to "match velocities with target", Schedule the burn "at closest approach to target". Yes? i.e. slam on the brakes!

You must know that... scratches head... I am not sure what you are describing. OK maybe this... When you have killed your relative motion with the asteroid and you are still 27 km away then use "intercept target at chosen time" say 600 seconds after the burn? and then match velocities again. If you are still too far away then repeat.

Edited May 7, 2014 by Kaa253
trying to imagine what new advice might be helpful

[Kaa253]

I am having a strange failure with calculating Hohmann transfers from LKO to the Mun. It is targeting off by about 120 degrees retrograde in the Mun's orbit.

It has happened to every craft for a few days now. I have regularly been updating MechJeb. Screenshot is #242. First appearance of the problem was noted at #238, I think. I skipped #234 which the changelog says touched the Hohmann calculations. Is it only with my heavily modded install? Has no-one else seen this?

All other Hohmann transfers seem to be working perfectly. It is only the Mun!!!

It is as if the Mun is out of position with the Astronomical Almanac.

I know I have been moving a bunch of rocks around, but I think I would remember if I had moved the Mun

If it is only on my overloaded install (Linux 64) then no matter, I can easy just slide the node around on the LKOrbit until it intercepts properly.

[BARCLONE]

Throwing my $0.02 into the hat...

Concerning the ARM, I think everyone has developed their own "touch" to solving the challenge. The method I've been using recently saves a snoot full of Dv compared to earlier attempts, so I consider this to be my "better method"...

1. LKO -- I generally launch to an equitorial orbit of 200km. The AGAP is your friend here, as long as the gimbal range of your engines can handle the corrective movements. My larger beasts were cartwheeling until I adjusted their ranges (I use Tweakable Everything to do this).
   
2. Escape burn -- Do a 900 m/s burn to escape Kerbin SOI. You can't do anything until you're away from Kerbin's influence. I use the node editor for this, as I can not only set the burn value, but I can adjust the start time to "fine tune" the path. Usually, I either tweak the time so that the escape path lines up with Kerbin's path, or points outbound in the general direction of the asteroid.
   
3. Intercept Target At Designated Time -- Select a time about 1 day past the SOI escape point as the burn time, and calculate an intercept about 2 days ahead of the asteroid's encounter. If you do this early, it often takes less than 200 m/s of Dv to reach the intercept point. The farther away you do this burn, the less you have to burn.
   
4. Hardest action you'll have to take -- WAIT for the intercept. Don't get cute, don't try to adjust the closest approach distance, just be patient. Time warp is suggested.
   
5. Match Velocity At Closest Approach -- No explanation needed here. You don't want to overshoot.
   
6. Smart A.S.S. -> TGT -> TGT+ -- Point yourself directly at the target and burn. At the start of this burn, you should be well inside 1000km, probably within 600km, and maybe even closer. You might even be able to see the target, but if not just "point and shoot". You need only about 100 m/s here at best as a closing rate. As soon as the burn gets you that rate, shut it down, flip to TGT- and wait until you see the target show up. Burn short spurts to kill the velocity down to zero until you're inside 5km.
   
7. Rendezvous AP -- Set a distance about 75-100m, and per earlier recomendations, set a reasonably high number of "orbits" (30-50), then engage. RAP should get you right up to the asteroid from here, especially if you've worked yourself to within 5km of the asteroid.
   

All but one of these steps uses a MJ autopilot. While each asteroid intercept is a bit different, I've found that catching it about 2 days ahead of the encounter works far better than waiting for the asteroid to enter Kerbin SOI to go up and try to rendezvous. Also remember, each of these steps might need a little tweaking as to time, direction, or duration of burn, so this is not a "chiseled in asteroid stone" method. It does represent what I've generally found gets the job done.

Edited May 7, 2014 by BARCLONE

[mario.masters]

I am having a strange failure with calculating Hohmann transfers from LKO to the Mun. It is targeting off by about 120 degrees retrograde in the Mun's orbit.

http://i.imgur.com/gxo0Q3i.png

It has happened to every craft for a few days now. I have regularly been updating MechJeb. Screenshot is #242. First appearance of the problem was noted at #238, I think. I skipped #234 which the changelog says touched the Hohmann calculations. Is it only with my heavily modded install? Has no-one else seen this?

All other Hohmann transfers seem to be working perfectly. It is only the Mun!!!

It is as if the Mun is out of position with the Astronomical Almanac.

I know I have been moving a bunch of rocks around, but I think I would remember if I had moved the Mun

If it is only on my overloaded install (Linux 64) then no matter, I can easy just slide the node around on the LKOrbit until it intercepts properly.

Got RSS installed? Or at least a part of it which came with another mod?

[Kaa253]

Yes. I do have a part of it. The RealSolarSystem.dll and a configuration script that changes atmosphere appearance, hopefully, that's all. As you say, they came with another mod.

[Tassyr]

Throwing my $0.02 into the hat...

Concerning the ARM, I think everyone has developed their own "touch" to solving the challenge. The method I've been using recently saves a snoot full of Dv compared to earlier attempts, so I consider this to be my "better method"...

1. LKO -- I generally launch to an equitorial orbit of 200km. The AGAP is your friend here, as long as the gimbal range of your engines can handle the corrective movements. My larger beasts were cartwheeling until I adjusted their ranges (I use Tweakable Everything to do this).
   
2. Escape burn -- Do a 900 m/s burn to escape Kerbin SOI. You can't do anything until you're away from Kerbin's influence. I use the node editor for this, as I can not only set the burn value, but I can adjust the start time to "fine tune" the path. Usually, I either tweak the time so that the escape path lines up with Kerbin's path, or points outbound in the general direction of the asteroid.
   
3. Intercept Target At Designated Time -- Select a time about 1 day past the SOI escape point as the burn time, and calculate an intercept about 2 days ahead of the asteroid's encounter. If you do this early, it often takes less than 200 m/s of Dv to reach the intercept point. The farther away you do this burn, the less you have to burn.
   
4. Hardest action you'll have to take -- WAIT for the intercept. Don't get cute, don't try to adjust the closest approach distance, just be patient. Time warp is suggested.
   
5. Match Velocity At Closest Approach -- No explanation needed here. You don't want to overshoot.
   
6. Smart A.S.S. -> TGT -> TGT+ -- Point yourself directly at the target and burn. At the start of this burn, you should be well inside 1000km, probably within 600km, and maybe even closer. You might even be able to see the target, but if not just "point and shoot". You need only about 100 m/s here at best as a closing rate. As soon as the burn gets you that rate, shut it down, flip to TGT- and wait until you see the target show up. Burn short spurts to kill the velocity down to zero until you're inside 5km.
   
7. Rendezvous AP -- Set a distance about 75-100m, and per earlier recomendations, set a reasonably high number of "orbits" (30-50), then engage. RAP should get you right up to the asteroid from here, especially if you've worked yourself to within 5km of the asteroid.
   

All but one of these steps uses a MJ autopilot. While each asteroid intercept is a bit different, I've found that catching it about 2 days ahead of the encounter works far better than waiting for the asteroid to enter Kerbin SOI to go up and try to rendezvous. Also remember, each of these steps might need a little tweaking as to time, direction, or duration of burn, so this is not a "chiseled in asteroid stone" method. It does represent what I've generally found gets the job done.

Gonna try this tonight. Thanks.

[Toyotawolf]

So just a question, and please I don't need all the "you shouldn't use mechjeb to do that" or "stop being lazy". All I want is whether it works and if the numbers I'm seeing are correct.

First off I am trying to get to Duna or Eve using mechjeb, is this possible?

Secondly when I get into Kerbin orbit at 100pe x 100ap and I select "transfer to another planet" and select Duna, I get a maneuver node anywhere from 33yrs off to 88yrs off.... Is that normal or am I missing something mundane?

[Red Iron Crown]

So just a question, and please I don't need all the "you shouldn't use mechjeb to do that" or "stop being lazy". All I want is whether it works and if the numbers I'm seeing are correct.

You won't get any of that in this thread, we're all MechJeb users here.

First off I am trying to get to Duna or Eve using mechjeb, is this possible?

Secondly when I get into Kerbin orbit at 100pe x 100ap and I select "transfer to another planet" and select Duna, I get a maneuver node anywhere from 33yrs off to 88yrs off.... Is that normal or am I missing something mundane?

No, that's not normal, your transfer window shouldn't be more than 2 years away, tops. I mean this respectfully, but are you sure you are reading the time to maneuver node correctly? It's not the # of days away you are reading?

[daawgees]

Got RSS installed? Or at least a part of it which came with another mod?

I noticed this when I installed Better Atmospheres along with EVE. Only happened with Mun, once I removed BA everything seemed to work normally again. Guess I should have removed that RSS .dll that was packaged in with BA and I would have been fine. D'oh!

[BARCLONE]

Gonna try this tonight. Thanks.

I just tried it again as a test, and the initial burn was just under 600 m/s, so keep in mind what I said about every rendezvous being different. I also had to burn twice to reach the rendezvous point. My first burn took me out just far enough to get an encounter with Mun, and it threw me way inside the orbit of Kerbin. The second burn was over 1200 m/s, but my closest approach numbers are looking great at this point.

ADDENDUM: At the start of the velocity match, I was only 470 km from the asteroid.

Sometimes you might need to burn to the inside of the orbit to get a better starting point, instead of to the outside. Watch out for unexpected encounters when you set up the initial burn, and don't be afraid to try another approach vector before hitting the "execute" button.

Edited May 7, 2014 by BARCLONE

[Galane]

Anyone else having issues with Auto staging the last few builds? Build 236 would immediately stage any boosters I had loaded but worked normally once that happened (or perhaps it just staged once immediately upon launch). Build 240 is just running non-stop through the staging leaving me to my last module only seconds after launch.

If you have any engines in a stage that does not have an inline or radial decoupler in the same stage, MechJeb may light those engines at the same time as engines in a lower stage - even though if you stage manually the engines fire in the sequence you want.

The easiest way to see this is to make a simple rocket with a couple of small SRBs with a decoupler between them. Put a Stayputnik on top for remote guidance and four Sepratrons around the upper SRB. Put the lower SRB in the lowest stage (2), the decoupler and upper SRB in the middle stage (1) and the Sepratrons in the top stage (0).

Launch with auto staging and a fraction of a second after the first staging and lighting the upper SRB MechJeb will light the Sepratrons instead of waiting for the upper SRB to burn out. If you're doing manual staging, those Sepratrons won't light until you hit the space bar.

Currently the options with such cases are

1. Stage manually while Ascent Guidance controls steering and throttle.

2. Set the auto staging limit to one number below the stage where MechJeb won't follow how manual staging works. You will then have to trigger the staging after that point manually, which will happen in the order you've built it.

3. Redesign your rocket to include an inline or radial decoupler *icon* in every stage with an engine.

Try placing a couple of the small radial decouplers on the lower SRB (which is in stage 2) and their icons in stage 0 with the Sepratrons, then launch with auto staging set to 0. Also try stacking two inline decouplers between the SRBs but put the icon for the lower decoupler in stage 0. If you put the upper decoupler in stage 0 it will block the thrust of the upper SRB because it won't trigger and drop off until the upper SRB burns out.

Edit: Tried it and that doesn't stop it. The decoupler with the engines you don't want to light prematurely has to stay with the rocket.

MechJeb does not seem to have any issues flying a rocket with decouplers that will be discarded before they can be triggered because they're not physically attached to any component in the stage their icons are placed into.

Edited May 8, 2014 by Galane

[mario.masters]

Yes. I do have a part of it. The RealSolarSystem.dll and a configuration script that changes atmosphere appearance, hopefully, that's all. As you say, they came with another mod.

I noticed this when I installed Better Atmospheres along with EVE. Only happened with Mun, once I removed BA everything seemed to work normally again. Guess I should have removed that RSS .dll that was packaged in with BA and I would have been fine. D'oh!

The RSS seems to be the problem for the new transfer orbit logic. I reported this while back however it doesn't seem to me like a MechJeb problem. In my case I got RSS with Better Atmospheres mod which only sets the AtmosphereFromGround wave length I think, however behind the scenes RSS does many changes to the planetary bodies from what I was able to see while reading the code. I figured sometime to go back and see what exactly might be the problem but I never got around to it (RL and a tiny fact that I'm new to the game and its API etc). Anyway if you got your RSS with better atmospheres you should be able to safely delete it as it's only a cosmetic change (it's intended to remove the white atmosphere from Kerbin IIRC). If you have the know how you could fork the RSS and make necessary source code adjustments for your own personal use. From what I remember you could potentially safely comment out everything not related to the wavelength and atmospheres from ground in the code (RealSolarSystem.cs and Watchdog.cs IIRC) and recompile. You could never of course have the real RSS installed obviously with your personalized forked copy .

So just a question, and please I don't need all the "you shouldn't use mechjeb to do that" or "stop being lazy". All I want is whether it works and if the numbers I'm seeing are correct. First off I am trying to get to Duna or Eve using mechjeb, is this possible? Secondly when I get into Kerbin orbit at 100pe x 100ap and I select "transfer to another planet" and select Duna, I get a maneuver node anywhere from 33yrs off to 88yrs off.... Is that normal or am I missing something mundane?

I don't suppose you as well have RSS installed in some "form"?

[Toyotawolf]

You won't get any of that in this thread, we're all MechJeb users here.

No, that's not normal, your transfer window shouldn't be more than 2 years away, tops. I mean this respectfully, but are you sure you are reading the time to maneuver node correctly? It's not the # of days away you are reading?

I'll double check once I am home

And to Mario.masters, no I don't have RSS installed, my solar system is all stock.

I'll also list what mods I have once I get home, but most of my mods are parts mods, no real game changers.

Edited May 7, 2014 by Toyotawolf

[mario.masters]

I'll double check once I am home And to Mario.masters, no I don't have RSS installed, my solar system is all stock. I'll also list what mods I have once I get home, but most of my mods are parts mods, no real game changers.

RealSolarSystem. EDIT: Saw you edited your post. There are mods out there which provide some cosmetic changes to the planetary bodies without turning your system into a Sol System that is . However these mods provide the RealSolarSystem.dll as well. Edited May 7, 2014 by mario.masters

[sarbian]

So just a question, and please I don't need all the "you shouldn't use mechjeb to do that" or "stop being lazy". All I want is whether it works and if the numbers I'm seeing are correct.

First off I am trying to get to Duna or Eve using mechjeb, is this possible?

Secondly when I get into Kerbin orbit at 100pe x 100ap and I select "transfer to another planet" and select Duna, I get a maneuver node anywhere from 33yrs off to 88yrs off.... Is that normal or am I missing something mundane?

What version do you use ? The_Duck changed things in the last few build that may impact those. Maybe he broke something.

I just did a version on my development install and it gave me a node in 157 days. I used dev #240 and no other mods.

[Toyotawolf]

What version do you use ? The_Duck changed things in the last few build that may impact those. Maybe he broke something.

I just did a version on my development install and it gave me a node in 157 days. I used dev #240 and no other mods.

Hehe good ole sarb, long time no chat, I'm using the version that is on the spaceport right now, that much I do know.

[sojourner]

Always update to the latest dev build before posting a problem.

[BARCLONE]

Dev 243...

Sarbian and Duck,

I think I might be starting to understand what the connection is between the navball drift and the low-thrust region of the engines. The navball is keying off of the torque stabilization, and that value is falling when the engines tail off. In essence, the navball is basing its thrust vector off of the maximum available torque, which is OK while the engines are running above a certain throttle value. But when the engines tail off, so does the maximum torque, and thus, so drifts the thrust vector.

I haven't tested this by using the "Stock SAS" setting, but since this appears to be a dynamic action, and the torque is a calculated value based on engine power, I think it makes sense.

Thoughts?

[Toyotawolf]

So I just plotted a transfer to Duna and it came out at 1 year and 301 days, is that normal?

Mods installed:

Latest Dev MJ2

Nova Punch 2

Final Frontier

DmAgic Orbital Sience

Magic Smoke Industries

Wolf Pack Aeronautics

KW

Kethane

HL Labs

KAX

Tyberdyne

[OrbitalDebris]

RPM 0.16 update for dev build 243 posted at the usual spot

[BARCLONE]

So I just plotted a transfer to Duna and it came out at 1 year and 301 days, is that normal?

Mods installed:

Latest Dev MJ2

Nova Punch 2

Final Frontier

DmAgic Orbital Sience

Magic Smoke Industries

Wolf Pack Aeronautics

KW

Kethane

HL Labs

KAX

Tyberdyne

The time doesn't seem all that out-of-whack, really. It depends on where Kerbin is at the time you leave LKO and get to the escape point. Think about how RAP plots the intercept for ships in orbit around Kerbin, or Mun. If you're located in the "sweet spot" of being slightly behind and at a lower orbit relative to the target, then your time-to-intercept will be a lot shorter than if you have to travel "around the block" a time or two to set up for the burn.

It sounds like you were "ahead" of Duna when you plotted the burn.

[BARCLONE]

Physics bug!

I'm trying to connect to a class-E asteroid, and the physics engine is stuttering whenever I get inside 200m. It's so bad, I've several times found myself traveling through the asteroid (without damage). Now, it may be due to my having a high-parts-count grabber, with a mass of over 136t...

Looks like a fish, steers like a cow....

I don't think MechJeb has anything to do with this problem, but I thought you'd like to hear about it.

[Kaa253]

Thanks mario.masters and daawgees for your great help. I will remove the RSS dll and I expect that will fix the Mun (sounds like it really is the Mun that is effected and not MJ, lol). +Rep to you both.