jackie's profile - activity

You could check out Jennifer Buehler's URDF to GraspIt package, which was designed to convert URDF files to DH parameters:

https://github.com/JenniferBuehler/jb...

She's currently working on releasing it as a debian package.

Can you be more specific than "it doesn't work"? e.g. what instructions did you put into the terminal and what error messages do you get?

Did you include genmsg in your package.xml as a build_depend?

this appears to be redundant with http://answers.ros.org/question/22845... ; can you close this one (or whichever one you think has the better name)?

I don't think that your subscriptions callbacks are guaranteed to overlap. How did you choose 25,000 lines, and have you timed the callback to see if it actually takes longer than 0.5 seconds?

I would try rewriting your subscription callback as such:

void myCallback(const std_msgs::String& str)
{
  count++;
  ros::Duration d(0.6);
  printf("\nSubscriber %i is going to sleep\n", count);
  d.sleep();
 printf("\nSubscriber %i is waking up\n", count);
}

This way you know that the subscription callbacks are slower than your publish calls. You should then expect to see the subscription process print something like:

Subscriber 0 is going to sleep
Subscriber 1 is going to sleep
Subscriber 0 is waking up

etc...

It's true, the documentation contradicts itself for most data types. If data_offset is in bytes, then the indexing scheme described in B only applies to byte arrays.

If data_offset truly were in bytes, then it would take more complicated bitwise arithmetic to index into the array, particularly if offset were unaligned. The comment on line A should probably be changed to something like "Number of padding entries at front of data".

Of course, before changing the documentation, it might be good to understand how downstream packages are using MultiArrayLayout and if they consider data_offset to count bytes or words, but again I suspect that few users of std_msgs are doing the proper bitshifting necessary to accomodate byte padding for 32 or 64-bit int types.

Can you ticket this issue on https://github.com/ros/std_msgs? Thanks.

The ROS_ROOT environment variable will only be defined if the ROS setup.bash (e.g. /opt/ros/<distro>/setup.bash) has been sourced in the environment from which CMake was called. So for this solution you need guarantee that, if there is a ROS install, the ROS setup.bash was sourced before calling cmake.

Alternatively, if you know ROS was installed from a debian package and not from source, you can check if the folder /opt/ros/<distro> exists. However this solution is not entirely portable.

Thanks for listening!

We are preparing a post for a summary of the meeting, a link to the recording, and the notes (which will include links) to ROS Users and the ROS blog ( http://www.ros.org/news/ ).

In the meantime, here is the link to the notes taken during the meeting:

https://docs.google.com/document/d/1r...

Did you create a rigid body to publish and edited the mocap.yaml?

Can you get a gdb backtrace of that segfault and post it as an issue on the Github repo for the package ( https://github.com/ros-drivers/mocap_... ), to help the maintainers?

Follow the directions to configure Motive on your Windows system via the GUI on the Wiki page: http://wiki.ros.org/mocap_optitrack

The Chrono/Gazebo project that you linked is probably your best bet, combined with gazebo_ros_pkgs. Asher (author of that repo) is a grad student at the lab at University of Wisconsin Madison that founded Chrono. I haven't heard of other efforts that bridge Chrono and ROS without Gazebo.

And yes, you might want to invest in a supercomputer if you are planning on doing navigation and motion planning while running Chrono with a real-time factor of 1 :)

In a catkin workspace, you need to source the devel/setup.bash in order to configure your PATH and your ROS environment to find the files that you built in the workspace. See page 14 of the book, or the catkin tutorials http://wiki.ros.org/catkin/Tutorials/...

Make sure you've cloned and the nasa_r2_simulator and nasa_r2_common (instructions are page 172 in the copy I have) into your catkin workspace (i.e. run the "git clone" commands in chessbot/src). You should also make sure that you've sourced the devel/setup.bash file before you try run the r2_mime.py script.

r2_description is in the nasa_r2_common repository. Therefore you need to get the repository, build it into your catkin workspace, and source the setup.bash for that workspace before you can run code that uses it.

If you have more problems, please describe the state of your workspace and the commands that you've typed in and report the issue on https://github.com/osrf/rosbook/issues

make sure the robot is on and that baxter.sh is sourced in every terminal in which you put baxter-specific commands. If you have more problems you should really email the brr-users list: brr-users@rethinkrobotics.com

Did you source your baxter.sh file before trying to get the rosparam? The baxter.sh file configures your shell to talk to the ROS Master running on the Baxter robot. If the software_version parameter was set in the Parameter Server running on the Baxter's ROS Master, then you won't be able to access if it if you aren't connected.

You can also try emailing the brr-users list for Baxter-specific questions, or searching their Google Groups page:

https://groups.google.com/a/rethinkro...

Can you reconfigure your device to be in little-endian mode? MIPS is a bi-endian instruction set, so you should theoretically be able to switch it to little-endian mode...

From http://wiki.ros.org/rosserial_client

Note: The serialization and deserialization code generated by the make_libraries module assumes that the client is a little-endian machine. If you have a bi-endian target such as ARM or MIPS, be sure that it has been placed in little-endian mode in order to use it with rosserial.

I don't have a MIPS device with me to test this, sorry. Good luck!

I ran into the same problem installing ros-indigo-moveit-python and ros-indigo-moveit-commander from debians on 14.04.

The problem is that the version of libassimp3 that these packages depend on (via their dependency on python-pyassimp) is not provided by the package manager on Trusty.

To fix this manually, download libassimp3_3.0~dfsg-3_amd64.deb from here: https://launchpad.net/ubuntu/+source/...

then install it using sudo dpkg -i. You should then be able to install ros-indigo-moveit-full and/or the packages included in the metapackage that depend on libassimp3.