Project Orbiter economic simulation

MeeexC

Member
Joined
Nov 19, 2011
Messages
37
Reaction score
21
Points
8
Location
Ulm
I have recorded from all of you that on the way to an economic simulation visible to the player, it needs first of all a well-functioning artificial space traffic (AST). The economic aspect can then be added later or other features. I am now also sure that as soon as there should be a stable version, I will provide it as open source (except for the AI and everything concerning my personal licenses of course).


Now a few basic assumptions about the AST system:


- The player should get the feeling of a busy space. With the restriction that Orbiter simulates space realistically and accordingly trajectories and distance will always lower this feeling a bit. A feeling like in Freelancer or the X-series cannot be the goal, as we still want to have a simulation and not a "game".

- The AST will be optimized to experience traffic especially at bases and stations.

- Immersion is the main focus, so the system should work as autonomously as possible.

- The AST must behave adaptively in each scenario with respect to installed add-ons (new bases, ships, stations).

- At the beginning of a scenario the player should be able to make settings (number of ships, holding times at stations, max. Number of bases, which add-ons should be used). After that the AST is initialized and has to run continuously.


From this I derive the following development steps for the AST system:


1.1 The distribution function proposed by Face. This is to create a network between all available docking ports and landing sites, in such a way that they are always maximally utilized. Either way, the player will hardly encounter ships in orbit or between planets/moons, so the immersive experience is concentrated on the bases and stations. Thus, it is necessary to optimize the variables of flight time and standing time on site with the number of ships in such a way that the mentioned conditions are fulfilled. Here I will do some calculations and see where the limits are, if you would like to encounter a ship even in an orbit in 1h sim time (< 100 km) and others. In addition I would like to look whether I need trajectories or if time spans are sufficient for a zero approximation here (earth - moon: 3 - 10 days etc.).


1.2 Calculation of the actual trajectories to fulfill the parameters of the distribution function. Here I have to see what is possible, especially the ascent and the landing or reentry worry me here. In the end the trajectories alone are not enough, but the orientation of the ship - VESSELSTATUS2 - must be fitted all the time.


2. the implementation in Orbiter. Here I still have a lot of open points. How do I want to integrate the AST system (modules in the game or external program)? How do I create an immersive effect during landing and docking? How do I control that the ships really reach their destinations without it looking goofy when landing?


The more I think about the last point, the more I feel that an autopilot can solve the problems and a solution without an autopilot is no less costly and complicated.


Many greetings

Max
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,271
Reaction score
3,244
Points
203
Location
Toulouse
Seems you're well on the way. But again, don't underestimate the immensity of space. If you want to keep things realistic, the player will only encounter other ships in atmospheres or near hubs (bases, stations...). Unless there are billions of ships transiting between planets, and I'm not even sure that would make a difference.

But seeing even random traffic near bases and stations would make the sim much more immersive, so your AST would be fantastic.

I'd say try to avoid third-party modules and stick with Orbiter dlls (my two cents).
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
When it comes to orbiter integration, I think you can probably get away with only representing traffic near bases physically in the sim. Which are, unfortunately the hardest where integration is concerned. Docking and landing require a level of spacial awareness in the sim, even if it's not an autopiloted approach, but "on rails". The rails still have to make sense. For docking, that means approaching a station from the right vector for example, or that the vessels don't depart through the station.

For a first version (and you always should subdivide your projects into as small versions as possible) I'd probably go with tackling that problem, since it's the most essential and most visible. The whole trajectory thing at this point could still just be a procedural probability cloud that determines which vessels are docking or leaving which location at which time without much logic of where they're coming from or where they go to, and the focus would be on making them dock, launch and land appropriately.

The more I think about the last point, the more I feel that an autopilot can solve the problems and a solution without an autopilot is no less costly and complicated.
You are probably right on the second point. But it would be a lot more robust. When doing anything autopiloty in orbiter, you are always fighting the precision loss that occurs from time acceleration. If a player is a hundred km out and slowly drifting in with time accel cranked up to 100x, your autopilot trying to dock to the target station will be in one hell of a boiling pot, while the rails approach would have no difficulty handling it.
 
Last edited:

MeeexC

Member
Joined
Nov 19, 2011
Messages
37
Reaction score
21
Points
8
Location
Ulm
When it comes to orbiter integration, I think you can probably get away with only representing traffic near bases physically in the sim. Which are, unfortunately the hardest where integration is concerned. Docking and landing require a level of spacial awareness in the sim, even if it's not an autopiloted approach, but "on rails". The rails still have to make sense. For docking, that means approaching a station from the right vector for example, or that the vessels don't depart through the station.

For a first version (and you always should subdivide your projects into as small versions as possible) I'd probably go with tackling that problem, since it's the most essential and most visible. The whole trajectory thing at this point could still just be a procedural probability cloud that determines which vessels are docking or leaving which location at which time without much logic of where they're coming from or where they go to, and the focus would be on making them dock, launch and land appropriately.


You are probably right on the second point. But it would be a lot more robust. When doing anything autopiloty in orbiter, you are always fighting the precision loss that occurs from time acceleration. If a player is a hundred km out and slowly drifting in with time accel cranked up to 100x, your autopilot trying to dock to the target station will be in one hell of a boiling pot, while the rails approach would have no difficulty handling it.

That is exactly the point! An autopilot would "deliver" everything immersive but has the timewarp problem. But here again my question: Where is the bottleneck? Every controller, whether simple PID or whatever, comes to its limits when it has to react faster than its feedback loop allows. Is this due to the update rate of the autopilots (MFD refresh rate?) or to a delay in the control pulses of the thrusters which does not decrease according to the timewarp? I would like to learn something about where these limitations in the timewarp come from. Pure computational power does not seem to be the problem. With simulated controllers we actually have the advantage that we work with simulated physics. Here we know all the laws, and thus we should actually be able to consider the simulation detached from the timescale.


Now to the first part of the post: If you break the problem into parts, it is true that the path between orbits is the easier part. Sure there are slingshots etc but here the trajectories have to be calculated with great precision. But especially the approach and departure is the trickiest part, as you also mentioned. Here I can imagine that there are routes similar to those in aviation. For the sake of simplicity, I would first pick out only the ISS and Brighton Beach as examples. What works here can then be applied to other stations and bases. The earth I take only later into the focus.


If we were in a simple Cartesian coordinate system, I would define a cubic space sector around a station with six entry points. Each approach to the sector, i.e. each trajectory must arrive at one of these points, depending on the space direction from which it comes. From these points there are dedicated approach and departure paths for each dock or platform. These paths are "hardcoded". So my idea here is to perform an approach manually from said point to one of the docks and to read out the VESSELSTATUS2 (VS2) in very short sim time steps (t_Sim).
In a first approximation, as soon as a ship hits this point, one could update the VS2 of the ship from a VS2 table relative to the t_Sim. Thus, all consumables can be adjusted as well. Also, the engines can be controlled by this. However, I would like to find a way that the ships are not physically simulated during this time to have the path completely robust. After all, the positions are adjusted via the VS2. That's how I would try it out now as a first step. If this works, you can then manually fly some of these paths with different initial conditions (velocity vectors when reaching the entry point) and take the VS2/t_Sim values as training set for the AI. The AI can then calculate an approach from each entry point into the space sector. It makes sense to choose a spherical coordinate system. However, I have to take a closer look at how Orbiter works here to adapt to it. I think they are spherical systems with reference bodies/points or?


I still have one problem here! When I look in the API I find VESSEL::GetStatus but no VESSEL::SetStatus. There are flags with which you can set some items of the VS2 but not the positions. Do you know how the Scenario Editor does that? Without this function I can't guide a ship on a path without simulating it.


The only alternative would be to record the control commands instead of the position vectors and play them back. Then the ship would actually use its thrusters and airfoils, however I see a problem with timewarp and precision here too!


I am curious about your feedback. I will start to construct a suitable sector size around the ISS and record the first approaches to the docks. Let's see how well I can interpolate here. Unfortunately I have not yet been able to establish a direct communication between Matlab and Orbiter in real time. Orb::Connect works, but there are some API functions missing and TCP/IP protocol is mediocre in Matlab. In R2020b there is an update, but I wanted to wait for R2021a... I don't want to roll out a new Matlab version on my system here because of Orbiter alone. A version change is always a critical moment and I can't afford it right now. So I can't use Orb::Connect for my purposes at the moment. I would have to look into the source code here, but that would cost time again. I am thinking about using another protocol for the communication with Matlab, but then I would have to write a whole module for Orbiter from the drawing block again... I don't really want to do that, and I'm not familiar enough with C++ to enjoy it.
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
Is this due to the update rate of the autopilots
It's due to the update rate of the entire simulation.

You can think of the orbiter architecture as an event queue (it's not implemented as a queue as far as I know, but thinking of it as such comes close enough) that gets worked off from start to finish, updates the state according to the result, taking the sim time that elapsed during the processing as the new time for which to calculate the state, then starts at the beginning of the queue again. The entire queue for the entire simulation is processed synchronously in one go.

By default, this is frame-locked, i.e. the less sim time elapses between frames, the more precise the calculation is. Essentially, the time that elapses between those state updates does not exist and cannot be used for decision making. The illusion that the time is contiguous is because every update the sim state matches with the sim time. So if there's a lot of sim-time elapsing between two frames, that's a lot of time during which no actions can be taken, but acting forces still has the same effect. You're basically decreasing the resolution for available reaction time.

This resolution is measured in centiseconds range (you can easily deduce it from your FPS, really). While time acceleration is at 1x, the time elapsed in the real world and the simulation is the same. So if you have 30 frames per second, your autopilot gets to react 30 times per second in the simulation.
Now you crank up time acceleration to 100, and sim-time now elapses 100 times faster than the real time. If you're still at 30 frames per second, your autpilot now gets to react roughly once every 3 seconds in actual sim-time.
That don't sound so bad yet, until you consider that firing a thruster and turning off a thruster are two actions. In these circumstances, it doesn't mean that the autopilot has to wait 3 seconds until it can correct something. It means if it fires a thruster to correct something, it has to leave it running for 3 seconds until it can turn it of.

And thus, a merry chain of overcorrections usually ensues, which you can try to buffer by adjusting your thrust levels to have the desired effect at the current resolution of time, which becomes a pain in the ass, because your autopilot now has to predict state rather than just check it. Worse, it has to do so on incomplete information, because it only knows the delta time of the previous update and just has to assume that the delta time for the next frame will be about the same, which is mostly true, but certainly not always, meaning that there's always unpredictable stuff that can throw it a sudden curve ball that is difficult to recover from because it's reaction time is already severely limited.

I still have one problem here! When I look in the API I find VESSEL::GetStatus but no VESSEL::SetStatus. There are flags with which you can set some items of the VS2 but not the positions.
It is possible. It's called "state vectors", not position, as far as I remember.
 
Last edited:

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
I'd say try to avoid third-party modules and stick with Orbiter dlls (my two cents).
Second that.

1.2 Calculation of the actual trajectories to fulfill the parameters of the distribution function. Here I have to see what is possible, especially the ascent and the landing or reentry worry me here. In the end the trajectories alone are not enough, but the orientation of the ship - VESSELSTATUS2 - must be fitted all the time.

2. the implementation in Orbiter. Here I still have a lot of open points. How do I want to integrate the AST system (modules in the game or external program)? How do I create an immersive effect during landing and docking? How do I control that the ships really reach their destinations without it looking goofy when landing?

The more I think about the last point, the more I feel that an autopilot can solve the problems and a solution without an autopilot is no less costly and complicated.

When it comes to orbiter integration, I think you can probably get away with only representing traffic near bases physically in the sim. Which are, unfortunately the hardest where integration is concerned. Docking and landing require a level of spacial awareness in the sim, even if it's not an autopiloted approach, but "on rails". The rails still have to make sense. For docking, that means approaching a station from the right vector for example, or that the vessels don't depart through the station.

I agree with jedidia on this topic. Currently I am working on the multiplayer aspect of this whole "economic world building" here, and already have some code in place. What quickly came up there was the need to have placeholders instead of "real" vessels in the simulation to represent remote controlled objects. They work like a shell, only displaying a few meshes for the visuals, but without inner systems or settings, because they are controlled from elsewhere, anyway.
I can imagine to extend this "Puppet" - as I called it - with the ability to read way-point information from vessel-specific scenario-data in order to replay hard-coded and parametrized sequences in a rail manner. Such sequences could be:
  • Appear at MJD at point A, having latitude, longitude and height or orbital state vectors.
  • Atmosphere flight from current position to point A, ending at a given MJD. The puppet vessel will simply replay the necessary position changes on the great circle.
  • Orbital flight with given orbital parameters ending at MJD. Again, the puppet vessel will just initiate the DefSetStateEx() calls to setup the trajectory, then let Orbiter propagate it along.
  • VTOL landing sequence at point A (coming from current point) ending at MJD.
  • Pausing (perhaps with extra animation like hatch opening) ending at MJD.
  • VTOL starting sequence from current point to point A ending at MJD.
  • Taxi to point A ending at MJD.
  • Disappear.
  • HTOL landing sequence at strip defined with two points, ending at MJD.
  • HTOL starting sequence from current point into direction of point A up to point B, ending at MJD.
  • Docking approach coming from current position to target vessel and target port, ending at MJD.
  • Undocking, moving to relative point X w.r.t. vessel it undocked from, ending at MJD.
Alternatively, you could exchange the MJD parameters with speed parameters (except for e.g. appear, pause and disappear).
 
Last edited:

E69shango

Member
Joined
Apr 1, 2009
Messages
18
Reaction score
9
Points
18
Location
Spain
The economic game and to be able to see some traffic near the bases is great but I am not sure if the IA spacechips flying their routes are worth the effort. Honestly space is vast and lacking any kind of sensors it will make founding a ship in deep space real rare.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
The economic game and to be able to see some traffic near the bases is great but I am not sure if the IA spacechips flying their routes are worth the effort. Honestly space is vast and lacking any kind of sensors it will make founding a ship in deep space real rare.

I think somebody in here already mentioned to first focus on the traffic around the bases and stations only. I.e. let RNGesus create the vessels at some distant point, fly it in, let it land/dock, wait, then start/undock again and disappear in the distance. No need to simulate full flight-plans at first. You could even skip that part for the AI training, if only the distribution is important at first.
So yes, you wouldn't see anyone on-route, but as you come closer to your destination, you'd see traffic pop up in front of you. I can sure see how that brings a lot of fun to it.
 

MeeexC

Member
Joined
Nov 19, 2011
Messages
37
Reaction score
21
Points
8
Location
Ulm
The economic game and to be able to see some traffic near the bases is great but I am not sure if the IA spacechips flying their routes are worth the effort. Honestly space is vast and lacking any kind of sensors it will make founding a ship in deep space real rare.
Of course, you're right, that's why I'm working on docking and landing.


At the moment I'm trying a lot how to best integrate my system into Orbiter. Also, I'm thinking about what all is possible starting from the OAPI and what approaches work for me. Since I'm just trying and discarding, it's not worth reporting anything here. When I have found an approach that works for me, I will post it here. My goal right now is to generate realistic traffic around stations and bases that doesn't sacrifice performance and can still be expanded later, as I originally envisioned. The idea with the "puppets" is already quite good, I'll try if something in between.
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
Just for a bit of encouragement, I think it would be really cool if we had a generalised system that can handle that. Best of luck!
 

MeeexC

Member
Joined
Nov 19, 2011
Messages
37
Reaction score
21
Points
8
Location
Ulm
Just for a bit of encouragement, I think it would be really cool if we had a generalised system that can handle that. Best of luck!
I will try my best ;-)



