Bugfixes, timestamp accounting for transmission delay, custom baseframe #12
Conversation
echoGee
commented
Apr 11, 2023
echoGee
commented
- Fixed bugs for pointcloud publishing
- added a base frame variable to change from launch file
- publishes header with right timestamp accounting for transmit delay
…ng code, but not reliable. pointcloud publish does not work"
2. Changes the timestamp of the ros messages to account for the delay in transmission from the mocap system
| @@ -69,7 +71,7 @@ Launch file `natnet_ros.launch` contains the several configurable arguments. The | |||
|
|
|||
| #### Publishing the single marker | |||
| It is possible to track the single marker as a rigid body with constant orientation. Go to the `config/initiate.yaml` It is suggested to make a copy of the file and rename the new file. | |||
| The file contains the details on what to modify. | |||
| The file contains the details on what to modify. Basically, the approximate position of an individual marker has to be noted in this file and a basic filtering algorithm will track it over time. The filtering is not that robust and you can see it disappear often | |||
There was a problem hiding this comment.
Improved algorithm will be available soon. I am working on major changes and some additional features.
| msgRigidBodyPose.header.frame_id = "world"; | ||
|
|
||
| msgRigidBodyPose.header.stamp = ros::Time::now(); | ||
| initROSmsgHeader(msgRigidBodyPose.header, internal); |
There was a problem hiding this comment.
This looks good. I have one question,
It is not a good idea to use initROSmsgHeader(msgRigidBodyPose.header, internal); for each body and markers. Because I think it might cause major time stamp difference when there are multiple bodies and code will loop through all the number of frames for publishing.
I will modify it a bit.
There was a problem hiding this comment.
didn't follow. all the bodies in one frame should have the same time frame
There was a problem hiding this comment.
suppose we have a huge arena and we have multiple rigid bodies in parallel with multiple single marker tracking, so what your implementation is doing, is assigning all the same time stamp. But publishing is not done at the same time. Publishing is FIFO so all the body and markers will have slightly different time stamp (difference in nano seconds)
There was a problem hiding this comment.
The actual publishing is done in different timestamp, but the header timestamp consists of the "real" time at which the mocap captured the frame
There was a problem hiding this comment.
Yes that's where I am bit confused.
What makes more sense to you, to consider the time of arrival of data in queue or time of exit minus the communication delay between the systems?
There was a problem hiding this comment.
Having a header timestamp pointing to as precise of a time of exact occurrence helps for controls tuning, debugging etc
There was a problem hiding this comment.
I see. I will keep it optional and let users choose one of the model for the timestamp in the launch file.
| @@ -68,10 +68,10 @@ class Internal | |||
| void PubRigidbodyMarker(sMarker &data, Internal &internal); | |||
|
|
|||
| // Publish Single marker as the Rigidbody and TF | |||
| void PubMarkerPose(sMarker &data, Internal &internal); | |||
| void PubMarkerPoseWithTrack(sMarker &data, Internal &internal); | |||
There was a problem hiding this comment.
I prefer not change the name of this function as I have already developed on top of this.
There was a problem hiding this comment.
felt it was more descriptive this way :)
| if (replaced_strName) | ||
| ROS_INFO("RigidBody found : %s replaced name with %s", pRB->szName, body_name.c_str()); | ||
| else | ||
| ROS_INFO("RigidBody found : %s", pRB->szName); |
There was a problem hiding this comment.
Never faced this issue but good idea to consider this as it might create some troubles. Good found ;)
|
I won't be able to merge the pr for now as I am working on some other changes as well. plus I will have to test the code locally before merging it to the main. I will put it in other branch and let user choose the other branch till I finish the update. I will include the changes in the next update. can you re-base the pr to the branch |
