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

[sarbian]

No doubt. Perhaps my 'bug' has been fixed but I wonder if its always been there and I wonder if its been reported at all. The OP suggests this link to report bugs:

https://github.com/MuMech/MechJeb2/issues

I shall check if its been reported and list it if this is a new discover. Thanks.

No it was not reported, but it was fixed nonetheless.

As other said the current official release is not perfect. I should promote a new dev version as release but first I need to pinpoint the source of the undock/decouple problem to replace the dirty fix I made with a proper fix.

The problem is that I did not have much free time to dev for the last few days...

[Djolox]

Mechjeb is turning like crazy flipping over and burning RCS to the node and then burning back no precise control

[sarbian]

How am I supposed to reply to post like this ? You give no useful info, I don't know which version you run, the ship you fly and where you are flying it.

Mechjeb turn my ship fine here.

[federicoaa]

Mechjeb is turning like crazy flipping over and burning RCS to the node and then burning back no precise control

It is better for the developers if you give some useful information so they can recreate the problem and improve the mod

For example, MJ version, some picture/video of the ship, etc.

[TheDude]

Mechjeb is turning like crazy flipping over and burning RCS to the node and then burning back no precise control

Greetings,

I think I know what he's talking about. I'm running 2.1.1-167 on KSP 0.23 and I've noticed that sometimes Smart A.S.S. seems to fight itself to orientate the spacecraft. All of my ships are built with the RCS build aid so I have perfectly balanced RCS already. I've seen this behvior mostly when I follow these steps:

1. Enable RCS

2. In Smart A.S.S. enable "Force roll to X degrees"

3. Select prograde or retrograde which enables Smart A.S.S.

As the ship moves to pro/retro grade the force roll tries to roll the ship at the same time. This throws off the pro/retro grade orientation so it tries to compensate. The ship then will continue to spin and gyrate as the seemingly two modules/functions battle each other over the orientaiton of the ship.

Trigger events:

1. Having RCS enabled seems to make the problem worse as the movements are quicker and more forceful causing the ship to spin faster.

2. Having a ship with badly out of balanced RCS makes this problem really bad.

3. The more out of position the ship is at start seems to increase the likelyhood of the problem occuring.

To get around this I reverse the steps which seems to solve the problem.

1. Enable RCS

2. Select pro/retro grade orientation.

3. Wait a second or two while the ship start to reorients itself.

4. THEN select "Force roll x degrees"

If I may make a humble suggestion: Change the code so that the force roll is only executed when the orientation manuver has been completed.

Hope that helps.

Best regards,

The Dude

[sarbian]

If I may make a humble suggestion: Change the code so that the force roll is only executed when the orientation manuver has been completed.

Thanks for making more sense ^^

The same change was suggested on IRC. I nearly added it but I am afraid it will brake more things for plane, since they rely more on roll than yaw.

[AlmightyR]

I think I know what he's talking about. I'm running 2.1.1-167 on KSP 0.23 and I've noticed that sometimes Smart A.S.S. seems to fight itself to orientate the spacecraft. All of my ships are built with the RCS build aid so I have perfectly balanced RCS already.

(...)

As the ship moves to pro/retro grade the force roll tries to roll the ship at the same time. This throws off the pro/retro grade orientation so it tries to compensate. The ship then will continue to spin and gyrate as the seemingly two modules/functions battle each other over the orientaiton of the ship.

Actually, I have found out, which almost complete certainty, that the problem lies with unbalanced reaction wheels coupled with RCS, balanced or unbalanced, and not with RCS per-see. The problem is that both are used simultaneously and independently, and if one or both are unbalanced...

One example I tested unintentionally, was having a probe on top of a long 1.25m fuel tank, balanced RCS (also use RCS-BA here) distributed through 4x 4-symmetry rings, but "no reaction wheels", which actually means "unbalanced reaction wheels" because the probe's core has one. The end result was that, although the RCS pretty much dictated the turning and rolling operations, the difference to the same setup with a reaction wheel sitting just on top of the engine, below the fuel tank, was still quite noticeable. The first setup gets some Smart A.S.S. confusion, the second gets none.

Hope it helps!

[TheDude]

Thanks for making more sense ^^

The same change was suggested on IRC. I nearly added it but I am afraid it will brake more things for plane, since they rely more on roll than yaw.

Greetings,

(I'm totally talking out of my Smart A.S.S. here so feel free to mock me.....)

How about a check for air pressure? If the air pressure = 0 (vacuum) then reorient then roll otherwise do both at the same time.

Best regards,

The Dude

[AlmightyR]

The same change was suggested on IRC. I nearly added it but I am afraid it will brake more things for plane, since they rely more on roll than yaw.

How about a check for air pressure? If the air pressure = 0 (vacuum) then reorient then roll otherwise do both at the same time.

Please no...As far as I'm observing, this is not a failure with MechJeb, but of craft design; And thus the problem shouldn't be patched by the mod, but learned and corrected by the designers.

[TheDude]

Actually, I have found out, which almost complete certainty, that the problem lies with unbalanced reaction wheels coupled with RCS, balanced or unbalanced, and not with RCS per-see. The problem is that both are used simultaneously and independently, and if one or both are unbalanced...

I thought that no matter how many or where they were placed the combined forced of multiple reaction wheels was applied to the COM.

[sarbian]

AlmightyR : all it means is that MJ does not compute correctly the torque from reaction wheel far from the CoM.

The roll first is still a problem since MJ has to change its yaw/pitch correction while rolling.

Edit. TheDude : afaik the torque is applied to the part itself. And since I have no idea on how to transform this on torque applied to the CoM ...

[TheDude]

Greetings,

Yep, you're right.

All command modules except the EAS-1 External Command Seat have a reaction wheel and can provide torque. Adding additional parts utilising torque allows faster change in rotation. The placement does matter for reaction wheels. Generally speaking they can cause some problems if placed far from the center of mass. They function like grabbing the point where the reaction wheel is located and rotating around that point. The rotation will get anywhere other then near the center of mass.^[1]

Found here: http://wiki.kerbalspaceprogram.com/wiki/Reaction_wheel

And this:

Reaction Wheels :

The reaction wheels allow your vessel to spin by applying a torque directly to the part itself. This has replaced the old torque forces from the command pods that allowed a infinite source of control. They now require power to operate, and if you run out of electric charge, you will not be able to spin the command pods. You can still turn them if you have control fins or RCS instead. In short, all the reaction wheels do is spin your craft for you.

Found here: http://forum.kerbalspaceprogram.com/entries/740-Updated-Information-on-SAS-in-0-21-1

So to AlmightyR's point - Having reaction wheels located far away from the COM or in really bad places can cause all kinds of issues. Would good design have the reaction wheels as close to the COM as possble?

EDIT: Thinking aloud here... would it be better to disable all torque and/or reaction wheels if you're using RCS? Or have MJ disable torque and/or reaction wheels when using Smart A.S.S.

Edited January 20, 2014 by TheDude

[DerekL1963]

EDIT: Thinking aloud here... would it be better to disable all torque and/or reaction wheels if you're using RCS? Or have MJ disable torque and/or reaction wheels when using Smart A.S.S.

Disabling torque and reaction wheels when using SMART A.S.S. would mean ships without RCS would be uncontrollable when using SMART A.S.S..

[Commissar]

Disabling torque and reaction wheels when using SMART A.S.S. would mean ships without RCS would be uncontrollable when using SMART A.S.S..

not to mention, reaction wheels are nice to have for pretty much any sort of rotation, even when you have RCS. batteries are much lighter than monoprop tanks, and you can recharge them without needing to dock with anything.

I generally reserve RCS for docking.

pretty much the only time I use RCS outside of docking, is when i'm on the final intercept phase of rendezvous with my tankers. the only reason I use RCS then is due to the mass (and associated inertia and momentum) of 120k units of fuel, accompanying LOX, and 4000 monoprop. the reaction wheels simply don't have enough oomph for rapid turning.

otherwise, i'd be carrying way, way too much monopropellant, or i'd run out really fast. most of my spacecraft only carry 150-300 units of monoprop, because monoprop is really heavy. I don't even put any monoprop on craft I don't intend to dock, again, to save weight.

[TheDude]

... 120k units of fuel, accompanying LOX, and 4000 monoprop. .

Good gravy that's a lot of fuel. I'd love to see a picture (and a craft file) of that beast.

[Boamere]

So can someone explain orbital resonance to me? ;D

(I'm guessing it makes you orbit so that at orbit you are in a different place? (hard to explain but like chossing where you want to put a satellite if you have a ring of e.g 3?)

Edited January 20, 2014 by Boamere

[togfox]

No it was not reported, but it was fixed nonetheless.

Thanks Sarbian. Many people dont use dev versions as there is an impression that they are untested versions. If it is not officially released on the forum then its not official and its a gamble to dl and use. I stay away from ksp experimentals for the same reason. Just saying.

Im glad you fixed this one. Was a challenge to describe.

[Starwaster]

So can someone explain orbital resonance to me? ;D

(I'm guessing it makes you orbit so that at orbit you are in a different place? (hard to explain but like chossing where you want to put a satellite if you have a ring of e.g 3?)

It's useful for placing a network of geosync satellites. Everytime you arrive at apoapsis you drop a satellite and then circularize that satellite's orbit? Apoapsis has to be at geosync altitude though.

Or even not geosync, it's for regularly spacing out your sats.

[Starwaster]

Greetings,

Yep, you're right.

Found here: http://wiki.kerbalspaceprogram.com/wiki/Reaction_wheel

And this:

Found here: http://forum.kerbalspaceprogram.com/entries/740-Updated-Information-on-SAS-in-0-21-1

So to AlmightyR's point - Having reaction wheels located far away from the COM or in really bad places can cause all kinds of issues. Would good design have the reaction wheels as close to the COM as possble?

EDIT: Thinking aloud here... would it be better to disable all torque and/or reaction wheels if you're using RCS? Or have MJ disable torque and/or reaction wheels when using Smart A.S.S.

I've always taken that with a grain of salt even if it is official. Maybe they intended for off-center reaction wheel parts to be less effective but I think that in actual practice all reaction wheel torque is applied COM no matter where it is.

I wouldn't swear to that though and I guess it affects my rocket designs since I tend to put them close to COM or if applying them radially then in clusters around COM.....

Edit: never mind I take it back.

Edited January 20, 2014 by Starwaster

[Commissar]

Good gravy that's a lot of fuel. I'd love to see a picture (and a craft file) of that beast.

that may be off by an order of magnitude, it carries 1.5 big KW 3m tanks of LFO... not sure what that amounts to, but i'll check one I fix engineer redux... I know the monoprop is correct tho... 4 1000L tanks...

[OrbitalDebris]

I've been a fan of MJ for a while now and I wanted to thanks r4m0n, Sarbian and the other contributors for their excellent work. I also wanted to let the others here know a few tricks I've discovered over time, which you may find helpful.

• When building very long rockets, put a reaction wheel just after the first engine and another one every 2 stages - it makes the rocket respond faster to control inputs, which in turn allows MJ to make smaller corrections and you get a smoother ride.
  
• If you find that your rocket wobbles during an MJ-controlled ascent, it means that it's flexing (even if you can't see it) and you need to strengthen one or more joints. Use Kerbal Joint Reinforcement and/or struts.
  
• MJ's docking autopilot works best with symmetric spacecraft.
  
• If you notice that MJ overshoots nodes and needs to turn the craft around to do a correction (eg when circularizing), it means that the rocket engine is too powerful for the spacecraft it's pushing and you need to limit its thrust using the tweakable right-click menu the VAB. I wonder if this is something MJ could do automatically.
  
• A way to drastically reduce the number of times Jeb gets stranded is to get a delta-V map from the KSP wiki and use it with the MJ Delta-V Stats window while you're in the VAB. Remember that a good engineer always adds a bit extra - according to the map I'm using it takes 4550m/s to get to low Kerbin orbit, but in my experience it ends up being closer to 4800m/s.
  
• Related to the previous point, MOAR BOOSTARS is not always the answer to insufficient delta-V: rocket fuel is heavy, so you might actually end up with less delta-V after adding another stage! try the different rocket engines you can get from the spaceport (experiment by putting different engines in different stages) and try techniques like asparagus staging.
  

[togfox]

Good points and a worthy first post.

If you notice that MJ overshoots nodes and needs to turn the craft around to do a correction (eg when circularizing), it means that the rocket engine is too powerful for the spacecraft it's pushing and you need to limit its thrust using the tweakable right-click menu the VAB. I wonder if this is something MJ could do automatically.

MJ has a "Utility" menu that lets you reduce thrust to X% of full thrust. Yes - you can tweak in VAB, you can also tweak in flight - but the MJ utility option applies to all engines on all stages instantly and can be turned off at any time.

Welcome to the forum.

[OrbitalDebris]

Thanks! I figured I'd lurked long enough

[kalizec]

Would the following be an idea to add to a later version of MJ?

It happens regularly I'm playing around with very low thrust craft (think Ion engines and alike).

The current way MJ executes maneuvers doesn't always work with those craft because the orbital time isn't much larger than the projected burntime.

The most efficient way to use these engines is to no work with maneuver nodes, but instead just burn prograde and/or retrograde for a specific angular window each orbit.

MJ could help with this if it had options like:

- Burn prograde/retrograde until Apoapsis/Periapsis reaches X (does literally what it says).

- Execute maneuver node in N multiple orbits (divides burntime over N orbits).

- Execute maneuver node in N multiple orbits (same as above, but limiting each burn to the period it's within A degress of prograde/retrograde).

[Starwaster]

Would the following be an idea to add to a later version of MJ?

It happens regularly I'm playing around with very low thrust craft (think Ion engines and alike).

The current way MJ executes maneuvers doesn't always work with those craft because the orbital time isn't much larger than the projected burntime.

The most efficient way to use these engines is to no work with maneuver nodes, but instead just burn prograde and/or retrograde for a specific angular window each orbit.

MJ could help with this if it had options like:

- Burn prograde/retrograde until Apoapsis/Periapsis reaches X (does literally what it says).

- Execute maneuver node in N multiple orbits (divides burntime over N orbits).

- Execute maneuver node in N multiple orbits (same as above, but limiting each burn to the period it's within A degress of prograde/retrograde).

For #1 isn't it sufficient that you can already initiate burns that set apoapsis / periapsis to arbitrary altitudes? If you don't like where the maneuver node is then drag it around on the map until your ap/pe is where you want. Or use the node editor.

Some variation #2 & #3 is under consideration as the subject has had recent discussion. You're late to the party.