-
Notifications
You must be signed in to change notification settings - Fork 94
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
Added status topic to indicate which mux channel is selected and if l… #20
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -23,7 +23,6 @@ | |
#include <twist_mux/topic_handle.h> | ||
#include <twist_mux/twist_mux_diagnostics.h> | ||
#include <twist_mux/twist_mux_diagnostics_status.h> | ||
#include <twist_mux/utils.h> | ||
#include <twist_mux/xmlrpc_helpers.h> | ||
|
||
/** | ||
|
@@ -53,6 +52,9 @@ TwistMux::TwistMux(int window_size) | |
ros::NodeHandle nh; | ||
ros::NodeHandle nh_priv("~"); | ||
|
||
/// Get basic node configuration | ||
nh_priv.param("pub_status_continuously", pub_status_continuously_, false); | ||
|
||
/// Get topics and locks: | ||
velocity_hs_ = boost::make_shared<velocity_topic_container>(); | ||
lock_hs_ = boost::make_shared<lock_topic_container>(); | ||
|
@@ -61,6 +63,7 @@ TwistMux::TwistMux(int window_size) | |
|
||
/// Publisher for output topic: | ||
cmd_pub_ = nh.advertise<geometry_msgs::Twist>("cmd_vel_out", 1); | ||
status_pub_ = nh.advertise<std_msgs::String>("out_status", 5, true); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just |
||
|
||
/// Diagnostics: | ||
diagnostics_ = boost::make_shared<diagnostics_type>(); | ||
|
@@ -80,9 +83,15 @@ void TwistMux::updateDiagnostics(const ros::TimerEvent& event) | |
diagnostics_->updateStatus(status_); | ||
} | ||
|
||
void TwistMux::publishTwist(const geometry_msgs::TwistConstPtr& msg) | ||
void TwistMux::publishTwist(const geometry_msgs::TwistConstPtr& msg, const std::string& name) | ||
{ | ||
cmd_pub_.publish(*msg); | ||
if(pub_status_continuously_ || name != last_pub_name_){ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also here, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, I see here why the param is appended with But why publish a topic continuously when the data does not change? This is exactly what latched topics are for! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That mostly had to do with my application at the moment of writing this. I had it going through a ROS1 bridge to ROS2 which meant latching did not work for me so I had to get around it with that solution. I can probably remove it now since that specific application is no longer something I need. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks, it's probably nicer not to modify all nodes for a shortcoming in |
||
std_msgs::String status; | ||
status.data = name; | ||
status_pub_.publish(status); | ||
last_pub_name_ = name; | ||
} | ||
} | ||
|
||
template<typename T> | ||
|
@@ -157,6 +166,15 @@ bool TwistMux::hasPriority(const VelocityTopicHandle& twist) | |
priority = velocity_priority; | ||
velocity_name = velocity_h.getName(); | ||
} | ||
} | ||
else if(last_pub_name_ == velocity_h.getName() && | ||
(pub_status_continuously_ || last_locked_name_ != velocity_h.getName())) | ||
{ | ||
std_msgs::String status; | ||
status.data = "locked"; | ||
last_pub_name_ = "locked"; | ||
status_pub_.publish(status); | ||
last_locked_name_ = velocity_h.getName(); | ||
} | ||
} | ||
|
||
|
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.
wouldn't it be handier to add a new message that contains these two strings and publish that?
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 usually try to avoid adding custom messages for stuff like this. Unless you really believe that a new message type is the best way to go and don't like the current implementation of two topics, I'm thinking it might be better to either concatenate the strings with an easily parse-able delimiter or potentially use something like the diagnostics messages.
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 made the other couple small changes, let me know what you think the best course of action is on this. Unfortunately I no longer have a melodic setup with ROS1 so I may not be able to make + test any major modifications anytime soon.