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

OccupancyMapMonitor tests using Dependency Injection #569

Merged
merged 10 commits into from
Aug 25, 2021

Conversation

tylerjw
Copy link
Member

@tylerjw tylerjw commented Jul 23, 2021

Description

Dependency Injection for OccupancyMapMonitor. More tests to come.

Checklist

  • Required by CI: Code is auto formatted using clang-format
  • Create tests, which fail without this PR reference
  • While waiting for someone to review your request, please help review another open pull request to support the maintainers

@codecov
Copy link

codecov bot commented Jul 23, 2021

Codecov Report

Merging #569 (abba127) into main (31470cc) will increase coverage by 0.06%.
The diff coverage is 20.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #569      +/-   ##
==========================================
+ Coverage   54.22%   54.28%   +0.06%     
==========================================
  Files         190      191       +1     
  Lines       20063    20084      +21     
==========================================
+ Hits        10878    10901      +23     
+ Misses       9185     9183       -2     
Impacted Files Coverage Δ
...clude/moveit/occupancy_map_monitor/occupancy_map.h 8.34% <ø> (+8.34%) ⬆️
...veit/occupancy_map_monitor/occupancy_map_updater.h 0.00% <ø> (ø)
...or/src/occupancy_map_monitor_middleware_handle.cpp 0.00% <0.00%> (ø)
...ccupancy_map_monitor/src/occupancy_map_updater.cpp 0.00% <ø> (ø)
...ccupancy_map_monitor/src/occupancy_map_monitor.cpp 18.90% <46.67%> (+18.90%) ⬆️
...veit/occupancy_map_monitor/occupancy_map_monitor.h 25.00% <50.00%> (+25.00%) ⬆️
...dl_kinematics_plugin/src/kdl_kinematics_plugin.cpp 74.72% <0.00%> (-1.13%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 31470cc...abba127. Read the comment docs.

Copy link
Contributor

@jliukkonen jliukkonen left a comment

Choose a reason for hiding this comment

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

My initial review. I think I want to leave another round of comments later when I have time to go through it more thoroughly.


OccupancyMapMonitor::OccupancyMapMonitor(const rclcpp::Node::SharedPtr& node, double map_resolution)
: map_resolution_(map_resolution), debug_info_(false), mesh_handle_count_(0), node_(node), active_(false)
namespace
Copy link
Contributor

@jliukkonen jliukkonen Jul 23, 2021

Choose a reason for hiding this comment

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

Nit: Should this namespace be outside the occupancy_map_monitor namespace for better readability? My personal preference is to have them be outside any namespace to underscore their "anonymousness".

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm just copying a pattern I've seen in other parts of the MoveIt code base. I would prefer consistency, although I agree that having a separate anonymous namespace seems to be clearer. For consistency sake I want to leave this as is.

Copy link
Contributor

Choose a reason for hiding this comment

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

https://en.cppreference.com/w/cpp/language/namespace#Unnamed_namespaces

I ... think that the difference might be if someone wrote using namespace occupancy_map_monitor;, then another variable named LOGGER would conflict... I think.
While users shouldn't do that https://abseil.io/tips/153, we might consider not leaving a trap for them if my suspicion is correct.

but I guess all of this is in the cpp so... do they not export?

Copy link
Member Author

Choose a reason for hiding this comment

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

This is in the cpp so I would assume they wouldn't export

Copy link
Contributor

Choose a reason for hiding this comment

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

But do they?

Copy link
Contributor

Choose a reason for hiding this comment

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

Well, as cppreference points out, things in anonymous namespaces can be imported.
In your gtest, I would try to access something in your anon namespace defined in your cpp

Copy link
Contributor

Choose a reason for hiding this comment

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

cppreference:

Even though names in an unnamed namespace may be declared with external linkage, they are never accessible from other translation units because their namespace name is unique.

If that's what you mean by export here. But I guess you knew that before.
This only affects the individual cpp file and if anyone defines a second LOGGER there, you should change the names anyway to reflect the different meanings.

Usually I prefer anonymous namespaces inside file-wide namespaces to avoid having to spell out the file-wide namespace each time I need to access other symbols from there. While this is not used here, it makes some sense to keep the style consistent.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, it didn't seem likely that anything would be exported if declared in the cpp because of the external linkage. I guess it was a bit of sticker shock since I didn't know that anon-namespace anything could be exported.

file-wide namespace?

Copy link
Contributor

Choose a reason for hiding this comment

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

file-wide namespace?

It's not a technical term. Some maintainers introduced namespace declarations that span virtually the whole file for many packages in MoveIt (e.g., this one) to avoid the full namespace declaration for each symbol.

Copy link
Contributor

Choose a reason for hiding this comment

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

oic

Copy link
Contributor

@griswaldbrooks griswaldbrooks left a comment

Choose a reason for hiding this comment

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

Added comments. Also, not having the ability to resolve things is very frustrating 🚀

@tylerjw tylerjw force-pushed the occupancy_map_monitor_tests branch 2 times, most recently from 993dd37 to 614c8e3 Compare July 28, 2021 22:58
@tylerjw
Copy link
Member Author

tylerjw commented Jul 28, 2021

Added comments. Also, not having the ability to resolve things is very frustrating rocket

I agree, this seems like a github bug. https://twitter.com/weaveringrally/status/1420517755380436997 I couldn't find a github issue and found someone saying that tweeting at github has worked for them before at getting their attention.

I updated all the files I've touched with the same format for includes and consistent doxygen comments with descriptions as best as I understand.

@tylerjw tylerjw force-pushed the occupancy_map_monitor_tests branch 4 times, most recently from 0e29002 to 5b9fbae Compare July 28, 2021 23:21
@tylerjw tylerjw requested a review from v4hn July 28, 2021 23:30
@tylerjw tylerjw force-pushed the occupancy_map_monitor_tests branch 5 times, most recently from 3b3eb95 to 8637b7b Compare July 29, 2021 17:32
@tylerjw
Copy link
Member Author

tylerjw commented Jul 29, 2021

It seems that re-ordering the includes broke the Foxy CI run. I've installed foxy locally and am working on figuring this one out.

@tylerjw tylerjw force-pushed the occupancy_map_monitor_tests branch from 8637b7b to 0489a5b Compare July 29, 2021 21:02
std::unique_ptr<MiddlewareHandle> middleware_handle_; /*!< The abstract interface to ros */
std::shared_ptr<tf2_ros::Buffer> tf_buffer_; /*!< TF buffer */
Parameters parameters_;
std::mutex parameters_lock_; /*!< Mutex for synchronizing access to parameters */

Choose a reason for hiding this comment

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

I just realized that sometimes the access to parameters is protected by mutex but most of the time it isn't. Is that a bug or am I just reading the code wrong?

Copy link
Member Author

Choose a reason for hiding this comment

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

This mutex is never actually used to synchronize anything. I think someone had a plan to do that but didn't. I am separately working on implementing dynamic parameters for moveit2 and will clean this up in an unrelated change.


OccupancyMapMonitor::OccupancyMapMonitor(const rclcpp::Node::SharedPtr& node, double map_resolution)
: map_resolution_(map_resolution), debug_info_(false), mesh_handle_count_(0), node_(node), active_(false)
namespace
Copy link
Contributor

Choose a reason for hiding this comment

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

oic

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

Successfully merging this pull request may close these issues.

None yet

7 participants