Added KinBody.LinkInfo and KinBody.JointInfo classes in order to programatically build robots by calling KinBody.Init().

Fixed bugs in RobotBase::CalculateActiveJacobian (thanks to John Schulman)

SetUserData now supports a key to allow different modules to store their own uninterrupted user data. KinBody.SetCollisionData, KinBody.SetPhysicsData, KinBody.SetViewerData are deprecated. It can also be called through const pointers.

Debian packages of different openrave versions will now install without conflicting with each other since they will share no common files. symlinks pointing to non-versioned programs are written in a version-independent ‘openrave’ package.

added a new planner parameter _neighstatefn that adds two states together.

added a RobotConfiguration sampler for sampling robot active DOFs used for planning

added a Halton Sequence sampler

removed the PlannerParameters::_constraintfn and replaced it with PlannerParameters::_checkpathconstraints. Combined with _neighstatefn, the behavior of the old PlannerParameters::_constraintfn can be achieved. Allows us to remove all collision calls and dependencies on robots from planners!!

removed the PlannerParameters::_tWorkspaceGoal parameter since it is non-generic and not used in openrave.

added PlannerParameters::_sampleinitialfn to sample initial goals for the planner

added a _fromgoal parameter to PlannerParameters::_neighstatefn so users can know which direction the tree is growing in.

added a new openrave/planningutils.h file that contains many functions/heuristics to help users build planning algorithms.

adding the soversion suffix to all libopenrave libraries: libopenrave -> libopenraveX.Y. There is no libopenrave or libopenrave-core anymore, so linking with “-lopenrave” or “-lopenrave-core” will fail.

Documentation infrastructure rewritten. It now uses mostly reStructuredText and compiled with sphinx. the official openrave homepage is also outputted by sphinx. this allows us to combine interfaces, testing results, python docs, and C++ docs all in one. epydoc has been removed.

The robot database is now compiled from the ikfast results with robot images and links to the testing server.

Added OPENRAVE_DLL and OPENRAVE_DLL_EXPORTS to control import vs export of symbols. This changed the FindOpenRAVE.cmake file changed.

Added a “Release” cmake build type that disables all stl/boost asserts and security checks. This will produce the most optimized code possible, but should be used only for well-tested production code. (default build is still RelWithDebInfo).

Removed “vanchor” parameter from KinBody::Joint since it could be autogenerated.

Moved all configuration files to the build (BINARY) folder rather than have it in source. The
build process for configuration files changed a little to accommodate simultaneous builds with
different options better. This allows us tohave double/float precision + debug/release all at the
same time without forcing a rebuild. In order to avoid any collision troubles, the following files
were renamed:

classhashes.h -> interfacehashes.h
defines.h -> config.h

updated zlib 1.2.5 and minizip

Added more joint types involving all permutations of revolution and prismatic joints! For example Revolute, Revolute, Revolute or Revolute,Prismatic. or Prismatic,Prismatic,Revolute. In order to support joints with multiple axes better, many of the fields were changed from single values to vectors of values. Most of the Joint::Get* methods now take an axis index.

Organized the joint hierarchy and added a Joint::_ComputeInternalInformation to do some of the preprocessing that was previously done in the individual readers.

Added normalizeAxisRotation - Find the rotation theta around axis such that rot(axis,theta) * q is closest to the identity rotation. This is used in extracting joint angles and converting rotation to euler angles.

Kinematics hierarchy now supports closed-chains correctly. It uses graph theory to find places to find the loops and how to compute link transformations with the least dependencies. This information is pre-computed in KinBody::_ComputeInternalInformation() making calls to SetDOFValues/SetDOFVelocities much faster. Some of the added functions:

KinBody::GetClosedLoops - returns all the unique closed loops of the robot.
KinBody::GetChain - returns a chain of joints or a chain of links
KinBody::Link::GetParentLinks - returns all parent links
KinBody::Link::IsParentLink
KinBody::Joint::GetHierarchyParentLink - joint values computed in this coordinate system
KinBody::Joint::GetHierarchyChildLink - joint moves this link
KinBody::GetDependencyOrderedJoints - will return the joints in the correct topological order.

Thanks to Nick Hillier for giving us the Bobcat S185 skid-steer loader model to test closed-chains with! This robot has 11 joints with 3 closed-loops and only 2 degrees of freedom, which makes it an interesting challenge.

Started development on a new tool called ‘fkfast’. It solves the analytic equations for closed loops. It turns out that the Bobcat fk requires a quadratic equation to be solved with coefficients involving powers up to 8. Combined with the new mimic joint features, openrave can solve and simulate the mechanism correctly! If anyone is interested in checking it out, here’s the corresponding file (from ticket #94):

fkfast is still experimental, so is not as usable as ikfast. For anyone curious, the file can be found in

Introduced a new planner called “WorkspaceTrajectoryTracker” that can take arbitrary trajectories of the end effector and quickly produce smooth configuration space trajectories that can follow the workspace path. The planner can also follow constraints as specified in the PlannerParameters::_constrainfn. The “MoveHandStraight” function now defaults to this planner. There’s an example that shows off this functionality here:

Cleaned up velocity functions in the physics engine (interface is simpler). KinBody class now converts joint velocities to link velocities (and vice versa) internally. All joint velocity functions have been removed from the physics engine interface, ie only link velocity functions are offered. Link velocities always point to the link’s coordinate system origin (not the center of mass).

Setting velocity behaves similar to setting dof values. the default physics engine now stores velocities (it did not before).

Controller interface cleaning up, setting a controller on a robot now requires the degrees of freedom that the controller uses to be specified. The controller dof features allows multiple controllers to use the same robot without interfering with each other.

Added a MultiController class to simplify setting multiple controllers per robot. A C++ example is shown in the ormulticontrol C++ demo:

Separates the global OpenRAVE state from the environment state. The main reason for this move was for better management of multiple environments and for a new upcoming ROSEnvironment class that will integrate better with the ROS package file system.

More specifically, the new global state

manages plugins/interfaces

allows users to better manage multiple environments

manages debug levels

fixes many race conditions by organizing destruction order of all global resources.

allows destruction of entire OpenRAVE state and all resources using a single call: RaveDestroy. These changes fix all thrown exceptions when a program exits.

OpenRAVE is initialized by first calling RaveInitialize, independent of the environment.

A sensor can be added into the environment without a robot using Enviornment.AddSensor()

All the sensors in the environment can be queried using Environment.GetSensors, this returns all
sensors attached to all the robots and all the environment sensors. Individual sensors can be
queried by name using Environment.GetSensor().

Can now store sensor parameters in side *.sensor.xml files and include them from a parent xml file
using the file=”...” attribute. This applies to all interface types, not just sensors. Here’s a tutorial.

Added IMU sensor definitions

Cloning treats sensors separately now. In order to clone sensors (robot+environment), the Clone_Sensors option has to be specified. The definitions of the robot attached sensors are still cloned, but not the internal interfaces.