University of Southern CaliforniaUSC
USC ICT TwitterUSC ICT FacebookUSC ICT YouTube

Grabbing a cube | General SmartBody Discussion | Forum

Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Grabbing a cube
January 15, 2016
6:01 am
Avatar
Germany
Member
Members
Forum Posts: 24
Member Since:
June 22, 2015
sp_UserOfflineSmall Offline

Hello,

I currently try to let Brad grab a cube an hold it in his hand. I tried to do it in a inverse kinematics fashion, by moving the cube and a corresponding SBPawn with an identical collision shape around.

I trigger the grabbing with the following code

<sbm:reach sbm:action="grab" target="cube_pawn" sbm:reach-finish="false" sbm:reach-duration="2.0"/>

However, there are two issues that I experience:

1. Can I somehow fix the grabbing point? Because when I move the cube around Brad's hand slides around my cube in an unnatural fashion, while I would like the hand to be fixed to the cube in the way it was when it first touched and grabbed the cube even if I translate and rotate the cube.

2. Is there a way to find out whether the hand has already touched the cube? Because when I start the animation of the cube at the same moment as sending the grab command, the cube flies around before the hand has reached it. Maybe I can define a callback method or poll to see if the hand has already touched it?

 

Thank you very much for any help.

January 20, 2016
5:20 am
Avatar
Germany
Member
Members
Forum Posts: 24
Member Since:
June 22, 2015
sp_UserOfflineSmall Offline

Hello,

I found a solution to the second problem. Unfortunately the method SBReach::isPawnAttached() does not work in the way I expected it to do, because the target pawnName seems not to be updated. However, I wrote one myself that is guided by that method

std::map<int,MeCtReachEngine*> engines = GetReach(charname)->getReachEngineMap();
    for (ReachEngineMap::iterator mi = engines.begin();
        mi != engines.end();
        mi++)
    {
        MeCtReachEngine* re = mi->second;
        if (re)
        {
            ReachStateData* data= re->getReachData();
            ReachTarget reachTarget = data->reachTarget;
            if(reachTarget.getTargetPawnName() == pTarget->getName()) //unfortunately comparing the pawn pointer directly is not working
                return data->ikReachTarget;
        }
    }

This ikReachTarget member seems however to not be the optimal choice, because it is not immediately reset to 0 after a new reach is triggered but is set to 1 once the target is reached, so that works for me.

 

Still my first problem with a not fixed grabbing point remains. I thought about manually updating the hand position, but I am not sure where to do this as SBSkeleton only provides getter for the joints and whether this would destroy the whole animation. Hopefully you can point me in some direction towadrs a solution.

January 20, 2016
5:44 am
Avatar
Germany
Member
Members
Forum Posts: 24
Member Since:
June 22, 2015
sp_UserOfflineSmall Offline

Oh, I have just seen that I could have as well used Reach Events to handle the second problem. I will give that as well a try.

January 20, 2016
11:27 am
Avatar
Admin
Forum Posts: 52
Member Since:
August 8, 2012
sp_UserOfflineSmall Offline

Hi Jonathan,

The reason Brad's hand posture will change when the cube is moving is because the hand pose is interpolated from a database of example reaching poses based on cube's position. This is a design choice to ensure that both the body and hand pose would be more reasonable when the cube is in a different relative positions to Brad. If the hand orientation is fixed, it can result in a very unnatural hand pose depending on where the cube is placed. 

If you want to have more control over the IK target and fix the grabbing point, the "sbm:constraint" command may work better for you. It is basically a IK controller that can fix an end effector joint to a particular position and orientation.  You can check "ConstraintDemo.py" example for more usage.

Let me know if you have any questions.

Andrew

January 26, 2016
4:45 am
Avatar
Germany
Member
Members
Forum Posts: 24
Member Since:
June 22, 2015
sp_UserOfflineSmall Offline

Hi,

thanks, that sounds like a very good idea. So I tried integrating constraints.

However, somehow it does not like the way I use handles... I execute:

sbm:handle="myHandle" target="Cube_0"/>

Something seems to be wrong, because I get the following errors;

XML-ERR: att:'sbm:handle'; val:"myHandle"; tag:

BML::parse_bml_constraint ERR: Handle: 'myHandle': controller not found.

However, the constraint seem to be working and this error message only comes the first time I use this handle, so is this actually the correct way to use it?

