Giter VIP home page Giter VIP logo

robot_model's Introduction

Robot Model

robot_model contains packages for modeling various aspects of robot information, specified in the Xml Robot Description Format (URDF). The core package of this stack is urdf, which parses URDF files, and constructs an object model (C++) of the robot.

Deprecation

This repository and the robot_model metapackage are deprecated. The other packages will continue to be maintained, but are being moved to new repositories. More information is available at ros/robot_model#195.

Moved Repos

robot_model's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

robot_model's Issues

Update gitignore file.

I would like to have a .gitignore file added. From the top-level of my ROS workspace when I run:

$ rosws status --untracked

I get the following output:

??      ros/robot_model/collada_parser/build/
??      ros/robot_model/collada_parser/lib/
??      ros/robot_model/collada_urdf/bin/
??      ros/robot_model/collada_urdf/build/
??      ros/robot_model/collada_urdf/lib/
??      ros/robot_model/colladadom/build/
??      ros/robot_model/colladadom/include/
??      ros/robot_model/colladadom/installed
??      ros/robot_model/colladadom/lib/
??      ros/robot_model/colladadom/wiped
??      ros/robot_model/convex_decomposition/build/
??      ros/robot_model/convex_decomposition/convex_decomposition/
??      ros/robot_model/convex_decomposition/installed
??      ros/robot_model/convex_decomposition/wiped
??      ros/robot_model/ivcon/bin/
??      ros/robot_model/ivcon/build/
??      ros/robot_model/kdl_parser/bin/
??      ros/robot_model/kdl_parser/build/
??      ros/robot_model/kdl_parser/lib/
??      ros/robot_model/resource_retriever/build/
??      ros/robot_model/resource_retriever/lib/
??      ros/robot_model/robot_state_publisher/bin/
??      ros/robot_model/robot_state_publisher/build/
??      ros/robot_model/robot_state_publisher/lib/
??      ros/robot_model/simmechanics_to_urdf/build/
??      ros/robot_model/srdf/build/
??      ros/robot_model/srdf/lib/
??      ros/robot_model/urdf/bin/
??      ros/robot_model/urdf/build/
??      ros/robot_model/urdf/lib/
??      ros/robot_model/urdf_interface/build/
??      ros/robot_model/urdf_parser/bin/
??      ros/robot_model/urdf_parser/build/
??      ros/robot_model/urdf_parser/lib/

KDL vs. Gazebo: Inertia in the root link

KDL does not support inertia in the root link. So far one just left out the inertia specification in the URDF for the root link (as done here). Unfortunately, this now causes a crash, if somebody is using Gazebo in Fuerte (e.g.: turtlebot simulation).

To me this seems to be a design mismatch between KDL and Gazebo. Any idea how to align both?

Remark: Would be interesting, why root link inertia is now required in Gazebo and wasn't before.

physics support for collada_parser

find attachment for reading mass,inertia property from collada format into urdf/Link object.

I have few questions:

  1. urdf its self has 6 elements for inertia xx,yy,zz,ix,iy,iz where as collada rigid_body -> technique_common -> inertia has only xx,yy,zz elements (see collada_robots/data/robots/willowgarage-pr2.dae). rigid_body tag is not clearly
    defined in http://openrave.programmingvision.com/wiki/index.php/Format:COLLADA ,
    I would be fine if we can support the both
    xx yy zz or xx yy zz ix iy iz tag syntax.

  2. I'd like to upload model using following commands and gazebo requires tag

rosrun gazebo spawn_model -file robot.dae -urdf -model robot -z 1

what is the best way to include this information in the colllada file?
I tried 2 syntax as followings but both produced COLLADA warning with schema violation, but works fine with urdf2gazebo.patch.

.....
<gazebo>
</gazebo>

and other is

...

<extra type="physics" name="gazebo">
<gazebo>
</gazebo>
  1. what is the reference robot.urdf model that we can test urdf_to_collada and collada_parsaer works fine?

ros-groovy-resource-retriever and gdal

The .deb should depend on libcurl-ssl-dev and not libcurl4-openssl-dev, that conflicts with libcurl4-gnutls-dev which GDAL depends on.

[ http://wiki.ros.org/resource_retriever points this as the issue tracker ]

joint_state_publisher node issues with floating joints

System Configuration:

  • ROS version: Hydro
  • Ubuntu version: 12.04

The joint_state_publisher node crashes or produces invalid joint states when floating joints are present in the URDF. There are two failure modes depending on what other joints are present in the URDF

Steps to reproduce:

  1. URDF contains only a single floating joint

    1. URDF File:

      <?xml version="1.0" ?>
      <robot name = "jsp_bug" xmlns:xacro="http://ros.org/wiki/xacro">
      <link name="world" />
      <link name="floating_link" />
      <joint name="world-to-floating-link" type="floating">
      <parent link="world"/>
      <child link="floating_link"/>
      <origin xyz="0 0 0" rpy="0 0 0"/>
      </joint>
      </robot>
      
    2. View URDF using roslaunch urdf_tutorial xacrodisplay.launch model:=<xacro_file>.xacro use_gui:=true

    3. The following error is generated by robot_state_publisher: [ERROR] [1411791439.030568077]: Robot state publisher received an invalid joint state vector

    4. The joint_state topic echo shows:

    ---
    header: 
    seq: 236
    stamp: 
    secs: 1411789283
    nsecs: 295578002
    frame_id: ''
    name: ['world-to-floating-link']
    position: []
    velocity: []
    effort: []
    ---
    
  2. URDF contains a single floating joint and revolute joint

    1. URDF File:

      <?xml version="1.0" ?>
      <robot name = "jsp_bug" xmlns:xacro="http://ros.org/wiki/xacro">
      
      <link name="world" />
      <link name="floating_link" />
      <link name="revolute_link" />
      <joint name="world-to-floating-link" type="floating">
      <parent link="world"/>
      <child link="floating_link"/>
      <origin xyz="0 0 0" rpy="0 0 0"/>
      </joint>
      
      <joint name="world-to-revolute-link" type="revolute">
      <origin xyz="0 0 0" rpy="0 0 0" />
      <parent link="world" />
      <child link="revolute_link" />
      <axis xyz="0 1 0" />
      <limit lower="-3.14" upper="3.14" effort="0" velocity="3.14" />
      </joint>
      </robot>
      
    2. View URDF using roslaunch urdf_tutorial xacrodisplay.launch model:=<xacro_file>.xacro use_gui:=true

    3. The joint_state_publisher node crashes with the following:

    process[rviz-4]: started with pid [13283]
    Traceback (most recent call last):
    File "/opt/ros/hydro/lib/joint_state_publisher/joint_state_publisher", line 330, in <module>
    jsp.loop()
    File "/opt/ros/hydro/lib/joint_state_publisher/joint_state_publisher", line 202, in loop
    if has_position and 'position' in joint:
    TypeError: argument of type 'NoneType' is not iterable
    [joint_state_publisher-2] process has died [pid 13262, exit code 1, cmd /opt/ros/hydro/lib/joint_state_publisher/joint_state_publisher __name:=joint_state_publisher __log:=/home/ros/.ros/log/9de95ddc-45fe-11e4-b3c6-080027f3243a/joint_state_publisher-2.log].
    log file: /home/ros/.ros/log/9de95ddc-45fe-11e4-b3c6-080027f3243a/joint_state_publisher-2*.log
    

    Expected Result:
    In the first case, the floating joint is incorrectly included in joint states. A floating joint requires a 6DOF transform, so a single joint state value is not valid. The source for floating joints should be tf. In the case that a valid tf is not present, joint state publisher could publish the default transform specified by origin in the floating joint.

Joint State publisher fails on OS X

Reposting tingfan's post from answers.ros.org: http://answers.ros.org/question/32616/joint_state_publisher-on-osx

When running joint_state_publisher on OSX Lion, I encounter the following error

[INFO] [WallTime: 1335373686.654959] Centering
2012-04-25 10:08:06.886 Python[41356:450b] *** Assertion failure in +[NSUndoManager _endTopLevelGroupings], /SourceCache/Foundation/Foundation-833.24/Misc.subproj/NSUndoManager.m:324
2012-04-25 10:08:06.888 Python[41356:450b] +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only safe to invoke on the main thread.
2012-04-25 10:08:06.901 Python[41356:450b] (
    0   CoreFoundation                      0x00007fff8c261fc6 __exceptionPreprocess + 198
    1   libobjc.A.dylib                     0x00007fff9040dd5e objc_exception_throw + 43
    2   CoreFoundation                      0x00007fff8c261dfa +[NSException raise:format:arguments:] + 106
    3   Foundation                          0x00007fff93a7c743 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 169
    4   Foundation                          0x00007fff939eb983 +[NSUndoManager(NSPrivate) _endTopLevelGroupings] + 144
    5   AppKit                              0x00007fff8df2721b -[NSApplication run] + 596
    6   libwx_osx_cocoau_core-2.9.dylib     0x000000010d637e20 _ZN14wxGUIEventLoop5DoRunEv + 44
    7   libwx_baseu-2.9.dylib               0x000000010dbebf79 _ZN13wxCFEventLoop3RunEv + 63
    8   libwx_baseu-2.9.dylib               0x000000010db3cd97 _ZN16wxAppConsoleBase8MainLoopEv + 81
    9   _core_.so                           0x000000010cfa5619 _ZN7wxPyApp8MainLoopEv + 81
    10  _core_.so                           0x000000010cfc1c2b _wrap_PyApp_MainLoop + 235
    11  Python                              0x000000010c5315d8 PyEval_EvalFrameEx + 16006
    12  Python                              0x000000010c533cd8 PyEval_EvalCodeEx + 1996
    13  Python                              0x000000010c4d1abf PyClassMethod_New + 1378
    14  Python                              0x000000010c4b0d32 PyObject_Call + 97
    15  Python                              0x000000010c4bf6e9 PyInstance_New + 13169
    16  Python                              0x000000010c4b0d32 PyObject_Call + 97
    17  Python                              0x000000010c530f63 PyEval_EvalFrameEx + 14353
    18  Python                              0x000000010c533cd8 PyEval_EvalCodeEx + 1996
    19  Python                              0x000000010c4d1abf PyClassMethod_New + 1378
    20  Python                              0x000000010c4b0d32 PyObject_Call + 97
    21  Python                              0x000000010c5315ec PyEval_EvalFrameEx + 16026
    22  Python                              0x000000010c533df7 PyEval_EvalCode + 224
    23  Python                              0x000000010c530e0a PyEval_EvalFrameEx + 14008
    24  Python                              0x000000010c533df7 PyEval_EvalCode + 224
    25  Python                              0x000000010c530e0a PyEval_EvalFrameEx + 14008
    26  Python                              0x000000010c533cd8 PyEval_EvalCodeEx + 1996
    27  Python                              0x000000010c4d1abf PyClassMethod_New + 1378
    28  Python                              0x000000010c4b0d32 PyObject_Call + 97
    29  Python                              0x000000010c4bf6e9 PyInstance_New + 13169
    30  Python                              0x000000010c4b0d32 PyObject_Call + 97
    31  Python                              0x000000010c52cc40 PyEval_CallObjectWithKeywords + 180
    32  Python                              0x000000010c55e40d initthread + 2629
    33  libsystem_c.dylib                   0x00007fff9074b8bf _pthread_start + 335
    34  libsystem_c.dylib                   0x00007fff9074eb75 thread_start + 13
)

After some google search, it appears the issue that in newer Cocoa/Lion?, it requires the "App.MainLoop?" run in the same thread as the thread who initialize the wx. In joint state publisher, the App.MainLoop? is run by a newly created thread while the main thread is used to send out joint_state messages..

Here I provide an workaround that swap these two threads,

diff -r 655f14965dbc joint_state_publisher/joint_state_publisher
--- a/joint_state_publisher/joint_state_publisher   Wed Jun 01 14:37:58 2011 -0700
+++ b/joint_state_publisher/joint_state_publisher   Wed Apr 25 10:00:03 2012 -0700
@@ -58,10 +58,10 @@
         use_gui = get_param("use_gui", False)

         if use_gui:
-            app = wx.App()
+            self.app = wx.App()
             self.gui = JointStatePublisherGui("Joint State Publisher", self)
             self.gui.Show()
-            Thread(target=app.MainLoop).start()
         else:
             self.gui = None

@@ -200,7 +203,8 @@
     try:
         rospy.init_node('joint_state_publisher')
         jsp = JointStatePublisher()
-        jsp.loop()
+        Thread(target=jsp.loop).start()
+        jsp.app.MainLoop()

     except rospy.ROSInterruptException: pass

Here's a minimum set of code to generate the same crash

def gui():
        import wx
        app = wx.App()
        frame = wx.Frame(None)
        frame.Show()
        app.MainLoop()
import threading
threading.Thread(target=gui).start()

Again this is reposted from: http://answers.ros.org/question/32616/joint_state_publisher-on-osx

urdf_to_collada in collada_urdf seg faults

When trying to convert a URDF file to Collada in Groovy, a segfault occurs. This problem started after upgrading to Groovy - it did not occur in Fuerte. I have testing the urdf_to_collada converter with lots of simplistic URDF variants but the crash always occurs.

rosrun collada_urdf urdf_to_collada clam.urdf clam.dae

Gives me:

Reading symbols from /opt/ros/groovy/lib/collada_urdf/urdf_to_collada...(no debugging symbols found)...done.
Starting program: /opt/ros/groovy/lib/collada_urdf/urdf_to_collada clam.urdf clam_new.dae __name:=urdf_to_collada __log:=/home/dave/.ros/log/541e7d72-8507-11e2-96d9-d43d7e05aeaf/urdf_to_collada-2.log
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device]
Usage: urdf_to_collada input.urdf output.dae
[Inferior 1 (process 20133) exited with code 0377]
(gdb) bt
No stack.

@isucan I mentioned this problem to you a while back, any thoughts?

Thanks!

collada_dom 2.4 on gentoo

While installing collada_parser package, I ran into an odd error where it failed compiling beause it could not find collada_dom's dae.h file (no longer have the exact backlog, sorry)

the location of this file on my system is:

/usr/include/collada-dom2.4/dae.h

I fixed this by changing line 20 of src/robot_model/collada_parser/CMakeLists.txt from:

find_package(COLLADA_DOM 2.3 COMPONENTS 1.5)

to

find_package(COLLADA_DOM 2.4 COMPONENTS 1.5)

As an aside, this likely needs a REQUIRED or something.

kdl_parser as ros_build dependency causes error in service generation (hydro)

I encountered a very strange issue with kdl_parser when updating to hydro. I have a dry package that depends on kdl_parser and also defines some services. Running rosmake on the package produces an error in generating the services. If the dependency to kdl_parser is removed, the issue is resolved.

To reproduce the bug:
roscreate-pkg test kdl_parser sensor_msgs
cd test
mkdir srv
echo -e 'sensor_msgs/PointCloud2 in \n---\nsensor_msgs/PointCloud2 out' > srv/Test.srv
echo "rosbuild_gensrv()" >> CMakeLists.txt
rosmake

Output:
Traceback (most recent call last):
File "/opt/ros/hydro/share/roslisp/rosbuild/scripts/genmsg_lisp.py", line 873, in
generate_srv(sys.argv[1])
File "/opt/ros/hydro/share/roslisp/rosbuild/scripts/genmsg_lisp.py", line 822, in generate_srv
write_srv_component(s, spec.request, spec)
File "/opt/ros/hydro/share/roslisp/rosbuild/scripts/genmsg_lisp.py", line 697, in write_srv_component
write_md5sum(s, spec, parent)
File "/opt/ros/hydro/share/roslisp/rosbuild/scripts/genmsg_lisp.py", line 596, in write_md5sum
compute_files=False)
File "/opt/ros/hydro/lib/python2.7/dist-packages/roslib/gentools.py", line 325, in get_dependencies
raise MsgSpecException("Cannot load type %s. Perhaps the package is missing a dependency."%(str(e)))
roslib.msgs.MsgSpecException: Cannot load type 'sensor_msgs/PointCloud2'. Perhaps the package is missing a dependency.

wrong lib options for urdf (and others)

HI, currently pkg-config --libs urdf returns -l with -l:/xxx not -l/xxx thats breaks downstream packages. i'm not if 1.10.19 fixed this problem, but need new release. I think current release is http://jenkins.ros.org/job/ros-hydro-urdf_sourcedeb/ 1.10.18.

$ pkg-config --libs urdf
-L/opt/ros/hydro/lib -lurdf -l:/opt/ros/hydro/lib/liburdfdom_sensor.so -l:/opt/ros/hydro/lib/liburdfdom_model_state.so -l:/opt/ros/hydro/lib/liburdfdom_model.so -l:/opt/ros/hydro/lib/liburdfdom_world.so -lrosconsole_bridge -lroscpp -l:/usr/lib/libboost_signals-mt.so -l:/usr/lib/libboost_filesystem-mt.so -lrosconsole -lrosconsole_log4cxx -lrosconsole_backend_interface -l:/usr/lib/liblog4cxx.so -l:/usr/lib/libboost_regex-mt.so -lxmlrpcpp -lroscpp_serialization -lrostime -l:/usr/lib/libboost_date_time-mt.so -l:/usr/lib/libboost_system-mt.so -l:/usr/lib/libboost_thread-mt.so -lpthread -lcpp_common -l:/opt/ros/hydro/lib/libconsole_bridge.so

$ LANG=C aptitude show ros-hydro-urdf
Package: ros-hydro-urdf                  
New: yes
State: installed
Automatically installed: no
Version: 1.10.18-1precise-20140617-0608-+0000
Priority: extra
Section: misc
Maintainer: Ioan Sucan <[email protected]>
Architecture: amd64
Uncompressed Size: 251 k
Depends: libboost-filesystem1.46.1 (>= 1.46.1-1), libboost-system1.46.1 (>= 1.46.1-1), libc6 (>= 2.14), libgcc1 (>=
         1:4.1.1), libstdc++6 (>= 4.6), libtinyxml2.6.2, ros-hydro-pluginlib, ros-hydro-rosconsole-bridge,
         ros-hydro-roscpp, ros-hydro-urdf-parser-plugin, ros-hydro-urdfdom, ros-hydro-urdfdom-headers
