# [solved] Struggling to run ros_control controller in gdb

Hi folks,

Intro

I am using the guided policy search (GPS) package ( http://rll.berkeley.edu/gps/ ) 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.                                      -->
<!-- ======================================================================= -->

<launch>
<!-- 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>

<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 -->
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 -->
file = "$(find gps_agent_pkg)/launch/lwr_controller.yaml" /> <!-- <param name = "lwr ... edit retag close merge delete ## 1 Answer Sort by » oldest newest most voted 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" />


to:

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


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

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.

( 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.

( 2018-07-04 04:06:38 -0500 )edit