compas-rrc / compas_rrc Goto Github PK
View Code? Open in Web Editor NEWOnline control for ABB robots over a simple-to-use Python interface.
Home Page: https://compas-rrc.github.io/compas_rrc/
License: MIT License
Online control for ABB robots over a simple-to-use Python interface.
Home Page: https://compas-rrc.github.io/compas_rrc/
License: MIT License
Describe in a few sentences a summary of what the problem is.
welcome result, connection established
(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
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()
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?
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.
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
As a compas_rrc user, I would like to take advantage of the tool relative motion (RAPID RelTool)
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.
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
.
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))
Installation
sectionREADME.rst
.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
.
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.
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.
Python Exception raised
Nothing, script gets stuck.
Parse a feedback incorrectly e.g. string_values[0]
when string_values
is an empty list
Operating System name and version, Python version, etc.
compas_rrc v 1.1.0
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]
.
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
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.
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.
A error message quickly flashed on the TP, it is viewable from Robot Studio.
Just try print a long text with rrc.PrintText
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
.
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())
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
.
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.
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
.
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
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 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
.
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
Allow to easily convert back and forth between compas.robots.Configuration
and compas_rrc.RobotJoints/ExternalAxes
, taking care of the unit change (deg/rad).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.