Neil Traft's profile - activity

After calling publish, can I reuse the same message object to send a similar message with some small changes? Basically I'm asking if the message is already serialized by the time the publish function returns. If it's not serialized right away, then there is a chance that I could overwrite some values from the previous message, and so it would not be possible to reuse it.

If I roslaunch something that broadcasts a TF, then launch RViz, I can visualize the TF in RViz. However, if I then restart the launch file, the new TF is not picked up. I need to also restart RViz to get the new TF.

I'm having a hard time debugging my Turtlebot because I don't know what a functioning Turtlebot should look like. Now that I've read the source code for turtlebot_calibration I have some better understanding of what to expect, but I'm still not sure if my bot is mechanically broken.

• Is it normal for Tbot to stop for long periods of time during the calibration routine?
• Is it normal for calibration to take 7-10 minutes, or more?
• What are some examples of reasonable values for gyro_scale_correction and odom_angular_scale_correction (for a gyro_measurement_range of 150)? Is a gyro value of 0.3 completely unreasonable? What about 3.4? Should it be much closer to the default?
• What is a normal error range for odom and IMU? Even on a good run I might see an odom error of >10% and IMU error >40%.
• Is it normal for the bot to drift out of place during calibration? (i.e. it doesn't turn in place perfectly, but drifts a few centimeters over the course of the routine; one wheel must be spinning faster than the other, I guess)
• Also, what kind of error is acceptable overall (from the EKF's odom_combined) to be able to run gmapping? If I rotate 360° while watching the output of rosrun tf_echo odom base_footprint, should the yaw delta be within 1-2°? Or can I accept errors of more like 10-20° and still be able to run SLAM?

Here's a video showing my bot doing calibration (I know it over-turns right now so the numbers aren't correct, I just want to show you how it stops for long periods of time making weird noises, e.g. t=0:50): https://www.youtube.com/watch?v=8X8Sm...

I appreciate any clues you can give, even if you can't answer all of the questions above. We can collaboratively put together an answer here.

Edit: Seriously? No one is going to even give me a hint of whether they think my video looks normal or not??

The message is of type nav_msgs/Odometry so it should look like any ROS callback, except replace the message pointer type with nav_msgs::Odometry::ConstPtr. The URDF syntax worked for me in Hydro/Gazebo 1.9, but you might need to also comment out this line that begins: <interface:position...

I don't know if this is old syntax or what, but to get this to work I had to use this syntax: <plugin name="p3d_base_controller" filename="libgazebo_ros_p3d.so"> instead of <controller:gazebo_ros_p3d...

I'm not familiar with any of these, but I just stumbled on a number of generic controllers that might suit your purpose.

I've been trying to figure out the same thing (I'm trying to simulate a holonomic point robot). The Planar Move Plugin looks promising. Did you ever find a good solution?

Of which question is this a duplicate?

Try this example. If you only want to see the planes/non-planes there is a way to copy just those points into a new point cloud but I forget how. Some other PCL tutorial might show it.

It's still added to all those other paths, as shown above, but it's just missing from the package path. Not sure if that's fine or if it will cause errors at some point.

Yeah, doing that with any random catkin package will correctly overlay that package, but only that package is added to the package path and ompl is still missing: ROS_PACKAGE_PATH=/home/ntraft/Development/ompl-ws/src/catkin:/opt/ros/hydro/share:/opt/ros/hydro/stacks.

By "clone a copy of catkin into the workspace" did you mean just git clone git@github.com:ros/catkin.git and re-run catkin_make_isolated?

Edit: I think the final answer to this question was basically, "This is expected. Don't worry about it."

I want to overlay the ompl package, which is a cmake-only build: <buildtool_depend>cmake</buildtool_depend> . I follow the steps according to the workspace overlaying tutorial:

$ mkdir -p ~/ompl-ws/src && cd ~/ompl-ws/src
$ catkin_init_workspace
$ git clone git@github.com:ros-gbp/ompl-release.git ompl
$ cd ..
$ catkin_make_isolated  # "isolated" is needed for cmake-only builds.
$ source devel_isolated/setup.zsh  # I use zsh.
$ rospack find ompl
/opt/ros/hydro/share/ompl

At this point, I would expect rospack find ompl to return ~/ompl-ws/src/ompl, but it does not. That's because the ROS_PACKAGE_PATH hasn't been updated. In fact, here's the setup file (devel_isolated/ompl/setup.sh):

#!/usr/bin/env sh
# generated from catkin.builder module

# remember type of shell if not already set
if [ -z "$CATKIN_SHELL" ]; then
  CATKIN_SHELL=sh
