ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
2019-10-28 01:18:53 -0500 | received badge | ● Famous Question (source) |
2019-07-22 14:07:47 -0500 | received badge | ● Notable Question (source) |
2019-07-09 09:11:26 -0500 | marked best answer | robot_localization not producing data while fusing Odometry I have a robot_localization node, and for testing purposes I want to fuse in a very accurate GPS receiver as if it was a normal smooth odometry sensor (e.g. wheel encoders). I have a nav_msgs/Odometry topic producing an ENU-formatted UTM position, as well as a sensor_msgs/Imu topic filled with FLU-formatted rates and accelerations. However, I get the following error, and robot_localization doesn't seem to produce data:
This doesn't make sense, because I'm running this node specifically to produce this transform! EDIT: I've found the lines in robot_localization that are the culprit, but I'm not sure how to proceed. In ros_filter.cpp: if (poseCallbackData.updateSum_ > 0) { // Grab the pose portion of the message and pass it to the poseCallback geometry_msgs::PoseWithCovarianceStamped *posPtr = new geometry_msgs::PoseWithCovarianceStamped(); posPtr->header = msg->header; posPtr->pose = msg->pose; // Entire pose object, also copies covariance geometry_msgs::PoseWithCovarianceStampedConstPtr pptr(posPtr); poseCallback(pptr, poseCallbackData, worldFrameId_, false); } For Odometry messages, it's taking the Pose part and attempting to transform it all the way to the "world" frame (which is odom). END EDIT EDIT #2: Switching on the "_differential" flag works because it integrates the pose as a twist instead. However, then my covariances grow with time, which I don't want (they should remain bounded, as the covariances of the poses are bounded). END EDIT #2 Here's my configuration: frequency: 50 sensor_timeout: 0.1 transform_time_offset: 0.1 transform_timeout: 0 odom_frame: odom base_link_frame: base_link world_frame: odom two_d_mode: false imu0: /sensor/imu/data_enu imu0_config: [false, false, false, false, false, false, false, false, false, true, true, true, false, false, false ] imu0_differential: false imu0_relative: false imu0_queue_size: 10 imu0_remove_gravitational_acceleration: false odom0: /sensor/gps/utm_enu odom0_config: [true, true, true, true, true, true, false, false, false, false, false, false, false, false, false] odom0_differential: false odom0_relative: true odom0_queue_size: 10 publish_tf: true publish_acceleration: true print_diagnostics: true debug: false debug_out_file: /mnt/ramdisk/relative_localization_filter_debug.txt use_control: false alpha: 0.001 kappa: 0 beta: 2 Here's an example output of each message: --- header: seq: 77976 stamp: secs: 1560451949 nsecs: 823664380 frame_id: "imu_link_enu" orientation: x: -0.00890241184106 y: -0.0122976751383 z: 0.941373781502 w: -0.337023616012 orientation_covariance: [2.4716113409053997e-07, 0.0, 0.0, 0.0, 2.466269938791087e-07, 0.0, 0.0, 0.0, 7.467046920414323e-08] angular_velocity: x: -0.00106572255027 y: 0.00128244573716 z: -7.25421487004e-05 angular_velocity_covariance: [-1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0] linear_acceleration: x: 0.0310777239501 y: 0.000748675898649 z: -0.0431123189628 linear_acceleration_covariance: [-1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0] --- --- header: seq: 79161 stamp: secs: 1560451990 nsecs: 483678060 frame_id: "gps_enu" child_frame_id: "imu_link_flu" pose: pose: position: x: 308876.393439 y: 4310470.5311 z: -77.3288650513 orientation: x: -0.00886148846847 y: -0.0123107011776 z: 0.941312561823 w: -0.337195168431 covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0 ...(more) |
2019-07-09 09:08:54 -0500 | commented answer | How to correctly conform to REP-145 I edited my question above as well, but I think this answer makes sense and matches with my current understanding. Thank |
2019-07-09 09:07:48 -0500 | marked best answer | How to correctly conform to REP-145 Edit later down to try and clarify the question. I'm writing a driver for a GNSS/INS solution. The data it provides is:
There are two pieces of data I need to produce, per REP-145:
However, unlike nav_msgs/Odometry, sensor_msgs/Imu doesn't have a separate frame_id for Twist information vs Pose information. Thus, REP-145 tells us to produce orientation in ENU if that's what the sensor provides, but also to duplicate the accelerations and rotational rates from the data_raw topic. So, my question is:
Or, should I fill the angular_velocity and linear_acceleration portions with front-left-up velocities and accelerations? In that case, which frame should be put into frame_id? Or, should I fill everything (including imu/data_raw) with ENU-transformed accelerations/rotations? Or, should imu/data_raw contain the sensor-specific data (front-right-down formatted), and imu/data contain everything transformed to ENU? And most important, which format will be most accepted by robot_localization? EDIT: I'm updating this question to try and make it more clear for future readers, hopefully. We have the FLU fixed frame to the IMU, in which the data_raw (acceleration and angular rates) is published, which should have a frame_id of "imu_link" or whatever you'd like that is centered on the inertial unit with X pointing forward, Y pointing left, and Z pointing up. The accelerations and angular rates are measured w.r.t. this vehicle-fixed origin (standard REP-103, REP-105, and REP-145 stuff). We then have an orientation which is measured in the globally fixed frame of UTM (standard on dual-antenna INS, moving-baseline differential GNSS, or INS that can gyrocompass or fuse course-over-ground heading). There is some frame_id associated with this orientation, centered somewhere on the equator. Assume that the data (which is almost always in the X=north, Y=east, Z=down convention) has been transformed to conform to REP-105 (X=east, Y=north, Z=up). I should add that this is NOT just a UTM-heading issue: if this orientation is coming out of the sensor initialized to some arbitrary identity (e.g. the Redshift UM7 IMUs) you have the same issue. Since sensor_msgs/Imu doesn't contain 2 frame_id's, thus cannot resolve the orientation's transform origin, I assume that' * we fill the frame_id with "imu_link" i.e. FLU, vehicle-fixed * we assign whatever orientation we want into the orientation field, assuming it conforms to REP-105 (so an ENU or FLU orientation, with some origin either arbitrary (e.g. identity on startup) or globally fixed (e.g. UTM) * If we fuse into robot_localization as an orientation, I assume (???) that robot_localization ... (more) |
2019-07-09 09:07:48 -0500 | received badge | ● Scholar (source) |
2019-07-09 09:07:46 -0500 | received badge | ● Supporter (source) |
2019-07-09 09:07:41 -0500 | edited question | How to correctly conform to REP-145 How to correctly conform to REP-145 Edit later down to try and clarify the question. I'm writing a driver for a GNSS/IN |
2019-07-03 08:41:38 -0500 | commented answer | How to correctly conform to REP-145 OK, makes sense for fusing the orientation to base_link using the lever arm, but what about the order of rates and accel |
2019-07-03 08:30:19 -0500 | commented answer | robot_localization not producing data while fusing Odometry Ah, understood. The gps_enu frame should really be the origin of the UTM zone in ENU convention, so then the gps_enu -&g |
2019-06-20 09:27:54 -0500 | received badge | ● Student (source) |
2019-06-20 09:08:41 -0500 | received badge | ● Famous Question (source) |
2019-06-20 07:49:05 -0500 | received badge | ● Popular Question (source) |
2019-06-20 07:48:02 -0500 | received badge | ● Notable Question (source) |
2019-06-20 07:48:02 -0500 | received badge | ● Popular Question (source) |
2019-06-20 07:47:14 -0500 | received badge | ● Famous Question (source) |
2019-06-20 07:47:14 -0500 | received badge | ● Notable Question (source) |
2019-06-14 09:08:48 -0500 | received badge | ● Popular Question (source) |
2019-06-13 14:36:41 -0500 | asked a question | How to correctly conform to REP-145 How to correctly conform to REP-145 I'm writing a driver for a GNSS/INS solution. The data it provides is: An internal |
2019-06-13 14:28:31 -0500 | edited question | robot_localization not producing data while fusing Odometry robot_localization not producing data while fusing Odometry I have a robot_localization node, and for testing purposes I |
2019-06-13 14:19:42 -0500 | edited question | robot_localization not producing data while fusing Odometry robot_localization not producing data while fusing Odometry I have a robot_localization node, and for testing purposes I |
2019-06-13 13:56:03 -0500 | asked a question | robot_localization not producing data while fusing Odometry robot_localization not producing data while fusing Odometry I have a robot_localization node, and for testing purposes I |
2019-05-20 00:59:56 -0500 | marked best answer | 3d robot_localization and bounding Yaw I'm fusing the wheel odom and imu on the Husky, with robot_localization's UKF. What I'm wondering is the following: I don't really want to rely on the magnetometer output for bounding yaw from the IMU, but I also don't want to orient my yaw around my wheel encoder yaw. So, I'd like to just fuse both as angular velocities, and let it slowly drift with gyro bias. However, when I do this (fuse YawRate from odom, YawRate from IMU) the covariance for YawYaw (/odometry/filtered/pose/covariance[35]) grows slowly. After a few hours, it will be very large. Is this a significant issue? I assume the filter will become unstable (I'm using the UKF currently). Thus, do I have to fuse an absolute yaw from somewhere in order to keep the filter stable? As a side note, the covariance for ZZ is also growing (/odometry/filtered/pose/covariance[14]), but I don't think that matters as much. |
2019-05-20 00:58:41 -0500 | received badge | ● Famous Question (source) |
2019-03-25 07:34:35 -0500 | received badge | ● Enthusiast |
2019-03-19 02:42:35 -0500 | marked best answer | rviz does not know of custom panel TL;DR I cannot get my custom rviz panel to show up in rviz. EDIT: Initial problem was a hosed workspace somehow. New problem is missing symbol in the library. CURRENT PROBLEM (MISSING SYMBOL DEFINITION): When loading the panel (which exists in rviz) I get the following: [ERROR] [1552945665.814417674]: PluginlibFactory: The plugin for class 'myrviz/CustomPanel' failed to load. Error: Failed to load library /home/zlacelle/catkin_ws/devel/lib//libcustompanel.so. Make sure that you are calling the PLUGINLIB_EXPORT_CLASS macro in the library code, and that names are consistent between this macro and your XML. Error string: Could not load library (Poco exception = /home/user/catkin_ws/devel/lib//libcustompanel.so: undefined symbol: _ZTVN10myrviz11CustomPanelE)
I have the constructor defined, with a QWidget* argument, which is defaulted to '0' in the function definition. ORIGINAL PROBLEM (SOLVED BY NEW WORKSPACE): I'm running ROS Kinetic, using catkin to build my packages. I've made a custom rviz plugin to visualize some data, based on examples here: https://github.com/OctoMap/octomap_rv... https://github.com/ccny-ros-pkg/imu_t... I've created a package.xml that:
I have a plugin_description.xml which has all of the normal fields. I have a CMakeLists.txt which:
Finally, I have a PLUGINLIB_EXPORT_CLASS(myrviz::CustomPanel,rviz::Panel) at the bottom of my source code declaration. All of this builds, and I then source my devel/setup.bash. I can see the library However, I cannot see the plugin listed with moveit_ros_visualization /opt/ros/kinetic/share/moveit_ros_visualization/robot_state_rviz_plugin_description.xml moveit_ros_visualization /opt/ros/kinetic/share/moveit_ros_visualization/planning_scene_rviz_plugin_description.xml moveit_ros_visualization /opt/ros/kinetic/share/moveit_ros_visualization/motion_planning_rviz_plugin_description.xml moveit_ros_visualization /opt/ros/kinetic/share/moveit_ros_visualization/trajectory_rviz_plugin_description.xml grid_map_rviz_plugin /opt/ros/kinetic/share/grid_map_rviz_plugin/plugin_description.xml octomap_rviz_plugins /opt/ros/kinetic/share/octomap_rviz_plugins/plugin_description.xml rviz_imu_plugin /opt/ros/kinetic/share/rviz_imu_plugin/plugin_description.xml rviz /opt/ros/kinetic/share/rviz/plugin_description.xml What's my next step to try and debug this issue? |
2019-03-18 17:46:28 -0500 | answered a question | rviz does not know of custom panel The answer was that I did not have the resulting MOC object files linked into my library, thus resulting in undefined sy |
2019-03-18 16:52:52 -0500 | edited question | rviz does not know of custom panel rviz does not know of custom panel TL;DR I cannot get my custom rviz panel to show up in rviz. EDIT: Initial problem wa |
2019-03-18 16:52:52 -0500 | received badge | ● Editor (source) |
2019-03-18 16:50:41 -0500 | answered a question | rviz does not know of custom panel Well, the initial problem from above is that my workspace was hosed: I couldn't roscd to anything and ROS didn't see any |
2019-03-18 15:44:53 -0500 | asked a question | rviz does not know of custom panel rviz does not know of custom panel TL;DR I cannot get my custom rviz panel to show up in rviz. I'm running ROS Kinetic, |
2018-11-12 07:20:37 -0500 | received badge | ● Notable Question (source) |
2018-04-19 03:41:11 -0500 | received badge | ● Popular Question (source) |
2018-04-17 16:21:38 -0500 | edited question | 3d robot_localization and bounding Yaw 3d robot_localization and bounding Yaw I'm fusing the wheel odom and imu on the Husky, with robot_localization's UKF. Wh |
2018-04-17 14:12:59 -0500 | asked a question | 3d robot_localization and bounding Yaw 3d robot_localization and bounding Yaw I'm fusing the wheel odom and imu on the Husky. What I'm wondering is the followi |
2018-03-26 03:44:38 -0500 | received badge | ● Famous Question (source) |
2018-03-05 18:04:56 -0500 | received badge | ● Notable Question (source) |
2018-03-05 18:04:56 -0500 | received badge | ● Popular Question (source) |
2017-12-20 18:53:29 -0500 | asked a question | Why do nodelets sometimes not start Why do nodelets sometimes not start I have a standard camera pipeline set up with nodelets: pointgrey_camera_driver -> |