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

[Craze]

Maybe I will repeat, but - there is a problem.

If, during the operation of the engine to change the target, the burn site will begin again.
And the second, if the next stage contains only engines-it will be turned on. But it's not for nothing that I divided them into different stages, right?

And just wish. I would like to be able to reset the stage after the completion of the orbit circularization, optionally (checkbox).
PS-Sorry for my English.

[Tonka Crash]

@El Sancho  For the jumping rover try remapping the control keys for the ground vessels to the number pad on your keyboard. I use 8(forward) 4(left) 6(right) 2 (reverse) 5 (brakes).The default rover forward/back/left/right are also the pitch and yaw controls for spacecraft so they are triggering the reaction wheels to pitch and yaw. Makes a huge difference in rover control.

Off the main menu select Input and the Vessel Tab. There's a set for wheels that by the default are the same as the ones used to control the attitude of a spacecraft.

[El Sancho]

5 hours ago, Tonka Crash said:

@El Sancho  For the jumping rover try remapping the control keys for the ground vessels to the number pad on your keyboard. I use 8(forward) 4(left) 6(right) 2 (reverse) 5 (brakes).The default rover forward/back/left/right are also the pitch and yaw controls for spacecraft so they are triggering the reaction wheels to pitch and yaw. Makes a huge difference in rover control.

Off the main menu select Input and the Vessel Tab. There's a set for wheels that by the default are the same as the ones used to control the attitude of a spacecraft.

Umm, it's not a problem, bro. I was jumping it quite deliberately to show how well the stability assist functions. My rovers are working great

But thank you.

[Gilph]

Hi, having a weird issue with Ascent on 1.6.1 and dev 862.

Summary: Gravity turn on the Mun does not start at the proper altitude. The ship heads straight up vertically and does a circularization burn, which is very inefficient. But, Ascent on the same craft worked perfectly on Kerbin.

TL:DR section:

After landing a simple stock landing craft on Mun, I used Ascent to lift off into a 20km orbit. The Classic Ascent Profile has all of the correct values for altitude, turn end altitude, etc., and I set a 15 deg turn angle. Usually, the craft would ascend for a few seconds and then turn. Now, it ascends straight up for roughly 3km and then turns, but by that point, my Ap is at my peak and it just does a very large circularization burn. The amount of distance it rose vertically (3km) was roughly equivalent to my surface elevation (around 3km). Not sure if that is a coincidence, or it is not accounting for the ASL distance.

But, that same craft lifted of of Kerbin and Ascent worked perfectly. It seems like only the Mun is affected, and the Mun is the only body I landed on so far.

Craft and logs are here

Thanks

 

[Tonka Crash]

@Gilph Your log file indicates you are running MechJeb #855 and not #862.

[El Sancho]

1 hour ago, Gilph said:

Hi, having a weird issue with Ascent on 1.6.1 and dev 862.

Summary: Gravity turn on the Mun does not start at the proper altitude. The ship heads straight up vertically and does a circularization burn, which is very inefficient. But, Ascent on the same craft worked perfectly on Kerbin.

TL:DR section:

I have encountered that on Minmus and Mun. When it happened to me, I checked the Ascent settings carefully, and found that the altitude at which it was set to begin the gravity turn was too high. Everything else was right, but that one parameter had no been autoset correctly, i.e. down to something like 1km. When I adjusted that manually, it all worked. This has happened to me at least half a dozen times over the last few months, and every time the problem was the same.

[Gilph]

38 minutes ago, Tonka Crash said:

@Gilph Your log file indicates you are running MechJeb #855 and not #862.

Blarg...thanks @Tonka Crash

I have two 1.6.1 versions: a mostly stock one and a heavily modded one. I originally noticed the problem with the modded one, which is running 862. I copied the craft and reproduced the problem on my less modded one, which is 855. So, the issue seems to be with both versions.  I'll upgrade the less modded one to 862 and will update if anything changes.

[Gilph]

50 minutes ago, El Sancho said:

I have encountered that on Minmus and Mun. When it happened to me, I checked the Ascent settings carefully, and found that the altitude at which it was set to begin the gravity turn was too high. Everything else was right, but that one parameter had no been autoset correctly, i.e. down to something like 1km. When I adjusted that manually, it all worked. This has happened to me at least half a dozen times over the last few months, and every time the problem was the same.

