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

[Starwaster]

All you should have to do is change the root part back to a part that doesn't get decoupled from the ship. There are very few situations where it makes sense to have the root part decoupled and, in those cases, you usually don't need to know the deltaV of the following stages until you decouple anyway.

With very large rockets you get a wobbling that can be eliminated by making the root a part that is closer to your center of mass. Itself a bug that affects both stock SAS and MJ. (the wobbling is caused by excess overcorrection)

[Padishar]

With very large rockets you get a wobbling that can be eliminated by making the root a part that is closer to your center of mass. Itself a bug that affects both stock SAS and MJ. (the wobbling is caused by excess overcorrection)

Can you post an example of such a ship? It isn't that I don't believe you, but I've never seen a SAS induced wobble in a ship that wasn't structurally unsound in general and I don't think I've ever seen one where changing the root part makes any difference to the wobble...

[Greystripe3]

thanks for a brilliant mod!

[Starwaster]

Can you post an example of such a ship? It isn't that I don't believe you, but I've never seen a SAS induced wobble in a ship that wasn't structurally unsound in general and I don't think I've ever seen one where changing the root part makes any difference to the wobble...

Oh please, do you think I fell off the turnip truck yesterday?

Of COURSE it's because you don't believe me!

Felger knows more about it than I do and he has a cool nifty video demonstrating the problem and the effect changing the root has on it.

http://forum.kerbalspaceprogram.com/threads/99966-0-90-Realism-Overhaul-7-0-7-2015-032?p=1721842&viewfull=1#post1721842

Ooooo videos! Aaaaahhhh

[Padishar]

Oh please, do you think I fell off the turnip truck yesterday?

Of COURSE it's because you don't believe me!

Felger knows more about it than I do and he has a cool nifty video demonstrating the problem and the effect changing the root has on it.

http://forum.kerbalspaceprogram.com/threads/99966-0-90-Realism-Overhaul-7-0-7-2015-032?p=1721842&viewfull=1#post1721842

Ooooo videos! Aaaaahhhh

Thanks for the link to the video. So it does only appear to happen with rockets that flex badly (i.e. are structurally unsound, like I said). I can imagine there would be a few awkward bits but I can't believe it would be too difficult for Squad to change various things to use the "control from here" part rather than the root part (e.g. the origin of the coordinate system, the part the vessel's motion is read from etc).

[Virtualgenius]

Why would they do the landing AP with FAR support when stock is whats mostly used, is FAR support really required when the aerodynamic model is about to change and FAR may or may not exist going into the future

[Galane]

We don't know what will be done to the stock aero, but it's likely that there will be room for FAR and other mods to improve upon it. My speculation is that it will make most, if not all, previous aircraft designs obsolete.

If there's a way to make MechJeb read and adjust to any alterations any aero mod makes, without needing to have specific support for each mod, that would be very nice.

[Padishar]

We don't know what will be done to the stock aero, but it's likely that there will be room for FAR and other mods to improve upon it. My speculation is that it will make most, if not all, previous aircraft designs obsolete.

If there's a way to make MechJeb read and adjust to any alterations any aero mod makes, without needing to have specific support for each mod, that would be very nice.

A little bit of thought should make it obvious that this is an impossible request. MechJeb needs to simulate what happens when the craft is flying through the atmosphere and there is no way that it can do this ahead of time without knowing how the particular aero mod works.

[sarbian]

Thanks for the link to the video. So it does only appear to happen with rockets that flex badly (i.e. are structurally unsound, like I said). I can imagine there would be a few awkward bits but I can't believe it would be too difficult for Squad to change various things to use the "control from here" part rather than the root part (e.g. the origin of the coordinate system, the part the vessel's motion is read from etc).

"structurally unsound" : it's not a problem with rocket design. It's a problem with the game joints that does not scale well. You end up with wobbly mess when you play with large rockets in RO/RSS or the other upscale mods.

I can change the "control from here" for MJ with code I have on my local version. But it require 2 things:

- the change I made with velocity (MJ now can compute the velocity at the CoM instead of using the velocity of the command part as provided by KSP). With this the velocity vector is less affected by the wobble.

- a stable "up" direction. For rockets that flex the "up" is moving a lot and that create the over correction. So far I did not find a good way to create that "up" direction that would work on all ship designs.

[smjjames]

We don't know what will be done to the stock aero, but it's likely that there will be room for FAR and other mods to improve upon it. My speculation is that it will make most, if not all, previous aircraft designs obsolete.

If there's a way to make MechJeb read and adjust to any alterations any aero mod makes, without needing to have specific support for each mod, that would be very nice.

True, but it shouldn't be too hard to add support for landing in FAR.

Sounds like the new stock aeros are going to be pretty close to FAR though.

[Padishar]

"structurally unsound" : it's not a problem with rocket design. It's a problem with the game joints that does not scale well. You end up with wobbly mess when you play with large rockets in RO/RSS or the other upscale mods.

I understand that, I wasn't blaming the unsoundness on anything in particular and certainly not on the design of rocket. I have seen this sort of wobble before when I first started playing but I didn't realise it could be fixed by changing the root part (and wouldn't have wanted to do it that way anyway due to the deltaV simulation issues) so I would just heavily strut the rocket to prevent virtually all flexing...

[Starwaster]

"structurally unsound" : it's not a problem with rocket design. It's a problem with the game joints that does not scale well. You end up with wobbly mess when you play with large rockets in RO/RSS or the other upscale mods.

I understand that, I wasn't blaming the unsoundness on anything in particular and certainly not on the design of rocket. I have seen this sort of wobble before when I first started playing but I didn't realise it could be fixed by changing the root part (and wouldn't have wanted to do it that way anyway due to the deltaV simulation issues) so I would just heavily strut the rocket to prevent virtually all flexing...

Something that just occurred to me about changing the root is that aside from the reasons cited by Felger, there's also a long standing Unity bug that it would help. Namely a bug affecting parent / child relations where the child is more massive than the parent results in floppier connections.... I had totally forgotten about that when I watched that video.

[sarbian]

I tough this was one of the thing that Squad fixed when they included some of KJR fix ?

When do we get Unity 5... I may not fix everything but at least will will have a better physic engine...

[Starwaster]

I tough this was one of the thing that Squad fixed when they included some of KJR fix ?

Not that I'm aware of; the large child / small parent issue (really rigidbody mass) is something that I don't think Squad or KJR addressed. I think I even mentioned it once to Ferram because I thought he had fixed it but he indicated that KJR wasn't doing anything about that.... so I don't know.

If I'm wrong though I'd love to know about it, or rather I'd love to BE wrong about it.

Actually I think I have a rocket that had that same wobble problem with a monstrous first stage.... I could fly it on manual and see for myself if it's more or less wobbly with the larger stage as the root. (or just the same bit of wobbliness)

[Galane]

- a stable "up" direction. For rockets that flex the "up" is moving a lot and that create the over correction. So far I did not find a good way to create that "up" direction that would work on all ship designs.

Up on the pad is known. Once in flight, monitor the amount of deviation of the velocity vector from the initial static up direction, if it varies. Sample it every second or so and 'forecast' the wobble to calculate how much and which direction control input will be required in the next instant to counteract the wobble. If the last input made the wobble worse than the previous deviation, alter the calculation and control input. Could also have an "I give up!" bailout function that after a certain number of adjustments that don't dampen wobble or make it worse, revert to the old method.

Some fighter planes are made deliberately unstable and use computer control systems that constantly correct without over correcting, but their dedicated control system makes hundreds to thousands of corrections per second to make the plane seem to be flying on rails.

I assume they use a system that is at least in part similar to what I described. The pilots don't direct the airplane which way to go, it's more like they tell the computer which way to allow the plane to be unstable toward. That's how they get such extreme maneuverability - the plane wants to go any direction except straight ahead. Biasing the constant corrections toward letting the instability turn the plane *that* way enables it to turn *that* way much quicker than a control surface can force an inherently stable plane to turn.

[Neutrinovore]

Um, sorry to interrupt the flow, but I have a comment about something a bit different.

I'm using build #401, and I've noticed that the landing autopilot is now using the RCS thrusters a lot during the 'coasting to deceleration burn' phase of descent, which it never did before. Plus, the RCS system can't be disabled while the autopilot is active. Meaning that even if I have my RCS system off (no green light), the thrusters will start firing to bring the landing prediction as close as possible to my chosen landing coordinates or target.

I should also mention that I'm using the 'Stock Drag Fix' mod, but not NEAR or FAR, as most people seem to be doing lately.

Anyway, this issue doesn't bother me, I always play with the 'infinite fuel' and 'infinite RCS' cheats enabled, and I only play Sandbox, so I'm not concerned that it's using up too much monoprop, but I would think that such behavior WOULD be a problem for someone who was concerned about having a finite amount of fuels to work with. That's really the only reason I thought I'd mention it.

So, fwiw, there you go. Have a great day, Sarbian, and everyone else too of course! Lol. Later!

[Sirrobert]

So I have started running into a very weird bug(?) with the accent autopilot.

The autopilot consistently keeps staging the first stage (after liftoff) mere seconds info the flight. While the stage still has MORE than enough fuel left.

This happends both with Autostage on and with Autostage OFF.

Screenshots:

Before

After

Even entire half rockets

I am the latest devbuild. I am also running NEAR, and the NEAR Mechjeb plugin

Edited February 9, 2015 by Sirrobert

[smjjames]

Is it just with one rocket design or all? Also, does it automatically trigger the clamps without your input (unless timed launch is on)? Sounds like that kind of problem that I had some time ago. Haven't seen it in a while.

[Galane]

The staging looks proper for Ascent Guidance, no stages with engines without a decoupler icon. There are some ways of arranging staging that work just fine with manual staging control but which do not work with Ascent Guidance's auto staging.

Post the craft file to pastebin.com so other people can examine it for assembly issues.

[Sirrobert]

Multiple craft files, everything I build in the past few days it seems. I also think they all contain some modded parts. I will take a look and see if I can replicate the problem with a stock rocket and upload that file, though I can't imagine how the payload would influence Mechjeb's staging.

Clamps are not a factor here, they are part of the launch stage

[sarbian]

Up on the pad is known. Once in flight, monitor the amount of deviation of the velocity vector from the initial static up direction, if it varies. Sample it every second or so and 'forecast' the wobble to calculate how much and which direction control input will be required in the next instant to counteract the wobble. If the last input made the wobble worse than the previous deviation, alter the calculation and control input. Could also have an "I give up!" bailout function that after a certain number of adjustments that don't dampen wobble or make it worse, revert to the old method.

I don't want a method that only works for the first stage on the pad. I want a working method that works nearly all the time, not something that will get me an endless stream of support post for design that breaks it.

Some fighter planes are made deliberately unstable and use computer control systems that constantly correct without over correcting, but their dedicated control system makes hundreds to thousands of corrections per second to make the plane seem to be flying on rails.

I assume they use a system that is at least in part similar to what I described. The pilots don't direct the airplane which way to go, it's more like they tell the computer which way to allow the plane to be unstable toward. That's how they get such extreme maneuverability - the plane wants to go any direction except straight ahead. Biasing the constant corrections toward letting the instability turn the plane *that* way enables it to turn *that* way much quicker than a control surface can force an inherently stable plane to turn.

Those control systems have some information about the plane shape and flight model hard coded.

And you did not understand what I need. The stability control you describe is already in MJ (the PID, torque, MoI and related code). What I need is not related to the current velocity and attitude at all.

Neutrinovore : I ll add a checkbox to disable the RCS use somewhere.

Edited February 10, 2015 by sarbian

[armegeddon]

I'm getting a NRE error in the log that is either caused by MJ or RT, not sure if it is causing additional some instability with the game or not. It appears to be related to RT allowing the AR202 to be used as an antennae.

[LOG 02:23:32.793] RemoteTech: ModuleSPU: OnDestroy
[LOG 02:23:32.794] RemoteTech: ModuleRTAntenna: OnDestroy
[LOG 02:23:32.795] RemoteTech: ModuleSPUPassive: OnDestroy
[ERR 02:23:32.796] MechJeb module MechJebModuleDebugArrows threw an exception in OnDestroy: System.NullReferenceException: Object reference not set to an instance of an object
  at MuMech.MechJebModuleDebugArrows.OnDestroy () [0x00000] in <filename unknown>:0 
  at MuMech.MechJebCore.OnDestroy () [0x00000] in <filename unknown>:0 

This will sometimes repeat a couple of times. Mostly seems to occur when going from the VAB to launch. The ship it appears to be causing problems with does have two AR202 modules so I can make different stages controllable.

[sarbian]

It should not create any problem. I just need to cleanup some code I added.

[RoorsT5]

Would be useful to have a 'Hold position' function relative to another craft. Maybe as a sub-set of the docking autopilot, to place aa hold point on a docking. For instane, docking could be halted at a set distance (5-25m), so that the rotation could be fine tuned or other aspects checked before proceeding to final distance.

I often use the Canadarm mod to do the final docking of supply vehicles etc to avoid craft impacting with solar panels or other fragile parts on my space stations. However, using the Rendevous autopilot is not sufficient, as I need to drone craft to hold a stationary position for long enough to manouvre the arm. Even with the best balanced craft and carefully tuned orbit, stationary craft tend to drift.

Just a suggestion.

[Starwaster]

Would be useful to have a 'Hold position' function relative to another craft. Maybe as a sub-set of the docking autopilot, to place aa hold point on a docking. For instane, docking could be halted at a set distance (5-25m), so that the rotation could be fine tuned or other aspects checked before proceeding to final distance.

I often use the Canadarm mod to do the final docking of supply vehicles etc to avoid craft impacting with solar panels or other fragile parts on my space stations. However, using the Rendevous autopilot is not sufficient, as I need to drone craft to hold a stationary position for long enough to manouvre the arm. Even with the best balanced craft and carefully tuned orbit, stationary craft tend to drift.

Just a suggestion.

That definitely would be a cool addition.

And yeah, the thing about orbital mechanics is that it's pretty much guaranteed that you constantly have to have station keeping performed once in awhile. If two objects occupy different spatial positions then their orbits can't be the same so they will drift eventually.