Skip to content


Subversion checkout URL

You can clone with
Download ZIP


setTargetPoseRelative not allowing interruption #35

130s opened this Issue · 8 comments

3 participants


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/
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


@130s 130s added the question label

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


@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

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

@130s 130s self-assigned this

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


it seems we have waitInterpolation on ->, 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


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???)


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


@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.


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


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.