You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
(4) |
Feb
(6) |
Mar
(16) |
Apr
(9) |
May
(6) |
Jun
(2) |
Jul
|
Aug
(14) |
Sep
(10) |
Oct
(12) |
Nov
(15) |
Dec
(3) |
2012 |
Jan
(15) |
Feb
(9) |
Mar
(10) |
Apr
(19) |
May
(20) |
Jun
(14) |
Jul
(1) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(1) |
Dec
(2) |
2013 |
Jan
(13) |
Feb
(8) |
Mar
(11) |
Apr
(20) |
May
(11) |
Jun
(11) |
Jul
(12) |
Aug
(3) |
Sep
|
Oct
(7) |
Nov
(9) |
Dec
(1) |
2014 |
Jan
(1) |
Feb
(4) |
Mar
(13) |
Apr
(5) |
May
(10) |
Jun
(27) |
Jul
(17) |
Aug
|
Sep
(8) |
Oct
(12) |
Nov
(19) |
Dec
(31) |
2015 |
Jan
(21) |
Feb
(11) |
Mar
(15) |
Apr
(1) |
May
(15) |
Jun
(11) |
Jul
(23) |
Aug
(6) |
Sep
(28) |
Oct
(17) |
Nov
(18) |
Dec
(1) |
2016 |
Jan
(14) |
Feb
(42) |
Mar
(20) |
Apr
(10) |
May
(11) |
Jun
(3) |
Jul
(9) |
Aug
(6) |
Sep
(6) |
Oct
(8) |
Nov
|
Dec
(1) |
2017 |
Jan
(3) |
Feb
(1) |
Mar
(2) |
Apr
(6) |
May
(11) |
Jun
(5) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
(1) |
Dec
(8) |
2018 |
Jan
(8) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(3) |
Jun
(8) |
Jul
(21) |
Aug
(7) |
Sep
(12) |
Oct
(4) |
Nov
(3) |
Dec
(2) |
2019 |
Jan
(9) |
Feb
(7) |
Mar
(5) |
Apr
(1) |
May
(4) |
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(2) |
Oct
(5) |
Nov
(2) |
Dec
(5) |
2020 |
Jan
(5) |
Feb
(5) |
Mar
(9) |
Apr
|
May
(2) |
Jun
(10) |
Jul
(7) |
Aug
(1) |
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
2021 |
Jan
(4) |
Feb
(5) |
Mar
(2) |
Apr
(5) |
May
(1) |
Jun
|
Jul
(2) |
Aug
(13) |
Sep
(5) |
Oct
(5) |
Nov
(1) |
Dec
(1) |
2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
(1) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(1) |
2025 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Patrick B. <bee...@gm...> - 2020-06-24 14:36:13
|
Thanks. I know it is the case that some other planners (RRT for example) will do this as well. Basically, I think many of my issues could/should be improved if the optimizing planners had a mode switch that would allow them to return immediately upon finding an answer. That is, if I've already built out a roadmap for PRM*, there's no need to keep optimizing at some point. I want to flip a switch that says just give me an answer. Similarly, another "optimization" to PRMs and their derivatives in general would be to always add a graph/roadmap edge between any start/goal pair fed into the planner (for PRM this would require collision checking, but for Lazy would be evaluated later) This could/would create "super-highways" in the node graph which might be beneficial long term, but also when paired with the mode I mention above would basically allow many planning problems to return back a solution immediately if the start/goal is the shortest known solution. I realize that the two things above don't exist, and that the second item is more of a "Research" item that would require evaluation to prove out my hypothesis. But having a mode switch to turn off "exploration" for some of the OMPL planners just seems like a practical thing to have. Otherwise, these planners that run for the full timeout become largely unusable in time-sensitive contexts. On Wed, Jun 24, 2020 at 9:14 AM Jonathan Gammell <ga...@ro...> wrote: > > Message: 1 > > Date: Tue, 23 Jun 2020 10:01:21 -0500 > > From: Patrick Beeson <bee...@gm...> > > To: omp...@li... > > Subject: [ompl-users] Straight line (in config space) path? > > Message-ID: > > <CAEt3jgKmkb4JJOmbNT= > 5jA...@ma...> > > Content-Type: text/plain; charset="utf-8" > > > > In using OMPL via MoveIt!, I'm noticing that OMPL often does a whole lot > of > > work to plan even when there's a straight line in configuration space > from > > the start to the goal. So it'll find a solution of let's say 6-10 points > > then that gets shortened down to 2, the start and goal. > > > > In asking about just checking the 2 point plan of start/goal for > collisions > > in MoveIt! ( > > > https://answers.ros.org/question/355617/can-moveit-first-check-shortest-path-before-planning/ > ), > > the short answer was "your planner needs to support it". So, now I'm > > asking here, does OMPL support this functionality as an option prior to > > running plans, and is this exposed via the MoveIt! API into OMPL? If so, > > I'm missing where this is documented. If not, is there a viable solution > > to do this in OMPL? > > Hi Patrick, > > I am not personally aware of such a feature in OMPL in general, but some > specific planners do behave this way as a result of their design. I'm > specifically thinking of planners that use heuristics to inform their > search in order of potential solution quality, such as BIT* and AIT*. > > You can find them in OMPL under geometric/planners/informedtrees/ > > Full disclosure, these are planners I've worked on. They haven't been > tested exhaustively with MoveIt!, but I believe they do work with it. > > Best, > Jon > > -- > Jonathan Gammell, Ph.D. > > Departmental Lecturer in Robotics > Estimation, Search, and Planning (ESP) Research Group > Oxford Robotics Institute (ORI) > Department of Engineering Science > University of Oxford > office: +44 1865 613082 > skype: jdgammell > https://robotic-esp.com/gammell > > > > _______________________________________________ > ompl-users mailing list > omp...@li... > https://lists.sourceforge.net/lists/listinfo/ompl-users > |
From: Jonathan G. <ga...@ro...> - 2020-06-24 13:27:43
|
> Message: 1 > Date: Tue, 23 Jun 2020 10:01:21 -0500 > From: Patrick Beeson <bee...@gm...> > To: omp...@li... > Subject: [ompl-users] Straight line (in config space) path? > Message-ID: > <CAEt3jgKmkb4JJOmbNT=5jA...@ma...> > Content-Type: text/plain; charset="utf-8" > > In using OMPL via MoveIt!, I'm noticing that OMPL often does a whole lot of > work to plan even when there's a straight line in configuration space from > the start to the goal. So it'll find a solution of let's say 6-10 points > then that gets shortened down to 2, the start and goal. > > In asking about just checking the 2 point plan of start/goal for collisions > in MoveIt! ( > https://answers.ros.org/question/355617/can-moveit-first-check-shortest-path-before-planning/), > the short answer was "your planner needs to support it". So, now I'm > asking here, does OMPL support this functionality as an option prior to > running plans, and is this exposed via the MoveIt! API into OMPL? If so, > I'm missing where this is documented. If not, is there a viable solution > to do this in OMPL? Hi Patrick, I am not personally aware of such a feature in OMPL in general, but some specific planners do behave this way as a result of their design. I'm specifically thinking of planners that use heuristics to inform their search in order of potential solution quality, such as BIT* and AIT*. You can find them in OMPL under geometric/planners/informedtrees/ Full disclosure, these are planners I've worked on. They haven't been tested exhaustively with MoveIt!, but I believe they do work with it. Best, Jon -- Jonathan Gammell, Ph.D. Departmental Lecturer in Robotics Estimation, Search, and Planning (ESP) Research Group Oxford Robotics Institute (ORI) Department of Engineering Science University of Oxford office: +44 1865 613082 skype: jdgammell https://robotic-esp.com/gammell |
From: Patrick B. <bee...@gm...> - 2020-06-23 15:02:09
|
In using OMPL via MoveIt!, I'm noticing that OMPL often does a whole lot of work to plan even when there's a straight line in configuration space from the start to the goal. So it'll find a solution of let's say 6-10 points then that gets shortened down to 2, the start and goal. In asking about just checking the 2 point plan of start/goal for collisions in MoveIt! ( https://answers.ros.org/question/355617/can-moveit-first-check-shortest-path-before-planning/), the short answer was "your planner needs to support it". So, now I'm asking here, does OMPL support this functionality as an option prior to running plans, and is this exposed via the MoveIt! API into OMPL? If so, I'm missing where this is documented. If not, is there a viable solution to do this in OMPL? |
From: Mark M. <mm...@ri...> - 2020-06-11 19:09:52
|
Hadar, If you don’t need the retrieve/repair capability of Thunder, then you can just use regular PRM as your planner. When you are constructing the planner instance, you can pass in a PlannerData object containing a roadmap/tree from a previous planning attempt. The PlannerData can be stored on disk using the PlannerDataStorage class. Also, if you repeatedly call PRM::solve without calling clear, it will also reuse the previous constructed roadmap. Best, Mark > On Jun 11, 2020, at 4:00 AM, hadar sinvani <had...@gm...> wrote: > > Hi, > > How can I save the PRM RoadMap graph, load it again in an attempt of solving a new query? > > I would like to use the constructed road map, find a path from scratch without using retrieve-repair module and past solutions. > > I tried to use the Thunder framework: > > ot::Thunder expPlanner(setup.getSpaceInformation()); > expPlanner.setFilePath("thunder.db"); > > //attempt to solve the problem > if (setup.solve(20)) > { > ... > } > expPlanner.doPostProcessing(); > (setup.getPlanner()->as<og::PRM>())->clearQuery(); > > // create new start and goal > ob::ScopedState<> start(setup.getStateSpace()); > start[0]=... > start[1]=... > ob::ScopedState<> goal(setup.getStateSpace()); > goal[0]=... > goal[1]=... > > expPlanner.setStartAndGoalStates(start, goal); > expPlanner.setPlanner(std::make_shared<og::PRM>(setup.getSpaceInformation())); > //plan from SCRATCH and disable using previous plan > expPlanner.enablePlanningFromRecall(false); > expPlanner.solve(5); > > > > As can be seen, I disabled PlanningFromRecal but when running the program, RRTconnect is still being used. Is there anything missing in my program? > > Also, is it possible to save prm graph (to a file maybe...), load it again in a different program and use it to solve a new query? > > Best, Hadar. > > > > > > _______________________________________________ > ompl-users mailing list > omp...@li... > https://lists.sourceforge.net/lists/listinfo/ompl-users |
From: hadar s. <had...@gm...> - 2020-06-11 11:01:06
|
Hi, How can I save the PRM RoadMap graph, load it again in an attempt of solving a new query? I would like to use the constructed road map, find a path from scratch without using retrieve-repair module and past solutions. *I tried to use the Thunder framework:* ot::Thunder expPlanner(setup.getSpaceInformation()); expPlanner.setFilePath("thunder.db"); //attempt to solve the problem if (setup.solve(20)) { ... } expPlanner.doPostProcessing(); (setup.getPlanner()->as<og::PRM>())->clearQuery(); // create new start and goal ob::ScopedState<> start(setup.getStateSpace()); start[0]=... start[1]=... ob::ScopedState<> goal(setup.getStateSpace()); goal[0]=... goal[1]=... expPlanner.setStartAndGoalStates(start, goal); expPlanner.setPlanner(std::make_shared<og::PRM>(setup.getSpaceInformation())); //plan from SCRATCH and disable using previous plan expPlanner.enablePlanningFromRecall(*false*); expPlanner.solve(5); As can be seen, I disabled PlanningFromRecal but when running the program, RRTconnect is still being used. Is there anything missing in my program? Also, is it possible to save prm graph (to a file maybe...), load it again in a different program and use it to solve a new query? Best, Hadar. |
From: Mark M. <mm...@ri...> - 2020-06-04 00:09:57
|
Hi all, We are happy to announce version 1.5.0 of the Open Motion Planning Library (OMPL). OMPL 1.5 contains the following main changes: A C++14 compiler is now required. The minimum version of CMake required is now 3.5 and the minimum version of Boost supported is now 1.58. All development now takes place on Github <https://github.com/ompl/ompl>. This used to be a git mirror of the mercurial repository on BitBucket, but since BitBucket is phasing out mercurial support the GitHub repo is now the main repo. All the old issues have been migrated to GitHub. Added build targets for easily creating Docker images for OMPL, the PlannerArena web server <http://plannerarena.org/>, and the OMPL web app <http://omplapp.kavrakilab.org/>. Docker images are available on Docker Hub <https://hub.docker.com/u/kavrakilab>. Added new planners: XXL <http://ompl.kavrakilab.org/classompl_1_1geometric_1_1XXL.html#gXXL>: a probabilistically complete sampling-based algorithm designed to plan the motions of high-dimensional mobile manipulators and related platforms. ABIT* <http://ompl.kavrakilab.org/classompl_1_1geometric_1_1ABITstar.html#gABITstar>: an extension to BIT* that uses advanced graph-search techniques to find initial solutions faster. AIT* <http://ompl.kavrakilab.org/classompl_1_1geometric_1_1AITstar.html#gAITstar>: an anytime asymptotically optimal algorithm that simultaneously estimates and exploits problem-specific heuristics. Quotient-Space RRT <http://ompl.kavrakilab.org/quotientSpacePlanning.html>: a generalization of RRT to plan on different abstraction levels. The abstraction levels are represented by quotient-spaces. Taskspace RRT <http://ompl.kavrakilab.org/classompl_1_1geometric_1_1TSRRT.html#gTSRRT>: a variant of RRT where exploration is guided by the task space. RLRT <http://ompl.kavrakilab.org/classompl_1_1geometric_1_1RLRT.html#gRLRT> and BiRLRT <http://ompl.kavrakilab.org/classompl_1_1geometric_1_1BiRLRT.html#gBiRLRT>: basic tree-based planners without any sophistic heuristics to guide the exploration, useful as a baseline for comparison against other tree-based planners. PRM, PRM*, LazyPRM, and LazyPRM* can now be initialized with an ompl::base::PlannerData <http://ompl.kavrakilab.org/classompl_1_1base_1_1PlannerData.html> instance (the generic way to represent roadmaps/trees in OMPL). This means that you can seed these planners with data from a previous run from any other planner. Using the ompl::base::PlannerDataStorage <http://ompl.kavrakilab.org/classompl_1_1base_1_1PlannerDataStorage.html> functionality, this data can be saved to or loaded from disk. Added support for deterministic sampling. Halton sampling is included, other deterministic sampling methods can be added. Added a new PlannerTerminationCondition called CostConvergenceTerminationCondition, which can be used to terminate asymptotically (near-)optimal planners based on convergence. Cleaned up ompl_benchmark_script.py for Python 3. Updated PlannerArena again to work with latest versions of R dependencies. Misc. bug and documentation fixes. Major contributions to this release were made by: • Ryan Luna, Rice University (now at Waymo) • Marlin Strub, Oxford University • Jonathan Gammell, Oxford University • Andreas Orthey, University of Stuttgart • Henning Kayser, PickNik Robotics • Leonard Bruns, Robert Bosch GmbH (now at KTH Royal Institute of Technology) • Luigi Palmieri, Robert Bosch GmbH Updated packages for various package managers should appear shortly, including: the ROS Noetic release and versions in MacPorts (macOS), HomeBrew (macOS), and vcpkg (Microsoft Windows). The OMPL web page can be found at http://ompl.kavrakilab.org. Best, Mark -- Mark Moll Sr. Research Scientist | moll.ai <https://moll.ai/> | Rice University |
From: Mark M. <mm...@ri...> - 2020-05-27 15:05:29
|
Hi June, The most likely reason is that you have multiple versions of python installed and you use a different version than /opt/local/bin/ompl_app. Look at the first line of ompl_app and use the python interpreter specified there. Since the OMPL python modules are compiled for a specific version of Python, they will likely not work with a different version. Best, Mark > On May 25, 2020, at 12:51 AM, Jun Ju <ju...@uq...> wrote: > > Hello! > > I’m a Mac user and my MacBook Pro is macOS Catalina (Version 10.15.3). > > I just installed OMPL by “sudo port install ompl +app” on terminal. I can open ompl app by “/opt/local/bin/ompl_app” successfully now. > > However, when I wrote “import ompl” in python, it told me “ModuleNotFoundError: No module named 'ompl'”. I have tried on both python2.7 and python3 and both failed. In addition, I can only find 3 documents relevant to OMPL in the directory of ““/opt/local/bin/”. > <image001.png> > > It seems I didn’t install OMPL with Python bindings. I want to write code in python. Do you know how should I install Python bindings on Mac? > > > Many thanks, > June > > > _______________________________________________ > ompl-users mailing list > omp...@li... <mailto:omp...@li...> > https://lists.sourceforge.net/lists/listinfo/ompl-users <https://lists.sourceforge.net/lists/listinfo/ompl-users> |
From: Jun Ju <ju...@uq...> - 2020-05-25 08:23:52
|
Hello! I’m a Mac user and my MacBook Pro is macOS Catalina (Version 10.15.3). I just installed OMPL by “sudo port install ompl +app” on terminal. I can open ompl app by “/opt/local/bin/ompl_app” successfully now. However, when I wrote “import ompl” in python, it told me “ModuleNotFoundError: No module named 'ompl'”. I have tried on both python2.7 and python3 and both failed. In addition, I can only find 3 documents relevant to OMPL in the directory of ““/opt/local/bin/”. [cid:image001.png@01D632BD.112F0430] It seems I didn’t install OMPL with Python bindings. I want to write code in python. Do you know how should I install Python bindings on Mac? Many thanks, June |
From: Helio P. F. <xpe...@gm...> - 2020-03-30 13:19:16
|
Hi Jack, It depends on what you're using these metrics for. If you're using them after-the-fact e.g. to monitor system performance, you can compute them after the call to the planner's (or SimpleSetup's) solve() function. Otherwise, if you want to use the metrics to influence planning, you should compute them in an optimization objective, and possibly also a validity checker to flat-out discard states that cross a performance threshold. You might also want to implement a custom state sampler that is biased towards states with better performance metrics. Take a look into these tutorials for reference: Defining optimization objectives for optimal planning https://ompl.kavrakilab.org/optimizationObjectivesTutorial.html Setting up state validity checking https://ompl.kavrakilab.org/stateValidation.html Using existing samplers and creating new ones https://ompl.kavrakilab.org/samplers.html -- Best regards, Helio Perroni Filho E-mail: ma...@xp... Web: http://xperroni.me <http://machineawakening.blogspot.com/> On Sun, Mar 29, 2020 at 2:33 PM Jack Green <jgr...@gm...> wrote: > Hello, > > I am running 3D printing simulations using a robot arm in VREP with the > OMPL plugin for the motion planning of the arm. I am trying to calculate a > couple of metrics for the movement of the arm (such as swept volume, energy > expenditure, etc.) and am trying to figure out where to put the code that > calculates these values. Thanks. > > Best, > Jack Green > |
From: Jack G. <jgr...@gm...> - 2020-03-29 18:33:24
|
Hello, I am running 3D printing simulations using a robot arm in VREP with the OMPL plugin for the motion planning of the arm. I am trying to calculate a couple of metrics for the movement of the arm (such as swept volume, energy expenditure, etc.) and am trying to figure out where to put the code that calculates these values. Thanks. Best, Jack Green On Tue, Mar 24, 2020 at 6:04 AM Pouria Tajvar <ta...@kt...> wrote: > Hello, > > I am writing to ask about the paper(s) where the algorithm for OMPL's LTL > planner is explained. I was wondering if it includes the algorithm > presented in "Sampling-based motion planning with temporal goals" by > Bhatia, Kavraki and Vardi. Thanks in advance. > > Best Regards, > Pouria > _______________________________________________ > ompl-users mailing list > omp...@li... > https://lists.sourceforge.net/lists/listinfo/ompl-users > |
From: Mark M. <mm...@ri...> - 2020-03-24 23:37:27
|
Hi Pouria, The LTLPlanner should be very close to the pseudocode described in that paper, but the implementation is somewhat different from the one used for that paper. This may be another useful reference: A. Bhatia, M. R. Maly, L. E. Kavraki, and M. Y. Vardi, “Motion planning with complex goals,” IEEE Robotics & Automation Magazine, vol. 18, pp. 55–64, Sept. 2011. Best, Mark > On Mar 24, 2020, at 7:04 AM, Pouria Tajvar <ta...@kt...> wrote: > > Hello, > > I am writing to ask about the paper(s) where the algorithm for OMPL's LTL planner is explained. I was wondering if it includes the algorithm presented in "Sampling-based motion planning with temporal goals" by Bhatia, Kavraki and Vardi. Thanks in advance. > > Best Regards, > Pouria |
From: Helio P. F. <xpe...@gm...> - 2020-03-24 20:23:13
|
Hi all, I started looking into LTL motion planning following Pouria's question. I see that the demo <https://ompl.kavrakilab.org/LTLWithTriangulation_8cpp_source.html> uses convex polygons for propositions, which is certainly the most cost-effective approach. But I was wondering, would OMPL's LTL planner still work if a suitable implementation of non-convex propositions were supplied? Moreover, what if propositions were discontinuous? For example, in my system I use a distance map to quickly determine the distance between a 2D point and the closest obstacle. Let's say I created a subclass of ompl::control::PropositionalDecomposition <https://ompl.kavrakilab.org/classompl_1_1control_1_1PropositionalDecomposition.html> with an overloaded worldAtRegion(int rid) <https://ompl.kavrakilab.org/classompl_1_1control_1_1PropositionalDecomposition.html#aab6a90b0083de432493948f8ce6d01fe> function that set the truth value of an "obstructed" proposition depending on whether the centroid of the decomposition region rid is closer than a threshold d to an obstacle, and set the safety automaton to always enforce that proposition to be false. Would the LTL planner be able to handle that? I looked into the source code and didn't see anything that made me think it wouldn't work, but I would like to hear a second opinion. -- Best regards, Helio Perroni Filho E-mail: ma...@xp... Web: http://xperroni.me <http://machineawakening.blogspot.com/> |
From: Pouria T. <ta...@kt...> - 2020-03-24 11:04:18
|
Hello, I am writing to ask about the paper(s) where the algorithm for OMPL's LTL planner is explained. I was wondering if it includes the algorithm presented in "Sampling-based motion planning with temporal goals" by Bhatia, Kavraki and Vardi. Thanks in advance. Best Regards, Pouria |
From: Helio P. F. <xpe...@gm...> - 2020-03-11 14:32:08
|
Hi Hadar, How can I get the path with more states along the path in addition to the > start and goal? There are a couple ways to accomplish that, but to decide which one to use we first need to ask, why is it a problem that the planner is only returning the start and end states? If the solution is valid in the context of the navigation task (there are no obstacles obstructing the way, etc) and you just need it to contain intermediary states down to a given resolution (say, one state every 0.01 m), you can use the ompl::geometric::PathGeometric::interpolate <http://ompl.kavrakilab.org/classompl_1_1geometric_1_1PathGeometric.html#a29c50018bc71d4d25b0f8e4d3e97aecd> function to add intermediary states to the computed path. Optionally you can also use ompl::geometric::PathSimplifier::smoothBSpline <http://ompl.kavrakilab.org/classompl_1_1geometric_1_1PathSimplifier.html#aa4ecd0970d2061c457f57b7665fd6f6b> before it to ensure transitions between paths are smoother. For example: // space is assumed to be an instance of ompl::base::RealVectorStateSpace created previously. ompl::geometric::SimpleSetup solver(space); // Setup solver - set planner, validity checker, start and goal states etc. // Compute path from start state to goal. solver.solve(timeout); // Smooth and interpolate path. auto &path = solver.getSolutionPath(); solver.getPathSimplifier()->smoothBSpline(path); path.interpolate(path.length() / resolution); If however the problem is that the path is not actually valid, e.g. it leads through an obstacle, then you need to use a finer resolution for the validity checker. That can be done by setting the length of the longest valid path edge as a fraction of the maximum extent of the state space: ompl::geometric::SimpleSetup solver(space); // Set path edge resolution. auto state_space = solver.getStateSpace(); double fraction = edge_length / state_space->getMaximumExtent(); state_space->setLongestValidSegmentFraction(fraction); // Finish setting up solver... solver.solve(timeout); You may actually want to combine the two approaches for performance reasons, i.e. set the longest valid segment to a size just short enough to ensure path validity, then use interpolation for further refinement. -- Best regards, Helio Perroni Filho E-mail: ma...@xp... Web: http://xperroni.me <http://machineawakening.blogspot.com/> On Wed, Mar 11, 2020 at 9:49 AM hadar sinvani <had...@gm...> wrote: > Hello again, > > I'm trying to use PRM/PRMstar planner in a RealVectorStateSpace. > In both cases, I'm only getting the start and goal states with no > additional states along the path. > If it matters, my "bool isStateValid(const ob::State *state)" function > always returns true. > How can I get the path with more states along the path in addition to the > start and goal? > > Best, Hadar. > > > _______________________________________________ > ompl-users mailing list > omp...@li... > https://lists.sourceforge.net/lists/listinfo/ompl-users > |
From: Mark M. <mm...@ri...> - 2020-03-11 13:51:35
|
Hadar, You can use the interpolate methods of the PathGeometric class: http://ompl.kavrakilab.org/classompl_1_1geometric_1_1PathGeometric.html <http://ompl.kavrakilab.org/classompl_1_1geometric_1_1PathGeometric.html> Best, Mark > On Mar 11, 2020, at 9:48 AM, hadar sinvani <had...@gm...> wrote: > > Hello again, > > I'm trying to use PRM/PRMstar planner in a RealVectorStateSpace. > In both cases, I'm only getting the start and goal states with no additional states along the path. > If it matters, my "bool isStateValid(const ob::State *state)" function always returns true. > How can I get the path with more states along the path in addition to the start and goal? > > Best, Hadar. |
From: hadar s. <had...@gm...> - 2020-03-11 13:49:04
|
Hello again, I'm trying to use PRM/PRMstar planner in a RealVectorStateSpace. In both cases, I'm only getting the start and goal states with no additional states along the path. If it matters, my "bool isStateValid(const ob::State *state)" function always returns true. How can I get the path with more states along the path in addition to the start and goal? Best, Hadar. |
From: Antonio G. <rob...@gm...> - 2020-03-09 07:54:37
|
Hi everyone, I work with ABB articulated robot arms connected to external axes. For its programming, a custom software in C# was developed. The inverse and normal kinematics are already implemented in the software. The next step is to make the software calculate the joint path (MoveJ/MoveAbsJ) of the robot and simulate it, so for this reason I'm searching for some kind of DLL where the start / end positions can be sent and a list of points given back (with robot axis values) where the robot will pass during the movement. I wonder if such DLL is available anywhere or if anyone may have some helpful information, as I believe it is only a fragment of what developers do with the collision avoidance. Thanks, Gil <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Sem vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> |
From: Mark M. <mm...@ri...> - 2020-02-26 20:04:19
|
Hi Brian, In theory it’d be possible to create a CompoundStateSpace composed of the StateSpaces for each individual robot. You’d have to modify the state validity checker to return true if for a given joint state of the robots neither is colliding with the environment or with each other/themselves. Here is a basic example of how this can be done in OMPL.app for rigid bodies: Python version: https://github.com/ompl/omplapp/blob/master/demos/SE3RigidBodyPlanning/SE3MultiRigidBodyPlanning.py <https://github.com/ompl/omplapp/blob/master/demos/SE3RigidBodyPlanning/SE3MultiRigidBodyPlanning.py> C++ version: https://github.com/ompl/omplapp/blob/master/demos/SE3RigidBodyPlanning/SE3MultiRigidBodyPlanning.cpp <https://github.com/ompl/omplapp/blob/master/demos/SE3RigidBodyPlanning/SE3MultiRigidBodyPlanning.cpp> Doing this in V-REP would be a non-trivial amount of work. Alternatively, you can plan for each robot separately and reparametrize the timing of the trajectories to avoid collisions (analogous to cars crossing an intersection). Best, Mark > On Feb 26, 2020, at 4:19 AM, Brai. P <bri...@gm...> wrote: > > Hi, > I am working on centralized coupled planning for 2 robotic arms on vrep. My question is how to represent the joint space of both of the robots in the one joint space so I can avoid self-collision and robot- robot collisions. I have configured the kinematic chain in the simulation tool but yet I need to know how to represent this coupled configuration space using ompl , could you suggest the steps? > Cheers > _______________________________________________ > ompl-users mailing list > omp...@li... > https://lists.sourceforge.net/lists/listinfo/ompl-users |
From: Brai. P <bri...@gm...> - 2020-02-26 10:19:44
|
Hi, I am working on centralized coupled planning for 2 robotic arms on vrep. My question is how to represent the joint space of both of the robots in the one joint space so I can avoid self-collision and robot- robot collisions. I have configured the kinematic chain in the simulation tool but yet I need to know how to represent this coupled configuration space using ompl , could you suggest the steps? Cheers |
From: Mark M. <mm...@ri...> - 2020-02-21 15:08:14
|
Hi Peter, One possibility is to create a new wrapper state space that augments your existing state space as follows. It defines a new StateType that adds a new member variable representing cost-to-come to the StateType of the underlying state space. It might still be a bit tricky to make sure that distance and interpolation are defined correctly. Ideally, this would work without having to change the implementation of any of the planners, and you just modify your state validity checker to reject states whose cost-to-come exceeds some threshold. If you care primarily about time-optimality, another option is to create a CompoundStateSpace composed of your current state space (with weight 1) and a TimeStateSpace (with weight 0). The weights make sure that the time doesn’t affect the distance. As before, the planners don’t change and you just modify your state validity checker to reject states whose time component exceeds some threshold. Best, Mark > On Feb 19, 2020, at 4:21 PM, Peter Mitrano <mit...@gm...> wrote: > > Hi Mark & others, > > I'm hoping someone can give me advice on how to implement constraint checking on an entire trajectory. Right now I'm using the control::RRT, and propagateWhileValid only checks constraints on a state-by-state basis. However, I want something that is conceptually like hard "max path length" constraint. Specifically, a constraint check that gets in all the states and actions from the root of the tree until the proposed new node, and checks based on that. It's not as simple as accumulating some variable as I propogate -- I need the actual state itself. > > Looking at the RRT code, I feel like I just want to write something to replace propogateWhileValid, which uses Motion throughout instead of State, since Motion has a pointer to parent. Does this make sense? > > Thanks > -Peter > _______________________________________________ > ompl-users mailing list > omp...@li... > https://lists.sourceforge.net/lists/listinfo/ompl-users |
From: Peter M. <mit...@gm...> - 2020-02-19 22:21:51
|
Hi Mark & others, I'm hoping someone can give me advice on how to implement constraint checking on an entire trajectory. Right now I'm using the control::RRT, and propagateWhileValid only checks constraints on a state-by-state basis. However, I want something that is conceptually like hard "max path length" constraint. Specifically, a constraint check that gets in all the states and actions from the root of the tree until the proposed new node, and checks based on that. It's not as simple as accumulating some variable as I propogate -- I need the actual state itself. Looking at the RRT code, I feel like I just want to write something to replace propogateWhileValid, which uses Motion throughout instead of State, since Motion has a pointer to parent. Does this make sense? Thanks -Peter |
From: hadar s. <had...@gm...> - 2020-02-06 12:21:13
|
Hello, I would like to use the reeds shepp state space for a 3d surface environment so that planning for the car model in the x-y plane will be according to reeds shepp curves. The Z value of the car model will be set according to the Z value of the environment at the same x-y coordinates. In that way, the car model will follow any given surface (with changing z values) but the planned path will be according to reeds shepp curves. Can I implement or change the code of reeds shepp state space to be a 3d state space but to sample and plan only in X,Y coordinates and to set the Z value by myself? I would appreciate any help and tips for this implementation! Best, Hadar. |
From: hadar s. <had...@gm...> - 2020-01-06 10:07:07
|
Hi Mark, Thanks for all of your help! According to your suggestion, I used the app demo:SE2RigidBodyPlanning. The "setup" variable remains an instance of "app::SE2RigidBodyPlanning" object (for dealing with mesh). I changed "start" and "goal" variables from: base::ScopedState<base::SE2StateSpace> start(setup.getSpaceInformation()); base::ScopedState<base::SE2StateSpace> goal(start); To: base::ScopedState<base::ReedsSheppStateSpace> start(setup.getSpaceInformation()); base::ScopedState<base::ReedsSheppStateSpace> goal(start); however, running: ((setup.getSpaceInformation())->getStateSpace())->getName() gives: SE2CompoundSpace3 while running: base::StateSpacePtr space(std::make_shared<base::ReedsSheppStateSpace>()); space->getName(); gives: SE2CompoundSpace0 what does each number (0,3) mean? (Is there a list for each number and its corresponding State Space? haven't found one) and how can I change the state space of my "setup" variable to be as ReedsSheppStateSpace? Best and thanks again, Hadar. On Sun, Jan 5, 2020 at 7:44 PM Mark Moll <mm...@ri...> wrote: > Hi Hadar, > > Dealing with meshes is part of the ompl_app library. The easy (but hacky > fix) is to simply replace all occurrences of SE2StateSpace with > ReedsSheppStateSpace and recompile. Now rigid body planning in 2D will be > done using Reeds-Shepp curves. > > Best, > > Mark > > > > On Jan 5, 2020, at 8:38 AM, hadar sinvani <had...@gm...> wrote: > > Thanks alot! > I couldn't find in any of the classes used in this demo where I can > "setEnvironmentMesh" (for specifying the cad file) just like > ompl::app:RigidBodyGeometry class offers. > How can I define the environment in this case? > Best, Hadar. > > > On Thu, Jan 2, 2020 at 7:19 PM Mark Moll <mm...@ri...> wrote: > >> Hi Hadar, >> >> There is no control-based PRM implementation in OMPL. This requires a >> steering function that can exactly connect two states while obeying the >> system’s dynamics/kinematics. This is very hard for the general case. For a >> kinematic car you can pretend it’s a Dubins or Reeds-Sheep car and use the >> corresponding state spaces. With these state spaces you can use “regular” >> PRM (ompl::geometric::PRM). See this demo >> <http://ompl.kavrakilab.org/GeometricCarPlanning_8cpp_source.html> for >> usage. >> >> Best, >> >> Mark >> >> >> >> On Jan 2, 2020, at 7:19 AM, hadar sinvani <had...@gm...> wrote: >> >> Hi, >> How can I use the kinematic car model robot for solving path planning >> queries with a control based PRM? is there a away to add kinodynamic >> adaptations to the geometric based PRM? >> Thanks! >> >> >> _______________________________________________ >> ompl-users mailing list >> omp...@li... >> https://lists.sourceforge.net/lists/listinfo/ompl-users >> >> >> > |
From: Mark M. <mm...@ri...> - 2020-01-05 17:45:05
|
Hi Hadar, Dealing with meshes is part of the ompl_app library. The easy (but hacky fix) is to simply replace all occurrences of SE2StateSpace with ReedsSheppStateSpace and recompile. Now rigid body planning in 2D will be done using Reeds-Shepp curves. Best, Mark > On Jan 5, 2020, at 8:38 AM, hadar sinvani <had...@gm...> wrote: > > Thanks alot! > I couldn't find in any of the classes used in this demo where I can "setEnvironmentMesh" (for specifying the cad file) just like ompl::app:RigidBodyGeometry class offers. > How can I define the environment in this case? > Best, Hadar. > > > On Thu, Jan 2, 2020 at 7:19 PM Mark Moll <mm...@ri... <mailto:mm...@ri...>> wrote: > Hi Hadar, > > There is no control-based PRM implementation in OMPL. This requires a steering function that can exactly connect two states while obeying the system’s dynamics/kinematics. This is very hard for the general case. For a kinematic car you can pretend it’s a Dubins or Reeds-Sheep car and use the corresponding state spaces. With these state spaces you can use “regular” PRM (ompl::geometric::PRM). See this demo <http://ompl.kavrakilab.org/GeometricCarPlanning_8cpp_source.html> for usage. > > Best, > > Mark > > > >> On Jan 2, 2020, at 7:19 AM, hadar sinvani <had...@gm... <mailto:had...@gm...>> wrote: >> >> Hi, >> How can I use the kinematic car model robot for solving path planning queries with a control based PRM? is there a away to add kinodynamic adaptations to the geometric based PRM? >> Thanks! >> >> >> _______________________________________________ >> ompl-users mailing list >> omp...@li... <mailto:omp...@li...> >> https://lists.sourceforge.net/lists/listinfo/ompl-users <https://lists.sourceforge.net/lists/listinfo/ompl-users> > |
From: hadar s. <had...@gm...> - 2020-01-05 14:38:56
|
Thanks alot! I couldn't find in any of the classes used in this demo where I can "setEnvironmentMesh" (for specifying the cad file) just like ompl::app:RigidBodyGeometry class offers. How can I define the environment in this case? Best, Hadar. On Thu, Jan 2, 2020 at 7:19 PM Mark Moll <mm...@ri...> wrote: > Hi Hadar, > > There is no control-based PRM implementation in OMPL. This requires a > steering function that can exactly connect two states while obeying the > system’s dynamics/kinematics. This is very hard for the general case. For a > kinematic car you can pretend it’s a Dubins or Reeds-Sheep car and use the > corresponding state spaces. With these state spaces you can use “regular” > PRM (ompl::geometric::PRM). See this demo > <http://ompl.kavrakilab.org/GeometricCarPlanning_8cpp_source.html> for > usage. > > Best, > > Mark > > > > On Jan 2, 2020, at 7:19 AM, hadar sinvani <had...@gm...> wrote: > > Hi, > How can I use the kinematic car model robot for solving path planning > queries with a control based PRM? is there a away to add kinodynamic > adaptations to the geometric based PRM? > Thanks! > > > _______________________________________________ > ompl-users mailing list > omp...@li... > https://lists.sourceforge.net/lists/listinfo/ompl-users > > > |