[1.12.x] Anatid Robotics / MuMech - MechJeb - Autopilot - [2.14.3] [4th March 2023]

[Gordon Dry]

#715 got a huge changelog, looking forward to test it, session begins in a few minutes.

[drtedastro]

just wanted to stop by and say THANKS for all of the great work and stuff for the dev builds.

Cheers and best wishes and fishes....

[Foxster]

What's the story behind #715?

What is the difference between Classic Ascent Profile and Stock-style Gravity Turn?

[Gordon Dry]

#720 now, going quick.

[Jim DiGriz]

18 hours ago, Foxster said:

What's the story behind #715?

What is the difference between Classic Ascent Profile and Stock-style Gravity Turn?

Classic Ascent Profile should be more or less what you're used to.  Hopefully more bugs were fixed than were introduced.  I think corrective steering may be busted, the code was kind of a mess and I couldn't understand what it was trying to do.  I think I get the idea behind it now, and will take another run at fixing it in a bit.

"Stock-style GravityTurn™" is similar to the gravity turn mod.   Its a 3-burn to orbit style of launch that can get to orbit with about 2800 dV on stock Kerbin.  If you want to have fun make a rocket that is basically a nose cone, a jumbo-64 a mainsail and some fairly big fins.  Have the pitch program flip it over aggressively (uncheck the AoA limiter, set the values to like 0.5 / 50 / 40 / 45 / 1) and let it rip.  Note that its not precisely the GT mod algorithm, and I didn't intend it to be -- I just didn't know what else to call it.  It does not do any pitch-up during the intermediate burn right now (that's another TODO) so it won't handle low TWR upper stages.

PEG is actual gravity turn algorithms from the Surveyor missions that properly integrates the trajectory.  It will likely not be that useful on Kerbin since it does not know how to do two-burn to orbit (does not understand coast phases) so most Kerbin launch vehicles won't ever get locked guidance with it.  So if you give a 100x100 orbit, then you need a rocket that will burn continuously, without throttling, until insertion where it will shut down right when it hits the 100x100 orbit.  Example of it flying a 3-stage rocket to orbit:  https://vimeo.com/224742550

There's also been a lot of cleanup of the algorithms internally.  The old ascent profile code in some places stopped following the ground track to hit the right inclination, turned off the AoA limiter, would occasionally start flying prograde instead of aligned with surface velocity so would flip out, all kinds of odd bugs.  The AoA limiter and the yaw control to hit the inclination are now applied consistently, and the different ascent profiles modify only the pitch (which consistently has the yaw steering applied and then consistently has the AoA limiter applied to that).  The result should be that if you have AoA limiting on you shouldn't get rockets that flip out, and should have more accurate launch inclination targeting (although hitting 0.0000 exactly remains troublesome because the yaw steering still only knows how to fly in exactly "straight" great circle lines so you can't hit latitudes lower than your launch site and KSC is not exactly on 0.0000).

 

Edited July 19, 2017 by Jim DiGriz

[Jim DiGriz]

Also note it turns out "PEG" isn't really "PEG".  What is currently in MechJeb is the guidance equations for the Surveyor missions.  The next generation of that is the Apollo-era IGM ("Iterative Guidance Mode").  Then the next generation after that is the Space Shuttle Unified Powered Flight Guidance (UPFG) which uses an the PEG (Powered Explicit Guidance) algorithm (i think?).  I got confused by some wiki pages which implemented the Surveyor mission model and called it PEG and the reference for the Surveyor model is the "Explicit Guidance Functions for Multistage Boost Trajectories".

Anyway at this point I'm more worried about expanding MJ to being able to handle three-dimensional targeting and yaw steering and then moving on to IGM at least which seems like a similar enough algorithm.  Then I'll rename it IGM and that'll clear up the naming issue...

 

[Argyle MHF]

Is there an ideal configuration for RCS thrusters for docking on a craft, using MJ version #712 & beyond? What I am used to building (thrusters oriented N,S,E,& W, placed at the front, middle & tail of craft) no longer works past #710. Prior to #712, that configuration worked a treat. Now, it races laterally and, once lined up, ends up swinging back and forth as it approaches the target port. I know there was some code changed at #712, & I basically understand why.

All things considered, I think my design is gibbled. Any suggestions? Thanks

[sarbian]

I guess the new code make some over problems with the RCS controls more obvious. I ll see if I can have a look and/or add a switch that make the new code optional.

Your vessel is heavy or light ? 

[Foxster]

Excuse my ignorance on this...

What is the process for vetting updates to MJ? Is there one or more persons collating updates and approving them before dev versions are released?

 

[sarbian]

There is no complex process. If I know you and you usually provide decent code then your merge is accepted. If I don't know you I ll try to read up and test the code, if I have the time.

The dev branch should not be expected to be stable. Sure that's where you will find the last new goodies but it does not get the same testing as the official release. For official I try to make sure most stuff works (but with the size of MJ and the possibilities of KSP building testing has its limits).

[Jim DiGriz]

8 hours ago, Foxster said:

Excuse my ignorance on this...

What is the process for vetting updates to MJ? Is there one or more persons collating updates and approving them before dev versions are released?

 

Sarbian runs the project and has to whack merge on PRs.  If you want to contribute just open a PR.  Sarbian doesn't stand on a lot of formality and does a pretty good job at keeping the bar low to encourage contribution (although occasionally points out where you've tried to change code you didn't understand fully and what you want won't work, but that's just inherent to trying to hack on a large codebase like MJ).

[FeliusKerNes]

I've been noticing some issues with ascent inclination, specifically that mechjeb seems to treat negative values there as if they were positive (also true for inputting the values as ”360-value"), meaning that if using it to launch on a non equatorial orbit it only has a single launch window to match it, not two, the other leading to the opposite orbit. I'll be leaving town soon for a few days so I can't fully investigate it but I'd rather post it now in case I forget it later when I come back.

[Starwaster]

On 7/19/2017 at 2:19 AM, Argyle MHF said:

Is there an ideal configuration for RCS thrusters for docking on a craft, using MJ version #712 & beyond? What I am used to building (thrusters oriented N,S,E,& W, placed at the front, middle & tail of craft) no longer works past #710. Prior to #712, that configuration worked a treat. Now, it races laterally and, once lined up, ends up swinging back and forth as it approaches the target port. I know there was some code changed at #712, & I basically understand why.

All things considered, I think my design is gibbled. Any suggestions? Thanks

• Your craft should be able to translate (left/right/up/down) without any torquing at all. If translating results in torque then it's going to have to fire other thrusters to try to compensate. That compensation is probably going to interfere with its efforts to translate. RCS Balancer may help but it's better to have a well balanced craft to start with.
• Also: Docking AP speed limit: Best to leave it at default unless your balance is perfect. Lowering the speed limit may help with balance issues but the AP starts having problems if it is too low. (0.25 is a good lower limit; 0.125 is probably too low) Sarbian mentioned that the position and velocity could be a frame behind. That tends not to be a problem until the speed limit gets as low as ~0.1 - 0.125 m/s. (and the closer it is to the target, the slower it wants to go).

 

(The swinging back and forth does sound like a balance issue. Test that by turning on RCS and pressing I/K/J/L - it should move laterally without turning at all. If it does then that's a balance issue. If it's only a little off balance then maybe MJ balancer can help like I said before)

[BMot360]

Is Mechjeb's Ascent Guidance able to change the flight path when staging to a lower TWR engine, i.e. pitch up to keep raising the time to apoapsis?

[Loren Pechtel]

46 minutes ago, BMot360 said:

Is Mechjeb's Ascent Guidance able to change the flight path when staging to a lower TWR engine, i.e. pitch up to keep raising the time to apoapsis?

As of KSP 1.2.2 at least, no.  You have to be very careful with low TWR upper stages.  In general you can fly them with a higher periapsis, though--but note that the resulting orbit is likely to be far from circular.  I haven't considered this a big deal as if I have a low-TWR upper stage it's because I'm going beyond Kerbin.  MechJeb doesn't do a good job of flying elsewhere from a low Kerbin orbit anyway so I'm going to raise the orbit whether on launch or afterwards.  (For everything but ascent and landing MechJeb uses maneuver nodes and they are a simplification based on the assumption that the whole burn occurs at the node.  If your burn is spread over too many degrees of orbit it's not going to go well, whether done with a node or with MechJeb.  This is especially an issue when using the Nerva engine.)

[siimav]

52 minutes ago, BMot360 said:

Is Mechjeb's Ascent Guidance able to change the flight path when staging to a lower TWR engine, i.e. pitch up to keep raising the time to apoapsis?

No but you can continously adjust the final ascent angle value to keep the time to Ap value whatever you want it to be.

[Jim DiGriz]

1 hour ago, BMot360 said:

Is Mechjeb's Ascent Guidance able to change the flight path when staging to a lower TWR engine, i.e. pitch up to keep raising the time to apoapsis?

Use "corrective steering".

The new guidance code for RSS/RO will handle fairly stupidly low lowers and uppers, its fun to watch math huck an underpowered 0.35 TWR Saturn Ib 4xRL10 upper up to 300km in order to have it drop down into a perfect 185x185 parking orbit.

Edited July 21, 2017 by Jim DiGriz

[Argyle MHF]

On 7/19/2017 at 1:46 AM, sarbian said:

I guess the new code make some over problems with the RCS controls more obvious. I ll see if I can have a look and/or add a switch that make the new code optional.

Your vessel is heavy or light ? 

I build big, heavy things in space for the most part. I going to think about what @Starwaster has said & look into my designs with more scrutiny.

And besides, where is the fun in things going smoothly all the time?

11 hours ago, Starwaster said:

*snip*

Thanks for the words, it gives me some things to think about, and a few ideas for modifications of my designs like smaller, lighter, an more modular in nature.

[Aelfhe1m]

I think the recent dev builds (#716 and later) have a conflict with Modular Fuel Tanks when calculating delta-V for jet engines.

Did a clean KSP 1.3 build containing only MJ and MFT and built the below simple test craft:

Spoiler

After saving this craft then exiting and re-entering the SPH, MJ began spamming my log with exceptions and the delta-V window was just an outline - logs here.

Edit: @sarbian this is probably related to this commit: https://github.com/MuMech/MechJeb2/commit/57be08f16d380e7bf8ddede1d55b384bdfec3869

Edited July 22, 2017 by Aelfhe1m

[Foxster]

59 minutes ago, Aelfhe1m said:

I think the recent dev builds (#716 and later) have a conflict with Modular Fuel Tanks when calculating delta-V for jet engines.

Did a clean KSP 1.3 build containing only MJ and MFT and built the below simple test craft:

  Reveal hidden contents

After saving this craft then exiting and re-entering the SPH, MJ began spamming my log with exceptions and the delta-V window was just an outline - logs here.

Edit: @sarbian this is probably related to this commit: https://github.com/MuMech/MechJeb2/commit/57be08f16d380e7bf8ddede1d55b384bdfec3869

Confirmed. I've seen this too but with just stock jet engine craft. 

I've been trying to get details together. On my system, KSP crashes a few seconds after I've noted the MJ error message spam in the console log. All I can make out before the crash is something about dV calculation and a limit exceeded. I'll try to get a proper log file posted. 

Update...Here's the log files: https://www.dropbox.com/s/uuyfpuuiylvpfam/2017-07-20_115414.zip?dl=0

This is what is spammed before KSP crashes: 

[MechJeb2] Exception in MechJebModuleStageStats.RunSimulation(): System.Exception: FuelFlowSimulation.SimulateStage reached max step count of 100
  at MuMech.FuelFlowSimulation.SimulateStage (Single throttle, Double staticPressure, Double atmDensity, Double machNumber) [0x00000] in <filename unknown>:0 
  at MuMech.FuelFlowSimulation.SimulateAllStages (Single throttle, Double staticPressureKpa, Double atmDensity, Double machNumber) [0x00000] in <filename unknown>:0 
  at MuMech.MechJebModuleStageStats.RunSimulation (System.Object o) [0x00000] in <filename unknown>:0 
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

 

Edited July 22, 2017 by Foxster

[Aelfhe1m]

10 minutes ago, Foxster said:

Confirmed. I've seen this too but with just stock jet engine craft. 

Interesting. I should have tested just stock before assuming it was an MFT conflict.

[Gordon Dry]

Just see #723 ...

Last session with #720 I had issues after switching to other vessels in physics range (recovery missions) and back.
After enabling RCS the log was spammed with

NullReferenceException: Object reference not set to an instance of an object
  at MuMech.RCSSolverThread.GetThrottles (.Vessel vessel, MuMech.VesselState state, Vector3 direction, System.Double[]& throttles, System.Collections.Generic.List`1& thrustersOut) [0x00000] in <filename unknown>:0 
  at MuMech.MechJebModuleRCSBalancer.GetThrottles (Vector3 direction, System.Double[]& throttles, System.Collections.Generic.List`1& thrusters) [0x00000] in <filename unknown>:0 
  at MuMech.VesselState.UpdateRCSThrustAndTorque (.Vessel vessel) [0x00000] in <filename unknown>:0 
  at MuMech.VesselState.Update (.Vessel vessel) [0x00000] in <filename unknown>:0 
  at MuMech.MechJebCore.FixedUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

This did not happen before I switched to another vessel the first time.

Log:
https://www.dropbox.com/s/ctn4ja6jnju9vo9/2017-07-24-1 KSP.log.zip?dl=1

[sarbian]

On 7/23/2017 at 0:20 AM, Aelfhe1m said:

I think the recent dev builds (#716 and later) have a conflict with Modular Fuel Tanks when calculating delta-V for jet engines.

Did a clean KSP 1.3 build containing only MJ and MFT and built the below simple test craft:

  Reveal hidden contents

After saving this craft then exiting and re-entering the SPH, MJ began spamming my log with exceptions and the delta-V window was just an outline - logs here.

Edit: @sarbian this is probably related to this commit: https://github.com/MuMech/MechJeb2/commit/57be08f16d380e7bf8ddede1d55b384bdfec3869

Most likely a commit before but it is broken anyway

A minimal craft I can use to test ? pod + Engine + Tank (fuels?) ?

 

31 minutes ago, Gordon Dry said:

This did not happen before I switched to another vessel the first time.

Hopefully it s easy to duplicate because I don't see anything obviously wrong.

[Aelfhe1m]

6 minutes ago, sarbian said:

A minimal craft I can use to test ? pod + Engine + Tank (fuels?) ?

This is the test craft for the logs that I posted above.

[Gordon Dry]

19 minutes ago, sarbian said:

Hopefully it s easy to duplicate because I don't see anything obviously wrong.

I have a few recovery contracts to go so I can try to reproduce the issue.

btw I was recovering 2 different kerbals from two different pods in one flight with Valentina as "host"...

I could try with another vessel, manned or unmanned. (the impersonal rescue approach...).