Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look into Descartes planner #163

Open
kirstyellis opened this issue May 12, 2016 · 6 comments
Open

Look into Descartes planner #163

kirstyellis opened this issue May 12, 2016 · 6 comments
Assignees

Comments

@kirstyellis
Copy link
Contributor

No description provided.

@kirstyellis
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

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 [email protected] 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
Copy link
Contributor Author

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
Copy link
Contributor

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

On 17 May 2016 at 11:09, kirstyellis [email protected] 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
Copy link
Contributor Author

'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.'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants