OHM ModuleMessagingExt v2.1d for Orbiter 2016

[OrbitHangar]

Author: adswnj

(Minor tidy-up from previous major release - 2.1a re-adds in the compatibility files for old MM v1 MFDs, 2.1b minor bugfix, 2.1c better MMExtMFD, and tidied MMExt interface, 2.1d fixes PRV NXT problem when no data in the log. )

This is a major release of the Module Messaging Extended library: a utility that allows data sharing between any Orbiter module. Examples of data interchange: LaunchMFD to TransX, RV Orientation to BaseSync and Glideslope. 

For this release, the core has been rewritten fron scratch to eliminate startup dependency error 126 errors. The old interface has been preserved for existing MFDs that rely on it, but there is a new and much cleaner set of v2 interfaces to allow developers to share data with a minimum of just 3 lines of code. 

This version also has a MMExt2MFD interface into the core data handler, so you can see data exchange in real time in the simulation. 

There are no longer any pre-requisites (no run time dependencies, etc.)

Co-authored by Enjo and ADSWNJ. 



DOWNLOAD

 

[ADSWNJ]

For anyone looking at this code, please be advised that a much better version is a few days away. PM me for details if interested.

 

[ADSWNJ]

Announcing updated v1.1 release of the Module Messaging Extended library. This has been a couple of weeks of intensive collaboration between Enjo and me, really working the code into a great shape.

This is now a mandatory pre-req for BaseSync v2.6 (also released today), and over time will replace Module Messaging (original) completely, as we work through the updates to the legacy code.

The family of MFD's that will eventually use this library will include:

LaunchMFD
BurnTimeCalc
BaseSyncMFD
Glideslope 2
RV Orientation
TransX


For all other MFD or Vessel developers ... please PM me if you have ideas for interconnection in/out of your modules, or if you need more features. The goal is to make this an open, generic framework for simple and logical data interconnection of MFD's just how the user would expect it to work on a modern flight deck.

 

[turtle91]

Just an idea for "traveling" from a to b on an airless world using this tools together:

-hover for takeoff and altitude-hold (i.e the XR built-in hover-altitude-mode)
-GlideslopeMFD for acting as a GPS to point b
-Burn-time Calc takes care about de-acceleration before reaching the target stored in GlideslopeMFD
-RV-Orientation performs the (RCS)cource-correction with data feeded by GlideslopeMFD.

Just an idea.....

 

[ADSWNJ]

... and it's a good idea, but probably with a different set of tools. The nice thing is that having a way to chain MFD's allows us to make a new set of simpler tools, doing single jobs, and then choose how to plug them all together. E.g. a GPS Mfd just giving location vectors, piped to a bare bones auto-pilot that has no way to select target, piped to a precision non-atmospheric lander MFD. Etc.

 

[boogabooga]

Just an idea for "traveling" from a to b on an airless world using this tools together:

-hover for takeoff and altitude-hold (i.e the XR built-in hover-altitude-mode)
-GlideslopeMFD for acting as a GPS to point b
-Burn-time Calc takes care about de-acceleration before reaching the target stored in GlideslopeMFD
-RV-Orientation performs the (RCS)cource-correction with data feeded by GlideslopeMFD.

Just an idea.....

No, you should use this:
[ame="http://www.orbithangar.com/searchid.php?ID=5712"]HoverMFD 1.1.1[/ame]

 

[Face]

... and it's a good idea, but probably with a different set of tools. The nice thing is that having a way to chain MFD's allows us to make a new set of simpler tools, doing single jobs, and then choose how to plug them all together. E.g. a GPS Mfd just giving location vectors, piped to a bare bones auto-pilot that has no way to select target, piped to a precision non-atmospheric lander MFD. Etc.

UNIX for Orbiter MFDs? Only do one job, but do it well? Sounds cool. :thumbup:

How do you configure what tool pipes what where? A kind of MFD mode shell?

 

[turtle91]

>No, you should use this:
>HoverMFD 1.1.1

