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

[smjjames]

Hi Guys,

I installed machjeb a while ago and used it to learn how to do the stuff in real.

So now im getting into rovers and i got the rover autopilot working (speed and direction) but when i exit the scene, to the space center or to another ship, the rover stops and does not follow its route like it should. Also time warp is not posibble while moving so essentially i neet to watch the autopilot so it works....

How can i time warp with the rover autopilot active so things progress ?

Thanks

You can't, outside of Kerbin anyway (not too sure about Duna, Laythe, and Eve), it's a hardcoded limitation of KSP.

[ManuxKerb]

Hi James,

Its on the mun, but its not my problem that i can not time accelarate while im at the scene, the promlem is, that the rover autopilot forgets to move the rover when im not at the scene. So when i switch back to the Space Center the rover stops but it should continue on its way to the waypoint (at least i hope this is intended!) In Space Center i could tan time exalerate. Also on Kerbin 5x times warp is possible seems not so on the mun.

Edited March 29, 2015 by ManuxKerb

[sarbian]

You can't control vessel (so rover too) when they are not in focus or less than 2.5 km.

[ManuxKerb]

Grr, so we stuck with it then how it is right ?

A suggestion tho, could you make it so, that we can use the waypoints without having this big waypoint window open? So we can manually drive the rover and follw the waypoint ?

This would be awesome.

[BudgetHedgehog]

A suggestion tho, could you make it so ... we can manually drive the rover and follw the waypoint ?

So, Waypoint Manager?

[Blue5]

Sarbian and all,

Thanks! that worked.

Looking forward in learning and using MechJeb.

Red5 (I will be changing my name - please stand by)

Do you have the game (or steam) install in C:\Program Files ? Windows protection may stop the game from loading the mod. You need to move the game elsewhere if this is the case.

[smjjames]

I was chute testing a return probe when mechjeb decided to be temporarily confused about math after I had landed and the orbital resource scanner (telescope looking scanner, SCANsat, or maybe MKS) got temporarily pushed into the radial chutes (novapunch I think) and the soil moisture scanner (Dmagic science) when it tipped over. I didn't have anything 'active' going, the only mechjeb thing I had open was the surface info window, also with dev build 414.

ArithmeticException: NAN
at System.Math.Sign (double) <0x00087>
at Orbit.solveEccentricAnomalyExtremeEcc (double,double,int) <0x00061>
at Orbit.getRelativePositionAtT (double) <0x00135>
at Orbit.getRelativePositionAtUT (double) <0x00039>
at MuMech.OrbitExtensions.SwappedRelativePositionAtUT (Orbit,double) <0x0001f>
at MuMech.OrbitExtensions.SwappedAbsolutePositionAtUT (Orbit,double) <0x0003c>
at MuMech.MechJebModuleInfoItems.TimeToImpact () <0x0009a>
at (wrapper dynamic-method) System.Runtime.CompilerServices.ExecutionScope.lambda_method (System.Runtime.CompilerServices.ExecutionScope,object) <0x0002b>
at MuMech.ValueInfoItem/<ValueInfoItem>c__AnonStoreyA.<>m__40 () <0x00019>
at MuMech.ValueInfoItem.DrawItem () <0x00015>
at MuMech.MechJebModuleCustomInfoWindow.WindowGUI (int) <0x000a6>
at UnityEngine.GUILayout/LayoutedWindow.DoWindow (int) <0x000bb>
at UnityEngine.GUI.CallWindowDelegate (UnityEngine.GUI/WindowFunction,int,UnityEngine.GUISkin,int,single,single,UnityEngine.GUIStyle) <0x00107>

[SaintWacko]

While I can't speak to what's causing the heading issues, or how to reproduce it, I can say that every single time it happens (and it happens a lot) it can be fixed by simply tapping 'f', which turns SAS on and back off.

[smjjames]

While I can't speak to what's causing the heading issues, or how to reproduce it, I can say that every single time it happens (and it happens a lot) it can be fixed by simply tapping 'f', which turns SAS on and back off.

Are you talking about the rover? the rover AP has problems with overcorrecting since it likes to be REALLY REALLY precise. Turning on stability control helps, as does switching to docking mode.

[sarbian]

I reverted a change I made 2 weeks ago that may be why you get those Control Freeze/SAS problems. Get the newest MJ dev and tell me if you still get it...

[smjjames]

Is there a way to get MechJeb to understand that craft like this example, have the bottom of the craft on the actual bottom? Other than placing a control module somewhere and then orienting it the correct way. Because it behaves like the top is actually forward of the probe pod rather than above it.

[BudgetHedgehog]

Is there a way to get MechJeb to understand ... craft like this example ... Other than placing a control module somewhere and then orienting it the correct way?

No.

To expand: whatever is controlling the navball orientation is what MJ uses for control as well. Docking ports, seats, probe cores, capsules etc. It can't use a control source that doesn't exist (one that faces up).

Edited March 31, 2015 by ObsessedWithKSP

[smjjames]

No. 10 Chars.

Oh well.

What about spaceplanes and planes in general, how does it fly those?

Edited March 31, 2015 by smjjames

[Red Iron Crown]

You could put a docking port on it facing in the direction you want to be up and control from there. Or the AR202 case MechJeb module mounted with its antenna facing upward and controlling from there would work, too.

[BudgetHedgehog]

Oh well.

What about spaceplanes and planes in general, how does it fly those?

Those control sources are pretty much always facing forwards (like your example) and most if not all movement is done in that direction as well (forward through the air rather than up).

[smjjames]

Okay. I was just wondering if there was another way to do it without switching probe pods.

[SilverlightPony]

Okay. I was just wondering if there was another way to do it without switching probe pods.

Like Red Iron Crown said, anything that you can right-click and press "control from here" could be placed on the top of the vehicle/side of the cylinder, oriented correctly, and set as the control point. You'd just have to remember to set "control from here" before launching every time you wheel it out to the pad/runway.

[sarbian]

Okay. I was just wondering if there was another way to do it without switching probe pods.

Yes, submitting me a patch that changes the many line of code that this would require. I considered it before but I find the utility/timeToPatch ratio not that great.

[sarbian]

A few update on what I am currently working on. Some of you may have noticed my thread in the "Plugin Development" forum and the fact that we now have proper debugging for KSP mods. I stumbled upon that while searching for a way to profile mods and improve MJ perf. So with that and some other tricks I can now profile MJ.

I am now fixing some easy performance problem (some those patch are already in dev) and will work on the more complex one.

While doing that I identified 2 main source of slow down :

- the way the custom window info works use a bit too much CPU. That one I was expecting since the legacy Unity UI we use and the way the code is made has MJ do some math twice per frame, which is not exactly smart. I am looking into a way to cache the result each frame without changing too much code. A longer plan would be to use the new Unity UI we will have with KSP 1.0 but that will require even larger code change and I want to experiment with that in a smaller mod than MJ.

- the fuel/deltav simulation eats a lot of memory weach time it runs. That memory is cleaned up by the garbage collector periodically and induce the small stutter you most likely noticed when using MJ.

I started working on a way to fix the simulation memory use and while re-reading the code I stumbled upon a bunch of TODO comment left there. That reminded me that the fuel sim needs some work to fix remaining bugs and add compatibility with a few more mods. And then I was also reminded on IRC that I talked about using KER code in MJ a while back. KER simulation is well maintained by padishar and that would save me a lot of time.

So I now have a working version of MJ that uses the KER simulation code. It does not mean that when you have both MJ and KER running you will only run 1 simulation (but that may be the case in the future). However you get all the nice KER goodies like support for KIDS and RealFuels. And it will most likely save me some time with the 1.0 change to ISP/Thrust.

It does not resolve the memory use problem yet (actually KER code is slightly worse on that point). But I have a solution for that and once I have it working I will submit the change back to KER.

TLDR : I will most likely push a MJ dev version that uses KER Fuel Sim later today

[Starwaster]

Sarbian: When Disable SmartRcs is placed into a menu, it shows up in that menu as Disable SmartASS. (lesser nitpick: It should be smartRCS)

[Foxster]

Little confused by power requirements.

I have this simple test ship in orbit. It has just what you see here...

If I use stock SAS or Smart ASS and make attitude changes or kill rotation then there is enough power for the Probodyne QBE and Advanced Reaction Wheel Module from the two PB-NUKs. They need 37.7/min and the PB-NUKs supply 90/min. So really one should be enough.

However, if I create a node with, say, Maneuver Planner to change the Ap and execute, then the power quickly disappears. The reaction wheel says it doesn't have enough power and the ship is dead in space until I kill the node. If I use three PB-NUKs then all is good.

I wouldn't have thought its the AR202 as it only needs 18/hour.

Anyone know what's going on?

Update...

Seems there is a difference between SAS and Smart ASS useage too. If, after creating a node and executing it until the craft starts to spin for alignment, I then delete the node and use Smart ASS to kill rotation then the power disappears. If I use stock ASS then it doesn't do this.

Edited April 2, 2015 by Foxster

[sarbian]

It is really strange that you have a power usage diff between the SAS and SASS. I ll have a look later.

I pushed a bunch of performance related update and the patch that move the fuel sim to KER code. Not sure you will see the perf improvement now (since the KER code offset the gain) but I started working on KER code and divided the memory usage by 3 so far (and found some trick that would work for the rest of MJ code)

[Climberfx]

Mech Jeb is already a marvelous equipment, and you are perfecting it?

Wonderful!

[smjjames]

I'm just noticing that the pages for dev builds 420 and 421 broke a little because instead of the main stuff being to the right of that sidebar, it's below it. It's still downloadable, so, it's more of a formatting type issue.

[futrtrubl]

Seems there is a difference between SAS and Smart ASS useage too. If, after creating a node and executing it until the craft starts to spin for alignment, I then delete the node and use Smart ASS to kill rotation then the power disappears. If I use stock ASS then it doesn't do this.

Mechjeb tends to be more aggressive and controlled in stopping rotation and locking on a heading than stock SAS. Also the power usage numbers for reaction wheels are for a single axis maxed I believe, and mechjeb frequently drives all three, especially if you have force roll selected.