ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version
client->sendGoalAndWait(joint_goal, ros::Duration(0.5));

It will depend on joint_trajectory_controller playing nicely, but if you don't use client->sendGoalAndWait(..), but instead client->sendGoal(..), you don't block and can then use any of SimpleActionClient::cancel*Goal(..) methods (documentation) to cancel the current goal.

int id = 0;
while(id == 0){
    ROS_INFO("I'm waiting for event!\n");
    std_msgs::Int8::ConstPtr id_ptr;
    id_ptr = ros::topic::waitForMessage<std_msgs::Int8>("/event_topic", n);
    [..]

Please don't do this. This is explicitly not what waitForMessage(..) was created for. Under the hood, you're now creating and destroying ros::Publisher instances, which takes time. As they need to resubscribe you run the risk of missing events, undersampling (aliasing) and other nasty effects.

ROS is an event based framework. Subscribe to /event_topic in the normal way, and then in your callback check whether you have an active goal (that you sent using client->sendGoal(..) earlier). If you don't, return from your callback without doing anything. If there is an active goal, check your threshold (or the id if you have to) and then cancel the goal from the msg callback using client->cancelGoal().

client->sendGoalAndWait(joint_goal, ros::Duration(0.5));

It will depend on joint_trajectory_controller playing nicely, nice (ie: be properly implemented, but I believe it is), but if you don't use client->sendGoalAndWait(..), but instead client->sendGoal(..), you don't block and can then use any of SimpleActionClient::cancel*Goal(..) methods (documentation) to cancel the current goal.

int id = 0;
while(id == 0){
    ROS_INFO("I'm waiting for event!\n");
    std_msgs::Int8::ConstPtr id_ptr;
    id_ptr = ros::topic::waitForMessage<std_msgs::Int8>("/event_topic", n);
    [..]

Please don't do this. This is explicitly not what waitForMessage(..) was created for. Under the hood, you're now creating and destroying ros::Publisher instances, which takes time. As they need to resubscribe you run the risk of missing events, undersampling (aliasing) and other nasty effects.

ROS is an event based framework. Subscribe to /event_topic in the normal way, and then in your callback check whether you have an active goal (that you sent using client->sendGoal(..) earlier). If you don't, return from your callback without doing anything. If there is an active goal, check your threshold (or the id if you have to) and then cancel the goal from the msg callback using client->cancelGoal().

client->sendGoalAndWait(joint_goal, ros::Duration(0.5));

It will depend on joint_trajectory_controller playing nice (ie: be properly implemented, but I believe it is), but if you don't use client->sendGoalAndWait(..), but instead client->sendGoal(..), you don't block and can then use any of SimpleActionClient::cancel*Goal(..) methods (documentation) to cancel the current goal.

int id = 0;
while(id == 0){
    ROS_INFO("I'm waiting for event!\n");
    std_msgs::Int8::ConstPtr id_ptr;
    id_ptr = ros::topic::waitForMessage<std_msgs::Int8>("/event_topic", n);
    [..]

Please don't do this. This is explicitly not what waitForMessage(..) was created for. Under the hood, you're now creating and destroying ros::Publisher instances, which takes time. As they need to resubscribe you run the risk of missing events, undersampling (aliasing) and other nasty effects.

ROS is an event based framework. Subscribe to /event_topic in the normal way, and then in your callback check whether you have an active goal (that you sent using client->sendGoal(..) earlier). If you don't, return from your callback without doing anything. anything (you could of course also only subcribe to /event_topic right before you submit your goal.). If there is an active goal, check your threshold (or the id if you have to) and then cancel the goal from the msg callback using client->cancelGoal().

client->sendGoalAndWait(joint_goal, ros::Duration(0.5));

It will depend on joint_trajectory_controller playing nice (ie: be properly implemented, but I believe it is), but if you don't use client->sendGoalAndWait(..), but instead client->sendGoal(..), you don't block and can then use any of SimpleActionClient::cancel*Goal(..) methods (documentation) to cancel the current goal.

int id = 0;
while(id == 0){
    ROS_INFO("I'm waiting for event!\n");
    std_msgs::Int8::ConstPtr id_ptr;
    id_ptr = ros::topic::waitForMessage<std_msgs::Int8>("/event_topic", n);
    [..]

Please don't do this. This is explicitly not what waitForMessage(..) was created for. Under the hood, you're now creating and destroying ros::Publisher instances, which takes time. As they need to resubscribe you run the risk of missing events, undersampling (aliasing) and other nasty effects.

ROS is an event based framework. Subscribe to /event_topic in the normal way, and then in your callback check whether you have an active goal (that you sent using client->sendGoal(..) earlier). If you don't, return from your callback without doing anything (you could of course also only subcribe to /event_topic right before you submit your goal.). goal). If there is an active goal, check your threshold (or the id if you have to) and then cancel the goal from the msg callback using client->cancelGoal().