compas-rrc / compas_rrc Goto Github PK

Summary

As a user who send motion commands to ABB, I want to know the actual position/joint value of the robot after each motion command so that I can monitor the error/deviation.

Details

I would in essence like to have a combined version of rrc.MoveToJoints with rrc.GetJoints. The use case for this is that I send motion commands that came from JointTrajectory, each JointTrajectoryPoint creates one rrc.MoveToJoints. At each point, I use a Zone.Z5 so that motion is not jagged and at the same time I would like to monitor the deviation within this Zone. This deviation comes also from the fact that I'm using the soft move function in ABB.

I have tried to weave rrc.MoveToJoints and rrc.GetJoints. But this produces a start and stop jagged motion for every point in a trajectory. It is not practical. I believe the RAPID code / controller side motion planner do not tween motion commands when they are separated by the GetJoints command.

it would be welcome that the README.md makes the implementation explicit (that its using ROS)
this is non-obvious since ABB controller support a REST API via webservices

Perhaps the best way would be to render the diagram (https://github.com/compas-rrc/compas_rrc/blob/main/images/overview-diagram.png) in the README.md?
It's gorgeous and the architecture of the project is crystal clear

As a compas_rrc user, I would like to take advantage of the tool relative motion (RAPID RelTool)

Details

Describe the feature and the current behavior/state
RelTool allows tool relative motion and rotation.

Describe alternatives you've considered
I am currently reading in the robot frame, offsetting the frame, and then moving the robot with a MoveL to the offset target frame.

Will this change the current API? How?
Adding a class ToolRelativeMove to motion.py, and implementing the RAPID function.

Are you willing to contribute it?
Yes, I can help with the class ToolRelativeMove in the motion.py module.

Summary

As a user who execute robotic code, I want to program an operator stop and ask user to confirm on the Teach Pendant so that I do not have to constantly run back and forth between my code window and Teach Pendant.

Details

Describe the feature and the current behavior/state
I want to create dialog box on the Teach Pendant. With 2 to 3 buttons. The command should block the robot motion, wait for user to press a button, return the result.

Describe alternatives you've considered
At the moment, if I want to have an operator confirm an action, I program an rrc.Stop() and the only interaction I can perform is to press the Play again to continue. Anything more complex than that I have to do this in command line and I have to jump back and forth between TP and command line. And while my left hand holds down the TP switch and the TP isn't wireless, this is a pain point.

Will this change the current API? How?
It is a new feature so it is probably Backward compatible.

Are you willing to contribute it?
No

I tried to print an manifesto on the ABB TP. And I realize it throws an obscured error which took me a while to fugure out.

Turns out RAPID String class only holds less than 80 characters.....
https://forums.robotstudio.com/discussion/8948/why-string-length-is-limited-to-80-characters-in-rapid#:~:text=It%20is%20described%20in%20the,)%20enclosed%20by%20quotation%20marks%22.

Expected Result

I want this behavior to be documented or have an error thrown at me in a more understandable error message. Ideally throwing it back to me in code not just something viewable from RobotStudio.

Maybe the RAPID side can implement something behind the scene to deal with longer string and display it one way or another.

Actual Result

A error message quickly flashed on the TP, it is viewable from Robot Studio.

Reproduction Steps

Just try print a long text with rrc.PrintText

Summary

As a [user], I want rrc.Stop to expose ABB option Stop\NoRegain so that there is an option to not automatically regain position upon restart.

Details

Describe the feature and the current behavior/state
After I stop a program using rrc.Stop, and if I manually jogged the robot using the TP, upon restart of the program, the robot controller by default goes back to the last program execution point. The ABB controller will only display a message to ask user what to do when the jogging is large, for small jogging the robot will automatically regain previous position without asking (how impolite).

This is not always desirable and it is just an easy option in RAPID to have Stop\NoRegain;

Will this change the current API? How?
New Feature

Are you willing to contribute it?
No

Any additional info.
@fleischp previously wrote a custom function for me and I think other people can benefit from it too.

Summary

As an RRC user, I want be able to send an instruction even before the robot has connected, and have the code wait until robot connection to execute it so that I can simplify the client code.

Details

Will this change the current API? How?
One option would be to have a method abb.wait_for_robot() so that client code could be:

ros = RosClient()
ros.run()

abb = AbbClient(ros,'/')
abb.wait_for_robot()
current_pose = abb.send_and_wait(GetFrame())

Additionally, wait_for_robot could take a timeout parameter, but not raise exceptions if it's expired, just like the wait methods of threading.Event, eg:

ros = RosClient()
ros.run()

abb = AbbClient(ros,'/')

while True:
   if not abb.wait_for_robot(timeout=10):
      print('Robot not connected, will retry...')
      continue

   current_pose = abb.send_and_wait(GetFrame())

Summary

As a compas_fab user, I want be able to send an entire trajectory to the robot so that I don't have to manually send individual waypoints/configurations that result from the planning tools.

Details

Describe the feature and the current behavior/state
Currently, it is needed to iterate over the waypoints in a trajectory and send them individually as send -usually ending with send_and_wait.

The ideal scenario should allow doing things like automatically vary speed using easing functions so use higher speeds at waypoints far away from collisions, and then slow down when approximating insertion frame.

Will this change the current API? How?
It should not be a breaking change.

Are you willing to contribute it?
Yes

When using a custom instruction based on the RRC custom_instruction template, that sends feedback i.e. parse_feedback, the custom instruction can get stuck and hang forever.

The culprit is the incorrect parsing of the feedback values, that normally would raise a Python Exception. However in conjunction with rrc's send_and_wait no Exception is raised whatsoever.

Expected Result

Python Exception raised

Actual Result

Nothing, script gets stuck.

Reproduction Steps

Parse a feedback incorrectly e.g. string_values[0] when string_values is an empty list

System Information

Operating System name and version, Python version, etc.
compas_rrc v 1.1.0

Summary

As a user, I want to send compas_fab planned result directly via rrc so that I do not need to manually convert JointTrajectoryPoint to compas_rrc.RobotJoints/ExternalAxes.

Details

It might be similar to # 10 but it is slightly different. As a user of the RFL URDF, I get planner result sometimes in full configuration (4 robots + 10 external axis). It would be nice if the functions in rrc that consumes a compas.robots.Configuration can automatically take the relevant joint values. Because in practice I have different controllers managing 4 robots and they all consume part of this config.

full_config # type: compas.robots.JointTrajectoryPoint
robot_11.send(rrc.MoveToJoints.from_configuration(full_config))
robot_12.send(rrc.MoveToJoints.from_configuration(full_config))
robot_21.send(rrc.MoveToJoints.from_configuration(full_config))
robot_22.send(rrc.MoveToJoints.from_configuration(full_config))

• Add continuous integration to build RRC in Github Actions
• Add rrc to Zenodo to have a citable DOI
• Add pip/conda badges
• Reword the Installation section
• Check if compas_rrc_start repo is already published otherwise remove from README.rst.
• Add link to documentation website on Github repo
• New docker image needed?

Summary

As a user of the library, I want to have a __version__ attribute so that I can track errors and post them accordingly in here.

Details

Describe the feature and the current behavior/state

Now:

>>> import compas_rrc
>>> compas_rrc.__version__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'compas_rrc' has no attribute '__version__'

How it should look like:

>>> import compas_rrc
>>> compas_rrc.__version__
1.0.0

Allow to easily convert back and forth between compas.robots.Configuration and compas_rrc.RobotJoints/ExternalAxes, taking care of the unit change (deg/rad).

Summary

As a [user], I want [to be able to stop motion tasks and flush the buffer] so that [we can stop motion by code, not only from TP].

Details

Describe the feature and the current behavior/state
I often send multiple rrc.MoveToJoints for a trajectories that have multiple points. I also have to send enough points to the ABB buffer to ensure smooth motion (acc/deacc). However we cannot easily stop the motion from code and flush the buffer.

Describe alternatives you've considered

At the moment if we want to stop and flush buffer, we can only press the Stop button on TP and are forced to PPtoMain . This is quite messy because funcing in my code may be waiting for a future that will never arrive and stuck in a for-ever loop.

Will this change the current API? How?
new feature

Are you willing to contribute it?
No

Describe in a few sentences a summary of what the problem is.

Expected Result

welcome result, connection established

Actual Result

(rrc_lab) C:\Users\arizai\Documents\Projects\algorithmic_details>C:/Users/arizai/Anaconda3/envs/rrc_lab/python.exe c:/Users/arizai/Documents/Pro
[docker_compose.txt](https://github.com/compas-rrc/compas_rrc/files/11099758/docker_compose.txt)
jects/algorithmic_details/src/algorithmic_details/waam/rrc_welcome.py
Connected.
Traceback (most recent call last):
  File "c:/Users/arizai/Documents/Projects/algorithmic_details/src/algorithmic_details/waam/rrc_welcome.py", line 9, in <module>
    abb.send_and_wait(rrc.PrintText('Welcome to COMPAS_RRC'))
  File "C:\Users\arizai\Anaconda3\envs\rrc_lab\lib\site-packages\compas_rrc\client.py", line 253, in send_and_wait  
    future = self.send(instruction)
  File "C:\Users\arizai\Anaconda3\envs\rrc_lab\lib\site-packages\compas_rrc\client.py", line 203, in send
    self.ensure_protocol_version()
  File "C:\Users\arizai\Anaconda3\envs\rrc_lab\lib\site-packages\compas_rrc\client.py", line 146, in ensure_protocol_version
    raise Exception('Protocol version mismatch. Server={}, Client={}'.format(self._server_protocol_check['version'], CLIENT_PROTOCOL_VERSION))
Exception: Protocol version mismatch. Server=None, Client=2

Reproduction Steps

Provide a reproducible test case that is the bare minimum necessary to generate the problem.

import compas_rrc as rrc

ros = rrc.RosClient()
ros.run()

abb = rrc.AbbClient(ros, '/rob1')
print('Connected.')

abb.send_and_wait(rrc.PrintText('Welcome to COMPAS_RRC'))

ros.close()

System Information

Win 10 64-bit
Python 3.8.8
compas_rrc 1.1.0
Robot C31_R31
Attached the docker_compose.yml I am running
docker_compose.txt

the docker_compose attached here that I am running is not the same as the one here, could this be it?