Conflicts: ros-hydro-urdf
Description: This package contains a C++ parser for the Unified Robot Description Format (URDF), which is an XML format for representing a robot model. The code API of the parser has been through our review process and will remain backwards compatible in future releases.

Homepage: http://ros.org/wiki/urdf


urdf_to_collada:

I get the following errors and I can't find the error. The command used is

rosrun collada_urdf urdf_to_collada ./input.urdf ./out.dae

I/O error : No such file or directory
I/O error : No such file or directory
error : xmlNewTextWriterFilename : cannot open uri

My system is Ubuntu 14.04, 64bits, ROS Indigo. ROS Answer didn't help much :(

resource_retriever: Add support for param:// to use ROS param

It would be nice to have a param:// protocol as well, so that the contents of an URDF could be set to something like 'param:///robot_description' or 'package://my_robot/urdf/robot.urdf'.

If putting that in complicates things (since it requires the ROS be init'd), then there could be an extra boolean flag to make it explicit (and error out if param:// is requested without that flag).

If others are interested, I could implement that feature.

collada_to_urdf does not supports cylinder shapes with radius < 0.01m

This is an odd one: When the URDF contains a link with a cylinder shape geometry with a radius smaller than 0.01m urdf_to_collada segfaults.

Cylinder length can be smaller than 0.01m and sphere and box shapes are immune to this error (i.e. sizes can be smaller than 0.01).

This example URDF segaults:

<robot name="test_robot" xmlns:xacro="http://www.ros.org/wiki/xacro">
  <link name="test_link">
    <visual>
      <geometry>
        <cylinder length="0.009" radius="0.009"/>
      </geometry>
      <origin xyz="0.0 0.0 0.0" rpy="0 0 0"/>
    </visual>
  </link>
</robot>

Where as changing radius="0.009" to radius="0.01" makes it work again.

Segfault backtrace:

#0  0x00007ffff6d20002 in collada_urdf::ColladaWriter::_loadVertices (this=0x7fffffffd2c0, mesh=0x705ce0, pdomgeom=...)
    at /opt/korus_workspace/moveit_ws/src/robot_model/collada_urdf/src/collada_urdf.cpp:1484
#1  0x00007ffff6d1d4ea in collada_urdf::ColladaWriter::_WriteGeometry (this=0x7fffffffd2c0, geometry=..., geometry_id=..., org_trans=0x0)
    at /opt/korus_workspace/moveit_ws/src/robot_model/collada_urdf/src/collada_urdf.cpp:1306
#2  0x00007ffff6d1b155 in collada_urdf::ColladaWriter::_WriteLink (this=0x7fffffffd2c0, plink=..., pkinparent=..., pnodeparent=..., strModelUri=...)
    at /opt/korus_workspace/moveit_ws/src/robot_model/collada_urdf/src/collada_urdf.cpp:1199
#3  0x00007ffff6d182f1 in collada_urdf::ColladaWriter::WriteKinematics_model (this=0x7fffffffd2c0, id=0)
    at /opt/korus_workspace/moveit_ws/src/robot_model/collada_urdf/src/collada_urdf.cpp:1030
#4  0x00007ffff6d15bcc in collada_urdf::ColladaWriter::_WriteInstance_kinematics_model (this=0x7fffffffd2c0, parent=..., sidscope=..., id=0)
    at /opt/korus_workspace/moveit_ws/src/robot_model/collada_urdf/src/collada_urdf.cpp:878
#5  0x00007ffff6d134b4 in collada_urdf::ColladaWriter::_WriteRobot (this=0x7fffffffd2c0, id=0)
    at /opt/korus_workspace/moveit_ws/src/robot_model/collada_urdf/src/collada_urdf.cpp:787
#6  0x00007ffff6d11c87 in collada_urdf::ColladaWriter::convert (this=0x7fffffffd2c0) at /opt/korus_workspace/moveit_ws/src/robot_model/collada_urdf/src/collada_urdf.cpp:691
#7  0x00007ffff6d093f2 in collada_urdf::WriteUrdfModelToColladaFile (robot_model=..., file=...)
    at /opt/korus_workspace/moveit_ws/src/robot_model/collada_urdf/src/collada_urdf.cpp:1938
#8  0x0000000000407002 in main (argc=3, argv=0x7fffffffd7c8) at /opt/korus_workspace/moveit_ws/src/robot_model/collada_urdf/src/urdf_to_collada.cpp:57

Parallel Robots

" The main limitation at this point is that only tree structures can be represented, ruling out all parallel robots."

This issue is more of a wish.
I believe that it is time to integrate parallel robots in the URDF models and ROS in general.

URDF release 1.11.7 causes segfault on RVIZ

Hello!

I recently faced segfault running RVIZ in Ubuntu arm with ROS Indigo on jetson tk1.
Isssu is caused by release 1.11.7, because downgrading URDF back to 1.11.6 solves the issue.
As well, latest commit #108 did not resolve the issue.

GDB backtrace:

[ INFO] [1433239574.583682161]: OpenGl version: 4.4 (GLSL 4.4).
[New Thread 0xa8e363b0 (LWP 3071)]
[New Thread 0xa86363b0 (LWP 3072)]

Program received signal SIGSEGV, Segmentation fault.
is_anchored (code=code@entry=0x685460 "}", bracket_map=bracket_map@entry=0, 
    backref_map=backref_map@entry=0) at pcre_compile.c:7339
7339    pcre_compile.c: No such file or directory.

#0  is_anchored (code=code@entry=0x4e9858 "}", 
    bracket_map=bracket_map@entry=0, backref_map=backref_map@entry=0)
    at pcre_compile.c:7339
#1  0xb37c80de in pcre_compile2 (pattern=, 
    options=, errorcodeptr=errorcodeptr@entry=0x0, 
    errorptr=errorptr@entry=0xbeffde44, erroroffset=0xbeffde48, 
    tables=0xb37eda70 <_pcre_default_tables> "", tables@entry=0x0)
    at pcre_compile.c:8076
#2  0xb37c8240 in pcre_compile (pattern=, 
    options=, errorptr=0xbeffde44, 
    erroroffset=, tables=0x0) at pcre_compile.c:7616
#3  0xac27da72 in pcrecpp::RE::Compile(pcrecpp::RE::Anchor) ()
   from /usr/lib/arm-linux-gnueabihf/libpcrecpp.so.0
#4  0xac27db7a in pcrecpp::RE::Init(std::string const&, pcrecpp::RE_Options const*) () from /usr/lib/arm-linux-gnueabihf/libpcrecpp.so.0
#5  0xac27dbc4 in pcrecpp::RE::Init(char const*, pcrecpp::RE_Options const*)
    () from /usr/lib/arm-linux-gnueabihf/libpcrecpp.so.0
#6  0xa7ab998e in pcrecpp::RE::RE(char const*) ()
   from /home/chili/catkin_ws/devel/lib/liburdf.so
#7  0xa7ab8096 in __static_initialization_and_destruction_0(int, int) ()
   from /home/chili/catkin_ws/devel/lib/liburdf.so
#8  0xa7ab8132 in _GLOBAL__sub_I_model.cpp ()
   from /home/chili/catkin_ws/devel/lib/liburdf.so
---Type  to continue, or q  to quit---
#9  0xb6fea20e in call_init (l=, argc=1, argv=0xbeffec44, 
    env=0xbeffec4c) at dl-init.c:78
#10 0xb6fea2a0 in _dl_init (main_map=main_map@entry=0x4f1500, argc=1, 
    argv=0xbeffec44, env=0xbeffec4c) at dl-init.c:126
#11 0xb6fed076 in dl_open_worker (a=) at dl-open.c:577
#12 0xb6fea140 in _dl_catch_error (objname=objname@entry=0xbeffe164, 
    errstring=errstring@entry=0xbeffe168, 
    mallocedp=mallocedp@entry=0xbeffe163, 
    operate=0xb6fece41 , args=args@entry=0xbeffe16c)
    at dl-error.c:187
#13 0xb6feca8e in _dl_open (
    file=0x5ce864 "/opt/ros/indigo/lib/libdefault_plugin.so", 
    mode=-2147483391, 
    caller_dlopen=0xb5508e67 , nsid=, argc=1, argv=0xbeffec44, env=0xbeffec4c)
    at dl-open.c:661
#14 0xb5094af8 in dlopen_doit (a=0xbeffe3c0) at dlopen.c:66
#15 0xb6fea140 in _dl_catch_error (objname=0x2cd74, errstring=0x2cd78, 
    mallocedp=0x2cd70, operate=0xb5094aa5 , args=0xbeffe3c0)
    at dl-error.c:187
#16 0xb5094f48 in _dlerror_run (operate=0xb5094aa5 , 
    args=args@entry=0xbeffe3c0) at dlerror.c:163
#17 0xb5094b82 in __dlopen (
---Type  to continue, or q  to quit---
    file=0x5ce864 "/opt/ros/indigo/lib/libdefault_plugin.so", 
    mode=) at dlopen.c:87
#18 0xb5508e66 in Poco::SharedLibraryImpl::loadImpl(std::string const&) ()
   from /usr/lib/libPocoFoundation.so.9
#19 0xb55091ce in Poco::SharedLibrary::SharedLibrary(std::string const&) ()
   from /usr/lib/libPocoFoundation.so.9
#20 0xb64f5556 in class_loader::class_loader_private::loadLibrary(std::string const&, class_loader::ClassLoader*) ()
   from /opt/ros/indigo/lib/libclass_loader.so
#21 0xb64f181c in class_loader::ClassLoader::loadLibrary() ()
   from /opt/ros/indigo/lib/libclass_loader.so
#22 0xb64f199a in class_loader::ClassLoader::ClassLoader(std::string const&, bool) () from /opt/ros/indigo/lib/libclass_loader.so
#23 0xb64f79ec in class_loader::MultiLibraryClassLoader::loadLibrary(std::string const&) () from /opt/ros/indigo/lib/libclass_loader.so
#24 0xb6f83162 in pluginlib::ClassLoader::loadLibraryForClass(std::string const&) () from /opt/ros/indigo/lib/librviz.so

Please let me know if I can provide more information.

Use of multiple collision geometries in URDF models

As talked about at ROScon, multiple collision geometries have been added to the Atlas robot model and are currently used within the DRC project. This change apparently hasn't been coordinated with Ioan, who was pretty surprised (and not amused ;) ) about this.

This new feature certainly is useful. Unfortunately some existing tools like self_filter or MoveIt! planning will silently degrade in performance, as they currently only use the first defined collision object defined for a link and ignore all others (so they still "kind of" work, just not correctly).

Thus, inclusion of this addition into URDF should be discussed (and appropriate steps taken). As can be seen from tickets below, for example rviz already has been patched without prior coordination with the robot_model maintainer.

Some DRC related tickets:
https://bitbucket.org/osrf/drcsim/issue/255/atlas-urdf-and-sdf-collision-geometries
ros-visualization/rviz#633

Uninitialized value in urdf::Geometry

Hello,

Checking my code with valgrind I got an error:
Conditional jump or move depends on uninitialised value(s)

After investigating, it seems that the empty constructor of
::urdf::Geometry does not initialize the field "type".

I am using groovy provided by ubuntu-12.04 32bits.

reqeust for release of new version

current deb package (1.10.5) produces error when we use collada model file with robot_state_publisher. if we use current hydro-devel that contains following commi, it's ok. So I request to release new version for deb package.

9ac73ac

Linking issue with assimp when compiling from source on ARM

When doing so, I got this error:

/media/pendrive/ros/groovy/catkin_workspace/devel_isolated/collada_urdf/lib/libcollada_urdf.so: undefined reference to `vtable for Assimp::IOSystem'
/media/pendrive/ros/groovy/catkin_workspace/devel_isolated/collada_urdf/lib/libcollada_urdf.so: undefined reference to `typeinfo for Assimp::IOSystem'
collect2: ld returned 1 exit status

Launch file Param Zeros error (joint_state_publisher)

Hello,

i am trying to execute the next launch file with the "zeros" parameter of the node Joint_State_Publisher and i receive an error.

Launch File:

<arg name="model" />
<arg name="gui" default="False" />
<param name="robot_description" textfile="$(arg model)" />
<param name="use_gui" value="$(arg gui)"/>
<node name="joint_state_publisher" pkg="joint_state_publisher" type="joint_state_publisher">
        <param name="zeros" value="meded: 1.57075"/>
</node>
<node name="robot_state_publisher" pkg="robot_state_publisher" type="state_publisher" />
<node name="rviz" pkg="rviz" type="rviz" args="-d $(find urdf_tutorial)/urdf.rviz" required="true" />

URDF (without XML '<' character):

?xml version="1.0"?>
robot name="test">
link name="base_link">
visual>
geometry>
cylinder length="0.6" radius="0.2"/>
/geometry>
material name="blue">
color rgba="0 0 .8 1"/>
/material>
/visual>
/link>

link name="med">
visual>
geometry>
box size="0.6 .2 .1"/>
/geometry>
origin rpy="0 1.57075 0" xyz="0 0 -0.3"/>
material name="white">
color rgba="1 1 1 1"/>
/material>
/visual>
/link>

joint name="meded" type="revolute">
axis xyz="0 0 1"/>
limit effort="1000.0" lower="0.0" upper="3.1415926535" velocity="0.5"/>
parent link="base_link"/>
child link="med"/>
origin xyz="0 0 0.5" />
/joint>

/robot>

Error:

ubuntu@ubuntu-HP-EliteBook-8460p:~/catkin_ws/src/visbot/urdf$ roslaunch visbot test.launch model:='$(find visbot)/urdf/my_robot.urdf' gui:=True... logging to /home/ubuntu/.ros/log/9b19dbd0-e03c-11e4-b650-101f74f8af09/roslaunch-ubuntu-HP-EliteBook-8460p-18780.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://ubuntu-HP-EliteBook-8460p:51617/

SUMMARY

PARAMETERS

  • /joint_state_publisher/zeros: meded: 1.57075
  • /robot_description: <?xml version="1....
  • /rosdistro: indigo
  • /rosversion: 1.11.10
  • /use_gui: True

NODES
/
joint_state_publisher (joint_state_publisher/joint_state_publisher)
robot_state_publisher (robot_state_publisher/state_publisher)
rviz (rviz/rviz)

ROS_MASTER_URI=http://localhost:11311

core service [/rosout] found
process[joint_state_publisher-1]: started with pid [18798]
process[robot_state_publisher-2]: started with pid [18799]
process[rviz-3]: started with pid [18824]
Traceback (most recent call last):
File "/opt/ros/indigo/lib/joint_state_publisher/joint_state_publisher", line 328, in
jsp = JointStatePublisher()
File "/opt/ros/indigo/lib/joint_state_publisher/joint_state_publisher", line 84, in init
zeroval = self.zeros[name]
TypeError: string indices must be integers, not unicode
[joint_state_publisher-1] process has died [pid 18798, exit code 1, cmd /opt/ros/indigo/lib/joint_state_publisher/joint_state_publisher __name:=joint_state_publisher __log:=/home/ubuntu/.ros/log/9b19dbd0-e03c-11e4-b650-101f74f8af09/joint_state_publisher-1.log].
log file: /home/ubuntu/.ros/log/9b19dbd0-e03c-11e4-b650-101f74f8af09/joint_state_publisher-1*.log

Someone know which is the problem?

Best Regards.

robot_model metapackage has non catkin package dependencies

A metapackage should not depend on anything but the catkin packages which make it up. The robot_model metapackage depends on both system dependencies and catkin packages which are not part of this metapackage.

System dependencies:

  • assimp
  • collada-dom
  • curl
  • graphviz
  • urdfdom
  • urdfdom_headers

Other catkin packages it should not depend on:

  • angles
  • common_msgs
  • geometry
  • orocos_kdl
  • ros
  • ros_comm
  • rosconsole_bridge

Packages using liburdf: "Undefined reference" when linking

As posted on answers.ros.org http://answers.ros.org/question/37399/receive-an-undefined-reference-error-when-make/ there is an issue when compiling packages which link against liburdf.so
If I compile the package 'planning_models' from 'armnavigation' stack, I encounter the following compile error:

~/ros/robot_model/urdf/lib/liburdf.so: error: undefined reference to 'operator<<(std::basic_ostream<char, std::char_traits<char=""> >&, TiXmlNode const&)'

collect2: ld returned 1 exit status

This issue can be solved by appending '-ltinyxml' to the 'cpp cflags' line in manifest.xml of the urdf package. The resulting line looks like:

<cpp cflags="-I${prefix}/include" lflags="-Wl,-rpath,${prefix}/lib -L${prefix}/lib -lurdf -ltinyxml"/>

collada_to_urdf.cpp fails to compile

Building CXX object CMakeFiles/collada_urdf.dir/src/collada_urdf.cpp.o
hydro/src/collada_urdf/src/collada_to_urdf.cpp: In function ‘void assimp_file_export(std::string, std::string, std::string)’:
hydro/src/collada_urdf/src/collada_to_urdf.cpp:79:30: error: ‘AI_CONFIG_IMPORT_COLLADA_IGNORE_UP_DIRECTION’ was not declared in this scope
     importer.SetPropertyBool(AI_CONFIG_IMPORT_COLLADA_IGNORE_UP_DIRECTION, true, &existing);
                              ^
CMakeFiles/collada_to_urdf.dir/build.make:57: recipe for target 'CMakeFiles/collada_to_urdf.dir/src/collada_to_urdf.cpp.o' failed

The "AI_CONFIG_IMPORT_COLLADA_IGNORE_UP_DIRECTION" property was added in Assimp's git master branch[1] but is not present in any of the released versions.

[1] assimp/assimp@5470f5f

Release 1.10.21 Hydro

Since #93 (merged) is significant for one of the packages I maintain. I can test the DEB during shadow-fixed period. Thanks!

Segmentation fault in kdl_parser.

After building in Hydro one of my Gazebo plugins which use kdl_parser crash.
Backtrace:

#0  0x00007fffdc034e55 in boost::detail::atomic_increment (pw=0x4d) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:66
#1  0x00007fffdc034f76 in boost::detail::sp_counted_base::add_ref_copy (this=0x45) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:133
#2  0x00007fffdc035085 in boost::detail::shared_count::shared_count (this=0x7fff8f7fc758, r=...) at /usr/include/boost/smart_ptr/detail/shared_count.hpp:228
#3  0x00007ffff7e0ac3d in boost::shared_ptr<urdf::Link const>::shared_ptr<urdf::Link> (this=0x7fff8f7fc750, r=...) at /usr/include/boost/smart_ptr/shared_ptr.hpp:238
#4  0x00007ffff7e09d2d in kdl_parser::treeFromUrdfModel (robot_model=..., tree=...) at /home/konrad/ws/velma/src/robot_model/kdl_parser/src/kdl_parser.cpp:178
#5  0x00007ffff7e099bc in kdl_parser::treeFromXml (xml_doc=0x7fff8f7fc900, tree=...) at /home/konrad/ws/velma/src/robot_model/kdl_parser/src/kdl_parser.cpp:164
#6  0x00007ffff7e097d7 in kdl_parser::treeFromString (xml=..., tree=...) at /home/konrad/ws/velma/src/robot_model/kdl_parser/src/kdl_parser.cpp:154
#7  0x00007fffdc0320bd in gazebo::LWRController::GetRobotChain (this=0x7fff80435fb0) at /home/konrad/ws/velma/src/lwr_robot/lwr_simulation/src/lwr_controller.cpp:144
#8  0x00007fffdc031544 in gazebo::LWRController::Load (this=0x7fff80435fb0, _parent=..., _sdf=...) at /home/konrad/ws/velma/src/lwr_robot/lwr_simulation/src/lwr_controller.cpp:75
#9  0x00007ffff738d378 in gazebo::physics::Model::LoadPlugin(boost::shared_ptr<sdf::Element>) () from /usr/lib/libgazebo_physics.so.1
#10 0x00007ffff738d715 in gazebo::physics::Model::LoadPlugins() () from /usr/lib/libgazebo_physics.so.1
#11 0x00007ffff73cacba in gazebo::physics::World::ProcessFactoryMsgs() () from /usr/lib/libgazebo_physics.so.1
#12 0x00007ffff73cbb9e in gazebo::physics::World::ProcessMessages() () from /usr/lib/libgazebo_physics.so.1
#13 0x00007ffff73cc188 in gazebo::physics::World::Step() () from /usr/lib/libgazebo_physics.so.1
#14 0x00007ffff73cdf5c in gazebo::physics::World::RunLoop() () from /usr/lib/libgazebo_physics.so.1
#15 0x00007ffff5c85ce9 in thread_proxy () from /usr/lib/libboost_thread.so.1.46.1
#16 0x00007ffff6a9be9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#17 0x00007ffff502eccd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#18 0x0000000000000000 in ?? ()

Shows the problem somewhere in kdl_parser.

Collada_URDF Seg Fault

When converting a URDF to DAE file, urdf_to_collada crashes in the collada_urdf package. No output or error message is given except:

Segmentation fault (core dumped)

GDB backtrace reports:

gdb --ex run --args urdf_to_collada ~/ros/clam/src/clam_description/urdf_ikfast/clam.urdf ~/ros/clam/src/clam_description/urdf_ikfast/clam.dae
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/dave/ros/misc/devel/lib/collada_urdf/urdf_to_collada...(no debugging symbols found)...done.
Starting program: /home/dave/ros/misc/devel/lib/collada_urdf/urdf_to_collada /home/dave/ros/clam/src/clam_description/urdf_ikfast/clam.urdf /home/dave/ros/clam/src/clam_description/urdf_ikfast/clam.dae
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6c96f28 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x00007ffff6c96f28 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007ffff54ea300 in cdom::nativePathToUri(std::string const&, cdom::systemType) ()
   from /usr/lib/libcollada-dom2.4-dp.so.0
#2  0x00007ffff54dbbd0 in DAE::makeFullUri(std::string const&) () from /usr/lib/libcollada-dom2.4-dp.so.0
#3  0x00007ffff54dc2d6 in DAE::writeCommon(std::string const&, std::string const&, bool) ()
   from /usr/lib/libcollada-dom2.4-dp.so.0
#4  0x00007ffff7b51e30 in collada_urdf::colladaToFile(boost::shared_ptr<DAE>, std::string const&) ()
   from /home/dave/ros/misc/devel/lib/libcollada_urdf.so
#5  0x000000000040737b in main ()
(gdb) 
#0  0x00007ffff6c96f28 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007ffff54ea300 in cdom::nativePathToUri(std::string const&, cdom::systemType) ()
   from /usr/lib/libcollada-dom2.4-dp.so.0
#2  0x00007ffff54dbbd0 in DAE::makeFullUri(std::string const&) () from /usr/lib/libcollada-dom2.4-dp.so.0
#3  0x00007ffff54dc2d6 in DAE::writeCommon(std::string const&, std::string const&, bool) ()
   from /usr/lib/libcollada-dom2.4-dp.so.0
#4  0x00007ffff7b51e30 in collada_urdf::colladaToFile(boost::shared_ptr<DAE>, std::string const&) ()
   from /home/dave/ros/misc/devel/lib/libcollada_urdf.so
#5  0x000000000040737b in main ()

Compiling in Gentoo

Hi,
I was trying to collada_urdf on gentoo and I hat some problems linking with the collada library.

First I installed version 2 but in my system they where installed in include/collada/... so the includes in collada_urdf.cpp should be something like:

include <collada/assimp.hpp>

As I didn't want to edit the file and I saw version 3 is also accepted so I installed it but cmake still thought I was using version 2, I edited the CMakeFile in order to force version 3 and all went fine.

#if( ${ASSIMP_VERSION} STRGREATER "2.0.0" )
set(IS_ASSIMP3 1)
add_definitions(-DIS_ASSIMP3)
#endif()
include_directories(${ASSIMP_INCLUDE_DIRS})
link_directories(${ASSIMP_LIBRARY_DIRS})

Maybe there is a problem with the string comparation?

If you need me to test anything else please let me know.

Thanks.

Use common FindTinyXML.cmake

There is a new package called cmake_modules, which we just created:

https://github.com/ros/cmake_modules

