-
Notifications
You must be signed in to change notification settings - Fork 2
Add controller manager introspection topic system #33
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
base: main
Are you sure you want to change the base?
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #33 +/- ##
==========================================
+ Coverage 38.62% 39.37% +0.75%
==========================================
Files 2 4 +2
Lines 145 193 +48
Branches 34 40 +6
==========================================
+ Hits 56 76 +20
- Misses 80 107 +27
- Partials 9 10 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
const size_t N = std::min(names.size(), latest_pal_values_.values.size()); | ||
for (size_t i = 0; i < N; i++) |
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 think it is better to check if both the data are of same size before continuing, because I'm not sure if the variables are appended or reordered for every instance
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 just copied this from plotjuggler
https://github.com/facontidavide/PlotJuggler/blob/75f9885826a7aca8c337057d368fe9e4ccfd89b2/plotjuggler_plugins/ParserROS/ros_parser.cpp#L585-L590
not sure why this std::min makes sense here? maybe for robustness for different data sources publishing the same names_version?
pal_values_subscriber_ = get_node()->create_subscription<pal_statistics_msgs::msg::StatisticsValues>( | ||
"~/values", rclcpp::SensorDataQoS(), | ||
[this](const pal_statistics_msgs::msg::StatisticsValues::SharedPtr pal_values) { | ||
latest_pal_values_ = *pal_values; |
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.
Do we need to worry about concurrent access?
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.
that's what my comment in L30 is about. But as there is no such thing in the other component here, I thought that it might not be worth it
Lines 132 to 134 in c179773
topic_based_joint_states_subscriber_ = get_node()->create_subscription<sensor_msgs::msg::JointState>( | |
get_hardware_parameter("joint_states_topic", "/robot_joint_states"), rclcpp::SensorDataQoS(), | |
[this](const sensor_msgs::msg::JointState::SharedPtr joint_state) { latest_joint_state_ = *joint_state; }); |
"~/values", rclcpp::SensorDataQoS(), | ||
[this](const pal_statistics_msgs::msg::StatisticsValues::SharedPtr pal_values) { | ||
latest_pal_values_ = *pal_values; | ||
}); |
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.
Should we add a warning if nothing is publishing on the configured topics? That or add a throttled print when // no data received yet
in read().
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.
in my case it was obvious because no joint_states/tf was published then. But sure, a throttled warning does not hurt
#include <rclcpp_lifecycle/state.hpp> | ||
#include <ros2_control_test_assets/descriptions.hpp> | ||
|
||
TEST(TestTopicBasedSystem, load_topic_based_system_2dof) |
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.
What do you think about adding a test that publishes on the topics this system is listening to and verifying the state matches?
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.
would be great :D
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.
Awesome! Maybe have some data in there that is should nicely ignore 😄.
if (joint_state_interfaces_.find(name) != joint_state_interfaces_.end() ||
sensor_state_interfaces_.find(name) != sensor_state_interfaces_.end() ||
gpio_state_interfaces_.find(name) != gpio_state_interfaces_.end() ||
unlisted_state_interfaces_.find(name) != unlisted_state_interfaces_.end())
Co-authored-by: Marq Rasmussen <[email protected]>
This is useful to replay bags and inject state interfaces from a hardware component into the ros2_control stack.
I'm open for any name suggestions ;)