Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Robot Stop feature not available. /stop topic not found #82

Open
gautham-nf opened this issue Jul 29, 2024 · 6 comments
Open

Robot Stop feature not available. /stop topic not found #82

gautham-nf opened this issue Jul 29, 2024 · 6 comments

Comments

@gautham-nf
Copy link

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?

@leeminju531
Copy link
Contributor

@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

@gautham-nf
Copy link
Author

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.

@leeminju531
Copy link
Contributor

@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 

@gautham-nf
Copy link
Author

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?

@leeminju531
Copy link
Contributor

@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

@gautham-nf
Copy link
Author

Thanks for the response. Will continue to watch this thread for any update on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants