Open gautham-nf opened 3 months ago
@gautham-nf , Sorry for late response.
Move_stop is addressed in the case of motion moving with an asynchronous service.
doosan-robotics@minju:/workspace/doosan_ws$ ros2 service call /dsr01/motion/move_joint dsr_msgs2/srv/MoveJoint "pos:
- 0.0
- 0.0
- 0.0
- 90.0
- 0.0
- 90.0
vel: 30.0
acc: 30.0
time: 0.0
radius: 0.0
mode: 0
blend_type: 0
sync_type: 1"
Please specify sync_type as '1' and check it.
++
#____________________________________________________________________________________________
# move_joint
# The robot moves to the target joint position (pos) from the current joint position.
#____________________________________________________________________________________________
float64[6] pos # target joint angle list [degree]
float64 vel # set velocity: [deg/sec]
float64 acc # set acceleration: [deg/sec2]
float64 time #= 0.0 # Time [sec]
float64 radius #=0.0 # Radius under blending mode [mm]
int8 mode #= 0 # MOVE_MODE_ABSOLUTE=0, MOVE_MODE_RELATIVE=1
int8 blend_type #= 0 # BLENDING_SPEED_TYPE_DUPLICATE=0, BLENDING_SPEED_TYPE_OVERRIDE=1
int8 sync_type #=0 # SYNC = 0, ASYNC = 1
---
bool success
cc @song-ms
Thanks for the response @leeminju531
As you suggested, I tested and the stop service works when I initialize the movement in async
.
In my use case I want to wait for the service.. And stopping the bot would be a separate call.
Is there a way to accommodate both? Or know if the bot is moving.
@gautham-nf
This service seems to be proper to check the bot is moving in async mode.
ros2 service call /dsr01/motion/check_motion dsr_msgs2/srv/CheckMotion "{}"
ref.
#____________________________________________________________________________________________
# check_motion
# return status of the currently active motion.
# Homing is performed by moving to the joint motion to the mechanical or user defined home position.
# According to the input parameter [target], it moves to the mechanical home defined in the system or the home set by the user.
#____________________________________________________________________________________________
---
int8 status # DR_STATE_IDLE(0) : no motion in action
# DR_STATE_INIT(1) : motion being calculated
# DR_STATE_BUSY(2) : motion in operation
bool success
Got it, that helps for now.
In addition to that, having an option to quickly stop the cobot motion via a topic would be extremely helpful.
For example, if I have an action to pick an item from A to B, and then from B to C, I would send these commands in sequence. If we send them asynchronously, the service won't wait for completion between commands. So, if we need to wait for one action to finish before sending the next, we would have to run a loop just to check if it's still moving. That feels a bit excessive.
With a topic for stopping, I could call the service in synchronous mode, where it waits for each task to complete. Then, if we ever need to stop the motion quickly, we could easily manage that for all use cases.
Does that make sense?
@gautham-nf
In a nutshell, the motion service filled with sync_mode 0
also needs to work with move_stop
, which currently only supports sync_mode 1
. this use case makes sense.
However, it seems to support not only our ROS workspace but also the DRCF controller. we will follow up on this internally.
Thanks.
cc: @song-ms @doosan-robotics
Thanks for the response. Will continue to watch this thread for any update on this.
In ROS1 version. there is a topic to stop the robot mid movement. But unable to get this topic in ROS2 implementation.
Also
/motion/move_stop
service to stop the movement is useless as it gets stuck in the thread and does not stop the bot in time.Would the feature to stop the bot be bought back to
humble
soon?