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

[Galane]

I did a few test with Galane lander. It seems most of the problem are related to the starting alt. I'll have to find out why.

Is there a starting altitude from which it will deorbit and just go and settle on the landing trajectory without wildly flipping around and firing the engines every which way?

[sarbian]

I did not try a lot of alt but at 150 it went on a proper trajectory. It crashed later but because aerodynamic flipped it and it could not recover from that.

The way it burn at lower alt is indeed strange. Something must return aberrant values

Is the docking ap going to use the much requested "align to docking axis first, then close distance" method?

You should try some of the newer dev version.

@sarbian I've never really run into issues with FAR and MJ's ascent autopilot going too wonky. Only a couple important things need to be remembered by users. 1) Turn early (0.1 Km) and 2) keep center of lift below center of mass until atmosphere thins enough for it not to matter (typically 30+ Km).

It works but it's still far from "proper" ascent profile for a rocket with FAR, and a lot of player still get confused by FAR + default profile. So one that does it better would be welcome I think.

[BARCLONE]

Sarbian,

Something I noticed on the last few tilt-over launch mishaps I've had was a tendency for MJ to hold the turn input a little too long, then try to do a reverse too late to matter. I'm wondering if an adjustment could be made to the slope of the inputs (their aggressiveness). Maybe be a little less aggressive on the start of the turn, but very aggressive in nullifying that input once the turn has started? Perhaps even anticipating the point of nullifying out the input and cutting back before the rocket reaches the turn attitude.

I'm guessing this is what MJ should already be doing, but the aggressiveness (or sluggishness) of the inputs might need some tweaking.

Also, one suggestion for a new user input control could be a "Start turn at xxx m/s" input box.

[Starwaster]

Is the docking ap going to use the much requested "align to docking axis first, then close distance" method?

Sarbian,

Something I noticed on the last few tilt-over launch mishaps I've had was a tendency for MJ to hold the turn input a little too long, then try to do a reverse too late to matter. I'm wondering if an adjustment could be made to the slope of the inputs (their aggressiveness). Maybe be a little less aggressive on the start of the turn, but very aggressive in nullifying that input once the turn has started? Perhaps even anticipating the point of nullifying out the input and cutting back before the rocket reaches the turn attitude.

I'm guessing this is what MJ should already be doing, but the aggressiveness (or sluggishness) of the inputs might need some tweaking.

Also, one suggestion for a new user input control could be a "Start turn at xxx m/s" input box.

Does MJ still have a problem calculating the effectiveness of control surfaces? If so it's probably not calculating the Tf properly for PID when in atmo....

But I think a bunch of work was done in that area and the FAR Extensions for MJ help it deal better with control surfaces under FAR.

[sarbian]

AFAIK all control surface are properly taken into account. There may be some errors, I'll do a quick check on that too.

I feel that the control works fine when you get the proper Tf. Right now the Tf auto tunning is not perfect for atmo flight.

[BARCLONE]

AFAIK all control surface are properly taken into account. There may be some errors, I'll do a quick check on that too.

I feel that the control works fine when you get the proper Tf. Right now the Tf auto tunning is not perfect for atmo flight.

FWIW, I don't use any aerodynamic parts on my rockets, like fins or winglets. It's all torque and thrust vectoring.

[Dr. Jet]

Tried to experiment with FAR+DE+MJ(with FAR support module) and heavy SSTO spaceplanes. Partial success.

Typical scenario:

1a) Manually launch, then slowly accurately pitch up close to the high-in-the-sky AG navball, then turn on AG with 0,1;69;0;35 (corrective steering off)

1b) Turn on AG with 0,1;69;0;20 (corrective steering on) right at start and pray about not catching a huge stall after takeoff

2) Wait till Rapiers or Sabres autoswitch and finally bring a spaceplane to orbit. Then do stuff at orbit (rendezvous, docking and such).

3) Deorbit burn to either 25km or even slightly negative PE, targetting at ocean to the west from KSC (Node planner or retrograde SASS and manual controlled burn).

3) Activate SASS with 90;5;0 setting (pitching 5 degrees about horizon). 5 to 7 degrees pitch seems to provides enough lift to aerobrake slowly without taking too much heat, while prograde trajectory with active DE effectively kills both spaceplane and crew. With shallow pitch at SASS almost no oscillation or wobbling occurs, what is good considering that any agressive pitch easily converts to stall.

4) At about 16 km altitude activate SPG "initiate hold" with 90;15000 and turn on engines (manually set back to airbreathing mode).

5) Pray about too aggressive SPG PID vertical oscillation and resulting wobbling not destroying spaceplane or put it to stall.

6) Wait for about 30 km distance to KSC runway. Activate autoland.

7) Pray about too aggressive SPG PID vertical oscillation not destroying spaceplane or crash it to land.

8) Slowly manually change thrust to zero. Manually deploy RealChute drag chutes at touchdown.

So... Almost everything is very nice , however landing process is a bit complex. Just few suggestions to make things better.

1) A separate AG trajectory for SPH launches - starting from 0 degrees pitch, not 90 degrees as for VAB launches. Easy to implement, I believe.

2) Absolutely needed option to make SPG's PID less agressive at pitch correction, ideally disabling vertical oscillation at all. Corresponding PID tweaks are already implemented in rover autopilot, i believe.

3) Some way to automate the abovementioned landing scenario (3-8) would be nice. Input parameters: deorbit starting node, aerobraking pitch, glide altitude (already in SPG), landing dive distance, landing angle (already in SPG). Glide heading is determined by target (KSC or island). Maybe Autom8 revival?

4) Maybe some FAR-compatible and spaceplane-compatible aerobrake calculator for predicting a deorbit node and other needed parameters? Alas it would be some complex math for sure...

5) RealChute mod support. It's much more useful for VAB projects, but nevertheless.

P.S. Still can't figure out if SASS is capable of holding "targetwise" heading with manually assigned pitch.

Edited February 28, 2014 by Dr. Jet

[Jacke]

Jacke : I'm afraid that's all there is. I'll have to work on it one day but docs never were my strong point...

It's still a great tool, sarbian. Even just for the Ascent Guidance alone. I also use the Manuever Planner to execute nodes I've created manually. (I also use PreciseNode beside MechJeb2 to get maneuvers right.)

I wish I could add an Autostage section to other windows, like Vessel Info. Ascent Guidance has one but for on-orbit Autostage you have to leave the Utilities window up.

[JedTech]

Hey Sarbian, the Rendezvous Planner needs to have an "Execute Next Node" button like the Maneuver Planner does.

[TK421d]

tried to use the docking autopilot last nite, set it and walked away. came back 10 minutes later and it was still "backing up to align...." etc.

the controls it was trying to use were still the old maneuvering controls (h,n,i,k,j,l) so it was just quivering in space. i had to map the secondary controlls in-game to the old ones to get it to work.

[sarbian]

MJ does not use the keys at all so I don't see how that would change anything. And I don't use the default key mapping either since I don't play on a QWERTY keyboard.

And you specify which version you use.

[TK421d]

v2.1.1.01

and in the popup for the docking, its labeled on the x,y,z axis' that it is using those keys??? also behavior went to normal as i said when i remapped the secondary use keys in the ksp settings.

screenshot: http://i.imgur.com/Pt5rE02.png

[sarbian]

it's just to help people who want to manually dock. It has nothing to do with how MJ control the ship.

[Starwaster]

v2.1.1.01

and in the popup for the docking, its labeled on the x,y,z axis' that it is using those keys??? also behavior went to normal as i said when i remapped the secondary use keys in the ksp settings.

screenshot: http://i.imgur.com/Pt5rE02.png

That was only coincidence.

The problem you described is intermittent. When I tried the latest docking AP, it would sometimes have extreme difficulty when presented with the perfect docking vehicles and targets in the perfect situation I set up for it.

Then it could turn right around and execute a perfect docking in a situation I deliberately made difficult.

[ImTheMinion]

I have a question. The version history says Mechjeb has support for toolbar using the Module Manager plugin (At least that's where the link sent me), but I have both installed but no toolbar support still... Was there a different module that the link was suppose to go to? I did see the toolbar support plugin by sarbian, but he states the newest toolbar update broke the integration.

Edited March 2, 2014 by ImTheMinion

[ctbram]

I have been trying out the beta builds and I just installed #187. So that I do not have to constantly rebuild my custom and ship specific cfg's I have been deleting the entire fold before installing the new mj and then I copy the plugins\plugindata folder from the mechjeb being replaced.

Is this okay? If you ever change the compatibility of the .cfg files please note it in the jenkins page release notes. I just have a fear one day copying this folder is going to bite me in the butt. But the thought of constantly rebuilding my customs windows outweighs the butt biting thing

[sarbian]

Don't worry. The way MJ is done it should never explode with old config file. The "worst" I have seen is that players with old config don't get change made to the default windows (like if I add something to the Vessel Info window)

ImTheMinion : yes, I need to redo the toolbar integration.

[K3-Chris]

Any of the recent fixes fixed that the 3m KW docking ports don't line up properly with a 2m docking port? they're capable of docking with 3m and 2m ports, but when docking with a 2m port it's offset so that one edge lines up, like so: Oo which doesn't work.

[Starwaster]

Any of the recent fixes fixed that the 3m KW docking ports don't line up properly with a 2m docking port? they're capable of docking with 3m and 2m ports, but when docking with a 2m port it's offset so that one edge lines up, like so: Oo which doesn't work.

If I understand the problem, I think the newer dev versions should dock it better. Though in my experience the new docking AP's reliability is not constant. Sometimes it does good and sometimes not so good. But when it works it is better at aligning the docking axes than pre-170 versions which tended to come in at nearly a 45 degree angle.

[K3-Chris]

No it's not the old problem of sideways docking, it aligns really far out and remains completely steady aimed like 0.5m wrong sideways the whole way, I assume because the 3m KW port also works as a 2m port but the 2m port functionality is offset from the part's edge since it's centered, but MJ still aims for the edge to align, think of it as the top left "corner" of the part being the root instead of the center.

The orb and the docking UI thingy are both correct however, and shows MJ is misaligned the entire time, I can't use the docking ap to dock 3m with 2m, I have to do it manually.

It's a problem with MJ aligning the parts, not actually with how MJ approaches etc, it can do 2m to 2m and 3m to 3m docking just fine, but docking a 2m port to a 3m port or visa versa it always mis-aligns the same way. and the same amount.

Edited March 4, 2014 by K3|Chris

[Starwaster]

No it's not the old problem of sideways docking, it aligns really far out and remains completely steady aimed like 0.5m wrong sideways the whole way, I assume because the 3m KW port also works as a 2m port but the 2m port functionality is offset from the part's edge since it's centered, but MJ still aims for the edge to align, think of it as the top left "corner" of the part being the root instead of the center.

The orb and the docking UI thingy are both correct however, and shows MJ is misaligned the entire time, I can't use the docking ap to dock 3m with 2m, I have to do it manually.

It's a problem with MJ aligning the parts, not actually with how MJ approaches etc, it can do 2m to 2m and 3m to 3m docking just fine, but docking a 2m port to a 3m port or visa versa it always mis-aligns the same way. and the same amount.

MJ does no such thing. It doesn't aim for the edge or anything. It aims for the docking port's transform. The only way it would deliberately aim for the edge is if the docking port has offset transforms. By default it aims for the part's transform itself, but that can be overridden when designing a docking port part.

Also, I just did two flawless dockings with two quick docking targets I put together. One with the KW 3m port and one with the 2m port

I'm not sure exactly where the KW port's transform is but if it's sunk into the part (which is fairly large and bulky) what would happen if MJ did not precisely align with the docking axis? It would clip the edge, wouldn't it. (that's not really a question, that is exactly what it would do)

The version of MJ I'm currently using is a personally modified version of build 168 which gives guarantees that it will be aligned before approaching. It had absolutely no problem docking the two parts and I deliberately placed them back to back before initiating docking so it would have to back up the long way around on its own and then figure out how to approach.

Some screenshots. Notice shots 2-4. See where the target indicator is for the port? It's actually at the BOTTOM of the part. But the top is what needs attaching to. Anything but a flawless approach risks clipping the edge.

Javascript is disabled. View full album

Edited March 4, 2014 by Starwaster
Added some screenshots

[Woodstar]

To upgrade the dev build I only need the .dll correct?

[Starwaster]

To upgrade the dev build I only need the .dll correct?

Yeah, that's usually all that changes in dev builds. I think a few times there's been part pushes incorporated but generally it's just the dll.

Edited March 4, 2014 by Starwaster

[K3-Chris]

I'm on #187, also a fun new bug, when you dock with something using the docking AP it remains on after you dock and tries to push you around using the RCS still...

Only fix I've come up with is time-warping to freeze the controls, set a new target to make the docking ap's UI show again, enable it and then disable it to stop it, docking ap is green in the MJ menu and basically goes full tilt forwards (h) after docking.

And the RV Ap turns off auto-warp MJ-wide, use it and all other stuff including MP, AG etc all have auto-warp off.

Edited March 4, 2014 by K3|Chris

[Walsht9]

Using latest dev build, docking AP totally broken. Doesn't align and rams target at full forward RCS thrust. Doesn't slow down on approach.