Hi all,
I’ve been working with compas_rrc and had two related questions:
Is it possible to achieve some form of concurrency or parallelism with compas_rrc?
More specifically, I would like to record the trajectory my robot follows while it’s moving. However, whenever I try to use getJoints() during a motion, the request only seems to be processed after the motion has completed. This is problematic because if I’m commanding the robot to move to a specified frame or joint configuration, I already know the start and end states, what I really want is the path it takes in between.
Is there any way to access joint states (or TCP poses) in real time during motion?
Collision-free planning in RobotStudio via compas_rrc
For motion planning, I’ve been using MoveIt via compas_fab to build the collision scene and generate paths. However, I’ve noticed that the paths from MoveIt can sometimes be overly complex or inefficient. Is there any way to access or trigger RobotStudio’s built-in collision-free path planner directly through compas_rrc?
Any guidance or ideas would be very much appreciated!
Yes, there’s a few options. a) use the webservice branch of compas_rrc that adds a new “channel” to the robot controller, with it, you can retrieve info like current joints (and many more things) independently of the RAPID execution pointer. b) accessing the webservices directly might be an alternative if you don’t want to use non-released compas_rrc versions from a branch, c) maybe @fleischp has other ideas, perhaps using the Execution Level?
Thanks for the quick reply!
I wasn’t aware of the web services interface, that’s really helpful to know. I’ll look into using it directly, since I assume the branch of compas_rrc might be subject to changes and the API may not be stable long term.
Yes, using the Execution Levelin combination could definitely be a viable option — but only together with a custom instruction and the send_and_subscribe method. However, this would need to be tested internally first. Could you explain your application in a bit more detail? That would help me better understand whether and how this could be implemented.
Currently, I don’t see a direct solution, but I’m in close contact with ABB, and as soon as I understand the situation better, we’ll consider whether and how this could be helpful for our users.
In general, we aim to further develop the integration of RWS (Robot Web Services) so that it is easily accessible to all our users. We’re doing our best to push this forward as quickly as possible — but we also need to prioritize in order to support our users effectively.
Right now, our main focus is on user support and documentation (Priority 1). In parallel, we’re actively working on the new compas_rrc_abb repository, which we plan to release soon.
Hi,
Thanks for the reply, I will also look into send_and_subscribe then.
Regarding my application: I want the robot to operate in an environment where a human operator might be present. For safety, I need to monitor the robot’s position continuously during movement, which currently isn’t possible. With real-time position data and external cameras, I could detect when the end effector gets too close to the operator and trigger a stop and reset. In general, I think being able to also monitor the state of the other signals while a motion is being executed would be a very useful feature.
Hi,
I have to bring up an important issue here: it is not really safe to ensure human safety at the application layer, this should be enforced at a lower level. For example, directly hooking up your proximity sensing to emergency interruptions at the controller level itself.