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

St3am's profile - activity

2020-01-04 13:10:49 -0500 received badge  Taxonomist
2018-09-09 00:50:25 -0500 received badge  Good Answer (source)
2018-09-09 00:50:25 -0500 received badge  Enlightened (source)
2018-09-09 00:50:23 -0500 received badge  Good Question (source)
2015-08-13 16:23:29 -0500 received badge  Self-Learner (source)
2015-07-17 12:35:12 -0500 received badge  Nice Question (source)
2015-07-17 12:35:09 -0500 received badge  Nice Answer (source)
2014-10-29 17:36:14 -0500 asked a question Line numbers do not resolve in catkin compile errors

Hi, I usually use a source compiled version of indigo on debian testing, but I have some new hardware and to speed things up I've installed Ubuntu 14.04 with pre-compiled ROS packages.

With Ubuntus distribution I'm running into a problem where compile errors are produced without resolving the references to lines in the source. Instead the location is indicated is an address from the symbol table (I think that’s the right definition for what I'm seeing, correct me if I'm wrong). This makes it almost impossible for me to use the information to debug. This problem only occurs in the Ubuntu implementation, my Debian install shows the line numbers like a normal g++ compile.

Here is an example of the problem:

dynamixel_controller.cpp:(.text._ZNK3ros9Publisher7publishIN20dynamixel_controller16DynamixelStates_ISaIvEEEEEvRKT_[_ZNK3ros9Publisher7publishIN20dynamixel_controller16DynamixelStates_ISaIvEEEEEvRKT_]+0x297): undefined reference to `ros::console::initializeLogLocation(ros::console::LogLocation*, std::string const&, ros::console::levels::Level)'
dynamixel_controller.cpp:(.text._ZNK3ros9Publisher7publishIN20dynamixel_controller16DynamixelStates_ISaIvEEEEEvRKT_[_ZNK3ros9Publisher7publishIN20dynamixel_controller16DynamixelStates_ISaIvEEEEEvRKT_]+0x2d2): undefined reference to `ros::console::setLogLocationLevel(ros::console::LogLocation*, ros::console::levels::Level)'
dynamixel_controller.cpp:(.text._ZNK3ros9Publisher7publishIN20dynamixel_controller16DynamixelStates_ISaIvEEEEEvRKT_[_ZNK3ros9Publisher7publishIN20dynamixel_controller16DynamixelStates_ISaIvEEEEEvRKT_]+0x2dc): undefined reference to `ros::console::checkLogLocationEnabled(ros::console::LogLocation*)'

I would normally expect these symbols to be resolved to a single line number like this:

dynamixel_controller.cpp:(console:4): undefined reference to `ros::console::initializeLogLocation(ros::console::LogLocation*, std::string const&, ros::console::levels::Level)'
dynamixel_controller.cpp:(console:7): undefined reference to `ros::console::setLogLocationLevel(ros::console::LogLocation*, ros::console::levels::Level)'
dynamixel_controller.cpp:(console:8): undefined reference to `ros::console::checkLogLocationEnabled(ros::console::LogLocation*)'

In debian I use the DEBUG flag when I build instead of release, that might be related to the problem. Is there anything I can do to get this functionality in Ubuntu's ROS distribution?

2014-09-25 01:30:42 -0500 received badge  Famous Question (source)
2014-09-18 23:32:38 -0500 answered a question Problems Building ROS Hydro for Debian

What instructions did you use to set up the build before this error occurred? I just installed indigo on debian jessie last week and didn't run into anything like this (there was plenty of other issues though). I did have some trouble with the stable release (circa april 2013) of openrave in which python was having trouble importing. Rebuilding with the latest master release (circua august 2014) fixed those problems so it has made me wonder if there was some change in behavior in the debian archives python packages that is causing version compatibility issues.

2014-08-15 11:47:32 -0500 commented answer Dynamic Robot Model Implementation

Sorry about that, I forgot about this. The telescoping method worked well, although the mimic relationship did not. The bug is here: https://github.com/ros/robot_state_pu... , but it looks like its been fixed.

2014-08-15 05:53:21 -0500 received badge  Good Question (source)
2014-06-13 13:12:43 -0500 received badge  Self-Learner (source)
2014-06-13 13:12:43 -0500 received badge  Teacher (source)
2014-06-13 12:37:35 -0500 received badge  Famous Question (source)
2014-05-22 02:34:31 -0500 received badge  Notable Question (source)
2014-04-23 04:26:22 -0500 received badge  Famous Question (source)
2014-04-22 04:49:51 -0500 received badge  Famous Question (source)
2014-04-20 06:57:22 -0500 marked best answer Correctly configuring end effectors for moveit

I've created a new robot model for integration with moveit and am having trouble getting moveit to recognize the end effectors. I've generated the SRDF as well as other configuration files with the moveit setup assistant, and then launch the demo automatically generated along with my own node called servo capture. In my node I wait for rviz to come up, instantiate a move group similar to the PR2 move group interface tutorial, and then have a listener callback that sets a goal when a point is published from rviz. When the callback executes an error is displayed right after I print confirmation that the point was received:

[ INFO] [1397094975.183158794]: Got new goal: [1.72786,2.13589,0.553876]
[ERROR] [1397094975.183266964]: No end-effector to set the pose for
[ INFO] [1397094975.184236157]: Planning request received for MoveGroup action. Forwarding to planning pipeline.
[ WARN] [1397094975.186156762]: No goal constraints specified. There is no problem to solve.

I've tried printing out the parent link name and and end effector name but both member functions to do so return empty strings.

Of the different ways I've configuring my planning groups in the setup assistant, the most reasonable one I could come up with is in the background below. With my current understanding the end effector group should have no links in common with its parent, be a child group of the arm, and defined as an end effector attached to the last link of the arm. It also needs to have its own kinematics solver written if it is not a chain, I've avoided this problem by just fixing the non chain components. If I launch the demo launch file which starts a joint publisher, transform publisher, state publisher, move group server and rviz, they should provide all resources necessary to run a fully functional move group interface node. If something was wrong with the end effector description I would still expect that the end of the chain link for the arm would at least be the default end effector. Is there anything in the above that seems like a misunderstanding?

Background:

Here is a visualization of the URDF:

image description

And here is how I have the arm configured in the SRDF (through the setup assistant):

<group name="arm">
    <link name="base_link" />
    <link name="base" />
    <link name="shoulder" />
    <link name="arm" />
    <link name="boom0" />
    <link name="boom1" />
    <link name="boom2" />
    <link name="boom3" />
    <link name="boom4" />
    <link name="boom5" />
    <link name="boom6" />
    <link name="boom7" />
    <link name="boom8" />
    <link name="boom9" />
    <link name="boom10" />
    <link name="boom_cap" />
    <joint name="base_link_to_base" />
    <joint name="base_to_shoulder" />
    <joint name="shoulder_to_arm" />
    <joint name="arm_to_boom" />
    <joint name="boom0_to_boom1" />
    <joint name="boom1_to_boom2" />
    <joint name="boom2_to_boom3" />
    <joint name="boom3_to_boom4" />
    <joint name="boom4_to_boom5" />
    <joint name="boom5_to_boom6" />
    <joint name="boom6_to_boom7" />
    <joint name="boom7_to_boom8" />
    <joint name="boom8_to_boom9" />
    <joint name="boom9_to_boom10" />
    <joint name="boom_to_boom_cap" />
    <chain base_link="base" tip_link="boom_cap" />
    <group name="electrostatic_gripper" />
</group>
<group name="electrostatic_gripper">
    <link name="top_pad" />
    <link name="left_pad" />
    <link name="right_pad" />
    <link name="bottom_pad" />
    <link name ...
(more)
2014-04-20 06:57:16 -0500 marked best answer Creating a CollisionObject from a mesh in Hydro

I'm trying to create create a collision object from a mesh resource and am having trouble understanding how to pass an enumerated type to a message constructor:

const shapes::Mesh* navstar_shape = shapes::createMeshFromResource("package://altius_arm/meshes/NAVSTAR_GPS_Satellite.dae");
shape_msgs::Mesh navstar_mesh;
shapes::constructMsgFromShape(navstar_shape,navstar_mesh);
navstar_collision_object.meshes[0] = navstar_mesh;

I get the following compiler error:

/home/peter/ros/altius_ws/src/altius_arm/src/servo_capture.cpp: In constructor ‘ServoCapture::ServoCapture()’:
/home/peter/ros/altius_ws/src/altius_arm/src/servo_capture.cpp:77:61: error: invalid initialization of reference of type ‘shapes::ShapeMsg& {aka boost::variant<shape_msgs::SolidPrimitive_<std::allocator<void> >, shape_msgs::Mesh_<std::allocator<void> >, shape_msgs::Plane_<std::allocator<void> > >&}’ from expression of type ‘shape_msgs::Mesh’
/opt/ros/hydro/include/geometric_shapes/shape_operations.h:62:6: error: in passing argument 2 of ‘bool shapes::constructMsgFromShape(const shapes::Shape*, shapes::ShapeMsg&)’

I thought constructMsgFromShape was asking for the message object by reference, but it didn't work so I tried passing it by address which at least gets the compiler to realize that I'm passing the right typedef but gives a similar error. Does anyone have any idea what I'm doing wrong?

2014-04-20 06:57:10 -0500 marked best answer Catkin enviornmental variables do not resolve

When trying to compile moveit from the wiki directions I run into a cmake error:

-- +++ processing catkin package: 'moveit_planners_ompl'
-- ==> add_subdirectory(moveit_planners/ompl)
-- Boost version: 1.49.0
-- Found the following Boost libraries:
--   system
--   filesystem
--   date_time
--   thread
--   serialization
CMake Error at moveit_planners/ompl/CMakeLists.txt:20 (find_package):
  By not providing "FindOMPL.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "OMPL", but
  CMake did not find one.

  Could not find a package configuration file provided by "OMPL" with any of
  the following names:

    OMPLConfig.cmake
    ompl-config.cmake

  Add the installation prefix of "OMPL" to CMAKE_PREFIX_PATH or set
  "OMPL_DIR" to a directory containing one of the above files.  If "OMPL"
  provides a separate development package or SDK, be sure it has been
  installed.


-- Configuring incomplete, errors occurred!
Invoking "cmake" failed

What I interpret from this error is that some of the magic that is performed by catkin as it ingests the CMakeList.txt didn't work quite right despite the fact that the file looks fine:

cmake_minimum_required(VERSION 2.8.3)
project(moveit_planners_ompl)

if(NOT CMAKE_CONFIGURATION_TYPES AND NOT CMAKE_BUILD_TYPE)
  set(CMAKE_BUILD_TYPE Release)
endif()

find_package(Boost REQUIRED system filesystem date_time thread serialization)
find_package(catkin REQUIRED COMPONENTS
  moveit_core 
  moveit_ros_planning
  roscpp
  rosconsole
  pluginlib
  tf
  dynamic_reconfigure
  eigen_conversions
  )

find_package(OMPL REQUIRED)

generate_dynamic_reconfigure_options("ompl_interface/cfg/OMPLDynamicReconfigure.cfg")

catkin_package(
  LIBRARIES
    moveit_ompl_interface
    ${OMPL_LIBRARIES}
  INCLUDE_DIRS
    ompl_interface/include
    ${OMPL_INCLUDE_DIRS}
  CATKIN_DEPENDS
    moveit_core
)

include_directories(SYSTEM
                    ${Boost_INCLUDE_DIRS})

include_directories(ompl_interface/include
                    ${catkin_INCLUDE_DIRS}
            ${OMPL_INCLUDE_DIRS})

link_directories(${catkin_LIBRARY_DIRS})
link_directories(${Boost_LIBRARY_DIRS})
link_directories(${OMPL_LIBRARY_DIRS})

add_subdirectory(ompl_interface)

install(FILES ompl_interface_plugin_description.xml
  DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION})

The component I thought it was complaining about is the find package OMPL, but I tried including it in the catkin included components like recommended in the CMakeList.txt docs and this thread but the exact same error is produced. Has anyone encountered this problem before?

2014-04-20 06:56:56 -0500 marked best answer Dynamic Robot Model Implementation

I'm wondering if anyone can offer advice on how to approximate a non-rigid robot model. I'm implementing a model of a 3 DOF arm for a university independent study that uses a rollable prestressed tube (like this: http://www.youtube.com/watch?v=tJ5w8x... ) as one of the extensible elements (this is the robot: https://www.youtube.com/watch?v=xlHGN... ). Essentially it is just a rolled fiber composite that can be unrolled to provide a rigid tube like a tape measure. I can't model the roll because it deforms from its rigid form, but I can make the assumption that the boom section is rigid. I initially set the model up with a prismatic joint so the boom could slide in an out of the arm, but the arm then retracts into the body of the arm and eventually out the back and looks terrible. This method also introduces problems with collision checking in moveit due to self collisions when the boom extends into the arm, and with the environment when it extends out the back.

The next approach I'm researching is to dynamically set the length of the straight tube in the boom section so that the model renders properly within rviz/gazebo, dynamically resizes the collision elements, and correctly publishes transforms and link/joint states. I think I have a good handle publishing the transforms and states with a custom robot state publisher (I'm working on an implementation based on the tutorial: http://wiki.ros.org/urdf/Tutorials/Us... ) but I'm getting bogged down in the implementation details trying to work out how to update the collision and visualization meshes

There are 3 possibilities that seem feasible:

  1. Publish the link as a marker with the transforms in a robot state publisher and skip the link in the urdf file that rviz parses so that the marker just fills in for the boom.

  2. Modify a rviz node to update the representation of the mesh for the tube by subscribing to a robot state publisher along the lines of the answer to this thread: http://answers.ros.org/question/9425/... I'm still trying to understand how exactly rviz displays the model, but I assume it can be done programatically similar to gazebo.

  3. It seems like a pointer to a robot model is passed around in gazebo, if this is also true in rviz it might be possible to subscribe to the pointer to the model in my state publisher, build the new model and switch it out with the old one. I'm not sure how to deal with race conditions that would be caused here without modifying rviz.

Does anyone have a better idea for how this could be done? Do any of the ideas I have so far seem like they are the right way to go?

2014-04-20 06:55:50 -0500 marked best answer Adding ROS install tutorials

I went through the process of building ROS Hydro from source on Debian and recorded to process for wiki material. I just created an account with the ros.org and it seems like I don't have the kind of privileges to go about making a new page. I had tried to edit yesterday and accidentally overwrote the install page, someone noticed it before I did and it has now been fixed. How do I add a page and link it to the Hydro experimental install section correctly, is this even how I should be contributing this material?

2014-04-20 06:55:49 -0500 marked best answer Catkin_make_isolated pthread linking error

I'm running a fresh install of Debian Wheezy and trying to install ROS hydro from source and am on the following step:

./src/catkin/bin/catkin_make_isolated --install

My build dies 3/4 of the way through, but for a different error than the one in this question. Trying to solve this other issue I became curious about one of the common cmake errors I get in the CMakeError.log's:

$ find . -type f -exec grep "cannot find" {} +
...
./build_isolated/tf2_bullet/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/rqt_web/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/rqt_plot/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/robot/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/angles/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/pcl_conversions/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/smach_ros/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/rqt_srv/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/catkin/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/random_numbers/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/trajectory_msgs/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/rosmaster/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/eigen_conversions/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/geometric_shapes/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
./build_isolated/collada_parser/CMakeFiles/CMakeError.log:/usr/bin/ld: cannot find -lpthreads
... and hundreds more

The full error from ./build_isolated/rosmaster/CMakeFiles/CMakeError.log looks like:

$cat ./build_isolated/rosmaster/CMakeFiles/CMakeError.log
...
/usr/bin/gcc         CMakeFiles/cmTryCompileExec1355085001.dir/CheckSymbolExists.c.o  -o cmTryCompileExec1355085001 -rdynamic 
CMakeFiles/cmTryCompileExec1355085001.dir/CheckSymbolExists.c.o: In function `main':
CheckSymbolExists.c:(.text+0x16): undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
make[1]: *** [cmTryCompileExec1355085001] Error 1
make[1]: Leaving directory `/home/nexix/Documents/source/ros_catkin_ws/build_isolated/rosmaster/CMakeFiles/CMakeTmp'
make: *** [cmTryCompileExec1355085001/fast] Error 2
...
/usr/bin/gcc     -DCHECK_FUNCTION_EXISTS=pthread_create    CMakeFiles/cmTryCompileExec2282391930.dir/CheckFunctionExists.c.o  -o cmTryCompileExec2282391930 -rdynamic -lpthreads 
/usr/bin/ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status
make[1]: *** [cmTryCompileExec2282391930] Error 1
make[1]: Leaving directory `/home/nexix/Documents/source/ros_catkin_ws/build_isolated/rosmaster/CMakeFiles/CMakeTmp'
make: *** [cmTryCompileExec2282391930/fast] Error 2

I have pthread installed, but the spelling is slightly different:

$ locate libpthread
/lib/x86_64-linux-gnu/libpthread-2.13.so
/lib/x86_64-linux-gnu/libpthread.so.0
/usr/lib/x86_64-linux-gnu/libpthread.a
/usr/lib/x86_64-linux-gnu/libpthread.so
/usr/lib/x86_64-linux-gnu/libpthread_nonshared.a

But looking in the CMakeCache file makes it look like the logic is there to get around naming differences like that:

$ cat ./build_isolated/rosmaster/CMakeCache.txt
...
gtest_LIB_DEPENDS:STATIC=general;-lpthread;
...
//Disable uses of pthreads in gtest.
gtest_disable_pthreads:BOOL=OFF
...
//Dependencies for the target
gtest_main_LIB_DEPENDS:STATIC=general;-lpthread;general;gtest;
...
//Have symbol pthread_create
CMAKE_HAVE_LIBC_CREATE:INTERNAL=
//Have library pthreads
CMAKE_HAVE_PTHREADS_CREATE:INTERNAL=
//Have library pthread
CMAKE_HAVE_PTHREAD_CREATE:INTERNAL=1
//Have include pthread.h
CMAKE_HAVE_PTHREAD_H:INTERNAL=1
...

My question is how do I find out if this is causing compile problems? It seems to be ... (more)

2014-04-20 06:55:39 -0500 marked best answer Rosdep failed to detect argparse (Debian)

Hi guys,

I'm trying to build ROS hydro/groovy (recently switched to hydro upon hearing that groovy may have had more than its fair share of bugs) on Debian Jesse and have been having a lot of trouble getting rosdep to run all the way through. I tried skipping rosdep and just manually installing the packages with apt-get when the catkin build process stalled on a missing package, but once I thought I got them all it got bogged down in a mess of linking errors. This made me think rosdep maybe was doing something other than just getting apt-get to fill all of the dependencies. I finally managed to build collada-dom-dev and so rosdep would stop failing there but now it fails to find python argparse. It's my understanding that argparse is provided by python 2.7 (the library libpython2.7-stdlib specifically) which I verified by checking packages.debian.org/jessie/python-argparse. Does anyone know how to get rosdep to recognize that python contains argparse and to link the libraries there? I will update the wiki with everything I learn from your responses!

Peter

2014-04-17 10:54:17 -0500 commented answer KDL Kinematics Solver Limitations

Thanks for the links, I'm pursuing the plug-in style to start with. I think I might need the TranslationDirection5D because of the wrists degrees of freedom but I would like to learn to use the IKFast generator, I'll try to see if I can add/test the other cases when the semester ends.

2014-04-17 10:42:36 -0500 marked best answer KDL Kinematics Solver Limitations

I'm working on integrating a robot model consisting of 1 DOF revolute and prismatic joints with moveit and have made a simplified example to make it easier to break down the problems: https://github.com/st3am/KDL-Test (roslaunch kdl_test demol.launch)

image description

I think I'm seeing issues with the KDL kinematics solver. When I have my arm in a configuration of just 2 DOF I can not move the interactive marker. This makes perfect sense to me because the end effector point can not be moved in any direction without increasing the radius from the origin and the chances that I release the marker on the thin spherical shell (.005 thickness defined in the kinematics.yaml) are very low.

The problem occurs when I add the prismatic joint at the end of this arm. The solver can find solutions if I pull the joint out in the axis that is collinear with the axis of the prismatic joint (I manipulate this with the interactive marker on the end effector link), but no solutions are found when I try moving it perpendicular to this radial axis. The sphere of possible solutions is much larger in this case; extending the length between the prismatic joints.

When I add a revolute joint at the end of the prismatic joint and make it the new end effector I can get radial motion perpendicular to the revolute axis because the pose of the end effector does not have to change. By changing the pose and radial position with in steps with the marker I can get the arm to revolve all the way around on a single plane. When I add a second revolute joint perpendicular to the first and make it the new end effector I can move it in either axis, but the first one I move it in subsequently locks the second one. When I try to set a move group goal with all 5 DOF using moveit::planning_interface::MoveGroup.setPositionTarget(), moveit cant find a kinematic solution and times out.

Can anyone tell me if this is a limitation of KDL or if it looks like I'm doing something incorrectly? It seems like in this case the KDL can't find the orientation for a pose either because I'm not giving it what its expecting or because the limited number of DOF's along the prismatic joints somehow cause its root finding algorithms to run into a sort of gimal lock.

2014-04-17 10:42:34 -0500 commented answer KDL Kinematics Solver Limitations

Thanks, adding "position_only_ik: True" to my kinematics.yaml file got me to the point where I could find IK solutions with the interactive marker for my demo. Because the joint angles are fully determined for any possible end effector pose I think the KinematicsBasePlugin is the best end solution