On 06/19/2012 12:49 PM, Enea Scioni wrote:
> Maybe Path_RoundedComposite could be the most appropriate kdl
> trajectory generator in kdl suite
> http://people.mech.kuleuven.be/~rsmits/kdl/api/html/classKDL_1_1Path__Ro...
> <http://people.mech.kuleuven.be/%7Ersmits/kdl/api/html/classKDL_1_1Path__RoundedComposite.html>,
> but I am asking a confirm to Erwin...
Path_RoundedComposite can help you, but there are some remarks:
- it was originally designed to be used in 6D space (3
translations/rotations). It is still
usable for motion in the plane, but there is some overkill.

- It uses straight line segments which are rounded in the intermediate
points. In traditional industrial
manipulator robotics this is called "via points". Note: due to the
rounding these via points are not actually reached.

- It is suited to generate a smooth path between a small number of
points. It is especially suited to generate
paths between manually placed points, because it is very easy for the
human to predict the followed path.

- It is _not_ suited to generate a smooth path between a large number
of points, close to each other.

When points are to close to each other ( such that the rounding of
the next segment intersects the previous rounding), the methods
currently give back a planning error. Ideally this could be solved by
implementing a Path_Spline and a factory that can generate such a
spline from a sequence of points, but we did not find the time yet to
implement such thing.

>
> I'm generating "manually" the waypoints just to let this part ready
> when the points will be planned using navigation algorithms.
>
> Speaking about motion planning and navigation algorithms, as Herman
> said, several opensource implementations are already available.
> Probably the most in vogue is ompl library. Anyway (in my opinion)
> these methods are fine for "global" planning purpose, but they don't
> fit completely as trajectory generator.
>
> Maybe with a lookforward that help the platform modify it's speed
> before changing a lot its "direction" to avoid running off of torque
> and so go out from the planned trajectory. I don't know if it is
> possible...
>
>
> My point (and maybe your also!) is that these methods take in account
> only geometrical constraints (shortest path), few of them are (sub)
> time optimal, collisions free, but they don't take in account a
> tollerance to deviate from the original path in according with other
> possible constraints (if free space, of course). And this is more
> important in case of omnidirectional platforms, because reach a goal
> pose can be done with several different movements, and some of them
> would be sub-optimal respect different points of view: traveling time,
> velocities/accelerations, energy efficiency and so on...
>
> In conclusion, between motion planning and a controller for a mobile
> platform, there is still main step (trajectory generators) which has
> to answer to the questions: how am I going to interpolate my
> waypoints/viapoints? How much can I deviate from the original path?
> and in according to which criterias? (of course, it depends about the
> specification of the task...)
> In this direction, there's still some work to do and I don't think KDL
> will help you (yet!).
>
> Just a short note: I am taking this occasion to share this, hoping to
> receive feedbacks...especially negative feedbacks! :-)
>
> - Enea
>
>
>

On Tue, 19 Jun 2012, Enea Scioni wrote:

> Maybe Path_RoundedComposite could be the most appropriate kdl trajectory
> generator in kdl suite
> http://people.mech.kuleuven.be/~rsmits/kdl/api/html/classKDL_1_1Path__Ro...,
> but I am asking a confirm to Erwin...
>
> I'm generating "manually" the waypoints just to let this part ready
>> when the points will be planned using navigation algorithms.
>
> Speaking about motion planning and navigation algorithms, as Herman said,
> several opensource implementations are already available. Probably the most
> in vogue is ompl library. Anyway (in my opinion) these methods are fine for
> "global" planning purpose, but they don't fit completely as trajectory
> generator.

This becomes interesting... I feel that both your remarks make a lot of
sense, to differentiate the "pure planning" from the "online,
control-oriented trajectory generation". But I can not yet point to the
essential differences/complementarities exactly.

> Maybe with a lookforward that help the platform modify it's speed
>> before changing a lot its "direction" to avoid running off of torque
>> and so go out from the planned trajectory. I don't know if it is
>> possible...
>
> My point (and maybe your also!) is that these methods take in account only
> geometrical constraints (shortest path), few of them are (sub) time
> optimal, collisions free, but they don't take in account a tollerance to
> deviate from the original path in according with other possible constraints
> (if free space, of course).

Agreed! (Of course, since I am advocating this approach to motion
specification (and sensing and control) since quite some time already :-)

> And this is more important in case of
> omnidirectional platforms, because reach a goal pose can be done with
> several different movements, and some of them would be sub-optimal respect
> different points of view: traveling time, velocities/accelerations, energy
> efficiency and so on...
>
> In conclusion, between motion planning and a controller for a mobile
> platform, there is still main step (trajectory generators) which has to
> answer to the questions: how am I going to interpolate my
> waypoints/viapoints?

With the addition: "Taking into account the _platform specific_ (dynamic)
properties of the robot."

> How much can I deviate from the original path? and in
> according to which criterias? (of course, it depends about the
> specification of the task...)
> In this direction, there's still some work to do and I don't think KDL will
> help you (yet!).
>
> Just a short note: I am taking this occasion to share this, hoping to
> receive feedbacks...especially negative feedbacks! :-)
>
> - Enea

Herman