Update:

Using less modded version and 862, I landed on Mun. ASL shows 4284m.

Using Ascent, the value for turn start is 4.3km, which is historically what I would expect, as previous versions have that value as just above surface ASL. This means the gravity turn starts after a few seconds. I leave all the values unchanged and set a high orbit alt of 500km. The gravity turn starts at roughly 8700, which is twice the starting surface ASL. So, it does appear to be ignoring the surface ASL.

If I turn off Automatic Altitude Turn in the Ascent Path Editor and set Turn start altitude to 0.5km, as @El Sancho suggested, the gravity turn started at 4800 km, which was correct.

The issue seems to be that the Automatic Altitude Turn part of the Classic Ascent profile is using sea level as a reference, not the ASL, during the ascent. The workaround seems to be to use the manual config, which uses relative to ASL settings which are correct.

Please let me know if there is anything else needed.

 

Edited February 8, 2019 by Gilph

[El Sancho]

2 minutes ago, Gilph said:

Update:

Using less modded version and 862, I landed on Mun. ASL shows 4284m.

Using Ascent, the value for turn start is 4.3km, which is historically what I would expect, as previous versions have that value as just above surface ASL. This means the gravity turn starts after a few seconds. I leave all the values unchanged and set a high orbit alt of 500km. The gravity turn starts at roughly 8700, which is twice the starting surface ASL. So, it does appear to be ignoring the surface ASL.

If I turn off Automatic Altitude Turn in the Ascent Path Editor and set Turn start altitude to 0.5km, as @El Sancho suggested, the gravity turn started at 4800 km, which was correct.

The issue seems to be that the Automatic Altitude Turn part of the Classic Ascent profile is using sea level as a reference, not the ASL, during the ascent. The workaround seems to be to use the manual config, which uses relative to ASL settings which are correct.

Please let me know if there is anything else needed.

 

Glad I could help, in my somewhat bumbling manner. I knew what was happening, but you figured out why!  Tip of the hat to you.

[Loren Pechtel]

2 hours ago, Gilph said:

Hi, having a weird issue with Ascent on 1.6.1 and dev 862.

Summary: Gravity turn on the Mun does not start at the proper altitude. The ship heads straight up vertically and does a circularization burn, which is very inefficient. But, Ascent on the same craft worked perfectly on Kerbin.

TL:DR section:

After landing a simple stock landing craft on Mun, I used Ascent to lift off into a 20km orbit. The Classic Ascent Profile has all of the correct values for altitude, turn end altitude, etc., and I set a 15 deg turn angle. Usually, the craft would ascend for a few seconds and then turn. Now, it ascends straight up for roughly 3km and then turns, but by that point, my Ap is at my peak and it just does a very large circularization burn. The amount of distance it rose vertically (3km) was roughly equivalent to my surface elevation (around 3km). Not sure if that is a coincidence, or it is not accounting for the ASL distance.

But, that same craft lifted of of Kerbin and Ascent worked perfectly. It seems like only the Mun is affected, and the Mun is the only body I landed on so far.

Craft and logs are here

Thanks

 

I don't know if it's related but I've seen this sort of behavior being caused by the rocket not being able to turn fast enough.  It's easy to have a very high TWR on a low-g world, if it doesn't have much command authority it's not able to make a meaningful gravity turn into such a low orbit.  Years ago I had one rocket that I could actually get better performance out of on Minmus by burning radial out for about 1 second, then shutting down my engines and turning completely horizontal, then burning for orbit--by the time I started falling back I was building up enough horizontal speed.  I was trying to figure out how to modify it to take off at perhaps 10 degrees from the horizontal but I didn't see any practical solutions.

[Gilph]

32 minutes ago, Loren Pechtel said:

I don't know if it's related but I've seen this sort of behavior being caused by the rocket not being able to turn fast enough.  It's easy to have a very high TWR on a low-g world, if it doesn't have much command authority it's not able to make a meaningful gravity turn into such a low orbit.  Years ago I had one rocket that I could actually get better performance out of on Minmus by burning radial out for about 1 second, then shutting down my engines and turning completely horizontal, then burning for orbit--by the time I started falling back I was building up enough horizontal speed.  I was trying to figure out how to modify it to take off at perhaps 10 degrees from the horizontal but I didn't see any practical solutions.

