Board index FlightGear Development Spaceflight

Space Shuttle - Development

Discussion about development and usage of spacecraft

Re: Space Shuttle - Development

Postby wlbragg » Sun May 17, 2020 7:55 pm

I think we miss these lines in Payload/HST/hst.xml

OK, I removed those blocks, specifically the "sum-wrist-yaw-deg" parameter because if I included it in hst.xml when you grab the payload in the bay you get this...
Image

I can add the "ang-wrist-roll-deg" parameter, no issues.

So why on the hand off from hst-secured.xml to hst.xml is it not accounting for (as in subtracting) the shoulder yaw accumulated in the arm transition towards gabbing the payload?

When the model rotates on "grab" like in this image, it breaks the release logic and I am dead in the water to remove it from the bay. I can't even test if adding it back in cures the yaw rotation issues during deployment rotation.
Without the "sum-wrist-yaw-deg" block, neither the shoulder yaw or the wrist yaw transfer to the deployment rotation visual. I am assuming with that block that the payload yaw rotates correctly on both shoulder and wrist? But I can't test that because the initial rotation on grabbing breaks it from that point forward.

I'm not happy with the initial placement of the hst-secured.xml model. It needs to be moved slightly on the Shuttle y and x axis. Also the end-eff position to grab is slightly to deep past the connection point on the Hubble pie connector.

I think I should first adjust those x/y positions and also change the end-eff attachment point to the other Hubble pie, the one closer to the arm. Not that we shouldn't be able to use either, but it might be a better option to use the attachment closer to the original position of the RMS.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
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

Postby eatdirt » Sun May 17, 2020 9:53 pm

OK, I removed those blocks, specifically the "sum-wrist-yaw-deg" parameter because if I included it in hst.xml when you grab the payload in the bay you get this...


That's weird, I don't have that anymore. When I grab it, it is just behaving fine. To be clear, I do remember to have that in the very first version of yours, but even adding those lines you removed works fine to me *now* when I am grabbing. It is when I am increasing the pitch on SINGLE mode on SHOULDER that I am seeing it progressively yawing. Would you mind to test again and report the rotary switch position?

Maybe the rotary button (ELBOW, SHOULDER etc...) interferes!? That's possible, because as I said, in my case, if I am lifting HST in OPR CMD mode, by just changing the Z coordinate for instance in SPEC94, I don't see any spurious yaw angle appearing. As Thorsten said, a lot of trigonometry inside, but the behavior should be the same in these cases no?
eatdirt
 
Posts: 604
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

Postby wlbragg » Mon May 18, 2020 4:07 am

Would you mind to test again and report the rotary switch position?

I was using the GUI from exterior view. You want me to report the rotary switch position when?
I was using "single" mode and position x/y/z.

Maybe the rotary button (ELBOW, SHOULDER etc...) interferes!? That's possible, because as I said, in my case, if I am lifting HST in OPR CMD mode, by just changing the Z coordinate for instance in SPEC94, I don't see any spurious yaw angle appearing

So you haven't tried it using "Single" mode, using position x/y/x?

I tried it using "direct" and same thing, it matches the shoulder yaw on grab instead of subtracting that amount.

I don't know how to use the OPR CMD mode. I never did learn how to use the CRT's and the computer much.


The shoulder yaw is messed up for all three modes. It sure looks like it might be a logic or math issue.
It is interesting though that the correct attitude is given to the hst-disconnected.xml model. Just the offset is messed up. So the attitude numbers are retained correctly when passed to disconnected model.

Note:
The six properties passed to the hst.xml model upon "grabbed are...
/fdm/jsbsim/systems/rms/sum-wrist-yaw-pitch-deg (rotation)
/fdm/jsbsim/systems/rms/sum-wrist-yaw-deg (rotation)
/fdm/jsbsim/systems/rms/ang-wrist-roll-deg (rotation)
/fdm/jsbsim/systems/rms/effector-x (translation)
/fdm/jsbsim/systems/rms/effector-y (translation)
/fdm/jsbsim/systems/rms/effector-z (translation)

The three properties passed to the disconnected model are...
/controls/shuttle/HST/payload-pitch-deg (rotation)
/controls/shuttle/HST/payload-yaw-deg (rotation)
/controls/shuttle/HST/payload-roll-deg (rotation)

