This repository has been archived by the owner on Jan 16, 2019. It is now read-only.
forked from ros-industrial-attic/ur_modern_driver
-
Notifications
You must be signed in to change notification settings - Fork 19
various improvements and fixes for use_ros_control=true #6
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
1ebfea3
Find matching hardware_interface using the required type
491679f
separate read & update in controller
v4hn 6b96679
Handle latency in pipeline loop
v4hn eb92f43
fix typo
v4hn 0276987
publish wrench w.r.t. tcp frame
v4hn b23d73c
support ros_control in indigo
v4hn File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -28,6 +28,7 @@ static const std::string MAX_VEL_CHANGE_ARG("~max_vel_change"); | |
static const std::string PREFIX_ARG("~prefix"); | ||
static const std::string BASE_FRAME_ARG("~base_frame"); | ||
static const std::string TOOL_FRAME_ARG("~tool_frame"); | ||
static const std::string TCP_LINK_ARG("~tcp_link"); | ||
static const std::string JOINT_NAMES_PARAM("hardware_interface/joints"); | ||
|
||
static const std::vector<std::string> DEFAULT_JOINTS = { "shoulder_pan_joint", "shoulder_lift_joint", "elbow_joint", | ||
|
@@ -43,6 +44,7 @@ struct ProgArgs | |
std::string prefix; | ||
std::string base_frame; | ||
std::string tool_frame; | ||
std::string tcp_link; | ||
std::vector<std::string> joint_names; | ||
double max_acceleration; | ||
double max_velocity; | ||
|
@@ -65,6 +67,7 @@ bool parse_args(ProgArgs &args) | |
ros::param::param(PREFIX_ARG, args.prefix, std::string()); | ||
ros::param::param(BASE_FRAME_ARG, args.base_frame, args.prefix + "base_link"); | ||
ros::param::param(TOOL_FRAME_ARG, args.tool_frame, args.prefix + "tool0_controller"); | ||
ros::param::param(TCP_LINK_ARG, args.tcp_link, args.prefix + "ee_link"); | ||
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. Could you provide some context for what "ee_link" is? 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. The standard end effector link of the UR in ROS-I's urdfs |
||
ros::param::param(JOINT_NAMES_PARAM, args.joint_names, DEFAULT_JOINTS); | ||
return true; | ||
} | ||
|
@@ -109,7 +112,7 @@ int main(int argc, char **argv) | |
if (args.use_ros_control) | ||
{ | ||
LOG_INFO("ROS control enabled"); | ||
controller = new ROSController(*rt_commander, traj_follower, args.joint_names, args.max_vel_change); | ||
controller = new ROSController(*rt_commander, traj_follower, args.joint_names, args.max_vel_change, args.tcp_link); | ||
rt_vec.push_back(controller); | ||
services.push_back(controller); | ||
} | ||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
The existing code here is a mess and it's no wonder you've removed it :-)
Since
onTimeout
isn't used at all and it's sort of being abused as a heartbeat function in your code I'm wondering if it wouldn't make better sense to just always callconsume
after 8ms but in the case of failure, product will be set toT::InvalidProduct
which then would have to be typedef'ed forRTPacket
,StatePacket
andMessagePacket
together with extending the the consumers to accept the new packet types.At least that's something I might end up doing after merging if we can reach a conclusion for the Indigo problem.
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.
Both ways sound ok to me.
You are right that my proposal uses
onTimeout
as a heartbeat, but consuming a non-existing package as an invalid package is just as weird in my opinion.It's simply a matter of where you want to place the guarantee on the lower-bound of the call-rate.
The important point here is that the current pipeline behavior breaks the minimum update rate and results in jerking trajectory execution