Very true...but not applicable in this case. TWR was around 4 and once I lowered it to 1.5 for one test run and there was no difference.

[Sokol_323]

In the latest version, the issue of bringing the plane into the plane has not been solved. This question was repeatedly raised on the forum. For example, I have a station in orbit Kerbin, which is launched from the launch site of Woomerang with an inclination of about  45 degrees. This means that the station passes approximately six times in six turns over the KSC. I launch visiting expeditions from the KSC launch site into the target plane using the MechJeb automatic script. MJ calculates the launch time itself and the spacecraft is displayed with a minimum deviation in the plane. Further, as in real flight: the adjustment of the difference of the angles of inclination of the orbits and the transition from one orbit to another using two maneuvers. The whole procedure from the moment of launch to the end of the docking takes no more than 2.5 turns. Such a scenario allows launching rockets with a minimum delta to enter a circular orbit with an altitude of about 100 km, and maneuvers in close proximity with the help of spacecraft engines and the fuel available in it. This is a very economical scheme that allows you to display objects in a plane with a minimum deviation of up to 1 km before docking. In the latest version of MJ, this script does not work. The spacecraft will be displayed in the plane with the inclination of the launch pad, which in the case of the KSC is 0 degrees. Accordingly, only about 2000 deltaV will be required for correcting the difference in the angles of inclination of the orbits. The previously proposed version using the rendezvous script in my case is not optimal due to the large difference in the orbital inclination angles and the need to accurately bring the spacecraft to the rendezvous height (this is difficult, because the orbit is not perfectly circular and the exact height of the orbit at the proposed meeting point is difficult to calculate ). Therefore, again, an additional delta is required to correct for the divergence and actual alignment of the spacecraft in the plane of the station orbit. Apparently the same 2,000 deltaV or so. The proposed scenario works fine on Mun or Minmus due to the low altitudes and the difference in orbital inclinations between the landing module and the main spacecraft or station in orbit, as well as the small cost of maneuvers in general. But it is completely unacceptable in the example I described.

Will the issue in this part of the work of automatic scripts MJ? In the meantime, I have to use the previous version of the mod, since there was no such problem and everything worked correctly.

Edited February 8, 2019 by Sokol_323

[Redneck]

Thank you @sarbian for keeping this mod going :thumbsup:

[PTGFlyer]

How far along in the tech tree do you need to be to unlock Spaceplane Guidance? I really don't want to manually fly all the way around Kerbin.

[MikeO89]

OK, got my Apollo moon rocket working fine now. I had to add a probe core to both the LEM and the 3rd stage even though I shouldn't have had to have done that. The 3rd stage already had the Kane instrument unit on it  but for some reason 3rd stage wasn't recognizing it with latest BDB update. I never have had to put a prob core on the LEM before either, all I've ever needed to do with it is add a mechjeb module to it so I could control it without a pilot. I tried to add a probe core that was very small and ended up choosing the Probododyne OKTO2 with a cubic strut to attach it on both the LEM and 3rd stage. Now SAS works on all of them separately. 

[Jacke]

1 hour ago, PTGFlyer said:

How far along in the tech tree do you need to be to unlock Spaceplane Guidance? I really don't want to manually fly all the way around Kerbin.

By default, Tier 7 node Unmanned Tech.

I have a Module Manager script I use to both add  MechJeb to Command parts (now done by stock MechJeb) and Kerbal Seat parts like the External Command Seat.  I also change things to unlock all MechJeb functions at Start.

Spoiler

// MM.MechJeb2.MC+KS.<date-version>.cfg
//
// Version 20190205a
// for KSP v1.6.1
//
// Powered by ialdabaoth and sarbian's ModuleManager
//      http://forum.kerbalspaceprogram.com/index.php?/topic/50533--/
// ModuleManager config coding by KSP forum user Jacke
//      http://forum.kerbalspaceprogram.com/index.php?/profile/103694-jacke/
// Copyright 2019 by Jacke
// Licence GNU General Public Licence version 3
//      https://www.gnu.org/licenses/gpl-3.0.en.html
//
// Include this file with Kerbal Space Program
//
// for MechJeb >= 2.1.1
//
// add MechJeb functions to all parts with MODULE ModuleCommand and/or KerbalSeat
// enable these functions from Start of careers
//
// 2019 Feb 05 Tue  confirmed good for KSP 1.6.1 and recent MM and MechJeb2
// 2017 Aug 21 Mon  split code for ModuleCommand and KerbalSeat as '|' in HAS not working
// 2017 Aug 19 Sat  75 Anniversary of the Dieppe Raid - Lest We Forget
//                  confirmed good for MechJeb2 version 2.6.1.0-735
// 2016 Dec 24 Sat  changed to recreate existing MODULE MechJebCore to change the unlockTechs
// 2016 Dec 13 Tue  changed to one @PART block using '|' in :HAS code
// 2016 Dec 12 Mon  added :NEEDS[MechJeb2], added code block for KerbalSeat
//                  similar to Mahal's StockPlugins,
//                  renamed this file from MMJ-Graphotron-ModuleCommand
//                  to MMJ-MechJeb-MC+KS
// 2016 Apr 20 Wed  updated links for KSP new forum
// 2015 May 12 Tue  updated coding
// 2015 May 07 Thu  updated for KSP 1.0.2 and recent changes
// 2014 Aug 30 Sat  changed order of HAS tests
// 2014 Feb 20 Thu  MM coding by Jacke
//
// where    GameData/zzzFinal/
// what     parts with MODULE ModuleCommand and/or KerbalSeat
// files    part config files with MODULE ModuleCommand or KerbalSeat
// nodes    PART's with MODULE ModuleCommand or KerbalSeat
//
//
// Standard Command Modules and Kerbal carrying parts
//
@PART[*]:HAS[@MODULE[ModuleCommand]]:NEEDS[MechJeb2]:FINAL
{
	-MODULE[MechJebCore] {}		// delete any existing MODULE MechJebCore to change unlochTechs
	MODULE
	{
		name = MechJebCore
		MechJebLocalSettings {
			MechJebModuleCustomWindowEditor { unlockTechs = start }		// flightControl
			MechJebModuleSmartASS { unlockTechs = start }			// flightControl
			MechJebModuleManeuverPlanner { unlockTechs = start }		// advFlightControl
			MechJebModuleNodeEditor { unlockTechs = start }			// advFlightControl
			MechJebModuleTranslatron { unlockTechs = start }		// advFlightControl
			MechJebModuleWarpHelper { unlockTechs = start }			// advFlightControl
			MechJebModuleAttitudeAdjustment { unlockTechs = start }		// advFlightControl
			MechJebModuleThrustWindow { unlockTechs = start }		// advFlightControl
			MechJebModuleRCSBalancerWindow { unlockTechs = start }		// advFlightControl
			MechJebModuleRoverWindow { unlockTechs = start }		// fieldScience
			MechJebModuleAscentGuidance { unlockTechs = start }		// unmannedTech
			MechJebModuleLandingGuidance { unlockTechs = start }		// unmannedTech
			MechJebModuleSpaceplaneGuidance { unlockTechs = start }		// unmannedTech
			MechJebModuleDockingGuidance { unlockTechs = start }		// advUnmannedTech
			MechJebModuleRendezvousAutopilotWindow { unlockTechs = start }	// advUnmannedTech
			MechJebModuleRendezvousGuidance { unlockTechs = start }		// advUnmannedTech
		}
	}
}
//
@PART[*]:HAS[@MODULE[KerbalSeat]]:NEEDS[MechJeb2]:FINAL
{
	-MODULE[MechJebCore] {}		// delete any existing MODULE MechJebCore to change unlochTechs
	MODULE
	{
		name = MechJebCore
		MechJebLocalSettings {
			MechJebModuleCustomWindowEditor { unlockTechs = start }		// flightControl
			MechJebModuleSmartASS { unlockTechs = start }			// flightControl
			MechJebModuleManeuverPlanner { unlockTechs = start }		// advFlightControl
			MechJebModuleNodeEditor { unlockTechs = start }			// advFlightControl
			MechJebModuleTranslatron { unlockTechs = start }		// advFlightControl
			MechJebModuleWarpHelper { unlockTechs = start }			// advFlightControl
			MechJebModuleAttitudeAdjustment { unlockTechs = start }		// advFlightControl
			MechJebModuleThrustWindow { unlockTechs = start }		// advFlightControl
			MechJebModuleRCSBalancerWindow { unlockTechs = start }		// advFlightControl
			MechJebModuleRoverWindow { unlockTechs = start }		// fieldScience
			MechJebModuleAscentGuidance { unlockTechs = start }		// unmannedTech
			MechJebModuleLandingGuidance { unlockTechs = start }		// unmannedTech
			MechJebModuleSpaceplaneGuidance { unlockTechs = start }		// unmannedTech
			MechJebModuleDockingGuidance { unlockTechs = start }		// advUnmannedTech
			MechJebModuleRendezvousAutopilotWindow { unlockTechs = start }	// advUnmannedTech
			MechJebModuleRendezvousGuidance { unlockTechs = start }		// advUnmannedTech
		}
	}
}
//
// END OF MM.MechJeb2.MC+KS.<date-version>.cfg

 

 

