mkoval's profile - activity

I found a few other answers that hint at the solution. This is what I finally came up with that works:

I created a file my_package-extras.cmake.em that exports CMake variables that point to all of the binary files that I plan to use during the build of another Catkin project. This file detects whether we are doing a devel build or an install build---and sets the paths appropriately---by checking whether my_package_SOURCE_DIR is defined.

Finally, I added the option CFG_EXTRAS my_package-extras.cmake to the catkin_package() call. This file will be included in any CMake files that find_package(my_package). Therefore, those CMake files can use the variables defined in that file to depend on (to insure that its built) and call the binaries exported by my_package.

I am trying to using add_custom_target to invoke a binary during the build process. This is tricky because the binary is built by another Catkin package and is installed its libexec directory. I can't figure out how to make this work when both packages are built in the same Catkin workspace. I also am not sure how to call the binary in a way that is portable between the devel and install spaces.

These seem to be two separate issues:

1. How do make my custom target depend on the binary built by the other package? I can't simply add it as a dependency, because that would fail when the other package is in a chained workspace.
2. What is the correct way of resolving the path to the binary? Should I use rosrun, rospack, or catkin_find? Or do I need to somehow export a CMake variable that contains the path?

I would like to enable an input filter in my Doxyfile used when calling rosdoc_lite with the Doxygen backend. There are a few Doxygen customization options listed in the Doxygen builder section of the rosdoc_lite Wiki page, but there doesn't seem to be any way to append arbitrary options to the Doxyfile. Is there any way to get rosdoc_lite to use a custom Doxyfile template?

My immediate goal is to enable the Doxypy input filter for Python files. In the future, I also plan to change some of the formatting options.

Edit: We're building the documentation myself on an internal server, so it is not a hard requirement for our Doxyfile to work on the ROS build farm. One option is to to add a command-line option to rosdoc_lite that can point to a different Doxyfile (rather than the default templates/doxy.template). Alternatively, we can give up on using rosdoc_lite and just invoke Doxygen directly.

I am trying to package some of my robot's stack it's easier to get running on a base installation of ROS-Desktop-Full. In particular, my stack depends on several stacks that aren't installed by default (e.g. prosilica_camera, laser_drivers, etc). These stacks are developed by Willow, so there are debs available (i.e. ros-fuerte-prosilica-camera, ros-fuerte-laser-drivers, etc) and it works fine if I manually install the debs.

I thought rosdep would handle this (i.e. rosdep install my_stack), but it doesn't detect any missing dependencies. Is rosdep the right tool to do this? If not, is there another way of achieving this type dependency resolution?

I recently updated to fuerte and attempted to simulate the same robot model that I was using in Electric. It is defined in URDF and is loaded using spawn_model. Even though this model works fine in the fuerte version of RViz, it is completely broken in the new version of Gazebo (i.e. all of the collision and visual geometries are in the wrong places).

I haven't been able to diagnose the issue, but I have found a minimal example that breaks. Load the following model into Gazebo and view collision geometry. Even though I didn't modify any of the origins in the URDF, there is a huge offset between the two models. This becomes even buggier if you add non-zero <origin/>s inside the collision and geometry nodes.

I am able to simulate the PR2 fine, e.g. pr2_wg_world.world in the pr2_gazebo package, so I am not sure what I am doing wrong.

Skeleton URDF Example

<?xml version="1.0"?>
<robot xmlns:xacro="http://ros.org/wiki/xacro" name="test">
    <xacro:property name="robot_weight" value="90.0"/>

    <link name="base_link">
        <inertial>
            <mass value="${robot_weight}"/>
            <inertia ixx="1.000" ixy="0.000"  ixz="0.000"
                                 iyy="28.500" iyz="0.000"
                                              izz="34.800"/>
        </inertial>
        <collision>
            <geometry>
                <box size="0.83 0.60 0.25"/>
            </geometry>
        </collision>
        <visual>
            <geometry>
                <box size="0.83 0.60 0.25"/>
            </geometry>
        </visual>
    </link>
</robot>

Screenshot of the Problem in Gazebo (debs)

Screenshot of the Problem in Gazebo (svn)

Edits:

• Edit 1: Nothing changes if I add <origin xyz="0 0 0" rpy="0 0 0"/> to the <geometry/> elements.
• Edit 2: This may only be a problem in how Gazebo 1.0 renders the collision model. It's behaving as if the collision model is correct, even though it's rendering in the wrong position.
• Edit 3: It's broken in a different way using the SVN version of Gazebo. See above. The output of urdf2model appears to be correct, so I think it's a bug in Gazebo.
• Edit 4: I fixed the issues with the collision model by modifying how I called spawn_model. It is only buggy if I pass a non-zero offset (e.g. -z 0.5).

I've written quite a few nodes for a custom robot that I've been working on. Several of these nodes are general purpose hardware drivers that would be useful to the larger ROS community. I have been using Git for version control and have a separate repository for each package for several reasons (e.g. to keep separate commit histories, to have more granular control of push access).

This leaves me confused as for how to get these packages listed with Wiki pages on ROS.org. Most of the documentation assumes that each person or organization uses one large repository (e.g. "umd-ros-pkg"). One option I was considering was to make an overarching GIt repository that contains the other packages as submodules. What is the preferred method of dealing with this situation?

I've recently acquired a PNI Fieldforce TCM-XB and would like to interface it with ROS. It communicates over serial using a binary protocol described in their datasheet. The protocol appears to be proprietary, but I am not familiar enough with the protocols used by other manufacturers to know for sure.

Basic searches in the ROS package database haven't turned up any existing packages. Before I take the time to write one, has anyone else written a ROS node for communicating with this compass?

Update: It's not completely polished, but here is the fieldforce_tcm node that I wrote. It is written in Python and publishes a nav_msgs/Imu message with the orientation field populated.

I am using a stereo camera for both stereo reconstruction and monocular image processing. Since I am not calibrating the pair of cameras twice, I am doing all of the monocular processing using the stereo calibration parameters. For the camera intrinsics, this works fine. I am not sure how to handle the extrinsics.

I would like to have the left and right cameras in different TF frames that correspond to their positions on my robot (e.g. /stereo_left_link and /stereo_right_link). Since the stereo baseline is encoded in the stereo calibration parameters, I am not sure stereo_image_proc will deal with the two images being in different TF frames.

What is the correct way to set the CameraInfo and Image message frame_ids to safely proceed to avoid being affected by the potential inconsistencies?

The individual calibrations are correct, but the calibration_tf_publisher saves all of the transforms relative to the /world frame (e.g. /world -> cam1 and /world -> /cam2 instead of /cam1 -> /cam2). The resulting TF tree is incorrect because /world is different for each pairwise calibration [1].

Is there any way I can save the transformation between the cameras without including the /world parent frame?

If I was calibrating three cameras (cam1 through cam3), I would calibrate cam1-cam2 and cam2-cam3 separately. Currently, the calibration_tf_publisher would save the following transforms:

• /world-/cam1 (calibration 1)
• /world-/cam2 (calibration 1)
• /world-/cam2 (calibration 2)
• /world-/cam3 (calibration 2)

Because the world frame is arbitrary and differs between the two calibrations, there are two conflicting transforms from /world to /cam2. I would prefer that calibration_tf_publisher directly publish the transformation between the cameras (with no /world intermediate):

• /cam1-/cam2 (calibration 1)
• /cam2-/cam3 (calibration 2)

I don't think this would cause any problems with multiple-camera calibration, either: all of the transforms could be published as children of the first camera.

I have been using rosbag play to test some CPU-intensive computer vision algorithms on recorded data. Periodically during playback the command-line interface to rosbag play becomes completely unresponsive: the timer stops counting and it is no longer responsive to keyboard controls. Messages are still being published while it is unresponsive (verified with rostopic hz and image_view). If I play the same data back without the CPU-intensive nodes running, everything is fine.

Stepping through the data is important for evaluating my nodes, so this has been very frustrating. Has anyone found a workaround for this problem?

I have recently converted a few of my nodes to nodelets to take advantage of zero-copy message passing. Even though I have converted all of the standard ROS logging macros (e.g. ROS_ERROR()) to the nodelet-aware equivalents (e.g. NODELET_ERROR()), I get the following warning printed to my terminal:

Warning: recursive print statement has occurred. Throwing out recursive print.

After this message prints it appears that the logging macros cease to function. Has anyone else encountered this message when using nodelets? How can I fix it?

I am simulating several cameras in Gazebo using the gazebo_ros_camera plugin in the gazebo_plugins package. All of the cameras are defined in the robot's URDF and the corresponding coordinate frames are published by the joint_state_publisher and robot_state_publisher nodes.

When I view frames captured from the simulated cameras, it is clear that they are pointing in roughly the correct direction. If I view the simulated world in RViz, the visualized world renders correctly for horizontal cameras (left), but not for cameras with a non-zero pitch (right):

It appears that the images captured in Gazebo have approximately twice the pitch that is specified in the URDF (note how the ground plane projected by RViz is too high in the right image). Has anyone else run into a similar problem?

@William Thanks! I'll send you a pull request if I figure out a better way of handling this use-case.

I am trying to build a package in a private Bloom repository with ROSDISTRO_INDEX_URL pointing to a custom index.yaml file. This works up until Bloom invokes rosdep to resolve my package's dependencies.

I tried following the answer to a similar question from 2012:

sudo rm /etc/ros/rosdep/sources.list.d/20-default.list
sudo rosdep init
rosdep update

This did not change anything. I repeated the above with the latest versions of rosdep and Bloom in the Ubuntu APT repository (python-rosdep and python-bloom) and pip (rosdep and bloom) and got the same result.

Interestingly, it looks like the "hydro" line added in 09e4ae3ff3e8e81408127582c4b260718c679f6 was recently removed in 5e4a02a408361241a7158361ea2b228b08c0c671. This comment was added in its place:

# newer distributions (Groovy, Hydro, ...) must not be listed anymore, they are being fetched from the rosdistro index.yaml instead

Unfortunately, this does not seem to be the case. I can't rosdep resolve any of the standard Hydro packages:

$ rosdep resolve message_generation
ERROR: no rosdep rule for 'message_generation'

This happens even if I am in a shell that freshly sourced /opt/ros/hydro/setup.bash; i.e. ROSDISTRO_INDEX_URL is not set.

Any suggestions?

Edit 1: Running rosdep update fixes the issue when running with the default ROSDISTRO_INDEX_URL.

Edit 2: To outline our use-case in a bit more detail:

We use ROS extensively across two robots---one robotic arm and one dual-arm mobile manipulator---and have accumulated a large collection of internal ROS packages. Most of our packages are open-source, but we have some hard constraints that prevent us from open-sourcing everything (e.g. includes on commercial/proprietary software, sponsor has IP restrictions, software associated with papers that are under peer review, etc).

We've been building Debians of our dry Fuerte packages with a custom Jenkins setup and are finally upgrading to Indigo. Our plan is to switch to Bloom to manage releases and a (potentially heavily modified) version of buildbot-ros as our internal build server.

Edit 3: See our discussion on @tfoote's comment below for the solution we arrived at.

I now see that Bloom generates a patch file in /tmp with an auto-generated filename. Is there any way to control where the patch file is written? Or to query where the file was saved? The best options I can come up with are to either fork Bloom or grep its output for the log message.