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

[Galane]

I was trying out some of my Mun mining kethane landers at Duna last night. Used MJ build 106. Results were mixed. Landings achieved from 45KM with ease but (as expected) not much fuel left.

Then I filled up everything with hyperedit to see how short on fuel they'd be to get to orbit. Yup, not enough. But one of them, the big 32,000 unit one, gets partway into the ascent then the pitch and yaw go off and it starts rolling around. I'll have to give it a Mun test, and another Duna test to see if it may have been just a glitch that session.

[Starwaster]

I was trying out some of my Mun mining kethane landers at Duna last night. Used MJ build 106. Results were mixed. Landings achieved from 45KM with ease but (as expected) not much fuel left.

Then I filled up everything with hyperedit to see how short on fuel they'd be to get to orbit. Yup, not enough. But one of them, the big 32,000 unit one, gets partway into the ascent then the pitch and yaw go off and it starts rolling around. I'll have to give it a Mun test, and another Duna test to see if it may have been just a glitch that session.

One thing I've noticed is that 106 does roll less but I did have an unwanted roll on descent that stopped when I disengaged the AP and turned off Force Roll in the Smart A.S.S.

BTW am I the only person, who when playing KSP alone in their room at night, while clicking MJ buttons, shouts authoritatively at the screen.... ENGAGE THE SMARTASS!!!!

[sarbian]

One thing I've noticed is that 106 does roll less but I did have an unwanted roll on descent that stopped when I disengaged the AP and turned off Force Roll in the Smart A.S.S.

Ok, the improvement wasn't just in my head then. I'll look into the roll when FR is active in Smart ASS.

About the failed landing : I had this bug but I never managed to replicate it when I have some debug log enabled. I will look into it when I find the courage to test landing again (landing AP is a really boring thing to debug/test, it takes forever).

Galane : I may not have tell it before but I know landing on Duno is really bugged. The trouble is that when I looked into it (a few month ago) I could not find why. Most likely something related to atmo is wrong when not landing on Kerbin, but I could not find what. I look into it now that I am more comfortable with MJ code but as usual there is no promise that I can find what's wrong.

On other news : someone posted a really detailed bug report on github about MJ CPU usage and with some info from where the code could be improved. #107 should fix that. KSP perf should be a bit better with MJ, even more on ship having more than 1 MJ module.

[BigD145]

I don't know what happened but 107 broke itself. The AR202 is unplaceable and loading any vehicle with one on makes the whole vehicle unclickable and destaged (no orange staging numbers, just every part from staging in a tall vertical tower of grey blocks). Deleting and putting 105 in fixes everything. I was going from 105 to 107, deleting mechjeb2 from gamedata only before copying the new mechjeb2 folder in.

[sarbian]

Just saw that too. Sorry about that

108 fix it

[drtedastro]

Hey Sarbian, I just updated to 108 and it 'seems' that during docking autopilot that it is burning more rcs than it was in my last version, the details from the .dll show it as 2.0.13252.2353

I dont remember which pull it was, 106, 105, ????

any change made in that part of the code??

thanks.

[Virindi]

I've had suspicions that MJ might behave like that myself, but there's too much unknown about your pictures to consider it damning evidence. At worst, it might only be guilty of poor responses to forces that are already acting to throw your rocket off course. You're at a critical point in your ascent where depending on your velocity and heading, you could go severely off course beyond MJ's ability to compensate for (considering, FAR and RSS)

Also, What FAR corrective features are enabled if any? FAR does provide control inputs to the rocket and they can fight each other.

No FAR control features were enabled. MechJeb continuously attempted to turn the rocket away from the proper course, smoothly, the entire time. In multiple tests when this happened if I disabled MJ and manually turned the rocket towards prograde, control was easily regained. If I turn MJ back on, it instantly starts spinning the rocket in the wrong direction again.

Note that MJ also does this with corrective steering off. When I manually fly an identical ascent profile (using the navball guidance) there is absolutely no issue.

[Galane]

Here's something not working. I have my manned Duna lander docked to the return ship to move to Ike orbit to finish refueling but MechJeb will not run the throttle on the four Skippers.

I have control set to one of the RockoOKTOClampo on the ship, facing the correct direction. The Skippers are active, the Poodle on the lander is deactivated. Checked to make sure it knows the right way to go by using smartass to point prograde.

But come the node for the hohmann transfer burn and... nothing happens. If I put control on the lander can or the lander's docking port and switch which engines are active, it works. I used the poodle to raise the orbit to 61KM so it could warp faster.

But if MechJeb is going to refuse to run the skippers, Jeb and Bill are going to be stuck at Duna.

With a previous build I had a similar problem with two ships docked end to end with engines facing opposing directions. Every other maneuver I had to switch which craft had control and which engines were active because it would not run two burns in a row on the same ship.

Build 108 isn't doing the switch thing, just will not fire those engines and also won't allow manual throttle control of the engines it won't throttle up automatically.

I wonder if it has something to do with which ship was active at docking time? The pair is shown by the lander's name.

This *is not* affecting RCS thrusters. Those work on both ships.

MechJeb is integrated using Module Manager and it does work on ships with no remote control part other than the ROC. The other encounter with this issue was on two docked ships without any modded control pods aside from having MechJeb on through Module Manager.

[Spooks]

Mech fail to land @ ksp from kerbal orbit he send me in space ?

[BPI_Bel]

mikeydz: The unlock progression for MechJeb as of the current release build is

Custom Window Editor, Smart ASS -> Flight Control

Maneuver Planner, Maneuver Node Editor, Translatron, Warp Helper, Attitude Adjustment, ThrustWindow, RCS Balancer -> Advanced Flight Control

Rover Autopilot -> Field Science

Ascent Guidance, Landing Guidance, Spaceplane Guidance -> Unmanned Tech

Docking Autopilot, Rendezvous Autopilot, Rendezvous Planner -> Advanced Unmanned

I pulled the data from the AR202 part cfg file that is included in the zip. I think ThrustWindow is Utilities, but I am not sure.

Sarbian: Perhaps we could include this information in the first post so that new people to MJ have some idea of what to expect. I remember having a 'what is wrong' feeling at first when I tried using career mode and had unlocked the part.

[MaxP]

The AR202 from 107 dev build cannot be attached to vessel in VAB, log is full of exception. With stable version all is stable (weird things )))

[forsaken1111]

No FAR control features were enabled. MechJeb continuously attempted to turn the rocket away from the proper course, smoothly, the entire time. In multiple tests when this happened if I disabled MJ and manually turned the rocket towards prograde, control was easily regained. If I turn MJ back on, it instantly starts spinning the rocket in the wrong direction again.

Note that MJ also does this with corrective steering off. When I manually fly an identical ascent profile (using the navball guidance) there is absolutely no issue.

I've noticed something similar. Using Mechjeb when I was coming back into the atmosphere, I manually oriented my rocket toward retrograde and told it to keep me pointed retrograde. Instantly it began turning the rocket off of the retrograde vector. I cancelled it and was easily able to manually reorient it but another test and MJ turned the rocket away from retrograde again.

For now I just use it for information as it can't seem to handle even basic flight instructions.

Which is the latest build before .22 integration with the gradual techtree unlocking? That version worked fine for me when I was using it, and I somewhat regret upgrading.

[AndreyATGB]

About reentry retrograde. The RETRO button is for orbital only, it will point towards the orbital retrograde not the surface one. Once you slow down enough, orbital will remain basically the same (almost horizontal) while surface will be straight down.

[Damaske]

The AR202 from 107 dev build cannot be attached to vessel in VAB, log is full of exception. With stable version all is stable (weird things )))

He knows that 107 is messed up please use dev build 108 as it is the same as 107 but without the weirdness.

[forsaken1111]

About reentry retrograde. The RETRO button is for orbital only, it will point towards the orbital retrograde not the surface one. Once you slow down enough, orbital will remain basically the same (almost horizontal) while surface will be straight down.

I was under the impression that the retrograde marker on the navbal points away from your current direction of travel with reference to your current SOI while the prograde marker points towards the direction of travel.

This should be true regardless of where you are.

In any case, I've used this method on previous MJ builds to keep the heatshield in the right place and it's worked fine before.

[Starwaster]

About reentry retrograde. The RETRO button is for orbital only, it will point towards the orbital retrograde not the surface one. Once you slow down enough, orbital will remain basically the same (almost horizontal) while surface will be straight down.

when you slow down enough your orbit is carrying you into the ground. Prograde will point in that direction as well. Pointing retro at tha time will have your aft aimed at the ground eventually.

[Starwaster]

Ok, Sarbian here's an idea for some re-entry sanity checking. When MJ starts a de-orbit burn or entry course correction it should save the original delta-V requirement. Then, at several points during the burn it should check to see if the required DV has gone up or gone down. If a (to be determined threshold) number of such samples show that DV requirements are going up instead of down then something has gone south. MJ should re-initialise the re-entry. (basically the equivalent of me pressing abort and then pressing either land at target or land anywhere, depending on which I was trying to do originally)

[forsaken1111]

when you slow down enough your orbit is carrying you into the ground. Prograde will point in that direction as well. Pointing retro at tha time will have your aft aimed at the ground eventually.

