-
Notifications
You must be signed in to change notification settings - Fork 19
Publish industrial_msgs::RobotStatus #5
Changes from 3 commits
528e707
f119853
3c7b2a0
a2c620f
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 |
---|---|---|
|
@@ -71,4 +71,4 @@ class RTPublisher : public URRTPacketConsumer | |
virtual void stopConsumer() | ||
{ | ||
} | ||
}; | ||
}; |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -18,6 +18,79 @@ void MBPublisher::publish(ur_msgs::IOStates& io_msg, SharedMasterBoardData& data | |
io_pub_.publish(io_msg); | ||
} | ||
|
||
void MBPublisher::publishRobotStatus(const RobotModeData_V1_X& data) const | ||
{ | ||
industrial_msgs::RobotStatus msg; | ||
|
||
//note that this is true as soon as the drives are powered, | ||
//even if the breakes are still closed | ||
//which is in slight contrast to the comments in the | ||
//message definition | ||
msg.drives_powered.val = data.robot_power_on; | ||
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. Can 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. testing with ursim I get the following output in Poly: meanwhile the robot mode contains the following data: when I turn off the robot: when I turn on the robot but do not yet release the brakes (ON but not START): when I release the brakes: so I'm not sure what real_robot_enabled is supposed to tell us, maybe there is a way to switch to moving a simulated robot on the actual controller? 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.
There is a two-option selection bullet list at the bottom right or left (don't remember) that contains those two options. I've never used it, but IIRC you can use it to switch to a virtual robot. 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.
Edit: hm, no. That makes no sense. 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. ok, found that (for the reference: it is in 'Program Robot' -> 'Move' or 'I/O' but I can only change it to simulated in IO), real_robot_enabled then does turn to false. But this doesn't map to any of the industrial_msgs::RobotStatus fields does it? 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.
So yes, maybe drives powered should be obtained from Mode == RUNNING as in that halfway on mode (breakes still on) it does not automatically start moving. But then drives_powered would be the same as motion_possible. And as far as I understand motion_possible is authorative? 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. I think
|
||
|
||
msg.e_stopped.val = data.emergency_stopped; | ||
|
||
//I found no way to reliably get information if the robot is moving | ||
//data.programm_running would be true when using this driver to move the robot | ||
//but it would also be true when another programm is running that might not | ||
//in fact contain any movement commands | ||
msg.in_motion.val = industrial_msgs::TriState::UNKNOWN; | ||
|
||
//the error code, if any, is not transmitted by this protocol | ||
//it can and should be fetched seperately | ||
msg.error_code = 0; | ||
|
||
//note that e-stop is handled by a seperate variable | ||
msg.in_error.val = data.protective_stopped; | ||
|
||
if (data.robot_mode == robot_mode_V1_X::ROBOT_FREEDRIVE_MODE) | ||
msg.mode.val = industrial_msgs::RobotMode::MANUAL; | ||
else | ||
msg.mode.val = industrial_msgs::RobotMode::AUTO; | ||
|
||
//todo: verify that this correct, there is also ROBOT_READY_MODE | ||
msg.motion_possible.val = (data.robot_mode == robot_mode_V1_X::ROBOT_RUNNING_MODE) | ||
? industrial_msgs::TriState::ON : industrial_msgs::TriState::OFF; | ||
|
||
status_pub_.publish(msg); | ||
} | ||
|
||
void MBPublisher::publishRobotStatus(const RobotModeData_V3_0__1& data) const | ||
{ | ||
industrial_msgs::RobotStatus msg; | ||
|
||
//note that this is true as soon as the drives are powered, | ||
//even if the breakes are still closed | ||
//which is in slight contrast to the comments in the | ||
//message definition | ||
msg.drives_powered.val = data.robot_power_on; | ||
|
||
msg.e_stopped.val = data.emergency_stopped; | ||
|
||
//the error code, if any, is not transmitted by this protocol | ||
//it can and should be fetched seperately | ||
msg.error_code = 0; | ||
|
||
//I found no way to reliably get information if the robot is moving | ||
//data.programm_running would be true when using this driver to move the robot | ||
//but it would also be true when another programm is running that might not | ||
//in fact contain any movement commands | ||
msg.in_motion.val = industrial_msgs::TriState::UNKNOWN; | ||
|
||
//note that e-stop is handled by a seperate variable | ||
msg.in_error.val = data.protective_stopped; | ||
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. 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. there does not seem to be another way to be informed about errors looking at the format in robot_mode.h 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. What about 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 okay, I thought of e-stopped more like a state and the error would appear separately once you try moving despite it being in e-stopped mode. But I can change it to said union. This would again ask for a place to define the "vendor specific" error codes and then setting 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. "Vendor specific" means that the error codes are defined by the vendor. Not by us, for every vendor. This field is typically populated by copying the error code that the robot controller gives you for different errors. On Fanucs fi you would be copying the code returned by the Those codes are defined by Fanuc. We don't make them up ourselves. UR has similar codes I believe (just take a look at the log on the TP), but I'm not sure we can retrieve those from somewhere. 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 could definitely be a way to implement it, but we would need a way to reliably determine which of the two it is. I don't have a scripting manual with me right now, but if there is a 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. You're correct. Let's keep what you have for now. Sorry for the noise. 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. re: vendor specific codes: looking at a UR we have here I keep seeing Those are the codes that would go into |
||
|
||
msg.motion_possible.val = (data.robot_mode == robot_mode_V3_X::RUNNING) | ||
? industrial_msgs::TriState::ON : industrial_msgs::TriState::OFF; | ||
|
||
if (data.control_mode == robot_control_mode_V3_X::TEACH) | ||
msg.mode.val = industrial_msgs::RobotMode::MANUAL; | ||
else | ||
msg.mode.val = industrial_msgs::RobotMode::AUTO; | ||
|
||
status_pub_.publish(msg); | ||
} | ||
|
||
bool MBPublisher::consume(MasterBoardData_V1_X& data) | ||
{ | ||
ur_msgs::IOStates io_msg; | ||
|
@@ -42,13 +115,16 @@ bool MBPublisher::consume(MasterBoardData_V3_2& data) | |
|
||
bool MBPublisher::consume(RobotModeData_V1_X& data) | ||
{ | ||
publishRobotStatus(data); | ||
return true; | ||
} | ||
bool MBPublisher::consume(RobotModeData_V3_0__1& data) | ||
{ | ||
publishRobotStatus(data); | ||
return true; | ||
} | ||
bool MBPublisher::consume(RobotModeData_V3_2& data) | ||
{ | ||
publishRobotStatus(data); | ||
return true; | ||
} | ||
} |
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 this perhaps be published at "ur_driver/robot_status"?
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.
We could, but that would make it non-compliant with other ros-i robot drivers.
A remap can fix that though.
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.
Alright yes that makes perfect sense, let's keep it as it is here then.
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.
Well .. let's actually not.
All topics for the
ur_driver
are below aur_driver
namespace already, so having this one outside it breaks that.If/when we need to make this driver ros-i compliant, we can either blanketly remap everything or update the topics.
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.
So I'll add the prefix for consistencies sake?
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 believe that makes the most sense for now, yes.
Otherwise users would find all topics of the driver under the
ur_driver
namespace, but a lone (and seemingly unrelated)/robot_status
topic in the global one.