Max joint position exceeded with panda robot

🛠 Done
Alban Laflaquiere

I tested planning for a Panda joint configuration that exceeds a joint limit (panda_joint2 going to 100 when its max position is supposed to be 1.7628).
The planner returned a trajectory that indeed reaches this out-of-bound value (see attached image).

6 months ago

Activity
Yahav changed status to 🛠 Done

3 months ago

Yahav

This issue is now fixed and will be available in the upcoming release!

0    3 months ago    Reply

Comment must be at least 20 characters.
Cancel

We appreciate your feedback.

Yahav changed status to 🤖 Working on it!

3 months ago

Yahav changed status to 💬 Open

3 months ago

Alban Laflaquiere

A quick check about the status of out-of-bounds joints.
Was the inner working of the optimizer modified to guarantee the joints don't go out of bounds?

0    3 months ago    Reply

Comment must be at least 20 characters.
Cancel

We appreciate your feedback.

Yahav

Hey Alban,
At the moment, if you provide an out-of-bound configuration manually, the planner will allow it (trusting the user). We have decided to change it so that the planner will always block those configurations, and we'll release it in the near future.

Best,
Yahav

0    3 months ago    Reply

Comment must be at least 20 characters.
Cancel

We appreciate your feedback.

Lars Berscheid

Hi Alban,

I assume that you are planning a motion to a goal position of 100.0 in joint2? If so, we are currently indeed not checking that it is outside its max_position.

I think this is a broader issue of validating user input, and when to warn or return an error instead of calculating a best possible solution. So far, I was trying to be forgiving for input violations that are easy to spot (e.g. for exceeding position limits), and throw an error for violations that are hard to detect (e.g. when planning to a goal velocity and goal acceleration that is only reachable by violating a velocity limit).

Now that I'm thinking about it, my approach seems to be a slippery slope and maybe we should just be strict (at least by default) and throw an error if a motion is not feasible.

Thanks for bringing this up!

Best,
Lars

0    6 months ago    Reply

Comment must be at least 20 characters.
Cancel

We appreciate your feedback.

Alban Laflaquiere

Hi Lars,

Thank for your explanation.

As a user, it would make sense to me that the planner throws an error if the goal is out of bound. When manually specifying the goal, one could assume the user is responsible for checking; but when the goal comes from another part of the system, all bets are off!

Still, I don't understand how the planner can generate a trajectory that goes out of bound. Are the joint limits treated as soft constraints with a very high --but not infinite-- penalty? Does that mean we don't have a 100% guarantee that the trajectory won't exceed the joints/vel/acc limits?

0    6 months ago    Reply

Comment must be at least 20 characters.
Cancel

We appreciate your feedback.

Alban Laflaquiere

Hi Lars,

Just checking, because I'm not sure if you get notified when I reply here.

0    5 months ago    Reply

Comment must be at least 20 characters.
Cancel

We appreciate your feedback.

One vote