setTargetPoseRelative not allowing interruption #35

Open
130s opened this Issue Mar 6, 2014 · 8 comments

Projects

None yet

3 participants

@130s
Member
130s commented Mar 6, 2014

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 Mar 6, 2014
@k-okada
Member
k-okada commented Mar 6, 2014

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

@emijah
Collaborator
emijah commented Mar 7, 2014

@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 Mar 10, 2014
@fkanehiro fkanehiro referenced this issue in fkanehiro/hrpsys-base Apr 11, 2014
Open

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

@130s 130s self-assigned this May 12, 2014
@130s
Member
130s commented May 12, 2014

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

@k-okada
Member
k-okada commented May 13, 2014

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
Member
k-okada commented May 13, 2014

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
Member
k-okada commented May 16, 2014

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

@130s
Member
130s commented Jun 18, 2014

@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
emijah commented Jun 18, 2014

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