fzi-forschungszentrum-informatik / cartesian_ros_control Goto Github PK

Hello

I found a little bug in the Action Server when you don't have the SpeedSlider (at the Teachpanel) at 100%.

100%, Move Duration 5s:
-> The robot moves 5s to the target position
-> I get for 5 seconds a feedback from the Action Server

50%, Move Duration 5s:
-> The robot moves 10s to the target position
-> I get for 5 seconds a feedback from the Action Server

So the Action Server don't include the SpeedSlider

Currently, the passthrough controllers send the trajectory and when the designated time is up, it is checked whether the robot is at its final position or not (within specified limits).

I think that we should not use such a fire&forget&check interface but rather wait for the underlying hardware to signal completion.

E.g. for the ur_robot_driver we should send something back when reaching this line.

As this will introduce a potential endless wait, we should implement a strategy to either read keepalive signals from the hardware or add a user-specified timeout that we can use ontop of the trajectory time to declare a goal `LOST´.

Hello

First of all thank you for the controllers!

I want to report a little issue with the pass_through_controller that occurs when I cancel my goals at the Controller. I get the error:

[ERROR] [1618999819.211363]: Received comm state PREEMPTING when in simple state DONE with SimpleActionClient in NS /forward_cartesian_traj_controller/follow_cartesian_trajectory

I did some testing and the error occurs always at the command self.client.cancel_goal() when I already canceled a goal.

Example:
I send a goal and the arm is moving to the target destination. While it's moving I cancel the goal and the arm stops. And if I send the cancel command again, I get always the error. The error occurs only withcancel_goal() and not with cancel_all_goals().

Best regards.

After setting up and testing pass_through controllers we experienced some weird behaviour through MoveIt and also while executing our prerecorded trajectory. The issue is that the sequence of the joints which is defined in the trajectory is not taken into account. The sequence of joint names in our prerecorded trajectory was following: elbow_joint, shoulder_pan_joint, shoulder_lift_joint, wrist1, wrist2, wrist3 and the values of positions in respective order.

It seems that the controller takes the first value assuming that it is the shoulder_pan_joint, but in reality, in this case, this was elbow_joint. And this of course explained the weird behaviour.

After manually modifying position values so that the shoulder_pan_joint comes first, the trajectory was executed correctly. We also tried the same setup with scaled_pos_joint_traj_controller, where joint names are taken into account.

The current implementation of Cartesian command handles allows to run joint-based and Cartesian-based ROS-controllers in parallel (see e.g. here). While technically they do not claim the same resources and hence could run in parallel regarding the ROS-Control philosophy, some drivers go for an either-or-approach.

Let's rethink resource handling for these cases.

When using tolerances with the passthrough controllers, the controller crashes with an assertion_error if the RobotHW doesn't provide a full error state including accelerations and efforts.

e.g. when using with the current implementation inside the ur_robot_driver the joint error looks like this:

positions[]
  positions[0]: 0
  positions[1]: 0
  positions[2]: 0
  positions[3]: 0
  positions[4]: 0
  positions[5]: 0
velocities[]
  velocities[0]: 0
  velocities[1]: 0
  velocities[2]: 0
  velocities[3]: 0
  velocities[4]: 0
  velocities[5]: 0
accelerations[]
effort[]

That they are all exactly 0 seems a bit suspicious, but that's a separate topic. However, that accelerations and effort are empty leads to the mentioned assertion_error from

Is that on purpose and the implementation in ur_robot_driver should be changed and if so, why is acceleration required, but not effort? This seems a bit arbitrary to me.

Edit: They are all 0 as I am using URSim for testing, where target == actual.

Hello,

I am considering using this controller because I would like to send a trajectory to the UR 10e and then change the speed during the execution from a ROS node.

I saw that you say that "Speed-scale trajectories" is available to "Robots with new interfaces". Does the UR 10e fall under that category? How can I check if the UR 10e does? (My system is Ubuntu 16 with kinetic. Don't know if the driver makes a difference, but I am currently using this one: https://github.com/UniversalRobots/Universal_Robots_ROS_Driver)

A more general question, because I have mostly used moveit so far: How do I best get started with the cartesian_ros_control?

Thanks!

Daniel