Jump to content

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


r4m0n

Recommended Posts

Not meant to flog a dead horse here, but my post earlier about the ARM maneuver needed an update:

  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. More often than not, just burning such that the path winds up 90-degrees outbound from Kerbin will be sufficient for most rendezvous.
  3. OPTIONS:
    • Intercept Target At Designated Time -- If your probe does not have a close approach already on the map view, use this option. 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 700 m/s of Dv to reach the intercept point. The farther away you do this burn, the less you have to burn.
    • Fine Tune Closest Approach -- If you see that your probe already has a reasonably close approach with the asteroid, then try this maneuver instead. Set the approach distance to anywhere from 100 - 300 km (I use 200 km) and trigger the burn at wherever the map view says you currently have closest approach. FTCA will narrow the gap, not always in your range, but well inside 1000 km. Close enough. This maneuver is often less than 300 m/s of Dv.

[*] Match Velocity At Closest Approach -- No explanation needed here. You don't want to overshoot. Use auto-warp.

[*] 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. Get closer if you dare, but don't overshoot.

[*] Rendezvous AP -- Set a distance-to-target of 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.

As I mentioned before, using this sequence gets me consistently to the asteroid without using excess amounts of Dv. Each step requires the use of a different MechJeb autopilot, so it's well worth playing with even as a teaching tool.

Edited by BARCLONE
Link to comment
Share on other sites

Gotta quick question for Sarbian, or any other MJ dev/contributor who may have worked on this part of the code - how does MJ calculate planetary transfer windows, and how does it compare to the way, say, Kerbal Alarm Clock does it?

The reason I'm asking is this: I've spent the last several in-game days staging the components of a multi-part mission to Laythe in medium-Kerbin orbit. I docked the last segment last night, topped off fuel and monoprop in all tanks and components, and then asked MJ to plot a transfer burn to Jool. MJ gave me a burn of about 1930 m/s roughly 6 hours from the time I requested. By contrast, KAC tells me the window to Jool begins in about 66 DAYS. I decided something wasn't right here so I returned to the Space Center and quit the game. I reloaded it this morning and just for grins, I deleted the planned maneuver node and told MJ to calculate it again. This time, I got an estimated burn of ~1907 m/s but in 54 days rather than 6 hours. That's still 10 days sooner than KAC's alarm but at least within the range of reasonable if we presume KAC's alarm is an idealized lowest-energy trajectory point in the window.

I know you guys have bigger fish to fry in the MJ world but any insight is appreciated.

LameLefty : I can't help much with that. I did not write that part and it's a bit complex. I can tell you that KAC use a different method since I had a look at the code and the flow if quite different. I may have a shoot at it later but The_duck know that part better than I do. I know that http://alexmoon.github.io/ksp/ do a great job at finding the correct time too, so I may look at how it does it too if I get myself to look into that part of MJ code.

falken : no and not yet

Link to comment
Share on other sites

LameLefty : I can't help much with that. I did not write that part and it's a bit complex. I can tell you that KAC use a different method since I had a look at the code and the flow if quite different. I may have a shoot at it later but The_duck know that part better than I do. I know that http://alexmoon.github.io/ksp/ do a great job at finding the correct time too, so I may look at how it does it too if I get myself to look into that part of MJ code.

Actually, KAC itself has two methods it can use to calculate a transfer, which yield different times: Formula and Model. You toggle them with a radio button on the 'transfer alarm' page. Mechjeb's transfers generally seem to end up close to one or the other of them, but which isn't consistent. I'm guessing that each method in KAC varies in accuracy and particularly efficiency, and that Mechjeb's using a more sophisticated and detailed method that's both more accurate and more relevant.

Mechjeb's also accounts for the ejection angle you need and thus where your craft will be in its orbit when the window arrives, to some extent or another, which I'm pretty sure KAC's alarms don't do at all. KAC seems to just note when the planets are in the right position relative to each other. Back before the fix that made mechjeb always find the first transfer window, I twice tried to use KAC's alarms to execute the burn manually out of sheer frustration. One time it worked okay-ish. The other it sent me in the exact opposite direction from where I needed to go. I was on point of re-downloading protractor for the first time since before Mechjeb 2 came out when the fix went in on the dev version.

Edited by Tiron
Link to comment
Share on other sites

Is there any way for me to take control of the throttle on the ascent guidance? Also, any way to force a roll during ascent guidance?

You can set throttle limits. That's about it.

No roll specification for the launch AP. Be nice if one existed but it does not.

Link to comment
Share on other sites

So here is a funny thing that happens, and yes i have the latest mechjeb,

When i dock with a craft all of a sudden all the RCS thrusters kick on full blast and the things spins wildly, i use Smart ASS to stop it but then its just station keeping with the thrusters at full blast until i shut the feeds off from the RCS tanks....thoughts?

Link to comment
Share on other sites

So here is a funny thing that happens, and yes i have the latest mechjeb,

When i dock with a craft all of a sudden all the RCS thrusters kick on full blast and the things spins wildly, i use Smart ASS to stop it but then its just station keeping with the thrusters at full blast until i shut the feeds off from the RCS tanks....thoughts?

That's actually the docking autopilot staying 'on', or active, after docking, as though the (now conjoined) ship is still trying to dock with something. If you close the docking AP window, that shuts it off. Then you can re-open the window with no problems. It doesn't do it to me all the time, but it happens frequently enough that I always hover my mouse over the 'close window' button as it's just about to dock, just in case. Then, if I see or hear (I have the RCS Sounds mod) the RCS system firing after docking, I'm ready to shut it off.

I hope this helps. :) I think this has been this way since sometime around when 0.23.5 came out, but I'm not sure. It's been a while, though.

Anyway, rotsa ruck! :D

Link to comment
Share on other sites

Is there any way for me to take control of the throttle on the ascent guidance? Also, any way to force a roll during ascent guidance?

I know others have answered, but here's my 2 cents. :)

Throttle, no, other than setting a max throttle percentage or limiting to a given acceleration or to terminal velocity using the ascent guidance window.

But as for rolling, your manual controls should still work for that. I do it all the time, just manually roll my ship to where I want it. It doesn't always stay steady, sometimes it drifts a bit so I need to add periodic corrections, but I don't mind. :)

I hope this helps. :D

Link to comment
Share on other sites

Is this a bad thing or what?

[ERR 17:14:50.860] MechJeb moduleRegistry creation threw an exception in LoadComputerModules loading ExsurgentEngineering, Version=1.0.5040.39249, Culture=neutral, PublicKeyToken=null: System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.

at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (bool)

at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0

at MuMech.MechJebCore.LoadComputerModules () [0x00000] in <filename unknown>:0

Showed up in the logs while the game was loading. MechJeb2 v2.2.1.0 was used

Link to comment
Share on other sites

I have an interesting problem where MechJeb is setting up my Hohmann transfers to the Mun with the proper dV but making the node early. If I shift the time forward in the node editor I get a decent transfer. But by default, it creates a node ~10 minutes early. Any insight would be helpful.

edit:Just deleted mechJeb and reinstalled using 246. Problem still here. Is there config files/lines I should delete/modify to figure this out?

edit edit: I just reverted to 2.2.1 (non-dev) problem does not exist in it. Seems that it is a dev version bug. Will be happy to provide any necessary debug or screenies for troubleshooting.

Edited by akherber
Update
Link to comment
Share on other sites

I did with every reinstall. The problem exists on fresh installs of the Dev versions. At least with Dev 240-246. I didn't install any before that to see if they have the same issue. The issue is not present in the stable 2.2.1.0 Release.

A question: Are there other mods that may affect this? Doesn't seem like there should be for a calculation like this.

If there is no insight I will do a clean install and start attempting to isolate variables and see what I can find.

Edited by akherber
Link to comment
Share on other sites

I did with every reinstall. The problem exists on fresh installs of the Dev versions. At least with Dev 240-246. I didn't install any before that to see if they have the same issue. The issue is not present in the stable 2.2.1.0 Release.

A question: Are there other mods that may affect this? Doesn't seem like there should be for a calculation like this.

If there is no insight I will do a clean install and start attempting to isolate variables and see what I can find.

What mods do you have? There was a similar problem being caused by the RSS mod. Even if you don't have RSS, other mods sometimes contain the RSS dll file.

Link to comment
Share on other sites

Well my first instinct was to say "I don't have RSS" but there it is. So now I need to figure what mod has dependency on it.

My Gamedata folder:

Blizzy Toolbar

Active Texture Management

B9 Aerospace

BoulderCo (Clouds)

Distant Objects

Editor Extensions

Enhanced NavBall

Environmental Visual Enhancements

Exsurgent Engineer (B9)

FAR

Firespitter (B9)

JSI (RasterPropMonitor)

KAS

Keramzit (Procedural Fairings)

Kethane

KineTech Animation (B9)

KW Rocketry

Magic Smoke Industries (Infernal Robotics)

MechJeb2 (Dev 246)

MechJeb2 RPM (Raster Prop Monitor MJ interface)

Navy Fish (Docking Port Alignment)

NovaPunch2

Open Resource System (Interstellar)

Real Chute

Real Solar System

ResGen (B9)

SCANsatRPM (Raster Prop Monitor SCANsat interface)

Thunder Aerospace (TAC fuel Balancer)

Tree Loader (Interstellar)

Trigger Tech (Kerbal Alarm Clock)

Warp Plugin (Interstellar)

B9 Fixes

Module Manager 2.0.5

Link to comment
Share on other sites

Actually within the DOE release is an option to replace stock colors with enhanced colors using RSS in some fashion. As you suggested you can use DOE without the RSS dependency.

Removing RSS solved the issue.

So for the Devs: Dev releases, at least after 240, maybe before, do not play nice with Real Solar System! Thanks for the help everyone. Problem solved.

Link to comment
Share on other sites

Ever since the download was added to the Curse host, it has been unbelievably slow. I have 40mb down internet so it isnt anything from my end.

EDIT: Thankfully it was still available on spaceport, instantly loaded :D

Edited by Marksius
Link to comment
Share on other sites

We release something like than 5 officials versions a year. I am sure you can wait the 10 second it takes to DL our gigantic 4MB.

But then with a 40 millibits per seconds internet it might be slow indeed...

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...