fi
# detect if running on Darwin platform
_UNAME=`uname -s`
IS_DARWIN=0
if [ "$_UNAME" = "Darwin" ]; then
  IS_DARWIN=1
fi

# Prepend to the environment
export CMAKE_PREFIX_PATH="/home/ntraft/Development/ompl-ws/devel_isolated/ompl:$CMAKE_PREFIX_PATH"
if [ $IS_DARWIN -eq 0 ]; then
  export LD_LIBRARY_PATH="/home/ntraft/Development/ompl-ws/devel_isolated/ompl/lib:$LD_LIBRARY_PATH"
else
  export DYLD_LIBRARY_PATH="/home/ntraft/Development/ompl-ws/devel_isolated/ompl/lib:$DYLD_LIBRARY_PATH"
fi
export PATH="/home/ntraft/Development/ompl-ws/devel_isolated/ompl/bin:$PATH"
export PKG_CONFIG_PATH="/home/ntraft/Development/ompl-ws/devel_isolated/ompl/lib/pkgconfig:$PKG_CONFIG_PATH"
export PYTHONPATH="/home/ntraft/Development/ompl-ws/devel_isolated/ompl/lib/python2.7/dist-packages:$PYTHONPATH"

This is very different from the normal setup file! Even when I put a normal setup file in there, it still doesn't work, because it's not a catkin build (it doesn't have a .catkin file, which is what _setup_util.py looks for). If I use workspace chaining to build something else that depends on ompl, it does use the overlayed version, but it makes me nervous because it doesn't say it's using the overlaid version, and rospack find still points to the system version:

# It says:
-- This workspace overlays: /opt/ros/hydro
# It SHOULD say:
-- This workspace overlays: /home/<user>/ompl-ws/devel_isolated;/opt/ros/hydro

Is this normal?? What's the correct way to overlay a cmake-only package?

Well, what I meant was, if I decide to also use MoveIt in my program then could there be conflicts? Or maybe not, because I'd be using the MoveIt from /opt/ros/hydro which is already linked to /opt/ros/hydro/ompl and that would not change?

ROS Hydro comes with OMPL 0.13.0. I want to use OMPL 1.0.0. For this project, I'm using OMPL on its own; I'm not trying to change the one used by MoveIt, only the one used by my program. How do I set it up such that the line:

find_package(OMPL REQUIRED)

in my CMakeLists.txt will find the version of OMPL at /usr/local and not the one at /opt/ros/hydro?

As suggested by /opt/ros/hydro/share/ompl/ompl-config.cmake, I tried:

$ catkin_make -DOMPL_PREFIX="/usr/local"

But that didn't seem to work at all. I even output a message to ensure the variable was set:

-- +++ processing catkin package: 'sgpp'
-- ==> add_subdirectory(sampled-gradient-path-planning/sgpp)
CMake Warning at sampled-gradient-path-planning/sgpp/CMakeLists.txt:6 (message):
  OMPL prefix is: /usr/local


-- Using these message generators: gencpp;genlisp;genpy
-- Found MATLAB: /usr/local/MATLAB/R2014a/bin/matlab 
-- Found OMPL: /opt/ros/hydro/lib/libompl.so 
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ntraft/Development/catkin_ws/build

Notice the line Found OMPL: /opt/ros/hydro/lib/libompl.so

Edit: Hmm, should I instead be looking into how to build the ompl ROS package and use workspace overlaying?? But then that would change the version of OMPL for the whole system, rather than just my program... right?

Did you ever solve your rqt_bag error? I have the same problem.

You're right that the new ROS support is extensive, and while my preference is for C++, it is probably possible to port the entire thing to Matlab. I don't have R2015a though, and ROS support is a bit more limited in previous versions. But it's still an option to consider.

Thanks for your help. I decided the best thing for my situation would be to completely separate the Matlab nodes from the C++ nodes so that I don't need to use the Matlab C/C++ APIs. It limits the ways I can structure the program, but of course it's less limiting than a program that doesn't compile.

Thanks to whoever converted my comment to an answer, I guess, but it really isn't a good answer to the question, and was intended as a comment.

Quoting REP 119 — Specification for TurtleBot Compatible Platforms:

Odometry is expected to be accurate within 1% after calibration in both linear and angular movement.

So dead reckoning should be very good indeed. This doesn't answer all the questions posed, but it does give a target to shoot for. I never tried manually calibrating the gyro so I can't be sure that my Turtlebot actually had a hardware issue, but I do imagine it should have been much better than that, even with a suboptimal calibration.

Nothing to do with ROS.

Indent your code so that it is all treated as a single code block.

What exactly are you hoping for as an answer? Do you know how to write a Python class? Change this C++ class into a Python class and then change all the C++ syntax into Python syntax. They should be almost the same.