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

[DaveS]

---------- Post added at 21:44 ---------- Previous post was at 21:38 ----------

And can you put "Support 1024 x 1024 MFD resolution" to our TODO list? Where are we currently tracking the issues?

Same place we always have: https://sourceforge.net/p/shuttleultra/tickets/


And ticket created: https://sourceforge.net/p/shuttleultra/tickets/208/

 

[n72.75]

I've been going back and forth about whether or not to write this, and just share my opinion in a place where it's probably not needed, but here goes. I've never developed for SSU, and the last time I had it installed was circa 2013

I given the amount of time and effort that has gone into this project over the years, I think it would be extremely unfortunate if SSU died on the vine. Even with the short(relatively) history of OF the shuttle has gone from being a fact of every day spaceflight to a relic of the past.

Given the original commitment to systems it was always my view that SSU would be similar in NASSP in terms of fidelity and comprehensiveness (at least where NASSP is aiming). I think both of these projects have the rather unique distinction of being the only accessible free way there is to simulate, with any degree of accuracy, how the these space craft behaved in use. That's not an insignificant fact, and it's probably not inappropriate to think of these projects as more on the side of historical preservation rather than like a game.

I don't have the time to develop for SSU. I've recently started working on small projects for NASSP, and I barely have time for that, and in the next few years, with kids and all, I'll have even less, so i understand where people are coming from on that. If you want to attract new younger programmers to(which you need to), you need to put a face on the project. Explain what you're doing, show off new features, etc. Take a page out of the book of a project like Beyond Skyrim. Dont tell me there aren't thousands or at least hundreds of college students and high school kids with C++ experience and a passion for spaceflight. These are the people that have the time and the drive to help you, and you only need, maybe 5 of them. But almost no one is going to join if to even be interested they need to read through 10 years of forum posts (they will have to read through them at some point, but this can't be your only marketing strategy). My advice: it's 2020, make a few video essays on the subject.

Regarding the development, you guys need a new roadmap. What systems are implimented, that ones are partially implemented, what needs to be, what isn't within the scope of the project.

I'm probably missing something and definitely stepping on toes by asking this, but why all the mesh issues? Have a development phase where you fix the mesh issues and get it to where you want it, and then dont touch it while you work on code. Also, how are changes that break the whole thing getting added? Test, confirm no issues, agree, then merge.

If I've hurt anyone's feelings, I'm very sorry. I want this to succeed, and I want people to be happy. If I can help (in a way that isn't 20 hours of coding a week) let me know.

 

[Urwumpe]

Well, I am still returning to development after a long hiatus, so, what kind of question would you want to get answered about developing SSU first?

---------- Post added at 21:17 ---------- Previous post was at 20:00 ----------

I'm probably missing something and definitely stepping on toes by asking this, but why all the mesh issues? Have a development phase where you fix the mesh issues and get it to where you want it, and then dont touch it while you work on code. Also, how are changes that break the whole thing getting added? Test, confirm no issues, agree, then merge.

That is what we tried already, actually. Sadly, we have different concepts of time. :lol:


I think one problem for separating mesh development and code development is, that those who work on the meshes are rarely able to compile the sources and test the meshes in Orbiter. Maybe it would work better, if changing meshes and animations would no longer depend on writing C++ code.

 

[DaveS]

Well, I am still returning to development after a long hiatus, so, what kind of question would you want to get answered about developing SSU first?

---------- Post added at 21:17 ---------- Previous post was at 20:00 ----------




That is what we tried already, actually. Sadly, we have different concepts of time. :lol:


I think one problem for separating mesh development and code development is, that those who work on the meshes are rarely able to compile the sources and test the meshes in Orbiter. Maybe it would work better, if changing meshes and animations would no longer depend on writing C++ code.

We have already externalized the aero properties, why not the animations as well?

 

[Urwumpe]

We have already externalized the aero properties, why not the animations as well?

Well, it is a bit more complex to implement. A flat key-value file would be relatively easy to do (Still a lot of work), but would only to allow changing the properties of the animations (vectors, meshgroups), but not their structure.

 

