Ask Your Question

FTrommsdorff's profile - activity

2015-06-29 02:14:42 -0500 received badge  Famous Question (source)
2014-02-21 11:44:15 -0500 received badge  Teacher (source)
2013-11-21 19:35:34 -0500 received badge  Notable Question (source)
2013-11-21 19:35:34 -0500 received badge  Popular Question (source)
2013-11-18 05:59:13 -0500 received badge  Famous Question (source)
2013-04-10 01:21:12 -0500 received badge  Famous Question (source)
2013-03-04 01:19:30 -0500 received badge  Popular Question (source)
2013-03-04 01:19:30 -0500 received badge  Notable Question (source)
2013-01-14 03:45:04 -0500 commented answer Error when installing IPC Bridge for ROS and MatLAB

Sorry for the delay, but I wasn't here for a long time. I updated my answer above.

2012-11-22 03:02:33 -0500 asked a question Stopping simulation during computations / model swings up

I am using the update event mechanism to trigger my computations of additional forces in Gazebo, and I call the following line in the load function of my controller (which isn't really a controller, rather does compute simplified aerodynamics for a small blimp):

  this->update_connection_ = event::Events::ConnectWorldUpdateStart(
      boost::bind(&Blimp_FlightMechanics::UpdateChild, this));

In the UpdateChild() method, I am doing all the computational stuff. This takes some time, I used ros::WallTime to determine it. The problem is, I first read some model states, and then I do my math. When I want to apply the forces and torques, which can be seen as a response of the current model state, then some time is gone and the response isn't valid anymore. This effect swings up my model and leads to instability.

My question is: can I stop the simulation, read in the necessary state information, do the math, set the forces and then run the simulation again, until the next event alls my method UpdateChild()? I guess, the answer is "yes", but I didn't found the programmatic tools to do so.

EDIT: I tried the command ros::Duration(sleep_time).sleep(), but when using that, the simulation stops completely.

EDIT2: Using the command common::Time::MSleep(2) works for now. But maybe some workaround for switching the simulation "off" and "on" again does exist anyway?

2012-11-21 23:04:25 -0500 received badge  Notable Question (source)
2012-11-20 22:41:38 -0500 answered a question How to set Real Time Factor to 1.0 in Gazebo ROS Fuerte

There's a parameter for the update rate in Fuerte. I've chosen it to 1000, which seems to fit to dt = 0.001, which gives a real time factor nearly to one. My according sdf file looks like:

<physics type="ode" update_rate="1000.0">
  <gravity xyz="0 0 0"/>
    <solver type="quick" dt="0.001" iters="20" sor="1.3"/>
    <constraints cfm="0.0" erp="0.2" contact_max_correcting_vel="100.0" contact_surface_layer="0.001"/>


2012-11-20 00:51:06 -0500 received badge  Student (source)
2012-11-20 00:07:02 -0500 received badge  Scholar (source)
2012-11-19 22:58:05 -0500 received badge  Popular Question (source)
2012-11-19 21:48:47 -0500 commented question Subscriber callback isn't invoked

@Lorenz: Thank you for the reference about the track_object. But I wonder, why many examples of controllers are using the SubscriberOptions the same way? I try to figure out the difference between them and my code, but until now, I didn't find the crucial point.

2012-11-19 04:33:52 -0500 asked a question Subscriber callback isn't invoked

I'm currently rewriting this gazebo controller plugin to apply additional forces to a link of my model. My goal is to simulate the flight behaviour of a indoor blimp at low velocity. I tried to wrap the computations of the additional mechanical forces and moments and the subscription of the control input (which is at the moment some input from the keyboard, just for testing purposes) in one class. I tried to keep the example as tight as possible:

namespace gazebo

class Blimp_FlightMechanics : public ModelPlugin
  public: Blimp_FlightMechanics()
        this->wrench_msg_.force.x = 0;
        this->wrench_msg_.force.y = 0;
        this->wrench_msg_.force.z = 0;
        this->wrench_msg_.torque.x = 0;
        this->wrench_msg_.torque.y = 0;
        this->wrench_msg_.torque.z = 0;
  public: virtual ~Blimp_FlightMechanics()
        delete this->rosnode_;      
protected: void Load(physics::ModelPtr _model, sdf::ElementPtr _sdf)
// Load data from xml file
  if (!ros::isInitialized())
  this->rosnode_ = new ros::NodeHandle(this->robot_namespace_);

  ros::SubscribeOptions so = ros::SubscribeOptions::create<geometry_msgs::Wrench>(
    boost::bind( &Blimp_FlightMechanics::UpdateObjectForce,this,_1),
    ros::VoidPtr(), &this->queue_);
  this->sub_ = this->rosnode_->subscribe(so);

  this->update_connection_ = event::Events::ConnectWorldUpdateStart(
      boost::bind(&Blimp_FlightMechanics::UpdateChild, this));

  protected: virtual void UpdateChild()
    math::Vector3 force_sum = math::Vector3(0,0,0);
    math::Vector3 torque_sum = math::Vector3(0,0,0);

[Do computations of forces and torque here]

   // this is the crucial part: although the callback is set above, it will not be called within the simulation; for debugging, I juse "ROS_INFO()", but the call here is never executed
    private: void UpdateObjectForce(const geometry_msgs::Wrench::ConstPtr& _msg)
        this->wrench_msg_.force.x = _msg->force.x;
        this->wrench_msg_.force.y = _msg->force.y;
        this->wrench_msg_.force.z = _msg->force.z;
        this->wrench_msg_.torque.x = _msg->torque.x;
        this->wrench_msg_.torque.y = _msg->torque.y;
        this->wrench_msg_.torque.z = _msg->torque.z;
        ROS_INFO("F-Ctrl: [%g %g %g], T-Ctrl: [%g %g %g]",this->wrench_msg_.force.x,this->wrench_msg_.force.y,this->wrench_msg_.force.z,this->wrench_msg_.torque.x,this->wrench_msg_.torque.y,this->wrench_msg_.torque.z);

I also tried to keep the basic tutorials for subscribers at the wiki page in mind. At runtime, I execute my tele-operating (toy) keybord input programm and made a check using "rostopic info force1", with the following output:

Type: geometry_msgs/Wrench

 * /talker (<adress>)

 * /gazebo (<adress>)

which seems feasible. I also receive messages, using "rostopic echo force1". Anybody has a clue or do I forget something?

EDIT: Problem was solved. For the subscriber, I used:

this->sub_ = this->rosnode_->subscribe<geometry_msgs::Wrench>(this->topic_name_, 1,boost::bind(&Blimp_FlightMechanics::UpdateObjectForce,this,_1));

and the callbacks are executed as expected, when a new message is published. Thanks to Lorenz.

2012-11-15 06:41:09 -0500 commented question Wrench controller doesn't publish

The plugin "" is provided by Gazebo, you'll find the code here:

2012-11-15 02:11:30 -0500 asked a question Wrench controller doesn't publish

I've implemented a gazebo_ros_force controller, which uses the message class "geometry_msgs::Wrench". The code isn't much more than a test:

#include <unistd.h>
#include "ros/ros.h"
#include "geometry_msgs/Wrench.h"

using namespace std;

int main(int argc, char **argv)
  ros::init(argc, argv, "talker");
  ros::NodeHandle n;
  ros::Publisher wrench_pub = n.advertise<geometry_msgs::Wrench>("force1", 1000);
  ros::Rate loop_rate(10);
  int count = 0;
  while (ros::ok())
    geometry_msgs::Wrench msgForce1;
    msgForce1.force.x = 0.001*float(count);
    msgForce1.force.y = 0.001*float(count);
    msgForce1.force.z = 0.001*float(count);
    msgForce1.torque.x = 0.001*float(count);
    msgForce1.torque.y = 0.001*float(count);
    msgForce1.torque.z = 0.001*float(count);

    ROS_INFO("Debug output: %f", msgForce1.force.x);
    ROS_INFO("Debug output: %f", msgForce1.force.y);
    ROS_INFO("Debug output: %f", msgForce1.force.z);


  return 0;

If only roscore is running, the messages were published as expected. When I am running gazebo and spawning my model from a urdf-file, where I introduced the controller, nothing happens, just the first debug-output is written on the shell.

  <controller:gazebo_ros_force name="controller_name" plugin="">

I used roswtf and got the following messages:

Package: test_mesh
[rospack] Warning: ignoring duplicate cpp tag in export block
[rospack] Warning: ignoring duplicate cpp tag in export block
[rospack] Warning: ignoring duplicate cpp tag in export block
[rospack] Warning: ignoring duplicate cpp tag in export block
[rospack] Warning: ignoring duplicate cpp tag in export block
[rospack] Warning: ignoring duplicate cpp tag in export block
[rospack] Warning: ignoring duplicate cpp tag in export block
[rospack] Warning: ignoring duplicate cpp tag in export block
[rospack] Warning: ignoring duplicate cpp tag in export block
[rospack] Warning: ignoring duplicate cpp tag in export block
Static checks summary:

Found 1 warning(s).
Warnings are things that may be just fine, but are sometimes at fault

WARNING The following packages have msg/srv-related cflags exports that are no longer necessary
        <cpp cflags="..."
 * dynamic_reconfigure: -I${prefix}/msg/cpp -I${prefix}/srv/cpp
 * driver_base: -I${prefix}/msg/cpp

Found 1 error(s).

ERROR The following packages have rpath issues in manifest.xml:
 * test_mesh: found flag "-L/opt/ros/fuerte/lib", but no matching "-Wl,-rpath,/opt/ros/fuerte/lib"
 * urdf_parser: found flag "-L/opt/ros/fuerte/lib", but no matching "-Wl,-rpath,/opt/ros/fuerte/lib"
 * rosconsole: found flag "-L/opt/ros/fuerte/lib", but no matching "-Wl,-rpath,/opt/ros/fuerte/lib"
 * trajectory_msgs: found flag "-L/opt/ros/fuerte/lib", but no matching "-Wl,-rpath,/opt/ros/fuerte/lib"
 * nodelet_topic_tools: found flag "-L/opt/ros/fuerte/lib", but no matching "-Wl,-rpath,/opt/ros/fuerte/lib"
 * diagnostic_updater: found flag "-L/opt/ros/fuerte/lib", but no matching "-Wl,-rpath,/opt/ros/fuerte/lib"
 * pcl_ros: found flag "-L/opt/ros/fuerte/lib", but no matching "-Wl,-rpath,/opt/ros/fuerte/lib"
 * nav_msgs: found flag "-L/opt/ros/fuerte/lib", but ...
2012-11-08 03:37:09 -0500 received badge  Supporter (source)
2012-11-08 03:34:42 -0500 commented answer Error when installing IPC Bridge for ROS and MatLAB

My problem above was solved - had to make the "mex"-command available to the environment.

2012-11-08 03:28:55 -0500 received badge  Editor (source)
2012-11-08 03:28:26 -0500 answered a question Matlab-ROS Communication with ipc_bridge_ros

There is another way: using (I guess) any UNIX-system, you can force Matlab to use any installed gcc version (which is possible, because there can exist more than one installed version of gcc). This worked for me (of course adopting all paths and gcc-version to your required settings):

2012-11-08 02:07:43 -0500 answered a question Error when installing IPC Bridge for ROS and MatLAB

Sorry, this is not an answer, but I stuck at the same procedure. My problem occurs, when I try to compile the first message folder (roscd ipc_roslib && make). The output message is:

[ rosmake ] rosmake starting...                                                 
[ rosmake ] Packages requested are: ['ipc_bridge_ros']                          
[ rosmake ] Logging to directory <my_dir>/.ros/rosmake/rosmake_output-20121108-150035
[ rosmake ] Expanded args ['ipc_bridge_ros'] to:
[rosmake-1] Starting >>> ipc [ make ]                                           
[rosmake-0] Starting >>> roslang [ make ]                                       
[rosmake-2] Starting >>> geometry_msgs [ make ]                                 
[rosmake-2] Finished <<< geometry_msgs  No Makefile in package geometry_msgs    
[rosmake-0] Finished <<< roslang  No Makefile in package roslang                
[rosmake-2] Starting >>> sensor_msgs [ make ]                                   
[rosmake-0] Starting >>> roscpp [ make ]                                        
[rosmake-3] Starting >>> nav_msgs [ make ]                                      
[rosmake-2] Finished <<< sensor_msgs  No Makefile in package sensor_msgs        
[rosmake-0] Finished <<< roscpp  No Makefile in package roscpp                  
[rosmake-3] Finished <<< nav_msgs  No Makefile in package nav_msgs              
[rosmake-1] Finished <<< ipc [PASS] [ 0.83 seconds ]                            
[rosmake-1] Starting >>> ipc_bridge [ make ]                                    
[rosmake-1] Finished <<< ipc_bridge  No Makefile in package ipc_bridge          
[rosmake-1] Starting >>> ipc_bridge_ros [ make ]                                
[rosmake-1] Finished <<< ipc_bridge_ros  No Makefile in package ipc_bridge_ros  
[ rosmake ] Results:                                                            
[ rosmake ] Built 8 packages with 0 failures.                                   
[ rosmake ] Summary output to directory                                         
[ rosmake ] <my_dir>/.ros/rosmake/rosmake_output-20121108-150035

I guess, that the folder ipc_msgs is not at the right place (I did not see an intruction for that, thus I placed it into the ipc_bridge_stack folder, which is agained placed into the ROS package/stack folder).


When compiling the message folder, an error similar to "unknown command "mex"" could appear. This happens, when the matlab command "mex" is not available in the environment variable "PATH". To do so, use the following line in your .bashrc script:

export PATH=<your path="" to="" matlab="">/bin:$PATH

With it, you should be able to call the mex command from anywhere in the shell.