timm's profile - activity

This is a duplicate of the following question, and has already been answered:
RGBDSLAM V2 catkin_make error

Please use the search function next time before posting a new question. Also, it can be helpful to add a short description of your problem at the beginning of your question. Thanks!

Edit: I saw you posted this question again. Next time, please use the edit function if you have additional information to add...

The easiest way to dynamically spawn a model from your code is to call the spawn_model ROS service offered by gazebo_ros, which essentially is the same what the spawn_model node does internally. I.e. instead of running the spawn_model node, you call the spawn_model service.

You can see here how the corresponding service interface is defined. Use rosservice list to find the correct name of the service instance while you have your Gazebo instance running.

Tutorials for writing a service client (which is very easy and similar to writing a ROS publisher) can be found here:
C++ service client tutorial
Python service client tutorial

The linker error message is pretty clear: It tells that the function which you are calling in feedbackLoop(), Tool::getPose(...), is declared in a header file, but its implementation is not defined.

In tool.cpp you have a typo: It says Toll::getPose instead of Tool::getPose. I wonder why you are getting a linker error, though, as this should already cause an error during compilation because a Tollclass it not declared anywhere. In your CMakeLists.txt, did you forget to add tool.cpp as a source file in the add_executable() / add_library() call?

I believe this would only work under the following circumstances (I did it once under Ubuntu 12.04 / Hydro):

• The machine you are building on uses exactly the same operating system version, and has exactly the same set of libraries (+versions) installed, including the ROS version
• Both machines use the same architecture (e.g. x86 or x64)

In those cases, you could just copy the binaries. However, in general I would recommend highly against it, and instead fix the original issue. Why can't you compile C++ code on that machine? Which error messages do you get?

Here are some suggestions:

• Are you sure your messages are published with the correct timestamps, with regard to ros::Time::now()?
• Use rostopic echo --offset TOPIC_NAME/header/stamp to examine by how much your messages are delayed w.r.t. ROS time. The delay is the sum of communication / serialization overhead + the processing time of your nodes. Note that the stamp of a header consists of seconds and nanoseconds, e.g. 0 seconds and 500000000 nanoseconds means your time offset is 0.5 sec
• At which frame rate are you publishing the data? Does the delay disappear if you reduce the publishing rate? In this case, maybe your computations are just too computationally complex? Disparity calculations, without GPU acceleration, can be quite slow depending on which stereo matching algorithm you are using, I believe some only achieve 10-15 FPS on common hardware...
• Are you using any message_filters::Synchronizer in your code? If yes, try increasing the queue size of the message_filters::Subscriber that serve as an input
• Are you using any tf::TransformListener and waitForTransform() somewhere which might cause delays if the transforms are delayed? In that case, diagnose transform delays using rosrun tf tf_monitor
• The number of nodes, or length of a processing chain, is usually not a problem in practice. However, message serialization can incur overheads, especially for large data such as images. Use multiple nodelets within a common nodelet manager, instead of separate nodes, to eliminate overhead caused by ROS message serialization (this is what e.g. the rgbd_launch package does). As nodelets are a bit more difficult to debug, I would recommend this only if you are sure that serialization is the most probable cause of your issues.

Can you try to search for Boost in a separate find_package() call?

According to CMake documentation, the syntax is

find_package(<package> [version] [EXACT] [QUIET] [MODULE]
         [REQUIRED] [[COMPONENTS] [components...]]
         [OPTIONAL_COMPONENTS components...]
         [NO_POLICY_SCOPE])

Since Boost is a separate package, and not a component of the catkin package, I believe you should search for it separately:

find_package(
  catkin
  REQUIRED COMPONENTS roscpp rospy std_msgs
)

find_package(
  Boost
  REQUIRED COMPONENTS algorithm
)

https://github.com/spencer-project/sp...

This Github repository contains people and group detection and tracking components developed during the EU FP7 project SPENCER for 2D laser, camera and RGB-D data. As the project is still going on, new detection and tracking modules and documentation will still be added during the next 12 months.

Our laser detector (reimplementation of the boosted classifier using laser segment features from Arras et al., ICRA'07) is trained on data from an LMS 200 and LMS 500 at around 70 cm height above ground, and it works at ranges up to 15-20 meters, though precision drops at larger distances.

In general, detection results are of course much better when visual data is available (esp. in complex environments). We have also integrated the upper-body RGB-D detector and groundHOG detectors by RWTH Aachen by Jafari et al. mentioned in the original question, as well as the RGB-D people detector from PCL.

All components are tested on ROS Hydro and Indigo. There is also a set of reusable RViz plugins for visualizing the outputs of the perception pipeline.

Is RViz showing any error messages in the Marker display status? Have you set your fixed frame in RViz to "/my_frame"? Maybe also try to play around with the marker.mesh_use_embedded_materials flag, and if possible, try a DAE file instead of STL.

Is the TF broadcaster "/base_to_laser_broadcaster" the same in both cases? Is it a tf static_transform_publisher or a node you wrote yourself? Can you try to increase the publish rate for /base_to_laser_broadcaster?

The rosbag play application itself is implemented in C++: play.cpp

The code relevant to publishing messages can be found in the method Player::publish(). The C++ file also contains code for pausing and resuming playback, console output etc., but maybe you can use this code to get a rough idea: player.cpp

I'd expect Python to give slightly worse performance compared to C++ if you plan to play large bagfiles (e.g. containing camera images).

Edit, to answer your question: I believe there is no other way than either

• using the C++ API (should provide best performance)
• using the Python API
• invoking "rosbag play" using a system() command.

I have not yet had the chance to try this out, but using !!str on the command line should enforce the argument to be treated as a string, as described here:

YAML uses "tags" to override types, where the YAML syntax may be ambiguous. Common tags are: !!str, !!int, !!float, !!seq and !!map. Most likely you will just need to know about !!str. YAML tags are difficult because ! has its own meaning in Bash, so you have to use single-quotes.

e.g.

./bin/testnode _rotations:='!!str 270'
./bin/testnode _rotations:='!!str 90 -90 0'

After installing ASUS' USB 3.0 hotfix, have you tried changing the USB interface to bulk endpoints as specified here or here? Quote from the first link:

"To get the device working I used OpenNI Unstable 1.5.4.0 (https://github.com/OpenNI/OpenNI.git) and PrimeSense Sensor Unstable 5.1.2.1 (https://github.com/PrimeSense/Sensor.git)"

"After installing the driver it is necessary to change the "USB interface" that is used to BULK endpoints by uncommenting UsbInterface=2 in GlobalDefaults.ini (/usr/etc/primesense/GlobalDefaults.ini). I've also found it works when the interface is set to 0. The following comment from the file explains the meaning of the parameters: ; USB interface to be used. 0 - FW Default, 1 - ISO endpoints, 2 - BULK endpoints. Default: Arm - 2, other platforms - 1"

I am requesting a string parameter from the parameter server in ROS Groovy like this:

ros::NodeHandle node_ns("~");
std::string rotations;
node_ns.param<std::string>("rotations", rotations, std::string("0"));

When I run my ROS node with the following command line, everything works fine:

./bin/testnode _rotations:='90 -90 0'

i.e. if I check the value of the string "rotations", it is "90 -90 0". However, if I only input a single numeric value as the string's value,

./bin/testnode _rotations:='270'

the supplied value is ignored and "rotations" has its default value of "0". I think this occurs because the single value is treated as an integer instead of a string. Is this a bug? This can have pretty nasty consequences! I was debugging my code for over an hour trying to figure out why my supplied parameter value was being ignored although it had worked perfectly in other cases...