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

[Guest]

so im trying to in put the cords of my kethane -61.695,-137.890 as these dont fit into MJ2, as MJ2 does not have the same function as the older MJ how do i convert the cords to put in to MJ2 **,**,** N **,**,** E

thanks you

Try this site: http://transition.fcc.gov/mb/audio/bickel/DDDMMSS-decimal.html

that could be my issue, I tend to set 15-30km descent orbits

You're definitely starting much too low. Try from 100km and see how you fare.

[Srilania]

so im trying to in put the cords of my kethane -61.695,-137.890 as these dont fit into MJ2, as MJ2 does not have the same function as the older MJ how do i convert the cords to put in to MJ2 **,**,** N **,**,** E

thanks you

MJ2 has degrees, minutes, and seconds as well. But, in Kethane maps, like 122.322 isn't 122 degrees, 32 minutes, 2 seconds. you have to convert it

[agentexeider]

having an issue where the MECHJEB probe body parts CAN'T be the first part, How do I enable them so they can.

Edited June 23, 2013 by agentexeider

[Fazmandoo]

How do I install for KSP 0.20.0? The download seems to be different to any other mods I have seen for 0.20.0. Erm.... Help!

[GavinZac]

so im trying to in put the cords of my kethane -61.695,-137.890 as these dont fit into MJ2, as MJ2 does not have the same function as the older MJ how do i convert the cords to put in to MJ2 **,**,** N **,**,** E

thanks you

You can use any online converter; or even just google it, I think Google will convert radians to degrees just as it will convert miles to kilometres.

[MissMolly]

ok thank you all for the help

[BloodyRain2k]

so im trying to in put the cords of my kethane -61.695,-137.890 as these dont fit into MJ2, as MJ2 does not have the same function as the older MJ how do i convert the cords to put in to MJ2 **,**,** N **,**,** E

thanks you

MJ2 has degrees, minutes, and seconds as well. But, in Kethane maps, like 122.322 isn't 122 degrees, 32 minutes, 2 seconds. you have to convert it

I think you can just enter the numbers into the first fields, just set them to N E, else it'd do negative south which is north again etc.

No idea what that'd be but it should be S 61° 40min W 137° 55min ? Something around that.

[Virtualgenius]

Jack whats your yellow lander consist of in post 2093

[Guest]

Jack whats your yellow lander consist of in post 2093

That's the Altair from BobCat's American Pack. It also has the Orion CSM.

[agentexeider]

having an issue where the MECHJEB probe body parts CAN'T be the first part, How do I enable them so they can.

there seems to be a problem with the Mechjeb parts, when I drag them from the selection in the VAB they don't want to attach to anything, the textures are messed up and if I unselect them I can't grab them again. Is there any fix for this?

-Æ

[kaldak]

I'm having trouble using mechjeb for interplanetary transfers. I use alarm clock to get me within a few days of the launch window on the ground where I can get very fast time warp, then head to orbit and use the maneuver planner. But it always seems to pick the following window, which is often hundreds of days away. I've tried moving up my launch to orbit, to allow for the differences between Alarm Clock and Mechjeb launch window calculations, but that doesn't seem to help.

[HoY]

Get your ship into orbit then try to add the transfer node again, if it still tries for the next window enter time warp and go half way around the planet, remake the node, if it still doesn't work go to time warp for a little bit longer and try again. That will usually get you a good transfer

[kaldak]

I am starting the transfer from orbit. And I just tried warping around the orbit a few times and remaking the maneuver in different locations. It still wants a transfer window hundreds of days out for duna.

Another experiment: I got a ship up to orbit, set it for a transfer to duna (in 200+ days), went to a vehicle on the ground and warped to 12 hours before the node. Then I went back to the ship in orbit, removed the node, tried to set a new transfer, and once again it jumped to the next window (another 200+ days out).

Edit: Hmm, OK, I got a successful mechjeb transfer window by warping to 30 min before the "model" transfer window determined by Alarm Clock. Anyway, the process seems to take some tinkering...

Edited June 23, 2013 by kaldak

[TriggerAu]

