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

[sarbian]

Toyotawolf : be aware that in .23.5 the game display days in Kerbin time now (1 day = 6h). There is an option in KSP settings to change that back.

Dev 243...

Sarbian and Duck,

I think I might be starting to understand what the connection is between the navball drift and the low-thrust region of the engines. The navball is keying off of the torque stabilization, and that value is falling when the engines tail off. In essence, the navball is basing its thrust vector off of the maximum available torque, which is OK while the engines are running above a certain throttle value. But when the engines tail off, so does the maximum torque, and thus, so drifts the thrust vector.

I haven't tested this by using the "Stock SAS" setting, but since this appears to be a dynamic action, and the torque is a calculated value based on engine power, I think it makes sense.

Thoughts?

Err Yes. Actually it's voluntary. Let me explain why, and how it will be fixed (or not) :

in the past I had this wonder full idea that torque would be so much better if we used the current thrust. I changed the code and all was fine at first look. Then I added the "cosine loss" calculation. Then some time later people complained that the translatron was not working anymore, so I reverted some of those code.

The problem is that for both code to work together I need the know the "rest" position for a gimbaled engine. The game does not provide that to mods for now (the value is "protected" for those who code). I asked the devs to change that, and wait to see if we get it in .24. If it not changed for .24 then I have an other solution (use reflection, I did it in my Auto Trim mod) but it's a bit messy and would break MJ when the dev do the change (easy to fix, but it would not show up at compile).

So for now we wait

[Nudles]

edit: Double post

Edited May 8, 2014 by Nudles

[Nudles]

I think this is the right place to post this. I don't know if this is a MechJeb, game or other bug, or what.

Low frame rate youtube vid: http://youtu.be/sUOPhwqmR2M

Higher frame rate but lower bitrate version: http://tinypic.com/r/jgs1w9/8

As the video somewhat shows, the camera is jittery when running the delta v window in MechJeb, the framerate is fine though (on my screen).

It does not go like this when the other MechJeb windows are open, just the delta V window. This happens inside, and outside when 'flying'.

It's much harder to tell in youtube videos, because it makes everything jittery.

The jittering I am talking about are the sudden jumps every few seconds. On my screen, it is silky smooth, except at those points.

My guess is that MechJeb Delta V calculator is recalibrating its stats every few seconds, causing it to do this.

Anyone got a suggestion on how to fix this?

Other mods installed: Kerbal Alarm Clock, Enhanced Nav Ball

Computer specs are: i5 3570k, AMD HD 7950, SSD and 8gb ram.

[phoenix_ca]

It's much harder to tell in youtube videos, because it makes everything jittery.

It's extremely difficult to tell. You could try using FRAPS to record frame rate over time, then import the data to any spreadsheet editor and graph it. That would show the spikes better, as well as their frequency. Though what would really be more useful is the render time for each frame, but I can't recall what has that...maybe MSI Afterburner.

[Nudles]

It's extremely difficult to tell. You could try using FRAPS to record frame rate over time, then import the data to any spreadsheet editor and graph it. That would show the spikes better, as well as their frequency. Though what would really be more useful is the render time for each frame, but I can't recall what has that...maybe MSI Afterburner.

Some good ideas there, thanks. I'll look into trying these when I get home. Just as a reference, the most noticeable 'jerk' is at about 8 seconds.

Btw, nice guide on geostationary orbit, I'll be trying that later too.

Edited May 8, 2014 by Nudles

[LameLefty]

Gotta quick question for Sarbian, or any other MJ dev/contributor who may have worked on this part of the code - how does MJ calculate planetary transfer windows, and how does it compare to the way, say, Kerbal Alarm Clock does it?

The reason I'm asking is this: I've spent the last several in-game days staging the components of a multi-part mission to Laythe in medium-Kerbin orbit. I docked the last segment last night, topped off fuel and monoprop in all tanks and components, and then asked MJ to plot a transfer burn to Jool. MJ gave me a burn of about 1930 m/s roughly 6 hours from the time I requested. By contrast, KAC tells me the window to Jool begins in about 66 DAYS. I decided something wasn't right here so I returned to the Space Center and quit the game. I reloaded it this morning and just for grins, I deleted the planned maneuver node and told MJ to calculate it again. This time, I got an estimated burn of ~1907 m/s but in 54 days rather than 6 hours. That's still 10 days sooner than KAC's alarm but at least within the range of reasonable if we presume KAC's alarm is an idealized lowest-energy trajectory point in the window.

I know you guys have bigger fish to fry in the MJ world but any insight is appreciated.

[BARCLONE]

Err Yes. Actually it's voluntary. Let me explain why, and how it will be fixed (or not) :

in the past I had this wonder full idea that torque would be so much better if we used the current thrust. I changed the code and all was fine at first look. Then I added the "cosine loss" calculation. Then some time later people complained that the translatron was not working anymore, so I reverted some of those code.

The problem is that for both code to work together I need the know the "rest" position for a gimbaled engine. The game does not provide that to mods for now (the value is "protected" for those who code). I asked the devs to change that, and wait to see if we get it in .24. If it not changed for .24 then I have an other solution (use reflection, I did it in my Auto Trim mod) but it's a bit messy and would break MJ when the dev do the change (easy to fix, but it would not show up at compile).

So for now we wait

OK, so maybe I am getting closer to understanding this.

I'm trying to think in terms of what can be done now, using available figures.

What about this idea: How does the "stock SAS" value figure into the dynamic value? Or does it? Do you combine the dynamic value from the engines with the static value of the total SAS capacity, or are these values kept separated at this time? What if the SAS total were used as a "baseline" value for a dynamically-generated total? In other words, what if the lowest torque value at any given point in the flight was the combined SAS torque? The torque would never drop below this value as long as the SAS units are powered up.

"Rest" position of the engine -- are you describing the position of the nozzle/chamber assembly (and thus the thrust angle) when the engine is shut down? I would suggest (for now, anyway) setting an arbitrary position of 0-0, or no deflection in any direction. Consider that thrust deflection is the "off-nominal" condition, and that "pro-grade" is the "nominal" condition.

Edited May 8, 2014 by BARCLONE

[sarbian]

When "Use stock SAS" is active MJ does nothing and juste ask the stock KSP SAS code to point "that" way. Works in some case but not well for turning. So when it's active MJ does "nothing" related to turning the ship.

[Nudles]

It's extremely difficult to tell. You could try using FRAPS to record frame rate over time, then import the data to any spreadsheet editor and graph it. That would show the spikes better, as well as their frequency. Though what would really be more useful is the render time for each frame, but I can't recall what has that...maybe MSI Afterburner.

Hi pheonix_ca the fraps suggestion worked perfectly, chart below.

For the first 30 seconds I sat the camera stationary, fewing the rocket in the hanger, holding the mechjeb gadget on my cursor over the rocket. At the 31 second mark, I clicked to attach the object, starting MechJebs delta v calculator and watch again, with the camera stationary. The mean frame rate per second without mechjeb was 170, and with mechjeb running it was 135 and the 'spikes/jittering' started to occur. Each dip/spike gives the average fps (please excuse the redundant part of the y axis title , where i say "FSP Per Second"...) when playing. In the background I can see the vehicles "jumping" very slightly every few seconds. When I ran the conditions in reverse, I got practically the same results, 140 FSP with MechJeb and 180 FSP without. So on average MechJeb is reducing the frames by 40 FSP.

If it is possible to dedicate a single core to MechJeb I would do that, as I think the jittering might be caused by MechJeb hogging the CPU every few seconds.

Original post, for context for others reading.

I think this is the right place to post this. I don't know if this is a MechJeb, game or other bug, or what.

Low frame rate youtube vid: http://youtu.be/sUOPhwqmR2M

Higher frame rate but lower bitrate version: http://tinypic.com/r/jgs1w9/8

As the video somewhat shows, the camera is jittery when running the delta v window in MechJeb, the framerate is fine though (on my screen).

It does not go like this when the other MechJeb windows are open, just the delta V window. This happens inside, and outside when 'flying'.

It's much harder to tell in youtube videos, because it makes everything jittery.

The jittering I am talking about are the sudden jumps every few seconds. On my screen, it is silky smooth, except at those points.

My guess is that MechJeb Delta V calculator is recalibrating its stats every few seconds, causing it to do this.

Anyone got a suggestion on how to fix this?

Other mods installed: Kerbal Alarm Clock, Enhanced Nav Ball

Computer specs are: i5 3570k, AMD HD 7950, SSD and 8gb ram.

[sarbian]

If it is possible to dedicate a single core to MechJeb I would do that, as I think the jittering might be caused by MechJeb hogging the CPU every few seconds.

As you said earlier it's most likely the dV solver that slow down things (there is an other problem specific to the Editor that I'll have an other shot at solving soon). We currently ask Unity to run that in a thread, but Unity does not do real thread so we get that slow down. I can search for other solution but for now the only one I see is waiting for KSP to use Unity 5 (so 2015 most likely...).

I know it's not the answer you hoped for, but that's all I have for now

[Nudles]

As you said earlier it's most likely the dV solver that slow down things (there is an other problem specific to the Editor that I'll have an other shot at solving soon). We currently ask Unity to run that in a thread, but Unity does not do real thread so we get that slow down. I can search for other solution but for now the only one I see is waiting for KSP to use Unity 5 (so 2015 most likely...).

I know it's not the answer you hoped for, but that's all I have for now

Hi sarbian, thanks for the reply , and thanks for MechJeb. MechJeb does so so much that there really is nothing to complain about from me! Great job on it. So if this cannot be addressed, it's really not an issue. Also, my apologies as I did not mention it was version [0.23.5] MechJeb 2.2.1 .

Edited May 8, 2014 by Nudles

[Nudles]

Hi sarbian, thanks for the reply , and thanks for MechJeb. MechJeb does so so much that there really is nothing to complain about from me! Great job on it. So if this cannot be addressed, it's really not an issue. Also, my apologies as I did not mention it was version [0.23.5] MechJeb 2.2.1 .

Now I am noticing it when the Delta V window is not open, although not as pronounced or as frequent. Is it possible to turn it off completely when not in use? And I don't mean for you to go to the trouble of coding that, I mean is there something I can do on my end to stop it making checks whilst the window is not open? Other than not attaching it, of course! Such as an option in a config file, to tell it to do fewer or no checks when no windows are open.

If you're like me, you like graphs. This is it without the frame limiter on.

[sarbian]

What's the software to generate those ? I ll have fun with it in the next few days

[AndreyATGB]

Man I understand that you're losing FPS, but seriously 300? Even for a 144Hz monitor that's way overkill and if you'd limit it to 144 I bet there's no difference with and without MechJeb.

[Yilmas]

Can somebody explain this to me ?

If you set a -90 inclination on the ascent guidance, the orbit info will tell you that it is +90. Why is that ?

[Castun]

Can somebody explain this to me ?

If you set a -90 inclination on the ascent guidance, the orbit info will tell you that it is +90. Why is that ?

A 90' inclination is North, a 180' inclination is to the West, so I'm pretty sure you'd want a 270' inclination to launch to the South.

[NathanKell]

Because inclination is unsigned. +90 = -90 with a different LAN.

EDIT: ninja'd.

[NeoMorph]

0 degrees inclination means flat on the equatorial plane going from west to east which is why your rocket launches the way it does using Mechjeb with the inclination set to 0 degrees. To get the inclination angles use a circular protractor and align east to 0.

[Franklin]

Stupid question probably, but will MechJeb do its thing when I've given it a series of nodes and then switched to a different ship? Or will it only function for the current ship? I'd like to fly multiple rockets in tandem.

[BudgetHedgehog]

Stupid question probably, but will MechJeb do its thing when I've given it a series of nodes and then switched to a different ship? Or will it only function for the current ship? I'd like to fly multiple rockets in tandem.

Providing they're withing rendering range, MJ will execute a node on another ship. I know it can dock by itself for sure, I like watching it dock from EVA, I like to pretend it's one of the other guys piloting inside.

[Starwaster]

Providing they're withing rendering range, MJ will execute a node on another ship. I know it can dock by itself for sure, I like watching it dock from EVA, I like to pretend it's one of the other guys piloting inside.

Well, actually it has to be within 2km. Outside of 2km it can still be within rendering range but it will be on-rails and additionally not processing any PartModule code at all.

[CaelumEtAstra]

Stupid question probably, but will MechJeb do its thing when I've given it a series of nodes and then switched to a different ship? Or will it only function for the current ship? I'd like to fly multiple rockets in tandem.

Sadly, no. the only thing that will stick are the nodes, as in .23.5 they are persistent. If you want to do formation flying, here's a plugin to do that (as of now it is a WIP though): http://forum.kerbalspaceprogram.com/threads/75170-WIP-Plugin-%280-23-5%29-Burn-Together%21-Alpha-v4-%284-21-14%29?

[Nudles]

Man I understand that you're losing FPS, but seriously 300? Even for a 144Hz monitor that's way overkill and if you'd limit it to 144 I bet there's no difference with and without MechJeb.

Hey AndreyATGB, you misunderstand the situation. You can get 300 fps and still have a low a frame rate.

For example, I am getting for example 144 fps (on my 144mhz monitor), but it is far from smooth. Because during that one second,I get lets say 143 frames for the first 3/4 of a second, then the last quarter of a second I get 1 frame. So technically that is 144 FPS... but it is veeery jerky . So whether I set the framerate to 30, 60 or 120, it is still jerky. Because the frames are not evenly spread throughout the second its not true high fps.

So in a sense its 144 FPS for a few seconds, and then 4 FPS, and it keeps alternating this pattern. But when looking at the graph it gives a false picture, without context.

[Nudles]

What's the software to generate those ? I ll have fun with it in the next few days

I got the data using the benchmark in the free version of FRAPS, and the files it created in Microsoft Excel to create the graphs.

[tmbomber]

Not sure if this was something covered in one of the recent "cleanup" releases, but as of 240 the issues I was having with the docking AP seem to have been cleared up. I'm not backing up ridiculous amounts any more and the bounding boxes look like they should.

Thanks for fixing this one.

http://imgur.com/VRR1knf