ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

[solved] Struggling to run ros_control controller in gdb

asked 2018-06-28 10:54:55 -0500

walkingbeard gravatar image

updated 2018-07-04 04:07:59 -0500

Hi folks,


I am using the guided policy search (GPS) package ( ) to run the back-end of a ros_control controller for a Gazebo simulation of the KUKA LWR 4+ arm.

My working environment is Linux 18.3 (Ubuntu 16.10) with Kinetic. My kernel is 4.10.0-38-generic.

Currently, my controller crashes in update() because the base class, which is provided by the GPS distribution, initialises two sets of internal controllers (one for each of two arms) and then tries to update both. My derived controller only has one arm to work with. Compiled with debugging, lots of assertions fail at runtime. Compiled without debugging, I get segmentation faults when methods are called on the non-existent second arm.

I don't particularly want to change the underlying code, because I want my controller to be easily installable and I don't really think it's necessary.

What I need

As a ROS noob, I find the code quite difficult to follow, and all I want is to be able to set some breakpoints and get stack traces, but I can't start the controller in gdb.

I have tried running my launch file with debug:=true on the command line. I have tried adding a gdb prefix to the controller spawner, but that's a Python script and in any case does not contain the executing controller. I have tried compiling as release, but with debugging information (so the controller fails with a seg fault rather than on the debugging assertions) and then running with the debug:=true parameter/argument, but when the seg fault occurs, gzserver crashes and there is no PID to use with gdb.

I have been unable to find any more information than this on debugging ROS controllers. Can anyone give me a reliable method of starting the controller in gdb? Please?

<?xml version="1.0"?>
<!-- ======================================================================= -->
<!-- lwr_gazebo.launch                                                       -->
<!-- Description: Launches the Gazebo simulation of the KUKA LWR 4+ and      -->
<!--              guided policy search.                                      -->
<!-- ======================================================================= -->

  <!-- Set debug on -->
  <!-- <env name = "ROSCONSOLE_CONFIG_FILE" 
       value = "$(find gps_agent_pkg)/launch/custom_rosconsole.conf" /> -->

  <arg name = "robot_name" default = "single_lwr_robot" />

  <!-- Upload robot description to ros parameter server -->
  <param name = "robot_description" command = "$(find xacro)/xacro 
    --inorder $(find single_lwr_robot)/robot/$(arg robot_name).urdf.xacro" />

  <!-- Set up state publishers. Don't know if this is needed for GPS -->
  <node name = "joint_state_publisher" pkg = "joint_state_publisher"
      type = "joint_state_publisher">
    <rosparam param = "source_list">[/lwr/joint_states]</rosparam>

  <node name = "robot_state_publisher" pkg = "robot_state_publisher"
    type = "robot_state_publisher" />

  <!-- Start up gazebo and spawn the KUKA in an empty world -->
  <node name = "spawn_urdf" pkg = "gazebo_ros" type = "spawn_model"
    args = "-param robot_description -urdf -model $(arg robot_name)"
    respawn = "false" output = "screen" />

  <include file="$(find gazebo_ros)/launch/empty_world.launch" />

  <!-- Load hardware interface configuration to parameter server -->
  <rosparam command = "load"
    file = "$(find single_lwr_robot)/config/hw_interface.yaml" />

  <!-- Load hardware limits as per Kuka's LWR T1 training mode -->
  <!-- Still TODO in controller code -->
  <rosparam command = "load"
    file = "$(find single_lwr_robot)/config/t1_joint_limits.yaml" />

  <!-- Configuration of controller as per PR2 -->
  <rosparam command = "load"
    file = "$(find gps_agent_pkg)/launch/lwr_controller.yaml" />

  <!-- <param name = "lwr ...
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2018-06-28 13:21:45 -0500

gvdhoorn gravatar image

updated 2018-06-28 13:23:31 -0500

I have tried running my launch file with debug:=true on the command line.

Unless the launch file your launching defines a debug arg and does something special if you set it to true, that will not make things run in gdb or turn on some debugging infrastructure. I don't see anything in the launch file you include that suggests setting that argument would work.

I have tried adding a gdb prefix to the controller spawner, but that's a Python script and in any case does not contain the executing controller.

If this is using gazebo_ros_control, then the process that is hosting the controller plugins would be gzserver, and it would be that process that you'd have to run in gdb.

empty_world.launch does accept a debug arg (here) and if that is set to true, it will eventually start gzserver in gdb (here, via this and then this).

So to do that, you would have to change:

<include file="$(find gazebo_ros)/launch/empty_world.launch" />


<include file="$(find gazebo_ros)/launch/empty_world.launch">
    <arg name="debug" value="true" />

Make sure to compile all relevant code with the Debug build type, or backtraces will be useless, but I guess you already know that.

edit flag offensive delete link more


Note that the page you link for gps setup seems a bit dated. Manually changing the ROS_PACKAGE_PATH is not something we typically do these days.

gvdhoorn gravatar image gvdhoorn  ( 2018-06-28 13:24:59 -0500 )edit

Thank you for your replies - very helpful! Honestly, there are many outdated things about this project I'm doing, but I have limited time, so I can either do the project or update the underlying code. It's frustrating, but such is life.

walkingbeard gravatar image walkingbeard  ( 2018-07-04 04:06:38 -0500 )edit

Question Tools



Asked: 2018-06-28 10:54:55 -0500

Seen: 668 times

Last updated: Jul 04 '18