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
(3) |
Oct
|
Nov
|
Dec
|
|
From: Manuel Kaspar <kaspar.manuel@po...> - 2016-05-10 11:23:49
|
Hi together, thank you, Mark Moll, that you directed me to the Thunder Framework. I also had a look at the ThunderLightning-Demo and (at the beginning) it was running. In my own project and also now in the demo I get the exception when doing the doPostProcessing() step. that Vector Subscript is out of Range. In Sparsedb.cpp line 815: i == addedStateIDs[usedIDTracker] is it possible that the whole thing does only work with a working thunder.db? And can't create new ones? I cant find the problem?! lg Manu |
|
From: Mark Moll <mmoll@ri...> - 2016-05-09 16:09:45
|
Hi Manu, You may want to look into using Thunder (see ompl/demos/ThunderLightning.cpp for a demo), which stores a sparse roadmap and can handle multiple queries. Mark > On May 9, 2016, at 9:44 AM, Manuel Kaspar <kaspar.manuel@...> wrote: > > Hello together, > I have a major problem with my PRM Planner: > > We are having a problem with two industrial robots that carry together a > material. I want to use the PRM Planner because the movment is going to > be done for probably a few hundred times, but always with slightly > different start and different goal positions. > > To find a solution the PRM planner needs over an hour, so it is > absolutely neccessary to store the Roadmap (or planner state), so that > the initial roadmap doesn't have to be constructed all the time. > > I found following thread in the mailinglist: > https://sourceforge.net/p/ompl/mailman/message/32657097/. There it is > told, that we can use PlannerDataStorage for that. But as far as I can > see, I can change the goal but the start has to be an existing vertice. > (Also i don't understand if this can deal with states that are not > exactly a vertice in the roadmap?!) > > In the thread it is also said, that the ompl team is working on a > solution for serializing internal multi query planner states. Does > anybody have an idea how to deal with this problem? I thought about > implementing a serialization myself. But there are lots of objects that > don't support serialization and would have to be adapted?! > > Thanks a lot! > Greets Manu > |
|
From: Manuel Kaspar <kaspar.manuel@po...> - 2016-05-09 14:45:04
|
Hello together, I have a major problem with my PRM Planner: We are having a problem with two industrial robots that carry together a material. I want to use the PRM Planner because the movment is going to be done for probably a few hundred times, but always with slightly different start and different goal positions. To find a solution the PRM planner needs over an hour, so it is absolutely neccessary to store the Roadmap (or planner state), so that the initial roadmap doesn't have to be constructed all the time. I found following thread in the mailinglist: https://sourceforge.net/p/ompl/mailman/message/32657097/. There it is told, that we can use PlannerDataStorage for that. But as far as I can see, I can change the goal but the start has to be an existing vertice. (Also i don't understand if this can deal with states that are not exactly a vertice in the roadmap?!) In the thread it is also said, that the ompl team is working on a solution for serializing internal multi query planner states. Does anybody have an idea how to deal with this problem? I thought about implementing a serialization myself. But there are lots of objects that don't support serialization and would have to be adapted?! Thanks a lot! Greets Manu |
|
From: Ainsworth, Samuel <samuel_ainsworth@br...> - 2016-05-07 02:50:54
|
Thanks for the detailed response! I ended up hacking together a solution in which my Python planner overrides the `planners()` method and provides a custom param holder. It's not ideal, but it gets the job done. Best, Samuel On Fri, May 6, 2016 at 12:36 PM, Mark Moll <mmoll@...> wrote: > Samuel, > > This is tricky. Look at the declaration of ParamSet::declareParam: > > void declareParam > <http://ompl.kavrakilab.org/classompl_1_1base_1_1ParamSet.html#a3b27e180d07144d220f332750590fc71>; (const > std::string &name, const typename SpecificParam > <http://ompl.kavrakilab.org/classompl_1_1base_1_1SpecificParam.html><; T > >::SetterFn &setter, const typename SpecificParam > <http://ompl.kavrakilab.org/classompl_1_1base_1_1SpecificParam.html><; T > >::GetterFn &getter=typename SpecificParam > <http://ompl.kavrakilab.org/classompl_1_1base_1_1SpecificParam.html><; T > >::GetterFn()) > > You need to export this method fully instantiated with all types. In > generate_bindings.py you could add some thing like this for a parameter of > type double: > > self.ompl_ns.class_(‘ParamSet’).add_registration_code(""" > def(“declareDoubleParam”, > &::ompl::base::ParamSet::declareParam<double, std::function<void(double)>, > std::function<double(void)>>) > > But that’s not all. You also need to export the setter and getter function > types so that you can convert your python functions to that type. I *think* > it can all be done, but it’ll be messy. > > If you are doing this because you want to use your planner in the GUI, it > might be easier to change the (Python) PlanningAlgorithms class in > ompl/__init__.py. > > Mark > > > > On May 5, 2016, at 3:14 PM, Ainsworth, Samuel <samuel_ainsworth@...> > wrote: > > Is there any way to use declareParam from a Planner implemented with the > Python bindings? More generally, how should planners written in Python > expose their parameters? > > Attempting to use declareParam in Python produces an "object has no > attribute" error, which is somewhat to be expected since declareParam is a > C++ template. However, it's not clear to me that any other approach exists > for Python planners. > > Best, > Samuel > > > |
|
From: Mark Moll <mmoll@ri...> - 2016-05-06 16:36:17
|
|
From: Ainsworth, Samuel <samuel_ainsworth@br...> - 2016-05-05 20:46:03
|
Is there any way to use declareParam from a Planner implemented with the Python bindings? More generally, how should planners written in Python expose their parameters? Attempting to use declareParam in Python produces an "object has no attribute" error, which is somewhat to be expected since declareParam is a C++ template. However, it's not clear to me that any other approach exists for Python planners. Best, Samuel |
|
From: Dave Coleman <davetcoleman@gm...> - 2016-05-05 17:24:57
|
FYI I've moved discussion of auto-formatting OMPL code to an issue on Bitbucket. https://bitbucket.org/ompl/ompl/issues/237/auto-formatting-of-style-guide-guide-using - dave On Wed, Jul 22, 2015 at 7:41 AM, Mark Moll <mmoll@...> wrote: > I like this! It’d be nice to get a minimal .clang-format that would result > in the smallest diff when applied to all of the OMPL code. If we are really > close to an existing style, then we should consider adopting that style, so > that people don’t have to “learn” yet another style. > > I’m not sure what the best way is to “enforce” a style. If we apply > clang-format with our format to all code, then anybody who has cloned and > modified OMPL is going to have a bad time updating to the latest changes. > OTOH, people can apply clang-format on their own clone before updating. > > Another potential place for enforcement is in hg/git hooks. I think we > should encourage people to use this, but it wouldn’t be too difficult to > occasionally apply clang-format on accepted pull requests. > > Best, > Mark > > > > > On Jul 22, 2015, at 1:23 AM, Dave Coleman <davetcoleman@...> > wrote: > > > > I've gotten spoiled in other software projects that have the Clang > Format tool to auto enforce style guidelines. Just curious if anyone has > made on for OMPL? We'd need a .clang-format file > > > > This might help: > > http://clangformat.com/ > > > > But it might be fastest to choose a similar style guideline (Google?) > and just modify their config file to match out Style Guidelines > > |
|
From: Mark Moll <mmoll@ri...> - 2016-04-26 15:35:32
|
Hi Aashish, See ompl/demos/RigidBodyPlanningWithIK.cpp for a demo on how genetic search is used to sample IK solutions for the goal in a separate thread from the planning algorithm. Hope that helps. Best, Mark > On Apr 26, 2016, at 10:16 AM, Aashish Vatsyayan <aashishv11@...> wrote: > > Hello, > > I am trying to use the genetic search to determine the closest reachable point for a motion planning task. My motion planning is done in Moveit! and I want to generate an intermediate point to switch planners. > > I know that genetic search is a tool for determining the valid states but I am unsure how to implement it. Does it replace the existing valid state sampler or works along side? I am unclear how to implement it with the ompl_moveit interface plugin. > > Any help will be appreciated > > -- > Thanks and Regards, > Aashish Vatsyayan |
|
From: Aashish Vatsyayan <aashishv11@gm...> - 2016-04-26 15:17:06
|
Hello, I am trying to use the genetic search to determine the closest reachable point for a motion planning task. My motion planning is done in Moveit! and I want to generate an intermediate point to switch planners. I know that genetic search is a tool for determining the valid states but I am unsure how to implement it. Does it replace the existing valid state sampler or works along side? I am unclear how to implement it with the ompl_moveit interface plugin. Any help will be appreciated -- Thanks and Regards, Aashish Vatsyayan |
|
From: Ainsworth, Samuel <samuel_ainsworth@br...> - 2016-04-26 02:17:04
|
So, the Py++ bindings provide a nice way to interact with OMPL's C++ infrastructure via Python. I know that one can construct a Python wrapper of a C++ object from Python. Is it possible to do such a thing from C++? In other words, say I have an ompl::base::State. Is there any way to construct a Py++ Python object wrapping it in the form PyObject in C++, which can then be handed to Python code via the Python C API? Best, Samuel |
|
From: Ainsworth, Samuel <samuel_ainsworth@br...> - 2016-04-17 05:08:10
|
Perfect, thank you! Best, Samuel On Friday, April 15, 2016, Mark Moll <mmoll@...> wrote: > You can use StateSpace::printState to write a state to a > std::ostringstream and from that you get a std::string. > > You can also serialize states to a binary representation (or use > base::StateStorage to save/load states). > > Mark > > > > On Apr 14, 2016, at 9:47 PM, Ainsworth, Samuel <samuel_ainsworth@...> > wrote: > > Is there any way to convert an arbitrary ompl::base::State to a string? It > would be incredible helpful for debugging. > > Best, > Samuel > > > |
|
From: Mark Moll <mmoll@ri...> - 2016-04-16 03:47:55
|
|
From: Mark Moll <mmoll@ri...> - 2016-04-05 16:00:15
|
|
From: Mark Moll <mmoll@ri...> - 2016-04-04 14:32:44
|
Not at the moment. You can use ompl::control::SST in the OMPL repository. It is an asymptotically *near*-optimal algorithm. Mark > On Apr 4, 2016, at 3:53 AM, David Boon <boonflies@...> wrote: > > Hello, > Is there any possibility to use optimization objectives with control_RRT? > |
|
From: Mark Moll <mmoll@ri...> - 2016-04-04 14:29:20
|
|
From: David Boon <boonflies@gm...> - 2016-04-04 08:53:37
|
Hello, Is there any possibility to use optimization objectives with control_RRT? Regards, Boon |
|
From: David Boon <boonflies@gm...> - 2016-04-04 08:49:28
|
Hello, While running an optimizing planner, is the time displayed in benchmarking, the time before optimization begins? Regards, Boon |
|
From: Mark Moll <mmoll@ri...> - 2016-03-31 13:36:52
|
|
From: Federico Ferri <ferri@di...> - 2016-03-30 16:03:29
|
Hi all, I was wondering why is there a GoalState class AND a GoalStates class? Can't the single goal state functionality be implemented with the GoalStates class with only one goal state? -- Federico Ferri |
|
From: Mark Moll <mmoll@ri...> - 2016-03-24 14:07:58
|
If your code depends on OMPL or if you have your own modified version of OMPL, then this is important for you. I just merged a large number of C++11 related changes in the default branches of the ompl and omplapp repositories. As a first step, many Boost-related code has been replaced with C++11 equivalents. (We cannot get rid of Boost entirely since we use Boost.Graph.) The switch to C++11 also affects the generation of python bindings. Gccxml, the low-level tool used to create XML parse trees for C++ code doesn’t work with C++11 (it is based on gcc-4.2 and no longer maintained). Luckily, there is a drop-in replacement in the form of castxml, which follows clang development. The python modules pygccxml and pyplusplus will have to be updated to recent versions that will call castxml instead of gccxml. If you have questions or concerns about this change, please let me know. Mark |
|
From: Ainsworth, Samuel <samuel_ainsworth@br...> - 2016-03-17 23:30:35
|
Great, thank you! Trying now... Samuel On Thu, Mar 17, 2016 at 7:16 PM, Mark Moll <mmoll@...> wrote: > See http://ompl.kavrakilab.org/pybindingsPlanner.html and > http://ompl.kavrakilab.org/python.html. > > Mark > > > > On Mar 17, 2016, at 4:44 PM, Ainsworth, Samuel <samuel_ainsworth@...> > wrote: > > Alright, at this point I've settled on implementing a planner in C++ in > the hopes of painless integration with omplapp and MoveIt!. I've written a > file ompl/src/ompl/geometric/myplanner/MyPlanner.cpp: > > ``` > namespace ompl > { > class MyPlanner : public base::Planner > { > public: > MyPlanner(const base::SpaceInformationPtr &si) : base::Planner(si, > "MyPlanner") > ... > ``` > > according to the starter template here: > http://ompl.kavrakilab.org/newPlanner.html. > > Everything builds properly. However, the Python bindings are not being > generated and MyPlanner does not show up in omplapp as a result. What steps > must be taken in order to set up the Python bindings for a new planner? > I've been playing around with things for a bit but nothing seems to work > and rebuilding takes about 2-3 hours. > > Best, > Samuel > > On Wed, Mar 2, 2016 at 1:19 AM, Ainsworth, Samuel < > samuel_ainsworth@...> wrote: > >> Ok, thanks for the info! I'm dealing with a planner that also has Python >> dependencies, so I'll have to figure out something sneaky in order to work >> with MoveIt. >> >> Best, >> Samuel >> >> On Tue, Mar 1, 2016 at 7:21 PM, Mark Moll <mmoll@...> wrote: >> >>> Hi Samuel, >>> >>> > On Feb 29, 2016, at 5:58 PM, Ainsworth, Samuel < >>> samuel_ainsworth@...> wrote: >>> > I've written a custom planner in Python by extending >>> ompl.base.Planner. How can I go about incorporating it into the OMPL GUI >>> and ultimately MoveIt? >>> > >>> > I understand from the documentation ( >>> http://ompl.kavrakilab.org/newPlanner.html) that this is accomplished >>> by publicly deriving ompl::base::Planner for C++ based planners. How is >>> this done for planners written in Python? >>> >>> Although it’s technically possible to derive a new planner in python >>> from the ompl::base::Planner class, in practice this is typically not >>> advisable beyond prototyping. >>> >>> The OMPL.app GUI automatically populates the planner dropdown widgets by >>> type introspection of the ompl.geometric and ompl.control modules (using >>> the ompl.initializePlannerLists() function). If you add your planner to one >>> of those modules, it should just show up. >>> >>> It seems virtually impossible to add your python-based planner to >>> MoveIt!. >>> >>> Mark >>> >> >> > > |
|
From: Mark Moll <mmoll@ri...> - 2016-03-17 23:16:57
|
|
From: Ainsworth, Samuel <samuel_ainsworth@br...> - 2016-03-17 21:44:48
|
Alright, at this point I've settled on implementing a planner in C++ in the
hopes of painless integration with omplapp and MoveIt!. I've written a file
ompl/src/ompl/geometric/myplanner/MyPlanner.cpp:
```
namespace ompl
{
class MyPlanner : public base::Planner
{
public:
MyPlanner(const base::SpaceInformationPtr &si) : base::Planner(si,
"MyPlanner")
...
```
according to the starter template here:
http://ompl.kavrakilab.org/newPlanner.html.
Everything builds properly. However, the Python bindings are not being
generated and MyPlanner does not show up in omplapp as a result. What steps
must be taken in order to set up the Python bindings for a new planner?
I've been playing around with things for a bit but nothing seems to work
and rebuilding takes about 2-3 hours.
Best,
Samuel
On Wed, Mar 2, 2016 at 1:19 AM, Ainsworth, Samuel <
samuel_ainsworth@...> wrote:
> Ok, thanks for the info! I'm dealing with a planner that also has Python
> dependencies, so I'll have to figure out something sneaky in order to work
> with MoveIt.
>
> Best,
> Samuel
>
> On Tue, Mar 1, 2016 at 7:21 PM, Mark Moll <mmoll@...> wrote:
>
>> Hi Samuel,
>>
>> > On Feb 29, 2016, at 5:58 PM, Ainsworth, Samuel <
>> samuel_ainsworth@...> wrote:
>> > I've written a custom planner in Python by extending ompl.base.Planner.
>> How can I go about incorporating it into the OMPL GUI and ultimately MoveIt?
>> >
>> > I understand from the documentation (
>> http://ompl.kavrakilab.org/newPlanner.html) that this is accomplished by
>> publicly deriving ompl::base::Planner for C++ based planners. How is this
>> done for planners written in Python?
>>
>> Although it’s technically possible to derive a new planner in python from
>> the ompl::base::Planner class, in practice this is typically not advisable
>> beyond prototyping.
>>
>> The OMPL.app GUI automatically populates the planner dropdown widgets by
>> type introspection of the ompl.geometric and ompl.control modules (using
>> the ompl.initializePlannerLists() function). If you add your planner to one
>> of those modules, it should just show up.
>>
>> It seems virtually impossible to add your python-based planner to MoveIt!.
>>
>> Mark
>>
>
>
|
|
From: Mark Moll <mmoll@ri...> - 2016-03-17 12:03:10
|
|
From: Ainsworth, Samuel <samuel_ainsworth@br...> - 2016-03-17 07:03:01
|
Why does the omplapp default branch have two different heads, 90bcd1038a55 and ef186b0bb56d? What's the difference between them? Best, Samuel |