-
Notifications
You must be signed in to change notification settings - Fork 196
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
Cannot move GP4 + YRC1000micro with ROS using rostopic pub
or MoveIt + RViz configuration
#472
Comments
Thanks for the detailed issue explanation; I don't see any obvious issues with your approach or your MoveIt config. MoveIt has some dynamic reconfigure parameters relating to trajectory execution that might be causing your issue. You might try turning off |
I'd suggest using code similar to what is linked in #229. I'm slightly confused as well: AFAIK and IIRC, goals with a Additionally, I'd suggest to use motoman_gp4_support which provides convenience Starting the driver then only needs:
nothing more is needed. @adamlouis: please try again with just that And please start it using I'd also suggest updating your Edit: and don't use The MoveIt configuration you've shared includes a |
@marip8 wrote:
If that was with Unless perhaps the joint limits for the specific robot were not configured correctly and whatever parameterised the trajectory is expecting the robot to be able to move faster than it really can. |
Agreed; I'm going to work with the robot more this week, so hopefully I can figure out what is going on. The fix I mentioned might at least get the robot moving in case there are other parameterization/joint velocity limit issues that are MoveIt/URDF related. |
Thank you @gavanderhoorn & @marip8 for you quick replies and suggestions! Here's what I've done & observed: 1. MoveIt duration params
I did this by adding these 2 lines to my MoveIt launch file:
When I do this, I do not get a timeout error, but the robot does not move. 2. use
|
I'm starting to suspect your YRC1000 is somehow not configured correctly. Could you do one more test with the action client script, and make a wireshark trace of the network traffic between the YRC1000 and your ROS PC at the same time? Then please attach it here (make sure to compress it). Additionally:
|
Please also send that CMOS to the Partner Support team in the separate other email chain. They can check to ensure there isn't anything configured that would prevent robot motion. |
There is a parallel support effort, next to this thread? @adamlouis: could you please let us know when that has reached a conclusion? I'll close this one for now, as I don't like potentially duplicating effort. |
@gavanderhoorn: I asked him to open this issue because I didn't see anything wrong with the description of his procedure. It appears that the robot-side is working ok. I figured there was something wrong in the support package that I'm not aware of. I just wanted to have our support group check to make sure there isn't some safety-circuit configured improperly or something. |
Thanks all! I will work on this later today.
I will do this after I send the zip to Yaskawa/Motoman partner support & hear back
Will do later today
As Ted mentioned - I emailed our contacts at Yaskawa. Over that email, I was asked to open the GitHub issue here. Later, I was asked for the same .zip you requested. I will send my zip to partner support & come back here if needed (or to report a resolution). FYI - I have been able to get our robot up & running by programming against the YRC1000 ethernet interface. I suspect I will be able to do our initial task with just the ethernet interface. In any case, I would like to figure the ROS configuration out to support more sophisticated use cases as they emerge. Thanks again! |
@ted-miller wrote:
This all makes complete sense, but please ask people to mention that in the initial post. Especially when things like the CMOS settings haven't been checked yet, as that is almost impossible to diagnose from "the ROS side". Knowing that's being looked at would change the approach to diagnose what's going on. @adamlouis wrote:
I would suggest to still create the wireshark trace. It should not take very long, and there is a good chance we'll be able to diagnose what's going on from that -- provided the CMOS backup shows no problems with the configuration of the YRC1000u itself. |
@adamlouis: let us know whether you'll still create the Wireshark trace and we'll re-open. |
The support guys found that the Inform job was incorrect. (Sorry, I should have caught that.) For anyone experiencing similar issue in the future, please use the standard INIT_ROS jobs posted to GitHub. The motion API command will only work if the control-group is being blocked by a WAIT command. This is a safety mechanism to prevent conflicting motion from multiple points of control. |
How did that happen? Was the job not the one we host here? |
There were 2 issues. The first is resolved. For the second, I have a work around (or perhaps this is how it must be done). 1. error in
|
I realized point 2 in my post above is true when starting other custom pendant jobs with the ethernet interface, not just when starting It seems I must first go to PLAY mode before starting jobs in REMOTE mode. In either case, I think I am unblocked & can figure this out. Thanks all again for your help & for your work on this repo! |
You should be able to start everything in Something does not seem to be right still. |
This sounds like the error came from our manufacturing area. I'll look into it.
This is not normal. Could you please use Wireshark to record the network traffic when you attempt |
Thanks for the feedback! I will try to post the wireshark output by EOD tomorrow. Likewise, I will let you know if we figure out a more minimal set of steps reproduce the behavior. |
Friendly ping @adamlouis |
@gavanderhoorn & @ted-miller - I've attached a zip of my wireshark traffic here. There was a fair amount of data constantly passing between my compute & the yrc1000, but the capture represents a 5-10s window during which I ran I can confirm that my ros terminal printed I have consistently reproduced the behavior I described before & have a few more details. My flow is:
The behavior above is true of other custom jobs I wrote and not just This seems to indicate the issue is with something on the YRC / pendant side vs. on the ROS driver side given that starting jobs in REMOTE mode fails similarly even when not using any of the code in this repo. Thanks again! Let me know if you have any other experiments / evidence you'd like me to capture. |
Seems like MotoROS considers starting
does imply there is something not entirely correct on the YRC1000 side.
Could have been informative if you'd included the traffic when you're attempting to execute a trajectory, but I'm sort-of expecting to just see acceptance of traj pts until the buffer is full and then nothing. |
@adamlouis Can you check that this installation step was done properly:
|
@adamlouis Also check the Operate Enable Settings:
|
@adamlouis Could you please save out a fresh copy of the following files and attach them here. Be sure to zip them; they compress extremely well. INIT_ROS.JBI |
done!
@EricMarcil -- I referenced this in my initial post & the private email thread, but I am using a smart pendant and not a standard pendant. I have not found Do you have documentation to accomplish this with the smart pendant rather than the standard pendant? Are you able to read the necessary data from the system backup rather than the pendant UI? For my own reference -- are the smart pendant & standard pendant two clients of the same controller core, or do the two pendants require different controller configuration? Thank you! |
It's (almost certainly) not the cause of the problem, but I notice you're running MotoROS That's rather old, as the current version would be You might want to upgrade. The binaries can be found here for the YRC1000u. |
This step is not required for the Smart Pendant. The signal must already be enabled for the SP to work. I have updated the installation instructions to hopefully make this clearer.
They are two clients of the same controller core.
Yes. I have found the problem. The job is set to "step" mode where it only executes one step at a time. (I didn't know this was a thing, nor can I explain why it behaves differently in PLAY mode.) Smart Pendant instructions:
|
@adamlouis: I just learned some new information about this issue. The instructions above are not sufficient long-term. It will automatically switch back to Touch From the main menu, touch The touch the power-symbol button in the top right to return back to the Smart Pendant interface. |
@adamlouis: have you had a chance to figure this out? The last comment(s) by @ted-miller should help with the |
Assuming this has been fixed, I'm going to close the issue. Please let us know your current status @adamlouis. |
Hi! I am trying to get a new GP4 robot working with ROS + MoveIt using a YRC1000micro controller.
I can't get to the robot to move ... but I seem close. I would appreciate any help or debugging steps to get our robot moving.
We purchased our robot with the ROS package installed.
summary
Failed to initialize MotoRos motion, trajectory execution ABORTED. If safe, call the 'robot_enable' service to (re-)enable Motoplus motion and retry.
rostopic
commands fail with the same errorrosservice call /robot_enable "{}"
and calling it again does not change the behaviorWhy can't I move the robot?
What simple test can I run to verify configuration of remote control of the GP4 over ROS with the YRC1000?
details
1. set up motoman driver
First, I followed the instructions here: https://wiki.ros.org/motoman_driver/Tutorials/Usage
I start roscore in terminal 1
terminal 1
then, I load the gp4 urdf & joint names
command terminal
then, I run the driver for our controller w/ the robot's pre-set IP
terminal 2
2. run a moveit config
next, I run my move it configuration.
I adapted my configuration from this one in
motoman_experimental
: https://github.com/ros-industrial/motoman_experimental/tree/kinetic-devel/motoman_mpl80_moveit_configMy modifications were:
- replace
mpl80
withgp4
- replace
motoman_mpl_support
withmotoman_gp4_support
- replace
mpl80
urdf & srdf withgp4
urdf & srdf- remove components that duplicate the interface streaming above
- remove
fake_execution
andsim
... because I am trying to test a real robot- remove db ... don't need it for my test
I forked the
motoman_experimental
repo and created a branch here with my motoman_gp4_moveit_config configuration: https://github.com/adamlouis/motoman_experimental/tree/motoman_gp4_moveit_config/motoman_gp4_moveit_configI would be happy to clean that up & find a way to include it in motoman_experimental when I figure out what's wrong.
then, I run it with
terminal 3
at this point, if I move the robot using our teach pendant, the movement is reflected in Rviz.
this is good & tells me that I am able to read state from the yrc1000micro.
3. prepare for execution
now, I am ready to move the robot
command terminal
I hear relays click and see the servo lights turn on
output in command terminal
output in terminal 2
This is good - in theory, I can move the robot.
4. Try to move with RViz + MoveIt
I try to move the robot 2 ways & get the same behavior.
First, in Rviz + MoveIt, I set a goal position. I choose a goal position only small distance from the current position. I click "Plan" and "Execute".
On "Execute", I get the following output:
output in terminal 2
output in terminal 3
If I run the command to enable the service
command terminal
& repeat the above steps, I get the same error.
5. Try to move with
rostopic
It's possible I wrote a bad moveit config, so I try to run some trivial command to move the robot with ROS.
The easiest thing seemed like:
rostopic pub /joint_trajectory_action/goal control_msgs/FollowJointTrajectoryActionGoal
. Is there some simpler command to test "write" commands to the yrc1000 over ROS?This command fails with the same errors as above:
output in terminal 2
output in terminal 3
Here's my full command. The positions I provide are the robot's current positions.
Some notes:
INIT_ROS
is the "Current Job" on the teach pendantSVO
andSTART
- which implies to me remote control is okCMD REMOTE SEL
is set to "valid" in the pseudo input display per page 22 / 291 of the "YRC1000micro OPTIONS INSTRUCTIONS for Ethernet Function". We have a different teach pendant than is referenced in the documentation & I have not found this setting. Is this related? I suspect I am ok, since I could start jobs over the ethernet protocolrobot_interface_streaming_yrc1000.launch
. The warnings seem fine & the errors seems fine per @gavanderhoorn's reply in Failed to find topic_list parameter #242 & Failed to find topic_list parameter #235 ...Thanks for reading & thanks in advance for any help! Would appreciate any pointers to help get us up an running.
The text was updated successfully, but these errors were encountered: