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

[sarbian]

7 minutes ago, dboi88 said:

@sarbian I've finally settled on a design for the template page. I'll stick with this if you are happy with it?I'm about half way though the content, won't be long now.

Hard to tell without content to read  but that seems OK.

[dboi88]

18 minutes ago, sarbian said:

Hard to tell without content to read

The text will be formatted and spaced more clearly as i add the content but here's what it looks like with some quick text and image over the top.

 

[edemlama]

Ok I'm having another issue with Ascent Guidance: once activated it makes, an otherwise stable rocket, roll violently and randomly (with  or without the force roll option activated) is anyone experienced the same issue?

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

Edited February 1, 2017 by edemlama

[ansaman]

For sarbian, (on topic) http://imgur.com/gallery/hJrYK6D

[iFlyAllTheTime]

I can't seem to rename my Custom Windows. Is anyone else running into a similar issue?

 

Thanks for the great mod btw.

[DerekL1963]

If any other MechJebbers are into airships...  Smart A.S.S. does a bang-up job of controlling them and the Surface Info window gives a lot of handy information.

@sarbian if @r4m0n doesn't see this, could you ask him to update the old Mechjeb thread to point to this one?  It currently points to the one that was lost in the forum hiccup right after the New Year.

[edemlama]

I forgot to attach the log, here it is:

https://mega.nz/#!y8dECAQa!qNUh8KaST1H3g8K_ll7D9TuaIcF0Pvh9bATabD4W6Ac

 

[Starwaster]

On 1/31/2017 at 5:47 PM, edemlama said:

Ok I'm having another issue with Ascent Guidance: once activated it makes, an otherwise stable rocket, roll violently and randomly (with  or without the force roll option activated) is anyone experienced the same issue?

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

It's those control surfaces. Lose them. Unless your engines are not gimbaled. If that's the case and you absolutely need control surfaces then reduce their control authority to somewhere between 30-50%

If those engines ARE gimbaled then you don't need control surfaces

[Loren Pechtel]

3 hours ago, Starwaster said:

It's those control surfaces. Lose them. Unless your engines are not gimbaled. If that's the case and you absolutely need control surfaces then reduce their control authority to somewhere between 30-50%

If those engines ARE gimbaled then you don't need control surfaces

Second this.  You almost never need any control surfaces when MechJeb flies a rocket even if you need them to fly it manually.  I have found two cases where I wanted some:

1)  Flying a low-tech design that was still in use when I unlocked the ascent module.  I've found some long, thin birds made with 1.25m parts need some fins.

2)  When I'm hauling something obnoxious like a rover that's not shielded.  I haven't needed a fin since I switched to lifting such things with skycranes, though.

Note that on the way down is a different matter.  I have had a lot of trouble with birds with two passenger compartments behind the capsule.  I forget what mod it is but I found some grid fins that I slap on the capsule of such rockets, they're no longer prone to lawn darting and they're draggy enough when deployed that I survived a lawn darting.  (I play with Stage Recovery which means I hold onto my booster during re-entry if it has any fuel left.  I hold off on burning that fuel as long as I can and my entry angle was a little too steep that one time, the rocket flipped the instant the booster ran out of fuel.)

[edemlama]

18 hours ago, Starwaster said:

It's those control surfaces. Lose them. Unless your engines are not gimbaled. If that's the case and you absolutely need control surfaces then reduce their control authority to somewhere between 30-50%

If those engines ARE gimbaled then you don't need control surfaces

I got rid of them but MechJeb still wants to roll, it's not as violent and out of control as before but it still rolls 

[Starwaster]

1 hour ago, edemlama said:

I got rid of them but MechJeb still wants to roll, it's not as violent and out of control as before but it still rolls 

Lower your engine gimbal authority to 36%

If control authority is too low after that then gradually increase it. (36% should do fine)

[Guest]

MechJeb has been purring like a kitten lately. Less than one metre off target on the latest landing.

[WuphonsReach]

Unfortunately, docking is still a bit off in dev build #685.  The DPAI window is accurate, but the docking auto-pilot often comes in and is off on the horizontal axis (which would be an inclination difference if I'm thinking straight).  I'm wondering if the problem lies with calculating the target when the AP is turned on and then it taking so long to dock that not updating the target position again within the scene matters.

In general, I let docking auto-pilot get the craft lined up and on final approach to the target docking port, then I turn off auto-pilot and guide it in the last 3-10m by hand using DPAI.  Often that means just turning on SAS or KILL-ROT and doesn't require any X/Y translation with the I/J/K/L keys and just slowing down slightly using the N key.

One idea might be that once the craft gets within 2m of the target, with a closure rate of 0.10-0.30, and if the green lines in DPAI are close, that MechJeb should stop trying to adjust the offset using the RCS and just keep it from rotating as it travels the last 2m.

[Guest]

27 minutes ago, WuphonsReach said:

Unfortunately, docking is still a bit off in dev build #685.

 

Interesting. It was dead-on for me when it came to the docking and extraction of the LEM, fully automatic. 

[aluc24]

Hey, @sarbian , I've been using Mechjeb for controlling rovers for a while now, and I'm wondering - would it be possible to make Mechjeb detect if there's a sudden change in slop coming up, so that it could slow down the rover? For example, when approaching a crater, or exiting it. Right now, I either have to set my rovers to a very low speed (and sometimes even leave KSP running overnight to cross these hundreds of kilometers), or set them to high speed, and quickload each time they crash, which is kind of frustrating. After all, the usually Mun flat terrain allows very high speeds (50m/s +), but just one ridge, and the rover is gone. I try to set waypoints to avoid major craters and such, but it's impossible to avoid all dangers without slowing down.

Would it be a lot of work to implement dynamic speed control based on surrounding terrain?

P.S. I noticed that "Terrain look ahead" in the settings, but I have no idea, is it related to what I'm asking about?

Edited February 5, 2017 by aluc24

[iFlyAllTheTime]

On 2017-01-31 at 10:27 PM, iFlyAllTheTime said:

I can't seem to rename my Custom Windows. Is anyone else running into a similar issue?

 

Thanks for the great mod btw.

Sorry, I should've posted the output_log.txt here.

I'm using the latest Dev build.

Any help would be appreciated.

[Foxster]

Can anyone help me with a Landing Guidance issue?

As soon as contact with the surface is made, Landing Guidance disengages and Smart ASS becomes available again. If the landing was on a slope then I'm hovering the mouse over the Smart ASS screen to click  SURF+UP to stabilise things. Often I miss and the craft topples. 

Any way to get SURF UP on by default when Landing Guidance disengages?

Edited February 5, 2017 by Foxster

[Curveball Anders]

14 hours ago, WuphonsReach said:

Unfortunately, docking is still a bit off in dev build #685.  The DPAI window is accurate, but the docking auto-pilot often comes in and is off on the horizontal axis (which would be an inclination difference if I'm thinking straight).

Was the docking port mounted in line with the ship's axis or was it mounted sideways or in an otherwise 'odd' place or rotation?

[Starwaster]

32 minutes ago, Curveball Anders said:

Was the docking port mounted in line with the ship's axis or was it mounted sideways or in an otherwise 'odd' place or rotation?

That doesn't really matter because the docking AP looks at the part itself, specifically its transforms. The transform dictates where the part's docking axis actually is and which way it points. Because of that, a docking port can be located anywhere on the vessel and it can point any direction. The vessel transform isn't used and the docking transforms (up to two of them: One for control and the docking axis itself) can be different (and usually are) from the part's own transform.

[Curveball Anders]

Just now, Starwaster said:

That doesn't really matter because the docking AP looks at the part itself, specifically its transforms. The transform dictates where the part's docking axis actually is and which way it points. Because of that, a docking port can be located anywhere on the vessel and it can point any direction. The vessel transform isn't used and the docking transforms (up to two of them: One for control and the docking axis itself) can be different (and usually are) from the part's own transform.

Well, in my experience it does matter.

Never had any issues with the port in the classic in line position, often issues when out on the edges (like on larger space stations).

That why I asked where the docking port was located.

(But it's not an MJ issue, hold target has the same issues).

[Starwaster]

50 minutes ago, Curveball Anders said:

Well, in my experience it does matter.

Never had any issues with the port in the classic in line position, often issues when out on the edges (like on larger space stations).

That why I asked where the docking port was located.

(But it's not an MJ issue, hold target has the same issues).

Album demonstrating  use of inline ports, surface mounted and rotated.

http://imgur.com/a/FZltq

It really does not matter. If you had problems with something like this in the past then other factors were at work.

 

The docking AP may not be perfect but it's pretty robust and capable of handling some pretty weird configurations. The only thing I've really seen it have trouble with is where it has other larger parts that expand its bounding box to the point that the target port is deep inside. The reason being that it can get confused as to which side it needs to be on. Increasing the starting point and making sure it's on the right side beforehand can help it handle even those situations.

Edited February 5, 2017 by Starwaster

[Curveball Anders]

Just now, Starwaster said:

Album demonstrating  use of inline ports, surface mounted and rotated.

http://imgur.com/a/FZltq

It really does not matter. If you had problems with something like this in the past then other factors were at work.

The problem is very hard to reproduce and I don't know what relation to root, control point or distance that causes it.

But approaching a docking port way out on an 'arm' on a larger station creates a situation where MJ (and stock hold target) is aiming 3-4 meters off the actual center of the port.

I've gotten used to it so I kill the autodock 5-10 meters out and complete it manually.

My question to WuphonsReach was just out of curiosity if he had found some more data.

[Mandella]

15 hours ago, aluc24 said:

Hey, @sarbian , I've been using Mechjeb for controlling rovers for a while now, and I'm wondering - would it be possible to make Mechjeb detect if there's a sudden change in slop coming up, so that it could slow down the rover? For example, when approaching a crater, or exiting it. Right now, I either have to set my rovers to a very low speed (and sometimes even leave KSP running overnight to cross these hundreds of kilometers), or set them to high speed, and quickload each time they crash, which is kind of frustrating. After all, the usually Mun flat terrain allows very high speeds (50m/s +), but just one ridge, and the rover is gone. I try to set waypoints to avoid major craters and such, but it's impossible to avoid all dangers without slowing down.

Would it be a lot of work to implement dynamic speed control based on surrounding terrain?

P.S. I noticed that "Terrain look ahead" in the settings, but I have no idea, is it related to what I'm asking about?

While not exactly what you are asking for, you might be interested in this mod:

 

http://spacedock.info/mod/950/BonVoyage

[Starwaster]

27 minutes ago, Curveball Anders said:

The problem is very hard to reproduce and I don't know what relation to root, control point or distance that causes it.

But approaching a docking port way out on an 'arm' on a larger station creates a situation where MJ (and stock hold target) is aiming 3-4 meters off the actual center of the port.

I've gotten used to it so I kill the autodock 5-10 meters out and complete it manually.

My question to WuphonsReach was just out of curiosity if he had found some more data.

If you can provide me a station that demonstrates what you're talking about using only stock parts, I would love to see it.

Every other time that someone has said that MJ is 'aiming' or 'targeting' a point that is off-target, it's been a case of something else. Usually an inability of the docking craft to close the gap between the two docking axes. I've even demonstrated this in the past using custom code that shows how MJ is thinking and where it is really aiming at. (remember that in the final phase of docking, it keeps its docking axis parallel with the target docking port's axis)

[Curveball Anders]

Just now, Starwaster said:

If you can provide me a station that demonstrates what you're talking about using only stock parts, I would love to see it.

Every other time that someone has said that MJ is 'aiming' or 'targeting' a point that is off-target, it's been a case of something else. Usually an inability of the docking craft to close the gap between the two docking axes. I've even demonstrated this in the past using custom code that shows how MJ is thinking and where it is really aiming at. (remember that in the final phase of docking, it keeps its docking axis parallel with the target docking port's axis)

I'll see if I can find time to replicate it with only MJ.

And again, it's not MJ that is acting up, it's in the core game.