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

[sarbian]

Toolbar works for me in 157. I ll have a look later, tired right now.

drtedastro : the problem is not having a list of change. it's bug on their end that impact only mods, or change in how they do things we have to understand without docs.

[LameLefty]

Toolbar works for me in 157. I ll have a look later, tired right now.

Just FYI, Toolbar is working fine 157. I did accidentally overwrite the entire MJ folder when I updated, so I had to reinstall the MechJebToolbar .dll file and reorganize my buttons but that was my fault.

[drtedastro]

Toolbar works for me in 157. I ll have a look later, tired right now.

drtedastro : the problem is not having a list of change. it's bug on their end that impact only mods, or change in how they do things we have to understand without docs.

It is a shame that they do not provide some form of a set of docs to help you with their changes. It would benifit them as well as the entire population of users / moders etc....

[katalex-3]

Yes, just should reinstall toolbar panel MJMenuToolbar.

[longhornchris]

@sarbian - not sure when you added it, but I really like the that the maneuver editor now has the 'execute node' button. Thanks

[DerekL1963]

A further appraoch is to add support for reachchutes, and then we can ask StupidChris nicely to do whatever is required to allow MJ to have more control over when these deployments happen.

+100 to this idea!

[Starwaster]

They're adjustable in .23, I just haven't tried adjusting them yet.

I'm not talking about end user control over parachutes. I was referring to how the chute behavior affects MechJeb's landing autopilot.

Thanks for the advice. I am afraid it is not so simple - the issue is not about what the strategy is for making course corrections, or for handling data samples over time*. The problem is that the flight path is influenced by something that we are not able to predict in advance. However if you think that you would be able to improve the situation, then by all means - break out the code and have a go.

If I had time to work on code I would. I barely have time to work on modeling a part that shouldn't have taken me a month but has.

So all I can contribute is advice.

Edited January 4, 2014 by Starwaster

[Bobe]

Does the landing guidance module require you to be at a minimum altitude for a given body for it to work properly? I was in an 80 km orbit around Duna and picked a target almost on the other side of the planet so it had plenty of time to prepare. However after the initial high deorbit burn, instead of pitching up and doing a minor course correction, it pitched down and started burning away from the planet indefinitely. The blue predicted landing indicator was also way off target.

I tried increasing my orbit to 100 km, but got the same result. Is there something I'm missing or is it just buggy?

[Starwaster]

Does the landing guidance module require you to be at a minimum altitude for a given body for it to work properly? I was in an 80 km orbit around Duna and picked a target almost on the other side of the planet so it had plenty of time to prepare. However after the initial high deorbit burn, instead of pitching up and doing a minor course correction, it pitched down and started burning away from the planet indefinitely. The blue predicted landing indicator was also way off target.

I tried increasing my orbit to 100 km, but got the same result. Is there something I'm missing or is it just buggy?

Sometimes it does bug out like that. Before any landing attempt be sure to F5 so you can F9

It doesn't always do that so, no it's not like you tried from a bad orbit.

Honestly it's random.

If you had quicksaved before it screwed up and then restored that save point and tried immediately again, odds are it will work. Or it might crap out again.

Also, trust your intuition. If you suspect that it might be doing a bad course correction then you're probably right and you should abort the landing procedure. Depending on how badly it screwed up you might need to restore to last quicksave OR you might just be able to click the land (at target/anywhere) and have it land successfully.

And another thing, MechJeb does do unnecessary course corrections in mid re-entry so sometimes it does pay to shut it off after the initial de-orbit burn and wait until it's most of the way down before re-enabling it. You'll get a feel for when to re-enable if you practice often enough. For landing at KSC I generally do it right somewhere between where I'm approaching the coast of the continent that KSC is on and the mountain ranges.

[Bobe]

Sometimes it does bug out like that. Before any landing attempt be sure to F5 so you can F9

It doesn't always do that so, no it's not like you tried from a bad orbit.

Honestly it's random.

If you had quicksaved before it screwed up and then restored that save point and tried immediately again, odds are it will work. Or it might crap out again.

Also, trust your intuition. If you suspect that it might be doing a bad course correction then you're probably right and you should abort the landing procedure. Depending on how badly it screwed up you might need to restore to last quicksave OR you might just be able to click the land (at target/anywhere) and have it land successfully.

And another thing, MechJeb does do unnecessary course corrections in mid re-entry so sometimes it does pay to shut it off after the initial de-orbit burn and wait until it's most of the way down before re-enabling it. You'll get a feel for when to re-enable if you practice often enough. For landing at KSC I generally do it right somewhere between where I'm approaching the coast of the continent that KSC is on and the mountain ranges.

Of course I always quicksave before doing anything important. I tried several times but I could not get it to behave.

For non-powered landings I do typically disable it after the deorbit burn and course correction, but I couldn't even do that in this case. The deorbit burn alone was putting the landing spot hundreds of kilometres from the target.

Maybe I was just getting unlucky, but to be honest I think it was a lost cause anyway. I did eventually give up and just let it coast to the surface, overshooting the target. However, without a braking burn, my 40 t lander couldn't withstand the force of the chutes deploying, and I didn't install and drogue chutes. I never really intended it to land on Duna, but I'm having trouble getting my ship any further, which is another issue entirely.

[Starwaster]

Of course I always quicksave before doing anything important. I tried several times but I could not get it to behave.

For non-powered landings I do typically disable it after the deorbit burn and course correction, but I couldn't even do that in this case. The deorbit burn alone was putting the landing spot hundreds of kilometres from the target.

Maybe I was just getting unlucky, but to be honest I think it was a lost cause anyway. I did eventually give up and just let it coast to the surface, overshooting the target. However, without a braking burn, my 40 t lander couldn't withstand the force of the chutes deploying, and I didn't install and drogue chutes. I never really intended it to land on Duna, but I'm having trouble getting my ship any further, which is another issue entirely.

When you say it was burning away from the planet indefinitely, was it one of those burns where you eventually reach escape velocity out of duna into Kerbol SOI?

Is there anything in the debug log when it does? Like errors?

[codepoet]

Does the landing guidance module require you to be at a minimum altitude for a given body for it to work properly? I was in an 80 km orbit around Duna and picked a target almost on the other side of the planet so it had plenty of time to prepare. However after the initial high deorbit burn, instead of pitching up and doing a minor course correction, it pitched down and started burning away from the planet indefinitely. The blue predicted landing indicator was also way off target.

I tried increasing my orbit to 100 km, but got the same result. Is there something I'm missing or is it just buggy?

I have never see that happen, so I would in interested in any info you can pass on about it. In particular - is there anychance you could make a video (in the past I have done so with ezvid or fraps) as it would be interesting to to watch it happen. Also logs etc would be useful, or a game save and instructions to reproduce it.

[Starwaster]

I have never see that happen, so I would in interested in any info you can pass on about it. In particular - is there anychance you could make a video (in the past I have done so with ezvid or fraps) as it would be interesting to to watch it happen. Also logs etc would be useful, or a game save and instructions to reproduce it.

I have seen it but it was totally random for me. Had saved, targeted point on Kerbin and clicked land at target F9 right back to just before I had started the landing sequence, target a point on planet clicked land at target and it didn't happen that time.

There was an error and I posted it in this forum.... disturbing to think I did that for naught.

Was several months back.

Edit: If Bobe's is consistent I think you'd do better with a copy of his craft file than just repro instructions.

Edited January 4, 2014 by Starwaster

[codepoet]

...

And another thing, MechJeb does do unnecessary course corrections in mid re-entry so sometimes it does pay to shut it off after the initial de-orbit burn and wait until it's most of the way down before re-enabling it. You'll get a feel for when to re-enable if you practice often enough. For landing at KSC I generally do it right somewhere between where I'm approaching the coast of the continent that KSC is on and the mountain ranges.

Could you explain what you mean by "unnecassery"? Are you suggesting that it would land acurately without a course correction?

The way that it works in the current version is (perhaps a little simplified) as follows:

1) High deorbit burn (unless it is doing a low deorbit burn, but that is a different matter!) This involves waiting until it is a quater orbit away, and then both changing the plane (hence the quarter orbit away) and lowering the periapsis until it is 10% below sea level.

2) Then it performs a course correction which will stop once the predicted landing spot is <150m from target

3) Then it coasts towards a deceleration burn. If the predicted landing site is more than 600m from target it will got to step 2 and course correct again.

