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

[THobson]

I am a newbie here so forgive me for the rather basic question, but what do I need to unlock in Research to activate the Docking Assistant?

Many thanks.

[sarbian]

Have a look at the second link in my signature.

[codepoet]

I dropped back to the dev152 build, and the anomaly went away. Two landing attempts, no explosions. So whatever the problem is, it's confined to the 153 build.

BARCLONE,

Thank you for providing logs and other helpful information in your reports. Your information was very helpful in guiding me towards what I think was the cause of some of the bizzare stuff in the logs about the terrain system. My terrain rendering problems seem to be fixed now too. I have offered the fix up, so hopefully it will be in a dev build soon.

[CleverLikeMe]

Has anyone noticed MJ miscalculating burn times for simple maneuver nodes (hohman transfers, circularizations, etc). Latest dev version seems to be starting burns significantly later than before (resulting in a lopsided distribution of thrust relative to the node)

[LameLefty]

Just got done with some tests on build 153. The results were not so good.

Rather than tempt fate with Eve for the umpteenth time I excavated an old AARP Stock Lander 1, built of all stock parts back in .21. Didn't want any non-stock parts to possibly cause any problems. Hyperedited to a 20KM Mun orbit, picked a smooth looking spot as a landing target, zeroed to put it right on the equator then poked the land at target button.

It turned retrograde, did the initial deorbit burn, flipped prograde to do a little correction burn then it kept the engine at idle, burning prograde

and headed for higher altitude.

I had the same problem last night landing on Laythe. With "Show Landing Prediction" checked and my lander approaching the aim point roughly northwest-to-southeast, during the high deorbit burn, I watched Map view as the blue prediction marker moved westward down the orbital track and approach the red target marker, but then keep right on sailing several hundred km past and well short of the target. MJ would then try a >200 m/s correction burn to lengthen the landing approach, but instead push right back into an oddball highly elliptical orbit. I reverted to a quick save and tried again twice with the same results.

I was finally able to land by first clicking "Land at Target" and then at the point in time when the blue and red markers roughly overlapped during the high deorbit burn, aborting the auto landing. I then monitored the reentry and tweaked it a bit with RCS to get the miss distance down to around 700 m. Once I was well through the atmosphere and coasting toward the target at about 20 km altitude, I clicked "Land at Target" - this time MJ did a few m/s correction burn to get the miss-distance down to about 140 meters, finished the coasting trajectory, popped the chutes and landed at a nice, easy 1 m/s (which is what I have it set for).

Now I will say that the initial orbit I was landing from was inclined at 30º on purpose so I would overfly more of those archipelagos on Laythe, and the orbit was quite elliptical. However, I was landing on the descending node and very close to perigee; the reentry burn started at around 100 km altitude. Furthermore, the aim point was almost dead-on the ground track, requiring little to no cross-range correction. So the first part of the landing autopilot worked great, as did the actual landing once I was well into the coast phase.

[sarbian]

BARCLONE,

Thank you for providing logs and other helpful information in your reports. Your information was very helpful in guiding me towards what I think was the cause of some of the bizzare stuff in the logs about the terrain system. My terrain rendering problems seem to be fixed now too. I have offered the fix up, so hopefully it will be in a dev build soon.

Soon like now

#154 is up

Has anyone noticed MJ miscalculating burn times for simple maneuver nodes (hohman transfers, circularizations, etc). Latest dev version seems to be starting burns significantly later than before (resulting in a lopsided distribution of thrust relative to the node)

I had some report about that but I had trouble duplicating it. At one point I thought it was the autowarp exiting too late but now I don't think so. Is it with all you ship ?

Edit : I had an idea just now. This may be related to the same kind of problem Codepoet just fixed in #154. The burn system use a thread too, so it may crash silently and report false value. I'll test that theory tonight.

LameLefty : It's one of the long standing bug for the landing AP I need to track down.

Edited January 3, 2014 by sarbian

[Tex_NL]

Question: Does the latest dev build use SAS reaction wheels properly? (Or will future versions?)

Some time ago I had a single engined lander with a very minor mass imbalance. Mechjeb's landing guidance was not able to keep it under control. When MJ throttled up, the lander started to rotate. MJ throttled down and re-aligned the craft only to let it rotate again as soon as it throttled up. And the cycle continued resulting in rapid disassembly on the Munar surface. MechJeb ran out of space and time to perform a proper landing. But when I tried to manually land my lander it performed flawlessly. I simply turned on the SAS and throttled up: no rotation at all. It flew as it was on rails, like it was perfectly balanced.

So it must have been MechJeb that was at fault. The reaction wheels were more than capable of keeping the lander stable. MechJeb just didn't use them.

[sarbian]

MJ use the reaction wheel properly since they exist, and used the previous system too. Torque in space is well handled since the RCS change around april/may. You crash may be related to something else.

"Some time ago" does not allow me to tell you this or that has been fixed since then.

[Tex_NL]

'Some time ago' as in 'last month'. It was with MechJeb v2.1.0 in KSP 0.23.

Edited January 3, 2014 by Tex_NL

[LameLefty]

LameLefty : It's one of the long standing bug for the landing AP I need to track down.

Ah, thank you sir!

Well for now, since I know it's a know bug, I'll be looking for it carefully and trying to work around it. The good news is once I had actually entered atmosphere and was coasting, codepoet's parachute landing routines worked great!

[sarbian]

Since .23 I fixed a bug with the Reaction Wheel where MJ tough they were offline from time to time (related to a KSP change in .23). And I a bug for torque from gimbal for engine with more than 1 nozzle.

So that may be one of those 2, more likely the first one, of an other bug. Trying the last version is the best way to see.

[BARCLONE]

I have seen some of the problems you describe in development and testing - however I think they became apparent to me when I moved up to 0.23, so I had concluded that they were a 0.23 thing. Interestingly they all seem to relate to the terrain system, which I have discussed a lot with Sarbian. In my own game I sometimes see distortions in the terrain (see picture below) after moving to 0.23 and the log that you quoted contains exceptions all related to terrain vertices and "PQS" which I do not understand, but believe is related to the celestial body / terrain system. In my own game I sometimes see a log saying "PQS Duna: Restarted", at which point the terrain visual distortion disappears. Finally on your report that a part of your craft magically exploded - I once had a similar thing happen in testing - one of my engines exploded when I was 1000m AGL. When I checked the flight report (f3) it said that the engine had impacted the ground, which sounds a bit like the terrain had momentarily rush up to mee the craft.

So I have my suspicions that there is something wacky going on with the terrain system. I also have suspicions that it is related to thread saftey, so perhaps there is a way forward to address it.

http://s24.postimg.org/hknjvuwyt/screenshot1.png

I am sure that you will understand why getting a landing autopilot to work well in an environment when the ground you are trying to land on is literally constantly shifting is a challenge!!

Those terrain anomalies were showing up in my copy, too. I just figured (like you did) it was part of the "new" Unity engine, and it would sort itself out in time.

I just tested dev154 with my 10th lander, and it went smooth from launch to touchdown. The terrain also seems to be better stitched together.

Thank you for providing logs and other helpful information in your reports. Your information was very helpful in guiding me towards what I think was the cause of some of the bizzare stuff in the logs about the terrain system. My terrain rendering problems seem to be fixed now too. I have offered the fix up, so hopefully it will be in a dev build soon.

You guys are more than welcome! I'm just happy to (finally) be of useful assistance. I have no idea what those entries mean, other than recognizing they're telling me something dreadful this way comes, but I figured you did...

Since dev154 may have cleared things up, I'm going back to testing my other mods for compatibility.

[sarbian]

Ah, thank you sir!

Well for now, since I know it's a know bug, I'll be looking for it carefully and trying to work around it. The good news is once I had actually entered atmosphere and was coasting, codepoet's parachute landing routines worked great!

I have seen it with TWR < 1 on body without atmo. I would not really call this one a bug since it's more MJ trying to save his skin

The real bug is when it happens on body with atmo, and it's the case I never manage to duplicate at will.

You may have seen it on Duna on version < 150 since MJ thought Duna atmo was too thin and used the "no atmo" landing proc.

I should make a post to explain how the landing AP work. This may help clear misunderstanding and make testing more useful.

[LameLefty]

I have seen it with TWR < 1 on body without atmo. I would not really call this one a bug since it's more MJ trying to save his skin

The real bug is when it happens on body with atmo, and it's the case I never manage to duplicate at will.

You may have seen it on Duna on version < 150 since MJ thought Duna atmo was too thin and used the "no atmo" landing proc.

I should make a post to explain how the landing AP work. This may help clear misunderstanding and make testing more useful.

Such a post would be great!

My testing last night was on Laythe with a lander that has t/w ratio substantially >1, and lots of parachutes. The idea of the design was to be able to enter mostly with 'chutes and have plenty of fuel for ascent and return to orbit.

[houlihan]

I should make a post to explain how the landing AP work. This may help clear misunderstanding and make testing more useful.

+1. This could be really helpful - if we're all on the same page as to what we should expect then pulling out real bugs would (should?) be easier.

[codepoet]

+1. This could be really helpful - if we're all on the same page as to what we should expect then pulling out real bugs would (should?) be easier.

I would have liked to have had that post before I started fiddling with the code to try to make it do things!

On the subject of things that are helpful in debugging the landing, in recent changes I added some good chunky logging that outputs lots of details about each simulation that is run by the predictor. I accidentally left it turned on in 153 (some of you might have spotted it), but it is now turned off again. I wonder if it would be helpful to have a way of allowing the user to enable it to provide more data for dogey landing reports.

[BARCLONE]

I would have liked to have had that post before I started fiddling with the code to try to make it do things!

On the subject of things that are helpful in debugging the landing, in recent changes I added some good chunky logging that outputs lots of details about each simulation that is run by the predictor. I accidentally left it turned on in 153 (some of you might have spotted it), but it is now turned off again. I wonder if it would be helpful to have a way of allowing the user to enable it to provide more data for dogey landing reports.

I would suggest you leave it in, at least for all of these dev builds. You can then take it out for the "official" release to reduce binary size. It wouldn't hurt if this code were even more "chunky", as it might help the rest of us spot the areas you're needing to see, and then we can cut-n-paste those log outputs in our posts here.

Can your debug code produce "comment lines" in the log? The more information it can insert, the better.

[codepoet]

I would suggest you leave it in, at least for all of these dev builds. You can then take it out for the "official" release to reduce binary size. It wouldn't hurt if this code were even more "chunky", as it might help the rest of us spot the areas you're needing to see, and then we can cut-n-paste those log outputs in our posts here.

Can your debug code produce "comment lines" in the log? The more information it can insert, the better.

The debug I am refering to looks like this:

Result:LANDED Time to run: 81 millisecondsBetweenSimulations: 5 new dt: 0.459811685506734 Time.fixedDeltaTime 0.02

Simulation result

{Inputs:

{

input_initialOrbit: Orbit

input_UT: 1321610.72414121

input_dragMassExcludingUsedParachutes: 3.66099241206038

input_mass: 19.9049718244169

input_descentSpeedPolicy: MuMech.PWBCoastDescentSpeedPolicy

input_decelEndAltitudeASL: 6738.53968487917

input_maxThrustAccel: 8.64291605903644

input_parachuteSemiDeployMultiplier: 3.59487877296827

input_probableLandingSiteASL: 5702.35211155534

input_multiplierHasError: False

input_dt: 0.378445831692785

}

id: 9c8c6afa-56bf-4edf-a95c-51b444876529

outcome: LANDED

maxdt: 0.378445831692785

timeToComplete: 525.997448260896

endUT: 1322136.72158948

startPosition: [-23.0430221537827, 3.00457021516922, 30.2319142802444]

endPosition: [-4665.69690810953, -206.856225475352, -24085.6099024956]

endASL: 0

endVelocity: 25.6101039850263,-0.172424142452214,31.1141657672668

maxDragGees: 6.36675957639426

deltaVExpended: 1497.89297021537

multiplierHasError: False

parachuteMultiplier: 3.59487877296827

}

Which is probably Dutch to most people, but to those who are familiar the reentry simulations it shows for each prediction what the "inout parameters" were (ie all the information that describe the situation the craft is in at that moment) and then the outcome - did it land, aerobrake, timeout, not reenter etc, what the start and end locations were, how long it took, how much drag it pulled etc, how much delta-v it burned, how the parachutes were used etc etc. If someone is complaining about a landing seeing how this infomation developped over time as each prediction was run could be very helpful in diagnosing what was going on.

However, the problem with debug output / trace / logging is that is it always a balance between providing information against impacting performance and the size of the log. If I tell you that the landing predictor aims to perform at least 5 of these simulations per second, then you can see that you can quickly grow your log to be unhelpfully large. However if someone says that they can reproduce a problem, it is helpful information to get of the devs.

Anyhow it is a decision for someone other than me to make - Sarbian perhaps, or others. I sure some conversations will happen behind the scenes!

[BARCLONE]

UPDATE: HullCameraVDS works. I was able to watch through the cam after separation of the lander, even switch back-and-forth for a while, without the lander crashing or becoming uncontrollable. It didn't rotate around like I hoped, but it didn't crash. That's more important.

Next mods to test: KAS and MagicSmokeIndustries

[BARCLONE]

First landing attempt at the Center, dev154, using the Landing Guidance autopilot, selecting "Target KSC" and not "Target VAB"...

Landed on top of the VAB, just a couple of meters west of the center of the eastern "H" on the VAB roof...

And I manually triggered the parachutes just as the ship dropped below 10 KM and 300 m/s...

Really good tweaking, guys!

[skips]

I have two observations using dev154.

1. there still appears to be some sort of thread synchronization issue. After landing, I observed that the target difference value jitters from the nominal 193 m to some value in the hundreds of km (the value flashes on the screen for one update so the visual latencies only allow me to see a composite of the value with 193 m). The window for the issue must be relatively small because the flashes only occur at about 3-5 second intervals.

2. the predicted delta-v value does not seem reasonable. On most of my landings, I see values like 10,000 m/sec at altitudes of 5-7 km. On the last landing at 5 km the vertical velocity was like 175 m/sec. To just make it to landing with zero velocity takes 12.87 m/sec2 deceleration for 57.14 seconds or 735 m/sec delta-v, which is like an order of magnitude less than the value that is being reported. Since I ignored air drag, the actual required delta-v from the engine is probably somewhat less than my estimate.

skips

[sarbian]

And I manually triggered the parachutes just as the ship dropped below 10 KM and 300 m/s...

I find your lack of faith disturbing.

[codepoet]

I have two observations using dev154.

1. there still appears to be some sort of thread synchronization issue. After landing, I observed that the target difference value jitters from the nominal 193 m to some value in the hundreds of km (the value flashes on the screen for one update so the visual latencies only allow me to see a composite of the value with 193 m). The window for the issue must be relatively small because the flashes only occur at about 3-5 second intervals.

2. the predicted delta-v value does not seem reasonable. On most of my landings, I see values like 10,000 m/sec at altitudes of 5-7 km. On the last landing at 5 km the vertical velocity was like 175 m/sec. To just make it to landing with zero velocity takes 12.87 m/sec2 deceleration for 57.14 seconds or 735 m/sec delta-v, which is like an order of magnitude less than the value that is being reported. Since I ignored air drag, the actual required delta-v from the engine is probably somewhat less than my estimate.

skips

I would be helpful to get some log of that, only I have removed the logging!

On the delta-v, I am surprised to hear that it is in the 10000 range. It is not completely acurate anyway - it will be the delta-v needed up the the "final decent" step, But I though I would display it as that would motivate us to make it accurate! I have been doing a bit more tweaking - in particular managing when the parachute targeting stuff gives up because the data makes no sense, and how it can start getting good data again.

I have added several things to the display (quality and amount of parachute prediction data, time to landing, time to aerobrake exit) so that folks can monitor them and report if things look like they are going wrong. I have also rearranged the layout a little to hopefully have it make more sense: Targeting, Predictions, Control, and Status.

I am also tweaking the amount of type of simulations that are executed to try an improve the parachute situation on Duna.

[BARCLONE]

I find your lack of faith disturbing.

I'll try out the parachute deployment function before long. My ship configuration needs to punch off a service module before re-entry (think Apollo-style ship using the NovaPunch Odin...).

[RabidMonkey]

Would it be possible to add the ability to specify a particular amount of allowable error in the "Land at Target" routine? It seems like if I'm coming in for a landing site and the path crosses a cliff, my ship starts oscillating between "correcting" for a difference of a couple hundred meters and starting its coast toward a landing within millimeters of the target location.