Edit: Hmm, OK, I got a successful mechjeb transfer window by warping to 30 min before the "model" transfer window determined by Alarm Clock. Anyway, the process seems to take some tinkering...

The Model Transfer in Alarm Clock uses pre-created model data using more accurate elliptical orbits while MechJeb (And the Alarm Clocks Formula mode) uses Circular Formula's. It would be quite rare for them to align to be honest. Would suggest using the Formula mode in the Alarm clock if you are looking for that time to align.

Or even better you could use AlexMun's tool to find the best time - http://forum.kerbalspaceprogram.com/showthread.php/33023-WEB-APP-Launch-Window-Planner - but not sure how that would align into MechJeb.

[KhaosCorp]

I'm having trouble using mechjeb for interplanetary transfers. I use alarm clock to get me within a few days of the launch window on the ground where I can get very fast time warp, then head to orbit and use the maneuver planner. But it always seems to pick the following window, which is often hundreds of days away. I've tried moving up my launch to orbit, to allow for the differences between Alarm Clock and Mechjeb launch window calculations, but that doesn't seem to help.

As much as I love MechJeb2, I honestly wouldn't recommend using it to plan your initial transition burns for going to other planets. It may get you there sure, but in all my testing I found it to be very ineffective. Im still using Protactor mod to do initial transfer burn.

I tested this by sending many ships to duna, some with MJ2 and others using protractor. The flights using only MJ2 ended up on average using 400ish DeltaV more than doing main burn with protractor.

Also another thing you may try to het MJ2 play nice. Launch your ship a month or so before your intended transfer window. Get into 610KM parking orbit, there you can use max time warp, should be nothing ro zoom past a month or two.

[tek_604]

Alternatively, you can use the difference between Protractor and MJ to send two craft on their way at roughly the same time. Stick one in orbit, and tell MJ to send it on its next window. Go to ground, and launch the next one according to Protractor. All the while, use KAC to switch between them when mid course burns, SOI changes and the like.

MJ will get you there, but as KhaosCorp says, its not as efficient. For example, going to Jool, MJ often picks a window 1 or 2 days ahead of a Protractor launch, and will actually arrive some 80 days later. Still, looks cool having two on the way at the same time

[NGTOne]

OK, so I'm trying to land a large rolling base (mass to surface anywhere between 600 and 800 tons including skycrane, the base itself is about 370). MechJeb2 handles the landing FLAWLESSLY, up until it's about a meter from the surface and about to touch down. Then, for no apparent reason, it tries to pitch and yaw the thing in a random direction, and ends up crashing it. This has happened both on Minmus (where the skycrane had a TWR of about 19), and Eve (where the TWR is anywhere between 1.2 and 1.5, depending on re-entry characteristics). The object being landed is balanced PERFECTLY (MechJeb can fly it fine, without RCS assistance, in orbit and during re-entry), but MechJeb just goes nuts on the control inputs at the last moment before landing. I suspect this has something to do with the fact that the landing autopilot sees the ground level as being several meters above ACTUAL ground level, and gets confused when its altitude is "negative" (altitude over surface differs by as much as 20 meters between the Surface Information window and the Landing Guidance window).

The first time I encountered this, I was trying to land the base on one of the flat plains of Minmus. I chalked it up to the skycrane having a really high TWR, which threw off MechJeb's calculations and inputs. But then, the same thing happened on Eve, where the TWR was too low for that to be the case. Does anyone have any idea what might be causing this? For reference, I've included a picture of the base itself (including skycrane). The base is about 30 meters long (give or take), and maybe 20 wide (without the skycrane).

This issue is really frustrating me, because landing this thing from the last quicksave point can take half an hour to 45 minutes, just because of lag and its low rotation speed (even with RCS). Does anyone know what's going on?

(Sorry, I didn't take any really good glory shots of it on the surface, just because they don't exist yet).

[Mekan1k]

Physics lag is causing the landing calculation to be unable to accurately bring the structure down from orbit onto a surface.

To solve this, just before landing, try switching from 'land at target' to 'land somewhere', and if that does not work, deactivate the autopilot just before the crazy-spinning starts, then manually lower it down. The wheels should allow you to land with a bit of forward movement.

[AndreyATGB]

I would really like to see "Limit to terminal velocity" only work for Ascent guidance and not everywhere else if I don't select it myself. It's kind of annoying to test a plane and it just cuts throttle suddenly because I left that option on from a previous launch.

[mereman]

OK, so I'm trying to land a large rolling base (mass to surface anywhere between 600 and 800 tons including skycrane, the base itself is about 370). MechJeb2 handles the landing FLAWLESSLY, up until it's about a meter from the surface and about to touch down. Then, for no apparent reason, it tries to pitch and yaw the thing in a random direction, and ends up crashing it. This has happened both on Minmus (where the skycrane had a TWR of about 19), and Eve (where the TWR is anywhere between 1.2 and 1.5, depending on re-entry characteristics). The object being landed is balanced PERFECTLY (MechJeb can fly it fine, without RCS assistance, in orbit and during re-entry), but MechJeb just goes nuts on the control inputs at the last moment before landing. I suspect this has something to do with the fact that the landing autopilot sees the ground level as being several meters above ACTUAL ground level, and gets confused when its altitude is "negative" (altitude over surface differs by as much as 20 meters between the Surface Information window and the Landing Guidance window).

The first time I encountered this, I was trying to land the base on one of the flat plains of Minmus. I chalked it up to the skycrane having a really high TWR, which threw off MechJeb's calculations and inputs. But then, the same thing happened on Eve, where the TWR was too low for that to be the case. Does anyone have any idea what might be causing this? For reference, I've included a picture of the base itself (including skycrane). The base is about 30 meters long (give or take), and maybe 20 wide (without the skycrane).

This issue is really frustrating me, because landing this thing from the last quicksave point can take half an hour to 45 minutes, just because of lag and its low rotation speed (even with RCS). Does anyone know what's going on?

(Sorry, I didn't take any really good glory shots of it on the surface, just because they don't exist yet).

I'm finding the same thing on Mun. Funny thing is it's only just started doing this during the last week. Until then every landing was perfect within 2m of the target now it gets to 3-4 metres of touchdown and just falls over.

I'll try Mekan's idea.

[BloodyRain2k]

I would really like to see "Limit to terminal velocity" only work for Ascent guidance and not everywhere else if I don't select it myself. It's kind of annoying to test a plane and it just cuts throttle suddenly because I left that option on from a previous launch.

Should be easy to change that setting to a per type one so you could disable it and all planes of that type would share that setting.

I'm finding the same thing on Mun. Funny thing is it's only just started doing this during the last week. Until then every landing was perfect within 2m of the target now it gets to 3-4 metres of touchdown and just falls over.

I'll try Mekan's idea.

That's the old KillHS bug for you, fix is submitted and might be solved already in the latest 2.0.8 on jenkins, but dunno, I only play with my heavily modded MJ xD

[mereman]

Thanks just checked Jenkins and a newer dev build is on so trying that now

[elfindreams]

A couple of interesting issues.

Using MechJeb2-2.0.8.0-66 on Linux 64-bit (shouldn't make a difference but just in case).

If I have a relatively low thrust "tug" (the one I used had an approx TWR of 0.7) in orbit to shift the orbit of my (what I affectionately term) fuel guzzler (it has a approx TWR of around 10 along with a lot of fuel tanks, etc - heavy as hell... but I wanted to shift it's orbit using the more fuel efficient tug), after I dedock after shifting the orbit (30m burn, yay! thanks mechjeb for allowing me to fire it and go do something else).... the TWR calculations seem to be entirely borked. My tug shows a TWR of over 20 (as if it had all the gas guzzler's engines along with its own at its current weight) and even the guzzler's appears to be off.

It is like it never forgets about the engines it had when it was docked even when undocked, switching away form the ship and back doesn't help.

Issue #2 is related to Minmus transfers. If I get a transfer orbit from Kerbin to Minmus that hits the Mun on the way back (so leaving Kerbin, goes through Minmus SOI and then before getting back to Kerbin enters Munar SOI), using the options to "refine closest approach" seem to insist on using the Mun as the target even though I have Minmus set as the target. This has happened a number of times randomly where it seems to want to take me to the Mun no matter what I do to get to Minmus.

[KhaosCorp]

A couple of interesting issues.

Using MechJeb2-2.0.8.0-66 on Linux 64-bit (shouldn't make a difference but just in case).

If I have a relatively low thrust "tug" (the one I used had an approx TWR of 0.7) in orbit to shift the orbit of my (what I affectionately term) fuel guzzler (it has a approx TWR of around 10 along with a lot of fuel tanks, etc - heavy as hell... but I wanted to shift it's orbit using the more fuel efficient tug), after I dedock after shifting the orbit (30m burn, yay! thanks mechjeb for allowing me to fire it and go do something else).... the TWR calculations seem to be entirely borked. My tug shows a TWR of over 20 (as if it had all the gas guzzler's engines along with its own at its current weight) and even the guzzler's appears to be off.

It is like it never forgets about the engines it had when it was docked even when undocked, switching away form the ship and back doesn't help.

Issue #2 is related to Minmus transfers. If I get a transfer orbit from Kerbin to Minmus that hits the Mun on the way back (so leaving Kerbin, goes through Minmus SOI and then before getting back to Kerbin enters Munar SOI), using the options to "refine closest approach" seem to insist on using the Mun as the target even though I have Minmus set as the target. This has happened a number of times randomly where it seems to want to take me to the Mun no matter what I do to get to Minmus.

Couple things about this...

If your using a dev build you should make sure its the current build (that would be #68, not 66)

Just to be sure you should be doing homman transfers for getting to moons.

The main cause for this is bad timing.....MechJeb 2 is not a 'mindless gameplay' tool, and using it as such can create a lot of issues people have been posting about. MJ2 is a pilot assistance computer...not a pilot.

If you want a good moon transfer, use the homman transfer and PAY ATTENTION to the map. If the Mun is in the way wheb ya plan the node then you need to time warp a bit and redo the node. The 2 moons have VERY different orbits. So its just a matter a finding the right time to do your homman node.

Also another thing that will help is to match the inclination of your target BEFORE you even plan the homman. Based in inclination alone its rather easy to hit minmus without a munar encounter.

Hope this helps =P Remember MJ2 is a pilot assistance computer...not a pilot.

[elfindreams]

Couple things about this...

If your using a dev build you should make sure its the current build (that would be #68, not 66)

Just to be sure you should be doing homman transfers for getting to moons.

The main cause for this is bad timing.....MechJeb 2 is not a 'mindless gameplay' tool, and using it as such can create a lot of issues people have been posting about. MJ2 is a pilot assistance computer...not a pilot.

If you want a good moon transfer, use the homman transfer and PAY ATTENTION to the map. If the Mun is in the way wheb ya plan the node then you need to time warp a bit and redo the node. The 2 moons have VERY different orbits. So its just a matter a finding the right time to do your homman node.

Also another thing that will help is to match the inclination of your target BEFORE you even plan the homman. Based in inclination alone its rather easy to hit minmus without a munar encounter.

Hope this helps =P Remember MJ2 is a pilot assistance computer...not a pilot.

1) It wasn't the latest yesterday when I was testing this.

2) Read again, the Mun isn't in the way... it intersects with the Mun /after/ hitting Minmus SOI.

To re-iterate, I am not having problems using MechJeb or transferring to planets (look at my sig, those weren't using MechJeb) I am reporting a bug as to which body MechJeb is using to calculate something...

To clarify even further...

1) Create a transfer from Kerbin to Minmus with Mun on the return path, refine so that it passes through both SOIs (Minmus First, then Mun)

2) Set Minmus as target

3) Use the function to refine distance to target to 100km

4) Notice that it refined the Mun's SOI to have a 100km Pe node even going so far as to remove the intersect with Minmus.

5) Remember that I said Minmus SOI first.

Edited June 24, 2013 by elfindreams