ps4321's profile - activity

I have my robot (a small "car") defined in URDF. For the purpose of some fancy visualization, I added the wheels via two continuous joint states to the chassis - one joint is for the wheel rotation, the other for the steering angle. At the moment these joints serve no other purpose than to see the wheels move/steer in rviz. I am publishing the corresponding messages to the /joint_states topic, and when setting rviz's fixed frame to base_link it works quite ok.

However when setting the fixed frame to map, the wheels start lagging behind the car. This is more noticeable the faster the car goes. Even when increasing the publishing rate of the joint states to 100/s, I can see the car chassis driving away from the wheels and the wheels jumping back (maybe a few times per second).

My URDF binds the chassis fixed to the base_link. Then base_link has a joint (steering, type continuous, axis "0 0 1") to a link "axis" which has a joint (turning, type continuous, axis "1 0 0") to the link "wheel".

Obviously I am doing something wrong. So my question: what am I doing wrong / how can I fix the wheel's position to the car and only change the rotation in two axes?

I also believe this is a bug. So far I did not have sufficient time to delve that deep into the ROS code (so many other things to do) but I eventually will have to tackle it, I guess. Or hope that some update miraculously fixes it ;-)

I am trying to integrate an Ibeo Lux LIDAR, but I can not find a ROS package that handles this sensor. Does anybody know whether there is a ready-to-use ROS package available, or anything that is (close to being) compatible?

Did you try Doxygen?

P.S.: This is not related to ROS, so you may have more/better answers at e.g. stackoverflow.

Can you post a screenshot or let us know the names of these two topics? (You are right that boxes are topics and ovals are nodes)

I am running a nodelet manager with quite a few nodelets. When hitting Ctrl+C in the terminal, the nodelets take a long time to quit. This slows down the entire ROS shutdown procedure to a painstakinly slow crawl. This is because they are quitting serially and each nodelet is waiting the full second in https://github.com/ros/bond_core/blob...

I can reproduce this (in a somewhat lesser extent) when creating more than 9 nodelets in a manager, here n-9 nodelets will exhibit that behaviour (n = number of nodelets). I tried increasing the number of threads in the manager but this made no difference.

Launch file using the nodelet_tutorial_math package as an example:

<launch>
    <node pkg="nodelet" type="nodelet" name="nodelet_manager" args="manager" />

    <node pkg="nodelet" type="nodelet" name="n01" args="load nodelet_tutorial_math/Plus nodelet_manager" />
    <node pkg="nodelet" type="nodelet" name="n02" args="load nodelet_tutorial_math/Plus nodelet_manager" />
    <node pkg="nodelet" type="nodelet" name="n03" args="load nodelet_tutorial_math/Plus nodelet_manager" />
    <node pkg="nodelet" type="nodelet" name="n04" args="load nodelet_tutorial_math/Plus nodelet_manager" />
    <node pkg="nodelet" type="nodelet" name="n05" args="load nodelet_tutorial_math/Plus nodelet_manager" />
    <node pkg="nodelet" type="nodelet" name="n06" args="load nodelet_tutorial_math/Plus nodelet_manager" />
    <node pkg="nodelet" type="nodelet" name="n07" args="load nodelet_tutorial_math/Plus nodelet_manager" />
    <node pkg="nodelet" type="nodelet" name="n08" args="load nodelet_tutorial_math/Plus nodelet_manager" />
    <node pkg="nodelet" type="nodelet" name="n09" args="load nodelet_tutorial_math/Plus nodelet_manager" />
    <node pkg="nodelet" type="nodelet" name="n10" args="load nodelet_tutorial_math/Plus nodelet_manager" />
    <node pkg="nodelet" type="nodelet" name="n11" args="load nodelet_tutorial_math/Plus nodelet_manager" />
    <node pkg="nodelet" type="nodelet" name="n12" args="load nodelet_tutorial_math/Plus nodelet_manager" />
</launch>

Running this using roslaunch, waiting a few seconds and hitting Ctrl+C yields the following output:

[n12-14] killing on exit
[n10-12] killing on exit
[n11-13] killing on exit
[n09-11] killing on exit
[n08-10] killing on exit
[n07-9] killing on exit
[n06-8] killing on exit
[n05-7] killing on exit
[n04-6] killing on exit
[n03-5] killing on exit
[DEBUG] [1452286846.010427642]: Bond failed to break on destruction /n12_503ba84e-e519-4aff-b64c-2fc916001415 (dec02ef5-3080-4735-94f9-0f6c2b0ced47)
[n02-4] killing on exit
[DEBUG] [1452286847.013150698]: Bond failed to break on destruction /n10_6fc1725a-5bfa-46ab-81ab-d54a416ea289 (e3ba27a7-fac6-48a1-8baa-ac45fe3e10e5)
[n01-3] killing on exit
[DEBUG] [1452286848.015696163]: Bond failed to break on destruction /n11_7f67080a-7b9f-480a-8318-a89a33ce03be (3907ea9b-f8dd-4617-b7ac-254ab62f42d6)
[nodelet_manager-2] killing on exit
[rosout-1] killing on exit
[master] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done

Notice the timestamps which are 1 second apart. Occassionally I also get

[nodelet_manager-2] killing on exit
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error> >'
  what():  boost: mutex lock failed in pthread_mutex_lock: Invalid argument

at the end.

System is Ubuntu Trusty 14.04 running ROS Indigo (rosversion 1.11.16) fully updated using the latest debian packages from http://packages.ros.org/ros/ubuntu . The same effect can be observed with Jade.

Is this a limitation of nodelets and/or can I do something to not run into this issue and have everything quit faster?

It was actually somehow the other way around - i.e. I had to set ROS_IP (at least for the foreign_relay node) to get it working. Apparently a DNS issue, as there is no DNS entry for the local hostname.

But foreign_relay still communicates bi-directionally (for the subscription). Is there a way to statically define a set of topics to push remotely?

We are running a ROS system remotely. Due to the particular setup, there is a high network latency (esp. towards the remote site) which we can not fix. rviz does not handle this well and using it is basically impossible.

Given this scenario, is there any way to "mirror" the master? I.e. we would like to just send all (or preferably only some) topics from the remote ROS master to the local one (using unreliable transport / UDP), so we can use rviz with the local master. Is this possible?

Dear all,

I have ROS Groovy running on a remote system, but need to have topics available locally as well.

I've looked into multimaster_fkie and foreign_relay. I got foreign_relay working locally (running a ros master on two different ports), however when I did the same setup on two different laptops (connected to the same router / on the same subnet, no firewall) I only could see the topics but not the messages. I have the same issue with multimaster_fkie (which I would not like to use because of the mandatory discovery process, I much prefer foreign_relay's approach to have the remote master specified explicitely).

I saw the other questions on this site, but though the symptoms are precisely the same as answers.ros.org/question/10074/help-troubleshooting-foreign-relay, the fix did not help. I see answers.ros.org/question/12420/foreign_relay-problem has the exact same issue, but no answer. I hope that somebody using foreign_relay successfully could shed some light on this issue.

I want to use a Kinect for Windows (K4W) on ROS groovy. I installed groovy on Ubuntu via the repository at packages.ros.org/ros/ubuntu. However the libfreenect version included does not support the K4W, however the one on github does.

So how do I go about updating libfreenect and the freenect stack?

What I tried so far:

• downloaded the libfreenect source and compiled it successfuly
• copied the libfreenect files to /opt/ros/groovy/lib
• executed sudo rosinstall /opt/ros/groovy freenect.rosinstall which finished without error

However, now sourcing /opt/ros/groovy/setup.bash takes a long time (with one CPU core at 100%) and then the bash exits.

I am trying to cross-compile my ROS project for ARM. I have a full copy of my ARM's root file system (Ubuntu 12.04, with the armhf ROS binaries installed) and have set CMAKE_FIND_ROOT_PATH to it. Calling catkin_make -DCMAKE_TOOLCHAIN_FILE=rostoolchain.cmake now causes my cross compiler to be used.

However, I don't see that include paths are set correctly. I.e. one of my nodes uses a file that requires boost and compiles fine when not using cross-compilation. However when cross-compiling, the make command does not add the include folder of the rootfs, and the boost headers are not found:

arm-linux-gnueabihf-g++   -DROS_BUILD_SHARED_LIBS=1 -DROS_PACKAGE_NAME=\"example\" -I/home/user/my_projects/src/example/include -I/opt/ros/groovy/include    -o CMakeFiles/example.dir/src/example.cpp.o -c /home/user/my_projects/src/example/src/example.cpp

yields

in file included from /opt/ros/groovy/include/ros/ros.h:38:0,
             from /home/user/my_projects/src/example/src/example.cpp:10:
/opt/ros/groovy/include/ros/time.h:58:50: fatal error: boost/math/special_functions/round.hpp: No such file or directory

compilation terminated.

Additionally I notice that it uses the host's ROS installation, not the one from the ARM rootfs (in some aspects this makes sense, and as both are the same it doesn't really matter for now, but I am not sure this is right).

Finally, it also tries to link with the host's libraries:

/opt/ros/groovy/lib/libroscpp.so: file not recognized: File format not recognized
/opt/ros/groovy/lib/libpcl_ros_tf.so: file not recognized: File format not recognized

My question: What do I have to set additionally to cause catkin/cmake to actually cross-compile? I.e. use the headers and libs of the SDK (or the full root-fs in this case) instead of the host's headers and libs?

My toolchain file for reference:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_CROSSCOMPILING True)

set(CMAKE_C_COMPILER /opt/linaro/arm-linux-gnueabihf/bin/gcc)
set(CMAKE_CXX_COMPILER /opt/linaro/arm-linux-gnueabihf/bin/g++)
set(CMAKE_FIND_ROOT_PATH /tmp/ros/rootfs)

# something I tried, doesn't make any difference at all
SET(CMAKE_INCLUDE_PATH /tmp/ros/rootfs/usr/include;/tmp/ros/rootfs/usr/include/boost) 

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Note 1: Compiling on the robot / ARM board is not an option for me. I want to cross-compile.

Note 2: I do not want to add explicit include-folder requirements in the CMake files, as the code is also required to compile on the host.

I have the exact same issue on Groovy. The cross-compilation does not (always?) use the target files, but the host files. Also in some cases it doesn't even add the necessary include path (e.g. for boost).

(contd) And did I mention it is slow? :-) But seriously, cross-compilation is a common method for embedded development, building on the robot is like announcing defeat. I was quite shocked about the state of ARM support for ROS (but thank you, @ahendrix, for your work with the binary deb packages!)