ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Johannes Meyer's profile - activity

2022-08-28 12:00:23 -0500 received badge  Great Question (source)
2019-03-06 15:03:58 -0500 received badge  Favorite Question (source)
2019-01-25 08:44:00 -0500 received badge  Good Answer (source)
2016-12-29 09:58:36 -0500 commented answer Generating metapackage artifacts with catkin_tools?
2016-11-21 22:20:49 -0500 received badge  Favorite Question (source)
2016-09-02 05:27:00 -0500 received badge  Good Question (source)
2016-09-02 05:26:47 -0500 marked best answer Interpretation of IMU data from the gazebo_ros_imu plugin

We want to use the gazebo_ros_imu plugin for the simulation of our quadrotor and other vehicles in Gazebo. When looking at the output and source file of the plugin, several questions arise:

  1. When the platform is standing still, the simulated accelerations are all zero apart from the simulated noise. Shouldn't the gravity vector be added to the accelerations measured due to body motion? A real IMU would give a more or less constant gravity vector in body coordinates. Does this behavior mimic the output of the simulated Microstrain 3DM-GX2 IMU?
  2. Accelerations are calculated by a first-order approximation of the linear velocity. Is there a specific reason why the driver does not use the gazebo::Entity::GetRelativeLinearAccel() or gazebo::Entity::GetWorldLinearAccel() functions?
  3. I am not familiar with the Gazebo interface. The Entity class seems to provide two types of access functions for the body states, one in relative (body) coordinates and one in world coordinates. Wouldn't it be more straight-forward to directly use the body vectors instead of the rotated world vectors? I assume the reason is the rpyOffsets parameter and that the accelerations and angular velocities should match the "wrong" orientation. But in reality the things are other way round, namely that offsets in orientation are a result of offsets in the acceleration measurements.

By the way, in my opinion the term "IMU" is misleading for a device providing the orientation of a platform, as a pure IMU by itself only provides accelerations and angular velocity. The roll and pitch angles can be estimated with this information under the assumption that the velocity vector of the platform is more or less constant over time (which does not necessarily hold for flying vehicles). Heading or yaw always needs additional references like earth magnetic field or others. I think "AHRS" (Attitude and Heading Reference System) would fit better for what an IMU is in ROS.

Thanks in advance for some useful answers!

2016-09-02 05:26:47 -0500 received badge  Nice Answer (source)
2016-04-18 04:02:24 -0500 received badge  Great Question (source)
2016-03-27 06:42:19 -0500 received badge  Good Answer (source)
2014-11-29 17:19:50 -0500 answered a question Hector_quadrotor catkin_make fails compiling

I did a major update of the hector_pose_estimation packages during the last one or two weeks, which I merged into the catkin branch a few minutes ago. hector_quadrotor already had some patches that I accidentally pushed and that require the new version. The state of the repositories was therefore inconsistent for a few days. I am sorry.

If you want, please try again with the updated versions now. You have to build both repos, hector_quadrotor and hector_localization, from source.

It also should be noted here that with the default values of the launch file arguments the simulated quadrotor directly uses ground truth information from Gazebo for control and for the published tf transforms. hector_pose_estimation is only started if the quadrotor is spawned with the use_ground_truth_for_control:=true roslaunch argument.

For the hardware_interface issue: Please make sure that all dependencies are installed before building, e.g. using rosdep or rosinstall_generator. hardware_interface is an indirect dependency of hector_quadrotor_gazebo (and hector_quadrotor_demo):

$ rospack depends-why --target=hardware_interface hector_quadrotor_gazebo
Dependency chains from hector_quadrotor_gazebo to hardware_interface:
* hector_quadrotor_gazebo -> hector_quadrotor_controller_gazebo -> gazebo_ros_control -> controller_manager -> controller_interface -> hardware_interface 
* hector_quadrotor_gazebo -> hector_quadrotor_controller_gazebo -> gazebo_ros_control -> controller_manager -> hardware_interface 
* hector_quadrotor_gazebo -> hector_quadrotor_controller_gazebo -> hector_quadrotor_controller -> hardware_interface 
* hector_quadrotor_gazebo -> hector_quadrotor_controller_gazebo -> hector_quadrotor_controller -> controller_interface -> hardware_interface
2014-11-04 16:36:55 -0500 commented answer multiple hector_quadrotor flying simultaneously

hector_quadrotor should definitely support this. There is a spawn_two_quadrotors.launch example in the hector_quadrotor_gazebo package, but I have not used it recently. Other nodes controlling the quadrotors have to be run in the respective namespace.

2014-10-17 07:50:30 -0500 received badge  Nice Answer (source)
2014-07-13 12:31:08 -0500 answered a question Uncontrollable quadrotor_with_asus in Gazebo - hector_quadrotor

I could reproduce the problem. It is caused by the additional mass and moment of the ASUS camera, that was never tested with the new controller implementation. For some reason the Kinect model in our hector_sensors_description package has almost no mass, while the ASUS Xtion has a mass of 200 g.

