rationale behind jump threshold?

[rhaschke]

Can somebody explain me the rationale behind RobotState::testJointSpaceJump()?
Obviously the goal is to avoid joint-state jumps. However, I don't get why it computes the mean joint-state change over the whole trajectory and uses jump_threshold as a scaling factor, such that:
[single joint state change] < jump_threshold * [mean joint state change]

Wouldn't it be more reasonable to specify an absolute joint-space jump threshold?
In this case, one could even try to sample the Cartesian trajectory more densely to maintain the threshold...

I stumbled over this, because my generated joint-space trajectory is non-uniform (both in joint and Cartesian space). Thus the averaging process tries to find the mean of a multi-modal distribution...

[gavanderhoorn]

I think we discussed this before, and iirc, no one really knows (any more).

Same sort of confusion about the additional point(s) that get added to the trajectory.

[rhaschke]

Shouldn't we change it then?

[gavanderhoorn]

I believe that would make sense, yes. computeCartesianPath(..) has always been a bit of an afterthought and hasn't gotten much attention. If we can find a sane(r) way to get similar functionality then we should improve it.

(I tried to find the discussion(s) I seem to remember, but I can't. Maybe they only happened in my mind ..)

[davetcoleman]

@mlautman

[jrgnicho]

Perhaps using a max jump threshold that is a function of the joint's max speed might be more appropriate.

[mlautman]

+1 for absolute joint-space jump threshold. I implemented an equivalent computeCartesianPath function that uses Descartes under the hood and found that an absolute joint-space jump threshold was very helpful to ensure that the robot didn't flip joints mid trajectory.

[v4hn]

👎 to a fixed absolute joint-space jump threshold as a drop-in replacement for the current mechanism.
But the current approach is inherently flawed, I fully agree.

The factor was most likely added to account for different robot kinematics.
The absolute joint difference can be quite different between a 3dof and a 7dof arm.

If we want to have an absolute factor, we should imo also add an interpolation mechanism that attempts to fill in steps that are too big.

[mlautman]

I agree that an absolute joint space jump threshold is an imperfect solution but it has certain properties that are nice: it's easy for users to understand and it's easy to implement although I'm not sure it's strictly better than the existing solution. I'm not sure what an interpolation mechanism that fills in steps would look like. @v4hn Can you elaborate?

[mlautman]

Upon re-reading through the implementation, jump_threshold is a terrible variable name because it implies absolute joint space jump but it acts as more of a scaling factor. Perhaps a variable name change to jump_threshold_factor would help reduce confusion.

[rhaschke]

If we want to have an absolute factor, we should imo also add an interpolation mechanism that attempts to fill in steps that are too big.

That's what I proposed. I will take care of this after all the deadlines.

Perhaps a variable name change to jump_threshold_factor would help reduce confusion.

Good suggestion. However, is this variable also exposed to any external (ROS) interface? In this case, it get's tricky. Such a variable name change should be scheduled only for Lunar or later.