It provides a common FindTinyXML.cmake CMake module, which we should all try to use in order to prevent issues when doing things like cross-compiling.

The affected packages I found:

  • collada_urdf
  • kdl_parser
  • urdf

This is a low priority, but a good idea. The package is available for Hydro and Groovy, it will be in public on the next sync.

kdl_parser build error

Hello, I'd like some help with this build error I'm getting. Google isnt turning up anything.

==> Processing catkin package: 'kdl_parser'
==> Creating build directory: 'build_isolated/kdl_parser'
==> Building with env: '/Users/alex/Code/ros/ros_catkin_ws/install_isolated/env.sh'
==> cmake /Users/alex/Code/ros/ros_catkin_ws/src/kdl_parser -DCATKIN_DEVEL_PREFIX=/Users/alex/Code/ros/ros_catkin_ws/devel_isolated/kdl_parser -DCMAKE_INSTALL_PREFIX=/Users/alex/Code/ros/ros_catkin_ws/install_isolated in '/Users/alex/Code/ros/ros_catkin_ws/build_isolated/kdl_parser'
-- The C compiler identification is Clang 5.0.0
-- The CXX compiler identification is Clang 5.0.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Boost version: 1.55.0
-- Using CATKIN_DEVEL_PREFIX: /Users/alex/Code/ros/ros_catkin_ws/devel_isolated/kdl_parser
-- Using CMAKE_PREFIX_PATH: /Users/alex/Code/ros/ros_catkin_ws/install_isolated
-- This workspace overlays: /Users/alex/Code/ros/ros_catkin_ws/install_isolated
-- Found PythonInterp: /usr/bin/python (found version "2.7.5")
-- Using PYTHON_EXECUTABLE: /usr/bin/python
-- Using default Python package layout
-- Found PY_em: /Library/Python/2.7/site-packages/em.pyc
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: /Users/alex/Code/ros/ros_catkin_ws/build_isolated/kdl_parser/test_results
-- Found gtest: gtests will be built
-- catkin 0.5.80
-- Found PkgConfig: /usr/local/bin/pkg-config (found version "0.28")
Looking for KDL in: /Users/alex/Code/ros/ros_catkin_ws/install_isolated
-- checking for one of the modules 'orocos_kdl'
   Includes in: /Users/alex/Code/ros/ros_catkin_ws/install_isolated/include;/usr/local/include/eigen3
Compiler flags: -I/Users/alex/Code/ros/ros_catkin_ws/install_isolated/include;-I/usr/local/include/eigen3
   Libraries: orocos-kdl
   Libraries in: /Users/alex/Code/ros/ros_catkin_ws/install_isolated/lib
   Linker flags :
   Defines:
-- Found TinyXML: /usr/local/lib/libtinyxml.dylib
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/alex/Code/ros/ros_catkin_ws/build_isolated/kdl_parser
==> make -j4 -l4 in '/Users/alex/Code/ros/ros_catkin_ws/build_isolated/kdl_parser'
Scanning dependencies of target kdl_parser
[ 50%] Building CXX object CMakeFiles/kdl_parser.dir/src/kdl_parser.cpp.o
Linking CXX shared library /Users/alex/Code/ros/ros_catkin_ws/devel_isolated/kdl_parser/lib/libkdl_parser.dylib
[ 50%] Built target kdl_parser
Scanning dependencies of target check_kdl_parser
[100%] Building CXX object CMakeFiles/check_kdl_parser.dir/src/check_kdl_parser.cpp.o
/Users/alex/Code/ros/ros_catkin_ws/src/kdl_parser/src/check_kdl_parser.cpp:49:49: error: no member named 'segment' in
      'boost::shared_ptr<KDL::TreeElement>'; did you mean to use '->' instead of '.'?
  cout << prefix << "- Segment " << link->second.segment.getName() << " has " << link->second.children.size() << " child...
                                                ^
                                                ->
/Users/alex/Code/ros/ros_catkin_ws/src/kdl_parser/src/check_kdl_parser.cpp:49:94: error: no member named 'children' in
      'boost::shared_ptr<KDL::TreeElement>'; did you mean to use '->' instead of '.'?
  cout << prefix << "- Segment " << link->second.segment.getName() << " has " << link->second.children.size() << " child...
                                                                                             ^
                                                                                             ->
/Users/alex/Code/ros/ros_catkin_ws/src/kdl_parser/src/check_kdl_parser.cpp:50:40: error: no member named 'children' in
      'boost::shared_ptr<KDL::TreeElement>'; did you mean to use '->' instead of '.'?
  for (unsigned int i=0; i<link->second.children.size(); i++)
                                       ^
                                       ->
/Users/alex/Code/ros/ros_catkin_ws/src/kdl_parser/src/check_kdl_parser.cpp:51:27: error: no member named 'children' in
      'boost::shared_ptr<KDL::TreeElement>'; did you mean to use '->' instead of '.'?
    printLink(link->second.children[i], prefix + "  ");
                          ^
                          ->
4 errors generated.
make[2]: *** [CMakeFiles/check_kdl_parser.dir/src/check_kdl_parser.cpp.o] Error 1
make[1]: *** [CMakeFiles/check_kdl_parser.dir/all] Error 2
make: *** [all] Error 2
<== Failed to process package 'kdl_parser':
  Command '/Users/alex/Code/ros/ros_catkin_ws/install_isolated/env.sh make -j4 -l4' returned non-zero exit status 2

Reproduce this error by running:
==> cd /Users/alex/Code/ros/ros_catkin_ws/build_isolated/kdl_parser && /Users/alex/Code/ros/ros_catkin_ws/install_isolated/env.sh make -j4 -l4

Command failed, exiting.

collada_urdf "double-free corruption"

When running the collada_urdf utility under Ubuntu 14.04 and ROS Indigo (latest Debian install), the following error message is displayed when converting even the simplest URDF file to Collada format:

 $ rosrun collada_urdf urdf_to_collada box_robot_base_only.urdf box_robot.dae

 Document successfully written to box_robot.dae
*** Error in `/opt/ros/indigo/lib/collada_urdf/urdf_to_collada': double free or corruption (fasttop):     0x000000000191cb90 ***
Aborted

It seems that the .dae file is created OK but the error message is rather discouraging.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.