sarbian

[1.3.0] Anatid Robotics / MuMech - MechJeb - Autopilot - [2.6.1] [27 May 2017]

713 posts in this topic

#715 got a huge changelog, looking forward to test it, session begins in a few minutes.

Share this post


Link to post
Share on other sites

just wanted to stop by and say THANKS for all of the great work and stuff for the dev builds.

Cheers and best wishes and fishes....

Share this post


Link to post
Share on other sites

What's the story behind #715?

What is the difference between Classic Ascent Profile and Stock-style Gravity Turn?

Share this post


Link to post
Share on other sites
18 hours ago, Foxster said:

What's the story behind #715?

What is the difference between Classic Ascent Profile and Stock-style Gravity Turn?

Classic Ascent Profile should be more or less what you're used to.  Hopefully more bugs were fixed than were introduced.  I think corrective steering may be busted, the code was kind of a mess and I couldn't understand what it was trying to do.  I think I get the idea behind it now, and will take another run at fixing it in a bit.

"Stock-style GravityTurn™" is similar to the gravity turn mod.   Its a 3-burn to orbit style of launch that can get to orbit with about 2800 dV on stock Kerbin.  If you want to have fun make a rocket that is basically a nose cone, a jumbo-64 a mainsail and some fairly big fins.  Have the pitch program flip it over aggressively (uncheck the AoA limiter, set the values to like 0.5 / 50 / 40 / 45 / 1) and let it rip.  Note that its not precisely the GT mod algorithm, and I didn't intend it to be -- I just didn't know what else to call it.  It does not do any pitch-up during the intermediate burn right now (that's another TODO) so it won't handle low TWR upper stages.

PEG is actual gravity turn algorithms from the Surveyor missions that properly integrates the trajectory.  It will likely not be that useful on Kerbin since it does not know how to do two-burn to orbit (does not understand coast phases) so most Kerbin launch vehicles won't ever get locked guidance with it.  So if you give a 100x100 orbit, then you need a rocket that will burn continuously, without throttling, until insertion where it will shut down right when it hits the 100x100 orbit.  Example of it flying a 3-stage rocket to orbit:  https://vimeo.com/224742550

There's also been a lot of cleanup of the algorithms internally.  The old ascent profile code in some places stopped following the ground track to hit the right inclination, turned off the AoA limiter, would occasionally start flying prograde instead of aligned with surface velocity so would flip out, all kinds of odd bugs.  The AoA limiter and the yaw control to hit the inclination are now applied consistently, and the different ascent profiles modify only the pitch (which consistently has the yaw steering applied and then consistently has the AoA limiter applied to that).  The result should be that if you have AoA limiting on you shouldn't get rockets that flip out, and should have more accurate launch inclination targeting (although hitting 0.0000 exactly remains troublesome because the yaw steering still only knows how to fly in exactly "straight" great circle lines so you can't hit latitudes lower than your launch site and KSC is not exactly on 0.0000).

 

Edited by Jim DiGriz
1 person likes this

Share this post


Link to post
Share on other sites

Also note it turns out "PEG" isn't really "PEG".  What is currently in MechJeb is the guidance equations for the Surveyor missions.  The next generation of that is the Apollo-era IGM ("Iterative Guidance Mode").  Then the next generation after that is the Space Shuttle Unified Powered Flight Guidance (UPFG) which uses an the PEG (Powered Explicit Guidance) algorithm (i think?).  I got confused by some wiki pages which implemented the Surveyor mission model and called it PEG and the reference for the Surveyor model is the "Explicit Guidance Functions for Multistage Boost Trajectories".

Anyway at this point I'm more worried about expanding MJ to being able to handle three-dimensional targeting and yaw steering and then moving on to IGM at least which seems like a similar enough algorithm.  Then I'll rename it IGM and that'll clear up the naming issue...

 

Share this post


Link to post
Share on other sites

Is there an ideal configuration for RCS thrusters for docking on a craft, using MJ version #712 & beyond? What I am used to building (thrusters oriented N,S,E,& W, placed at the front, middle & tail of craft) no longer works past #710. Prior to #712, that configuration worked a treat. Now, it races laterally and, once lined up, ends up swinging back and forth as it approaches the target port. I know there was some code changed at #712, & I basically understand why.

All things considered, I think my design is gibbled. Any suggestions? Thanks

Share this post


Link to post
Share on other sites

I guess the new code make some over problems with the RCS controls more obvious. I ll see if I can have a look and/or add a switch that make the new code optional.

Your vessel is heavy or light ? 

Share this post


Link to post
Share on other sites

Excuse my ignorance on this...

What is the process for vetting updates to MJ? Is there one or more persons collating updates and approving them before dev versions are released?

 

Share this post


Link to post
Share on other sites

There is no complex process. If I know you and you usually provide decent code then your merge is accepted. If I don't know you I ll try to read up and test the code, if I have the time.

The dev branch should not be expected to be stable. Sure that's where you will find the last new goodies but it does not get the same testing as the official release. For official I try to make sure most stuff works (but with the size of MJ and the possibilities of KSP building testing has its limits).

1 person likes this

Share this post


Link to post
Share on other sites
8 hours ago, Foxster said:

Excuse my ignorance on this...

What is the process for vetting updates to MJ? Is there one or more persons collating updates and approving them before dev versions are released?

 

Sarbian runs the project and has to whack merge on PRs.  If you want to contribute just open a PR.  Sarbian doesn't stand on a lot of formality and does a pretty good job at keeping the bar low to encourage contribution (although occasionally points out where you've tried to change code you didn't understand fully and what you want won't work, but that's just inherent to trying to hack on a large codebase like MJ).

Share this post


Link to post
Share on other sites

I've been noticing some issues with ascent inclination, specifically that mechjeb seems to treat negative values there as if they were positive (also true for inputting the values as ”360-value"), meaning that if using it to launch on a non equatorial orbit it only has a single launch window to match it, not two, the other leading to the opposite orbit. I'll be leaving town soon for a few days so I can't fully investigate it but I'd rather post it now in case I forget it later when I come back.

1 person likes this

Share this post


Link to post
Share on other sites
On 7/19/2017 at 2:19 AM, Argyle MHF said:

Is there an ideal configuration for RCS thrusters for docking on a craft, using MJ version #712 & beyond? What I am used to building (thrusters oriented N,S,E,& W, placed at the front, middle & tail of craft) no longer works past #710. Prior to #712, that configuration worked a treat. Now, it races laterally and, once lined up, ends up swinging back and forth as it approaches the target port. I know there was some code changed at #712, & I basically understand why.

All things considered, I think my design is gibbled. Any suggestions? Thanks

  • Your craft should be able to translate (left/right/up/down) without any torquing at all. If translating results in torque then it's going to have to fire other thrusters to try to compensate. That compensation is probably going to interfere with its efforts to translate. RCS Balancer may help but it's better to have a well balanced craft to start with.
  • Also: Docking AP speed limit: Best to leave it at default unless your balance is perfect. Lowering the speed limit may help with balance issues but the AP starts having problems if it is too low. (0.25 is a good lower limit; 0.125 is probably too low) Sarbian mentioned that the position and velocity could be a frame behind. That tends not to be a problem until the speed limit gets as low as ~0.1 - 0.125 m/s. (and the closer it is to the target, the slower it wants to go).

 

(The swinging back and forth does sound like a balance issue. Test that by turning on RCS and pressing I/K/J/L - it should move laterally without turning at all. If it does then that's a balance issue. If it's only a little off balance then maybe MJ balancer can help like I said before)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now