-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
wheel_odometry #691
Conversation
fixes IntelRealSense#609 Only if the ROS params are set
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.
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), |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
@skohlbr I have the same question. Did you find out anything new? |
@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.) |
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