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

[Sudragon]

Would it be possible for all the Mods that create an on screen button to share the code for the ability to move that button?

Or all coordinate on making a 'toolbar' mod to dock them to?

I'm cross-posting this on multiple threads.

[sarbian]

Did you try to click and drag with the right mouse button ?

[Sudragon]

MechJeb is very good with this, I'm trying to get mod makers to co-operate on buttons.

[sojourner]

seems like alot of trouble for little reward. Especially as some mods stop getting updated due to lack of interest leaving other mods tied to them broken. Mods that interact in a friendly manner is a good thing. Mods that start to require other mods start to cause trouble.

[Dax]

Do you have errors in the log ? Did you try the dev version ?

Did you add the part on the ship ?

Does your install looks like that ?

KSP\GameData\MechJeb2
                                    \Plugins\MechJeb2.dll
                                    \Parts
                                         \MechJeb2_AR202\...
                                         \MechJeb2_Pod\...

Yes, this is how I have it. Any other ideas? Thanks

[sarbian]

The usual suspect :

Disable Anti virus, move the install out of Program Files if it's there (try C:\games\ksp of something like that).

If it still does not work launch the game, build a rocket with the AR202 module on in, send it to the launch pad. Then exit the game and copy your ksp\KSP_Data\output_log.txt to pastebin.com so I can take a look at it.

[BurningSky93]

I'm having some problems, for some reason when I'm on my craft's last stage, if I enable surf on Smart A.S.S. and then use my own personal input (i.e. press WASDQE myself), Smart A.S.S. will stop working. The surf function will still be enabled, but it wont actually input any control (I can see that the control surfaces on my craft aren't moving). Toggling the surf function on and off won't correct this, it is basically faulty for the remainder of the flight.

To give precise information in case this is highly situational:

-Craft uses the MK1 spaceplane cockpit, AR202 case and B9 aerospace parts

-Flight starts, I stage to activate the engines

-Input attitude values into surf, enable surf, control surfaces move as craft attempts to move the craft to given attitude (but it's on the runway, so it can't)

-Throttle up, craft accelerates and lifts off

-Craft takes attitude inputted into surf

-At this point, if I press anything on WASDQE, the moment i release the key the control surfaces will return to their "home" position, surf does not take over the attitude control again

-This happens only on stage 0, but it doesn't matter if the engines and cockpit STARTED on different stages, if I stage to 0, surf will cease to function after user input.

YES, I have electric charge, I'm not stupid.

EDIT: Ok, I seem to have found out what the problem was. Under attitude adjustment, the Tf value may have been too high, however, when it is too low the craft will jitter and oscillate wildly. How do I correct this?

Edited November 9, 2013 by BurningSky93

[skips]

I have been playing around with maneuvers with MechJeb 2.1.0.0-102 and have noted a number of interesting anomalies.

1. When using the maneuver planner and scheduling a burn at apoapsis, the burn starts at or after the passage of apoapsis. This effect can be best seen by scheduling a long burn. I expected the maneuver to be centered on apoapsis.

2. The burn time estimate does not seem to take into account the effects of the throttle limitations that are present in the Utilities dialog. Setting the Limit Throttle value to 10% does not increase the expected burn time by a factor of 10.

3. Using Smart ASS to hold the heading of the spacecraft in Orbit mode to +NML and throttling up for 1 minute centered on ascending node passage changes the shape of the orbit in addition to its inclination. I expected that burning normal to the plane of the orbit to leave the in-plane velocity (and so the shape of the orbit) unchanged.

skips

[BurningSky93]

I have been playing around with maneuvers with MechJeb 2.1.0.0-102 and have noted a number of interesting anomalies.

3. Using Smart ASS to hold the heading of the spacecraft in Orbit mode to +NML and throttling up for 1 minute centered on ascending node passage changes the shape of the orbit in addition to its inclination. I expected that burning normal to the plane of the orbit to leave the in-plane velocity (and so the shape of the orbit) unchanged.

skips

Consider a right angled triangle. The hypotenuse of the triangle is your resultant velocity after the burn and has a "vertical" (your normal burn) component and "horizontal" (your initial in-plane velocity) component. After your burn, your resultant velocity is given by Pythagoras' theorem and will be greater than your original in-plane velocity, hence if you burn at periapsis say, you will increase your apoapsis radius in addition to changing your inclination.

Hope this helps.

[Franklin]

I'm sure this has been asked before, so I'm prepared to get barked at, but why is my MechJeb missing all the guidance/auto options?:

edit: This is in career mode.

Edited November 9, 2013 by Franklin

[Nibb31]

If you're sure it's been asked before, then why didn't you look?

The advanced functions aren't available until you unlock them in the tech tree.

[Franklin]

I had looked, couldn't find a definitive answer, but was sure I wasn't the first to ask. Either way, thanks for the explanation.

[skips]

... The hypotenuse of the triangle is your resultant velocity after the burn and has a "vertical" (your normal burn) component and "horizontal" (your initial in-plane velocity) component. ...

In other words, this behavior is an artifact of the numerical integration of the equations of motion rather than the expected behavior. It is a good thing that the simulation of gravitational acceleration does not have this same artifact.

skips

[Galane]

Nope, it's how burning perpendicular to an orbit would really work. Turn the ship perpendicular to the direction of orbital motion and fire the engine. The resulting vector is then between the original direction of motion and 90 degrees to it.

Thus the forward speed is altered. Any alteration in orbital speed changes the orbital altitude. Thrust prograde and altitude increases, yet you fall behind an object that was next to you at your starting altitude. Thrust retrograde and the opposite happens.

It's counter-intuitive. You'd think by thrusting prograde to increase speed you could catch up to another ship that's ahead of you, but instead you increase altitude to a slower orbit.

If you have a lot of fuel to burn you could do a forced orbit. Angle the thrust vector somewhat outward to both increase speed *and* keep to the same altitude. But as soon as you let off the outward thrust the ship's speed will carry it to a higher altitude.

Forced orbit burns would be a nice addition to MechJeb. Useful to do quicker rendezvous, but once the distance is closed it'd have to do a big retrograde burn to get rid of the speed to stay in the orbit. That would take a LOT of fuel, thus the reason why forced orbits are generally only found in SciFi with torchships or other drive systems that don't yet exist.

[Duke-49th]

Hello.

I have a question or suggestion.

In the "Custom Window Editor" you can show the "Autostage status" and "Autostage settings".

But it is not possible to activate autostaging. And in no other window I found such a function, except the Ascent Autopilot.

Is it possible to activate autostaging?

That would be really nice. If you need to quickly stage, like if you have a big rocket on low vertical speed and espacially with low fps, that would be very helpful sometimes. Not always necessary. But sometimes it is. Beside that Im a lazy pilot

Edit: Okay...I found it..it is now in "Utilities" - This at least helps me. But it would be nice to have it as a choosable item in the "Custom Window Editor" - as if not, it makes no sense to have the other autostage things in there. But I guess this is just a mistake by the dev to not include the autostage on/off function. (?)

So I dont need to open another window (Utilities) and only have my one window with all informations and functions I really need

Ohh..and the autostage once function is a nice one. Sometimes all I need and want - should be a choosable item in custom window editor too (as I state above..with heavy rockets and low fps it is sometimes critical to stage by hand - and here I mean the first few stages)

Btw..if someone could give me the ID of that item, I may can add it by hand in the configuration file? (if that is possible at least..or if that item has an ID at all...) So I dont need to wait the next update^^

Thanks

Edited November 10, 2013 by Duke-49th

[sarbian]

It's in the utility window

[skips]

Nope, it's how burning perpendicular to an orbit would really work. Turn the ship perpendicular to the direction of orbital motion and fire the engine. The resulting vector is then between the original direction of motion and 90 degrees to it.

If this statement was true, then a circular orbit in a gravitational field would not be possible. In a circular orbit the gravitational acceleration it perpendicular to the velocity vector. It turns the vector and does not modify its magnitude. The same result should occur if you thrust in the direction normal to the orbital plane.

At least that is the way I read Newcomb.

[Artorp]

If this statement was true, then a circular orbit in a gravitational field would not be possible. In a circular orbit the gravitational acceleration it perpendicular to the velocity vector. It turns the vector and does not modify its magnitude. The same result should occur if you thrust in the direction normal to the orbital plane.

At least that is the way I read Newcomb.

You are correct, not sure what the others are on about, they probably misunderstood you burning normally with you burning in the same direction (which once was perpendicular to the orbit) over a long duration. It's probably an artifact of the engine itself and not with MechJeb missing the mark. Try burning at a lower thrust, I found I could change my inclination indefinitely without changing the eccentricity notably by burning with TWR at about 0.5.

[Galane]

Build 102, force roll in Smart A.S.S. and Docking Autopilot are 90 degrees off from each other.

[skips]

@artorp: Thank you for the suggestion. I found that the rate of change of the orbit was relatively little with accelerations less than about 0.2 percent of the orbital velocity. Unfortunately that makes rotating the orbital inclination by 90 degree take approximately 800 seconds. I guess that this result clears the Smart ASS as the cause of this issue and means it is a limitation of the game's equation of motion integrator. (sigh)

@galane & @BurningSky93: I apologize for being so "snarky" in my replies. The explanation that each of you gave is correct if you are adding two velocity vectors. The situation that I described (thrusting normal to the orbital plane) involves applying a force (or equivalently an acceleration) to a velocity vector, which is a different situation.

A simple "gedanken" experiment will show how the two situations are different. Consider two cases of applying a delta-V of 2 m/sec to a velocity of 10 m/sec using an acceleration of 1 m/sec/sec.

1. the delta-V is applied with a delta-t of 2 seconds as a single impulse of 2 m/sec. the resulting vector has a magnitude of sqrt(100+4) = 10.198 m/sec and is rotated by inverse-tan( .2 ) = 11.31 degrees.

2. the delta-V is applied as two impulses of 1 m/sec separated by delta-t of 1 second of time. The total impulse is still 2 m/sec. The first impulse changes the magnitude of the vector to 10.050 m/sec and rotates the vector by 5.71 degrees. The second impulse is applied to this vector and changes the magnitude to 10.100 m/sec and rotates the vector by another 5.68 degrees for a total rotation of 11.39 degrees.

Notice that the two solutions are different. The situation that I described is the limit where you reduce the delta-t between impulses to zero (think calculus). In this limit the magnitude of the vector is unchanged and the rotation after two seconds of acceleration of 1 m/sec/sec is 11.46 degrees.

skips

[BurningSky93]

@artorp: Thank you for the suggestion. I found that the rate of change of the orbit was relatively little with accelerations less than about 0.2 percent of the orbital velocity. Unfortunately that makes rotating the orbital inclination by 90 degree take approximately 800 seconds. I guess that this result clears the Smart ASS as the cause of this issue and means it is a limitation of the game's equation of motion integrator. (sigh)

@galane & @BurningSky93: I apologize for being so "snarky" in my replies. The explanation that each of you gave is correct if you are adding two velocity vectors. The situation that I described (thrusting normal to the orbital plane) involves applying a force (or equivalently an acceleration) to a velocity vector, which is a different situation.

A simple "gedanken" experiment will show how the two situations are different. Consider two cases of applying a delta-V of 2 m/sec to a velocity of 10 m/sec using an acceleration of 1 m/sec/sec.

1. the delta-V is applied with a delta-t of 2 seconds as a single impulse of 2 m/sec. the resulting vector has a magnitude of sqrt(100+4) = 10.198 m/sec and is rotated by inverse-tan( .2 ) = 11.31 degrees.

2. the delta-V is applied as two impulses of 1 m/sec separated by delta-t of 1 second of time. The total impulse is still 2 m/sec. The first impulse changes the magnitude of the vector to 10.050 m/sec and rotates the vector by 5.71 degrees. The second impulse is applied to this vector and changes the magnitude to 10.100 m/sec and rotates the vector by another 5.68 degrees for a total rotation of 11.39 degrees.

Notice that the two solutions are different. The situation that I described is the limit where you reduce the delta-t between impulses to zero (think calculus). In this limit the magnitude of the vector is unchanged and the rotation after two seconds of acceleration of 1 m/sec/sec is 11.46 degrees.

skips

I was of course assuming an instantaneous burn, which I believe would make my explanation correct? Obviously it's very hand-wavy.

[NNYGamer]

I looked back over the posts but didn't see my problem mentioned. Maybe I missed it. It may be my designs too.

Whenever I have mechjeb going to a maneuver node it seems to over control it. It spins around the long axis, over powers to the node, over shoots and goes back and forth. I've tied turning off all ASAS/SAS and gimbles, made sure the RCS was balanced but still it goes crazy. Turning of mechjeb lets me manually go to the node but it still over corrects/spins when I'm at it.

Even on launch it won't keep on track, it goes up and down. Same ship design worked fine with the old version.

I think I found the problem, there is an option to use standard SAS (or something like that) and after clicking it off my ships are not over controlled. Docking goes quite smoothly and actually faster then before.

[skips]

I was of course assuming an instantaneous burn, which I believe would make my explanation correct?

The problem with assuming an instantaneous burn is that the normal to the orbit is not well defined. At the burn time, the orbit has two orientations. If one assumes that the average of the two normals is the appropriate normal, then the angle that the delta-V makes with the two velocities is equal. By definition, this situation is the definition of an isosceles triangle, which makes the two velocities equal. For the example that I gave earlier (magnitude of the velocity is 10 m/sec and the delta-V is 2 m/sec), the law of cosines gives the rotation as 11.48 degrees.

skips

[softweir]

Build 102, force roll in Smart A.S.S. and Docking Autopilot are 90 degrees off from each other.

Force Roll has two modes: when a docking port is set as target, and otherwise.

When a docking port is targeted (such as when Mechjeb is in Docking mode, but also when manually docking and using "Parallel -" or "Parallel +") then the roll is relative to the target docking port. This helps ensure the ports are lined up after docking. This is excellent news for those trying to create neat space-stations, or those who suffer from docking O.C.D!

At all other times that I am aware of, force-roll is relative to the current orbited body, so it tries to level the navball.

I suspect that in your instance, the port you were docking with just happened to be at 90deg to the local horizon.

EDIT: I discovered this feature totally by accident only yesterday.

Edited November 10, 2013 by softweir
Afterthoughts.

[Galane]

I had two ships both with control set to a docking port and the other ship's docking port as the target. I then set one ship to Kill Rot then on the other ship (the one to be doing the docking) I turned on force roll in SASS with a setting of 0 degrees.

I then turned off force roll, then click OFF on SASS so it'd go to auto when I enabled docking autopilot. Then I enabled force roll, 0 degrees in docking autopilot and the ship rotated 90 degrees instead of keeping the same orientation SASS used.

Since the control parts and target parts were not changed between SASS control and Docking Autopilot control, the roll should not have changed.