Proposed solution at Github: https://github.com/tu-darmstadt-ros-p...

2014-07-10 04:44:26 -0500 answered a question Hector Quadrotor Control Question

It seems that you do not have installed the joystick drivers package joy. Try to install it using the command

sudo apt-get install ros-hydro-joy

I added it as a run dependency to hector_quadrotor_teleop to have it automatically installed in future releases of hector_quadrotor (see commit).

The left stick controls vertical velocity and yaw rate, while the right stick controls x and y velocity (mode 2). The joystick/gamepad buttons are currently unused.

2014-07-03 18:21:54 -0500 received badge  Guru (source)
2014-07-03 18:21:53 -0500 received badge  Great Answer (source)
2014-04-29 11:11:39 -0500 received badge  Good Question (source)
2014-04-20 13:44:37 -0500 marked best answer Which is the correct way to install header files in catkin packages?

It is common practice to place header files in a subdirectory of the package's include folder which has the same name as the package. The package exposes theses header files via its catkin_package() macro for dependent packages as it can be found in many catkin examples:

catkin_package(
   INCLUDE_DIRS include
   ...
)
Other packages will include these headers using the `#include <package header.h="">` directive. On the other side, catkin documentation at [ros.org](http://ros.org/wiki/catkin/CMakeLists.txt#Optional_Step:_Specifying_Installable_Targets) proposes the following cmake code to install header files contained in a package: md5-f68e7b950c4dd0a0dcb70833293102ff With this command header files are installed to `${CATKIN_PACKAGE_INCLUDE_DESTINATION}/package/header.h` which resolves to `${CMAKE_INSTALL_PREFIX}/include/package/package/header.h`.
  1. Is there a mechanism in the generated cmake/pkg-config files that add ${CMAKE_INSTALL_PREFIX}/include/package as an include directory if another package depends on my package, so that the #include <package/header.h> directive will continue to work in install space? As far as I can see, this is not the case and all packages installed in /opt/ros/groovy only expose /opt/ros/groovy/include as include directory and not /opt/ros/groovy/include/package.

  2. Should the example at ros.org changed to

    install(DIRECTORY include/${PROJECT_NAME}/
     DESTINATION ${CATKIN_PACKAGE_INCLUDE_DESTINATION}
     FILES_MATCHING PATTERN "*.h" PATTERN "*.hpp"
    )
    

    ? This is also the cmake fragment in the install section of the CMakeLists.txt generated by catkin_create_pkg.

  3. Header files could be installed to CATKIN_GLOBAL_INCLUDE_DESTINATION instead:

    install(DIRECTORY include/
       DESTINATION ${CATKIN_GLOBAL_INCLUDE_DESTINATION}
       FILES_MATCHING PATTERN ".h" PATTERN ".hpp"
    )
    

Which of the three above "solutions" is the correct/preferred way to install header files in catkin packages or did I miss something here?

2014-04-20 13:42:51 -0500 marked best answer Overlaying multiple catkin devel-spaces at the same time

Is it possible to create a rosbuild or catkin workspace, that overlays two or more independent catkin workspaces at the same time? I would like to keep the workspaces of different, independent projects A and B separated, but there may be a third project C which uses packages from A and B. In other words: Can I source two catkin-generated setup.sh scripts one after another, so that rospack and cmake's find_package() architecture will find packages from both workspaces A and B?

Here is a simple example setup with empty workspaces, which hopefully clarifies what I mean:

source /opt/ros/groovy/setup.bash

mkdir /tmp/catkin_overlay_test
cd /tmp/catkin_overlay_test

mkdir -p catkin_workspace_a/src     # create empty workspace A
mkdir -p catkin_workspace_b/src     # create empty workspace B

catkin_make -C catkin_workspace_a       # This will create catkin_workspace_a/devel
catkin_make -C catkin_workspace_b       # This will create catkin_workspace_b/devel

Now I would assume that I can use packages (if there were any) from both workspaces after having sourced both setup scripts or by merging them to a rosbuild workspace:

# Alternative 1: Source both setup scripts
source catkin_workspace_a/devel/setup.bash
source catkin_workspace_b/devel/setup.bash

# Alternative 2: Merge A and B in another rosbuild workspace C
rosws init rosbuild_workspace_c
cd rosbuild_workspace_c
rosws merge ../catkin_workspace_a/devel
rosws merge ../catkin_workspace_b/devel
source setup.bash

Both alternatives lead to the same result, namely that the setup script in workspace B overrides the environment variables set by A and packages in A are not visible:

$ env | grep catkin_overlay_test
ROS_PACKAGE_PATH=/tmp/catkin_overlay_test/catkin_workspace_b/src:/opt/ros/groovy/share:/opt/ros/groovy/stacks
ROS_WORKSPACE=/tmp/catkin_overlay_test/rosbuild_workspace_c
LD_LIBRARY_PATH=/tmp/catkin_overlay_test/catkin_workspace_b/devel/lib:/opt/ros/groovy/lib
CATKIN_TEST_RESULTS_DIR=/tmp/catkin_overlay_test/catkin_workspace_b/build/test_results
CPATH=/tmp/catkin_overlay_test/catkin_workspace_b/devel/include:/opt/ros/groovy/include
ROS_TEST_RESULTS_DIR=/tmp/catkin_overlay_test/catkin_workspace_b/build/test_results
PATH=/tmp/catkin_overlay_test/catkin_workspace_b/devel/bin:/opt/ros/groovy/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
PYTHONPATH=/tmp/catkin_overlay_test/catkin_workspace_b/devel/lib/python2.7/dist-packages:/opt/ros/groovy/lib/python2.7/dist-packages
PKG_CONFIG_PATH=/tmp/catkin_overlay_test/catkin_workspace_b/devel/lib/pkgconfig:/opt/ros/groovy/lib/pkgconfig
CMAKE_PREFIX_PATH=/tmp/catkin_overlay_test/catkin_workspace_b/devel:/opt/ros/groovy

Is this a bug in catkin or is it simply not possible to build upon multiple devel spaces? I did not try, but I assume there is no difference when using the install spaces instead. Does catkin only support a linear hierarchy of "parent workspaces"?

2014-04-20 13:25:40 -0500 marked best answer Which repository URL is displayed in the ROS wiki?

In our tu-darmstadt-ros-pkg SVN repo we used to have a special branch for fuerte in the /branches/fuerte directory. A couple of weeks ago, we moved the fuerte branch back to /trunk and the former /trunk branch to /branches/electric. The tu-darmstadt-ros-pkg.rosinstall file in the rosdistro repository at GitHub and the repository information in the release repo at code.ros.org were updated accordingly.

For some reason the wiki pages on ros.org still show the old URL for fuerte for released stacks and packages, e.g. hector_quadrotor. The last release was done from /branches/fuerte. The Releases page displays the new, correct URL for the development branch in /trunk.

Which information source is used for the meta information of stacks and packages in the ROS wiki? Is there a difference for released and unreleased stacks? How can I force the indexer to update the information?

Edit: roslocate uri also shows the updated URL.

2014-04-20 13:23:04 -0500 marked best answer rosmake with stack name argument

I wonder if it is intended behavior of the rosmake utility to include all packages in dependent stacks (stack A) in the list of packages to be built when invoked with a stack name (stack B) as argument although these packages are not required to build the packages in stack B.

Example:

stack A
  |- package A1
  |- package A2
stack B (depends on stack A)
  |- package B1 (depends on package A1)

Stack B depends on stack A because package B1 depends on A1. Note that package B1 does not depend on A2.

If you run rosmake for package B1 only, packages B1 and A1 will be built, which is what I would expect:

$ rosmake B1
[ rosmake ] rosmake starting...
[ rosmake ] Packages requested are:
['B1']
[ rosmake ] Logging to directory /home/meyer/.ros/rosmake/rosmake_output-20121126-192457
[ rosmake ] Expanded args ['B1'] to:
['B1']                                                             
[rosmake-0] Starting >>> A1 [ make ]
[rosmake-0] Finished <<< A1 [PASS] [ 1.80 seconds ]
[rosmake-0] Starting >>> B1 [ make ]
[rosmake-0] Finished <<< B1 [PASS] [ 1.35 seconds ]
[ rosmake ] Results:
[ rosmake ] Built 2 packages with 0 failures.
[ rosmake ] Summary output to directory
[ rosmake ] /home/meyer/.ros/rosmake/rosmake_output-20121126-192457

But if you run rosmake with the stack B as argument package A2 will also be built:

$ rosmake B
[ rosmake ] rosmake starting...
[ rosmake ] Packages requested are: ['B']
[ rosmake ] Logging to directory /home/meyer/.ros/rosmake/rosmake_output-20121126-192509
[ rosmake ] Expanded args ['B'] to:
['B1']
[rosmake-0] Starting >>> A1 [ make ]
[rosmake-1] Starting >>> A2 [ make ]
[rosmake-0] Finished <<< A1 [PASS] [ 1.00 seconds ]
[rosmake-0] Starting >>> B1 [ make ]
[rosmake-1] Finished <<< A2 [PASS] [ 1.57 seconds ]
[rosmake-0] Finished <<< B1 [PASS] [ 1.01 seconds ]
[ rosmake ] Results:
[ rosmake ] Built 3 packages with 0 failures.
[ rosmake ] Summary output to directory
[ rosmake ] /home/meyer/.ros/rosmake/rosmake_output-20121126-192509

If stack B does not declare the dependency to stack A in its stack.xml, package A2 will not be built.

The example has been tested with the current ros-fuerte-ros release (1.16.1.2ubuntu7).