UTNuclearRoboticsPublic / jog_arm

A real-time robot arm jogger.
45 stars 22 forks source link

Robot not moving when publishing to /jog_arm_server/joint_delta_jog_cmds #88

Closed PorkPy closed 5 years ago

PorkPy commented 5 years ago

I am trying to publish joint commands to a UR5 using jog_arm. Each command will be to move 6 joints by +/- 1 degree increments. First of all, I'm finding it difficult to find the correct syntax for publishing to this topic but I have been attempting to use: 'rostopic pub /jog_arm_server/joint_delta_jog_cmds jog_msgs/JogJoint -1 '{stamp: now, frame_id: base_link}' [wrist_3_joint] [10]' For which I get an output: 'publishing and latching message for 3.0 seconds' Echoing the topic gives: 'header: seq: 1 stamp: secs: 1550500372 nsecs: 132920026 frame_id: "base_link" joint_names: [wrist_3_joint] deltas: [10.0]'

So I'm getting an output and /jog_arm_server is connected to /move_group but the robot is not moving. Am I going about this the right way? I don't think sending discreet 1-degree commands to a UR5 should be this difficult. Many thanks.

Edit: if I change the header to: '{seq: auto, stamp: auto, frame_id: auto}' I get: [WARN] [1550506997.124494]: Inbound TCP/IP connection failed: 'Header' object has no attribute 'secs'

Here is my output from rqt_graph image

AndyZe commented 5 years ago

I just spent about an hour trying to re-create this. I think it's a bug with "auto" stamping of ROS messages. Joint jogging works fine if I use a joystick to send the commands. See here.

If you read through the github issue, they recommend adding -s for "substitution". I didn't try this.

As in that answer, I would recommend creating a Python executable to publish messages for testing.

AndyZe commented 5 years ago

Here's the command I was using to try to auto-fill the stamp. Really similar to yours:

rostopic pub -r 125 /jog_arm_server/joint_delta_jog_cmds jog_msgs/JogJoint "header: auto
joint_names:
- 'wrist_3_joint'
deltas:
- 1"

The message from the joystick that works looks like this (no frame_id needed):

header: 
  seq: 2711
  stamp: 
    secs: 1550528481
    nsecs: 533117410
  frame_id: ''
joint_names: [wrist_3_joint]
deltas: [1.0]
PorkPy commented 5 years ago

Thank you for your help. I don’t need to use auto headers, that as just a test to see if it made any different. To be honest I don’t really understand what it does or why it’s needed anyway. How critical is the rate? I see you’re using 125hz. Someone else mentioned using 25hz, but I thought I should be using -1 single action, meaning the robot should move the designated amount once only. Is this true if I’m sending single discreet commands like from the output of a neural network?

AndyZe commented 5 years ago

jog_arm actually expects a frequently-updated message. 25 or 125 Hz should both be fine. There's a "incoming_command_timeout" parameter -- if it doesn't get a new command within that timeframe, it stops. So that's why you need some type of rate, not just a single command.

The scale/joint parameter is radians per control cycle. For us with UR robots, it would be (radians per 0.008s.)

If you wanted to send a single command, maybe MoveIt! would be a better option. You could just set a joint goal.

AndyZe commented 5 years ago

If you don't want to use MoveIt!, just write a node that republishes your neural network output at a constant rate.

PorkPy commented 5 years ago

Originally I did want to use moveit for its collision avoidance, but having used it for a while now it seems like moveit and the UR family don’t really get on. I was consistently given errors saying ‘path planning failed’. When it did move the arm would act like a taxi driver, taking the longest most convoluted route it could find. Changing to the CHOMP and STOMP algorithms made no difference and so I decided to abandon the idea of moveit. Do you know if there is still some self collision avoidance when not using moveit? Singularity avoidance would be nice too.

This might be starting to get a little off topic but yes, I was thinking I would need to write a node that somehow collected the output from my NN, wherever that may be, on Matlab or simply a script or even a ROS node itself, and then perhaps store the results in a distribution table that the node can randomly choose actions from and publish to jog_arm. I’m thinking now that if I use a simple script file for my NN I will need to send the output to a ‘port’ on my local host? Then a ROS node would listen to that port for incoming data? Then I’m thinking, is this how ROS works under the hood? Are the nodes just ports?

Thanks again.

telejesus2 commented 5 years ago

Hi @PorkPy , did you manage to solve this issue ? I am having exactly the same problem on a UR3 robot, my rqt_graph looks like yours and I am publishing to /jog_arm_server/joint_delta_jog_cmds with no movement of the robot.

I doubt it's a header problem in my case since I have no issues publishing to /jog_arm_server/delta_jog_cmds In both cases I use "msg.header.stamp = rospy.get_rostime()" in a python node where msg is either a JogJoint or a TwistStamped message

Thanks !

@AndyZe thank you for your package, the end effector jogging works incredibly well it was really useful for my project

PorkPy commented 5 years ago

@telejesus2 I knew I’d be the one to witness the second coming of Telejesus! Lol. Anyway, I don’t actually recall if I got this working, probably not as I switched to using URScript via the ur_modern_driver. That works brilliantly. I’m sure jog arm would be brilliant too if I could figure it out! What are you working on?

telejesus2 commented 5 years ago

Hi @PorkPy thanks for your reply For now i'm doing visual servoing to control the robot with your arm. So far I have done it by following the hand with the end-effector jogging, but I would like to map other joints like the elbow or the shoulder so I need joint jogging.