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

Add boost serialization for Environment commands and all underlying types #726

Conversation

mpowelson
Copy link
Contributor

This adds boost serialization for types in tesseract_srdf, tesseract_common, tesseract_geometry, and tessseract_environment. This should be enough to fully serialize planning server requests. This also adds == operators for all of these types that is used to test the serialization. Every type should have a serialization unit test.

There are a few places where additional work can be done. For example we may want to add the ability to change how a mesh geometry is serialized and only serialize the path in some cases. I'll leave that for future work for now.

@mpowelson mpowelson force-pushed the feature/serialize_planning_request branch from e62d1c7 to a6d634a Compare March 22, 2022 21:50
@codecov
Copy link

codecov bot commented Mar 22, 2022

Codecov Report

Merging #726 (54211fd) into master (bfa7976) will decrease coverage by 0.20%.
The diff coverage is 88.71%.

❗ Current head 54211fd differs from pull request most recent head fba8e37. Consider uploading reports for the commit fba8e37 to get more accurate results

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #726      +/-   ##
==========================================
- Coverage   90.82%   90.61%   -0.21%     
==========================================
  Files         189      220      +31     
  Lines       12658    13483     +825     
==========================================
+ Hits        11496    12218     +722     
- Misses       1162     1265     +103     
Impacted Files Coverage Δ
tesseract_common/src/any.cpp 66.66% <ø> (ø)
tesseract_common/src/eigen_serialization.cpp 56.81% <0.00%> (ø)
tesseract_common/src/joint_state.cpp 100.00% <ø> (ø)
tesseract_common/src/kinematic_limits.cpp 100.00% <ø> (ø)
tesseract_common/src/manipulator_info.cpp 97.43% <ø> (ø)
tesseract_common/src/utils.cpp 94.50% <ø> (ø)
...ry/include/tesseract_geometry/impl/mesh_material.h 100.00% <ø> (ø)
tesseract_common/src/allowed_collision_matrix.cpp 76.47% <76.47%> (ø)
...mands/add_contact_managers_plugin_info_command.cpp 80.00% <80.00%> (ø)
...rc/commands/add_kinematics_information_command.cpp 80.00% <80.00%> (ø)
... and 82 more

@@ -27,7 +27,7 @@ TEST(TesseractCoreUnit, getCollisionObjectPairsUnit) // NOLINT
std::vector<tesseract_collision::ObjectPairKey> pairs =
tesseract_collision::getCollisionObjectPairs(active_links, static_links);

EXPECT_TRUE(tesseract_common::isIdentical<tesseract_collision::ObjectPairKey>(pairs, check_pairs, false));
EXPECT_FALSE(tesseract_common::isIdentical<tesseract_collision::ObjectPairKey>(pairs, check_pairs, false));
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems odd. Did some logic change somewhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The isIdentical function did change, but it should be doing the same thing. Looking at the test, it seems like this should be false since acm is nullptr.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this should still be returning true. It is comparing if the two vectors are equal and order does not matter which they should be equal. Am I missing something?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The problem is that pairs is empty. getCollisionObjectPairs only pushes back pairs if acm !=nullptr. At line 28 we aren't passing it in, so it is empty. When we call it at 48, we pass in the acm, so it is the same as check_pairs.

I'm not sure why this was passing before, but the vectors are not the same. One has the pairs above. The other is empty.

Copy link
Contributor Author

@mpowelson mpowelson Mar 23, 2022

Choose a reason for hiding this comment

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

Actually, I see the reason. If the first vector is empty, nothing was being checked. This is how isIdentical was checking equality

Since vec1 is empty, it just returns true.

    return std::equal(vec1.begin(), vec1.end(), vec2.begin());

However, I added this up above that. So now it fails

  if (vec1.size() != vec2.size())
    return false;

Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like getCollisionObjectPairs is broken. If acm is nullptr then it should add the pairs. The fix is below which needs to be updated two places in the function. Can you added it to this PR?

Current:

if (acm != nullptr && !acm(l1, l2))
        clp.push_back(tesseract_collision::getObjectPairKey(l1, l2));

Fixed:

if (acm == nullptr || acm != nullptr && !acm(l1, l2))
        clp.push_back(tesseract_collision::getObjectPairKey(l1, l2));

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@mpowelson mpowelson force-pushed the feature/serialize_planning_request branch from 54211fd to f4abc1b Compare March 24, 2022 00:24
@mpowelson mpowelson force-pushed the feature/serialize_planning_request branch from f4abc1b to fba8e37 Compare March 24, 2022 00:26
@Levi-Armstrong Levi-Armstrong merged commit fab4dc7 into tesseract-robotics:master Mar 24, 2022
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.

2 participants