SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[Urwumpe]

Looks like there is no FBW at all around - anyway, that looks like more than just one bug.

I'll take a look at this when working on G3.

Are you already able to file tickets and add new milestones?

 

[STS]

Looks like there is no FBW at all around - anyway, that looks like more than just one bug.

I'll take a look at this when working on G3.

Are you already able to file tickets and add new milestones?

Yeah, I though that FBW was doing bad things, the behavior on the last landing is very strange. When finishing the HAC, for me, I was on profile (maybe a little low), but as almost all the aiming data on the HUD moved to the left for some reason, and was impossible to see, you saw the result.


I still don't have permissions. I write again the username: turryboeing

 

[DaveS]

Yeah, I though that FBW was doing bad things, the behavior on the last landing is very strange. When finishing the HAC, for me, I was on profile (maybe a little low), but as almost all the aiming data on the HUD moved to the left for some reason, and was impossible to see, you saw the result.


I still don't have permissions. I write again the username: turryboeing

Try filing/editing a ticket now.

 

[STS]

Try filing/editing a ticket now.

Now I can, new options appeared for me.


Later on I will create/admin some, as posted earlier.


Thanks!!

---------- Post added at 04:54 PM ---------- Previous post was at 12:41 PM ----------

Ok, in case somebody else doesn´t know, on Sourceforge, milestones cannot have double quotes ( " " ) on the title... :facepalm::facepalm:


I edited some tickets and created some.

 

[Urwumpe]

Can you be a bit more specific on the aerodynamic / FBW problems? I just tried it using the keyboard, it was just a tiny bit "heavy" in its reaction... its no problem landing right on spot using the keyboard, but there is only little control authority left when you follow the director.

Also, it felt like roll rates are absurdly low for FBW, maybe a conversion problem from degrees to radians or back.

---------- Post added at 20:15 ---------- Previous post was at 20:05 ----------

Does somebody have the reference documents that GLS used for the reentry guidance? The code is effectively uncommented, I don't feel like I want to reverse engineer it.

 

[Marpilot]

Hello,
as I am flying default Atlantis for 3 weeks now and I just installed SSU can I ask if aerodynamics in atmosphere are the same? TAEM and approach - landing.
Thanks

 

[DaveS]

Hello,
as I am flying default Atlantis for 3 weeks now and I just installed SSU can I ask if aerodynamics in atmosphere are the same? TAEM and approach - landing.
Thanks

They're nowhere anywhere near the same. SSU isn't for the faint of heart. It requires knowing the systems very intimately, so I'd stay away from it unless you're ready to spend alot of time reading up on how everything fits together.


I'm saying this to spare both you and us alot of time of going back and forth as I can tell you're very new around here and to Orbiter in general.

---------- Post added at 10:24 PM ---------- Previous post was at 10:23 PM ----------

Does somebody have the reference documents that GLS used for the reentry guidance? The code is effectively uncommented, I don't feel like I want to reverse engineer it.

I have no idea which documents went into the making of the entry guidance.

 

[STS]

Can you be a bit more specific on the aerodynamic / FBW problems? I just tried it using the keyboard, it was just a tiny bit "heavy" in its reaction... its no problem landing right on spot using the keyboard, but there is only little control authority left when you follow the director.

Also, it felt like roll rates are absurdly low for FBW, maybe a conversion problem from degrees to radians or back.

Well, I took the STA a little bit (tried more landings) and I think I understand better what could be going on. I managed to land more times, with more success rate on the EDW 22 TAEM than on the FMI33 TAEM scenarios. If you miss the director just a little bit, you are dead. Margin for correction is very low. (I understand this (more realism?) but at the same time I don´t (FBW playing tricks on the one that is flying?))



What I mostly find unconfortable is that, as you say, roll rates are very low. Pitch responds OK, bot roll is very weird. Just made an ugly landing at FMI 33, and I noted that the rudder got stuck on 10% to one side (i don´t remember if right or left, I think right) after I finished the HAC. Yeah, I was a little bit off the centerline/"localizer", but jesus christ, with the rudder stuck like that it´s obvious that my energy went to hell, and the data of the HUD to one side, making it very unconfortable. I think this also happened during the last landing I showed you on the video of the other day, that looked like a strong crosswind.


Also, I can´t switch the speedbrake to manual (so that I can get energy), and the rudder/NWS doesn´t respond to my inputs. (I checked my joystick with the deltaglider and there the rudder responds OK)

 

[Urwumpe]

Hello,
as I am flying default Atlantis for 3 weeks now and I just installed SSU can I ask if aerodynamics in atmosphere are the same? TAEM and approach - landing.
Thanks

Additionally to what DaveS said: It is also uncomplete and often terribly broken. It can be very frustrating, if you are not ready for the experience of a flying construction site. Better stick to NASSP, if you want complexity, but not expect it to be your worst enemy.

---------- Post added at 23:13 ---------- Previous post was at 23:06 ----------

What I mostly find unconfortable is that, as you say, roll rates are very low. Pitch responds OK, bot roll is very weird. Just made an ugly landing at FMI 33, and I noted that the rudder got stuck on 10% to one side (i don´t remember if right or left, I think right) after I finished the HAC. Yeah, I was a little bit off the centerline/"localizer", but jesus christ, with the rudder stuck like that it´s obvious that my energy went to hell, and the data of the HUD to one side, making it very unconfortable. I think this also happened during the last landing I showed you on the video of the other day, that looked like a strong crosswind.

