Space Shuttle - Development

Discussion about development and usage of spacecraft

Re: Space Shuttle - Development

Why, because on the display P/Y/R when pitch is around 83 degrees, as for grabbing HST, that A angle appears on the value of Y, not on R!

Well, at the Euler singularity there's no way to define a difference between yaw and roll. So are we talking an Euler singularity issue here?

I was trying to describe what I was seeing in that the jump corresponds to the shoulder yaw angle and that must be translated to the end eff roll angle in some manner.

The end effector roll angle is what is shown on the display. That's the only property of that type as far as I understand my code. Now, if the problem is at pitch > 83 deg, then computing what is roll and yaw is blurry - the values you see depend increasingly on artifacts of the numerics, and the animation framework that determines where you see the arm (nested matrix equations) might do it differently from the JSBSim numerics (trigonometry) that determines where you see the payload (via translation animations).

So is that what you're seeing - different numerical artifacts at the Euler singularity?
Thorsten

Posts: 11649
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

So is that what you're seeing - different numerical artifacts at the Euler singularity?

I don't think so, this is always there, you don't need to be at pitch > 83 to see it, but you need to be at pitch different than 0 for sure. It becomes progressively more visible with higher pitches true, but in a smooth way and that is looking quite different than what happens close to Euler singularity. In fact, it looks more like some typo in a trigonometric transform or some projection issues with the angles. I can try to reverse engineer what you have coded, but I would need a starting point, like the name of a file?
eatdirt

Posts: 604
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

I can try to reverse engineer what you have coded, but I would need a starting point, like the name of a file?

Systems/rms.xml, specifically the (aptly named) channel 'Joint spatial positions' from line 2358.
Thorsten

Posts: 11649
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Thanks, perfect.

Sorry for the possibly stupid question, but when working out the value of
Code: Select all
`sum-wrist-yaw-rad`
my trigonometry simplifies to a simple sum of all yaw angles, the pitch completely disappears (up to some modulo pi/2 or sign I did not try to get yet).

You got me curious because there is a commented function:

Code: Select all
`<fcs_function name="systems/rms/sum-wrist-yaw-rad-test">`

that is doing exactly what I find, as opposed to the current one
Code: Select all
`[<fcs_function name="systems/rms/sum-wrist-yaw-rad">`
where the pitch appears. This is exactly that pitch dependence that we see on the video I posted before, increasing pitch makes that sum-wrist-yaw-rad changing and the HST yaws.

Most reasonable assumption is that you first took the same route as I did, then corrected for some reason. Would you remember a bit what was the reasoning here?
eatdirt

Posts: 604
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

No, sorry,
Thorsten

Posts: 11649
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Never mind, found my mistake... sorry. And I am recovering the exact same expressions for all the angles sum-*, and all the positions (x,y,z) of everything in rms.xml. Which does not help for our purpose... What remains, the animation?

Edit: Could we miss a sum-wrist-roll? The roll in the end effector frame is not the same as the roll in the Shuttle frame!?
eatdirt

Posts: 604
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

Not sure what the animation does... Multiple rotations always imply some convention about their sequence, so it may be that the animation sequence implies something that causes a roll whereas the JSBSim sequence does not.

You could introduce a compensating roll offset and see whether this cures the issues. Certainly we don't send any non-roll to the joint animation (I hope), so if there's a roll seen, it must have been implied by the prior sequence.
Thorsten

Posts: 11649
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Thank for the explanations!

I may have spotted a pattern. All animations of the payload in SINGLE mode are broken when the arm is pitched / not aligned with the Shuttle. The clearest one is changing the wrist's joints (WRIST ROLL/PITCH/YAW) in SINGLE MODE. The animation of the arm is perfect, but HST goes haywire. For instance, inducing a SINGLE mode WRIST ROLL makes the HST rolling along Shuttle x, not along the end effector. The WRIST YAW induces also an impossible motion for the HST.

Everything works fine in AUTO-MODE. But in AUTO-MODE, all the rotations take place at fixed end effector, (0,0,0), and translations at fixed angles. I am wondering if this is not the culprit here? In SINGLE mode, rotations take place around another center and the end effector is moving simultaneously. Maybe the way we animate the payloads in that case is not correct? (I am completely incompetent in this).
eatdirt

Posts: 604
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

Everything works fine in AUTO-MODE. But in AUTO-MODE, all the rotations take place at fixed end effector, (0,0,0), and translations at fixed angles. I am wondering if this is not the culprit here?

I fail to see how that could be the case. The inverse kinematics is exact (which is why it is calculable), so there is a one-to-one mapping between every state that can be reached by driving single angles and every state that can be reached by driving end effector (X/.Y/Z/P/Y/R).

Internally the computation of where the end effector is and how it is oriented runs via the same channel (the one which you had a look). That computation is - I believe - directly used in the payload animation (which, potentially, might have an error somewhere as well - in fact, from what you describe, it very likely has...).

So it is difficult to see how there could be an actual difference between the two cases, although it is easy to see how you explore different paths in configuration space while transiting from one position to the next.

Try looking into the animation sequence that moves the payloads - it's likely that I made a subtle mistake - like choosing the (in general) wrong roll axis.
Thorsten

Posts: 11649
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Try looking into the animation sequence that moves the payloads - it's likely that I made a subtle mistake - like choosing the (in general) wrong roll axis.

Here you go!!!! The axis are fine, but the sequence should be inverted. The following works, RYP:

Code: Select all
`<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>    <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/sum-wrist-yaw-pitch-deg</property>      <axis>        <x>0</x>        <y>1</y>        <z>0</z>      </axis>      <center>        <x-m> 0</x-m>        <y-m> 0</y-m>        <z-m> 0</z-m>      </center>    </animation>`

We currently have PYR. The funny yaw by pitching up is gone, and the wrist SINGLE mode now behaves fine. I'll do some more testing and push a merge request if you want?

Damned! I should have started there instead of redoing the bloody trigo
eatdirt

Posts: 604
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

If we knew what is wrong beforehand, we wouldn't have to call it debugging though...

Yes, please just do a merge request if that's possible for you (and send me a PM - SF isn't notifying me...)
Thorsten

Posts: 11649
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Nice work, glad you figured it out.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480

wlbragg

Posts: 5607
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: Space Shuttle - Development

Okay, I've merged the first batch from GinGin and the animation sequences - nice job everyone!
Thorsten

Posts: 11649
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Great, thanks Thorsten and Gingin!

Wayne, with your last push, I still have some (smaller) discrepancies in the 3D between the end effector and the attachment point when matching the hook coordinates. Because I felt ashamed to ask, I've tried to do it by myself with blender and I've tuned the origin (for quite a long time...)

Now I am getting this:

which satisfies myself

Now, I have no idea how to share that tuning with you. Is this file enough?

hst.ac

I can also share with you the blender saved file, or I can try to give you by how much I shifted the origin along x, y,z?

Weirdly enough, that does not match the origin of the spartan.ac file, maybe there are some shifts according to arm location!?

Cheers,
Chris.
eatdirt

Posts: 604
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

That ac file is probably enough, but, how much did that change the original position of the model when secured in the bay? Because it was exactly where I wanted the model when secured. The position for grabbing "success" I thought was good as well. But for sure the offset after a grab was off by a few inches at best (not good).
I really wasn't sure what the correct fix was going to be because two of the three positions were where we wanted them but not the third position. Secured was correct, I felt grab position was really close, only after grab offset was bad. So that kind of left me wondering how to proceed. The choices were, move the model position physically, or move the grab point, or both. I figured it was going to require moving them both to achieve the desired outcome. Maybe not though.
Let me download this into my installation and take look, then I'll let you know what I think before I push it.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480

wlbragg

Posts: 5607
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

PreviousNext