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

[Usgiyi]

I can't seem to find anything up to date concerning FAR & MechJeb compatibility. I know sarbian was working towards compatibility, but ran into some issues with FAR ("FAR does not allow to query it for drag coef when given speed/attitude/altitude."). Are there still plans to work towards compatibility?

[sarbian]

The FAR / MJ compat is a really complex problem.

There is the small compat module I made, that gives MJ info about the FAR control surface and help it handle turn better. This one is broken, but I only seems to think about fixing it while at work... I'll try to remember about it before .24. The problem with that module is that I am not perfectly sure that is does not change FAR simulation in any way .

Then there is the whole landing AP. There it's getting really complex. First let me make something clear : the fact that it's hard to do has nothing to do with ferram4. Don't go ask him for MJ related change since he can't do anything more about it, and he already made change to make it easier.

MJ landing AP needs to simulate the whole descent. To do that it need to know the drag force at a specific speed and position in space. With the KSP model it's easy, drag is the same with your ship sideway, upside down or however it turn itself while "falling".

FAR is made to answer that question for the current orientation, speed and density. So I can't just ask it to give me the drag force for a given future situation.

So right now I'm stuck here. I had a few ideas on how to handle that but most of them ended up being far too slow or just plain bad.

If anyone has a working idea (a bit more tested than "just do that" please) I am listening. But for now I think my time is better spent on fixing bugs and adding features in other MJ modules.

[Agathorn]

I've found the MJ landing predictions with FAR to still be pretty darn accurate. Maybe it depends on your re-entry profile? Though letting the auotpilot take over does seem to give it a seizure.

[sarbian]

When landing on a planet with an dense atmo ?

[brusura]

What I really miss from mj with far is the aerobrake prediction ( the one with the virtual node to simulate it ) rather than the landing ap, maybe make assumptions? For example I can land this thing or predict the aerobrake if you do not change heading, roll etc...

[BudgetHedgehog]

What I really miss from mj with far is the aerobrake prediction ( the one with the virtual node to simulate it ) rather than the landing ap, maybe make assumptions? For example I can land this thing or predict the aerobrake if you do not change heading, roll etc...

Even if you don't change your direction or orientation, once youre in atmo, FAR will, which renders any prediction useless.

[dlrk]

For FAR, what about a rough look up table for predictions?

Are there any plans for RemoteTech integration?

[Starwaster]

The FAR / MJ compat is a really complex problem.

There is the small compat module I made, that gives MJ info about the FAR control surface and help it handle turn better. This one is broken, but I only seems to think about fixing it while at work... I'll try to remember about it before .24. The problem with that module is that I am not perfectly sure that is does not change FAR simulation in any way .

Then there is the whole landing AP. There it's getting really complex. First let me make something clear : the fact that it's hard to do has nothing to do with ferram4. Don't go ask him for MJ related change since he can't do anything more about it, and he already made change to make it easier.

MJ landing AP needs to simulate the whole descent. To do that it need to know the drag force at a specific speed and position in space. With the KSP model it's easy, drag is the same with your ship sideway, upside down or however it turn itself while "falling".

FAR is made to answer that question for the current orientation, speed and density. So I can't just ask it to give me the drag force for a given future situation.

So right now I'm stuck here. I had a few ideas on how to handle that but most of them ended up being far too slow or just plain bad.

If anyone has a working idea (a bit more tested than "just do that" please) I am listening. But for now I think my time is better spent on fixing bugs and adding features in other MJ modules.

I suggest that in the real world, the kind of accuracy that MJ has for stock drag is impossible or very difficult. For exactly the reason you just cited. Even returning space capsules have to accept a certain amount of inaccurate predictions. The only ones that don't have to accept inaccuracy are those that can control their descent, like space planes/shuttles, or reentry vehicles like the one Curiosity had that could control its descent by pitching/yawing of its aeroshell with RCS thrusters. (that only allowed it to narrow its landing area down instead of giving pinpoint accuracy)

So,

suggestion #1: With FAR installed, abandon all notion of accuracy.

suggestion #1-B: Accept that it's ok for MJ to become inaccurate when FAR is installed.

Discarding those notions will let you move forward.

suggestion #2: This is the hard part because I don't know if FAR actually has provisions for you to query it as to drag for different orientations but you would query it twice for two orientations. One oriented along its -y axis and one for +z. (if possible to differentiate between space planes and capsules, you'd want +y but I dont know how you'd determine that)

Either you average your drag result to return your predicted landing site or report your landing site as a range using the difference between the two drag results from above.

[Galane]

What I really miss from mj with far is the aerobrake prediction ( the one with the virtual node to simulate it ) rather than the landing ap, maybe make assumptions? For example I can land this thing or predict the aerobrake if you do not change heading, roll etc...

Calculate the landing path with the assumption that the rocket will be in retrograde position all the way down, like a real life tailsitter rocket that can land vertically would be. If for some reason it goes sideways, forget it, the rocket is going to come apart or at best miss the landing target.

A feature I'd like to see is being able to choose the local time of day to land at the chosen target, even if the choices are only sunrise, mid-day or sunset. Then auto warp time to deorbit burn to land at the chosen time.

[Usgiyi]

The FAR / MJ compat is a really complex problem.

There is the small compat module I made, that gives MJ info about the FAR control surface and help it handle turn better. This one is broken, but I only seems to think about fixing it while at work... I'll try to remember about it before .24. The problem with that module is that I am not perfectly sure that is does not change FAR simulation in any way .

Then there is the whole landing AP. There it's getting really complex. First let me make something clear : the fact that it's hard to do has nothing to do with ferram4. Don't go ask him for MJ related change since he can't do anything more about it, and he already made change to make it easier.

MJ landing AP needs to simulate the whole descent. To do that it need to know the drag force at a specific speed and position in space. With the KSP model it's easy, drag is the same with your ship sideway, upside down or however it turn itself while "falling".

FAR is made to answer that question for the current orientation, speed and density. So I can't just ask it to give me the drag force for a given future situation.

So right now I'm stuck here. I had a few ideas on how to handle that but most of them ended up being far too slow or just plain bad.

If anyone has a working idea (a bit more tested than "just do that" please) I am listening. But for now I think my time is better spent on fixing bugs and adding features in other MJ modules.

Thank you, that answered all my questions.

Wish I had the answer to the problem, alas, I do not.

[CatastrophicFailure]

My two cents, if we can't yet have 100% compatibility, how about just a "ballpark" figure on the landing simulation/AP? Like the landing ellipse estimates for real atmospheric entries? Myself, I could live with just a rough guess about where a pod would return, since they usually go in the drink anyway. Seems if y'all could do this, the issues with FAR & the launch AP are at least manageable with good design and planning (and escape towers).

[Starwaster]

Apparently I derped out and only just now saw that he can't get anything but the current orientation. So that sucks.

[MoeMelek]

Tested a joystick with KSP for the fist time yesterday, and found that if I assign axis control of roll/pitch/yaw/throttle to a joystick, MechJeb will not auto contol your ship any more. As far as I could see in the debug window, there were no errors. Removing these bindings (without restarting KSP) resumed MechJeb auto control. I think MechJeb should work with a joystick installed.

[AndreyATGB]

My two cents, if we can't yet have 100% compatibility, how about just a "ballpark" figure on the landing simulation/AP? Like the landing ellipse estimates for real atmospheric entries? Myself, I could live with just a rough guess about where a pod would return, since they usually go in the drink anyway. Seems if y'all could do this, the issues with FAR & the launch AP are at least manageable with good design and planning (and escape towers).

I don't think the issue here is pods, since those are relatively simple to calculate I imagine. The big issue is large ships going in for aerobraking or landings. I suppose it's possible to just put a disclaimer that it doesn't work on anything but pods but then that defeats the purpose slightly. I recommend Sarbian just focuses on features that are easier and potentially affect everyone not just FAR users. This is a game where you can quicksave and quickload and any time, the only thing limiting your ability to land or aerobrake properly is time.

[CatastrophicFailure]

I don't think the issue here is pods, since those are relatively simple to calculate I imagine. The big issue is large ships going in for aerobraking or landings. I suppose it's possible to just put a disclaimer that it doesn't work on anything but pods but then that defeats the purpose slightly. I recommend Sarbian just focuses on features that are easier and potentially affect everyone not just FAR users. This is a game where you can quicksave and quickload and any time, the only thing limiting your ability to land or aerobrake properly is time.

That being the problem, not everyone HAS that kind of time for trial & erroring. Something that could just give an estimate of a projected orbit or landing would be better than nothing, and in doing so would add an element of challenge rather than tedium. NASA doesn't even know EXACTLY in what orbit an aero braking probe would end up.

[sarbian]

NASA has wind tunnel and computer sim to make their approximation.

[Galane]

There's an idea. A KSP "wind tunnel" to test planes and rockets with FAR - or some way to provide MechJeb with a model of how a specific assembly of parts flies at an expected range of orientations.

Build a rocket then pre-calculate how the launch assembly will behave during launch then how the parts that will be coming back to Kerbin, or landing on another planet or moon will act in that atmosphere. Then it wouldn't need realtime data from FAR, it could fly the craft based on the pre-modeled/recorded data. If the craft's orientation gets outside the bounds of what was precalculated, then stuff it, it's crashing or coming apart.

[CatastrophicFailure]

OMG THATS BLOODY BRILLIANT!!!

probably utterly impractical to actually implement, but brilliant none the less.

[stildawn]

Hi All

Firstly thanks for the mod, its awesome and allows me to do the mundane stuff while watching tv lol.

I'm just wondering if its possible or what ever, of a few extra features:

- Mechjeb to continue working on a craft even when you switch to another craft?

This would help me greatly, as recently been lifting up fuel to attach to my orbital depot, to do this (since I have done it a hundred times lol) I use the following mechjeb functions, 1. Accent to orbit 2. Revendous to Station 3. Docking Autopilot. Unfortunately currently I can only do this sequence one craft at a time, ideally I would like to have lots of craft doing mechjeb functions at the same time, so while one is going to orbit, another could be intercepting the target, while another is starting to dock with a target.

- Mechjeb Space Program Director (haha)

The ability using Mechjeb, to schedule launches, craft operations etc. So in another interface I could schedule 4 rockets to launch and orbit, then dock. And the game would do these all for me (while I was busy designing a new rocket, or landing on Eve or something)

These ideas might be a tall order, but would be great for me and I'm sure others to get away from the stuff we have to do over and over again.

Edited July 3, 2014 by stildawn

[AndreyATGB]

Galene, FAR already does that in the VAB. It's pretty technical so I'm sure it provides everything you need to know already. I'm not really sure how it would help MechJeb if it had access to that info though since predicting how a ship acts on reentry is much more difficult than that.

[DerekL1963]

There's an idea. A KSP "wind tunnel" to test planes and rockets with FAR - or some way to provide MechJeb with a model of how a specific assembly of parts flies at an expected range of orientations.

Build a rocket then pre-calculate how the launch assembly will behave during launch then how the parts that will be coming back to Kerbin, or landing on another planet or moon will act in that atmosphere. Then it wouldn't need realtime data from FAR, it could fly the craft based on the pre-modeled/recorded data. If the craft's orientation gets outside the bounds of what was precalculated, then stuff it, it's crashing or coming apart.

The problem is, drag varies not only with orientation - but with speed and altitude as well. In the real world the effects of drag also vary with the ballistic coefficient (essentially a combination of the surface area as seen by the airflow and the vehicles weight), I don't know whether FAR calculates that or not.

Either way, it's a Very Hard Problem. Even without dealing with the odd rounding error, the bits simulated and not simulated in game (even with plug ins), the bits that are either simply assumed or simply ignored...

[NeatCrown]

I'm having trouble installing MJ. Neither the main nor side-mounted modules function (the MechJeb Tab won't show up, but they still work as manually controllable modules)

May I receive some assistance? I'm using KSP Ver. 0.23.5 and MechJeb2 Ver. 2.2.1.262

[sebi.zzr]

I'm having trouble installing MJ. Neither the main nor side-mounted modules function (the MechJeb Tab won't show up, but they still work as manually controllable modules)

May I receive some assistance? I'm using KSP Ver. 0.23.5 and MechJeb2 Ver. 2.2.1.262

1st:read OP!

2nd:what is your mod list?

3rd and beyond:If you started fresh install with KSP and MJ only,all should work just fine.This is common question addressed on this thread many times. My experience is,when MJ didn't work was because mod conflict!The main culprit was RPM(my experiance,RPM shoud work now(not shure i don't use it))! You can always try MJ with toolbar plugin.

[Velsuvis]

Greetings, one and all

After reading as far back as I could to see if anyone else has encountered the same issue as I have... and after failing to find anyone, I feel it is time I finally post.

Since v 2.2.1.250+, I believe is when the issue started to occur.

Issue: a certain early stage separates almost immediately when I have 'Auto Stage' selected. Versions prior to this did not have this issue.

I strongly believe that it involves the use of the Structural Pylon as a use for stage separation. Again, I have used MechJeb on the same launch vehicles (and giving some modifications to the design, the use of the Structural Pylons have not changed). And yet another again... MechJeb did properly stage a few dev versions prior to this issue... believe before or around 2.2.1.250+ era.

I am willing to send the .craft files to any who would care to look, and help me resolve this issue. Also, this as been tested on several different installs of KSP, and the updates to MechJeb.

Most Sincere Thanks

Current Version Used:

MechJeb2-2.2.1.263-263

[BARCLONE]

Sarbian,

I'm playing with the latest (263) build...

If I'm within a certain distance to the target port, the DAP is insisting on moving to the rear of a target before trying to align ports and move in for the approach. My crew ship nearly came in contact with the carrier stage (the docking target is under the fairing shroud) trying to reach the "starting point". The DAP needs some way to see if the projected "starting point" is in front of the target or behind it, and make a correction to always be in front, before making any move.

Also, is there a way to "tweak" the approach angle to the target? Seems to me DAP is always trying to come in at an excessively steep vector. I don't see "real" spacecraft (like Soyuz or Progress) approaching the ISS this way -- they're always straight-in to the target.

The LGAP is acting ugly when trying to pinpoint the VAB or the PAD for a landing on Kerbin. It begins the high-orbit burn OK, but the "projected landing target" positions itself on the map view far to the west of the desired location and freezes. When the initial burn finishes, the LGAP rotates the ship fully 180 (pro-grade) and burns the orbit back up instead of fine-tuning. The projected target never moves in all of this, which probably explains the burn to pro-grade -- LGAP sees the projected target is too far west, and is trying to move it east. It doesn't move, so LGAP keeps trying to compensate until all of the fuel is burned.

ADDENDUM: If I take the LGAP off and "fix" the entry path manually, the "projected target" moves to follow the terminus. Apparently the "projected target" position gets updated if I do it manually, but not when it's on auto.

Linux Mint 17, 64-bit...

Edited July 4, 2014 by BARCLONE