Closed yamokosk closed 6 years ago
Thanks for the PR @yamokosk, this is much appreciated. I just wanted to let you know we've seen the PR, and it will be reviewed some time soon.
@yamokosk wrote:
How do other industrial robots handle
in_motion
? Are they more sensor driven? For instance looking at joint velocities or estimating joint velocities? In my cursory search through the ABB literature, I couldn't find pre-made signal to easily populate this field.
most industrial robots have some built-in way to signal that the robot (or more precisely: a specific motion-group) is moving.
I haven't checked, but perhaps ABB controllers have something similar. @jontje, would you know of something we could use?
@yamokosk and @gavanderhoorn, you can for example do something like the following.
In RobotStudio, under the Controller tab -> Configuration Editor -> I/O System:
VAR bool in_motion;
in_motion := DOutput(ROB_1_STATIONARY) = LOW;
@gavanderhoorn How about something like Mechanical Unit Not Moving
? Its a signal output of System Configuration (4.10.4.9 of the System Parameters manual).
Isn't that exactly what @jontje suggests?
Btw, I'd like to request that you split the whitespace changes and the functional changes in different commits. There aren't that many functional changes, but the diff is considerable as there are many tabs->spaces changes.
split the whitespace changes and the functional changes in different
@gavanderhoorn you could add ?w=1
to the query string and github shows the whitespace-ignored diff: e.g. https://github.com/ros-industrial/abb/pull/144/files?w=1 (i know, not the same, buuut... 😄 )
@gonzalocasas: thanks, that is indeed how I do this normally, but in this case it'd be nice to split them out, as it will make forward/backporting easier / less messy.
And in general it's more convenient to not mix whitespace/formatting/layout changes with functional changes in the same commit.
Look at the time stamps on the comments (not sure why they are ordered the way they are). I posted my response before i saw anything from @jontje.
Anyways I went ahead and tried this before seeing the confirmation and it worked perfectly on hardware.
As for the whitespace changes, I'll take a look at it.
Not sure what happened there with your comment, but good to hear you got it to work.
Couldn't easily rebase the whitespace changes. So I redid the work in a new branch. PR incoming.
This is a first start at addressing the enhancement originally identified in #34. I am the furthest thing from a RAPID expert that you could possibly find, but I scoured their technical manual and think I have the right API calls to populate the various fields in the robot status message.
Besides better ways I could be doing things, the one known issue I have currently is how to best populate the
in_motion
flag. My first idea was to just grab the state of theROS_new_trajectory
boolean. While this better represents a "motion eminent" state rather than strictly "in motion", I thought it would be a good approximation. However when I tested this logic on hardware, the robot refused to execute any commanded trajectory. My guess is there is maybe a race condition in some trajectory monitoring logic somewhere. If it is a race, it would be compounded by other issues we are currently having (#142). That is the best I can come up with...How do other industrial robots handle
in_motion
? Are they more sensor driven? For instance looking at joint velocities or estimating joint velocities? In my cursory search through the ABB literature, I couldn't find pre-made signal to easily populate this field.Other than help on this specific field, I know I will need to make a PR to update the tutorial wiki (http://wiki.ros.org/abb/Tutorials/InstallServer) as this solution does require setting up some signals in RobotStudio's System Configuration.