Jump to content

MechJeb 2 - Patch test bed release (October 10)


sarbian

Recommended Posts

Well, sojourner, that wouldnt work on a big space station.

Again, I'm still not using this patch although I'm watching it with great interest.

I'm just curious here because in reading this thread, I've never seen this item mentioned...

Is anybody besides me using stock MJ's built-in RCS Balancer app? Ever since I discovered it, I've been using it every time I let MJ's autopilot dock. This feature alone cuts MJ's mono usage down to about the same as my own when docking manually. It only uses brief puffs of mono to start moving in the desired direction and just coasts the rest of the time, just like a human.

I submit, therefore, that the typical MJ thing of spewing mono in all directions for no apparent reason is merely the result of the autopilot trying obsessively to stay perfectly lined up on the docking axis despite all the undesired rotations introduced by unbalanced thrusters. Humans aren't so picking, thinking they'll fix things later, so don't do all this constant RCS use. But anyway, the RCS Balancer app cures this MJ problem.

BUT IMPORTANT NOTE: KSP 0.21 introduced a form of RCS balancer into the stock game. It comes on automatically when you hit CapsLock to get fine controls. Stock MJ2 seems unaware of this feature and doesn't know how to deal with it. So, if using the docking autopilot, be sure NOT to have CapsLocks on or the MJ ship will just sit there doing nothing.

Link to comment
Share on other sites

Would it be possible to make MechJeb work like TAC fuel balancer or chatterer where the module is always active and doesn't require a part? I know I could always edit the command pods to include the mechjeb module but that gets annoying every time there's a mod update and I prefer not to modify the stock part files.
An other version (2.0.13243.1312)

- Ship flying away when docking from opposite side of the station

- Better RCS usage, I hope

- Speed Limit can't be negative

- Default docking speed is set to 0.5m/s now. Check yours and don't let it at 0 ( unlimited speed ).

Suggestion: Treat 0.0 speed limit to literally mean 'no faster than 0 m/s'

That would effectively allow the player to hold station outside the docking port

Argh not sure why Aurelius quote is there... maybe I meant to reply to him earlier. Maybe I did reply to him? I think maybe I did... yeah I think I told him that you CAN have MJ2 totally partless. That must be it.

Link to comment
Share on other sites

Again, I'm still not using this patch although I'm watching it with great interest.

I'm just curious here because in reading this thread, I've never seen this item mentioned...

Is anybody besides me using stock MJ's built-in RCS Balancer app? Ever since I discovered it, I've been using it every time I let MJ's autopilot dock. This feature alone cuts MJ's mono usage down to about the same as my own when docking manually. It only uses brief puffs of mono to start moving in the desired direction and just coasts the rest of the time, just like a human.

I submit, therefore, that the typical MJ thing of spewing mono in all directions for no apparent reason is merely the result of the autopilot trying obsessively to stay perfectly lined up on the docking axis despite all the undesired rotations introduced by unbalanced thrusters. Humans aren't so picking, thinking they'll fix things later, so don't do all this constant RCS use. But anyway, the RCS Balancer app cures this MJ problem.

BUT IMPORTANT NOTE: KSP 0.21 introduced a form of RCS balancer into the stock game. It comes on automatically when you hit CapsLock to get fine controls. Stock MJ2 seems unaware of this feature and doesn't know how to deal with it. So, if using the docking autopilot, be sure NOT to have CapsLocks on or the MJ ship will just sit there doing nothing.

