Space Shuttle - Development

[wlbragg]

The HST model jumps.

Right, that's some fine tuning I think.

I don't think I am seeing the 21 degree yaw locally? That rotation is no longer in the xml's either?
I'll run through a capture and release later and see if I can duplicate. But I don't think I am getting that!

Also is there a way you can automate the capture in the bay using pre configured RMS movements? Can the Shuttle computer do this, even partially?

[eatdirt]

Right, that's some fine tuning I think.

I hope you're right, but it feels that is not. If the offsets at release are correctly computed, which they should as the same code is used for SPARTAN, we should not see any jump at all. It sounds like something bad is again hidden somewhere

Also is there a way you can automate the capture in the bay using pre configured RMS movements? Can the Shuttle computer do this, even partially?

Yes, this should be in the mission file (under Missions/), the whole section about "rms-auto-sequences". I've never really used that because you should be careful to not hit Euler nor Software stop in the sequence, or byebye. But that is the proper way to go, but requires quite some tests before making it works smoothly.

What I do for testing:

a)Unstow the arm in SINGLE mode to pass the software STOP, a bit of pitch up on the SHOULDER and the same amount of pitch down on the ELBOW. Then the end-effector is at pitch=0
b) SPEC 94 in SM mode, ITEM +18 +8.77 +3.32 +0.34 EXEC
c) OPR CMD and ENTER

Now the RMS goes alone at the attachment point

d) in SPEC 94 ITEM +21 + 83
the end effector takes 83 degrees of pitch

c) GRAB

The arm crosses the inside of Hubble, but that's for testing.

NB: remember that the OPR CMD mode first change attitude at constant position. So if you enter +83 degrees of pitch already at step b) with the arm almost horizontal you immediately go into software stop.

[eatdirt]

I don't think I am seeing the 21 degree yaw locally?

I have been playing with blender for my very first 2 hours to try a thing, I know from where the 21.1 degrees of yaw are coming: the hook

I am a punk, nothing interesting here... You just need to have the bloody rotary switch on END EFF to read 0.0 of yaw, and not on ELBOW..........

[Thorsten]

Also is there a way you can automate the capture in the bay using pre configured RMS movements? Can the Shuttle computer do this, even partially?

If you have an auto-sequence, you can program it in the mission file and run it. Or you can punch the attachment point coordinates in as target.

[wlbragg]

Thanks Thorsten. I assumed it was possible, actually would have been shocked if it wasn't possible in the real thing. I didn't know if you took the time to program it and as you can see I am apparently adverse to reading.

[GinGin]

I made a sum up of my pfd changes here:

https://forum.flightgear.org/viewtopic.php?f=87&t=37429&p=367492#p367492

[eatdirt]

Right, that's some fine tuning I think.

I should have tried that first. The jump at released time is also present for SPARTAN-201, so this is not an issue with the HST only but something in the offset calculations. I cannot tell if this is a bug or something expected with the inherent accuracy limitations of the "proximity zone"?

cheers,
chris

[wlbragg]

I'm looking at how I want to animate the solar cells on HST.
I think the easiest for now is to use a select animation in the 2 controlled HST model files that hides the cell mesh objects. Then in the 1 released HST model file shows the cells as soon as a couple conditions are met.

I need to add another property to the payload_data_array, something like...
fdm/jsbsim/systems/rms/payload/payload-released
which would be triggered when the released payload is initiated at release.

That alone works, but one other thing I would like is to track the range the HST is from the shuttle. Something along the lines of
geo.aircraft_position.distance_to(HST_pos);. I could then use that range to limit the opening of the solar cells to a set distance from the Shuttle after the release.

@Thorsten, where are the coords calculated and/or exposed in either variables, or properties in the tree, for the released payload?

@eatdirt, I think I identified the "fine tuning" problem. The one joint axis "shoulder yaw" seems to be missing or incorrectly calculated. During the shoulder yaw, while attached to the ARM, the HST model is not yawing with the ARM shoulder. As soon as you release it though it appears to do that calculation but it is off a bit. Probably by the amount not tracked during the shoulder yaw in real time. Maybe you can help me locate or identify where that calculation is missing or incorrect?

Notice here the shoulder yaw was not translated to the HST.


But at release it is, just not perfectly.

[wlbragg]

Here is the visual of the issue with the shoulder yaw rotation. The first test I did appeared to only be off slightly after release. But this one I taped was off on possibly both the Shuttle X and Y and also the Z.

It also shows how the solar cells are deployed at release. Eventually I'd like to make that "after release" and X distance from Shuttle.

[wlbragg]

@Thorsten, when you get a chance, please review the commit and verify how I added a new property to the payload_data_array and used it after release to set the select animation for the solar cells. Please confirm that this is a preferred way to do this.

[Thorsten]

Gimme some time - I'm trying to get GinGin's stuff into a good streamlined structure trying to avoid unnecessary property I/O and so on, and I've been reading a lot of his work and exchanging messages the last days.

[GinGin]

That looks really nice !!

[eatdirt]

Thanks Wayne, looks very nice. I see the yaw problem. I may have an idea where it does come from, I'll test and report.

[eatdirt]

Ok, if I compare to Spartan, I think we miss these lines in Payload/HST/hst.xml, just after line 90

Code: Select all

<animation>   
   <type>rotate</type>
   <property>/fdm/jsbsim/systems/rms/sum-wrist-yaw-deg</property>
   <axis>
         <x>0</x>
         <y>0</y>
         <z>1</z>
     </axis>
     <center>
         <x-m> 0</x-m>
         <y-m> 0</y-m>
         <z-m> 0</z-m>
     </center>
   </animation>

   <animation>   
   <type>rotate</type>
   <property>/fdm/jsbsim/systems/rms/ang-wrist-roll-deg</property>
   <axis>
         <x>1</x>
         <y>0</y>
         <z>0</z>
     </axis>
     <center>
         <x-m> 0</x-m>
         <y-m> 0</y-m>
         <z-m> 0</z-m>
     </center>
   </animation>


Adding them fix the yaw problem, but not the jump. As I said earlier, the jump seems to me to be in the offset calculations that applies to all payloads.

There is something a bit strange though, if you pull out the HST from the bay in SINGLE mode by increasing the Shoulder pitch, the HST starts yawing in addition to pitching. It looks like there is a coupling between yaw and pitch. But it seems to be on purpose; the already existing section rotate has

Code: Select all

sum-wrist-yaw-pitch-deg

Should it be

Code: Select all

sum-wrist-pitch-deg

only?

Playing around shows that the pitch displayed in the Shuttle is matched to

Code: Select all

sum-wrist-yaw-pitch-deg

and not to

Code: Select all

sum-wrist-pitch-deg

I don't really get how the underlying thing works and why this property is called sum-wrist-yaw-pitch and how it relates to sum-wrist-pitch-deg.

Anyway, I've just tried with my arm, there is no reason for the end effector yaw to change while only changing the shoulder pitch angle

On the other hand, if you pull the HST using the OPR CMD mode, it goes up the bay exactly as it should, no yawing appears.

[Thorsten]

I don't really get how the underlying thing works and why this property is called sum-wrist-yaw-pitch and how it relates to sum-wrist-pitch-deg.

Lots of trigonometry. Basically you can't just add rotation angles and expect the result to be a rotation angle.