Realsense T265 communication issue

asked 2019-08-08 05:29:03 -0500

xlightx gravatar image

updated 2019-09-25 04:11:02 -0500

Tom Moore gravatar image

Hi all, I am trying to work on the new realsense t265 with the robot_localization on my differential drive two wheeled robot. The realsense outputs the topic "camera/odom/sample" of nav_msgs/Odometry which suits perfectly the robot_localization inputs. My problem is that once I connect both it seems I am having communication issues and I see specially this in RViz, it just slows down.

The odom topic is publishing at 200 Hz, due to the imu rate. As reported also here:

"Why do we need to limit the T265 data rate in step 5? As it turns out, the 200Hz data stream from the T265 is too fast for the FCU, especially the older hardware versions, to handle. In my experiment with fmuv2 hardware, the moment you start sending pose data at 200 times per second, the FCU will be flooded and “freezed”, as no more data coming to telem channel. Slowing down the pose data is necessary. Furthermore, we don’t really need 200Hz of data. 10-15Hz localization data is the bare minimum threshold that is required for testing, and 30Hz should be more than enough for most cases (relative to how fast the vehicle is moving)."

The hacky solution was found on part 2 of the blog, which consists in looking up the transform between the odom and pose frame and convert that to a PoseWithCovarianceStamped that inputs into the Odom EKF. I did this, but I lose the velocity information of course.

Is anyone having this problem? Any hints?

realsense-ros: 2.2.7; librealsense: 2.24.0

edit retag flag offensive close merge delete


Are you using package librealsense-ros? why don't you down-sample to 20 or 30Hz, 200Hz is too fast indeed and kind of useless, i think.

mattcenoo gravatar image mattcenoo  ( 2019-09-11 07:43:24 -0500 )edit

Hi. I am using realsense_ros yes. I did it different ways: - Explained above. - Using throttle from topic tools, still subscribes to a topic that publishes at 200 Hz, which is what I want to avoid. - Developed a node in python, but has the some effect as the above. - Developed a node in cpp, that is controlled by a rate. The later worked for me, but it's not an optimal solution, in my opinion. Should come from Intel the possibility of decreasing the rate.

xlightx gravatar image xlightx  ( 2019-09-11 07:53:40 -0500 )edit

Ah, this question had been asked in realsense github issues, and intel guys said NO. I don't know how your cpp node work, subscribe to that topic and publish a low-rate topic? Then, why don't you down-sample in pose_callback in realsense_ros, although it's not elegant either, :)

mattcenoo gravatar image mattcenoo  ( 2019-09-11 21:16:50 -0500 )edit

Having several realsense sensor in my robot, I think that will affect all. Right?

xlightx gravatar image xlightx  ( 2019-09-12 03:27:48 -0500 )edit

In case you have multiple pose streams (Tracking Module), yes.

mattcenoo gravatar image mattcenoo  ( 2019-09-12 08:02:34 -0500 )edit