Look into Descartes planner

[kirstyellis]

[kirstyellis]

So, it seems as though Descartes needs to be provided with a set of waypoints for the end effector. it does not create any new way points from this input, it purely finds sensible joint angles which allow the end effector to follow this path. Apparently it performs collision checking 'Key capabilities of Descartes include, path optimization, collision avoidance, near instantaneous re-planning, and a plug-in architecture' but I passed two waypoints, one either side of a box collision object, and the arm passed straight through the box, surprisingly it executed the trajectory without any collisions errors!

[kirstyellis]

This should also be noted; 'Offline Planning: Similar to MoveIt, but different than other planners, Descartes is primarily focused on offline or sense/plan/act applications. Real-time planning is not a feature of Descartes.'

[ugocupcic]

Might be good to ping the Descartes guys an email?

Sent from my iPhone, excuse the brevity.

On 17 May 2016, at 10:46, kirstyellis notifications@github.com wrote:

So, it seems as though Descartes needs to be provided with a set of waypoints for the end effector. it does not create any new way points from this input, it purely finds sensible joint angles which allow the end effector to follow this path. Apparently it performs collision checking 'Key capabilities of Descartes include, path optimization, collision avoidance, near instantaneous re-planning, and a plug-in architecture' but I passed two waypoints, one either side of a box collision object, and the arm passed straight through the box, surprisingly it executed the trajectory without any collisions errors!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

---

Shadow Robot Company Ltd.
251 Liverpool Road, N1 1LX, UK

Registered Number 3308007 (England & Wales)

[kirstyellis]

Do you think it is worth even investigating more? It seems that is is designed for a known end effector trajectory, for like, 'blending, painting, machining, sanding, sealing, and welding', not as we want, planning around objects

[ugocupcic]

Ah I see. My bad. Definitely not what I understood when looking at it !

On 17 May 2016 at 11:09, kirstyellis notifications@github.com wrote:

Do you think it is worth even investigating more? It seems that is is
designed for a known end effector trajectory, for like, 'blending,
painting, machining, sanding, sealing, and welding', not as we want,
planning around objects

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#163 (comment)

Ugo Cupcic_Chief Technical Architect_+44 20 7700 2487

---

Shadow Robot Company Ltd.
251 Liverpool Road, N1 1LX, UK

Registered Number 3308007 (England & Wales)

[kirstyellis]

'By contrast, many industrial applications must follow a pre-defined Cartesian path, where the path in between matters as well. Some common examples of this are blending, painting, machining, sanding, sealing, and welding. Unfortunately, solving the Cartesian path planning problem by simply applying an inverse kinematics solution results in an artificially limited solution set that doesn't take advantage of the process flexibility/tolerance allowances. In reality, Cartesian paths are typically semi-constrained. For example, in a machining application a five degree-of-freedom (DOF) path is required, where the sixth DOF, the orientation about the tool, is not defined (doesn't matter). Joint trajectory planners that fail to take advantage of these open constraints, such as inverse kinematics (IK) based planners, limit the likelihood of finding a valid solution, even though one could exist in the semi-constrained space. The Descartes planner library was initiated in Summer 2014 with NIST and ROS-Industrial Consortium Americas support to address semi-constrained Cartesian industrial processes. Descartes has already been demonstrated in a robotic routing and blending/sanding applications.'