Request Mechjeb like addon?

[PhantomCruiser]

The DG-IV has a suite of autopilots that do quite a bit. I didn't know that one of them would dock for me until maybe 4-5 years of flying it.

I'm with Face on this, I don't know what MechJeb does to start with.

With Artlav's UAP, LaunchMFD, IMFD, TransX, LOLA, AutoFCS and/or Glideslope, PursuitMFD, and the DGIV built-ins. I don't know what else I'd ever need.

Does MechJeb do all of that stuff mentioned, in a single interface? If so; groovy. If not; I already gots what I need.

My $0.02, if a single point-click MFD exists to do something that's really complex and make it ultra simple, it'd really take away some of the fun of mission planning. And that pucker factor of a landing, when the low fuel warning annunciates while you divert fuel from the RCS to the mains to spot land on the airless body of choice. Talk about rewarding!

How is it that a computer simulation can cause so much adrenaline? Orbiter=awesome! (even when I goof it up)

Even with that in mind, useful tools with an intuitive interface are always welcome.

 

[C3PO]

.....but the topic here is Mechjeb for Orbiter. Yet it is still vague to me what is meant with that.

From the information I have now, Mechjeb is nothing more than a bunch of autopilots for special KSP-related operations. Is this correct?

Correct. The main feature of MechJeb is that it is a complete set of auto-pilots in a single addon. It has a button for everything, but not ONE button for everything.

 

[Face]

Correct. The main feature of MechJeb is that it is a complete set of auto-pilots in a single addon. It has a button for everything, but not ONE button for everything.

Thanks. I suppose you speak from experience with the game and plugin mentioned, so please let me ask some other questions to carve that out a bit more:

1. What is "complete set of auto-pilots"? I guess ascent, docking, plane-change, transfer, re-entry, landing, attitude are certainly among them.
2. I've seen things like "plane landing" and "rover heading" and such, so I get doubts about the "every spacecraft" aspect of the OP's request. What is the quality of the above mentioned auto-pilots in terms of precision regarding variety of spacecrafts? In Orbiter (just as in reality), a control loop necessary for auto-pilots can't be made general beyond a certain precision threshold. I guess everybody with experience in control loop implementation (especially PID) will agree that tuning the loop for a certain setup is the hardest part of building auto-pilots.

 

[Izack]

The functionality of MechJeb in relation to Orbiter can be summarised pretty easily. It:

• Can display orbit information similar to OrbitMFD, as well as some simple atmospheric parameters.
• Can hold an arbitrary vessel at any of a set of given attitudes, very similar to Orbiter's built-in attitude autopilots. Its usefulness is similarly limited to lithe and quick-to-turn vessels (though its controller is somewhat less prone to overshooting than Orbiter's).
• Can provide an interface to manipulate KSP's built-in manoeuvre node system for astrogation, and automatically perform manoeuvres according to them (regardless of whether the node was made by Mechjeb itself or the player manually). This does not have such an easy analogy in Orbiter as it is one place where the two programs diverge significantly, however, functionality-wise it is quite similar to IMFD or TransX, which can both plan and execute manoeuvres. Further, its "planner" dialog allows a wide range of manoeuvres to be specified quite easily by the player, such as "Hohmann transfer to target" or "Return from a moon". This is probably what users here are complaining about the most. It is still far from a 'one-click to anywhere' autopilot, though. It is quite often very generalistic with its auto-manoeuvres, needing the player to fine-tune (and often drastically change) the given node, so it will probably take at least a dozen clicks.
• Can provide rough-cut controls for hovering craft, such as Hold Speed or Kill Horizontal Velocity.
• Can time-warp to a given point in the future, like the next periapsis or planet encounter. This functionality is available in a couple of Orbiter addons.
• Can automatically get a classic vertical-launch rocket into orbit with little player input. This is somewhat less of an issue in KSP, as actually flying the rocket is less than half of the challenge of getting to orbit. The player must construct an orbit-capable rocket him/herself. In Orbiter, this is comparable to Multistage to Velcro autopilot, but much more reliable and needing less tuning.
• Can automatically dock two spacecraft together. UAP or the DG-IV are capable of this in Orbiter.
• Can attempt to automatically rendezvous with a spacecraft. However, it is usually very inefficient and often runs the spacecraft out of propellant.
• Can automatically land a spacecraft. This is possibly one of its biggest 'crutch features'. Landing is rather difficult without guidance. This is somewhat mitigated in Orbiter, as it by default provides many, many times more information about the situation than KSP does.
• Can hold an aircraft or spaceplane on a certain heading at a certain altitude. More useful in KSP than Orbiter, as KSP's flight model is bizarre and unstable, and does not allow time acceleration on long flights.

There are several other tools that are mostly useful only in KSP and not relevant to Orbiter, such as an RCS balancer for vessels with oddly-placed thrusters. Forgive me if I've neglected anything important.

 

[C3PO]

Thanks. I suppose you speak from experience with the game and plugin mentioned,,,,,

I'm not up to speed on the latest version because I've been trying out other similar addons.

I'm not sure a MechJeb for Orbiter would be that useful to be honest. The 1/10 scale of the KSP system makes the margins huge compared to Orbiter. Even a DG Mk4 has slimmer margins than the simplest orbital KSP craft. Many of MechJeb's "plans" aren't efficient enough for Orbiter without a lot of handwavium. That can be mitigated with careful planning, but that isn't any help for a new user. If a casual KSP user hasn't bothered to learn basic orbital maneuvering, he's not going to enjoy Orbiter that much anyway. KSP has prettier landscapes and explosions.

IMHO a better way to ease the transition from KSP to Orbiter would be a map view with maneuver nodes. TransX' maneuver plan already provides similar functions, but it may be a bit daunting for a beginner.

 

[Urwumpe]

IMHO a better way to ease the transition from KSP to Orbiter would be a map view with maneuver nodes. TransX' maneuver plan already provides similar functions, but it may be a bit daunting for a beginner.

Well, what about a kind of a flight planning tool?

Some dialog similar to the scenario editor, which you can access anytime from Orbiter and use for planning your mission?

Maybe with some sort of interface to communicate with MFDs for simply loading planned maneuver nodes from this flight plan and handle the maneuver itself in flight, by doing the GNC tasks for this node?

It would take the biggest constraint away, the limited size of the MFD screen in Orbiter. Instead, there could be a larger window, and how much data you really see in that display can be configured, like you would expect from a better "Map" display.

I would just not include the node manipulation of KSP, because it is not accurate enough. Instead better have a way to define relative coordinates for maneuver nodes, like "Maneuver Target: 50 km below orbit of ISS" or "Maneuver Target: Jupiter flyby at 250,000 km distance"

This way, it would also be simpler to provide manual flying aids - like a MFD, that just shows you the data for the next burn.

And extending such a flight planner to provide more accurate data and have more intelligence to handle abstract requests would be simpler than finding the autopilot for to fly them all into darkness.

 

[AlfalfaQc]

Can automatically get a classic vertical-launch rocket into orbit with little player input. This is somewhat less of an issue in KSP, as actually flying the rocket is less than half of the challenge of getting to orbit. The player must construct an orbit-capable rocket him/herself. In Orbiter, this is comparable to Multistage to Velcro autopilot, but much more reliable and needing less tuning.

This is IMO the key point with MechJeb. Some people (like me) play KSP more for the building part of the game (and the explosions :lol. I fly all my missions manually, but some people are not really interested in flying their ship everywhere, therefore I can see why MechJeb is usefull to them. Orbiter is more about the Flight part of things, thus I don't really see the point of having something doing everything for you. If I just want to fly something to another planet, I'll play Orbiter, because I find the experience much more fun when it comes to flying things (more precise, more info, etc.)

That being said a good flight planning tool can be something really useful.

 

[C3PO]

CFD does give the developer more freedom to display than MFD. Good idea. :thumbup:

The map/node idea was meant to display to the user how the burn changes your orbit. This would give a KSP user a familiar view of what the planner is doing.

The problem is that Orbiter's realistic scale makes it difficult to see the subtle changes needed for an efficient burn. This is why Harvester went for a 1/10 scale system. I used to plan ISS interception burns using TransX maneuver mode, but you need to know the basics to make the rendezvous.

One option is to make a standard for impulses (a node). The planner(s) would set up the burn based on user inputs. Then a HUD or MFD could display the attitude/DV/timer. This is similar to the way MechJeb works (most of the time). It just seems a lot of work just to duplicate what is already available from existing MFDs.

 

[Urwumpe]

It just seems a lot of work just to duplicate what is already available from existing MFDs.

Yes, thats one key disadvantage there. But then, many MFDs also kept on growing in functionality and complexity, to the point of being hard to use.

So, giving new MFDs a start with simpler displays is sure not the worst event in evolution. But I recommend to first code a framework for such "next gen" MFDs... too keep the look uniform and the data formatting similar.

Everything dies, Baby thats a fact. Maybe everything that dies, someday comes back...

 

[RisingFury]

I'd like to throw my opinion and experience into this mix:

Autopilots aren't easy. I know. I've been working on them for nearly 5 years for OBSP. Most of the autopilots currently are atmospheric:
- Takoff from a runway
- Takeoff from a landing pad
- Landing on a runway
- Landing on a landing pad
- Taxiing
- Efficient navigation from one point on the planet to another
- Formation flying
- AA and AG combat
- many more

These are the modules. Each is intelligent enough to solve a small problem. But I've gone beyond that. I've joined them into an AI to where it makes it easy to control any human flyable vessel.

Currently you give a unit or a collection of units a command through LUA and the AI does all of the work. It figures out if it needs to take off, asks the ATC permission for taxi and take off, it takes off, flies to the destination and does what it needs to there. Lands and taxis to hangar if the destination is an airport.

It's as easy as

obspMove("GL-01", "Wideawake International")

I only have a little bit of work to do on the ATC and the atmospheric autopilots, but within a few months, I'm going orbital.

I'll be adding autopilots for ascent to orbit, changes in orbit (inclination, altitude), orbit sync, approach and docking, reentry and possibly even suborbital hops and integrate that into the existing AI. Following that, I'll add the ability for interplanetary travel. All one will need to move have a vessel land at Olympus mons base is

obspMove("GL-01", "Olympus")

The AI will automatically figure out what it needs to do to get there, if it can get there at all given current fuel level. Hell, I might even have it refuel itself before going there by taxiing over to a fueling station or something.


From what I've already created, it's a very very small step to a system where civilian vessels fly from one destination to another on their own. We're on the verge of have a live solar system in Orbiter.



The work has been slow going, though. OBSP autopilots are a hobby project of mine and I'd love to work on them 12 hours per day. AI is a highly technical field and I sometimes spend hours just tweaking a few lines of code. It'll still take some time before the alpha is out for your enjoyment.

 

[Donamy]

I'd like to throw my opinion and experience into this mix:

Autopilots aren't easy. I know. I've been working on them for nearly 5 years for OBSP. Most of the autopilots currently are atmospheric:
- Takoff from a runway
- Takeoff from a landing pad
- Landing on a runway
- Landing on a landing pad
- Taxiing
- Efficient navigation from one point on the planet to another
- Formation flying
- AA and AG combat
- many more

These are the modules. Each is intelligent enough to solve a small problem. But I've gone beyond that. I've joined them into an AI to where it makes it easy to control any human flyable vessel.

Currently you give a unit or a collection of units a command through LUA and the AI does all of the work. It figures out if it needs to take off, asks the ATC permission for taxi and take off, it takes off, flies to the destination and does what it needs to there. Lands and taxis to hangar if the destination is an airport.

It's as easy as

obspMove("GL-01", "Wideawake International")

I only have a little bit of work to do on the ATC and the atmospheric autopilots, but within a few months, I'm going orbital.

I'll be adding autopilots for ascent to orbit, changes in orbit (inclination, altitude), orbit sync, approach and docking, reentry and possibly even suborbital hops and integrate that into the existing AI. Following that, I'll add the ability for interplanetary travel. All one will need to move have a vessel land at Olympus mons base is

obspMove("GL-01", "Olympus")

The AI will automatically figure out what it needs to do to get there, if it can get there at all given current fuel level. Hell, I might even have it refuel itself before going there by taxiing over to a fueling station or something.


From what I've already created, it's a very very small step to a system where civilian vessels fly from one destination to another on their own. We're on the verge of have a live solar system in Orbiter.



The work has been slow going, though. OBSP autopilots are a hobby project of mine and I'd love to work on them 12 hours per day. AI is a highly technical field and I sometimes spend hours just tweaking a few lines of code. It'll still take some time before the alpha is out for your enjoyment.

Please, tell me this will include SC3 vessels ?

 

[jedidia]

Well, what about a kind of a flight planning tool?

Some dialog similar to the scenario editor, which you can access anytime from Orbiter and use for planning your mission?

It actually exists, there's just not a lot of people that know about it:
The Orbiter Navigator

3 disadvantages:
1. Beta stage, author missing in action, source code not available. Since I was on the beta testing team (hell, I was the Beta testing team at the bitter end, you know how it goes...), I know that the bugs are down to a few quirks in the interface here and there, nothing serious. It's fully usable. BUT:

2. Uses the XNA framework for visualisation. XNA is somewhat of a miscariage of microsofts, and doesn't run on a lot of GPUs. If yours isn't compatible, that is pretty much that.

3. Since it's beta stage, there's no actual solver implemented yet. The trajectory calculations are the precisest I have ever seen in Orbiter, integrating burntime and variable acceleration by propellant expenditure (works flawlessly for week-long burns in the mili-G range, the only tool for Orbiter I know about that can pull that of reliably) the whole thing links into an autopilot MFD that works even at the highest time accelerations (at least in deep space, you know what happens at high time acceleration near planets even without any autopilots running :shifty, but you have to set up the trajectory yourself, completely. Not very difficult since the thing is unholy fast and has good overview, but there's nothing that will give you a rough solution from which to optimise.

Anyways, the XNA problem is probably the bigest showstopper. Some two years ago or so I checked in with Mindblast, and he said he planned on getting back to it, but obviously something kept him from doing that.


Finally, I do not want to toot my own horn (which I'm really not, since most of the code is from Face), I'd suggest this for future projects that want to go the same way. Because irrlicht just somehow works, and because if it doesn't do what you want it to, you can make it...

Heck, maybe porting transX to a nice 3-d visualisation might be a good start, since that's open source too... Why have I never thought about that before? :facepalm:

 

[kamaz]

And that looks, IMHO, like a complicated mess of setting windows. No single button that reads "DO EVERYTHING FOR ME".

This is a more typical use case: http://orbiter-forum.com/showthread.php?p=431781&postcount=965

Basically, MechJeb is an all-in-one replacement for OrbitMFD, LaunchMFD, SurfaceMFD and attitude control.

It has a handful of features Orbiter does not have (such as fully automatic launch-to-intercept autopilot and a fully automatic pursuit-rendezvous-and-docking autopilot), but these features could be easily implemented in existing MFDs.

The OP's problem, basically, is that the required functionality is spread across multiple MFDs, while Mechjeb is an all-in-one package. That has certain appeal.

 

[RisingFury]

Please, tell me this will include SC3 vessels ?

The end goal is to include any vessel that a human can fly.

 

[elocoreloco]

I'm going to throw in my opinion, normally I don't post but there is always a second time.

I see two teams here, one that like autopilots and the ones that don’t like autopilots.
I think Orbiter is evolving to a new level with all recent and newer add-ons that developers are programming, like for instance Dans UCGO, UMMU action areas, Jedidas IMS, Wells Orcus Patera, etc, etc. all those details, are adding to the fun of the simulator plus an extra work to achieve a goal of what the player is trying to accomplish. Way back when IMS didn’t exist and only burchismo meshes existed without any more tasks than load up the module assemble it in space and let it orbit without more interaction, then Dan’s add-ons came up and added to the extra task and fun, now you have to keep an eye that there is enough oxygen and food at the ISS, because now you have to grab a ship with the oxygen cargo or food and head to ISS and save them before they starve or suffocate. IMS added more workload to whatever you are building, in my case I’m creating a Shipyard, for what purpose? to purchase an arrow freighter, using the trader made by Shakal, and initially have it docked at the shipyard when it’s finished, then take several cargos with the arrow to mars and use Orcus Patera to deliver cargos to colonize several other planets, and this is another small step of orbiter’s evolution, and an autopilot like that is useful because, as I said orbiter is evolving and is demanding more tasks to accomplish a whole project, sometimes while I’m waiting for my shipyard closest passage I’m doing other tasks like purchasing the modules and load them into an XR5, sometimes I have to use two XR5 to carry the modules and that means that I have to send one XR ahead time make into orbit, align with my shipyard and have a higher orbit so my shipyard catches my first XR, then take my second XR (by this time my Shipyard already passed over the Space center) so I have to take it into a lower orbit to catch up my shipyard, it would be nice to take both XR at the same time, also it would be nice let my XR taxi to the runway while I’m waiting the second XR fill up the tanks. The fun is in the imagination of each one of us and what tasks you may want to do to accomplish your whole project.
And I want to say this, we are here at this community because of the hard work that Mr. Martin has done and to all developers that are not expecting any economic reward than a thank you. So Thank you Mr. Martins and Thank you to all developers (If I name all, I don’t know how many pages would take)

elocoreloco

 

[Enjo]

Spaceflight in general is not an easy topic and IMO as education tool Orbiter can do better. With all due respect Enjo (LaunchMFD is really top piece of work) first look at LaunchMFD is kinda scary. I'm in no way demanding of you improving it in a way so 3 year old can perform direct ascent to ISS. That will be pointless because launch MFD wasn't designed for this task. It's not "entry level" autopilot.

That's OK. Some indicators could be removed there, for instance Curr. Error, Pitch, etc. especially since we have both MFD and HUD drawing, as well as PID AP, but firstly I wasn't directing my reply directly towards only you, and secondly, I speak also for TransX - I could remove the manual tuning since we have Auto-Min feature, because you can haz auto plan to Mars already, but I will keep it for educational purposes.

I'm also not stopping you from doing anything on your own, or with a team of enthusiasts.
Completely other thing though is that it's sometimes a good thing to distinguish between what we'd like to have done, and what we already have, which could be better adapted (ie. more popularized), not to redesign the wheel and to save time - development, testing, bug hunting etc.

 

[N_Molson]

In Orbiter, you have to read carefully the manuals. Not in KSP. Some people just don't accept that. Pity for them. :shrug:

 

[Pipcard]

In Orbiter, you have to read carefully the manuals. Not in KSP. Some people just don't accept that. Pity for them. :shrug:

There are no manuals for KSP. Just online tutorials.

 

[N_Molson]

There are no manuals for KSP. Just online tutorials.

Exactly, that's the point. Different gameplay, different approach.

 

[RisingFury]

In Orbiter, you have to read carefully the manuals. Not in KSP. Some people just don't accept that. Pity for them. :shrug:

I consider myself an advanced Orbiter uses, but I still prefer video tutorials over manuals and I still sometimes randomly mash the keyboard until I find the right buttons for a vessel's controls instead of reading the documentation.

I've never read Go play in space. I learned how to launch the Space Shuttle, how to dock to ISS and how to fly to the Moon using the playbacks that come with Orbiter.

The only manual I read straight through was the TransX manual and I didn't even fully understand TransX until I watched some videos.

So, do you pity me?


Orbiter isn't just user unfriendly. It grabs a hammer and smacks your head every time you look at an MFD. How many values displayed on the Orbit MFD does the average user actually look for on an average space flight?

ApA, PeA, ApT and PeT. The rest is not really useful, because there are other MFDs for that. Relative orbit inclination? Sure, just use Align orbit MFD.

And what's with the spelling? We clutter the screen with useless information until we run out of space and need to abbreviate words to the point you're *forced* to look at a manual or tutorial or video to learn what it means.


Orbiter isn't gonna become user friendly through a series of tutorials or a highly advanced autopilot system. Not until the community loses the "I'm better than the average KSPer" attitude and not until addon devs start designing more intuitive interfaces.