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

[codepoet]

Thanks again Sarb and poet for your work. Both of you definitely don't burn yourselves out on this. Believe me it sucks. I burned myself out on ArmA 2 modding and it's no fun having something you enjoy doing turn into work that you despise looking at (over 4000 hours combined between ArmA 2 and Operation Arrowhead).

Shad0wCatcher - thanks for the reality check, it is always good to take a break. To be honest I am about at the point now of going back to actually play the game. I am just a player, who sees working on mods as part of the game play - when NASA wanted to navigate to the moon they did not download a parts pack, they wrote a flight computer! I started working on parachutes because I wanted a solution to the Laythe Kethane rescue challenge where by I did not have to worry about driving to the target after landing, did not have to carry heavy engines and fuel to power the landing but could just fly to Laythe on ions and then appear on the surface next to the craft that needed rescuing. The solution was to land accuratly with parachutes. So I feel I have achieved what I set out to do - I will probably step back now and play the game (and live real life - I have a house to renovte, a job to work, and need to get a new job by the summer).

However I have a few closing thoughts on parachutes. First is that obviously support for RealChutes is something a lot of folks would like. To get there the whole handling of the concept of parachutes needs to be abstracted out first, which may not be trivial, and then different parachute implimentations can be added. I am hesitant to start work on that at the moment as I do not use RealChutes myself.

The other thought I have had about parachutes is a different solution to the problem of landing in hilly areas where the 'chute is fully deployed the AGL changes (passing over a cliff) and puts the landing off. The problem is that we can't take the terrain under the landing path into account because the terrain system is not thread-safe and the predictions need to run is a seperate thread so as not to cause a performance problem. I wondered if a fun solution would be to work with the ISA MapSat mod (if you are using it). So instead to getting terrain data from the game's own terrain system, MechJeb is able to access the terrain data that you gathered earlier by scanning the landing area. If you did not do the scan, or the data is incomplete, then your landing would be less accurate. The same principle could be used for other aspects of using AGL data in the landing system - if you have not done the scan then how can you know the height of the target location? Obviously you would impliment it so that it would only be this way for people using the MapSat mod. I would love to hear your thoughts on this idea.

Anyhow I will be lurking around and if people get bugs related to the parachute targeting I will jump up to fix them, but otherwise I will be busy colonising Laythe by parachuting living modules directly into place on the surface

[sarbian]

Had an error earlier in 157 causing a powered landing failure. Log available. It's probably mod-related however (was using a KSPI Anti-matter powered thermal rocket fueled by water) along with realchutes, FAR, and DRE.

Caused by the following:

Set landing autopilot to land at KSP launchpad with ~8.5 Km of dV left (of 16 Km) at 700 Km orbit.

No parachutes installed.

MJ proceeds to spam log with the following:

[...

Craft continually corrects landing site; at one point it attempted to obtain some type of periapse (1.6km)

This looks like the "ship burn to escape trajectory" bug, and it's now fixed in #158.

codepoet : yep, sometime we need a long break I can continue your work with the parachute now that you have done the heavy lifting

As for integration with ISA MapSat : no. never. I get that it would be an easy way to get the real altitude but no.

[Shad0wCatcher]

That would be interesting for sure; though I've never used MapSat. I use SCANsat (essentially the same thing; just different parts for different sets of data; rough; biome specific; and fine. Also includes threading to allow for multiple scanning satellites to operate at the same time to speed up the scan without needing to be focused [though the focused vessel still needs some type of device; a basic radar that can read the data suffices]). One thing though is every vessel would include at least some type of radar altimetry as all pods and cores have the navball that includes height above sea level.

[BARCLONE]

What a difference a couple of builds (and a change in OS kernel) can make!

I'm back to skywriting again using the dev155 build, with or without fins. Now it happens a little closer to the pad, usually before it reaches 1500 m and before the V reaches 100 m/s. Although the P/R/Y needles are showing inputs, they're usually pegged to the stops. How does a rocket that's locked on rails in one build suddenly act like the rails are on a roller coaster with the next build? FWIW, I have tried the 159 build with the same results.

One system change is an update to Linux Mint 16, 64-bit. I'm not discounting the possibility this change is affecting the game, although I have a laptop that runs (albiet sluggishly, not playable).

It's a shame I can't post attachments. I'd attach a copy of the whole log file so you could pick out anything that catches your attention. I can't see anything unusual in the output this time. I do know the game crashes on load-up whenever I try to include NovaPunch in the list. If I take it out, it loads. There may be something lurking in the shadows with this install...

[sarbian]

Open the attitude adjustment windows and uncheck the Auto Tune Tf. It seems to be a bad idea in atmosphere ...

[BARCLONE]

Sarbian says I have no faith in the autopilot...

Just for kicks, on the last skywriting flight I punched out the lander as the rocket was falling, and engaged the "Land at KSC Pad" function of the autopilot, with the "Deploy LG" button checked. The gear came out nicely at about 1000 m. The descent was wobbly, like the torque was excessive, but it still landed just off to the side of the pad.

[BARCLONE]

Open the attitude adjustment windows and uncheck the Auto Tune Tf. It seems to be a bad idea in atmosphere ...

It was a little better...

It reached 5000m before flipping...

Jittery as a hairless dog all the way.

[skips]

@barclone

I only see that problem when the attitude control does not have sufficient authority. Generally adding another RGA helps or solves the problem for me. (OTOH, my ships tend to be a lot smaller than those that I believe you are flying.)

skips

[Virtualgenius]

I had an awesome experience with my buran landed back at the KSC runway for the first time perfectly on mechjeb lined up perfectly and it was a simple mater of playing with the throttle to land

[ClearlySane88]

So, I downloaded the files and extracted them into my Game Data folder, but I can't find the button to turn it on anywhere. Was I supposed to put it in the Squad folder inside the Game Data folder? Any help would be much appreciated.

[BARCLONE]

OK, I just experienced a perfect flight! Complete mission to Mun with no problems whatsoever.

What I did this time:

1. Re-installed dev159
   
2. Unchecked "Tf auto tune", per Sarbian's post
   
3. Set the Tf value to 0.3, which was slightly higher than what the auto tune value was
   
4. Raised the gravity turn altitude to 4 Km instead of my previous 0.75 (750 m) and 1 Km altitudes
   
5. Turn end altitude 70 Km
   
6. Turn shape 75%
   
7. Acc limiter to 15 (keeps the G-meter down in the green zone)
   
8. Let 'er rip
   

So, what did I do right? What is that "Tf" setting? I think it has to do with vessel torque, right? If you've posted anything about it, show me where to read it and I'll head there...

[sarbian]

So, I downloaded the files and extracted them into my Game Data folder, but I can't find the button to turn it on anywhere. Was I supposed to put it in the Squad folder inside the Game Data folder? Any help would be much appreciated.

Did you add the AR 202 case on your ship ? If yes, can you try disabling your anti virus ? it seems the be the most common case

So, what did I do right? What is that "Tf" setting? I think it has to do with vessel torque, right? If you've posted anything about it, show me where to read it and I'll head there...

I have posted about it but it would take me longer to find the post than ton explain it again.

It's a Time Factor used for the PID controler and the low pass filter that regulate the command. In previous version it was set by default to 0.3 but it's not a good setting for ship that are "agile", and too small for big ship without much torque.

In version 148 I added an autotune setting that use the |MoI| / |Torque| ratio to find a good Tf (the ratio divided by 20 and bound between 0.04 and 1). It works fine in space but it seems I need an other approach in atmosphere where sharp turn are not a good idea. I need some king of formula that transit from atmo to space smoothly, most likely using the current atmo pressure.

Edited January 5, 2014 by sarbian

[ClearlySane88]

Okay, so I managed to find the case you were referring to, but it won't let me add it to the ship. Says I need to purchase something with Science first, do you know what Science item I need to buy before I can use it?

[BARCLONE]

Second perfect flight. This is beginning to get embarrassingly easy...

Things set different from previous flight:

1. Lowered gravity turn start to 3 Km
   
2. Lowered turn end altitude to 69 Km
   
3. Raised turn shape to 80%
   

The Dv for the burn-to-apoapsis was only 43 m/s. After the circularization burn, I had only used a total Dv of 133 m/s. Absolutely wild!

Oh, the LG deploy feature works great! Plenty of altitude.

[LameLefty]

Okay, so I managed to find the case you were referring to, but it won't let me add it to the ship. Says I need to purchase something with Science first, do you know what Science item I need to buy before I can use it?

If you're in Career Mode you cannot use MJ until you unlock the right nodes in the Tech Tree with science points earned from flying missions, performing experiments, etc. Alternately you can edit the config files and get full functionality without doing that. This thread has dozens of posts asking the same question and posting the same answers, so a thread search should find what you're looking for in very short order.

[BARCLONE]

It's a Time Factor used for the PID controler and the low pass filter that regulate the command. In previous version it was set by default to 0.3 but it's not a good setting for ship that are "agile", and too small for big ship without much torque.

Interesting. I picked 0.3 at random, without knowing about the previous values. Either I'm naturally good, or you better worry about the sanity of that code...

In version 148 I added an autotune setting that use the |MoI| / |Torque| ratio to find a good Tf (the ratio divided by 20 and bound between 0.04 and 1). It works fine in space but it seems I need an other approach in atmosphere where sharp turn are not a good idea. I need some king of formula that transit from atmo to space smoothly, most likely using the current atmo pressure.

Sounds like an exponential curve sort of function. Some planets will have denser atmospheres at their surface, others thinner, but the adjustment value you need won't be anything along a linear slope...

[BARCLONE]

Sarbian,

Are you trying to create a dynamic curve that continually changes as the rocket ascends, or just trying to pick an optimum value for the start of the flight with the obvious situation that as the rocket ascends into thinner atmosphere, it gets even more stable? Almost like the sliding CG-CP ratio where as the fuel burns off, the CG shifts farther ahead of the CP. Or even like the TWR calculation, where the relative thrust gets greater as mass burns off.

Perhaps you could adapt one of those ratios into your calculation, as there seems to be some relativity between all of them.

[Starwaster]

OK, I just experienced a perfect flight! Complete mission to Mun with no problems whatsoever.

What I did this time:

1. Re-installed dev159
   
2. Unchecked "Tf auto tune", per Sarbian's post
   
3. Set the Tf value to 0.3, which was slightly higher than what the auto tune value was
   
4. Raised the gravity turn altitude to 4 Km instead of my previous 0.75 (750 m) and 1 Km altitudes
   
5. Turn end altitude 70 Km
   
6. Turn shape 75%
   
7. Acc limiter to 15 (keeps the G-meter down in the green zone)
   
8. Let 'er rip
   

So, what did I do right? What is that "Tf" setting? I think it has to do with vessel torque, right? If you've posted anything about it, show me where to read it and I'll head there...

If you're playing stock (or at least no FAR and no RSS) then bump the acceleration limit to 21.5. It's still a safe value but also provides the best fuel usage. - I arrived at that figure after multiple launches of the same vehicle using a variety of values. I also tried limit to terminal velocity and while I do like the results, the one that got me the best results for fuel consumption was an acc limit of 21.5.

[BARCLONE]

If you're playing stock (or at least no FAR and no RSS) then bump the acceleration limit to 21.5. It's still a safe value but also provides the best fuel usage. - I arrived at that figure after multiple launches of the same vehicle using a variety of values. I also tried limit to terminal velocity and while I do like the results, the one that got me the best results for fuel consumption was an acc limit of 21.5.

Not using RSS, but I am using the latest FAR. I'll give that value a few runs and see what happens. Thanks!

[Starwaster]

It will sometimes do a course correction in the atmosphere. There is nothing wrong with that - it helps it land closrer to the target. There are times when it becomes hard to control attitude (depending on the design of your craft) and as I have described above there is a point at which it will give up trying to course correct. With previous versions I have seen it get "stuck" in the course correction step, whereby it can not do the burn as it can't control attitude in the face of the drag, but is too off target to switch back to the deceleration burn step, however in the latest builds that should not happen (or at least certainly not if you have got a parachute on the craft).

Sometimes burning +/-NRM is the right thing to do to correct the course - I am not sure why you are saying that is a problem.

A lot has changed with the builds of the last few days. If you experience problems with those builds do please provide logs, craft files, save files, instructions for reproducing the problems etc etc. However it might be time for you to give it another go, and see if you can bring yourself to leave it turned on. I am not bothered if you use it or not, but don't go saying that it does not work if you are not even giving it a chance to do its thing.

It became a problem with the landing prediction marker moved away from the landing target.

Same with the NRM burn, that became a problem when it took me into a polar orbit.

[mentat001]

Having an issue using rendezvous autopilot. Once it's disengaged I cannot right-click on docking ports to "control from here". Smart A.S.S. also ceases to function and will not respond to any clicks. I can correct it by returning to the space center and then going back to the ship.

[Starwaster]

Codepoet. Sarbian. Knock yourselves out.

No video, but several screenshots in sequence.

both ksp.log and output_log.txt

save file too (craft is 'landing tests') though you really shouldn't need it. It's not like this bug is particularly hard to encounter. If you try engaging the landing autopilot often enough it will happen sooner or later.

I'm done for the night.

https://www.dropbox.com/sh/9pxl3a3fz3tetcc/rxV0aqOzPz

[Bobe]

Might it be possible in a future build to create a launch sequence with scripted events at varying time intervals and conditions?

For example, you might set a specific time or T- interval and specify to ignite the engines three or four seconds prior to launch, set throttle to 100% a second or so before launch and then decouple the supports at T0. You could then program it to perform a roll and/or tilt five or so seconds after launch to set the correct heading and attitude.

Of course these aren't really required as the current launch guidance works fine, but it just looks too rigid. No rocket (that I know of) would go directly upward until ~7km (or Earth's equivalent) and then sharply pitch down. At the moment of launch, or rather after the roll maneuver, the vehicle is already set on a tilted attitude which continuously declines at a steadily increasing rate. Almost an asymptotic path.

So really this is just something I'd like to enhance the realism somewhat.

[codepoet]

Codepoet. Sarbian. Knock yourselves out.

No video, but several screenshots in sequence.

both ksp.log and output_log.txt

save file too (craft is 'landing tests') though you really shouldn't need it. It's not like this bug is particularly hard to encounter. If you try engaging the landing autopilot often enough it will happen sooner or later.

I'm done for the night.

https://www.dropbox.com/sh/9pxl3a3fz3tetcc/rxV0aqOzPz

Thanks Starwaster, that is just the sort of info we need to look into this. I will see if I can't fix it when I get a few free moments tonight (I am in GMT), unless someone else fixes it first.

[JuggernautOfWar]

I've got a quick question. I have a target selected in ascent guidance and when I click either "launch to rendezvous" or "launch into plane of target" I get a countdown and time warp, but then nothing. It will count down to zero seconds, then just sit there doing nothing. Both buttons have this affect. What am I doing wrong here? Thank you.