Today, I finally managed to establish a stable connection between Matlab and Orbiter via Orb:Connect. I guess, sometimes you should remember the basics, I just say: LF and CR...
It has actually become quite fast. I can sample the ship parameters with min 50 Hz.

Unfortunately the parser of Orb:Connect does not have all the OAPI functions I need, so I will continue here.
Right now I don't know what direction I'm going in but I definitely need to add something to Orb:Connect or write my own module with a parser. To be honest, I don't really want to do that, even if the latter would be more elegant, because I can compile everything into one module later.

In the final system this bypass via TCP/IP will not exist any more.
 

MeeexC

Member
Joined
Nov 19, 2011
Messages
37
Reaction score
21
Points
8
Location
Ulm
50 Hz is really good, good work (y)

I must confess that in my current version I can no longer go above 20 Hz... However, this limit should be at the same level as the frame rate later on.


But here's some news:


Thanks to Orb:Connect I can now record the trajectories of the ships via TCP/IP connection between Orbiter and Matlab. The first task I set myself was to land in Brighton Beach from different orbits. For the AI development I had to create a training set. So I manually (or with the help of MFDs) made some landings from different orbits. At the moment these are all perfectly aligned and circular. So I have only changed the altitude, distance to base and MJD. Still the training set is too small. So I am looking at the different MFDs so that I can land 6 DG at the same time.


I am reading out MJD and the VESSELSTATUS2 structure with the three subclasses for fuel, thruster and docking info with 10 Hz real time sampling.

Initial tests show me that it might make sense to also record the relative distance to the pad.


Now I am working on the AI:

The parameters still have to be transformed and interpolated. A conventional controller would now have all the parameters as input and calculate the control impulses for the thrusters from them. However, we have already discussed above that such an autopilot fails because of the time warp. So instead of the control impulses, a cheating autopilot outputs a new VESSELSTATUS2 to MJD+dt. As input my AI has the target (rbody, base, pad) as constants and the current VS2 as a function of MJD directly from Orbiter. As soon as the simulation reaches MJD+dt, the VS2 is loaded. So the spacecraft not only performs the movements correctly, but the thrusters are also controlled correctly. The AI is not super complicated, but I have to optimize it and that is only possible if I can test it "live" in the sim.

This is where my current problem arises: Orb:Connect unfortunately has no equivalent in the parser for the function VESSEL:DefSetStateEx() - which I see as the only possibility to pass a VS2 to the sim. So I can't avoid adapting something here and to recompile Orb:Connect 3.19. So far I have not been able to get this to work with Visual Studio 2019.... Has anyone here tried this before? If the AI works I will of course not use TCP/IP anymore but adapt my module to call the functions directly.


From this follows straight for the To-Dos

- Finish AI to predict landing trajectories from each aligned orbit in first version.

- Adapt Orb:Connect to use DefSetStateEx.

- Test AI in sim and optimize if approach works.

- Adjust dt to time warp to get the landing right even at 100000x.

- Same procedure for other planets/bases -> find a way not to create the training set manually.

- Repeat the cycle for docking at ISS -> Again from different orbits.

So far I start from an aligned orbit each time, I see no reason to start from an off-plane orbit, because realistic transfers should actually always be done that way or does anyone see it differently?

- The last thing I want to do is the transfer from rbody1 to rbody2. So that at the destination the orbit insert leads back to an aligned orbit.

- Sure launch to orbit will be also done. I have some headache thinking about reentry and landing on rwy...


And then we'll see.

At the moment, I am unfortunately also quite busy with my professional projects, so this is only going slowly... Especially, the manual creation of the training flights is time-consuming, plus I had to understand again how everything works in Orbiter, which often ends up with me playing around for 2 hours and trying out different things...

EDIT:

I'll take some time in the next few days to post a step-by-step tutorial with my Matlab code on how to create the connection. Maybe someone will want to do this again someday.
 

Owenmck

Read the documentation!
Joined
Apr 18, 2020
Messages
125
Reaction score
117
Points
58
Location
Scotland
Nice work. Don't feel like you need to rush, nothing good comes quickly anyway. (y)
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
This is where my current problem arises: Orb:Connect unfortunately has no equivalent in the parser for the function VESSEL:DefSetStateEx() - which I see as the only possibility to pass a VS2 to the sim. So I can't avoid adapting something here and to recompile Orb:Connect 3.19. So far I have not been able to get this to work with Visual Studio 2019.... Has anyone here tried this before? If the AI works I will of course not use TCP/IP anymore but adapt my module to call the functions directly.

What do you mean? Tried to recompile Orb:Connect, or tried to use DefSetStateEx? I did the later many times now, and from my experience there are some problems with DefSetStateEx:
  1. You have to properly initialize the structure. This means that you should zero all fields, then set the version 2, clear the flag block, use the right status value.
  2. If you want to enforce a landed state (status field zero), Orbiter 2016 has a bug that prohibits that. The only workaround I know is to fake a scenario loading for the vessel by means of calling the clbkLoadStateEx callback directly with a temporary scenario snippet file.
  3. Know when to call DefSetStateEx. I found the most reliable place to be in PreStep.
  4. You need to fake the acceleration vector, because this is not part of VS2, but essential for the propagator to keep running between DefSetStateEx samples. I.e. not taking acceleration into account with low frequency samples will make the object stutter along its trajectory, because the orbiter propagator handles the force-free object accordingly between samples. On orbit this might not be a big problem, but especially in atmosphere landings the drag will cause the object to decelerate between samples, causing it to make a leap each time the next state vector is applied. If you are in lockstep, though, this might be no problem.
 

MeeexC

Member
Joined
Nov 19, 2011
Messages
37
Reaction score
21
Points
8
Location
Ulm
What do you mean? Tried to recompile Orb:Connect, or tried to use DefSetStateEx?
I was not able to recompile it. But today I also tried to compile the mfd example and this gave me some issues too. But that worked before, so I have to look at my settings in detail.

Thank you for the advices with DefSetStateEx. I had no idea that this will be that tricky. But this is still the only possibility to influence the vessel state without controlling it, isn't it?
Is it possible to use the playback somehow?
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,842
Reaction score
2,105
Points
203
Location
between the planets
So I have only changed the altitude, distance to base and MJD. Still the training set is too small. So I am looking at the different MFDs so that I can land 6 DG at the same time.
You might want to try to mobilise the community a bit to send in replays. Not sure you'll get much, but it's worth a try.
Also, you could see if your training set is large enough to make the AI land at least a few times successfully, feed those back into the training set and go on recursively from there. Might get rather wonky at some point, of course.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
Thank you for the advices with DefSetStateEx. I had no idea that this will be that tricky. But this is still the only possibility to influence the vessel state without controlling it, isn't it?
Is it possible to use the playback somehow?

The DefSetState and DefSetStateEx functions are intended to be the only way to set it, I think. The scenario snippet trick is a hack IMHO, just a workaround for the buggy function.
Regarding using the playback feature somehow: that's a good question, I don't know. I think you could produce playbacks and then show them, but I don't see how you could use it arbitrarily inside an interactive session. I also don't know how stable the playback feature is regarding time-acc.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
Ok folks, now I feel dumb. I just took a look at the ScnEditor source code to see if there is some different function used for state setting, and low and behold, I found out why the landed state setting is not working with normal state vectors: apparently Martin used a magic number to disable the "arot" field: _V(10,0,0). If you use that number - which makes no sense according to the description of it - DefSetStateEx works as designed, even for landed states (remember that parking brake problem?). No need to do the snippet dance anymore.
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,271
Reaction score
3,244
Points
203
Location
Toulouse
@Face : so we may use this to make landed things like launchpads dead stable even at high time warp ? That would be quite a breakthrough !
 
Top