SSU Development Thread (2.0 to 3.0)

[Urwumpe]

Yep, nothing shows up.

Then I should better check if Realize or DefineVC are called.

 

[GLS]

I'm getting this in the log when changing vc positions (on all scenarios):

(SpaceShuttleUltra) [DEBUG] Panel state violation in C2, not realized at RegisterVC()
Registering Panel C3
(SpaceShuttleUltra) [DEBUG] Panel state violation in C3, not realized at RegisterVC()
(SpaceShuttleUltra) [DEBUG] Panel state violation in F2, not realized at RegisterVC()
(SpaceShuttleUltra) [DEBUG] Panel state violation in F3, not realized at RegisterVC()
(SpaceShuttleUltra) [DEBUG] Panel state violation in F4, not realized at RegisterVC()
(SpaceShuttleUltra) [DEBUG] Panel state violation in F6, not realized at RegisterVC()
(SpaceShuttleUltra) [DEBUG] Panel state violation in F7, not realized at RegisterVC()
(SpaceShuttleUltra) [DEBUG] Panel state violation in F8, not realized at RegisterVC()
(SpaceShuttleUltra) [DEBUG] Panel state violation in O3, not realized at RegisterVC()
(PanelO6::RegisterVC) Begin registration.
(SpaceShuttleUltra) [DEBUG] Panel state violation in O6, not realized at RegisterVC()
[CRT]:DIMENSIONS: 256 256

PanelA6: RegisterVC called
PanelA8::RegisterVC() called
PanelA8::AtlantisPanel::RegisterVC() called
[CRT]:DIMENSIONS: 256 256

(SpaceShuttleUltra) [DEBUG] Panel state violation in A6, not realized at RegisterVC()
PanelA6: RegisterVC called
(SpaceShuttleUltra) [DEBUG] Panel state violation in AftMDU, not realized at RegisterVC()
(SpaceShuttleUltra) [DEBUG] Panel state violation in A7U, not realized at RegisterVC()
(SpaceShuttleUltra) [DEBUG] Panel state violation in A4, not realized at RegisterVC()
PanelA8::RegisterVC() called
(SpaceShuttleUltra) [DEBUG] Panel state violation in A8, not realized at RegisterVC()
PanelA8::AtlantisPanel::RegisterVC() called
[CRT]:DIMENSIONS: 256 256

(SpaceShuttleUltra) [DEBUG] Panel state violation in R11, not realized at RegisterVC()
(SpaceShuttleUltra) [DEBUG] Panel state violation in R13L, not realized at RegisterVC()
(SpaceShuttleUltra) [DEBUG] Panel state violation in A6, not realized at RegisterVC()
PanelA6: RegisterVC called
(SpaceShuttleUltra) [DEBUG] Panel state violation in AftMDU, not realized at RegisterVC()
(SpaceShuttleUltra) [DEBUG] Panel state violation in A7U, not realized at RegisterVC()
(SpaceShuttleUltra) [DEBUG] Panel state violation in A4, not realized at RegisterVC()
PanelA8::RegisterVC() called
(SpaceShuttleUltra) [DEBUG] Panel state violation in A8, not realized at RegisterVC()
PanelA8::AtlantisPanel::RegisterVC() called

 

[Urwumpe]

I'm getting this in the log when changing vc positions (on all scenarios):

Yes, these debug outputs are just my slowly checking if the VC component state machine was not violated... I realized that a few state transitions are not properly implemented and missing, for example removing a panel from the VC event handling again.

 

[Donamy]

I seem to only be able to use single joint motion, on the RMS.

 

[DaveS]

I seem to only be able to use single joint motion, on the RMS.

No issues here. Did you power up the aft flight controllers on A6? Also make sure that the RMS SELECT switch is set to PORT and you have selected either ORB UNL or END EFF on the MODE select switch on A8L.

 

[GLS]

No issues here. Did you power up the aft flight controllers on A6? Also make sure that the RMS SELECT switch is set to PORT and you have selected either ORB UNL or END EFF on the MODE select switch on A8L.

I can confirm it all seems good here.

 

[Urwumpe]

No issues here. Did you power up the aft flight controllers on A6? Also make sure that the RMS SELECT switch is set to PORT and you have selected either ORB UNL or END EFF on the MODE select switch on A8L.

I can confirm it all seems good here.

Do we need a quick RMS tutorial for SSU? A video tutorial would be great, but I doubt I know how to produce something like that.

 

[DaveS]

Do we need a quick RMS tutorial for SSU? A video tutorial would be great, but I doubt I know how to produce something like that.

I think I could produce one in rather short amount of time.

 

[Urwumpe]

I think I could produce one in rather short amount of time.

That would be epic. Such a video tutorial would also be the best advertisement for SSU.

 

[Donamy]

The problem wass, I needed to turn on thrusters with cntrl+num/. But now I'm getting a joint 2 speed error, when trying to translate in the X axis. I'm using the rendezvous test scenario ?

 

[DaveS]

The problem wass, I needed to turn on thrusters with cntrl+num/. But now I'm getting a joint 2 speed error, when trying to translate in the X axis. I'm using the rendezvous test scenario ?

Well, currently the RMS implementation is a bit wonky I have noticed. You can only move the RMS with the normal controls when you're not in a Reach Limit mode. You can see this by a yellow "REACH LIM" light on A8U. If you see the joint speed message it means you have maneuvered the arm into a REACH LIM situation and you can't move further in that direction.

 

[Donamy]

The reach limit light was on, but when I moved the shoulder and elbow, by single joint mode the light went out, but it was unable to translate in the X axis, ...Y and Z translation worked fine.

 

[GLS]

The reach limit light was on, but when I moved the shoulder and elbow, by single joint mode the light went out, but it was unable to translate in the X axis, ...Y and Z translation worked fine.

You might have the arm in a singularity situation. That checking still isn't done (I think the speed limit is part of it). You'll just have to move it some other way.

 

[Donamy]

All I did was move it from the cradled position.

---------- Post added at 03:28 PM ---------- Previous post was at 03:26 PM ----------

Another thing I noticed, the wing root textures are off, where the RCC meets the tiles. Was it remapped or is it a older orbiter.msh ?

 

[DaveS]

All I did was move it from the cradled position.

I don't use the normal controls until I have the arm in the "pre-cradled" position (SP +25.0, EP -25.0 WP +5.0). This is in fact the proper procedure, as it is the closest park position where none of the joints are near a singularity.

---------- Post added at 05:31 PM ---------- Previous post was at 05:29 PM ----------

All I did was move it from the cradled position.

---------- Post added at 03:28 PM ---------- Previous post was at 03:26 PM ----------

Another thing I noticed, the wing root textures are off, where the RCC meets the tiles. Was it remapped or is it a older orbiter.msh ?

Could you show what is off? I haven't touched that area at all except for remapping the RCC texture to remove some distortions but the glove area (its where the wing meets the FWD fuselage) is untouched as is the bottom and top.

 

[GLS]

All I did was move it from the cradled position.

Yes, in that position you have a bunch of joints/axis aligned. I don't know what the checklists say, but I'm pretty sure the uncradle has to be single joint motion, until the arm is in a position to use the "fancy modes". Moving the 3 pitch joints (shoulder, elbow and wrist) a few degrees will probably do the trick.

 

[Urwumpe]

@GLS: You did remove too much "unused code" from SSU it seems, I have a missing "Atlantis::GetVisual" here.

Sadly sourceforge is broken again... reviewing the changes in Atlantis.h happens at 5 Byte/s

EDIT: Yep confirmed, the function got removed in 2206, but is still needed for StandardLight2.cpp... but StandardLight2 is not used yet, it is a similar implementation as the new talkback code, just for lights.

---------- Post added at 06:33 PM ---------- Previous post was at 06:25 PM ----------

I commented the problematic code out, since we are not using StandardLight2 yet. Maybe we would be better off, if we use your talkback code there as well, since both do very similar things, and just have different signatures to the outside.

 

[GLS]

@GLS: You did remove too much "unused code" from SSU it seems, I have a missing "Atlantis::GetVisual" here.

Sadly sourceforge is broken again... reviewing the changes in Atlantis.h happens at 5 Byte/s

EDIT: Yep confirmed, the function got removed in 2206, but is still needed for StandardLight2.cpp... but StandardLight2 is not used yet, it is a similar implementation as the new talkback code, just for lights.

---------- Post added at 06:33 PM ---------- Previous post was at 06:25 PM ----------

I commented the problematic code out, since we are not using StandardLight2 yet. Maybe we would be better off, if we use your talkback code there as well, since both do very similar things, and just have different signatures to the outside.

I see the problem now: the StandardLight2 is not used anywhere and also it is not added to the VS2010 solution (I searched the solution to see if it was used). I checked if it all compiled and worked well before committing.
Yes, the idea would be to also do the lights in the same way as the new talkbacks, and then when all is updated, change the name from "Talkback_2" to "Talkback".

 

[Urwumpe]

I see the problem now: the StandardLight2 is not used anywhere and also it is not added to the VS2010 solution (I searched the solution to see if it was used). I checked if it all compiled and worked well before committing.
Yes, the idea would be to also do the lights in the same way as the new talkbacks, and then when all is updated, change the name from "Talkback_2" to "Talkback".

Yeah... maybe we can separate the texture manipulating part from the behaviour of the element.

---------- Post added at 09:30 PM ---------- Previous post was at 07:16 PM ----------

I can't really get behind the bug in the OMS manoeuvre code. When I plan a VX=50 fps manoeuvre, I get a much higher VGO, but the burn time still assumes 50 fps velocity change. The displayed residuals are approximately the difference between initial VGO and PEG7.

I think about implementing the unified powered guidance algorithm in parallel to the old code, for testing if this results in more accurate burn data.

---------- Post added at 10:19 PM ---------- Previous post was at 09:30 PM ----------

Tested compiling SSU with Visual Studio 2015, but it looks like OrbiterSound 4.0 is a showstopper for it.... will work on it later.

 

[Donamy]

Could you show what is off? I haven't touched that area at all except for remapping the RCC texture to remove some distortions but the glove area (its where the wing meets the FWD fuselage) is untouched as is the bottom and top.

The model I have in my AC3D folder doessn't have it.