rdiankov / openrave Goto Github PK

FLANN radius search is 3x faster

when interface tags in reference a file, the interface type from the reference file is ignored.

ReadRobotXML('robots/pr2-beta-static.zae') crashes after having loaded a robot already. To reproduce, modify the show() of inversekinematics to:

    def show(self,options=None):
        self.env.SetViewer('qtcoin')
        try:
            with self.env:
                robot2 = self.env.ReadRobotXMLFile(self.robot.GetXMLFilename())
                self.env.AddRobot(robot2,True)
            manip2 = robot2.GetManipulators()[0]#(self.manip.GetName())
            with self.ArmVisibility(manip2,0.9):
                raw_input('press any key')
        finally:
            self.env.Remove(robot2)

some collada files need dummy links

methods like ReadRobotXMLFile should be renamed to ReadRobotFile.

Interface-base also has GetXMLFilename, could probably be renamed to GetFilename or GetResourceFilename or GetResource. If it isn't a filename, then we can easily store the entire resource

Should destroy all interfaces without first locking the environment thread. This allows users to freely start threads, lock environments, and wait on them in the destructors.

a while back there were several mods added to collada dom to get sensors working. these should be moved somewhere else so that openrave can start using the official library without compiling from sources

add a user-specified constraint function for the iksolver that will help prune solutions while searching the freespace.

this would be very useful for dual manipulation tasks where the other arm's solution has to be verified.

also useful for closed chains....

Making the offset really small makes the fastgrasping demo fail. Correct behavior is that it should always work (produce the same results) regardless of what this value is set. This suggests that collisions are not being appropriately considered when finding the "non-colliding grasp"

make sure that a change callback is also implemented to update the viewer.

once done, replace hack in Read*Filename methods.

several industrial robots have a range of ~700 degrees, add tests/examples. As long as the planner doesn't read back the dof using GetDOFValues, it is possible to have planners plan for this. Could possibly also add a GetDOFValues(prevvalues) function to keep track of the branches.

Goutham Mallapragada:

I am using the latest_stable version of openrave and it seems that the
collada writer has a bug in it. My robot model as defined in XML format
has a couple of dummy joints (with enable=false). When I do a
robot.GetJoints() on the XML model it returns correctly only the enabled
joints and does not return the dummy joints. I then did a convex
decomposition of the robot and saved the model. When I load the
resulting .zae file and queried the joints using robot.GetJoints() it
returns all the joints including the dummy joints.

response:

collada doesn't support disabled joints, so we'll have to add a custom format for it.

None

in doxygen have a custom command that outputs the interface commands. perhaps figure out a way to format the commands so they make sense to users?

In the process of organizing the collada reader/writer for openrave in order to support convex decompositions, geometric primitives, manipulator/gripper info, attached senosr info, and a couple of more custom tags for ROS integration.

After looking at the recent code, i'm really not satisfied with the current parsing structure. Especially the uri/sidref search functions. The current functions write the results in class variables, which makes things bugs prone and difficult to understand.

redesign of the trajectory class and handling trajectory retiming algorithms inside plugins

From Mike Vande Weghe:

One thing I'm starting to think of is just having a very basic
Trajectory base class in OpenRAVE that can then be subclassed by
different specific trajectory types.  That way you don't have to put all
the different varieties of geometry and timing in a single class.  It
would also open the door for trajectory plugins, so that a user could
easily have the same trajectory functions loading into OpenRAVE and also
running on their own controller.  The base class could have virtual
functions for adding/modifying points, sampling, and
serializing/deserializing, but it wouldn't have to know much beyond that.

== Usage Cases ==

• Planner uses the trajectory class easily to produce timestamps. It should be up to user to select trajectory type, so planner shouldn't have to deal with this.
• Users can create, append, retime, and serialize trajectories both in C++ and Python.
• Store arbitrary animations of an environment. Need support for any configuration space (similar to PlannerParameters) so that multiple bodies + affine transformations are supported (ie robot opening door).
• Play back a trajectory. Current mechanism is to pass it to a controller. Although this has been working fine, how would trajectories having multiple bodies be played back easily?
• Controller (on robot side) can link with openrave-core and use the trajectory class for interpolating (or possibly retiming) incoming trajectory data. Therefore, it should be possible to play back the trajectory classes without loading any robots. However, the usage case with a robot existing should be optimized for.

== Notes ==

• If the trajectory geometry changes, then the timing calculations would have to be done on a planner side so that constraints and collisions are checked. Therefore, all trajectories should support a "Modifies Geometry" query.
• Retiming should also be considered a planning process since it deals with robot movement. Perhaps have a planner that can take in a trajectory, an initial path, and the PlannerParameters structure that describes the configuration space/constraints for interpolation.
• The interpolation method should be also sent to the controller along with the timestamps. That should allow the computed trajectory to be regenerated perfectly.
• add quadratic solvers (quintic smoothing + retiming)
• Dividing it into 2 subclasses? one class that users use to fill the trajectory with data and perform the retiming, and another class of the re-timed trajectory that would be only used for querying the position, velocity, and acceleration of each of the joints at every time step.
• The computation time of a trajectory can greatly differ depending on interpolation mode. If at one point there is 10 different timing algorithms available to choose from, users will need to quickly decide which is best for their application. This can be done with "Supports" or "Modifies" flags like: "Geometry Modified", "Arbitrary Configuration Spaces", "Velocity Limits", "Acceleration Limits", "Collision Checking", "Constraint Checking" (_constraintfn), etc

os.path.relpath does not exist.

make sure to add an automated test with ubuntu 8.04 to jenkins with virtualbox before closing this ticket.

also, collada-dom relies on XML_PARSE_HUGE being defined, check for this flag in cmake.

mimic equations cannot support dummy joints that have J1xxx where J1 is a real joint name, since J1 gets selected before J1xxx

could solve this by arranging the joint names to be checked from longest to shortest.

The new library allows openrave to use it without internal modifications. make sure to email fedora thread when it is done.

dual sda10d gripper not initially in correct location after loading (but gets fixed when calling SetDOFValues)

add example robot to openrave repository

None

None

inversekinematics generation doesn't depend on the geometry of the robot, so should only create a hash depending on the kinematics structure starting at the base and ending at the end effector.

The ColladaWriter::Save method uses minizip to write compressed (zae) files. This puts a dependency on minizip that really should go into collada-dom rather than openrave.

there are two places to put it in collada-dom:

daeLIBXMLPlugin.cpp

or

daeIOPluginCommon.cpp

It seems that daeIOPluginCommon handles the zlib stuff... but it would be really faster if daeLIBXMLPlugin did it.

OPENRAVE_DATABASE will allow multiple database directories to be read, with priority given to the first

when writing first directory in OPENRAVE_DATABASE will be used

if OPENRAVE_DATABASE does not exist, use OPENRAVE_HOME

Give it parameters:

TriangulateOptions options, const std::string& name

similar to trianglatescene. perhaps rename TriangulateOptions?

Some information from _voffsets is getting left over into _tRight and _tLeft.

self-collision with independent links should be checked... in almost all cases this would be a desired property. however, openrave separates env collision from self collision calls, so perhaps it is better to create a new function and have independent checking?

From Daniel Leidner:

as i was playing around with the collision reports i found out some
additional importance about the distance queries active_dof only feature:

if your robot stands very close to some sort of table, the distance
query gives you always a very short distance due to the overall position
of the robot.
for example the base or the wheels are usually very close to the table
(or much worse the floor).
but i dont want to know that the robots feet are allmost colliding with
the floor o_O what i am interested in is my moving manipulator!

when planning for manipulator, ignore initial collisions with base link (since that doesn't move). Make sure to reflect this in the CO_ActiveDOFs option.

currently the classes hashes do not include whether dReal is float or double. EnvironmentBase is also not authenticated

specifically get pr2 dynamics working in ODE.

body transformations is misleading, should also conform to GetLinkVelocities

    virtual void GetLinkTransformations(std::vector<Transform>& transforms) const;

    virtual void GetBodyTransformations(std::vector<Transform>& transforms) const RAVE_DEPRECATED { GetLinkTransformations(transforms); }

    virtual void SetLinkTransformations(const std::vector<Transform>& transforms);

    virtual void SetBodyTransformations(const std::vector<Transform>& transforms) RAVE_DEPRECATED { SetLinkTransformations(transforms); }

IkSolver::SetCustomFilter should be transformed to

boost::shared_ptr IkSolver::RegisterCustomFilter()

where the returned handled maintains the registration of the filter similar to how plotting and other registrations work.

passing options like 'skipgeometry' should make environment loading faster for analysis

specify debug contexts like per environment, per plugin, etc. this is related to better logging and log4cxx stuff.

smoothing is a post processing step on a path (it needs to know path constraints, but does not need to search). possibly add a path smoothing class

remove _bComputeSmoothPath from planner parameters

it is getting very annoying to have to create a new manipulator just to change the grasp direction.

also, grasping for 5D IK needs an "approach direction", which is different from the "manipulator direction"

new users might not have set PYTHONPATH

add joint resolutions and weights as planning parameters to collada. after this, perhaps add some auto-generation step that fill sthe correct weights for each of the robots (otherwise hanoi won't work with default weights)

have a script that runs through all available plugins in openrave and records the interfaces they offer and who they were developed by.

== kinbody kinematics, geometry, transformations, basic information retrieval, updating ==

• transformation: SetTransform, GetTransform, SetBodyTransformations, GetBodyTransformations
• joint: SetJointValues, GetJointValues
• info: GetDOF, SetName/GetName, GetJointLimits, ,GetJoints, GetLinks
• AABB: ComputeAABB
• body hierarchy: DoesAffect
• link geometries: hinge, slider, and spherical
• any structural change to the body (new kinematic structure) or positional change should be propagated and update the corresponding time stamp and kinbody properties, which can be checked by GetUpdateStamp and KinBodyProperty
• any static property change should trigger RegisterChangeCallback

== initializing, adding, and accessing objects ==

• creating objects
• reading bodies through '''ReadKinBodyXMLFile''' and '''ReadKinBodyXMLData''' (the Data functions allow you to pass XML directly)
  * load a kinbody with bad grammar using '''ReadKinBodyXMLFile'''
  ** load a kinbody with good grammar using '''ReadKinBodyXMLFile'''
  ** add the loaded kinbody to the environment using '''AddKinBody'''
  ** check # of bodies the environment using '''GetBodies'''
  ** check added body's networkid using '''GetNetworkId'''
  ** check added body's name using '''GetName'''
  ** check added body's transform using '''GetTransform'''
• reading robots through ReadRobotXMLFile and ReadRobotXMLData
• adding objects to the environment through AddKinBody, AddRobot; accessing through GetKinBody, GetRobot

== destroying kinbodies ==

• make sure all destructors are called properly
• to test shared pointers: have several kinbodies each using one more feature than the other, e.g., first kinbody has just one link, the next has several links and introduces joints

current openrave represents inertia as the tensor, however this requires doing a eigenvalue analysis to get the major axes. instead, it would be simpler to represent inertia as the mass frame (COM + orientation of major axes) and a 3 vector inertia.

Using "with env" locks the python thread from C++, which causes a deadlock if the python thread holding the environment lock needs to be switched over.

The reason is because the python threading/locking and c++ mutexes are independent.

A temp workaround is to always create a environment lock on the python side and lock that always before attempting the C++ lock.

update collada writer so written files can be read back by openrave

because hashes on the robots can change (and they currently are not consistent across OSes), we should add a feature that manually loads the database files given the filename. Passing an argument to load()?

I've tried to compile a simple test that is linked with the libopenrave0.4.so, but this shared object contains a dependency from clock_gettime function:

264: 00000000 0 NOTYPE GLOBAL DEFAULT UND clock_gettime

This function is from librt.so library that doesn't listed in the NEEDEDs of libopenrave0.4.so:

0x00000001 (NEEDED) Shared library: [libxml2.so.2]
0x00000001 (NEEDED) Shared library: [libboost_date_time.so.1.44.0]
0x00000001 (NEEDED) Shared library: [libboost_thread.so.1.44.0]
0x00000001 (NEEDED) Shared library: [libboost_filesystem.so.1.44.0]
0x00000001 (NEEDED) Shared library: [libboost_system.so.1.44.0]
0x00000001 (NEEDED) Shared library: [libmpfr.so.4]
0x00000001 (NEEDED) Shared library: [libgmp.so.10]
0x00000001 (NEEDED) Shared library: [libstdc++.so.6]
0x00000001 (NEEDED) Shared library: [libm.so.6]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]

I think one of the possible solution is to add -lrt flag when compiling the library.

check out LMPL

http://www.indiana.edu/~motion/software.html

loading pr2 crashes on windows when instance_sensor is added

mehmet dogar says:

I have a grasp planner which can also reason about
moving obstacle objects out of the way, if needed. Given a pose of the
robot hand to grasp the goal object, it gets all the other colliding
objects, and then plans to move them away, so that the original grasp
can be executed.
In fact, I have already been doing this by calling CheckCollision over
and over until no collision occurs, each time adding the object
pointed to by report->plink1 to the vbodyexcluded argument to the next
CheckCollision. Then, when CheckCollision returns false, vbodyexcluded
gives you all the colliding bodies. But of course this takes a huge
amount of time.

at least add this into the oderave collision checker before making the option official. If option is set, then CollisionReport::vLinkColliding should be filled. contacts holds all points for all links.