[Urwumpe]

Well, the easiest approach is to load up the attached scenario Then press Ctrl-A to switch over control to the RMS. Then using the numpad controls yaw the EE past the singularity at Y/YAW +270.0 (Numpad 6) and back to +0.0 (Numpad 4). Now just repeat this for a few minutes. Now the EE and the MPLM should have diverged attitudes and there's no way the EE should still have a firm grapple of the MPLM.

Did not observe this behaviour after removing the additional dummy animation between EE and attachment point.



But now the RMS stops responding after entering a REACH LIMIT caution and can't be moved out of the limit.


Ah, now I got it, after passing through this point, it needs not much discussion:

 

[Urwumpe]

OK, after a few repetitions of the motion, the following happens to the direction vectors:

8.927682 RMS EE: +33.4 +77.3 -84.4 -94.0 +16.2 +54.5 -> (-0.000052, -1.000000, 0.000537) * (-0.000306, 0.999463, -1.000537) = -1.000000
34.250367 RMS EE: +23.2 +87.0 -103.1 -27.0 -59.7 +70.6 -> (0.999943, -0.012523, 0.000538) * (-0.999409, 0.012162, -1.000553) = -1.000044
39.437119 RMS EE: +22.7 +87.1 -106.8  -1.3 -65.9 +90.2 -> (0.981501, 0.191589, 0.000541) * (-0.980901, -0.191834, -1.000560) = -1.000051
45.824838 RMS EE: +23.4 +86.8 -101.8 -34.1 -56.5 +65.6 -> (0.995948, -0.090258, 0.000538) * (-0.995445, 0.089857, -1.000562) = -1.000060
50.366608 RMS EE: +22.9 +87.1 -104.9 -16.1 -63.1 +78.7 -> (0.996373, 0.085456, 0.000540) * (-0.995805, -0.085764, -1.000565) = -1.000063
54.595370 RMS EE: +23.4 +86.8 -101.8 -34.3 -56.4 +65.4 -> (0.995784, -0.092084, 0.000538) * (-0.995281, 0.091683, -1.000566) = -1.000066
76.155517 RMS EE: +33.4 +77.3 -84.4 -94.0 +16.2 +54.5 -> (-0.001437, -1.000053, 0.000515) * (0.001086, 0.999539, -1.000557) = -1.000109
114.505746 RMS EE: +23.2 +87.0 -103.0 -27.7 -59.4 +70.0 -> (0.999877, -0.019966, 0.000553) * (-0.999332, 0.019581, -1.000607) = -1.000153
118.117410 RMS EE: +23.0 +87.1 -104.0 -21.9 -61.4 +74.3 -> (0.999429, 0.035991, 0.000554) * (-0.998862, -0.036347, -1.000608) = -1.000154
122.776130 RMS EE: +23.2 +87.0 -103.1 -27.2 -59.6 +70.4 -> (0.999976, -0.014186, 0.000553) * (-0.999429, 0.013804, -1.000608) = -1.000154
129.400508 RMS EE: +22.6 +85.9 -109.4 +27.4 -67.4 +113.1 -> (0.933643, 0.358435, 0.000558) * (-0.932984, -0.358594, -1.000623) = -1.000165
136.400391 RMS EE: +23.2 +87.0 -103.1 -27.4 -59.5 +70.2 -> (0.999943, -0.017042, 0.000554) * (-0.999395, 0.016659, -1.000628) = -1.000176
138.488201 RMS EE: +23.2 +87.0 -103.2 -26.8 -59.7 +70.7 -> (1.000032, -0.010559, 0.000554) * (-0.999482, 0.010180, -1.000628) = -1.000176
159.543068 RMS EE: +33.4 +77.3 -84.4 -94.0 +16.2 +54.5 -> (-0.000631, -1.000110, 0.000502) * (0.000295, 0.999609, -1.000591) = -1.000222

Looks like some residuals are accumulating in the vertex array. The scalar product between two orthogonal vectors is increasing in magnitude when moving past the singularity ==> The vectors are no longer orthogonal

---------- Post added at 22:10 ---------- Previous post was at 22:04 ----------

The angle between the direction vectors does not change over time, only during motion.

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

So, that is what you get if you try to do vector math after many years of dumbing down with PLM service. orthogonal means zero. And it is zero.

28.294684 RMS EE: +24.1 +86.3 -99.2 -46.1 -48.9 +58.0 -> (0.966777, -0.255695, 0.000536) [1.000019] * (0.000427, -0.000480, -1.000010) [1.000010] = -0.000000
32.738585 RMS EE: +23.1 +87.0 -103.4 -25.7 -60.1 +71.5 -> (1.000021, 0.000405, 0.000539) [1.000022] * (0.000540, -0.000356, -1.000012) [1.000012] = -0.000000
37.016074 RMS EE: +22.6 +86.8 -108.0  +9.7 -67.0 +98.9 -> (0.965844, 0.259229, 0.000543) [1.000027] * (0.000617, -0.000205, -1.000020) [1.000021] = -0.000000
42.126458 RMS EE: +23.1 +87.0 -103.4 -25.5 -60.2 +71.7 -> (1.000028, 0.002670, 0.000540) [1.000032] * (0.000541, -0.000354, -1.000028) [1.000028] = -0.000000
46.291940 RMS EE: +24.2 +86.2 -99.1 -46.6 -48.6 +57.7 -> (0.964828, -0.263014, 0.000537) [1.000035] * (0.000425, -0.000481, -1.000030) [1.000030] = -0.000000
51.021714 RMS EE: +23.1 +87.0 -103.3 -26.1 -60.0 +71.2 -> (1.000032, -0.003201, 0.000540) [1.000038] * (0.000538, -0.000357, -1.000034) [1.000034] = -0.000000
55.480138 RMS EE: +22.6 +86.7 -108.0 +10.5 -67.0 +99.6 -> (0.964623, 0.263795, 0.000541) [1.000043] * (0.000617, -0.000203, -1.000040) [1.000040] = -0.000000
60.443861 RMS EE: +23.1 +87.0 -103.5 -25.0 -60.4 +72.1 -> (1.000019, 0.007513, 0.000540) [1.000048] * (0.000543, -0.000351, -1.000047) [1.000047] = -0.000000
65.102753 RMS EE: +24.2 +86.3 -99.2 -46.5 -48.7 +57.8 -> (0.965231, -0.261593, 0.000538) [1.000051] * (0.000428, -0.000479, -1.000051) [1.000051] = -0.000000
69.484514 RMS EE: +23.2 +87.0 -103.2 -26.5 -59.9 +70.9 -> (1.000026, -0.007355, 0.000540) [1.000054] * (0.000537, -0.000359, -1.000054) [1.000054] = -0.000000
75.059949 RMS EE: +22.7 +86.8 -107.9  +9.3 -66.9 +98.6 -> (0.966578, 0.256600, 0.000540) [1.000058] * (0.000614, -0.000209, -1.000061) [1.000061] = -0.000000
79.239261 RMS EE: +23.1 +87.0 -103.4 -25.7 -60.2 +71.5 -> (1.000062, 0.000512, 0.000540) [1.000063] * (0.000540, -0.000354, -1.000069) [1.000069] = -0.000000
85.171806 RMS EE: +24.2 +86.3 -99.2 -46.1 -48.9 +58.0 -> (0.966780, -0.255868, 0.000539) [1.000066] * (0.000432, -0.000475, -1.000071) [1.000071] = -0.000000
93.587977 RMS EE: +22.6 +86.7 -108.2 +11.9 -67.1 +100.7 -> (0.962357, 0.272062, 0.000538) [1.000075] * (0.000616, -0.000202, -1.000081) [1.000081] = -0.000000
101.251451 RMS EE: +24.2 +86.3 -99.2 -46.3 -48.8 +57.9 -> (0.965925, -0.259145, 0.000540) [1.000083] * (0.000432, -0.000474, -1.000091) [1.000091] = -0.000000
124.680349 RMS EE: +33.4 +77.3 -84.4 -94.0 +16.2 +54.5 -> (-0.000737, -1.000101, 0.000501) [1.000101] * (-0.000330, -0.000501, -1.000101) [1.000102] = -0.000000

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

Interesting though, the length of the vectors is increasing with every motion. Can somebody observe the same when using vertex arrays in animations?

---------- Post added at 22:49 ---------- Previous post was at 22:32 ----------

The bug seems to happen only inside Orbiters core, there is no manipulation of the data from within SSU. I also can't blame Orbiter there - the errors seem to come up from the incremental change to the vectors by multiplying them with a small transformation matrix.

It is also not related to the singularity as suspected, it only requires a large enough motion. A +/- 30° motion past the singularity has no bigger effect as a +/- 30° motion somewhere else.


I'd say, we need a custom forward kinematics solution there now.

 

[Donamy]

SiameseCat fixed it somehow in the SSRMS he did for the Canadarm2. Don't know what he did, but the animation is a little jittery while in motion. If you exit out of Orbiter, and restart the current scenario. The orientation corrects itself with the SSU RMS.

 

[Urwumpe]

SiameseCat fixed it somehow in the SSRMS he did for the Canadarm2. Don't know what he did, but the animation is a little jittery while in motion. If you exit out of Orbiter, and restart the current scenario. The orientation corrects itself with the SSU RMS.

Yes, because the transformation matrix is much more different to the unity matrix and only applied once. During motion, the matrix should be a diagonal of almost ones with almost zeros in the remaining matrix, which should be prone to rounding errors.



I don't think the motion has to be jittery, but I would need to do some research first before I can replace the vertex array code with a forward kinematics solution.

---------- Post added 6th May 2020 at 00:04 ---------- Previous post was 5th May 2020 at 23:09 ----------

OK, the SM functions seem to be completely missing in DPS, just checked through all of it. No SM SPEC 94 to 97 for having a second view on the PDRS.

 

[DaveS]

---------- Post added 6th May 2020 at 00:04 ---------- Previous post was 5th May 2020 at 23:09 ----------

OK, the SM functions seem to be completely missing in DPS, just checked through all of it. No SM SPEC 94 to 97 for having a second view on the PDRS.

If you mean in our DPS implementation, then that's correct. We've never had any SM functionality at all, just GNC. That explains why the Ku band antenna is half-dead at the moment, we don't have the SM 2011 software used to drive it when in COMM mode. So when in COMM mode, it doesn't do anything.

 

[Urwumpe]

If you mean in our DPS implementation, then that's correct. We've never had any SM functionality at all, just GNC. That explains why the Ku band antenna is half-dead at the moment, we don't have the SM 2011 software used to drive it when in COMM mode. So when in COMM mode, it doesn't do anything.

Yes, I thought we had faked it somewhere, but no, was never done. I'll look at this after fixing the RMS, just saw the SimpleGPCSubsystem implementation and got a bad headache.



I also wanted to have a proper transition to a new memory config after MM106 by showing the GPC MEMORY screen with major function "000" while the GPCs are processing system software only and load the new memory config.



This should take a few seconds in the real DPS, even the solid state MMUs have to pump the few hundred KBs of data with lots of redundancy and overhead through a 1 MBit/s bus to all GPCs.

 

[jarmonik]

Well, the easiest approach is to load up the attached scenario Then press Ctrl-A to switch over control to the RMS. Then using the numpad controls yaw the EE past the singularity at Y/YAW +270.0 (Numpad 6) and back to +0.0 (Numpad 4). Now just repeat this for a few minutes. Now the EE and the MPLM should have diverged attitudes and there's no way the EE should still have a firm grapple of the MPLM.

I can reproduce the issue and the MPLM will snap in place when saving and reloading the scenario. It looks like the robotic arm is in a right place but the payload is shifting. Due to way the animations are made there shouldn't exists any singularities. It looks like error accumulation over time since in the Orbiter animations are incremental not working in absolute basis. So, a previous animation state is incremented by small amount to move to the next frame. This is mostly because we had a software vertex processing in the past. Or it could be due to some timing error (race condition). So, we what two parallel incremental systems those should work in sync but for some reason at-least one is drifting from where it's supposed to be.

Can someone confirm if the robotic arm alone retains it's position during refresh (i.e. save - reload) it doesn't drift like the payload ?

We have GetMatrix() function in D3D9 that would bypass the problem. It would allow to use the same matrix for mesh animation and attachment point positioning. We can alter the animation to work in absolute basis in D3D9 but there is nothing we can do for the attachment point transformations.

 

[DaveS]

Can someone confirm if the robotic arm alone retains it's position during refresh (i.e. save - reload) it doesn't drift like the payload ?

The arm itself is fine, it doesn't drift. It's the attachment point that diverges from where the EE is physically. The RMS position/attitude is solid as indicated by the LED readouts on A8U. Only save/load issue related to the RMS is this one: https://sourceforge.net/p/shuttleultra/tickets/207/

 

[jarmonik]

The bug seems to happen only inside Orbiters core, there is no manipulation of the data from within SSU. I also can't blame Orbiter there - the errors seem to come up from the incremental change to the vectors by multiplying them with a small transformation matrix.

Yes, precisely that. We might be able to remove the "small transformation matrix" but just for the animations vertices in D3D9.

---------- Post added at 05:36 ---------- Previous post was at 05:29 ----------

The arm itself is fine, it doesn't drift. It's the attachment point that diverges from where the EE is physically. The RMS position/attitude is solid as indicated by the LED readouts on A8U. Only save/load issue related to the RMS is this one: https://sourceforge.net/p/shuttleultra/tickets/207/

I would assume that's the data fed to Orbiter from SSU. So, it's not necessary the real attitude of the actual visible mesh which might drift due to small errors in the math. I didn't detect any visible drifting during testing. GetMatrix() function would return the real actual orientation.

---------- Post added at 05:50 ---------- Previous post was at 05:36 ----------

I don't think the motion has to be jittery, but I would need to do some research first before I can replace the vertex array code with a forward kinematics solution.

The code that does that exists on a client side (D3D9) VVessel.cpp


void vVessel::AnimateComponent (ANIMATIONCOMP *comp, const D3DXMATRIX &T)
{
}

 

[Urwumpe]

Yes, precisely that. We might be able to remove the "small transformation matrix" but just for the animations vertices in D3D9.

I think I can do that better with a custom solution... I used to have a big blue robotics book somewhere in my library, so I would just need at most 12 calls of trigonometric functions and 12 linear combinations...

 

[jarmonik]

I have changed the animations to work in absolute basis instead of being incremental. Implementation is a bit tricky but it could work. Here's a build for testing...


The binary is for Orbiter Beta.

 

[DaveS]

I have changed the animations to work in absolute basis instead of being incremental. Implementation is a bit tricky but it could work. Here's a build for testing...


The binary is for Orbiter Beta.

Tested it using the same technique for reproducing the singularity bug and no problems this time. After yawing the EE through the 270° singularity for 10 minutes consistently, the there's no deviation between the EE itself and it's attachment point at all. I'd say it has been dealt with, at least in D3D9Client.

 

[Urwumpe]

Can't test with the beta, currently testing against the released Orbiter 2016.

 

[Donamy]

Tested it using the same technique for reproducing the singularity bug and no problems this time. After yawing the EE through the 270° singularity for 10 minutes consistently, the there's no deviation between the EE itself and it's attachment point at all. I'd say it has been dealt with, at least in D3D9Client.

Does this only work for the newest SSU ? I'm working with an older version and in STS-88, it is still broken.

 

[Urwumpe]

Does this only work for the newest SSU ? I'm working with an older version and in STS-88, it is still broken.

No, but it requires the Orbiter Beta release and the attached D3D9Client.dll for testing. I can't test it, should there also be a test release for Orbiter 2016, I could verify it with the test code.



Currently, with the 5th May release of D3D9Client, the bug is still there.