I was always using the RCS balancer and never noticed it to do what you describe. In the most recent updates (maybe just Sarbian's not sure) I had to turn that off along with all other RCS related settings to correct other docking issues. Maybe I'll try it again now that things are working better in these last few updates.

Link to comment
Share on other sites

I submit, therefore, that the typical MJ thing of spewing mono in all directions for no apparent reason is merely the result of the autopilot trying obsessively to stay perfectly lined up on the docking axis despite all the undesired rotations introduced by unbalanced thrusters.

I submit that even with thrusters perfectly balanced using RCS Build Aid, on a ship that has used no fuel from the stage for which the thrusters are balanced... I've still seen MJ flop about spewing mono wastefully. I don't typically use MJ for docking any more (it's not even present on the build I currently play) but it's nice to know that the RCS balancer helps in that regard.

I definitely recommend the RCS Build Aid plugin as well as TAC Fuel Balancer for people with these issues.

Link to comment
Share on other sites

Hrm. I just tried docking with this latest version and I can't get the autopilot controls to show up when I select a target dock. The 'you must select...' message goes away, but it's just an empty panel. I'm reinstalling and trying again.

Link to comment
Share on other sites

BUT IMPORTANT NOTE: KSP 0.21 introduced a form of RCS balancer into the stock game. It comes on automatically when you hit CapsLock to get fine controls. Stock MJ2 seems unaware of this feature and doesn't know how to deal with it. So, if using the docking autopilot, be sure NOT to have CapsLocks on or the MJ ship will just sit there doing nothing.

Yes, I want to use that but to make it work best I need to check how the RCS trust change when it's activated and add a special case in the VesselState code. I don't think it will be complex but it does need some code.

I may look into interfacing with TAC balancer too.

@johnsonwax Check your logs for error, but here docking works fine

Link to comment
Share on other sites

I am running the latest update, and i am noticing something 'funny' with this latest version. there seems to be some form of resonance at certain closure speeds for certain vessel mass / load.... using the same vessel, my space station tug, when moving different parts around, my rcs usage sometimes will be almost nothing at .35 m/s but at .25 the same load will start pushing forward then back , blasting maximum amounts of rcs +5 to 10 per burn, but at .35 or .23 it goes back to normal, very efficient burning with 0.01 to 0.03 occasional 'pops'... any one else seeing this???

Link to comment
Share on other sites

Hey this MechJeb2-Multipatch.zip is a good amount older than what's in the repo - but there's no release or build notes. I already have Unity and VS2013 installed so I shouldn't be missing much.

If you could post the quick and dirty build instructions I'd appreciate it and be willing to help test the latest changes - or just throw me an up-to-date link to where I missed the instructions and i'll figure it out myself. :)

Link to comment
Share on other sites

Hey this MechJeb2-Multipatch.zip is a good amount older than what's in the repo - but there's no release or build notes. I already have Unity and VS2013 installed so I shouldn't be missing much. If you could post the quick and dirty build instructions I'd appreciate it and be willing to help test the latest changes - or just throw me an up-to-date link to where I missed the instructions and i'll figure it out myself. :)
In the zip file, the AR202 part.cfg is time stamped 9/1/2013 12:02pm, and the MechJeb2.dll is time stamped 8/31/213 3:28pm. The changelog can be found in the first post of this thread which is being updated as sarbian works on the plugin. Quoting sarbian: [blockquote]August 31 ter (2.0.13243.1528) Tavert #163 g0 in fuel flow simulation should be 9.82 Move MJ2 Button with a right click drag and drop August 31 bis (2.0.13243.1312) Ship flying away when docking from opposite side of the station Better RCS usage, I hope Speed Limit can't be negative Default docking speed is set to 0.5m/s now. Check yours and don't let it at 0 ( unlimited speed ) August 31 (2.0.13243.0010) ( more info ) deactivate ASAS when MJ take control Ascent AP : Turn start altitude can't be set to 0km Remove special case for ascent AP that may turn some ship too soon. Add some feedback for this special case Made BloodyRain2k Auto ascend params use clearer with a radio button to activate it Improved Docking AP - More agressive and does dock Fix Exception spam on "Suicide burn countdown" & "Time to impact" taniwha-qf #162 : MechJeb doesn't see in-flight docked fuel[/blockquote] On edit: Not sure why line breaks and vBulletin shortcodes are being filtered out of my reply. *sigh* Edited by lincourtl
Link to comment
Share on other sites

I have a (quick) feature request. Could you add way to have the ascent guidance turn on the SAS reaction wheels if the rocket starts oscillating?

For some of my larger rockets I've found I've had to turn on SAS and only kick on the ascent guidance during the gravity turn.

Link to comment
Share on other sites

I have a (quick) feature request. Could you add way to have the ascent guidance turn on the SAS reaction wheels if the rocket starts oscillating?

For some of my larger rockets I've found I've had to turn on SAS and only kick on the ascent guidance during the gravity turn.

if you want to reduce the "shivering" try increasing the value of Tf:

In this Mod Tf determines the cutoff frequency of a low pass filter, approx:

-> Fcutoff = 1 / (Tf * 2 * Pi)

for high values ​​of "Tf" the cutoff frequency is lower. PID constants are recalculated from Tf.

Large values ​​of Tf are more suitable for large ships (0.6 ... 0.3) and small values ​​of Tf (0.3 ... 0.1) for small craft. Large values ​​Tf slow the PID response, smaller values ​​make faster.

If your ship wobbles whit with Tf values ​​of 0.6 would be better to make more rigid spacecraft using "EAS-4 struct connector"

Values ​​lower than 0.05 eliminate the ability of the filter (the minimum processing time is similar).

Link to comment
Share on other sites

Although MJ is generally excellent, I have a bug report/question. It seems that when MJ is calculating a burn time, it sums up the dV of all engines on a craft, regardless of whether or not they're activated (or pointing in the right direction). My larger ships tend to consist of several independent modules hooked together (landers, etc.), so a given "ship" will probably have 8-12 engines in it, most of which are disabled. If you have MJ calculate & execute a node, it and the game properly calculate the dV and place the node, and the game shows a correct burn duration for the number of engines active. However, it appears that MJ is calculating its own burn duration when deciding when to start the burn, and it seems to include all engines on the craft, regardless of whether they're turned on. This can lead to some pretty significant errors.

Some made up numbers for the sake of example: if my large ship has a total of 14 engines, 2 of which are activated for interplanetary insertion, MJ will calculate a 2000 dV burn, which the node display will show as taking 20 minutes. However, MJ does its own internal calculation and decides that if all 14 engines were active (even if they're pointing in the wrong direction), the burn should only take 5 minutes. Thus, MJ starts the burn at -2:30 rather than -10, potentially offsetting my interplanetary trajectory significantly.

It seems the "expected" behavior of MJ would be to only sum the dV of engines that are activated when the node is created when calculating burn times. Hopefully this is an easy fix, and this post isn't too long...

Link to comment
Share on other sites

In the interim, you can fly the burn manually by having MJ lock on to your node and burning the engines yourself.

That said, I too would like to see MJ's TWR calculations refined at some point, some burns are burns where you really just want the computer to fly it even though flying manually is always an option.

Link to comment
Share on other sites

if you want to reduce the "shivering" try increasing the value of Tf:

In this Mod Tf determines the cutoff frequency of a low pass filter, approx:

-> Fcutoff = 1 / (Tf * 2 * Pi)

for high values ​​of "Tf" the cutoff frequency is lower. PID constants are recalculated from Tf.

Large values ​​of Tf are more suitable for large ships (0.6 ... 0.3) and small values ​​of Tf (0.3 ... 0.1) for small craft. Large values ​​Tf slow the PID response, smaller values ​​make faster.

If your ship wobbles whit with Tf values ​​of 0.6 would be better to make more rigid spacecraft using "EAS-4 struct connector"

Values ​​lower than 0.05 eliminate the ability of the filter (the minimum processing time is similar).

I think he's talking about the apoapsis fine tuning which causes a constant cutting in and out of the throttle. Tf affects roll, yaw and pitch but I've never seen it have any effect on throttle. It's what causes my very large rockets to start pitching up after the fine tuning but before circularization is plotted. Cutting in SAS helps.

Link to comment
Share on other sites

Ok, I think I found the solution to both of my problems - the docking not working right and the poor prediction for ascent rendezvous. I had a slightly corrupted save and the logs were getting spammed with some sort of error. Probably a result of my part hacking. Upon relaunching, everything seems to be working fine.

Link to comment
Share on other sites

After some failed attempts to reach Moho with a reasonable dV budget, I've have been having a lot of success using the launch window planner (http://alexmoon.github.io/ksp), specifically the mid-course plane setting. To use it, I need to set the initial parameters of the ejection burn manually (usually in 2 kicks due to typically low interplanetary TWR). After launching into Kerbol SOI, MechJeb2 can take over and perform the expected mid-course plane change maneuver using the fine tune closest approach planner.

However, setting up that initial ejection angle is more of a pain than it needs to be. I typically would orbit at least once and use the orbit info window to find where to create the maneuver node for the right angle to prograde, then do the initial kick burn, then set it all up again for the interplanetary burn. Or I could get impatient and eye the ejection angle, only that angle is actually quite important for big burns like Eeloo or Moho (http://forum.kerbalspaceprogram.com/showthread.php/27236-Tutorial-Step-by-step-Interplanetary-Hohmann-transfer-guide-and-tips). So what I really wanted, was that MechJeb should be able to snap the maneuver node to a particular prograde angle. After all, it calculates the prograde angle in the orbit info window.

So I added the ability to show and set it in the maneuver node editor window, like shown here (I'm the probe body setting up a 800 m/s kick burn):

nWMW8WP.png

This ends up working really well with the shift time feature, as you can shift by say twice your orbit period and then snap it back to the desired prograde angle to get the optimal ejection angle at the perfect time. For convience with the launch window calculator, you can set the retrograde angle instead (which is just prograde-180). I thought it would be trivial to make, as I could just assume a circular like orbit and have it mostly work. But the results for kick burn orbits were horrendous, so I ended up learning a ton about Kepler orbits and the internal programming interfaces of MechJeb and KSP. And, wow, it actually works!

Wp8oyY7.png

I made it for me, but if anyone else is interested I can set up a pull request of github (as a giving back sort of thing).

Cheers,

CyberSoul

P.S. First Post

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...