Failed to read 'request_type' from a header for /rostopic

Hello,

I tried using the ros bridge earlier with MoveIt and was able to read some joint states using moveit, by loading a PR2 model. [msg type wasstd_msgs::msg::String]

This time I wanted to read joint_states streaming from a live UR10. But experienced some weird behavior with the ros2 nodes and ros2 topic lists.

So, I subscribed to joint states from UR:

void TestRos2::initialize(std::shared_ptr<rclcpp::node::Node>& n){
	sub_1 = n->create_subscription<sensor_msgs::msg::JointState>("joint_state", std::bind(&TestRos2::receiveMessage, this, _1));
}

void TestRos2::receiveMessage(const sensor_msgs::msg::JointState::SharedPtr msg){
	//std::cout << "Received. Interface Working: [" << msg->data << "]" << std::endl;

	std::map<std::string, double> joint_positions;
	for (unsigned int i = 0; i < msg->name.size(); i++) {
		joint_positions.insert(std::make_pair(msg->name[i], msg->position[i]));
		printf("%s \n, %lf \n", state->name[i], msg->position[i]); // **not sure if I can print it though**
	}
}

Next, I ros2 run the ros_bridge. After that when I did rostopic echo /joint_states (just to check if the message from UR10 was streaming), my ros_bridge window would throw this:

Failed to read 'request_type' from a header for '/rostopic_16527_1506418563704/get_loggers'
Failed to read 'request_type' from a header for '/rostopic_16527_1506418563704/set_logger_level'

However, I still ran my test ros2 node but nothing was at the output. Maybe my printing technique isn’t right. But I tried doing ros2 node list but could not see my node name either. I tried running the demo_node_cpp talker, I would start publishing, however, ros2 node list or the ros2 topic list would not show anything.

So how do I subscribe to the joint states from ur10 and publish the same in ros2?

joint_state message sample:
header:
seq: 37197
stamp:
secs: 1506418567
nsecs: 818417360
frame_id: ''
name: [‘shoulder_pan_joint’, ‘shoulder_lift_joint’, ‘elbow_joint’, ‘wrist_1_joint’, ‘wrist_2_joint’, ‘wrist_3_joint’]
position: [-1.5191767851458948, -1.6008179823504847, -1.594562832509176, -1.5892565886126917, 1.4281541109085083, -0.3266199270831507]
velocity: [0.0, 0.003975566942244768, -0.0, 0.0, 0.018676215782761574, 0.0]
effort: [-0.0366210974752903, 2.925110101699829, 4.784023761749268, 0.4127197563648224, 0.0269165076315403, 0.01345825381577015]

Can you specify the version of the code you are using ?
The error messages Failed to read 'request_type'... have been removed before the beta3 release: https://github.com/ros2/ros1_bridge/pull/91. So using beta3 or master should fix that problem.

Could you clarify what you had working before and what you are doing now?
My understanding is that:
Before you were sending joint states over String messages. Did you do that because it already didnt work with JointState message type ? Or did it also work with snesor_msgs/JointState at that point?

Now you have a UR10 streaming JointState messages (in ROS 1) and you try to convert them over the bridge to use them in ROS 2. Right?

If you can provide a reproducible example using only rostopic/ros2 topic of a modified talker/listener example that would allow us to help you.

I don’t have a UR10 closeby but passing joint states over the bridge seems to work with your sample:
Shell 1 : roscore
Shell 2:

source /opt/ros/kinetic/setup.bash
rostopic pub /joint_states sensor_msgs/JointState "header:
  seq: 37197
  stamp:
    secs: 1506418567
    nsecs: 818417360
  frame_id: ''
name: [‘shoulder_pan_joint’, ‘shoulder_lift_joint’, ‘elbow_joint’, ‘wrist_1_joint’, ‘wrist_2_joint’, ‘wrist_3_joint’]
position: [-1.5191767851458948, -1.6008179823504847, -1.594562832509176, -1.5892565886126917, 1.4281541109085083, -0.3266199270831507]
velocity: [0.0, 0.003975566942244768, -0.0, 0.0, 0.018676215782761574, 0.0]
effort: [-0.0366210974752903, 2.925110101699829, 4.784023761749268, 0.4127197563648224, 0.0269165076315403, 0.01345825381577015]"