Yes, I am using this a lot exactly for short/medium distance trips.
Works even on Mars, if the waypoints are not too far away, and if RCS thrusters are strong enough. (heli-mode does not work nice on worlds with an atmosphere, when i.e. using winged aircraft)
But it's not running with Orbiter-2016 and no sources available.
So my idea was, to reduce the amount of MFDS loaded into orbiter, and (cross)using just a few to reach the same goals.
So yes...one job doing well and giving results to the next one-job MFD to work on.

 

[ADSWNJ]

MFD mode shell would be cool. But first ... we need a definition for the common things to pass around, and a set of microservices that would be useful regardless of any interface. (Shout-out to Blix for this line of thought...)

Sent from my SAMSUNG-SM-G925A using Tapatalk

 

[Face]

MFD mode shell would be cool. But first ... we need a definition for the common things to pass around, and a set of microservices that would be useful regardless of any interface.

Coming from the UNIX analogy, there it was a completely undefined text stream. What would be the equivalent of a text stream (for text-based tools) in a graphics-based MFD mode environment? To me, that's starting to sound a bit too much like systemd and kdbus TBH .

 

[ADSWNJ]

Coming from the UNIX analogy, there it was a completely undefined text stream. What would be the equivalent of a text stream (for text-based tools) in a graphics-based MFD mode environment? To me, that's starting to sound a bit too much like systemd and kdbus TBH .

Not a text stream in a classic Linux pipe sense, no. I am envisaging a set of microservices that can run in the background and calculate things as needed. The interface is via ModuleMessagingExt, where you can safely map on top of any level of complexity of structures to pick up 2, 10, 100+ variables as you want, in real time. To start simply, we would have each microservice take requests and offer real-time updated solutions (e.g. updated guidance data) to the next service.

I'll mock some ideal up to show what I mean. In the meantime, for developers, look at MMTest 1+2 and ModuleMessagingExt to see how this safe pass-by-ref works.

 

[rrichard]

Auto Atmospheric Air Traffic Control

I would love to see Controller Script MFD send its instructions to UAP MFD or AutopilotMFD 1.7 for automated flight at launch and/or landing. Or perhaps GS2 to UAP (Aerial state hold).

 

[ADSWNJ]

ANNOUNCING: ModuleMessagingExt v2 for Orbiter 2016

This is a major release of the Module Messaging Extended library: a utility that allows data sharing between any Orbiter module. Examples of data interchange: LaunchMFD to TransX, RV Orientation to BaseSync and Glideslope.

For this release, the core has been rewritten fron scratch to eliminate startup dependency error 126 errors. The old interface has been preserved for existing MFDs that rely on it, but there is a new and much cleaner set of v2 interfaces to allow developers to share data with a minimum of just 3 lines of code.

This version also has a MMExt2MFD interface into the core data handler, so you can see data exchange in real time in the simulation.

There are no longer any pre-requisites (no run time dependencies, etc.)

Co-authored by Enjo and ADSWNJ.

---------- Post added at 01:25 PM ---------- Previous post was at 01:21 PM ----------

Sample code for developers:

#include "MMExt2_Basic.hpp"                     // From the usual Orbiter include folder
MMExt2::Basic modMsg(“XYZ”);                    // Declare Module Messaging Interface for your MFD - e.g. XYZ
bool ret = modMsg.Put("TargetObj", hObjTarget); // Send data to Module Messaging

 

[Urwumpe]

Coming from the UNIX analogy, there it was a completely undefined text stream. What would be the equivalent of a text stream (for text-based tools) in a graphics-based MFD mode environment? To me, that's starting to sound a bit too much like systemd and kdbus TBH .

Well, a good example how to solve this would be looking at the CAN aerospace serial bus standard:

http://www.stockflightsystems.com/tl_files/downloads/canaerospace/canas_17.pdf

While the electric side of it isn't really interesting for us, the message format and how data can be identified in a standardized way is.

 

[ADSWNJ]

Well, a good example how to solve this would be looking at the CAN aerospace serial bus standard:

http://www.stockflightsystems.com/tl_files/downloads/canaerospace/canas_17.pdf

While the electric side of it isn't really interesting for us, the message format and how data can be identified in a standardized way is.

We do not need to debate at this low protocol level. The Module Messaging library allows a wide variety of Orbiter objects to be passed as first-class citizens (e.g. from base data types, up to VECTOR3, MATRIX3, MATRIX4, and then up to OBJHANDLE). Beyond this, there is a general method to send more complex data structures, each with significant work to prevent CTD's.

If this library is to achieve the general benefit for all developers, I believe we need to agree naming conventions and data passing for common things that make the flight deck experience feel more immersive to our end-users. For example ... there should be a simple way for us to synchronize the following things:

• Target object (objhandle)
• Burn parameters (time as a MJD, burn vector in a specific ref frame, burn duration or DV.
• Flight waypoints
• Autopilot modes
• General vehicle status

Beyond this, there should be a standard way to discover, select, and interact with microservices. For example, a one-axis fuzzy logic autopilot, activated and controlled by any number of MFDs ... advertising capability to the MMExt, and then taking control inputs via a set of control variables, whilst returning status. This is technically easy to do, and could be auto-loaded and chained into an execution pipeline dynamically with no Error 126 issues, etc. These microservices could optionally be made Orbiter-independent, through shims to control oapi calls, so the code could live in other simulators, or run in the cloud etc. For example, with my LagrangeMFD ... maybe do 1000 times the resolution by chaining it to a network module and run it in AWS.

Heh ... flights of fantasy, but for now, we have the bare tools to start thinking like this. Devs of the world, unite!!

 

[Urwumpe]

Well, that is what I meant with the reference to CAN-Bus: The data not only has defined identifiers there, but also defined data types.

If "TargetObj" is always an OBJHANDLE, its easy. It wold just take a table of common identifiers and datatypes for developers to conform to.

The toughest question for the microservices case would be: Who defines the architecture?

Does ModuleMessagingExt know local communication, that is limited to a specific vessel? The example looks rather global.

 

[ADSWNJ]

There are two facades (or interfaces) to Module Messaging Ext - per Enjo's architectural guidance. The Basic Interface is for same-vessel only (and is really simple and sleek), but can point to another object (e.g. a star, a base, ISS, etc) no problem. The Advanced Interface can look for data for other vessels in a simulation, whilst maintaining all the right context. The Advanced Interface also has wildcard Find() functionality to discover common data types.

Who defines the architecture? We do ... i.e. the developers active in this forum. I don't presume to define this myself, but I could propose a first proposal on canonical names and meanings if the team would like a strawman to work from. If we had such a thing, I could encode it differently as reserved variable names, to lock in the strength of those names.

 

[Urwumpe]

Who defines the architecture? We do ... i.e. the developers active in this forum. I don't presume to define this myself, but I could propose a first proposal on canonical names and meanings if the team would like a strawman to work from. If we had such a thing, I could encode it differently as reserved variable names, to lock in the strength of those names.

Sorry... I am not talking clearly enough this night anymore, should really go to bed.

I meant the architecture of the microservices - which services are interacting how.

 

[ADSWNJ]

Sorry... I am not talking clearly enough this night anymore, should really go to bed.

I meant the architecture of the microservices - which services are interacting how.

LOL - that's funny!

So ... what microservices would make sense? Simple utility functions (in which case we need synchronous replies), or more complex functions like autopilots (where a next-simstep reply is fine).

My thinking is that we all write too many autopilots, PID or fuzzy control loops, guidance calculators, burn simulators, burn control algorithms, etc, for our own good, so there has to be a smarter way. But - to build such tools with almost zero usage ... there's no point.

SO Enjo and I plug away with the underlying plumbing, and look for people to join the effort with there vessels and modules, to help grow the integration of the community.

 

[Urwumpe]

Well, one possibility would also be "non GNC functions" For example, interacting with crew simulations or trade add-ons. For example, when having something similar to UMMU, another plugin could be installed to add a medical simulation there, which in turn could also interact with a ECLSS simulation either added as plugin or by a vessel specific implementation.

For autopilots it makes really sense to maybe also allow vessels to provide low-level functions themselves, instead of leaving this to a MFD/service to find out.