Exactly. And this is precisely the function I'm trying to use to keep my heatshield-covered aft aimed at the oncoming planet.

But MJ seems to be slipping off target each time, even before I enter atmosphere.

[Eric S]

I was under the impression that the retrograde marker on the navbal points away from your current direction of travel with reference to your current SOI while the prograde marker points towards the direction of travel.

An SoI by itself doesn't fully define a frame of reference. An orbital frame of reference doesn't rotate, the frame of reference when your navball is in "surface" mode does rotate.

An easy way to see the difference is to switch the navball between orbital and surface modes while doing a parachute landing on Kerbin when the parachutes are fully deployed (so you're moving less than 20m/s). Your surface mode prograde marker will be almost directly down, your orbit mode prograde marker will be almost directly horizontal, since your orbital velocity is much higher than your rate of descent.

As I understand it, it is possible to get SMARTASS to track the surface-relative prograde/retrograde in the advanced mode, but I've never played around with that.

[sarbian]

Ok, Sarbian here's an idea for some re-entry sanity checking. When MJ starts a de-orbit burn or entry course correction it should save the original delta-V requirement. Then, at several points during the burn it should check to see if the required DV has gone up or gone down. If a (to be determined threshold) number of such samples show that DV requirements are going up instead of down then something has gone south. MJ should re-initialise the re-entry. (basically the equivalent of me pressing abort and then pressing either land at target or land anywhere, depending on which I was trying to do originally)

I'd rather find why it try to deorbit instead of landing, but this sounds like a good idea if I can't find it.

I just push #109. It fix the MJ not showing up in the editor. Sorry about the multiple bugs with the last builds

[shrx]

Is it possible to improve the deltaV window so it displays deltaV for all stages, even those without engines?

For example, consider this rocket:

   /\       command pod 
o:|  |    radial decouplers on the upper tank with some ballast
  |/\|      upper engine
   --       decoupler
  |  |      lower tank
   /\       lower engine

Stage 0: activate radial decouplers

Stage 1: decouple lower tank, activate upper engine

Stage 2: activate lower engine

Mechjeb will display the deltaV info only for stages 2 and 0. For Stage 1 the deltaV will be 0. Is it possible to show the correct value?

[Galane]

Mech fail to land @ ksp from kerbal orbit he send me in space ?

First, make sure Control From Here is set on a command pod part that's facing the correct direction. Second, hit F9 to reload your last save and try it again. Lately MechJeb appears to be getting its directions confused some of the time.

I'd rather find why it try to deorbit instead of landing, but this sounds like a good idea if I can't find it.

I just push #109. It fix the MJ not showing up in the editor. Sorry about the multiple bugs with the last builds

I'm going to try #109, if that doesn't get it to work the Skippers on my Duna ship, I'll try the 2.1 release build. If it has no problem correctly running a pair of docked ships, then that's a benchmark to note.

If it doesn't work I'll go up in releases until I find one that does. Hopefully somewhere in there is one that will correctly switch throttle control when the user changes control pod and active engines from one side of a docking port to another.

I can do a test without any custom combined parts, put together a version of the upper stages of my Duna core with stock RCS blocks (though this issue isn't affecting RCS) and a plain Clampotron on top then dock the Two-Step lander to it, minus the strut guns.

Hmmm. I could try turning the strut guns off and see if that makes any difference. The Quantum struts will rigidly lock a ship's orientation if they're mounted on or the beam intersects the little Cubic Octagonal Struts*. Could be the strut guns are bugging MechJeb due to them connecting to the ROC custom part. 'Course the other time this cropped up with docked ships didn't involve strut guns or quantum struts, though I think those may have the three in one combined docking ports.

*This can be a feature, locking the rotation even better than Kill Rot in smartass.

[triffid_hunter]

As I understand it, it is possible to get SMARTASS to track the surface-relative prograde/retrograde in the advanced mode, but I've never played around with that.

I have, you want SURFACE_VELOCITY, BACK.

would really love a couple of buttons for easy access to surface pro/retrograde

While I'm at it, any chance of moving the aerobrake prediction out of landing autopilot? I think it makes sense to separate those and make aerobrake prediction available maybe one tier earlier in the tech tree

[Starwaster]

I'd rather find why it try to deorbit instead of landing, but this sounds like a good idea if I can't find it.

Please clarify, I have no idea what that means. An orbiting craft HAS to de-orbit. If it does not de-orbit it cannot land.

[sarbian]

You can't understand because I did not write what I meant too. I should sleep at night ...

I'd rather find why it try to NOT deorbit ...