# Revision history [back]

I launched the demo of the Abb_irb6640_moveit_config package [..]

demo.launch is not a launch file you would use for controlling a real robot or for visualising a real robot's state.

It's -- as the name implies -- a demo setup that you may use to test MoveIt's functionality with a particular robot's (urdf) model.

[..] but I am confused on how to control it by reading joint_states.

I'm not sure what you mean by this. JointState messages are intended to be used to report joint state, not to command it.

I launched the demo of the Abb_irb6640_moveit_config package [..]

demo.launch is not a launch file you would use for controlling a real robot or for visualising a real robot's state.

It's -- as the name implies -- a demo setup that you may use to test MoveIt's functionality with a particular robot's (urdf) model.

[..] but I am confused on how to control it by reading joint_states.

I'm not sure what you mean by this. JointState messages are intended to be used to report joint joint state, not to command it.

I launched the demo of the Abb_irb6640_moveit_config package [..]

demo.launch is not a launch file you would use for controlling a real robot or for visualising a real robot's state.

It's -- as the name implies -- a demo setup that you may use to test MoveIt's functionality with a particular robot's (urdf) model.

[..] but I am confused on how to control it by reading joint_states.

I'm not sure what you mean by this. JointState messages are intended to be used to report joint state, not to command it.

Edit:

My aoplogies, I want to use the joint_state feedback data from the physical robot to move the robot model in RViz,simply as a way to visualize what is happening to the real robot.

Ok. That should not be too hard, seeing as you already are publishing JointState messages.

Components involved in visualising robot state:

1. rviz
2. robot_state_publisher
3. a JointState publisher
4. a urdf/xacro for the robot model (more of a passive component, but still)

You wrote #3, ROS provides #1 and #2, ros-industrial/abb provides #4.

Probably the quickest way to visualise current robot state would be to edit abb_irb6640_support/launch/robot_state_visualize_irb6640_185_280.launch and comment/remove the section that starts the $(find abb_driver)/launch/robot_interface.launch file. We don't need it, as your ESP8266 is already publishing JointState messages (so takes over half the role of abb_driver). Also comment/remove the line declaring the robot_ip argument, as you don't need it. Now start your ESP8266 and then: roslaunch abb_irb6640_support robot_state_visualize_irb6640_185_280.launch RViz should come up and show you the current state of the robot (I don't know whether you have that particular variant of the IRB 6640, but that doesn't matter for now, you can fix that later). NOTE: abb_driver decouples axes 2 and 3 (here). Without that, JointState messages won't be correct and the pose of the robot will be reported incorrectly. You'll probably have to do something similar in the code running on your ESP8266. I have not been able to successfully write serial data to the robot controller, but for some reason I can receive data. Depending on your ultimate goal, it may be an idea to take a look at ros-industrial/industrial_core#107: that issue asks for a serial transport for industrial_core. Provided the S4C+ supports sufficient Rapid and with appropriate changes to abb_driver (ie: make it support a serial connection) you may be able to use the regular infrastructure but then over a serial connection. No guarantees of course, but if you'd be interested I'd be willing to help. I launched the demo of the Abb_irb6640_moveit_config package [..] demo.launch is not a launch file you would use for controlling a real robot or for visualising a real robot's state. It's -- as the name implies -- a demo setup that you may use to test MoveIt's functionality with a particular robot's (urdf) model. [..] but I am confused on how to control it by reading joint_states. I'm not sure what you mean by this. JointState messages are intended to be used to report joint state, not to command it. Edit: My aoplogies, I want to use the joint_state feedback data from the physical robot to move the robot model in RViz,simply as a way to visualize what is happening to the real robot. Ok. That should not be too hard, seeing as you already are publishing JointState messages. Components involved in visualising robot state: 1. rvizRViz 2. robot_state_publisher 3. a JointState publisher 4. a urdf/xacro for the robot model (more of a passive component, but still) You wrote #3, ROS provides #1 and #2, ros-industrial/abb provides #4. Probably the quickest way to visualise current robot state would be to edit abb_irb6640_support/launch/robot_state_visualize_irb6640_185_280.launch and comment/remove the section that starts the$(find abb_driver)/launch/robot_interface.launch file. We don't need it, as your ESP8266 is already publishing JointState messages (so takes over half the role of abb_driver). Also comment/remove the line declaring the robot_ip argument, as you don't need it.

Now start your ESP8266 and then:

roslaunch abb_irb6640_support robot_state_visualize_irb6640_185_280.launch

RViz should come up and show you the current state of the robot (I don't know whether you have that particular variant of the IRB 6640, but that doesn't matter for now, you can fix that later).

NOTE: abb_driver decouples axes 2 and 3 (here). Without that, JointState messages won't be correct and the pose of the robot will be reported incorrectly. You'll probably have to do something similar in the code running on your ESP8266.

I have not been able to successfully write serial data to the robot controller, but for some reason I can receive data.

Depending on your ultimate goal, it may be an idea to take a look at ros-industrial/industrial_core#107: that issue asks for a serial transport for industrial_core. Provided the S4C+ supports sufficient Rapid and with appropriate changes to abb_driver (ie: make it support a serial connection) you may be able to use the regular infrastructure but then over a serial connection.

No guarantees of course, but if you'd be interested I'd be willing to help.

I launched the demo of the Abb_irb6640_moveit_config package [..]

demo.launch is not a launch file you would use for controlling a real robot or for visualising a real robot's state.

It's -- as the name implies -- a demo setup that you may use to test MoveIt's functionality with a particular robot's (urdf) model.

[..] but I am confused on how to control it by reading joint_states.

I'm not sure what you mean by this. JointState messages are intended to be used to report joint state, not to command it.

Edit:

My aoplogies, I want to use the joint_state feedback data from the physical robot to move the robot model in RViz,simply as a way to visualize what is happening to the real robot.

Ok. That should not be too hard, seeing as you already are publishing JointState messages.

Components involved in visualising robot state:

1. RViz
2. robot_state_publisher
3. a JointState publisher
4. a urdf/xacro for the robot model (more of a passive component, but still)

You wrote #3, ROS provides #1 and #2, ros-industrial/abb provides #4.

Probably the quickest way to visualise current robot state would be to edit abb_irb6640_support/launch/robot_state_visualize_irb6640_185_280.launch and comment/remove the section that starts the \$(find abb_driver)/launch/robot_interface.launch file. We don't need it, as your ESP8266 is already publishing JointState messages (so takes over half the role of abb_driver). Also comment/remove the line declaring the robot_ip argument, as you don't need it.

Now start your ESP8266 and then:

roslaunch abb_irb6640_support robot_state_visualize_irb6640_185_280.launch

RViz should come up and show you the current state of the robot (I don't know whether you have that particular variant of the IRB 6640, but that doesn't matter for now, you can fix that later).

NOTE: abb_driver decouples axes 2 and 3 (here). Without that, JointState messages won't be correct and the pose of the robot will be reported incorrectly. You'll probably have to do something similar in the code running on your ESP8266.

I have not been able to successfully write serial data to the robot controller, but for some reason I can receive data.

Depending on your ultimate goal, it may be an idea to take a look at ros-industrial/industrial_core#107: that issue asks for a serial transport for industrial_core. Provided the S4C+ supports sufficient Rapid and with appropriate changes to abb_driver (ie: make it support a serial connection) you may be able to use the regular infrastructure but then over a serial connection.

No guarantees of course, but if you'd be interested I'd be willing to help.

Edit 2:

Now when I run this in parallel with launching robot_state_visualize after doing what you told me, parts of the model are now white, [..] Looking at the RobotModel Display in Rviz, it tells me there is "No transform from [link_1] to [base_link]" for every link after the base frame.

Your description and screenshot suggest that there is a problem with TF. This is typically either because robot_state_publisher (RSP) is not running, or RSP is not receiving proper JointState messages for the URDF it has loaded.

In your case, it's most likely the latter. In the code on the ESP8266, I see this (from here):

char *j_name[] = {"J1", "J2", "J3", "J4", "J5", "J6"};

While those are perfectly valid joint names (although I would personally never use capitals in ROS names), they won't work for the URDF that you are loading, as there the names of the joints are: joint_1, joint_2, joint_3, joint_4, joint_5 and joint_6 (see here).

For RSP to be able to perform the correct forward kinematics, the incoming JointState messages must use the correct joint names, or it won't know which joint to use for which transform.

I expect things to start working once you use the correct joint names on the ESP8266 side.