Recommendations for "position only" robots

[gavanderhoorn]

This is not really an issue with Ruckig per se, but more a usage question. Seeing as you don't have discussions enabled on this repository, I'm posting it as an issue.

Many (industrial) robots do not provide any state output except their current position, and sometimes even that with (quite) some delay.

What would be your recommendation for Ruckig usage with such robots: simply use derivatives to obtain velocity and acceleration, using full loop-back and 'forwarding' the output.new_position to the real system, a hybrid, something else?

I'd be interested to know what you feel would give the best performance -- or perhaps, less problems :)

[pantor]

Hi @gavanderhoorn,

I'm sure that I didn't fully get your question. When using position control, robots should (obviously) be controlled by the output.new_position signal. As long as the robot is able to follow the position, it is safe to assume that it will follow the velocity and acceleration with great precision too. So during a position-controlled trajectory, you therefore know the desired velocity and acceleration from the same output state.

So the situation only becomes tricky when starting a new trajectory from non-zero velocity or acceleration, and you know that the (old) desired and actual values differ. I think there is no easy fix for that, but I'm not sure whether this is relevant to your question?

using full loop-back and 'forwarding' the output.new_position to the real system

What do you mean here?

[gavanderhoorn]

As long as the robot is able to follow the position, it is safe to assume that it will follow the velocity and acceleration with great precision too.

Agreed, but I'm currently seeing OEM controller errors which I believe are due to Ruckig and the real hw diverging too much.

This could be due to limits set too 'optimistic', but I'm trying to make sure I'm not doing anything stupid before I start to doubt those -- as they're coming from the OEM.

Ideally I'd like to provide Ruckig with as much state as possible coming from the robot itself instead of looping-back what Ruckig outputs. Especially for non-zero-state situations as you already mentioned that would seem to be advantageous.

That is sort-of the context in which I posted my question. From your "I think there is no easy fix for that" it sounds like you're not necessarily suggesting to just use finite differencing.

using full loop-back and 'forwarding' the output.new_position to the real system

What do you mean here?

this is basically me trying to say:

When using position control, robots should (obviously) be controlled by the output.new_position signal.

[pantor]

Ah, I see your point. Ruckig should definitely be used in a full "loop-back" manner like this:

while (ruckig.update(input, output) == Result::Working) {
  robot.set_position(output.new_position);

  // Should be copied directly to your motion generator:
  input.current_position = output.new_position;
  input.current_velocity = output.new_velocity;
  input.current_acceleration = output.new_acceleration;
}

Otherwise, Ruckig will replan a trajectory each time step. If the robot moves along a time-optimal trajectory, infinitesimal noise can change the whole trajectory unexpectedly. Btw, you can find the code above in my motion generator for a Franka robot here.

If the robot is not able to follow the trajectory, it would be obvious the check for the kinematic limits first. If they are within the given limits by the robot, the real-time communication is also quite error-prone. Are you using Ruckig for Cartesian space or joint space control? Which robot are you using?

[gavanderhoorn]

the real-time communication is also quite error-prone.

I'll check this aspect again, but I've worked with RT systems for quite some time and I believe I've configured things correctly there. The controller would immediately punish me as well if I don't make the deadlines, and it's happy, so I'm happy.

Are you using Ruckig for Cartesian space or joint space control?

Joint for now. Going to Cartesian later.

Which robot are you using?

I'm using Ruckig with a Fanuc R-30iB+ controller. The robot doesn't really matter, as the interface is manipulator-agnostic.

[gavanderhoorn]

I'll close this, as I believe we've discussed my primary question.

I'll investigate the limit violations I'm experiencing some more. Depending on the outcome, I may open another issue.

Thanks for comments so far @pantor :+1: