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

[codepoet]

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.

Cliffs are really tricky - because when using parachutes, the game itself will fully deploy the parachutes when the AGL is at a certain level. However it is not possible for the simulation to simulate this because as the "thread / terrain" problem that we worked around earlier in the day (#154) demonstrated, it is not possible for the simulation thread to acccess the terrain data. (well at least at the moment it does not seem to be) The best advice I can give you is either:

1) land on a flat area

2) land on body with a thick atmosphere so that you are not going so much horizontal at low parachute triggering altitudes.

3) land at a low altitude location where the atmopshere it thicker (it makes a big difference for Duna)

4) tweak your parachutes to all deploy at slightly different altitudes (with say 200m between each). That way after each semi deployment the autopilot has a chance to adjust when it will semi deploy the next one, to continue targeting.

[Galane]

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.

What I keep getting on everything with reaction wheels is they flip back and forth between operational and not enough electricity, even though there's plenty of power from batteries, solar panels, RTGs or any combination.

Edited January 4, 2014 by Galane

[DrBackjack]

What I keep getting on everything with reaction wheels is they flip back and forth between operational and not enough electricity, even though there's plenty of power from batteries, solar panels, RTGs or any combination.

I've noticed that too, but it doesn't actually seem to affect the use of the reaction wheels.

[Starwaster]

Cliffs are really tricky - because when using parachutes, the game itself will fully deploy the parachutes when the AGL is at a certain level. However it is not possible for the simulation to simulate this because as the "thread / terrain" problem that we worked around earlier in the day (#154) demonstrated, it is not possible for the simulation thread to acccess the terrain data. (well at least at the moment it does not seem to be) The best advice I can give you is either:

1) land on a flat area

2) land on body with a thick atmosphere so that you are not going so much horizontal at low parachute triggering altitudes.

3) land at a low altitude location where the atmopshere it thicker (it makes a big difference for Duna)

4) tweak your parachutes to all deploy at slightly different altitudes (with say 200m between each). That way after each semi deployment the autopilot has a chance to adjust when it will semi deploy the next one, to continue targeting.

Obviously there's nothing you can do to control the game's stock behavior concerning parachutes.

on the other hand, if an elevation change from flight path is enough to force course corrections then that is something you can change. Once de-orbit burn has happened and re-entry is in progress, the AP should be reluctant to take further corrective action. Take samples over time. Average them. If the results are WAY off from the pre deorbit calculation by a TBD threshold then dont take action, wait and take samples again later in the flight path

[Galane]

Obviously there's nothing you can do to control the game's stock behavior concerning parachutes.

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

[Shad0wCatcher]

Just had a MJ failure using 154 that logged 50 megabytes within a couple minutes @ 150-160 faults a second (Guestimating...that's 150-160 writes to disk...every second. I'd REALLY like to keep my raptors alive another couple years).

MechJeb module MechJebModuleTargetController threw an exception in OnFixedUpdate: System.NullReferenceException: Object reference not set to an instance of an object

  at MuMech.CelestialBodyExtensions.TerrainAltitude (.CelestialBody body, Double latitude, Double longitude) [0x00000] in <filename unknown>:0 

  at MuMech.PositionTarget.Update (.CelestialBody body, Double latitude, Double longitude) [0x00000] in <filename unknown>:0 

  at MuMech.MechJebModuleTargetController.OnFixedUpdate () [0x00000] in <filename unknown>:0 

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

(Filename: C:/BuildAgent/work/ea95e74f6e5f192d/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54)

Game Paused!

multiply that by 60,000+ lines.

also the following:

NullReferenceException: Object reference not set to an instance of an object
  at MuMech.GLUtils.DrawMapViewGroundMarker (.CelestialBody body, Double latitude, Double longitude, Color c, Double rotation, Double radius) [0x00000] in <filename unknown>:0 

  at MuMech.MechJebModuleTargetController.DrawMapViewTarget () [0x00000] in <filename unknown>:0 

  at MuMech.MechJebModuleTargetController.DoMapView () [0x00000] in <filename unknown>:0 

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at RenderingManager.OnGUI () [0x00000] in <filename unknown>:0 

(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at MuMech.GLUtils.DrawMapViewGroundMarker (.CelestialBody body, Double latitude, Double longitude, Color c, Double rotation, Double radius) [0x00000] in <filename unknown>:0 

  at MuMech.MechJebModuleTargetController.DrawMapViewTarget () [0x00000] in <filename unknown>:0 

  at MuMech.MechJebModuleTargetController.DoMapView () [0x00000] in <filename unknown>:0 

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at RenderingManager.OnGUI () [0x00000] in <filename unknown>:0 

(Filename:  Line: -1)

dT is NaN! tA: 1.20605957508087, E: 0, M: 0, T: NaN

(Filename: C:/BuildAgent/work/ea95e74f6e5f192d/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54)

Camera Mode: AUTO

(Filename: C:/BuildAgent/work/ea95e74f6e5f192d/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54)

ASE -- Switching to Vacuum

by another 30-60,000 lines of code.

What occurred prior to the errors that are destroying my hard drives with read/writes

Had a double probe launch vehicle sent to the Mun

Successfully orbited at 33 kilometers (my first mistake; what I get for using an OP injection stage @ 800+ kN of thrust to push an 8 ton vehicle)

Successfully decoupled both probes from the Munar Injection stage

Successfully renamed both probes post decouple (MJ did it's usual failure to update the probes with any vessel information; but I built 'em with approximately 2.3k dV each to land and return)

One set to land at the Munar Highlands 68 degrees 30 minutes south; 45 degrees 15 minutes west

The other set to land in the Highland Craters

Highlands probe set to landing guidance at the coordinates posted above

Successfully performed low-orbit plane change

MJ locks at 0 m/s plane change and starts eating HDD life.

Game is currently paused with a quicksave prior to the landing maneuver.

Edited January 4, 2014 by Shad0wCatcher

[drtedastro]

nothing wrong with a good stress test once in a while....

[Shad0wCatcher]

I have other more specialized software for testing. I'd like to get this fixed so I don't have to stress the hell out of parts of this computer as I currently don't have the liquid assets to replace anything.

[codepoet]

Obviously there's nothing you can do to control the game's stock behavior concerning parachutes.

on the other hand, if an elevation change from flight path is enough to force course corrections then that is something you can change. Once de-orbit burn has happened and re-entry is in progress, the AP should be reluctant to take further corrective action. Take samples over time. Average them. If the results are WAY off from the pre deorbit calculation by a TBD threshold then dont take action, wait and take samples again later in the flight path

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.

There is of course another approach which is to take control of when the parachutes are deployed back from the game (by setting the deployment height to be zero under the covers, and then setting it to be the current AGL at the moment the autopilot wants to fully deploy them. However this fiddling would be visible to the user via tweakables, and they would be able to interfere with it by tweaking it .

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.

* in fact this new approach to parachutes reduces the urge to make course corections by timing when to deploy the parachutes instead. On the data handling side - it is infact using a statistical analysis on the prediction results, and employing a linear regression technique (least square method) to predict when to activate the 'chutes. It is also running extra preditions with deliberate variations in the parachute activation time to improve the quality of the data set that is used to time the parachutes. If you are interested, then I have just committed some updates that display some of this imformation so you can see how the quality of the prediction data varies throughout the landing approach.

Edited January 4, 2014 by codepoet
spelling

[codepoet]

Just had a MJ failure using 154 that logged 50 megabytes within a couple minutes @ 150-160 faults a second (Guestimating...that's 150-160 writes to disk...every second. I'd REALLY like to keep my raptors alive another couple years).

MechJeb module MechJebModuleTargetController threw an exception in OnFixedUpdate: System.NullReferenceException: Object reference not set to an instance of an object

  at MuMech.CelestialBodyExtensions.TerrainAltitude (.CelestialBody body, Double latitude, Double longitude) [0x00000] in <filename unknown>:0 

  at MuMech.PositionTarget.Update (.CelestialBody body, Double latitude, Double longitude) [0x00000] in <filename unknown>:0 

  at MuMech.MechJebModuleTargetController.OnFixedUpdate () [0x00000] in <filename unknown>:0 

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

(Filename: C:/BuildAgent/work/ea95e74f6e5f192d/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54)

Game Paused!

multiply that by 60,000+ lines.

also the following:

NullReferenceException: Object reference not set to an instance of an object
  at MuMech.GLUtils.DrawMapViewGroundMarker (.CelestialBody body, Double latitude, Double longitude, Color c, Double rotation, Double radius) [0x00000] in <filename unknown>:0 

  at MuMech.MechJebModuleTargetController.DrawMapViewTarget () [0x00000] in <filename unknown>:0 

  at MuMech.MechJebModuleTargetController.DoMapView () [0x00000] in <filename unknown>:0 

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at RenderingManager.OnGUI () [0x00000] in <filename unknown>:0 

(Filename:  Line: -1)

NullReferenceException: Object reference not set to an instance of an object
  at MuMech.GLUtils.DrawMapViewGroundMarker (.CelestialBody body, Double latitude, Double longitude, Color c, Double rotation, Double radius) [0x00000] in <filename unknown>:0 

  at MuMech.MechJebModuleTargetController.DrawMapViewTarget () [0x00000] in <filename unknown>:0 

  at MuMech.MechJebModuleTargetController.DoMapView () [0x00000] in <filename unknown>:0 

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at (wrapper delegate-invoke) Callback:invoke_void__this__ ()

  at RenderingManager.OnGUI () [0x00000] in <filename unknown>:0 

(Filename:  Line: -1)

dT is NaN! tA: 1.20605957508087, E: 0, M: 0, T: NaN

(Filename: C:/BuildAgent/work/ea95e74f6e5f192d/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54)

Camera Mode: AUTO

(Filename: C:/BuildAgent/work/ea95e74f6e5f192d/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54)

ASE -- Switching to Vacuum

by another 30-60,000 lines of code.

What occurred prior to the errors that are destroying my hard drives with read/writes

Had a double probe launch vehicle sent to the Mun

Successfully orbited at 33 kilometers (my first mistake; what I get for using an OP injection stage @ 800+ kN of thrust to push an 8 ton vehicle)

Successfully decoupled both probes from the Munar Injection stage

Successfully renamed both probes post decouple (MJ did it's usual failure to update the probes with any vessel information; but I built 'em with approximately 2.3k dV each to land and return)

One set to land at the Munar Highlands 68 degrees 30 minutes south; 45 degrees 15 minutes west

The other set to land in the Highland Craters

Highlands probe set to landing guidance at the coordinates posted above

Successfully performed low-orbit plane change

MJ locks at 0 m/s plane change and starts eating HDD life.

Game is currently paused with a quicksave prior to the landing maneuver.

That looks bad! The stack trace looks like it is related to drawing the target markers on the map, but there is also a stack trace that mention the dreaded TerrainAltitude I am not familiar wit that area of code, but can take a look.

* Were you in mapview when these logs occur?

* can you reproduce the problem by reloading the save / restoring the quicksave and doing the same thing again?

[codepoet]

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

I recomend you do. In fact I recommend that you set each parachute to have a slightly different deployment height. Thats way after each (semi deployment) there is a oppertunity to the landing site to be further refined by adjusting when then other parachutes are deployed. It will also reduce your max-g but not just popping everything at once.

[Shad0wCatcher]

I tried to reproduce but it was just a one-off. After loading the quicksave it functioned as it should have. I started in flight mode; switched to map-view to confirm the landing site; once it got close I switched back to flight-mode and counted down the last hundred or so dV (600 dV plane-change at 33 kM...almost lost that lander. go go overengineering!) Really really like that change that shows approximations of dV usage.

[codepoet]

I tried to reproduce but it was just a one-off. After loading the quicksave it functioned as it should have. I started in flight mode; switched to map-view to confirm the landing site; once it got close I switched back to flight-mode and counted down the last hundred or so dV (600 dV plane-change at 33 kM...almost lost that lander. go go overengineering!) Really really like that change that shows approximations of dV usage.

I don't suppose you saved off the log file with all the errors in did you? If so send me a PM and I will give you an email address to send it to. It sounds like that could be a hard to track down bug.

On the predicted delta-v - It is not particulatly acurate. It is the delta-v predicted to be used in the deceleration burn plus a bit. However the simulation does not simulate the final decent stage inthe way that it is performed, so there are some hacky approximations for that bit. However I do enjoy seeing it change during the course correction burn on Duna - at higher landing altitudes the delta-v is higher as the parachutes are of less use, and at lower altitudes it is lower as the atmosphere contributes more to the braking.

[Shad0wCatcher]

I still have the log. It's 53 megabytes though. I can see about trimming some of it if you want it.

EDIT: Oh right. Plain text. Compressed to 914 KB.

Also there will be some erroneous information toward the end (namely renderer lost as I paused the game then alt-tabbed as soon as it occurred).

Edited January 4, 2014 by Shad0wCatcher

[sarbian]

Just had a MJ failure using 154 that logged 50 megabytes within a couple minutes @ 150-160 faults a second (Guestimating...that's 150-160 writes to disk...every second. I'd REALLY like to keep my raptors alive another couple years).

There is that little thing called cache in modern OS. It won't write to the disk 150 times per seconds and eve if it did it would not change anything to the life of a Hard Drive, and even an SSD life wouldn't change much.

I'll add some NRE test to find this one...

[Shad0wCatcher]

Off Topic: 4 gigs of physical RAM; 2.5 gigs used by KSP. 1.2 gigs used by some of the OS (Windows Vista); most of the rest eaten up by other processes. When I can hear my Raptors' read-write heads crunching along at a rapid rate there's an issue. 4 MB cache in each. I'm well aware of when and how much my system is being taxed.

Back on topic; thanks much. Like I posted above, I have the full unedited log file compressed (just zip) still if you would find it helpful in any way.

[sarbian]

Yes, post the ziped log somewhere please. I want to see if there is something that make all the mainbody ref null ...

Edit : I re read your description of the event. Did it start to crash when the probe were getting away from each other ?

Edited January 4, 2014 by sarbian

[Shad0wCatcher]

Kk, I took a look through and didn't see anything. Installing Dropbox.

https://www.dropbox.com/s/7n417ja2exdrp2v/output_log.zip

Edited January 4, 2014 by Shad0wCatcher

[sarbian]

Thanks. With your log I have found the origin of the crash (something wrong in .23) and I'am trying to fix it now ...

[Shad0wCatcher]

Good stuff. Glad to be of service in the small way I can. Apologies for sounding terse earlier. When I hear the level of HDD activity I heard with that error log I cringe (it's only happened a couple times in the past with other more demanding software). I have to say though 154 has been absolutely flawless with what I've used apart from that one-off error. You and codepoet have been doing some solid stuff. Really appreciate it, even if I do sound like an ass from time to time.

[codepoet]

Good stuff. Glad to be of service in the small way I can. Apologies for sounding terse earlier. When I hear the level of HDD activity I heard with that error log I cringe (it's only happened a couple times in the past with other more demanding software).

Think of this this way - your HDD was busy taking one for the team, so that we could have the data that has allowed Sarbian to diagnose the problem. A good example for others to emulate

[sarbian]

I pushed a 2 new builds.

155 is codepoet last set of change (info + precision mostly)

156 is a fix for the NRE spam on decouple/undock.

Shad0wCatcher it will fix your error. I am not a fan of the "fix" but this will do for now.

I think there was an other NRE spam related to undocking ? I need to re read the last page of the thread ...

I think I take a break and play for the rest of the day. Those .23 related bugs annoys me since most of them come from bugs in KSP itself.

[katalex-3]

156 - really work version? Just after install it i have crash in angar.

[drtedastro]

I pushed a 2 new builds.

155 is codepoet last set of change (info + precision mostly)

156 is a fix for the NRE spam on decouple/undock.

Shad0wCatcher it will fix your error. I am not a fan of the "fix" but this will do for now.

I think there was an other NRE spam related to undocking ? I need to re read the last page of the thread ...

I think I take a break and play for the rest of the day. Those .23 related bugs annoys me since most of them come from bugs in KSP itself.

It seems that .23 'broke' a lot of items in a lot of mods. Do the dev's release a list of what was changed, or do you have to find all of the new 'features' on your own...????

thanks for all of the great work and great mod....

[katalex-3]

157 - I can't see MJ in toolbar.