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

zlacelle's profile - activity

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:

Could not obtain transform from gps_enu to odom. Error was "odom" passed to lookupTransform argument target_frame does not exist.

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:

  • An internally fused north- and gravity-oriented orientation
  • Acclerations in a Z-down frame
  • Rotational rates in a Z-down frame

There are two pieces of data I need to produce, per REP-145:

  • imu/data_raw - The raw readings, converted to a front-left-up frame
  • imu/data - The raw readings with the orientation data added

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:

  • imu/data_raw - Filled with REP-105-conformation (front-left-up) accelerations and rotational rates?
  • imu/data:
    • The angular_velocity and linear_acceleration portions filled now with ENU-transformed versions of the data in imu/data_raw?
    • The orientation portion filled with the ENU orientation?

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)

nm confirms this symbol is undefined.

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:

  • Has <build_depend> on rviz
  • Has <exec_depend> on rviz
  • Has an <export> section that lists <rviz plugin="${prefix}/plugin_description.xml" />

I have a plugin_description.xml which has all of the normal fields.

I have a CMakeLists.txt which:

  • Has a find_package on rviz
  • Has CATKIN_DEPENDS on rviz
  • Has an install() on plugin_description.xml to the SHARE_DESTINATION

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 libcustompanel.so in devel/lib. I can also see my plugin_description.xml in install/share/custompanel.

However, I cannot see the plugin listed with rospack plugins --attrib=plugin rviz. It lists the following:

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 ->