SDK Question TCP Comunication at Orbiter

[laura]

Hello everyone!!

I have just started a Project which means to use Orbiter as a real time visualization tool.

By far, I have made some examples on Orb:Connect and I have got a TCP communication function at Matlab... So, next step will be linking both server and client. I am new at this staff so I would really appreciate some help!!

And, DefStatus would be perfect for sending position and attitude data, is that right?


A lot of Reading but not many results got by now!

Thank you!

 

[laura]

Going on...

It is been a while since I started this Project.

Till now, I have been to set the connection between Matlab and Orbiter (once I have finished I pretend to explain the whole proccess in a post).

I am now working on the Orbiter module based on ScnEditor in order to set the attitude, position and velocity values.

Taking as template, the basic Rcontrol module this is the code which is not working:

// Frame update
void Control::clbkPreStep(double simt, double simdt, double mjd)
{
// Simulation time
double syst = oapiGetSysTime();

// Vessel data
g_Param.vessel = oapiGetFocusInterface();
// Set yaw attitude at a certain time
if (syst > 25 && syst <50)
{
VECTOR3 arot;
g_Param.vessel->GetGlobalOrientation(arot); // Read
arot.data[2] = 40 * RAD; // Set
g_Param.vessel->SetGlobalOrientation(arot); // Refresh
sprintf(oapiDebugString(), " time %.2f, alt %.2f, yaw %.2f", syst, alt, arot.data[2]);
}
}

I can properly read the attitude data which is displayed on the current session, but I am not able to change it... Could you please help me with this issue??

Thank you guys.

 

[Face]

I have a bit experience with Orbiter and TCP connections, but I can't answer your questions because they appear to be so unspecific.

DefSetStateEx and SetGlobalOrientation work just fine AFAICT. I guess you'll have to show some more code (perhaps a github repo?) in order to get more help.

 

[jarmonik]

I don't have much experience with SetGlobalOrientation() since it's pretty rare in a typical Orbiter applications.

But since you are calling it from clbkPreStep() it might be possible that Orbiter's physics core would overwrite your call to SetGlobalOrientation(). So, would be a worth to test calling it from some other location. There was a similar anomaly detected with some other input function to the Orbiter and a thread about it posted a few months ago. I'll try to find it...

---------- Post added at 23:59 ---------- Previous post was at 23:44 ----------

It's not exactly as I remembered but could help a bit. http://www.orbiter-forum.com/showthread.php?p=554040&postcount=8

---------- Post added 01-04-17 at 00:24 ---------- Previous post was 31-03-17 at 23:59 ----------

Just one more thing. Are you using Orbiter 2016 or 2010-P1 ?

---------- Post added at 04:53 ---------- Previous post was at 00:24 ----------

void Control::clbkPreStep(double simt, double simdt, double mjd)
{
// Vessel data
g_Param.vessel = oapiGetFocusInterface();

VECTOR3 arot;
g_Param.vessel->GetGlobalOrientation(arot); // Read
arot.data[2] = 40 * RAD; // Set
g_Param.vessel->SetGlobalOrientation(arot); // Refresh
}

I just tried the code and couldn't find anything wrong. It will set the third angle to 40 deg in Orbiter 2016.

 

[laura]

Focusing on the problem

Well, I will have a look at Github and try to post the code (I have heard before but never gone in),

But I will also try to focus the project´s stage at which I am right now.

As I mentioned before, I am able to set a proper connection via TCP IP connection between Matlab and Orbiter (based on Orb:Connect) and I have checked to be receiving the string data across the oapiWriteLog() instruction.

So now, I was trying to code a previous step to the final chain in which I would be able to change the attitude and position data at a certain time (overloading Orbiter core and similar to ScnEditor module).

Reading through the API reference, I found that some structures as opcOpenRenderViewport have got old in new Orbiter versions and they must be replaced by the clbkSimulationStart...

And that makes me think that may this changes are for Orbiter2016? Because I am developing the addon for Orbiter2010...

Thank you all!!

---------- Post added at 09:16 AM ---------- Previous post was at 09:12 AM ----------

On the other side, it is quite weird because writing the set value of the third Euler angle makes sense with the given intruction... although no change is seen on the vessel attitude.

 

[Face]

I don't have much experience with SetGlobalOrientation() since it's pretty rare in a typical Orbiter applications.

I've used it once in the [ame="http://www.orbithangar.com/searchid.php?ID=2609"]JumpDriveMFD[/ame] code to implement a "fleet command" in order to put all vessels into the same direction (/Orbitersdk/samples/JumpDriveMFD/JumpDrive.cpp, line 179). There it worked flawlessly, but of course that's some time ago now, and it was a different call stack (from MFD button action).

I think we do not see the whole picture here, so we can't really diagnose the problem. Thus my call for more information above.

---------- Post added at 11:33 ---------- Previous post was at 11:20 ----------

As I mentioned before, I am able to set a proper connection via TCP IP connection between Matlab and Orbiter (based on Orb:Connect) and I have checked to be receiving the string data across the oapiWriteLog() instruction.

So now, I was trying to code a previous step to the final chain in which I would be able to change the attitude and position data at a certain time (overloading Orbiter core and similar to ScnEditor module).

Well, I never used Orb:Connect, but OMP transmits state vectors via UDP (and sporadically TCP) from one machine to another, and using DefSetStateEx works perfectly for that (i.e. setting position and attitude). I'm using the standard WinSocket API directly, though.

 

[laura]

I have now changed the launcher on which I was trying to set attitude (from Vega add-on to Atlantis demo) and while in Vega a change can be appreciated at attitude, it doesnt keep the value. However, Atlantis demo is perfectly working...

Could it be related to the configuration?

 

[Face]

I have now changed the launcher on which I was trying to set attitude (from Vega add-on to Atlantis demo) and while in Vega a change can be appreciated at attitude, it doesnt keep the value. However, Atlantis demo is perfectly working...

Could it be related to the configuration?

Do you have a link handy for the Vega add-on? It could be that the vessel in question sets its attitude in its own code, perhaps overwriting your settings.

 

[Urwumpe]

Do you have a link handy for the Vega add-on? It could be that the vessel in question sets its attitude in its own code, perhaps overwriting your settings.

Or she applies the change to the wrong stage in a vessel made of attached stages, this would be my first guess there.

 

[Face]

Or she applies the change to the wrong stage in a vessel made of attached stages, this would be my first guess there.

Good point. That's possible, too.

The Vega add-ons I've found on OHM use multistage, so I guess it is a Multistage2015 scenario. The code for the later is available, and indeed sets the attitude according to an autopilot implementation. Since the code snippet we have seen shows a timed forcing of the attitude values, it could well be that the observed result is "while in Vega a change can be appreciated at attitude, it doesnt keep the value", because the autopilot promptly overrides it after the forcing period.

All speculation, of course.

 

[Urwumpe]

So, the solution could maybe be editing the multistage ini file and erase the autopilot definition there, so this code is not executed?

 

[Face]

So, the solution could maybe be editing the multistage ini file and erase the autopilot definition there, so this code is not executed?

Perhaps. From the quick glance at Multistage2015's code I think there are maybe 2 AP modes in action, one "vinka-compatible", one with PEG.
It is really hard to say with the currently available information. If I'd known the Vega add-on in question, I could try it out for myself. Jarmonik already tried the essential API-call and found nothing suspicious.

A scenario file together with a list of the involved add-ons (with links) would help to clear it up a little.

 

[fred18]

In both vinka's and ms2015 AP is of course not mandatory. If it's overriding the command coming it's enough to press p and it will stop, therefore letting the user do whatever he wants. Anyway in ms2015 mfd is possible to monitor inputs as well, if that's what's used it could be helpful

 

[martins]

The Vega add-ons I've found on OHM use multistage, so I guess it is a Multistage2015 scenario. The code for the later is available, and indeed sets the attitude according to an autopilot implementation.

Sorry for going off-topic, but does anybody know why the autopilot sets the attitude directly, rather than operating the vessel systems and allowing Orbiter to work out the resulting vessel state?

If there is a limitation in Orbiter's physics engine that requires this bypass, I'd be quite keen to hear about it.

 

[fred18]

Sorry for going off-topic, but does anybody know why the autopilot sets the attitude directly, rather than operating the vessel systems and allowing Orbiter to work out the resulting vessel state?

If there is a limitation in Orbiter's physics engine that requires this bypass, I'd be quite keen to hear about it.

Multistage2015 acts on attitude thrusters, no issue for me on that side

 

[Face]

Sorry for going off-topic, but does anybody know why the autopilot sets the attitude directly, rather than operating the vessel systems and allowing Orbiter to work out the resulting vessel state?

If there is a limitation in Orbiter's physics engine that requires this bypass, I'd be quite keen to hear about it.

It was not meant to say that it does SetGlobalOrientation() or somesuch directly. The code has an Attitude(pitch,roll,heading,pitchrate,rollrate,yawrate) function that gets called in the timestep while the AP is running. It operates via SetAttitudeRotLevel() on the axis.
For me, that's good enough for an autopilot, but of course it can result in what the OP described, especially if the rate is high enough and the forced attitude setting is time limited.

As I said before, it is all speculation, because we really don't know what is involved, what is observed exactly, and what is expected behavior. It was also only a guess that fred's Multistage is involved. Could be the old vinka module, too.

 

[laura]

Here it is the link: http://francophone.dansteph.com/?page=addon&id=218

you also need to download the vega launcher addon and Kourou global part 1 and 2. It is all explained at that link.

 

[Face]

Here it is the link: http://francophone.dansteph.com/?page=addon&id=218

you also need to download the vega launcher addon and Kourou global part 1 and 2. It is all explained at that link.

Thanks. What scenario did you use?

 

[laura]

you were right...

As you previously mentioned, it was due to the guidance file. After deleting the instructutions related to pitch and roll control, it worked perfectly.

Thank you all and sorry for the late answer.