4) If there is an atmopshere, during both 2) and 3), once the atmospheric drag is >100mm/s2 the statistical analysis of the predictions starts to time the parachutes. This is significant because if the flight path does not pass over the target at this point then timing the parachutes can not move the landing spot laterally. However because it can correct for over/undershoot it is likely to bring the error down to less than 150m and therefore not course correct, and so not correct the lateral error. For this reason it might make sense to turn the autopilot off and on again before reaching step 4 (100m/s2 drag) to force a correction if the error is let's say 300m (and significantly if there is a lateral error.)

5) The parachutes will open at the time that the satisitical analysis say they should - once at least one parachute is deployed then course corrections are not allowed, as the parachute drag would prevent the craft having effective attitude control. The deceleration burn will fire if the speed exceeds the target speed defined by the breaking policy*.

6) When we reach the deceleration end altitude above the predicted landing point (where the deceleration end altitude is something to do with the distance covered to produce enough drag to cancel our current speed, or something - it is a bit complicated and I do not quite understand it, or for bodies with no atmospehere it is 500m) we then move to the final decent phase, which is esentially a free drop down to a suicide burn to hopefully touch down at your desired speed.

7) The landing legs will deploy at any stage once the AGL < 1000m

That is pretty much how I understand it. So like I say I am not sure what you mean when you say a course correction is unneccasery. In the high atmosphere it is possbile and can result in a more precise landing. Once the drag gets too large then performing a course correction becomes difficult depending on the design of your craft, and once a parachute is deployed it becomes impossible.

Edited January 4, 2014 by codepoet
spelling

[codepoet]

I have seen it but it was totally random for me. Had saved, targeted point on Kerbin and clicked land at target F9 right back to just before I had started the landing sequence, target a point on planet clicked land at target and it didn't happen that time.

There was an error and I posted it in this forum.... disturbing to think I did that for naught.

Was several months back.

Edit: If Bobe's is consistent I think you'd do better with a copy of his craft file than just repro instructions.

If you can point me at the post I will take a look.

[Shad0wCatcher]

Thanks again Sarb and poet for your work. Both of you definitely don't burn yourselves out on this. Believe me it sucks. I burned myself out on ArmA 2 modding and it's no fun having something you enjoy doing turn into work that you despise looking at (over 4000 hours combined between ArmA 2 and Operation Arrowhead).

[Starwaster]

If you can point me at the post I will take a look.

Sorry, I have no idea where that post is; as active as this thread is it's probably over 100 pages back.

And unfortunately using the thread search tool to search for my posts by user name returns zero results, so apparently I have never even POSTED to this thread before.

So I have ZERO idea what you are even reading right now

[Starwaster]

Could you explain what you mean by "unnecassery"? Are you suggesting that it would land acurately without a course correction?

The way that it works in the current version is (perhaps a little simplified) as follows:

1) High deorbit burn (unless it is doing a low deorbit burn, but that is a different matter!) This involves waiting until it is a quater orbit away, and then both changing the plane (hence the quarter orbit away) and lowering the periapsis until it is 10% below sea level.

2) Then it performs a course correction which will stop once the predicted landing spot is <150m from target

3) Then it coasts towards a deceleration burn. If the predicted landing site is more than 600m from target it will got to step 2 and course correct again.

4) If there is an atmopshere, during both 2) and 3), once the atmospheric drag is >100mm/s2 the statistical analysis of the predictions starts to time the parachutes. This is significant because if the flight path does not pass over the target at this point then timing the parachutes can not move the landing spot laterally. However because it can correct for over/undershoot it is likely to bring the error down to less than 150m and therefore not course correct, and so not correct the lateral error. For this reason it might make sense to turn the autopilot off and on again before reaching step 4 (100m/s2 drag) to force a correction if the error is let's say 300m (and significantly if there is a lateral error.)

5) The parachutes will open at the time that the satisitical analysis say they should - once at least one parachute is deployed then course corrections are not allowed, as the parachute drag would prevent the craft having effective attitude control. The deceleration burn will fire if the speed exceeds the target speed defined by the breaking policy*.

6) When we reach the deceleration end altitude above the predicted landing point (where the deceleration end altitude is something to do with the distance covered to produce enough drag to cancel our current speed, or something - it is a bit complicated and I do not quite understand it, or for bodies with no atmospehere it is 500m) we then move to the final decent phase, which is esentially a free drop down to a suicide burn to hopefully touch down at your desired speed.

