ros-industrial / abb_driver Goto Github PK

I'm following the tutorial here to simulate a robot with RobotStudio. It's going fairly well until this step:

Before continuing in RobotStudio, you need to put the RAPID files of the ROS driver on the controller of the created arm.

    1. Go to <documents_directory>\RobotStudio\Systems and select the folder corresponding to the name of your station. 

Well, \Systems is empty.

I haven't manually saved a system yet. I did save a "station" that I created with my robot, but it's in a different folder and I don't think that's what I need at this step. I suspect the wiki is just outdated and maybe I shouldn't even be using this package anymore.

Tracking this here for abb_driver.

Connects: ros-industrial/ros_industrial_issues#27.

Hi,
I have the abb_drivers running a single ABB IRB 120 and I'm trying to get both of them online. There is a footnote in the installServer tutorial saying "For multi-robot controllers, specify the desired robot (e.g. rob1) for each task" but that doesn't make new rostopics for the different robots to communicate through. How do I make multiple robots work with this driver? I don't see a clear place where I can change the topic names in ROS so that the robots can be commanded.

I have tried renaming all the files Rob1/2 at the end and updating the inside, but it kind of blows up on me very quickly and doesn't seem like it will work on the ROS side.

Thanks!

Since there is no solution for direct serial communication of the 'abb_driver' with older ABB controllers which dont support a tcp connection i want to find a solution to publish a trajectory in ROS to an "arduino node" via TCP (Ethernet Shield) and redirect it via serial RS232 connection to the S4 Controller where I can extract the points in a loop to let the robot executing them.

Hardware:

• ABB IRB 4400 S4 Controller
• Arduino Mega2560 with Ethernet Shield and RS232 Module connected to Serial3

Here is the basic scheme on how i would like to solve the problem:

1. Use the ROS-Indutrial support for ABB IRB 4400
2. Streaming unidirectional for the beginning (is it possible to use the streaming interface for that?)
3. Fit the datastream on the Arduino for RAPID if necessary
4. Redirect it to serial port
5. Write a loop in RAPID to read the Path.
6. If possible publish the final position of the robot back to ROS.

I can already publish a message via tcp by using 'rosserial_python' to the serial output.
Does anyone have some recomendations on how to go on especially on ROS side.

My proposal is to add a a new function to the ROS_motion.mod task that would check the first point of the trajectory against the current state of the robot (essentially reuse the is_near function). If the first point is outside some tolerance of the current state, an error message would be written to a log (using ErrWrite) and the trajectory would be aborted (abort_trajectory).

Currently if the first point of the trajectory fails the is_near check, a slow (10s duration) movement is executed to the first point of the trajectory. If the robot's current state is only slightly out of tolerance the robot motion is imperceptible and it appears as if there is just a long time delay associated with sending trajectories to the robot (see ros-industrial/abb#142 for some history).

Hello !
Thanks for the driver. I managed to make it work for my irb120. I send custom trajectories on the "joint_trajectory_action" topic of ROS and the robot moves accordingly.

Now, I would like to add a new topic, which would be something like "/gripper". If I would publish a value of 1 on that topic, this would set a variable to 1 in the rapid code that would close my gripper (and if I publish 0, it would open it).

Could you please help me with regard to what I have to modify, both in the rapid files and on the ROS side, to make this work ?

Thanks a lot!
Regards

Louis

I'm using ABB experimental package with RobotStudio and ROS-kinetic. I followed these tutorials to configure ROS and an ABB IRB1200 robot in RobotStudio to work together. When launching the moveit_planning_execution.launch in a terminal that's shown below.

$ roslaunch abb_irb1200_5_90_moveit_config moveit_planing_execution.launch sim:=false robot_ip:=192.168.1.1

I get the following error when I start plan and execute :

[ERROR] [1610335075.542277098]: Controller is taking too long to execute trajectory (the expected upper bound for the trajectory execution was 3.590049 seconds). Stopping trajectory.

I tried 2 things in trajectory_execution.launch.xml without success:

1. Edit the following value from 1.2 to 3.2:
   <param name="trajectory_execution/allowed_execution_duration_scaling" value="3.2"/> <!-- default 1.2 -->

The result is it takes a longer time to show the same error.

2. Add the following parameter:
   <param name="trajectory_execution/execution_duration_monitoring" value="false"/>

The result is it took too long to execute without showing any output on the terminal, I have waited for 3 hours before closing it.

What am I doing wrong?

Please release for ROS Noetic.

The rapid code contains the magic number of max 100 trajectory points:

We have incremented this number when using this driver but it would be interesting to know of course if there are limits to array size in RAPID or hardware wise?

AFAIR points beyond 100 are skipped with this error message:

Triggered by #3: multi-controller and multi-group setups aren't very complex, but we should document how to do that.

I have studies this driver and I have not yet confirmed if it subscribes to the robot_status topic of type industrial_msgs/RobotStatus. Can someone please confirm for me if this is the case? I would like to be absolutely sure before I run anything on the real robot.

The current installation instructions are spread out through multiple wiki pages, and repos, and the fact that are detached from the code means they are out-of-sync. The usage instructions are not really documented anywhere official afaik.

I created PR ros-industrial/abb#161 to move the existing wiki content here, and added the missing stuff.

There are a number of forks adding functionality to or fixing bugs in abb_driver. These should be reintegrated where possible.

Candidates:

• rtkg/yumi
• ethz-asl/yumi