Edited February 9, 2019 by Jacke

[ChrisF0001]

On 2/5/2019 at 9:18 PM, sarbian said:

Most problems with the Rover AP are linked to a control part that is not oriented to look forward.

Is it possible that this can also happen with reaction wheels pointed in unexpected directions?

A couple of times I've had a rover get 'confused' somehow, I think after being docked to something else and then undocked again - basically with Stability Control off everything seems normal, but with it turned on the reaction wheels in the cockpit and the ones in the SAS module seem to try to turn in different directions, so steering say right turns the wheels right, but the rover itself grudgingly drifts left.  As far as I can tell this is unrecoverable after it happens, unless a convenient quicksave is available...

[Xd the great]

How do you use the scripting autopilot?

[Tonka Crash]

2 hours ago, ChrisF0001 said:

Is it possible that this can also happen with reaction wheels pointed in unexpected directions?

Reaction wheels don't care about orientation. They just apply torque in the requested direction. It sounds like your rover's control point may have shifted when it's docked. You need to right-click "control from here" on the part you want controlling your rover. Command pods, probe cores and docking ports have this option.

[El Sancho]

1 minute ago, Tonka Crash said:

Reaction wheels don't care about orientation. They just apply torque in the requested direction. It sounds like your rover's control point may have shifted when it's docked. You need to right-click "control from here" on the part you want controlling your rover. Command pods, probe cores and docking ports have this option.

That's what I was thinking, Tonka Crash, but I wasn't really sure enough to speak up on my own. I often use that "Control From Here" function after an undock just on general principles, to be sure MJ and I are on the same sheet of music

[Burning Kan]

@Xd the great old but shows the principle

https://www.youtube.com/watch?v=rPh1DfwJpMA

 

[ChrisF0001]

 

9 minutes ago, Tonka Crash said:

Reaction wheels don't care about orientation. They just apply torque in the requested direction. It sounds like your rover's control point may have shifted when it's docked. You need to right-click "control from here" on the part you want controlling your rover. Command pods, probe cores and docking ports have this option.

I did do that, but it didn't help - nor was it a pod with the new switchable control direction, just a plain old forwards only one, and no other parts on the rover that even *have* Control From Here (I think...).  Plus with Stability Control off, everything was fine.

(...And there were no other control parts because it wasn't docked with a docking port, but with a couple of 'legacy' KAS ports and a pipe, since the 'legacy' winch appears to be un-grabbable now and I haven't upgraded everything to the new transfer pipes yet.  It's complicated... ^_^;)

[Tonka Crash]

@ChrisF0001 The only other thing I can think to try is shift focus to a vessel out of physics range (go to the tracking station) and then back to the rover. Maybe when it reloads the rover it will reset whatever is going on. It might get around needing to reload a save.

[ChrisF0001]

2 minutes ago, Tonka Crash said:

@ChrisF0001 The only other thing I can think to try is shift focus to a vessel out of physics range (go to the tracking station) and then back to the rover. Maybe when it reloads the rover it will reset whatever is going on. It might get around needing to reload a save.

I shall certainly try that next time, thanks!   It wouldn't be the first transient issue that can be fixed like that...

[Michel Bartolone]

I've got a suggestion. I'm not sure if this is the right place or not. I'd like a 'crew' tab or crew info window, available in flight. Something that lists info on each kerbonaut, possibly just on the currently active vessel. It can list some simple info, like name, class (pilot, engineer, scientist), current mission time in space/on orbit, total number of missions, and total time in space. It would help with knowing which to rotate out of a station etc.