Simulation Capabilities

This page is meant to provide a view of the simulation environment from the vantage point of a programmer. I will detail the current capabilities, as well as shortcomings, of our currently-chosen simulation environment, the Arachi Dynamics Engine (DE).

For producing simulations of the robot's dynamics, our need is to have a good environment which not only provides accurate rigid body modeling and collision detection, but also allows us to easily add arbitrary forces and events, needed for simulations of compliant mechanisms and surface contact models.

In our search (see SimulationComparison) we did not find any packages which had support, to boot, for surface interactions like those we hope to model. It is our hope, through working with the small team of developers at Arachi, that we will be able to integrate reasonable methods for doing advanced modeling like this into the simulation environment.

Current Capabilities

  • DE provides an excellent interface for defining the geometry and dynamical properties of an object. Every object has a local coordinate frame, making it very easy, in code, to create connections between objects, and define degrees of freedom at joints.
  • Contact-based events: DE provdes us with extremely accurate collision times, thus we can generate events which occur exactly when objects make contact.
  • Time-based events: given their extensive Controller class and TimeEvent objects, we can design time-based events very easily.
  • Force modeling: an arbitrary force can be applied to an object, calculated from the state of the system (such as modeling springs). There are some tricks here to speed things up, like how you should connect forces to objects, depending upon how the objects are related to each other.
  • Exact geometries: DE is capable of modeling a sphere exactly, rather than estimating it through triangular meshes. Detecting collisions between these hulled-surfaces is very efficient. Unfortunately, detecting collisions between triangular mesh objects (arbitrary shapes) is slow in comparison.
  • more

Future Additions - things we plan to support on top of DE

  • RTI - Real Time Interface for virtual control/sensing
  • PCM - Parametrized Contact Mechanics
  • CDL - Creature Description Language
    • The library currently has no methods for inputing a geometry from file. I hope to eventually allow a creature to be defined in a plain text file, possibly later allowing individual components to be defined through common CAD formats (such as STEP AP203) [see note above about slow execution when using complex, arbitrarily-shaped objects].
  • more

Currently Unknown Capabilities - questionable features that we may or may not see implemented in future versions of DE

  • State-based events: we are uncertain how to trigger events/generate forces based upon arbitrary states. Some examples are modeling springs (confirmed to be possible) as well as using force-based constraints (such as letting a foot peel off of a surface only once a force threshold is passed)
    • For springs and other arbitrary forces, we hope Arachi will allow us a way to hook in our own functions to their integrator. The integrator would call our function which would return a value of the force. In order to allow coupling of forces, these functions would need full state of the world, rather than being passed the state of a single DOF. These functions should not modify the state of the world. (UPDATE: this is confirmed to be available in the library, though there are tricks to improve efficiency. See above)
    • To create events that modify the state of the system, we need a method to determine whether any discontinuities occurred between timesteps of the system, and have the system hone in on the exact time of discontinuity, much like how to Mirtich-style algorithm hones in on collision time. Then, we could trigger our event, and continue on with timesteps/integration.
  • more

Code Examples - these are some examples I am currently coding up, of which I hope to post rendered movies

  • the modeling of compliant linkages, such as RHex's circular legs
  • ability to detect exact collision times and modify state based upon collisions (in other words, implement the simplest sticky-block simulation)
  • modeling of a 4-bar linkage - show that it behaves as we expect it to. Perhaps hook two 4-bar leg actuators up to the sticky-blocks (above) and make it climb a wall. Now that'd be fun!
  • more

-- ClarkHaynes? - 23 Sep 2003

 
This site is powered by the TWiki collaboration platformCopyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback