Project Orbiter economic simulation

[jedidia]

Oh, the undocumented features!! ?‍ How many developers have already gone mad because of this?

 

[Face]

And of course I am not the only one who found this. Jarmo did so not long ago: https://www.orbiter-forum.com/threads/mars-2020-rover-and-mars-helicopter-scout.37153/post-577597

 

[Face]

@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 !

Yes, applying the landed state (in whatever way) should make it dead stable.

 

[N_Molson]

Please please sticky that ; I'm pretty sure that many people did not like O2016 too much because it was a hassle to keep a vessel landed.

Maybe with a small code sample ? Is it possible to apply the landed state in clbkPreStep, so that we could be sure it won't move at all ?

 

[N_Molson]

I made it work ! awesome !

I took the code from Jarmonik linked above, and made minor modifications.

The most challenging part was to find the right coordinates. Those are Polar Coordinates and they are expressed in RADIANS. So here's the procedure :

1) Use a scenario file or the Scenario Editor to put a vessel exactly where you want to go.
2) Pause, so that you'll sure the vessel won't move at all.
3) Open the Scenario Editor.
4) Select your vessel, click "Edit"
5) Click "State Vectors"
6) Switch "Frame" to "ref. equator (rotating)"
7) Switch "Coordinates" to "Polar"
8) Note the "longitude" and "latitude" values, with all the digits, this is important for something like a launchpad.
9) Convert those values from DEG to RAD. You can use a site like Wolfram Alpha for that.
10) Enter those values in RAD in the "v.surf_lng" (longitude) and "v.surf_lat" (latitude) fields of the code sample below.
11) Done ! Your Vessel won't move at all even at max time warp.
12) Be creative, you can do cool stuff like animated surface bases made of .dll modules !

void YOURVESSEL::clbkPreStep(double simt, double simdt, double mjd)
{
    OBJHANDLE h_Planet;
    h_Planet = oapiGetGbodyByName("Earth"); // enter the name of the planet/moon you want
    OBJHANDLE h_launchpad = GetHandle();
    VESSEL *v_launchpad = oapiGetVesselInterface(h_launchpad);

    VESSELSTATUS2 vs;
    memset(&vs, 0, sizeof(vs));
    vs.version = 2;
    vs.rbody = h_Planet;
    vs.status = 1;             // Landed
    vs.arot.x = 10;            // <----- Undocumented feature "command code" to land on touchdown points !! IMPORTANT !!
    vs.surf_lng = 1.9364618;  // example : Wenchang Satellite Center, PRC
    vs.surf_lat = 0.3423356;
    vs.surf_hdg = 0.0;
    v_launchpad->DefSetStateEx(&vs);
}

I spent my night on this... But I learned a lot of things today

Note to admins : please sticky this !

 

[jedidia]

Note to admins : please sticky this !

I think making a dedicated post for it would improve those chances, probably best in the SDK subforum.

 

[MeeexC]

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.

The problem in this case is that I still have to run the playbacks in real time to record the data. I won't be able to avoid doing this myself.

The loop you suggest is dangerous in my approach: the training set follows certain rules, and one of them is to aim for a normal distribution of all inputs. Otherwise, the AI will quickly become overtrained, i.e. this one manoeuvre will be perfectly reproduced, but all the others will become impure. This loop is rather part of a punishment function, if you then want the AI to learn from itself. Then you make it perform a new approach that it has never done before until it does it perfectly. But that is no longer part of the original training set.

For the sake of transparency, I want to use an artificial neural network here. There are certainly other suitable approaches, but I am familiar with ANNs and I want to try something out here.

 

[MeeexC]

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.

That's superb, then I will now try to get my VS2019 working properly and then extend the parser of OrbConnect with a DefSetStateEx function.

I'll also have a look at the ScnEditor, maybe I'll understand it all a bit better then.

Regarding the playback, unfortunately I haven't found any information on how it works exactly.

 

[N_Molson]

I think making a dedicated post for it would improve those chances, probably best in the SDK subforum.

I just sent a detailed post to Ironrain so he can do that.

As soon he does that I'll pull a request for a "Parking Brake MFD", so that people can use that "feature" without having to code themselves.

 

[MeeexC]

Update:
I am currently modifying Orb:Connect to integrate more functions of the OAPI into the parser. Does anyone know if kamaz or any of the previous authors are still active?

Also, a few questions about this:
- Do you see any benefit in giving Orb:Connect an extension in general? A lot of "Get..." functions are in the parser, the "Set..." functions look like less.

- I learned from the ScnEditor that DefSetStateEx is only used in one tab, otherwise there is a separate set function for each editing tab (e.g. SetElements). Would you find it useful to have this too?

- I would also like to integrate all the control options. Which functions would be important for you here?

You might notice that I don't want to say goodbye to my idea of the autopilot, yet ;-) I think a small side project is coming up here, because many lines of code that I write can be used for artificial space traffic as well as for an autopilot.

 

[MeeexC]

So, now I have added a DefSetStateEx function to Orb:Connect.

However, I noticed the following: I undocked from the ISS with a DG and then read out the vessel status via Orb:Connect and directly read it in again. This resulted in an offset between DG and ISS of several meters. Either the accuracy is not sufficient or the 50 ms between read and write is sufficient for that issue. I assume the latter, after all it is as if the DG would stop for 50 ms relative to the earth and the ISS moves on. If this is so, it can be fixed later by extrapolation.
Have I overlooked something else?

EDIT:
If I have some time tomorrow, I will read out a landing manoeuvre on BB, interpolate it and try to read it in relative to the new MJD.

 

[Face]

However, I noticed the following: I undocked from the ISS with a DG and then read out the vessel status via Orb:Connect and directly read it in again. This resulted in an offset between DG and ISS of several meters. Either the accuracy is not sufficient or the 50 ms between read and write is sufficient for that issue. I assume the latter, after all it is as if the DG would stop for 50 ms relative to the earth and the ISS moves on. If this is so, it can be fixed later by extrapolation.
Have I overlooked something else?

That's normal, because state vectors deal with orbital velocities. 50ms with 7km/s is 350m, after all.
What I do in multiplayer systems is to timestamp the state vectors transmitted (with the MJD it was taken at), then calculate the latency, then do RK4 to extrapolate. This reduces the jitter, but is no silver bullet for big latency (e.g. seconds upwards), which you can typically have in TCP-based setups. It is good enough for millisecond ranges, which you can achieve with UDP- or RTP-based setups. Then again the later bring along a whole bunch of other problems, like session initiation due to firewall-problems and packet drop etc.
You could also use elements instead of state vectors if your object is not thrusting. Or you use relative state vectors to get down the speed numbers.

 

[MeeexC]

That's normal, because state vectors deal with orbital velocities. 50ms with 7km/s is 350m, after all.
What I do in multiplayer systems is to timestamp the state vectors transmitted (with the MJD it was taken at), then calculate the latency, then do RK4 to extrapolate. This reduces the jitter, but is no silver bullet for big latency (e.g. seconds upwards), which you can typically have in TCP-based setups. It is good enough for millisecond ranges, which you can achieve with UDP- or RTP-based setups. Then again the later bring along a whole bunch of other problems, like session initiation due to firewall-problems and packet drop etc.
You could also use elements instead of state vectors if your object is not thrusting. Or you use relative state vectors to get down the speed numbers.

Yep, I calculated the same numbers this morning. So it means that everything is actually in place and working as it should.

I realize that in the case of multiplayer in online mode, latency will certainly be a troublemaker. In my case, at some point after developing the base code in Matlab, I will remove the communication over TCP and call the Matlab function from another library (that I will compile when ready). Initially I will now interpolate my data as I am also recording the MJD along with the ship state. Let's see what can be extracted here. Nevertheless, I also thought of building a case structure where the vessel state is only used when needed and when not, the elements are set. But that won't help that much, because in the critical and interesting phases of docking or landing, the thrusters are in action. My only advantage compared to your case is that I don't need to predict the trajectory, I just want to follow it.

 

[MeeexC]

Yesterday I had everything in place. I tried to land "automatically" on BB, but it was as you predicted: the ship jumped around.

Now, on the one hand, I'm trying to compensate for the offsets to get a soft landing.

On the other hand, I'm going to test another approach that was suggested earlier: I will combine the settings Elements, Enginespec, Fuelspec and the orientation of the vessel. But I don't know yet how to set the orientation. Do I need to read Pitch, Bank and Heading and then transform this into vs.arot? I am a bit lost here.

 

[Face]

Do I need to read Pitch, Bank and Heading and then transform this into vs.arot? I am a bit lost here.

You can do a GetStatusEx() to get the arot value from the received VESSELSTATUS2 structure. Keep in mind to reset the structure and set the version to 2 prior to invoking the call, though.

 

[MeeexC]

So, some time has passed!

Unfortunately, I'm very limited in time, because of work at the moment. If I have time, I'd rather take a flight in Orbiter than invest 30 minutes in coding.
Face has already helped me a lot with his answers here to find the right approach. However, I would now have to write a few lines of code and continue testing. Unfortunately, I have to postpone this until I have a few days at a stretch again.