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

Publishing transforms both directions is incorrect #1278

Closed
tfoote opened this issue Jul 19, 2019 · 5 comments
Closed

Publishing transforms both directions is incorrect #1278

tfoote opened this issue Jul 19, 2019 · 5 comments
Labels
Milestone

Comments

@tfoote
Copy link

tfoote commented Jul 19, 2019

The comment that you need to publish the transform the other way is incorrect.

// for being able to apply the transforms at the data coming from the FCU, the opposite transform is also required

Only one of these should be used:

publish_static_transform("fcu", "fcu_frd", Eigen::Affine3d(ftf::quaternion_from_rpy(M_PI, 0, 0)));
// for being able to apply the transforms at the data coming from the FCU, the opposite transform is also required
publish_static_transform("fcu_frd", "fcu", Eigen::Affine3d(ftf::quaternion_from_rpy(-M_PI, 0, 0)));

They will fight with each other and cause continuous reparenting such that at any given time the last one recieved will win. Likely the first version tested caused a disconnected tree by inadvertent reparenting and adding the second call masked it out.

And while I'm looking at this code. It's cleaner and more efficient to publish a vector of static transforms to take advantage of latching rather than publishing a sequence of individual transforms.

@mhkabir
Copy link
Member

mhkabir commented Jul 20, 2019

We brought this up here before: #1252 (comment)

@TSC21 FYI

@mhkabir
Copy link
Member

mhkabir commented Jul 20, 2019

@jkflying @baumanta Can you guys try to test if the timestamp issue exists with the duplicate publisher removed?

@vooon vooon added this to the Version 0.33 milestone Jul 20, 2019
@baumanta
Copy link
Contributor

baumanta commented Jul 22, 2019

@tfoote you were right with your you comment on issue #388 . The tf loop in mavros seems to be responsible for getting always the tf at ros::Time::now().

I put a tf listener in the avoidance code which retrieved the transforms at the timestamp of the last pointcloud and at ros::Time::now() and printed both transforms. As the drone was moving I would expect the transforms to be slightly different. Using Mavros 0.29.2. both transforms were always identical even thought the timestamps were not. Using Mavros PR #1252 the transforms were different.

@mhkabir
Copy link
Member

mhkabir commented Jul 22, 2019

OK, I suspect why the odom plugin code wasn't working is due to an obscure limitation of latched topics - you cannot publish different messages to a latched topic from the same process.

See ros/ros_comm#146 and https://answers.ros.org/question/261815/how-can-i-access-all-static-tf2-transforms/.

The workaround for this is to construct a vector of all the transforms and publish them in one shot (pass to specialized TF2 function http://docs.ros.org/melodic/api/tf2_ros/html/c++/classtf2__ros_1_1StaticTransformBroadcaster.html#a83d0664cb0cc85688b60a2236e9d81ff)

@TSC21
Copy link
Member

TSC21 commented Oct 7, 2019

Fixed #1300.

@TSC21 TSC21 closed this as completed Oct 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants