Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > OrbitHangar Addons & Comments
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

OrbitHangar Addons & Comments Addons uploaded at Orbithangar.com will automatically generate a new thread in this forum for comments. The thread link will also be included on the addons page.

Reply
 
Thread Tools
Old 01-27-2018, 12:37 AM   #16
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

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.
Urwumpe is online now   Reply With Quote
Old 01-27-2018, 01:12 AM   #17
ADSWNJ
Scientist
 
ADSWNJ's Avatar
Default

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.
ADSWNJ is offline   Reply With Quote
Old 01-27-2018, 01:43 AM   #18
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by ADSWNJ View Post
 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.
Urwumpe is online now   Reply With Quote
Old 01-27-2018, 02:07 AM   #19
ADSWNJ
Scientist
 
ADSWNJ's Avatar
Default

Quote:
Originally Posted by Urwumpe View Post
 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.
ADSWNJ is offline   Reply With Quote
Old 01-27-2018, 07:36 AM   #20
Urwumpe
Certain Super User
 
Urwumpe's Avatar

Default

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.
Urwumpe is online now   Reply With Quote
Old 01-27-2018, 08:45 AM   #21
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by Urwumpe View Post
 Well, a good example how to solve this would be looking at the CAN aerospace serial bus standard:
Interesting document, thanks for the link!

On the topic of Orbiter microservices, I must admit that I am very skeptical. From experience, most microservice architectures I've encountered - both private and at work - turned out to be an unmaintainable, over-complicated and over-engineered mess that actually solves problems nobody would have without them. YMMV, of course.

In that light, I'd suggest to first identify the problems you want to solve with such a system. Is there a combination of addons today (or in the foreseeable future) that will work better and/or faster with it? Will it be easier to deploy (versioning comes to mind) and use this combination with the microservice architecture in place?

The example of autopilots is very interesting, but I think it should be sketched out first in order to have a use-case for the architecture.
Face is offline   Reply With Quote
Thanked by:
Old 01-27-2018, 02:46 PM   #22
ADSWNJ
Scientist
 
ADSWNJ's Avatar
Default

My preference would be a consistent set of information sharing as a first goal. Enjo and I have done this for years with our set of MFDs, but I would like to do it for more modules.

(By the way - see the developer documentation that comes down with this release ... it's comprehensive!)

With the new Find() call in the Advanced Interface, it's now possible to look for sources of data without pre-knowledge of what will send it. For this to be more solid, I would prefer to have some reserved names and guidance for developers when to use those names, so we know what we are finding. E.g. a simple one: Target OBJHANDLE (where we already do a ton of checks to ensure that OBJHANDLE is always valid on any Put, Find, or Get) ... this should be something that we can agree on quite easily.

What chains of MFD's, or actions in vessels linking to MFD's would people like? To give you some ideas, think about this example:

1. XR-5 at the Cape, going to Luna space station. Initial planning with LaunchMFD, then TransX.

2. Some kind of Flight Management Computer MFD to plan the initial atmo phase up to parking orbit, then the TLI burn and glide to the moon (with pre-planned MCCs), then Lunar insertion and sync to Luna, then docking approach.

3. For the atmo phase ... we would have LaunchMFD, ScramAttitude, Align Planes, and TransX interacting with various controls on the XR-5 (e.g. opening scram doors, controlling APU, watching nose and wing temps), all with entry and exit criteria for using each tool.

4. Potentially the FMC MFD would work a control API interface with each utility, to activate each function at the right point ... e.g. adjusting the XR-5 bank AP to roll out onto 140 degrees, then hand off to LaunchMFD's AP, then leave LaunchMFD doing azimuth, and ScramAttitude to do AoA.

So rather than microservices (which I agree can get us into a ton of work for no benefit), this would be back to the original idea of chaining independent MFDs to achieve the look and feel of an integrated flight deck with all components aware of a bigger situation than just their controls.

Well ... I can dream, I guess...
ADSWNJ is offline   Reply With Quote
Thanked by:
Old 04-01-2018, 09:07 PM   #23
ADSWNJ
Scientist
 
ADSWNJ's Avatar
Default

V2.1 released. Minor tidy-up version to fix some issues as I was coding BaseSync and Glideslope natively to this new interface.
ADSWNJ is offline   Reply With Quote
Old 04-08-2018, 06:17 PM   #24
ADSWNJ
Scientist
 
ADSWNJ's Avatar
Default

v2.1c release ... more minor bugfixes and improvements (working through a couple things with Enjo). I also updated the MMExtMFD to have a data dump mode mode (as well as a variables and an activity mode), so you can see data changing in real time ... in nice colors too!
ADSWNJ is offline   Reply With Quote
Thanked by:
Old 04-09-2018, 07:44 AM   #25
Enjo
Mostly harmless
 
Enjo's Avatar


Default

It's worth noting, that downloading this release by users and not developers, is absolutely optional, because the communication dll hasn't changed at all.

[EDIT] Except for that MFD update of course, if anyone wishes to use it.

Last edited by Enjo; 04-09-2018 at 09:29 AM.
Enjo is offline   Reply With Quote
Old 04-10-2018, 12:54 AM   #26
ADSWNJ
Scientist
 
ADSWNJ's Avatar
Default

Quote:
Originally Posted by Enjo View Post
 [EDIT] Except for that MFD update of course, if anyone wishes to use it.
Worth it as an end user just for the pretty new colors on the MMExt MFD!!
ADSWNJ is offline   Reply With Quote
Old 04-10-2018, 06:53 AM   #27
Enjo
Mostly harmless
 
Enjo's Avatar


Default

but you still underestimate the compatibility that you deliver by not changing the core dll and not forcing the users to update, only making it optional. That's a feature too!
Enjo is offline   Reply With Quote
Reply

  Orbiter-Forum > Orbiter Addons > OrbitHangar Addons & Comments


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 02:00 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.