January 26, 2016
10:22 am
Avatar
Admin
Forum Posts: 52
Member Since:
August 8, 2012
sp_UserOfflineSmall Offline

Hi Jonathan,

That message is actually normal. It means the constraint controller with the handle name "myHandle" does not exist for the character, and thus the system will create a new one. This is why it only shows up the first time the command is called. Thus this message should not cause a problem as it is a warning instead of error.

Andrew

January 29, 2016
3:46 am
Avatar
Germany
Member
Members
Forum Posts: 24
Member Since:
June 22, 2015
sp_UserOfflineSmall Offline

Thank you for your help, the constraints seem to be exactly what I need. However, while the position constraint works as expected (with a pawn position in world coordinates), I have problems with the rotational constraint using sbm:constraint-type="pos". Do I have to be carfull to have the rotation quaternion of the pawn in some special coordinate system? Because what happenns is that the hand is rotated in a very weird fashion away from the pwan, so that it is not attached to it at all anymore. I rotate the pawn about 90° around the x-Axis. However, as soon as some rotation happens the hand is moved away from the pawn and positioned that the back is facing towards +Z although +Y would have been correct and then it rotates 90° around the z-Axis. and at some points jumps around position wise.

 

Any ideas what my problem could be? Can the problem be that I simply cast my internal Quaternion which is (x,y,z,w) to QrQuat by SrQuat(newOri[0], newOri[1], newOri[2], newOri[3]), because yours ist w-first?

January 29, 2016
10:17 am
Avatar
Admin
Forum Posts: 52
Member Since:
August 8, 2012
sp_UserOfflineSmall Offline

Hi Jonathan,

I think the quat conversion could be the problem. The SrQuat is constructed as (w,x,y,z). Thus if you put the parameters this way, the rotation should work. 

If this doesn't solve the problem, you can provide me the character configuration script and BML command you are using. I can look into the issue from my end.

Thanks,

Andrew

February 3, 2016
5:30 am
Avatar
Germany
Member
Members
Forum Posts: 24
Member Since:
June 22, 2015
sp_UserOfflineSmall Offline

Hello,

that was at least part of the Problem 😉 So what I actually want to do is, let Brad reach for the cube then remove the reaching and use Constraints to attach the hand to the cube while I animate it (the cube) and then put it back and let reaching do the rest for me (move the arm back)

So my commands are

<sbm:reach sbm:action="pick-up" sbm:handle="Worker1_reach" target="cubePawn" sbm:reach-finish="false"/>

once I get the pawn attached event:

<sbm:constraint effector="r_wrist" sbm:effector-root="r_sternoclavicular" sbm:handle="Worker1_r_wrist_rotConst" target="cubePawn" sbm:constraint-type="rot" sbm:fade-in="0.01" />

<sbm:constraint effector="r_wrist" sbm:effector-root="r_sternoclavicular" sbm:handle="Worker1_r_wrist_posConst" target="cubePawn" sbm:constraint-type="pos" sbm:fade-in="0.01" />

<sbm:reach sbm:handle="Worker1_reach" sbm:action="pick-up" sbm:reach-finish="true"/>

after the cube animation has finished and it is laid back

<sbm:constraint sbm:handle="Worker1_r_wrist_rotConst"  effector="r_wrist" sbm:effector-root="r_sternoclavicular" target="cubePawn" sbm:constraint-type="rot" sbm:fade-out="0.001"/>

<sbm:constraint sbm:handle="Worker1_r_wrist_posConst" effector="r_wrist" sbm:effector-root="r_sternoclavicular" target="cubePawn" sbm:constraint-type="pos" sbm:fade-out="0.001"/>

<sbm:reach sbm:action="pick-up" sbm:handle="Worker1_reach" target="cubePawn" sbm:reach-finish="false" sbm:reach-duration="0.01"/>

 

I basically have two issues with that. The constraints do not work both at the same time. Is that normal or is there one that does pos and rot at the same time? they are not really described with much detail in the manual. Also if I use these two constraints with two different handles I continiously get :

XML-ERR: att:'sbm:handle'; val:"Worker1_r_wrist_rotConst"; tag:<sbm:constraint .
../>

BML::parse_bml_constraint ERR: Handle: 'Worker1_r_wrist_rotConst': controller no
t found.

And the second problem is that when the cube is laid back and the arm should be moved smoothly back to the neutral position it is moved there directly and a few frames later it jumps up for one frame again. So am I doing it right in turning off the reach to let it smoothly handle the hand from there on? And can I turn off an constraint in this way? Or can I ommit some of the data fields when I want to just turn it off, so far if I left some of them out it wasn't able to understand the bml command at all.

 

Thank you,

Jonathan

February 5, 2016
11:24 am
Avatar
Admin
Forum Posts: 52
Member Since:
August 8, 2012
sp_UserOfflineSmall Offline

Hi Jonathan,

I believe the position and rotation constraints can be applied at the same time. Thus the way you are using the constraint is fine to have the same constraint controller ( with the same handle ) using both constraints. Also, the message "...controller no
t found..." means you have created another constraint controller with a different handle name, and thus a new one need to be created. ( This is actually a warning instead of error, which we should change in our code. )

As for the second problem, I don't think it would work well to mix constraint controller with reach controller during reach 'pick-up' or 'put-down' stage. Since reach controller also uses an IK solver and has its own logic to attach/detach pawn to the character, it may cause problems when combining with constraint controllers.  

If what you want is to have Brad's arm moving with the cube but still keep the reach to/return motion, I think it's better to use sbm:action="touch" when doing the reach. This way the pawn won't be attached to the character and you can apply constraints without problems.

Here are some sample commands I test :

First, apply reach with action="touch" to reach for cube

<sbm:reach sbm:action="touch" sbm:handle="Worker1_reach" target="cubePawn" sbm:reach-finish="false"/>')

Apply rotation/position constraint to fix the wrist. Here we can use the same handle name for constraint controller.

<sbm:constraint effector="r_wrist" sbm:effector-root="r_sternoclavicular" sbm:root="r_sternoclavicular" sbm:handle="Worker1_r_wrist_Const" target="cubePawn" sbm:constraint-type="rot" sbm:fade-in="0.01" />
<sbm:constraint effector="r_wrist" sbm:effector-root="r_sternoclavicular" sbm:root="r_sternoclavicular" sbm:handle="Worker1_r_wrist_Const" target="cubePawn" sbm:constraint-type="pos" sbm:fade-in="0.01" />

Then the cube can be moved around and the character's arm will follow.

Then deactivate the constraint first.

<sbm:constraint sbm:handle="Worker1_r_wrist_Const" effector="r_wrist" sbm:root="r_sternoclavicular" sbm:effector-root="r_sternoclavicular" target="cubePawn" sbm:constraint-type="rot" sbm:fade-out="0.001"/>
<sbm:constraint sbm:handle="Worker1_r_wrist_Const" effector="r_wrist" sbm:root="r_sternoclavicular" sbm:effector-root="r_sternoclavicular" target="cubePawn" sbm:constraint-type="pos" sbm:fade-out="0.001"/>

Then finally finish the reach.

<sbm:reach sbm:handle="Worker1_reach" sbm:action="touch" sbm:reach-finish="true"/>

Let me know if you have any questions.

Andrew

February 10, 2016
5:22 am
Avatar
Germany
Member
Members
Forum Posts: 24
Member Since:
June 22, 2015
sp_UserOfflineSmall Offline

Thank you very much for this elaborated answer. That solved nearly all of my problems. Especially knowing that I can use the same handle for rotational and positional constraints.

The only problem that remains for me is that if have one flickering at the end of the movement (when he moves back to the neutral position). That means that after the constraint is removed it seems all to work well and then a few frames later the constraint seems to kick in for one more single frame. Have you ever heard of comparable issues or any ideas what might go wrong. I use exactly the commands you wrote above. Or is there maybe another way to stop constraints (like there is for reaching) than having it fade-out with a small time. A fade-out time of 0.0 crashes the system.

Thank you again for this very specific and valuable help you are providing here in the forum.

Jonathan

February 19, 2016
12:42 pm
Avatar
Admin
Forum Posts: 52
Member Since:
August 8, 2012
sp_UserOfflineSmall Offline

Hi Jonathan,

I guess it may be related to the short fade-in time. If you increase the fade-in time ( say ~ 0.2 ), it should make a smoother transition of constraint enable/disable. This may reduce the flickering artifacts. Otherwise I would need to look into the code to check what is causing the flickering.

Let me know this helps. I can look into this further if you can send me the scripts you are using too.

Thanks,

Wei-Wen