UR5+velocity control: runaway robot after getting closer to goal pose
In my algorithm, the robot seemingly moves towards the right position, as the joint velocities reduce, after that the velocities start increasing as the robot moves away. I cannot understand why this is happening and need some urgent help. My github project link is given below: https://github.com/RiddhimanRaut/Ur5_... The object recognition and everything else is working as expected. Also the robot does not stop when I stop the run_ur5.py code, I've checked rostopic echo and joint velocities are still being published. Maybe the two problems are related. Please help.
The codes are all mine.
EDIT 2:
This is a trial velocity publisher I've written just to test the lag issue
#!/usr/bin/env python
import rospy
from ur5_control_nodes.msg import floatList
import rospy
from std_msgs.msg import String
def talker():
pub = rospy.Publisher('ur5_joint_velocities', floatList, queue_size=10)
rospy.init_node('talker', anonymous=True)
while not rospy.is_shutdown():
vels=[0,0,0.05,0,0,0]
pub.publish(vels)
if __name__ == '__main__':
talker()
Code for color detection
#!/usr/bin/env python
import rospy
import numpy as np
import cv2
from sensor_msgs.msg import Image
from ur5_control_nodes.msg import floatList
from cv_bridge import CvBridge, CvBridgeError
import imutils
bridge=CvBridge()
rgb_img=np.zeros((480,640,3),np.uint8)
depth_img=np.zeros((480,640))
#RGB Image Callback
def rgb_callback(rgb_msg):
global rgb_img
rgb_img=bridge.imgmsg_to_cv2(rgb_msg, "bgr8")
#Depth Image Callback
def d_callback(msg):
global depth_img
depth_img=bridge.imgmsg_to_cv2(msg, desired_encoding="passthrough")
#Getting XY Points
def xy_points(frame):
fl=531.15
xypoints=np.array([0,0,0,0,0,0], dtype=np.int64)
blurred = cv2.GaussianBlur(frame, (11, 11), 0)
hsv=cv2.cvtColor(blurred, cv2.COLOR_BGR2HSV)
#defining the Range of Blue color
blue_lower=np.array([87,100,150],np.uint8)
blue_upper=np.array([110,255,255],np.uint8)
blue=cv2.inRange(hsv,blue_lower,blue_upper)
blue = cv2.erode(blue, None, iterations=2)
blue = cv2.dilate(blue, None, iterations=2)
cnts_b = cv2.findContours(blue.copy(), cv2.RETR_EXTERNAL,
cv2.CHAIN_APPROX_SIMPLE)
cnts_b = imutils.grab_contours(cnts_b)
center_b = None
if len(cnts_b) > 0:
c_b = max(cnts_b, key=cv2.contourArea)
# epsilon = 0.1*cv2.arcLength(c,True)
# approx = cv2.approxPolyDP(c,epsilon,True)
M_b= cv2.moments(c_b)
center_b= (int(M_b["m10"] / M_b["m00"]), int(M_b["m01"] / M_b["m00"]))
cv2.circle(frame, center_b, 5, (255, 255,255), -1)
xypoints[2]=center_b[0]
xypoints[3]=center_b[1]
#Red
low_r = np.array([140,150,0],np.uint8)
high_r = np.array([180,255,255],np.uint8)
red=cv2.inRange(hsv,low_r,high_r)
red = cv2.erode(red, None, iterations=2)
red = cv2.dilate(red, None, iterations=2)
cnts_r = cv2.findContours(red.copy(), cv2.RETR_EXTERNAL,
cv2.CHAIN_APPROX_SIMPLE)
cnts_r = imutils.grab_contours(cnts_r)
center_r = None
if len(cnts_r) > 0:
c_r = max(cnts_r, key=cv2.contourArea)
# epsilon = 0.1*cv2.arcLength(c,True)
# approx = cv2.approxPolyDP(c,epsilon,True)
M_r= cv2.moments(c_r)
center_r= (int(M_r["m10"] / M_r["m00"]), int(M_r["m01"] / M_r["m00"]))
cv2.circle(frame, center_r, 5, (255, 255,255), -1)
xypoints[4]=center_r[0]
xypoints[5]=center_r[1]
#Green
low_g = np ...
Two comments:
Thank you for your reply, I've updated the question to include all my codes.
I've reformatted it a bit, but there are still many, many empty lines. Please remove those.
There are quite a few things that could be improved here:
Publisher
s orSubscriber
s inside callbacks orwhile
loops. Create them in the initialisation phase of your program and keep them around. Then reference them when you need them.rate.sleep()
in various locations in your code. Sleeping at random places doesn't make loops or callbacks run at a specific frequency, it just introduces a delay.joint_velocity
topic? Are you using themaster
branch of theur_modern_driver
? If so, please switch tokinetic-devel
and start using theJointGroupVelocityController
3_point_features
) are illegal.Thanks for your reply!
I thought the infinite loop for callbacks could be used for publishing as well. I will rectify that.
I thought we always had to specify the rate of publishing? I had a misconception there, most of the ros codes had it, so I assumed it was necessary. I have now changed it and the delay is a lot less. Not gone completely, but a lot lesser.
Yes I am using the ur_modern_driver package. I will look into that package at my earliest.
I am really sorry for this, I understand that the code has been very messy and I did plan to clean it up once I had the basic program running.
I've seen this...I wasn't really bothered about it because it was just a warning. I'll change that.
I'll update the post once I've worked on that package.
Okay, I cannot figure out how to implement ros_control to replace my ur_modern_driver package. Can you help or guide me in any way? I've gone through the documentations, most of it as well as the package I'm using is in CPP and i'm not very good at cpp. Can I email you, if you wouldn't mind?
That's not what you should do.
Start
ur_modern_driver
inros_control
mode (with the appropriate.launch
file) and start publishing messages to thecommand
topic of theJointGroupVelocityController
after you've madejoint_group_vel_controller
the active controller.No, let's keep this on ROS Answers.
okay so the launch shell code goes something like this
roslaunch ur_modern_driver ur5_bringup.launch robot_ip:=(robot_ip)
I've edited the following ur5_ros_control.launch code, made the changes in the yaml file, but i cannot see any topic named command in the rostopic list. I have edited the question to include the yaml and the launch file.