Closed dean4ta closed 2 years ago
Could you please describe your setup more? Is this a single- or multi-group robot, how are you starting things, which .launch
files are you using?
And if possible, a minimal script which reproduces what you're reporting.
References to code I cannot access complicate diagnosing what's going on.
Hi thanks for the support, I will get you more concise setup information and how we are launching things later today. In the meantime, I was having difficulty finding where the Action Server actually sends results using methods like: action_server.set_succeeded(result)
, action_server.set_preempted()
, action_server.set_aborted()
. Where are these resutls set?
edit:
I found where the goals are accepted/succeeded. they are using method names different from the python API setSucceeded()
and other camelcase examples
motoman_driver
is not written in Python, so I'm not surprised you couldn't find the methods you mention.
Okay so I gathered some data after launching the motoman drivers and Trajectory action server with the following:
top-level launch file:
joint_state_filter
node is meant to combine the published joint_states from the yaskawa arm and a slider rail into one message. (This step complicates the answer if we are using a single group or multigroup robot)
The motoman_adapter.launch
file launches one additional node that reads yaskawa alarms and interfaces with some IO.
The action client node was launched standalone with rosrun to create a trajectory consisting of 3 point with the first and third points being the starting position of the arm.
I conducted two tests: one with the robot completing the trajectory and one with the robot experiencing a collision part way. In both cases, the result ends the same with a goal status of 9
or LOST
and a result of None
.
Test 1 data:
Test 2 data:
There is also a bag file for each of the tests in the included zip: relevant_bags.zip
One thing worth noting is that when recording "all the topics" most of the action related topics had 0 messages to them and therefore did not show up in the bag recordings.
here is a list of the topics from a rostopic list
:
and a quick rosbag info on bag using: rosbag info all_topics_motoman_traj_action-collision_2022-02-03-05-32-01.bag
results in:
I hope this isn't too much information. Thanks
thanks for all the information.
This step complicates the answer if we are using a single group or multigroup robot
You have a multi-group system. I'm not really concerned with the ROS side. MotoROS and the configuration of the Yaskawa controller determine whether you have a multi-group system or not.
The fact you mention you have an R1
and an S1
already imply you have a multi-group system.
joint_state_filter
node is meant to combine the published joint_states from the yaskawa arm and a slider rail into one message.
I'm a little confused as to why this is necessary.
motoman_driver
publishes combined JointState
s for all defined groups on /joint_states
(together with separate publishers for each configured group).
Could you summarise why you found the extra script necessary?
What about the source_list
parameter of a regular joint_state_publisher
instead?
# The group numbers below are define in gp7_motion_interface.yaml file # That file specifies R1+S1 as Group 0, and S1 as Group 1. GROUP_R1S1 = 0 # R1S1 - GP7 arm and rail motor GROUP_S1 = 1 # S1 - station motor (rail motor)
could you clarify how your controller is configured?
Afaik MotoROS should report the joints in R1 in a message, and the joints of your S1 in a message, and the combination of those. motoman_driver
then converts those to separate messages on the joint_states
topics for each respective group and a single, combined JointState
message for everything together.
@ted-miller @EricMarcil: is it possible for MotoROS to do what the comment states (ie: have a joint in two groups)?
# Get joint states for R1S1 and S1. Note that GROUP_R1S1 doesn't contain info on # S1 joint position. Must grab that info specifically from GROUP_S1. This is an # idiosyncrasy of the ROS driver for the GP7.
this comment also confuses me, but perhaps you'll clear that up when you explain the need for the custom joint_state_filter
script.
<rosparam command="load" file="$(find yaskawa_robot_hw_interface)/config/joint_names_gp7.yaml" /> <rosparam command="load" file="$(find yaskawa_robot_hw_interface)/config/gp7_motion_interface.yaml" />
you don't need both of these. Either you have a multi-group system and use the topic_list
(ie: "motion interface .yaml
"), or you don't, and you use controller_joint_names
.
yaskawa.launch
: lots of remapping
I would recommend to see what the behaviour is if you remove all the remaps, and use a simple action client like shown in https://github.com/ros-industrial/motoman/compare/kinetic-devel...gavanderhoorn:actionclient_example.
If you want to namespace "everything yaskawa" in a yaskawa
namespace, could you perhaps just include
the relevant .launch
files with a ns="yaskawa"
attribute?
please:
rqt_graph
. I'm wondering whether there are incorrect connections due to the remaps you've introducedroslaunch --screen /path/to/yaskawa.launch
(or via the package it is in, doesn't matter). We don't need everything, but make sure to copy-paste all lines originating from the nodes in motoman_driver
.yaskawa_robot_hw_interface/config/gp7_motion_interface.yaml
joint_state_filter
motoman_driver
and MotoROS
(ie: the traffic between the Yaskawa controller and the ROS nodes when executing a trajectory)# The group numbers below are define in gp7_motion_interface.yaml file # That file specifies R1+S1 as Group 0, and S1 as Group 1. GROUP_R1S1 = 0 # R1S1 - GP7 arm and rail motor GROUP_S1 = 1 # S1 - station motor (rail motor)
@ted-miller @EricMarcil: is it possible for MotoROS to do what the comment states (ie: have a joint in two groups)?
No, not with the ROS interface.
On the teach pendant, there are "group combinations" that can be defined. These can appear to be a single group when programming an Inform job. However, they are distinct separate groups at a lower level.
As you stated above, the MotoROS interface will send three feedback messages to motoman_driver
. One for R1, one for S1, and one with both groups.
To elaborate a little more, it can be little extra confusing when using a rail mounted to the robot's base. The rail is implicitly linked to R1 without defining a "group combination". This makes it part of the robot's kinematic chain. But, the rail is still an independent group at the lowest level.
Yes, that's how our YRC1000 is also configured (GP25 on a TSL-1000).
Hi, I'm another engineer working on the same project as @dean4ta - we were able to strip down our code to create a more concise example of the error we experienced, incorporating the advice we've received so far. Hopefully this helps explain what we are seeing and what is going wrong.
Starting the launch file, we see the output:
[INFO] [1644281698.999809 /joint_traj_client] [/root/workspace/src/miso-robot-driver-stack/yaskawa_robot_hw_interface/nodes/joint_traj_client:main:52]: Waiting for driver's action server to become available ..
[INFO] [1644281699.222412 /joint_traj_client] [/root/workspace/src/miso-robot-driver-stack/yaskawa_robot_hw_interface/nodes/joint_traj_client:main:54]: Connected to trajectory action server
[INFO] [1644281699.274133 /joint_traj_client] [/root/workspace/src/miso-robot-driver-stack/yaskawa_robot_hw_interface/nodes/joint_traj_client:joint_state_cb:41]: Got rail message
[INFO] [1644281699.274389 /joint_traj_client] [/root/workspace/src/miso-robot-driver-stack/yaskawa_robot_hw_interface/nodes/joint_traj_client:joint_state_cb:36]: Got arm message
[INFO] [1644281699.324443 /joint_traj_client] [/root/workspace/src/miso-robot-driver-stack/yaskawa_robot_hw_interface/nodes/joint_traj_client:main:72]: Got full state
[INFO] [1644281699.324679 /joint_traj_client] [/root/workspace/src/miso-robot-driver-stack/yaskawa_robot_hw_interface/nodes/joint_traj_client:main:102]: Waiting for robot to be active
And after we send a rosservice call robot_enable
in a separate terminal, we see the following output:
[INFO] [1644281704.761014 /joint_traj_client] [/root/workspace/src/miso-robot-driver-stack/yaskawa_robot_hw_interface/nodes/joint_traj_client:main:106]: Robot active!
[INFO] [1644281704.761187 /joint_traj_client] [/root/workspace/src/miso-robot-driver-stack/yaskawa_robot_hw_interface/nodes/joint_traj_client:main:110]: Submitting goal ..
[INFO] [1644281704.761398 /joint_traj_client] [/root/workspace/src/miso-robot-driver-stack/yaskawa_robot_hw_interface/nodes/joint_traj_client:main:112]: Waiting for completion ..
[INFO] [1644281710.138613 /joint_traj_client] [/root/workspace/src/miso-robot-driver-stack/yaskawa_robot_hw_interface/nodes/joint_traj_client:main:114]: Done.
[INFO] [1644281710.139182 /joint_traj_client] [/root/workspace/src/miso-robot-driver-stack/yaskawa_robot_hw_interface/nodes/joint_traj_client:main:115]: Action server state: 9
[INFO] [1644281710.139769 /joint_traj_client] [/root/workspace/src/miso-robot-driver-stack/yaskawa_robot_hw_interface/nodes/joint_traj_client:main:116]: Action server result: None
While waiting for completion, all joints do successfully move as we would expect. However, we get the LOST state (9) when querying the action server state, rather than SUCCEEDED (3). We also get the LOST state when terminating the trajectory early, such as through an e-stop.
Thanks for the update, but I'd still like to see:
rqt_graph
screenshot, andmotoman_driver
nodes when you start everything with roslaunch --screen ...
def joint_state_cb(msg): # Find the starting position of all joints among the two groups # This is just a hacky way to get the entire robot's initial joints without # having to set up a joint_state_publisher, which eliminates some # potential issues for this simple test global arm global rail global start_pos if not arm and 'joint_1_s' in msg.name: arm = True rospy.loginfo('Got arm message') for i in range(6): start_pos[i] = msg.position[i] elif not rail and 'joint_1_rail' in msg.name: rail = True rospy.loginfo('Got rail message') start_pos[6] = msg.position[0]
this should not be necessary, provided you subscribe to the correct topic.
On my personal setup, I use a single rospy.wait_for_message('joint_states', JointState)
which gets me the full JointState
, including the track.
The /joint_states
topic should publish messages containing the full JointState
. The /gp7/gp7_yrc1000_r1/joint_states
topic should carry messages containing just the JointState
s of the gp7_yrc1000_r1
group, and the /gp7/gp7_yrc1000_s1/joint_states
should have them for just the gp7_yrc1000_s1
group.
Does that not work for you?
Seeing as you have a multi-group system, it's likely you're being bitten by what #259 attemps to fix. It's not complete (hence why it hasn't been merged), but there's a good chance it'll resolve the lost goals.
Hi @gavanderhoorn , I'm not sure why, but we are not seeing the /joint_states message containing all joint states in one frame. Would that data be originating from the MotoROS Application or is that something the motoman_driver will generate and publish to the /joint_states topic?
Please provide me with at least the wireshark trace, so we can rule out a couple of things.
I'd also still like the rest of the items I described in https://github.com/ros-industrial/motoman/issues/450#issuecomment-1031460588.
Friendly ping
Closing due to inactivity.
I'd still be interested in diagnosing this, but without more information, that's going to be difficult.
Hi @gavanderhoorn, sorry for the late response. Sorry for the late response. Will send you info in the next day or two. Thanks for following up.
Just checking you've resolved the issue.
Yes, we've applied similar changes to the issue you mentioned in #259. We were able to resolve the lost goals. Thank you.
we've applied similar changes
I'd be interested to know exactly which changes. That could help resolve it here as well.
Edit: I don't see a fork of motoman
on github.com/orgs/MisoRobotics.
Friendly ping?
And another ping.
And another friendly ping.
@dean4ta @nardavin @rsrisamang-miso: could you please respond to my request?
And another ping.
I would be also interested in this info, could you elaborate @rsrisamang-miso? See also my comment https://github.com/ros-industrial/motoman/pull/259#issuecomment-1074784596
You may be interested in the combination of https://github.com/ros-industrial/motoman/compare/kinetic-devel...gavanderhoorn:coalesced_joint_feedback_ex_relay and https://github.com/ros-industrial/motoman/compare/kinetic-devel...gavanderhoorn:rebased_two_arms_on_a_rail as well @dean4ta @nardavin @rsrisamang-miso
NOTE: this is not a complete solution. There are additional issues to address. I just want to test on more than my own hw config.
Hi all, sorry for leaving everyone hanging on this. Our changes have been in a constant state of "mostly working" for the last couple weeks, but we believe that our version of the motoman driver is now stable and correctly supports multigroup motion, at least for our hardware configuration. I'll make a PR in the next couple days once we have final approval on our end.
A pointer to a branch should be enough.
Friendly ping @nardavin
Context
When sending trajectories to a Yaskawa GP7 using an action server hosted by the joint_trajectory_action.cpp, the status goes from ACTIVE to LOST (see GoalStatus msg) regardless of the trajectory executed by the arm is a "success" (gets to its desired final position) or is interrupted by an e-stop or collision.
Process
We bring up an Action Client to the Action Server provided by Yaskawa and send a goal that executes as expected. We read the state output and it changes from ACTIVE to LOST.
partial code from the client side:
Terminal Output
What we are seeing is a log of the state when the robot arm achieves its trajectory.
it is worth noting that
Trajectory state: 1
means status is "ACTIVE" andTrajectory state: 9
means status is "LOST". You can also see there was adone_cb
for the action client that printed the status and resultExpected Results
I was expecting the Motoman's ActionServer to output the status "SUCCEEDED" when the trajectory was achieved and "ABORTED" or "PREEMPTED" on collision and e-stop.
Where I am at
I did not get very far, but I traced the launch file robot_interface_streaming_yrc1000.launch to this node implementation joint_trajectory_action.cpp where the Action Server is hosted, but I do not see where the result or status is handled or sent.
Thanks