Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wheel_odometry #691

Merged
merged 8 commits into from
Apr 1, 2019
Merged

Conversation

doronhi
Copy link
Contributor

@doronhi doronhi commented Mar 21, 2019

Integrating robot's odometry into T265.
rs_camera.launch include 2 more parameters that needs to be filled to use this option:
topic_odom_in - which topic to listen to. Only using twist.twist.linear
calib_odom_file - calibration file. Format is described in merged PR#3462

doronhi and others added 8 commits March 20, 2019 15:40
with equivalent to ros::names::isValidCharInName(char c)
by finding the ROS (static) param in the enum dictionary, which can take
values in the min:step:max range (not just 0 <= value < enum_dict.size()).

Also remove the check when the option is taken from the sensor, which
should always be correct.
so we don't loop with float values.
fix launch files.
@skohlbr
Copy link

skohlbr commented Mar 29, 2019

Will odometry also work for robots that undergo significant motion in rough terrain and/or exhibit significant noise in their odometry estimate? Or is there an implicit assumption that the robot is moving on flat ground? I'm thinking about tracked vehicles moving outdoors here.

void T265RealsenseNode::odom_in_callback(const nav_msgs::Odometry::ConstPtr& msg)
{
ROS_INFO("Got in_odom message");
rs2_vector velocity {-(float)(msg->twist.twist.linear.y),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to apply a coordinate transformation here. The relative transformation between odometry frame and T265 body frame is handled in the calibration.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to keep the calibration.json file in a ROS standard. That is, X-forward, Y-Left and Z-Up.
For that reason it is necessary to convert from ROS coordinate system to T265's.

@doronhi doronhi merged commit 6d2029e into IntelRealSense:development Apr 1, 2019
@sadransh
Copy link

@skohlbr I have the same question. Did you find out anything new?

@schmidtp1
Copy link
Contributor

schmidtp1 commented Nov 25, 2019

@skohlbr, @sadransh, there is no implicit assumption of the robot moving on a flat ground YET if only one component of the 3D velocity measurement vector is provided and the other two are set to zero, these act as pseudo measurements and enforce a "soft" constraint on the instantaneous velocity in these directions to be zero, i.e. that robot is moving on a (smooth) surface and cannot go up/down or left/right. It doesn't necessarily have to be flat and would work when driving on ramps for example or for rotation when driving over bumps. (This is important to keep track of visual features.)
The measurement noise covariance parameter allows to account for (white) noise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants