personalrobotics / aikido Goto Github PK
View Code? Open in Web Editor NEWArtificial Intelligence for Kinematics, Dynamics, and Optimization
Home Page: https://personalrobotics.github.io/aikido/
License: BSD 3-Clause "New" or "Revised" License
Artificial Intelligence for Kinematics, Dynamics, and Optimization
Home Page: https://personalrobotics.github.io/aikido/
License: BSD 3-Clause "New" or "Revised" License
This may not be the right way to check if a state is in TSR.
We should decide on one of the two.
Right now, aikido_rviz
is hard-coded to publish in the map
frame in two separate places.
https://github.com/personalrobotics/aikido/blob/master/aikido_rviz/src/FrameMarker.cpp#L62
https://github.com/personalrobotics/aikido/blob/master/aikido_rviz/src/BodyNodeMarker.cpp#L27
We should consolidate this to one location, and allow it to be changed to publish markers in another frame. This would handle situations where something else in TF corresponds to the kido
root frame.
Current implementation does not have setCollisionMask
.
Compute total length of sequence; useful for pre-allocating memory or not using iterators.
In aikido/aikido/include/aikido/statespace/dart/detail/MetaSkeletonStateSpace.hpp, we can implement the remaining joint types:
I have a version of DART built without Bullet, and I am getting the following error when compiling AIKIDO:
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
BULLET_INCLUDE_DIR
This might be a configuration issue in the exported DART config, I'm not sure yet.
We now have EQUALITY, INEQUALITY
. We may later want to add BOXCONSTRAINT
as some optimizers handle a box constraint more efficiently than two inequality constraints.
I wrote a custom GTest predicate CompareEigenMatrices
for comparing Eigen
matrices. We should replace all of our EXPECT_TRUE(a.isApprox(b))
calls with this predicate. There are a few advantages:
As mentioned by @mkoval in #12, we should set up Travis builds for automated testing. A few questions:
kido
should we test against?kido
from source)?@jslee02 recently set up code-coverage auditing for DART in dartsim/dart#632. I think it makes sense to have here as well, since we would like to have the same high-quality code in aikido
.
@lgw903 and @Shushman both ran into missing TinyXML symbols. I need to figure out the right find_package
incantations to add to CMakeLists.txt
to make this portable.
@cdellin pointed out that we put the DART-specific state spaces in the aikido/statespace/dart
subdirectory, but make no such distinction for aikido/constraint
. We should consider the same directory structure for aikido/constraint
for consistency.
We should have no build warnings
Current implementation returns all dimension. This should be changed to return only the dimensions with bounded constraints.
This should be either removed to use the default implementation or changed to call getValue
once.
Implement the getMaximumExtent
function on aikido::ompl::GeometricStateSpace
. This is used by OMPL planners to compute collision checking resolution. We are avoiding this by defining a custom MotionValidator
. But there may be other uses of the function that could cause planning errors.
AFAIK, there are two ways:
master
)In current implementation of IkSampleableConstraint->sample()
, when sampling from either mSeedSampler
or mPoseSampler
fails it will continue retrying mMaxIteration
has been reached. However, these samplers are deterministic, and once they cannot sample, it's likely that all samples are exhausted and thus retrying will not produce any new sample. One possible solution is to wrap these with FiniteCyclicSampelableConstraint
to cycle multiple times.
It seems like it would make sense to put the contents of test_resources
into the existing test directory i.e. tests/resources
.
There is already tests/gtest
in there, so it seems reasonable to put other test dependencies in the sample place and avoid another top-level directory.
Now that Aikido is public we should migrate from travis-ci.com to travis-ci.org. This was a bit of a painful process for or_fcl
, so I am holding off until we are done with the upcoming merges.
Change this to analytic derivative.
Current the aikido::ompl::StateSampler
throws a runtime_error
if a valid state sample cannot be generated. Many times failed sampling does not indicate that planning will fail, and we would like to allow planners to handle the failed sampling and continue. or_ompl
returns a state full of ``nan`s that will fail validity checking, rather than throw an exception. This issue is to discuss how we want to handle this in aikido.
We have SE(2) and SE(3) state spaces implemented in aikido::statespace
, but they are not fully supported by the rest of Aikido (e.g. distance metrics, interpolation methods, DART conversions). We need to add this functionality to make them first-class citizens.
@aaronjoh, @lgw903, and I discussed this offline and concluded that it is not possible to represent SE(2) and SE(3) as CompoundStateSpace
s of SO(2), SO(3), and a real vector space because the group operation differs. However, we may be able to gracefully handle both of these by implementing an AffineStateSpace
or an semi-direct product space. We should investigate this idea further before proceeding with implementation.
TODOs
When I do a sudo make install
on aikido_rviz
I get the following output
Install the project...
-- Install configuration: ""
-- Up-to-date: /usr/local/_setup_util.py
-- Up-to-date: /usr/local/env.sh
-- Up-to-date: /usr/local/setup.bash
-- Up-to-date: /usr/local/setup.sh
-- Up-to-date: /usr/local/setup.zsh
-- Up-to-date: /usr/local/.rosinstall
-- Up-to-date: /usr/local/lib/pkgconfig/aikido_rviz.pc
-- Up-to-date: /usr/local/share/aikido_rviz/cmake/aikido_rvizConfig.cmake
-- Up-to-date: /usr/local/share/aikido_rviz/cmake/aikido_rvizConfig-version.cmake
-- Up-to-date: /usr/local/share/aikido_rviz/package.xml
-- Up-to-date: /usr/local/lib/libaikido_rviz.so
-- Up-to-date: /usr/local/lib/python2.7/dist-packages/aikido_rviz.so
It seems to be installing the .so
files, but doesn't install any header files. Consequently aikido_rviz_INCLUDE_DIRS
appears to be empty in aikido_rvizConfig.cmake
?
I am trying to link against aikido
, and I get the error:
undefined reference to symbol '_ZNK6Assimp8IOSystem12ComparePathsEPKcS2_
When linking against r3
earlier, the only way to fix this issue was to manually link against -lassimp
in my CMakeLists.txt
file. It seems I still have to do this. Why?
It's currently implemented using this:
aikido::util::VanDerCorput vdc{1, true, 0.02}; // TODO junk resolution
I think we are implicitly choosing a metric for state space operations using the tangent space. @mkoval had an idea to recover a metric by using exp and log maps but I think this is just recovering this hidden metric. I'll do some more research on this, but wanted to leave an issue open.
It can be really hard to validate style conventions when reviewing PRs. Let's try to set up automated style checking for aikido
before the codebase gets too large.
Some promising options:
I believe this is related to the roscpp
node being forcefully exited:
terminate called after throwing an instance of 'std::system_error'
what(): Invalid argument
The current aikido::constraint::SampleGenerator
interface implies a strong distinction between a finite and infinite sequence of samples (via the getNumSamples()
and canSample()
methods). This distinction might be useful e.g. for planners which want to populate their graphs with unique start and goal vertices. The aikido::constraint::TSR
class currently handles point TSRs (defined with no freedoms at the w
frame) as an infinite sequence of identical samples, which may be a problem for planners which naively implement against the SampleGenerator
API. We should decide how we'd like to handle such cases in a way that is clear to both (a) planners that may make use of SampleGenerator
s and (b) users who are constructing TSR
s. This is important because I expect that all existing users of TSRs commonly use point TSRs to specify pose constraints, so if our software handles this differently (e.g. via a dedicated PoseConstraint
class, which I'm in favor of in any case), we should at least document it well (e.g. by throwing a warning when a point TSR is constructed).
Implement and test TSR::project(..)
method.
With reference to #24
We need to make a call on if waitForMessage
is the right way to get marker data from the apriltags
topic, or if it makes sense to subscribe to the 'apriltags` topic instead.
Address this comment on the current allocState
implementation:
This is actually a very inefficient way to allocate the state. It would be best to allocate a single block of memory for both the OMPL wrapper and the Aikido state, use placement-new to construct the OMPL state, and use allocateInBuffer to construct the Aikido state. Note that we would have to manually call the OMLP state destructor in freeState for this to work. It's fine if we don't do this for now - but we should file an issue as a note for future improvement.
The current aikido::constraint::SampleGenerator interface implies a strong distinction between a finite and infinite sequence of samples (via the getNumSamples() and canSample() methods). The current implementation of aikido::constraint::IkSampleableConstraint
uses a generator for its underlying pose constraint. If this pose generator samples from a finite set of samples, then the IkSampleableConstraint
generator will also return a finite set, even if there exists an infinite sequence of actual samples (e.g. because of kinematic redundancy). Even in the case that the IK set is finite (e.g. due to a 6-DOF arm), there are often multiple solutions for each pose sample.
When dart
becomes kido
:
r3
should become... you know what.
Currently, the sampling interface is called Sampleable
.
We define a header called SO2UniformSampler
.
Inside it is a class called SO2Sampleable
.
We need to standardize on these things. I posit the following naming convention:
Sampleable
Sampler
This makes some sense when doing inheritance, as the interface describe what the class will do, but if a class does multiple things it may not be named after any of them, e.g.
SO2Sampler : Sampleable
TSR : Sampleable, Projectable
Here are the errors I got in aikido build. It seems ompl and boost doesn't go well. I have ompl 0.13.0 and boost 1.54.0 installed.
/home/js/dev/pr/aikido/master/aikido/src/util/CatkinResourceRetriever.cpp:3:25: fatal error: ros/package.h: No such file or directory
#include <ros/package.h>
^
compilation terminated.
make[2]: *** [CMakeFiles/aikido.dir/src/util/CatkinResourceRetriever.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
In file included from /usr/include/boost/smart_ptr/make_shared.hpp:15:0,
from /usr/include/boost/make_shared.hpp:15,
from /home/js/dev/pr/aikido/master/aikido/src/ompl/plan.cpp:3:
/usr/include/boost/smart_ptr/make_shared_object.hpp: In instantiation of 'typename boost::detail::sp_if_not_array<T>::type boost::make_shared(Arg1&&, Args&& ...) [with T = ompl::geometric::SimpleSetup; Arg1 = const boost::shared_ptr<ompl::base::SpaceInformation>&; Args = {}; typename boost::detail::sp_if_not_array<T>::type = boost::shared_ptr<ompl::geometric::SimpleSetup>]':
/home/js/dev/pr/aikido/master/aikido/src/ompl/plan.cpp:77:59: required from here
/usr/include/boost/smart_ptr/make_shared_object.hpp:218:5: error: no matching function for call to 'ompl::geometric::SimpleSetup::SimpleSetup(const boost::shared_ptr<ompl::base::SpaceInformation>&)'
::new( pv ) T( boost::detail::sp_forward<Arg1>( arg1 ), boost::detail::sp_forward<Args>( args )... );
^
/usr/include/boost/smart_ptr/make_shared_object.hpp:218:5: note: candidates are:
In file included from /home/js/dev/pr/aikido/master/aikido/src/ompl/plan.cpp:9:0:
/usr/include/ompl/geometric/SimpleSetup.h:70:13: note: ompl::geometric::SimpleSetup::SimpleSetup(const StateSpacePtr&)
SimpleSetup(const base::StateSpacePtr &space);
^
/usr/include/ompl/geometric/SimpleSetup.h:70:13: note: no known conversion for argument 1 from 'const boost::shared_ptr<ompl::base::SpaceInformation>' to 'const StateSpacePtr& {aka const boost::shared_ptr<ompl::base::StateSpace>&}'
/usr/include/ompl/geometric/SimpleSetup.h:64:15: note: ompl::geometric::SimpleSetup::SimpleSetup(const ompl::geometric::SimpleSetup&)
class SimpleSetup
^
/usr/include/ompl/geometric/SimpleSetup.h:64:15: note: no known conversion for argument 1 from 'const boost::shared_ptr<ompl::base::SpaceInformation>' to 'const ompl::geometric::SimpleSetup&'
make[2]: *** [CMakeFiles/aikido.dir/src/ompl/plan.cpp.o] Error 1
make[1]: *** [CMakeFiles/aikido.dir/all] Error 2
make: *** [all] Error 2
14:19:27: The process "/usr/bin/make" exited with code 2.
Error while building/deploying project aikido (kit: Desktop)
When executing step "Make"
Our test coverage is currently being distorted by the presence of Hauser parabolic smoother. We don't use all of the functionality of the external library in our wrapper, so we clearly will not test all of it.
We should disable coveralls on these source files to get a more accurate reflection of our actual test coverage.
Current implementation risks memory leak when constructors copy State
s and throw error. We currently avoid this by freeing states before the constructor throws an error. It'd be nice to create an RAII helper class to encapsulate this (@mkoval's suggestion.)
Instruct users to build/install DART from our fork. (Provide package?)
@cdellin raised a good point on Reviewable:
I feel like this interpolation idea, if removed from the StateSpace (which is a reasonable design decision), starts to look more like a local planner class which returns a trajectory (or path) between the two states. If we're already committing to an API for planners and for trajectories (i.e. plan between two states, get a trajectory, make queries on the trajectory such as different derivatives, etc) , it seems weird to duplicate that functionality here.
There may be an argument that planners will want to interpolate things very quickly, without for instance instantiating a path object at each step. But at least we should make the API identical, I'd think. And it would be cool if planners could be passed different types of local planners (here called interpolators) and concatenate the resulting path segments using the stock trajectory API.
Current implementation of allocDefaultStateSampler
will allocate a sampler that returns the same sequence every time, i.e. two calls to the function will generate samplers that produce identical sequences. Check that this fits within OMPL's intended usage of the function.
It would be helpful to have a standard method of opaquely indexing into a CompoundState
to access a specific substate. We currently do this by index, which does not generalize nicely to nested CompoundStateSpace
s. This is similar to the SubstateLocation
concept in OMPL.
evaluateDerivative
on SplineTrajectory
currently returns a tangent vector in the tangent space of the start of the segment, instead of the local ("body") frame. We should use the adjoint transformation to transform the first derivative into the correct frame. I am not sure what the general form of this transformation is for higher-order derivatives.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.