ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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? Reported here: https://github.com/catkin/catkin_tool... |
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:
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 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): |
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 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:
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`.
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: 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: 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: 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: |
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 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: But if you run rosmake with the stack B as argument package A2 will also be built: 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). |