WIP: Adds robot status publishing

[yamokosk]

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 the ROS_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.

[yamokosk]

This is a known hack we have to make things work in our hardware setup, but will be removed for the final PR.

[gonzalocasas]

Can't this hack be replaced with "0.0.0.0" and it will generally bind to all interfaces? I tried it on RobotStudio and it works, I haven't had time to test on real hardware yet.

[gavanderhoorn]

There should be no need. If you have your controller setup properly (ie: not using any internal interfaces, which is why @yamokosk needs this), GetSysInfo(\LanIp) actually returns the correct IP.

Binding on all interfaces could work (not sure whether RW likes that), but I'm not a fan.

[yamokosk]

This logic is problematic on real hardware. It keep trajectories from being executed.

[gavanderhoorn]

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.

[gavanderhoorn]

@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?

[jontje]

@yamokosk and @gavanderhoorn, you can for example do something like the following.

In RobotStudio, under the Controller tab -> Configuration Editor -> I/O System:

1. Under Signal, add a Digital Output signal, e.g. named ROB_1_STATIONARY
2. Under System Output, add an output according to:
   Signal Name: ROB_1_STATIONARY
   Status: Mechanical Unit Not Moving
   Argument: ROB_1
3. After a warmstart, then you can use it in the RAPID code like:
   VAR bool in_motion;
in_motion := DOutput(ROB_1_STATIONARY) = LOW;

[yamokosk]

@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).

[gavanderhoorn]

Isn't that exactly what @jontje suggests?

[gavanderhoorn]

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.

[gonzalocasas]

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... 😄 )

[gavanderhoorn]

@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.

[yamokosk]

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.

[gavanderhoorn]

Not sure what happened there with your comment, but good to hear you got it to work.

[yamokosk]

Couldn't easily rebase the whitespace changes. So I redid the work in a new branch. PR incoming.