Shell 3:

source /opt/ros/kinetic/setup.bash
source <ROS2_WS_INSTALL_DIR>/setup.bash
ros2 run ros1_bridge dynamic_bridge

Shell 4:

source <ROS2_WS_INSTALL_DIR>/setup.bash
ros2 topic echo /joint_states sensor_msgs/JointState

Shell 4 displays:

$ ros2 topic echo /joint_states sensor_msgs/JointState
header:
  stamp:
    sec: 1506418567
    nanosec: 818417360
  frame_id: ''
name: ["\u2018shoulder_pan_joint\u2019", "\u2018shoulder_lift_joint\u2019", "\u2018elbow_joint\u2019", "\u2018wrist_1_joint\u2019", "\u2018wrist_2_joint\u2019", "\u2018wrist_3_joint\u2019"]
position: [-1.5191767851458948, -1.6008179823504847, -1.594562832509176, -1.5892565886126917, 1.4281541109085083, -0.3266199270831507]
velocity: [0.0, 0.003975566942244768, -0.0, 0.0, 0.018676215782761574, 0.0]
effort: [-0.0366210974752903, 2.925110101699829, 4.784023761749268, 0.4127197563648224, 0.0269165076315403, 0.01345825381577015]

The \u2018 is a “LEFT SINGLE QUOTATION MARK”, which seems odd as there are already double quotes around the string.

Is that expected after passing through the bridge?

The quotes are present because the provided sample is using left quotes instead of “regular” single or double quotes. As a result they show up on both the ROS 1 or ROS 2 side of the bridge:

$ rostopic echo /joint_states 
header: 
  seq: 1
  stamp: 
    secs: 1506418567
    nsecs: 818417360
  frame_id: ''
name: ['\xe2\x80\x98shoulder_pan_joint\xe2\x80\x99', '\xe2\x80\x98shoulder_lift_joint\xe2\x80\x99', '\xe2\x80\x98elbow_joint\xe2\x80\x99', '\xe2\x80\x98wrist_1_joint\xe2\x80\x99', '\xe2\x80\x98wrist_2_joint\xe2\x80\x99', '\xe2\x80\x98wrist_3_joint\xe2\x80\x99']
position: [-1.5191767851458948, -1.6008179823504847, -1.594562832509176, -1.5892565886126917, 1.4281541109085083, -0.3266199270831507]
velocity: [0.0, 0.003975566942244768, -0.0, 0.0, 0.018676215782761574, 0.0]
effort: [-0.0366210974752903, 2.925110101699829, 4.784023761749268, 0.4127197563648224, 0.0269165076315403, 0.01345825381577015]

If using a sample with “regular quotes” if work fine on both sides:

$ rostopic pub /joint_states sensor_msgs/JointState "header:
  seq: 37197
  stamp:
    secs: 1506418567
    nsecs: 818417360
  frame_id: ''
name: ['shoulder_pan_joint', 'shoulder_lift_joint', 'elbow_joint', 'wrist_1_joint', 'wrist_2_joint', 'wrist_3_joint']
position: [-1.5191767851458948, -1.6008179823504847, -1.594562832509176, -1.5892565886126917, 1.4281541109085083, -0.3266199270831507]
velocity: [0.0, 0.003975566942244768, -0.0, 0.0, 0.018676215782761574, 0.0]
effort: [-0.0366210974752903, 2.925110101699829, 4.784023761749268, 0.4127197563648224, 0.0269165076315403, 0.01345825381577015]"
$ ros2 topic echo /joint_states sensor_msgs/JointState
header:
  stamp:
    sec: 1506418567
    nanosec: 818417360
  frame_id: ''
name: [shoulder_pan_joint, shoulder_lift_joint, elbow_joint, wrist_1_joint, wrist_2_joint, wrist_3_joint]
position: [-1.5191767851458948, -1.6008179823504847, -1.594562832509176, -1.5892565886126917, 1.4281541109085083, -0.3266199270831507]
velocity: [0.0, 0.003975566942244768, -0.0, 0.0, 0.018676215782761574, 0.0]
effort: [-0.0366210974752903, 2.925110101699829, 4.784023761749268, 0.4127197563648224, 0.0269165076315403, 0.01345825381577015]

Hi @marguedas,

I believe I am using beta3 release, But I have both r2b2 and r2b3 version in /opt/ros/ path. However, in my bashrc, only r2b3 is sourced.

Goal: I am testing the ros_bridge to make sure we can use MoveIt and other sensor messages and robots in ROS2.0.

Before:

  1. At first, I just tried the ros_bridge tutorials and then moved on to have a PR2 model uploaded and stream the joint states in ros1 and launch the bridge. I created my interface in ros2 for listening to some translation and rotational states of the end_effector, which I could. I used very simple std_msgs::msg::String

      std::stringstream ss;
      ss << end_effector_state.translation() << end_effector_state.rotation();
      robot_joint_details.data=ss.str();
    
      while(n!=10){
      joint_details_.publish(robot_joint_details);
      ros::Duration(0.2).sleep();
      	n++;
      }
    

I did the same with a Sawyer model as well. I did not use JointState message in this case.

Now:
2. Now I wanted to stream in Joint States that were coming in from my UR10. I used JointState message, yes you are right I want to have the bridge, and listen to the joint_states in ROS2.0 terminal.

Ok, regarding the modified listener, its the two functions as you see above. However, here is the git repo: https://github.com/arunavanag591/test_ros2.git
Its a very simple class example.

I wonder if presence for the r2b2 and r2b3 is creating the issue. But it shouldn’t right because my bash only source r2b3.

@arunava_nag can you confirm that the example provided above using only rostopic pub on the ROS1 side and ros2 topic echo on the ROS 2 side works for you ? As mentioned in the previous post a reproducible example without relying on having a UR10 available would help us investigate the issue.

Thanks!

First of all apologies for the delayed response I was tied up with other things and could not have a look at the UR.

As the joint states are streaming from the robot I did not have to rostopic pub on the ros1 side, I just start the UR ros master by the ur10 bring up launch file and echo the joint states on ros 1 side to check the readings.

On the ros2 side, I start the bridge and do ros2 topic echo.
I am just using this simple startup script in ur10 ros wiki page. Nothing else on the UR side. I have already provided the link to my ros2 side code.

As pointed out earlier I don’t have a UR10 to test, so an examples reproducing the same issue without requiring a UR10 would be very appreciated. Please test to send the same JointState message using rostopic pub on the ROS 1 side and ros2 topic echo on the ROS 2 side.

1 make sure you have a recent version of the ROS 2 code (either beta3 or the current master version), it’s still unclear to me what version you are currently using.
2 Run the tests described in Failed to read ‘request_type’ from a header for /rostopic
2.a If it doesn’t work please report here with the command you ran and the console output
2.b if it works try to swap your ros2 topic echo with your custom ROS 2 node (without changing anything on the ROS 1 side). If this doesnt work please provide error message and detailed description of what happens vs what you expect to happen.

Cheers,

Hi @marguedas,

Before i proceed with reporting the test cases from point 2.

for 1.
Just to make sure I am running the right version of the binaries, I removed r2b2 from the path /opt/ros/.
Removed and rebuild and tested my ros2_ws (which takes forever).
Now when I sourceinstall/setup.bash, this warning pops up:

Warning: OSPL_URI was already set to [[file:///opt/ros/r2b3/share/opensplice_cmake_module/config/ros_ospl.xml]]. This will not override it to the default [[file:///home/artc/ros2_ws/install/share/opensplice_cmake_module/config/ros_ospl.xml]]. Please make sure this is the config that you want.

Any pointers what is this about? Why is it pointing towards the DDS opensplice.

Hi @marguedas,
Everything works now. Thanks. However please let me know how to get rid of the warning i am receiving as mentioned in here

You don’t need a UR, I just tried with its gazebo simulation as here, it streams out the topic /joint_states when I launch the ur10.launch file, and I could establish the bridge and listen to joint states, without actually needing to rostopic pub manually. I think previously it was still looking into r2b2, removing and rebuilding everything for r2b3 fixed it.