Floating base URDF joint has random child joints after library ugrade about urdfdom

[mcamurri]

UPDATE: the number of joints seems randomic, like the parsing fails to initialize the variables.

Here is a M(N)WE:

robot.urdf:

<?xml version="1.0" ?>
<robot name="robot" xmlns:xacro="http://ros.org/wiki/xacro">
  <joint name="floating_base" type="floating">
    <parent link="base_link"/>
    <child link="trunk"/>
  </joint>
  <!-- Links -->
  <!-- Footprint link -->
  <link name="base_link">
  </link>
  <!-- Trunk link -->
  <link name="trunk">
    <inertial>
      <origin xyz="0.02707 0.0 0.0329"/>
      <mass value="71.758"/>
      <inertia ixx="1.61053" ixy="-0.0288" ixz="0.34161" iyy="8.53505" iyz="0.0038" izz="9.19102"/>
    </inertial>
  </link>
</robot>

main.cpp:

#include <iostream>
#include <urdf/model.h>
#include <urdf_parser/urdf_parser.h>

using namespace std;

int main() {
    urdf::ModelInterfaceSharedPtr model = urdf::parseURDFFile("robot.urdf");
    std::vector<boost::shared_ptr<urdf::Link> > links;
    model->getLinks(links);
    std::cout << "Number of links: " << links.size() << std::endl;
    for (int i = 0; i < links.size(); i++) {
        std::cout << "Joint children per link " << i << ": ";
        std::cout << links[i]->child_joints.size() << std::endl;
    }
    return 0;
}

CMakelists.txt:

cmake_minimum_required(VERSION 2.8)

project(urdf-test)

find_package(PkgConfig)
pkg_check_modules(URDF urdf)
add_definitions(${URDF_DEFINITIONS})
include_directories(${URDF_INCLUDE_DIRS})

pkg_check_modules(URDFDOM urdfdom)
include_directories(${URDFDOM_INCLUDE_DIRS})

find_package(Boost REQUIRED COMPONENTS thread chrono system date_time atomic)
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})

add_executable(${PROJECT_NAME} "main.cpp")
target_link_libraries(${PROJECT_NAME} ${Boost_LIBRARIES} ${URDFDOM_LIBRARIES})

output:

Number of links: 2
Joint children per link 0: 18446744073708883089
Joint children per link 1: 18446744073708883069

The expected output is: 1 child for link 0 and 0 children for link 1

ldd output:

	linux-vdso.so.1 =>  (0x00007ffc215e0000)
	liburdfdom_model.so.0.4 => /usr/lib/x86_64-linux-gnu/liburdfdom_model.so.0.4 (0x00007f48f3277000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f48f2ef4000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f48f2cde000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f48f2914000)
	libtinyxml.so.2.6.2 => /usr/lib/x86_64-linux-gnu/libtinyxml.so.2.6.2 (0x00007f48f26fd000)
	libconsole_bridge.so.0.2 => /usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.2 (0x00007f48f24f8000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f48f21ef000)
	/lib64/ld-linux-x86-64.so.2 (0x00005609ee689000)

[sloretz]

Hi @mcamurri, thanks for the ticket.

When you say the library does not give the child joint, do you mean the joint isn't included in child_joints? In the second example, is the joint in child_joints on base_link or trunk?

[mcamurri]

In the second example I'm iterating over all the links. Link 0 is "base_link" and Link 1 is "trunk".
I expected Link 0 to have 1 child (and not 18446744073708883089 children).

Actually, I solved by reinstalling all the libraries.

With current ldd:

	linux-vdso.so.1 =>  (0x00007ffc24df7000)
	liburdfdom_model.so.0.4 => /usr/lib/x86_64-linux-gnu/liburdfdom_model.so.0.4 (0x00007f3fb4bd3000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3fb4850000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3fb463a000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3fb4270000)
	libtinyxml.so.2.6.2 => /usr/lib/x86_64-linux-gnu/libtinyxml.so.2.6.2 (0x00007f3fb4059000)
	libconsole_bridge.so.0.2 => /usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.2 (0x00007f3fb3e54000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3fb3b4b000)
	/lib64/ld-linux-x86-64.so.2 (0x000055ffc5149000)

I have the correct output:

Number of links: 2
Joint children per link 0: 1
Joint children per link 1: 0

[clalancette]

@mcamurri It looks like you solved the problem, so I'm going to close this out. Feel free to reopen if you still are having trouble.