Try to avoid starting anything in abb_driver directly when working with a particular robot. launch files in that package for your variant ( these launch files). Create a proper robot support package.Įven better: extend abb_irb2600_support and add your variant there. launch files (or anything really) to the abb_driver package. You could use motoman_driver/examples/simple_trajectory_action_client.py as inspiration.Īdditional comment: do not add URDFs nor custom. I don't have an example for abb_driver specifically, but that would also not be needed: the action server and client are generic. launch file is starting all the required parts, and the IRC5 is executing the required programs, I would expect that to work.
The normal way to interact with the driver is to write an action client which constructs a goal (with a JointTrajectory) and then submits that goal to the action server (which is exposed by the joint_trajectory_action node in your. I wrote a python script publishing a JointTrajectory msg on that same topic (confirmed with 'rostopic echo' command The motion task must be running as well, as that is the task which will actually execute the motion (the motion server only handles network traffic).Įdit: from the roslaunch output and the TP lines you commented it looks like everything is connected. Note: having a connection is not sufficient. Please check the steps in the Robot Motion Task section of wiki/abb_driver/Tutorials/RunServer and make sure the motion task is running, as otherwise no motion can be executed. Second thing to check: is the motion task actually running? (more)īut "/motion_download_interface" node seems to ignore itĭo you see the "client at X.X.X.X connected" message twice on th teach pendant? Once for the state server, and another time for the motion server? : Added message handler for message type: 10. : Added message handler for message type: 1
: Default communications fault handler successfully initialized : Initializing message manager with default comms fault handler : Found user-specified joint names in 'controller_joint_names': : Added message handler for message type: 0 ROS_MASTER_URI= process: started with pid Motion_download_interface (abb_driver/motion_download_interface) Joint_trajectory_action (industrial_robot_client/joint_trajectory_action) This may take a while.ĭone checking log file disk usage. logging to /home/jonathan/.ros/log/fa13eac8-dbd5-11ea-b6a8-74dfbfc383e1/roslaunch-ROS-Ubuntu-11962.logĬhecking log directory for disk usage. since in the urdf robot_description,, joints are named 'joint_1','joint_2' roslaunch abb_driver robot_interface.launch robot_ip:=192.168.1.28 -screen The launch file is given also (see after the verbatim of the console, it comes from the orginal abb_driver package, I just added a call to yaml file that gives the name of the joints 'rob1_1', 'rob1_2'. Here-under is the command and console info.
Would you please help find what is missing and how to fix it ? Thanks in advance, best regards !
But "/motion_download_interface" node seems to ignore it (no ROS_INFO msg on screen saying "Receiving joint trajectory message" as expected according to source code in. ) that publishes a JointTrajectory msg on that same topic (confirmed with 'rostopic echo' command).
The "/motion_download_interface" node is running (confirmed with 'rosnode list' command and ROS_INFO msg on the screen of the ROS PC ), it subscribes to the "/joint_path_command" topic (confirmed with 'rostopic info' command). I followed the instructions given in abb_driver tutorials (, ) and it seems to works correctly : at least, joint states are correctly received on the ROS PC upon the topic /joint_states (confirmed with 'rostopic echo' command) when I move links on RobotStudio PC. Several print screens from RobotStudio help to understand in a better way the process to operate RobotStudio and create robot programs off-line.I'm trying to have a virtual IRB2600 run on RobotStudio (v2020.1 64 bits) perform a joint trajectory thanks to the ROS abb_driver package (using ROS melodic on Ubuntu). All the necessary procedures to create a given robot application are described, step-by-step. It is divided in 4 modules in which each module is a different exercise.
This guide contains the basic commands to start using ABB RobotStudio. This guide/manual explains step-by-step the most common functionalities of RobotStudio.ĭepartment of Mechanical Engineering (POLO II), University of Coimbraġ.