I never did try the SPARTAN and guess what. It rotates to match the shoulder yaw at grab also. So the bug is in both payloads. Not anything I did apparently. You just can't tell as much with the smaller payload and it doesn't rotate enough to hit the bay walls or the pallet.

I pushed the addition of the missing rotations in hst.xml.
Last edited by wlbragg on Mon May 18, 2020 3:59 pm, edited 1 time in total.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
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

Postby eatdirt » Mon May 18, 2020 12:50 pm

Thanks for the details Wayne. I've tried your last push, the grabbing works for me!

I think I understand what's going on. Are you moving the arm "by hand" in SINGLE mode "before" grabbing the payload? I suspect you do.

My best guess of what is happening is that we have an absolute encoding of the rotation angle of the wrist around its elongated direction, let's call this angle A. When you use the OPR CMD command, you have to specify P/Y/R of the END EFFECTOR, and I am approaching the payload with P=83 Y=0 R=0. In that case Y is very close to A, A is nearly 0, I grab, everything goes fine.

If you do a SINGLE mode approach, you are only controlling one angle at a time, and if you have approached the payload using ELBOW/SHOULDER yaw and pitch changes, and WRIST pitch only, you will necessarily have a non-vanishing A and Yaw on the END EFFECTOR, and these are exactly given by the yaw you put on the SHOULDER (assuming A is initialized to 0 when the arm is folded). You grab, the payload suddenly yaws to match the END EFF yaw.

I might suspect that Thorsten coded it this way precisely for P/Y/R to be w.r.t the frame of the Shuttle, and the consequence is that A is somehow absolutely related to P/Y. That would also explain why I see the HST slowly yawing as I increase the SHOULDER pitch when I use SINGLE mode after the grabbing, and not when I use OPR CMD.

How it should be? Dunno, did not read that part yet in the SCOM :) But I suspect this angle A should not be absolute, that part of the wrist should certainly work as a screw? Can we do a reset of this guy when we grab? Or can we force A to be fixed when P is changed?


I don't know how to use the OPR CMD mode. I never did learn how to use the CRT's and the computer much.


I posted before what to do on SPEC 94 if you want to try. But it is actually good you tried the manual way, I think there is indeed something going bad there. Dunno if it is fixable though, Thorsten can say.

also change the end-eff attachment point to the other Hubble pie, the one closer to the arm. Not that we shouldn't be able to use either, but it might be a better option to use the attachment closer to the original position of the RMS.


I agree!

Edit: I do see the same slow yawing on SPARTAN pulling it out the bay in SINGLE mode, SHOULDER pitch-up after grabbing. It is just less spectacular due to its small size, as you spotted Wayne.
eatdirt
 
Posts: 604
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

Postby Thorsten » Mon May 18, 2020 2:16 pm

@eatdirt:

I'm not sure I understand all of your analysis... sorry.

and these are exactly given by the yaw you put on the SHOULDER (assuming A is initialized to 0 when the arm is folded). You grab, the payload suddenly yaws to match the END EFF yaw.


The grab at present does not require angular matching, only end effector to attach point matching (I found that awkward enough when trying to grab something in free-float...), so in modeling the zero point and orientation of the payload *.ac model there's an angle implied at which the payload is grabbed, and whenever you grab it, it will jump to that angle.

That may be small if you grab close to the real angle, but it will be as large as 180 deg if you grab 'from behind through the object' - if you haven't defined a hard core or angular limits that would be quite possible to do.

The solution to that one is to eventually check angular matching when doing a grab.

and the consequence is that A is somehow absolutely related to P/Y. That would also explain why I see the HST slowly yawing as I increase the SHOULDER pitch when I use SINGLE mode after the grabbing, and not when I use OPR CMD.


The automatic modes drive multiple angles simultaneously with the aim to satisfy either

* in translation mode a smooth translation of the x/y/z point without any change of the angular orientation
* in rotation mode a smooth change of the pitch/yaw/roll of the end effector without any position change

So yes, generally the translation or operator commanded translation mode (internally they're the same, except in one you supply the command to the PID controllers, in the other a Nasal script) would prevent any angular motion of the target, the single or direct mode would not.

However - the position / attitude of the end effector is determined the same way in all modes, so it can not be wrong in one but not the other, it has to be wrong in all of them or in none.
Thorsten
 
Posts: 11649
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Postby wlbragg » Mon May 18, 2020 4:35 pm

I assume the mechanical makeup of the end eff might be such that it has to be in in line with the payload hardware latch in order to attach to the payload connecting hardware. I. E.; the hardware latches of the end eff has to match the hardware latches of the payload. They obviously aren't if when we grab the payload the payload is rotating. So maybe the "the wrist should certainly work as a screw?" theory is true but it still has to line up on the attachment "plane" in order to work or attach. That doesn't mean you can't rotate it, but it can be rotated in a position that won't connect.

I assumed the end eff is just naturally or by design always going to match the payload connecting hardware. Not so unless the gearing in all the joints are designed to keep it that way, which I am not sure could even be done with all the possible angles. So it makes sense that the way I was driving the arm (especially the shoulder yaw) that the end eff is out of position. But I am back to you shouldn't be able to connect.

The grab at present does not require angular matching, only end effector to attach point matching (I found that awkward enough when trying to grab something in free-float...),

This is the part I think if we're going to work on something we try to come up with a solution. Especially for payload grabbing if not free float grabbing. For payload, I would rather see a notice that you can't because of a bad angle or rotation, or even flat out not being allowed to connect with out notice, rather than allowing it to connect and seeing that rotation jump.

So how does this relate to the angular separation of the payload and end eff upon movement of the arm when a payload is attached? Is there boundaries we are passing that we theoretically can't or shouldn't be passing because of mechanical or software restrictions that would typically be in place?
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
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

Postby Thorsten » Mon May 18, 2020 5:09 pm

In payload.nas, you have

Code: Select all
#if (math.abs(effector_yaw ) > 20.0) {flag = 0;}
#if ((math.abs(effector_pitch ) > 10.0) and (math.abs(effector_pitch) < 80.0)) {flag = 0;}

print ("yaw: ", math.abs(effector_yaw ));
print ("pitch: ", math.abs(effector_yaw ));


as you can see, that was my initial go at restricting grab angle. Feel free to expand on the theme :D

So how does this relate to the angular separation of the payload and end eff upon movement of the arm when a payload is attached?


I would think not at all. If I remember correctly, the angle is okay but there is an offset? That smells like a sine term missing in the computation of the end effector position. i.e. the position known by systems doesn't match the position computed by the animations.
Thorsten
 
Posts: 11649
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Postby wlbragg » Mon May 18, 2020 5:54 pm

If I remember correctly, the angle is okay but there is an offset?

Actually there appears to be 2 issues. The offsets, yes. That happens when you disconnect.

The other issue I see is after I grab the payload when I rotate the payload out of the bay using shoulder yaw, the payload does not rotate with the end eff on the Shuttle z axis (also shoulder connection to Shuttle, z axis). In this case it is the shoulder yaw (incorrect rotational matching of the end eff and the payload connection point).

The offsets, yes. That happens when you disconnect.

Yet it applies the correct rotational numbers in all axis on disconnect. Only offset is off.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
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

Postby eatdirt » Mon May 18, 2020 7:35 pm

Ok, that is not easy to be clear, sorry. Anyway, I think you sorted out most of what I wanted to say :)

there's an angle implied at which the payload is grabbed, and whenever you grab it, it will jump to that angle


Exactly.

What is unclear to me is whether or not that makes sense to do this for the END EFFECTOR A angle. I don't know how to call this angle, but let me try to be clear about that. In the rest frame of the end effector, sitting on it like a horse when it is horizontal (arm stowed), it would be a roll, let's call that roll A.

I would naively say that the real thing, and its wires closing in, is unaware of any relative difference between the A angle of the payload's hook and the one of the end effector (before grabbing of course).
In this picture, I would rather make the END EFFECTOR A angle jumping to the one assumed by the payload's hook rather than the contrary?

However - the position / attitude of the end effector is determined the same way in all modes, so it can not be wrong in one but not the other, it has to be wrong in all of them or in none.


Yes, if you're referring to the automatic modes, that is working this way, and it is working perfectly fine.

I think Wayne was having the HST jumping because he was using SINGLE mode to go to the attachment point, which then does not keep fix the P/Y/R of the END EFFECTOR and because he was allowed to grab the HST with a END EFFECTOR A angle not equal to 0.

So maybe the "the wrist should certainly work as a screw?" theory is true but it still has to line up on the attachment "plane" in order to work or attach.

This makes sense to me. The SCOM it is not really clear about the "A"angle attitude of payload's hook vs end effector, but looking at the pictures of the end effector, the wire mechanism looks rotational invariant.

So how does this relate to the angular separation of the payload and end eff upon movement of the arm when a payload is attached?


I would think not at all.




I agree with this too, the two things seem to be unrelated.

The other issue I see is after I grab the payload when I rotate the payload out of the bay using shoulder yaw, the payload does not rotate with the end eff on the Shuttle z axis


Wayne, your last push fixes this for me (see video below).

Now the thing I was not clear enough is illustrated on the following video. I am approaching the hook with auto-mode, the A angles match, everything is good, the grabbing is good.
For the purpose of showing the issue, I am pulling out the HST out of the bay in SINGLE mode SHOULDER pitch, ELBOW pitch and SHOULDER yaw only. There is an unexpected coupling to the angle A of the end effector, I am shaking the HST on SHOULDER pitch to make that clear (that issue is also present with SPARTAN)

rms_yawcoupling.webm

PS: The offsets pb at release time is also on the video.
eatdirt
 
Posts: 604
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

Postby wlbragg » Mon May 18, 2020 7:58 pm

I would rather make the END EFFECTOR A angle jumping to the one assumed by the payload's hook rather than the contrary?

Except, in reality it wouldn't do that. You would have to perform a rotation of the end eff to make it match. I would rather not allow attachment until the angles match.

Wayne, your last push fixes this for me (see video below).

Right, it probably does for me as well. I never tested it since the angle jump on grab broke the ability to continue deploying the payload.

Now the thing I was not clear enough is illustrated on the following video.

Out of time at the moment so I will look at this later this evening.

I am going to change the "hot" HST attachment point to the one closest to the arm simply for ease in testing and to reduce the potential disparity between end eff and shoulder yaw. While I am at it I will zero in the Shuttle/Payload Z depth (tolerance) for the end eff and HST connection. As in now you have to pass the end eff through the HST connector by a few inches at least to get a successful grab.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
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

Postby Thorsten » Tue May 19, 2020 5:31 am

What is unclear to me is whether or not that makes sense to do this for the END EFFECTOR A angle. I don't know how to call this angle, but let me try to be clear about that. In the rest frame of the end effector, sitting on it like a horse when it is horizontal (arm stowed), it would be a roll, let's call that roll A.

I would naively say that the real thing, and its wires closing in, is unaware of any relative difference between the A angle of the payload's hook and the one of the end effector (before grabbing of course).
In this picture, I would rather make the END EFFECTOR A angle jumping to the one assumed by the payload's hook rather than the contrary?


The angle definitions work like for an airplane - except that the airplane has the horizon and north as references, the Shuttle has the wing plane and the nose as references.

So any direction you can point the end effector in this coordinate system is a pitch (offset angle relative to the wing plane) and a yaw (direction relative to the nose, or rather tail). Around that direction you can rotate, and that is roll.

So what you're describing is always roll.

Now, the roll joint is the last joint before the end effector, i.e. changing the angle changes none of the other angles by construction - which is why the roll angle decouples from the rest of the computation. You can vary it completely independently.

The thing I do not get then is - why is that a problem? If you never drive the roll angle, it will always remain at zero, the payload grab assumes zero, so there should not be a jump necessary (if you drive the roll angle to 30 degrees, you'll force the payload to jump by 30 degrees when connecting - again, we can require angular matching).

What we can not do is set the end effector angle to any other value, because the end effector roll is known by the Shuttle avionics and displayed as alphanumerics, so the operator can drive it to the required value - but he can't meaningfully do that if we allow anything else to change it.

I probably still misunderstood something, but this is what I understood so far. :D
Thorsten
 
Posts: 11649
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Postby wlbragg » Tue May 19, 2020 6:31 am

why is that a problem? If you never drive the roll angle, it will always remain at zero, the payload grab assumes zero, so there should not be a jump necessary (if you drive the roll angle to 30 degrees, you'll force the payload to jump by 30 degrees when connecting - again, we can require angular matching)

It appears that when you execute a shoulder yaw, it translates that into an end eff roll, if I am explaining the issue in your terms of the end eff being totally uncoupled in its ability to roll.

if you drive the roll angle to 30 degrees, you'll force the payload to jump by 30 degrees when connecting

The payload is jumping by the amount of the shoulder yaw.

If you never drive the roll angle, it will always remain at zero

So no, it appears that the shoulder yaw does change the end eff roll angle.

we can require angular matching

Yes, I think we should to avoid the jump in case you roll the end eff by any means.

@eatdirt
I got reacquainted with the computer and entering commands. I was able to follow sm spec 94, item18-20 + value execute. Verify Good with item 25. But when I switched to AUTO OPR CMD you could see the ARM vibrating (for lack of better description) and software stop. It wouldn't position itself to my input.

I also changed the HST payload connection point to the closest connector. Required repositioning the payload, which I wanted to anyway. I'll push it tonight. I noticed I still need to make a small adjustment in the position of the model.
I verified the yaw problem after grab while deploying is indeed no longer an issue.

Pushed, new connection point is
8.43
0.76
0.60
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
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

Postby Thorsten » Tue May 19, 2020 10:44 am

So no, it appears that the shoulder yaw does change the end eff roll angle.


Please verify that you see a non-zero end effector roll angle displayed on the P/Y/R alphanumerics when doing a shoulder yaw (or clarify what angle is meant).
Thorsten
 
Posts: 11649
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle - Development

Postby eatdirt » Tue May 19, 2020 1:42 pm

If you never drive the roll angle, it will always remain at zero, the payload grab assumes zero, so there should not be a jump necessary


So no, it appears that the shoulder yaw does change the end eff roll angle.


That's what I see too, like Wayne.


Please verify that you see a non-zero end effector roll angle displayed on the P/Y/R alphanumerics when doing a shoulder yaw (or clarify what angle is meant).


Yes it is, R remains equal to 0. But let's call again that roll angle A :) 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! And that's why the payload jumps.

Only auto mode forces that Y value to be set at 0 explicitly. May be that's where the issue is? (I was convinced that P/Y/R where in the Shuttle frame due to this!?)



when I switched to AUTO OPR CMD you could see the ARM vibrating (for lack of better description) and software stop. It wouldn't position itself to my input


Yes, I've tried to explain this before :)
-Either you hit Euler singularity, don't enter pitch values greater than 83 degrees.
-Or this is because you have set the pitch angle in ITEM 21 while having the initial position of the arm too close to the stowed position. You should set pitch last. First you set X,Y,Z, keep pitch=0 and the arm will move to the hook. Then you enter the pitch ITEM 21 +83 and you grab. By default, AUTO OPR CMD first move the attitude of the end effector. So if you enter everything at first, X, Y, Z and pitch, the arm moves only the pitch, keeping its current position X, Y Z fixed. But doing so, close to the stowed position, makes the arm almost immediately going to software STOP (the arm tries to extend the elbow to compensate the loss of X when the end effector pitches down).
eatdirt
 
Posts: 604
Joined: Wed Aug 15, 2018 2:06 pm

Re: Space Shuttle - Development

Postby wlbragg » Tue May 19, 2020 2:24 pm

Yes, I've tried to explain this before
-Either you hit Euler singularity, don't enter pitch values greater than 83 degrees.
-Or this is because you have set the pitch angle in ITEM 21 while having the initial position of the arm too close to the stowed position.

Ah, yes you have. I didn't put two an two together. OK, I was reading the manual and it said enter the x/y/z so I plugged them all in at once.

So no, it appears that the shoulder yaw does change the end eff roll angle.

Wrong choice of words after a long day and not being capable to describe the technical details.
I was trying to get the point across that it "appeared" to change the roll value because we get that jump. If we shouldn't see a jump when the roll angle is at zero then it must be at an angle other than zero. 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.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
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

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 2 guests