Yeah, that could be a oversaturated I-controller. No idea though why, right now it looks a lot like the flow charts of the control loops.

 

[STS]

Thanks for reviewing this. I´ll keep test-flying and make you know of my findings.

---------- Post added at 11:36 PM ---------- Previous post was at 11:18 PM ----------

I think I found something.
In this approach I moved away from the centerline on purpose, and then tried to follow the diamond.


Look at what the diamond does (I just chase it, as I am supposed to do).

So it looks like something is wrong with it.

 

[Urwumpe]

Yeah - luckily its a sim. I wonder where the cause of the behaviour is, I still need to understand how the functions are stitched together now.

 

[DaveS]

I can tell now that clbkVCMouseEvent is not called for it. Is there a maximum limit to the number of event areas?

---------- Post added at 22:55 ---------- Previous post was at 22:31 ----------

Much worse, RegisterVC is also never called for it in the test scenario. So there is no region to call.

---------- Post added at 23:37 ---------- Previous post was at 22:55 ----------

Ok, RegisterVC is called now, like any other panel as well. Changed the order of the panel groups to see if a hard limit in Orbiter is a problem, but it had no effect yet.

---------- Post added 15th May 2020 at 00:01 ---------- Previous post was 14th May 2020 at 23:37 ----------

OK, the bug is not caused by the area IDs. Using an enum to define them does not change the behavior.

---------- Post added at 00:15 ---------- Previous post was at 00:01 ----------

Changing the order, how the Areas are registered, has no effect at all. When A8 is called before A7U, A7U registers its panel area, A8 doesn't.

---------- Post added at 00:24 ---------- Previous post was at 00:15 ----------

After flipping the coordinates of the area, the panel A8 reacts to events again, but the switch positions are now off.


Could this be related to D3D9Client?

Any updates? Or does it look like a D3D9Client bug?

 

[Urwumpe]

Any updates? Or does it look like a D3D9Client bug?

No D3DClient bug, this function is part of Orbiters core.



Since flipping the corners means, the switches all need new mouse event coordinates as well and some controls might not work properly afterwards when the coordinate system is flipped as well, I'll keep on putting priority on the JSON input files for the VC.



It would take a new vessel with simpler VC to be sure this is really an orbiter bug and not a result of doing too much math late at night.

---------- Post added at 10:36 ---------- Previous post was at 00:01 ----------

After some research on the NTRS: The maximum normalized roll rate during TAEM and A/L is 1.25°/s, and 1.4°/s during Entry. That is slow, but faster as we observe now.

Oh, and the guidance functions are from the C level requirements for mission control. That explains the individual executive for each phase, instead of using the global GNC Executive process (GEXEC) and the Dispatcher Table.

 

[EstebanDF]

I also cannot fly the SSU properly with my joystick, the rudder does not work at all, it only work with the keys K / L.

 

[DaveS]

I also cannot fly the SSU properly with my joystick, the rudder does not work at all, it only work with the keys K / L.

That's because the rudder is actuated by using actual rudder pedals, not the yaw channel of the joystick. The K/L keys simulate these. So everything is working properly.

 

[STS]

That's because the rudder is actuated by using actual rudder pedals, not the yaw channel of the joystick. The K/L keys simulate these. So everything is working properly.

I don´t understand this.
How is the rudder not supported by a joystick axis, wich is proportional, but with keyboard inputs, wich are on/off? Also, being keyboard inputs, doesn´t it make it unconfortable for the user who expects to operate the rudder with his joystick, as with any vehicle?

However, it´s good information that can help me and @EstebanDF to perform landings. But I think this should be changed.

 

[DaveS]

I don´t understand this.
How is the rudder not supported by a joystick axis, wich is proportional, but with keyboard inputs, wich are on/off? Also, being keyboard inputs, doesn´t it make it unconfortable for the user who expects to operate the rudder with his joystick, as with any vehicle?

However, it´s good information that can help me and @EstebanDF to perform landings. But I think this should be changed.

It shouldn't. The attached screenshot is from the GNC section of the SCOM on the Rudder Pedal Transducer Assembly (RPTA). The key part is the first part:


"The rudder pedals command orbiter acceleration in yaw by positioning the rudder during atmospheric flight."

 

[STS]

It shouldn't. The attached screenshot is from the GNC section of the SCOM on the Rudder Pedal Transducer Assembly (RPTA). The key part is the first part:


"The rudder pedals command orbiter acceleration in yaw by positioning the rudder during atmospheric flight."

I understand now, thanks for the explanation.

 

[EstebanDF]

It shouldn't. The attached screenshot is from the GNC section of the SCOM on the Rudder Pedal Transducer Assembly (RPTA). The key part is the first part:


"The rudder pedals command orbiter acceleration in yaw by positioning the rudder during atmospheric flight."

Great, that's very good to know, will keep training my landings Thanks a lot !!

 

[Urwumpe]

It shouldn't. The attached screenshot is from the GNC section of the SCOM on the Rudder Pedal Transducer Assembly (RPTA). The key part is the first part:


"The rudder pedals command orbiter acceleration in yaw by positioning the rudder during atmospheric flight."

It would be nicer if we could also support rudder pedals. Is there a successor to the FBW plugin around? I have rudder pedals available for testing because of DCS:A-10C...