Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

setTargetPoseRelative not allowing interruption #35

Open
130s opened this Issue · 8 comments

3 participants

@130s
Owner

For instance, run the following 2 commands on ipython terminal back to back without intervals (in particular, notice wait is False). But even though In [59] was returned already on the terminal but arms still moving, looks like In [60] waits for 59 to be done. Once the arm finished moving with 59, 60 finally starts.

Is it an intended behavior? If so, is there a way to interrupt the previous command and get the new one in action?

$ ipython -i `rospack find hironx_ros_bridge`/scripts/hironx.py
:
In [59]: robot.setTargetPoseRelative('larm', 'LARM_JOINT5', dz=-0.09, tm=30, wait=False)
[ 0.32550744  0.18235837  1.0746411 ] [-3.00137594 -1.56900497  3.00122438]
larm None [0.32550744094851297, 0.18235836592382365, 1.0746410958495576] [-3.0013759431884734, -1.5690049671364696, 3.0012243844015924] 30
Out[59]: True

In [60]: robot.setTargetPoseRelative('larm', 'LARM_JOINT5', dz=0.05, tm=2, wait=False)
[ 0.32548581  0.18235465  1.1246795 ] [-2.99326423 -1.56900659  2.99311658]
larm None [0.32548580932689786, 0.18235465271583126, 1.1246795017865097] [-2.9932642260633484, -1.5690065854538964, 2.9931165765312784] 2
Out[60]: True

@emijah

@130s 130s added the question label
@k-okada
Owner

maybe, some function wait for interpolation and some is not. see fkanehiro/hrpsys-base#156

@emijah
Collaborator

@130s, yes it's my fault. I was worried so I included a waitInterpolationOfGroup at the top of setTargetPoseRelative as there was a slight problem with setTargetPose at the very beginning.

I think we can create a test sequence that would allow removing the waitInterpolationOfGroup at the beginning of the function.

@130s 130s added bug and removed question labels
@fkanehiro fkanehiro referenced this issue in fkanehiro/hrpsys-base
Open

setJoint* 関数でwaitの扱いが不定 #156

@130s 130s self-assigned this
@130s
Owner

Bump. Assigning myself (maybe a patch to hrpsys-base?).

@k-okada
Owner

it seems we have waitInterpolation on -> https://github.com/fkanehiro/hrpsys-base/blob/1e9fab7863875fefd3b686ffaae4d1595c9f5b19/python/hrpsys_config.py#L805, I think we do not need this.

By the way, did #35 (comment) works? I have error on that ( I used rtmlaunch hironx_ros_bridge hironx_startup.launch)

In [1]: robot.setTargetPoseRelative('larm', 'LARM_JOINT5', dz=0.09, tm=30, wait=False)
[ 0.32556275  0.18236394  0.16462473] [-3.07322237 -1.56902192  3.07303213]
larm None [0.32556275164378523, 0.18236394191140365, 0.16462472659364472] [-3.0732223717039675, -1.56902192154894, 3.0730321326932279] 30
Out[1]: False
@k-okada
Owner

SORRY THIS COMMENT IS INVALID

In [38]: robot.seq_svc.setMaxIKError(0.0001,0.0001)
In [39]: robot.setTargetPose('larm', [0.32, 0.18, 0.2], [-3.0,-1.56,0.07], 10)

works, I'm using 315.1.9 + 1.0.11 ( does this fixed in 315.2.0???)

@k-okada
Owner

the reason we put waitinterpolation is discussed here-> start-jsk/rtmros_common#209 have to more close look at that.

@130s
Owner

@emijah So how would you conclude if we want to address this issue? Could you help me since I'm a bit confused?

In another ticket you reported that waiting at the beginning of setTargetPose is necessary.

But within this ticket you said you were wrong:

yes it's my fault. I was worried so I included a waitInterpolationOfGroup at the top of setTargetPoseRelative as there was a slight problem with setTargetPose at the very beginning.

@emijah
Collaborator

When I first tested this, when setTargetPose was just released for the first time, I tried to see what happens when I do a setTargetPoseRelative(dz=100[mm]) while the previous setTargetPoseRelative(dz=100[mm]) is running.
If the robot moved less than 200mm I would have been happy, However, it looked like you got the next position the robot would move to back from FK so the second command caused the robot to move faster.
setJointAnglesOfGroup can be called with good results, but I think we need to check whether

setTargetPose->setTargetPose
setJointAnglesOfGroup->setTargetPose

combinations can cause trouble.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.