r4m0n

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

Recommended Posts

I'm finding that getting MechJeb to accurately land on the Mun is near-impossible. It always ends up in the "braking burn" phase with the engine throttled down, and the projected landing site is always about 100km west of wherever I actually wanted to land, and it never manages to correct the course. It's annoying because I've previously used the landing autopilot on Minmus to try to rescue the crew of a downed lander, and it was so accurate I had to veer off at the last second to avoid landing on the crashed debris.

I'll bet this is the problem with the mechjeb landing autopilot not working properly with a low TWR. For some reason mechjeb misses a targeted landing by a wide margin (typically between 70 and 100 kilometers along the path of the orbit) when your craft's thrust to weight ratio is low. In this situation mechjeb doesn't start the deorbit burn at the correct time. If you increase the available thrust for the deorbit and landing, and change nothing else, the problem goes away.

EDIT: The above is in reference to Mun landings. I haven't noticed a problem for Kerbin or Minmus.

Edited by CrashnBurn

Share this post


Link to post
Share on other sites

I've been having fun too (for some perverse definition of fun) with MJ fluffing landings on the mun, with two recent craft of my own design. The first was a large lander with multiple crewtanks. That caused MJ to behave very spasmodically, it seemed as if it was Pulse-Width-Modulating the thrust, as it would burn in brief spurts and went completely titsup when close to the surface. A major redisign of the craft fixed that issue.

The 2nd craft (the one I'm trying to land now) has 6 of the little radial thrusters (from some parts pack) on a lander with a pair of symmetric radial attached stacks. This one looks like it will land, but MJ snatches defeat from the jaws of victory and screws the pooch a couple of metres above the terrain by overcompensating for some tiny lateral drift by making the craft swan dive face first into the dirt.

BTW, this is with MJ 1.9 (not 1.9.1) as I reverted back when I had the original issue with the crewtanktastic craft. Also, be advised that this isn't a complaint, or a bug report, but just some banter about MJ quirks. In fact, its all good fun. I'm getting quite adept at using the "Panic" button and a quick transition between the autolander and the autoascender to abort landings. I've even managed to recover and go around after a full 360 cartwheel on the surface that has left loads of presumably unneccessary spacecraft bits behind, followed by a succesful landing after another orbit.

Share this post


Link to post
Share on other sites
I'll bet this is the problem with the mechjeb landing autopilot not working properly with a low TWR. For some reason mechjeb misses a targeted landing by a wide margin (typically between 70 and 100 kilometers along the path of the orbit) when your craft's thrust to weight ratio is low......

I've found that if you must have a low TWR, starting from a higher orbit helps the accuracy. Typically above 40km

Share this post


Link to post
Share on other sites

Thanks, landing from a 100km orbit has completely resolved this. Well, the braking burn's taking forever, but it's on course for the target.

Share this post


Link to post
Share on other sites

Doesn't work for me. I always start from 50km or higher, typically 75-100km. I just use a bigger engine, or land manually, I can get much closer than mechjeb with a low TWR.

Share this post


Link to post
Share on other sites
Try building the DLL for .NET version 3.5.

Just change the module of your part to MuMechJebPod.

oh thanks that worked. im able to modify the view with freetrack, but i need to brush up on my quaternion maths to get my rotations to work right. il post a diff on pastebin or whatever when im done.

*edit*

k i think i got the liner algebra worked out. so i can look around and translate. probibly needs a little tweaking. im currently constraining rotations to 180 degrees on any axis, and confining leaning to a 1-unit cube. rotational and translational constrains might be wise to define in the part so that modders can prevent freetrack users from backing into the geometry or seeing something they shouldn't see.

i still have an ugly bug to fix. every once in awhile the freetrack interface doesn't respond and my code treats it as an error even though its just a hiccup in the api. as a result the view reverts to the default view for the camera. this just produces a frame where the camera is pointing in a different direction, and is only a minor graphical annoyance. i probibly just need to queue up the last good frame's position local camera info and use that, and if thats no good, then handle the no freetrack scenario. gonna fix that one at least, tweaks and features can come later.

Edited by Nuke
updated

Share this post


Link to post
Share on other sites

Just change the module of your part to MuMechJebPod.

I did that now whenever I start my game with this new part the game just quits on me. By that I mean I don't get a ship, I don't get a Kerbin, I can't move my camera.

Share this post


Link to post
Share on other sites

As an FYI, the relative inclination calculation in MechJeb is wrong. You can't just subtract the inclination angles of two bodies and call it "relative inclination." You have to factor in RAAN, as well.

Share this post


Link to post
Share on other sites

k heres a diff against rev 61. this adds freetrack support to mumech hull cameras. this is preliminary, id like to have other features like part specific camera constraints later on. i definately need feedback.

http://pastebin.com/dV2NQwG6

also since im using the freetrack api, that means you should also be able to use facetracknoir for head tracking. freetrack also supports wiimotes, webams etc. im using a trackir4 with freetrack, but dont tell natural point :D

another issue that im not sure if the ksp devs will like is that i am using freetrackclient.dll to supply the data to the new system (to be fair the rules didnt say anything about dynamically linking external dlls). the free track source (which comes with the dll source) is available on their website, be warned, its written in dephi pascal. you require the dll on your system, which if the freetrack installer did its job right should end up in the correct system path, if not you may need to copy the freetrackclient dll to your ksp folder. another thing, im kind of a c# noob, so tell me if i did anything bad.

Share this post


Link to post
Share on other sites
As an FYI, the relative inclination calculation in MechJeb is wrong. You can't just subtract the inclination angles of two bodies and call it "relative inclination." You have to factor in RAAN, as well.

Noticed this recently, the code is from Rincomp, I'll try to fix it soon.

k heres a diff against rev 61. this adds freetrack support to mumech hull cameras. this is preliminary, id like to have other features like part specific camera constraints later on. i definately need feedback.

http://pastebin.com/dV2NQwG6

also since im using the freetrack api, that means you should also be able to use facetracknoir for head tracking. freetrack also supports wiimotes, webams etc. im using a trackir4 with freetrack, but dont tell natural point :D

another issue that im not sure if the ksp devs will like is that i am using freetrackclient.dll to supply the data to the new system (to be fair the rules didnt say anything about dynamically linking external dlls). the free track source (which comes with the dll source) is available on their website, be warned, its written in dephi pascal. you require the dll on your system, which if the freetrack installer did its job right should end up in the correct system path, if not you may need to copy the freetrackclient dll to your ksp folder. another thing, im kind of a c# noob, so tell me if i did anything bad.

As-is, this would break compatibility with the Mac build, so I'll have to sit on it for a bit while I see if there is some way to integrate it nicely under all situations, but thanks for the patch.

Share this post


Link to post
Share on other sites

In the earliest rendezvous code there was a minor feature where the distance and speed for the x,y and z axes rotated for your current rotation was available. Would it perhaps be possible to reintroduce it? Those numbers were really helpfull.

Share this post


Link to post
Share on other sites
As-is, this would break compatibility with the Mac build, so I'll have to sit on it for a bit while I see if there is some way to integrate it nicely under all situations, but thanks for the patch.

yea i did a round of testing and the version i compiled will crash ksp if the dll is nor present. also the example code i based the interface off of was lacking some idiot proofing. it neither bothered with exception handling nor did it close the dll out when it was done. but what can i say, im fairly new to dynamic linking, not to mention c#. so i got some work to do on it. it works though and is a fairly good for a proof of concept. just need some virtual cockpits now. i could probibly cut one off of one of my mods for other games. ive done a lot of virtual cockpit mods for freespace2 open, and so i have a large number of assets lying around. otherwise its probibly not a very long wait for the iva features in the next version.

ive heard about there being some linux head tracking software. and there have been a few people interested in porting freetrack to mac. if there is some way to detect platform and then load up whatever interface library is neccisary to support head tracking on that system. i dont know a whole lot about macs, i haven't used one since the late 90s, so i dont know whats available as far as head tracking goes. if something does exist i suppose i could make the interface support head tracking protocols on those systems. it would likely be some time before that happens. my next job is to make the code tolerant of the absence of the dll, but first i need sleep.

Share this post


Link to post
Share on other sites

Hey, I've been trying to use MechJeb to make an Apollo style moonlander, but I haven't been having much success.

I'm using crew-able empty pods 0.3 http://kerbalspaceprogram.com/forum/showthread.php/15016-0-16-Crew-able-empty-pods-0-3 and using the small cylindrical mechjeb module which fits on the tip of the one man pod. I'm able to disengage my lander with the empty pod and the MechJeb module and select it (although only through the space center), but I cannot see or use any MechJeb functions once the lander is detached, and I can't change my attitude with RCS thrusters or gimballing engines. I can adjust the thrust, but only if the engine was engaged before or during seperation.

Also, once I select the lander (debris) from the space center I can no longer return to the space center or end the flight, and must restart the game to do anything else.

Share this post


Link to post
Share on other sites

I put the files in the KSP folder (Bought the game yesterday, it's the latest version) and when I try to add some mechJeb parts to my rockets, it says:

'This part type isn't available in this version KSP.'

2lwtc2q.png

Share this post


Link to post
Share on other sites

vava54, you must ensure that the MuMechLib.dll is in the plugins folder :)

Share this post


Link to post
Share on other sites

They should work then, if they are the most up to date, you may have to delete all those files you installed and reinstall afresh.

Share this post


Link to post
Share on other sites

It was already a fresh install, but I did it again, and it is still the same issue.

It's as if mechjeb isn't compatible with the newest 0.16.

Share this post


Link to post
Share on other sites

Do any other plugins work for you?

Are you running KSP from the desktop?

If you are, KSP and the plugins will not be able to write to the directory where they are installed, causing lots of problems like this one.

Unzip KSP to a non-windows made folder, such as C:\Games, and install MechJeb there, do not move your current KSP folder as it may already be damaged.

Share this post


Link to post
Share on other sites

Found the issue myself, it was my antivirus sandboxing the game. Thanks for the help though.

Share this post


Link to post
Share on other sites

Is your game in 'Program Files'? Then you have a problem with windows, best thing is to get the game out of there, also go to C:\Users\Nutzer\AppData\Local\VirtualStore (path IS different for your user of course!), and copy (with overwriting!) the ksp folder from there too to keep your persistence file.

Share this post


Link to post
Share on other sites

anyway i updated my patch for freetrack support.

http://pastebin.com/XGAR01SW

it now handles exceptions properly. so your not dependent on the dll to run the plugin.

i fixed a bunch of quirks with the translation. like the vector needed to be transformed into part space. and cleaned up the class abit. still needs a virtual cockpit to really shine though. still needs part specific constraints. the FreeTrackClient class supports changing of constraints, but nothing changes them yet. but thats probibly easier than doing interop stuffs.

Edited by Nuke

Share this post


Link to post
Share on other sites

Question: Does my mechjeb enabled craft benefit from having an ASAS onboard? I see that SAS is never turned on (I assume MJ turns it off and steers manually) so I'm not sure if my MJ craft require ASAS or if I can remove ASAS completely.

Share this post


Link to post
Share on other sites

Mechjeb does use SAS very effectively, just very quickly toggling it on/off most of the time, so you might not notice.

Mechjeb is an ASAS, it had conflicts with regular ASAS in earlier versions, apparently, but it plays nice now, although I don't see any benefit from using ASAS with Mechjeb.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.