nitschej's profile - activity

Hello there,

I want to spawn multiple nodes within the same C++ process. To this end I used boost/thread. All seems to work, except that always one of the nodes is not showing up in 'rosnode list'. This is the code that runs the threads and creates the nodes:

static boost::mutex mutex;
static boost::once_flag cv_thread_flag = BOOST_ONCE_INIT;

void worker0(int argc, char* argv[]) {
    mutex.lock();
    ros::init(argc, argv, "optical_flow_visualization0");
    optical_flow_analyser::visualize::of_visualize vis("asdf", 0);
    mutex.unlock();
    ros::spin();
}

void worker1(int argc, char* argv[]) {
    mutex.lock();
    ros::init(argc, argv, "optical_flow_visualization1");
    optical_flow_analyser::visualize::of_visualize vis("asdf", 1);
    mutex.unlock();
    ros::spin();
}

int main(int argc, char* argv[]) {
    boost::call_once(cv_thread_flag, &cv::startWindowThread);
    boost::thread worker_thread_0(worker0, argc, argv);
    boost::thread worker_thread_1(worker1, argc, argv);
    worker_thread_0.join();
    worker_thread_1.join();
    return 0;
}

Sample output of 'rosnode list':

% rosnode list
/gazebo
/optical_flow_visualization1
(...)

The internal workings of the node consist of subscribing to some image_transport topics and displaying them with cv::imshow() in the callback function. As stated above this does indeed work as it should, but the fact that only one of the nodes is found by rosnode tells me that I might be doing something wrong here.

So I wonder: Is this a sane way of spawning multiple nodes? If not: how should I do it instead?

The background of this is that I want to process multiple camera streams from Gazebo, and I'd like to have it so, that I can flexibly spawn processing nodes, depending on how many camera streams there are.

Gazebo is blurring textures at a certain distance from the camera. The transition from unblurred to blurred is actually quite hard and interferes with optical flow calculation.

Is there a way to disable this without recompiling Gazebo? I can actually live with all textures, even the very near ones, being blurred, as long as there is no visible transition.

If I use a gazebo camera like this:

<sensor:camera name="camera1_sensor">
  <imageSize>160 160</imageSize>
  <controller:gazebo_ros_camera name="controller-cam1" plugin="libgazebo_ros_camera.so">
    <updateRate>20.0</updateRate>
    <imageTopicName>/gazebo/cam1</imageTopicName>
    <cameraInfoTopicName>/gazebo/cam1/info</cameraInfoTopicName>
  </controller:gazebo_ros_camera>
</sensor:camera>

The timestamps for full second N is actually output as N-1 + 1000000000ns. This leads to weird behavior, for example when using

boost::lexical_cast<std::string>(image_message1->header.stamp)

in a C++ application, as it produces the string "{N-1}.10" instead of the expected "{N}.00".
I assume that it is probably wrong to blindly use the lexical_cast on every datatype that comes along. And actually this is not a big issue, if you finally realize that it works that way.
But I wonder if this is the correct behavior/usage of ROS::Time? Can I expect other components that output ROS::Time tho behave in the same way and should I do it the same if I ever was to create a ROS::Time object?

The problem appears with:

• zero gravity worlds (<gravity>0 0 0</gravity>) OR models with gravity disabled (<enableGravity>false</enableGravity>)
• AND models that use <attach> and <include> to include additional models (for example a pioneer2dx with attached sonyvid30)

What to do to make it happen: teleport your robot into some location above the ground, for example run

rosservice call /gazebo/set_model_state '{model_state: { model_name: pioneer2dx_model1, pose: { position: { x: 0, y: 0, z: .6 }, orientation: {x: 0, y: 0, z: 0, w: 0 } }, twist: { linear: {x: 0 , y: 0 ,z: 0 } , angular: { x: 0 , y: 0 , z: 0 } } }}'

What I would expect to happen: The robot appears in the specified location, peacefully floating there.

What actually happens: The robot does indeed appear in the specified location. But it is usually rotating wildly, sometimes also drifting away from its position

A good example is the pioneer2dx_camera.world which I think lives somewhere in most Gazebo installations. Just change the <gravity> specification to zero and try the rosservice call above.

The question is now: Is this a bug? Are there other workarounds known than to not use <attach> and <include> on models?

Edit: I actually use the Diamondback Ubuntu packages. So maybe this isn't relevant for newer versions.

An example, from the pioneer2dx_camera.world file, which shows the behavior :

<model:physical name="pioneer2dx_model1">
  <xyz>0 0 0.145</xyz>
  <rpy>0.0 0.0 0.0</rpy>
  <model:physical name="sonyvid30_model">
    <xyz>0.15 0 0.09</xyz>
    <attach>
      <parentBody>chassis_body</parentBody>
      <myBody>sonyvid30_body</myBody>
    </attach>
    <include embedded="true">
      <xi:include href="../models/sonyvid30.model" />
    </include>
  </model:physical>
  <include embedded="true">
    <xi:include href="../models/pioneer2dx.model" />
  </include>
</model:physical>

An example which does not show the behavior :

<model:physical name="pioneer2dx_model1">
  <xyz>1 1 0.145</xyz>
  <rpy>0.0 0.0 0.0</rpy>
  <include embedded="true">
    <xi:include href="../models/pioneer2dx.model" />
  </include>
</model:physical>

Any other models, that do not use the <attach>...</attach> + <include>...</include> tags are not affected, though I did not test all too many models. This is probably what you meant by "links".

Actually, when watching the "teleport operation" from a distance I can see what probably causes the spinning: The main body, for example the pioneer2dx_model1, appears at the new position instantly, but the attached body, for example the sonyvid30_model seems to remain at the old position for a very short time and then follows main body like it was attached with a rubber band or something the like. The ensuing impact then makes the robot spin and/or drift.

I think you don't need multiple nodes for your application. The main thing ros::init does is set the name and register the remappings.

You just need multiple topic descriptions and that works without a problem (you can remap topic names independent of the node name if you want).

I am surprised this seemed to work at all. I would not expect a single process to provide more than one node.

I recommend implementing each thread as a nodelet. They are well-supported and the nodelet manager can dynamically load additional threads for the process when needed.

Many camera drivers provide device nodelets, allowing you to display shared copies of the images published. The image pipeline also provides nodelets for similar reasons.