7) The landing legs will deploy at any stage once the AGL < 1000m

That is pretty much how I understand it. So like I say I am not sure what you mean when you say a course correction is unneccasery. In the high atmosphere it is possbile and can result in a more precise landing. Once the drag gets too large then performing a course correction becomes difficult depending on the design of your craft, and once a parachute is deployed it becomes impossible.

What I'm saying is that I have seen it do course corrections after it's already hit atmo and that I've had to turn it off so that it doesn't go off course or worse burn fuel that I'll need for a soft landing.

This is also to prevent it from doing things like Bobe described or to stop it from doing things like burning +/- NRM

Does it do it all the time? Nope. But it's happened often enough that I just haven't felt like I could trust it with atmospheric control within a window starting shortly after re-entry and until shortly before landing. Not for a few months anyway.

[Voidryder]

First, thanks to everyone who either created or maintains or improves MechJeb. I started playing KSP right when .17 came out, so I'm a bit of a newbie. MechJeb taught me how to fly. I learned a tremendous amount by paying attention to what it was doing and when it was doing it. Now I use it to automated the more routine parts of space missions so I can concentrate on other aspects (like snacks.) Do I have it do everything? No, but launching the same CM/LV configuration for the hundredth time is where it comes in very handy.

Anyway, I've been following the discussion about the Landing Guidance and other "bugs" for some time now and just wanted to offer my point of view. I don't particularly want a perfect MechJeb. I like the fact that some of the features don't always work 100%. When MJ pulls a weirdie it adds a bit of excitement and urgency to whatever mission I'm flying. Going to overshoot a Duna landing? I shut MJ down and go manual. Docking Rendezvous putting my cargo Dragon on the wrong side of my station? Shut it down and go manual. Fuel looking short on that Laythe landing? Abort and go for rescue. Etc, etc, etc.

Those glitches make the game entertaining for me. One thing real life space expolartion has shown us time and time again is just when we begin thinking it's all routine, something goes co-phooey! And flight controllers, engineers, astronauts and scores of others have to figure out how to fix it. I enjoy that "realism" made possible by a temperamental MechJeb.

Now I do understand other players wanting MechJeb to work as advertised and I appreciate the dedication that the MechJeb Team puts into making it right. I'm only offering my point of view as it seems different from what I've heard. It's nothing more.

[Galane]

Sometimes it does bug out like that. Before any landing attempt be sure to F5 so you can F9

And another thing, MechJeb does do unnecessary course corrections in mid re-entry so sometimes it does pay to shut it off after the initial de-orbit burn and wait until it's most of the way down before re-enabling it. You'll get a feel for when to re-enable if you practice often enough. For landing at KSC I generally do it right somewhere between where I'm approaching the coast of the continent that KSC is on and the mountain ranges.

And for some reason, after it's finally settled down on its final course to landing, you still have to wait until it's down in the atmosphere a ways before you can warp to speed things up. Dunno why it likes to twitch the ship and kick it back down to 1x speed. Leave it alone at 1x and it'll just ride on down without doing a anything until it turns upright for the landing.

Edited January 4, 2014 by Galane

[codepoet]

What I'm saying is that I have seen it do course corrections after it's already hit atmo and that I've had to turn it off so that it doesn't go off course or worse burn fuel that I'll need for a soft landing.

It will sometimes do a course correction in the atmosphere. There is nothing wrong with that - it helps it land closrer to the target. There are times when it becomes hard to control attitude (depending on the design of your craft) and as I have described above there is a point at which it will give up trying to course correct. With previous versions I have seen it get "stuck" in the course correction step, whereby it can not do the burn as it can't control attitude in the face of the drag, but is too off target to switch back to the deceleration burn step, however in the latest builds that should not happen (or at least certainly not if you have got a parachute on the craft).

This is also to prevent it from doing things like Bobe described or to stop it from doing things like burning +/- NRM

Sometimes burning +/-NRM is the right thing to do to correct the course - I am not sure why you are saying that is a problem.

Does it do it all the time? Nope. But it's happened often enough that I just haven't felt like I could trust it with atmospheric control within a window starting shortly after re-entry and until shortly before landing. Not for a few months anyway.

A lot has changed with the builds of the last few days. If you experience problems with those builds do please provide logs, craft files, save files, instructions for reproducing the problems etc etc. However it might be time for you to give it another go, and see if you can bring yourself to leave it turned on. I am not bothered if you use it or not, but don't go saying that it does not work if you are not even giving it a chance to do its thing.

[JeffreyCor]

using B157 I noticed when landing it wouldn't do anything unless I turned on RCS for some reason. Never that before. Is this a known issue that is being worked on?

Further testing shows also assent and maneuver modules also require RCS to be turned on to function now.

Edited January 5, 2014 by JeffreyCor
Additional information

[skips]

I did some landing tests with dev157 using a small test ship that I have. It has no parachutes, a TWR of 4.67 and a little more than 5000 m/sec dv. I performed a half dozen launches with the ascent guidance to a 100 km orbit and landings at the KSC launch pad. All of the landings were consistent with each other.

The predicted landing errors after the orbit correction burns were between -85 and +45 meters, where negative is short of the landing point.

The predicted landing after entering the atmosphere appeared to decrease by approximately 250 meters. i.e., the predicted landing point moved closer to the spacecraft.

After the aero-braking (at 13 km) the error had increased by approximately 50 meters. i.e., the spacecraft decelerated more slowly than the prediction.

During the final decent, the error increased by an additional 125 meters and stabilized at the point at which the suicide burn began.

For the case where the prediction in vacuum was 45 meters long (past the target), the ship landed within 1 meter of the target. For cases where the vacuum errors was 70 meters short of the target, the ship landed approximately 140 meters short of the target.

I draw two tentative conclusions from these observations.

• the aero-braking code slightly over-estimates the amount of braking that the drag forces produce.
  
• there is a change of the reference frame at or about the time that the final killing of the horizontal velocity occurs, which has the effect of giving the ship the rotational velocity of the landing point whereas the simulation is expecting the landing point to rotate under the descending ship.
  

On the other hand the dispersion in the landing points appears to be reasonable given that the simulation does not make additional corrections in decent path after the aero-braking. At orbital velocities, a 200 meter dispersion is only 0.1 seconds time dispersion. I would have thought that the simplest approach for handling the level of precision that is needed would be to plan to overshoot the landing point and at some point after the majority of the aero-braking was complete to further kill the horizontal velocity with the engines. I am guessing that this approach is the way codepoet is getting the parachute landings to be accurate by timing the opening of the parachutes (which effectively eliminate the horizontal velocity).

skips

[Bobe]

When you say it was burning away from the planet indefinitely, was it one of those burns where you eventually reach escape velocity out of duna into Kerbol SOI?

Is there anything in the debug log when it does? Like errors?

I never let it get that far, but I'm sure it would have.

I wouldn't even know where to being looking in the log as it was some time ago now, but if I can recreate it I'll take a look.

[Shad0wCatcher]

Had an error earlier in 157 causing a powered landing failure. Log available. It's probably mod-related however (was using a KSPI Anti-matter powered thermal rocket fueled by water) along with realchutes, FAR, and DRE.

Caused by the following:

Set landing autopilot to land at KSP launchpad with ~8.5 Km of dV left (of 16 Km) at 700 Km orbit.

No parachutes installed.

MJ proceeds to spam log with the following:

MechJeb module MechJebModuleLandingAutopilot threw an exception in Drive: System.ArgumentException: OrbitExtensions.NextTimeOfRadius: given radius of 603333.214716728 is never achieved: o.PeR = 603771.573203481 and o.ApR = 1299760.2823296

  at MuMech.OrbitExtensions.NextTimeOfRadius (.Orbit o, Double UT, Double radius) [0x00000] in <filename unknown>:0 

  at MuMech.MechJebModuleLandingAutopilot.ComputeCourseCorrection (Boolean allowPrograde) [0x00000] in <filename unknown>:0 

  at MuMech.MechJebModuleLandingAutopilot.DriveCourseCorrections (.FlightCtrlState s) [0x00000] in <filename unknown>:0 

  at MuMech.MechJebModuleLandingAutopilot.Drive (.FlightCtrlState s) [0x00000] in <filename unknown>:0 

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

Craft continually corrects landing site; at one point it attempted to obtain some type of periapse (1.6km)

Edited January 5, 2014 by Shad0wCatcher