Date: Fri, 6 Jun 2003 11:18:24 -0400 (EDT)
From: arizzi@benedict.msl.ri.cmu.edu
To: kod@umich.edu, Mark Cutkosky <cutkosky@cdr.stanford.edu>, Richard Altendorfer <altendor@eecs.umich.edu>
Cc: Alfred Rizzi <arizzi@benedict.msl.ri.cmu.edu>,  Martin Buehler <buehler@cim.mcgill.ca>, ulucs+@ri.cmu.edu
Subject: Initial thoughts about the RiSE simulations system

Folks,

Uluc and I have been talking about the options for the simulation
tools we will use on the RiSE project over the past few weeks, and are
starting to make some reasonable progress outline the options
available to us.  We will be sending out (shortly) a more technical
overview of the options that have been identified, and what their
implications might be for us.  My intent, here, is to focus us on what
the potential issues are and attempt to summarize my belief about what
are requirements are.

1) We need (internally) a set of tools that will allow us to
   effectively simulate performance of the evolving designs -- this
   will serve as both a design aid and verification tool for the
   platform designers as well as a surrogate system for the early
   behavior and control system developers.  I take this to imply that
   we need reasonably accurate full body dynamics simulation and some
   quality of ground/surface interaction simulation.

2) We need (for Bill McBride and SwRI) a means to provide predictions
   of performance over obstacles and during trials.  Possibly they
   will want to compare "full state" recordings from the robot
   performing a task to the "full state" predictions that come from
   our simulation and make some effort to resolve any discrepancies.
   At very least they will want to compare aggregate performance
   metrics such as speed, power consumption, and "success" between
   simulation and actual trials.  In this area Raibert's tools will
   probably represent the standard to which we will be compared.

3) We believe it is critical that our simulation tools be well
   integrated with our control system, allowing us to use the same
   behavioral control software both in simulation and on the robot.
   This has three significant benefits for us; i) it provides a s/w
   test and development environment that mirrors the robot (this has
   been a HUGE benefit during the RHex project), ii) it reduces the
   s/w support tasks by making the simulation and actual control s/w
   suites essentially identical, iii) it allows us to simulate with
   the "actual" control systems we use on the robot improving
   predictive quality of the simulations.

And here are a few observations about the current state of affairs in
the RHex project, some assumptions about our needs/desires and some
considerations to keep in mind as we make a decision.

SimSect++ is the current tool we use for RHex:
  - it is well integrated with our control software
  - the internal software architecture of SimSect is VERY opaque
    - difficult to adapt to new robot morphology
    - separate hand written code describing each possible contact
      configuration and transitions between contact states
  - it includes support for simulation of "continuous time" control
    systems -- not clear this will be useful in the future

Given our likely evolution of body design, we would like to have
certain features in our system:
  - some sort of "creature description language" 
  - a reasonably flexible environmental description/specification system
  - automatic generation/simulation of equations of motion and contact
    resolution

From a maintenance perspective some qualities we desire include:
  - well documented interfaces that enable an appropriate level of
    integration with our control systems
  - workable support structures to support our endeavors
    (documentation, openness of interfaces, good TechSupport for
    closed products)
  - expected longevity of the tool/product

Some open questions:
  - Simulation accuracy?
    - integration scheme (fixed time step vs. adaptive RK45)
    - impact/constraint modeling/satisfaction (constraint satisfaction
      vs. impulsive "correction" vs. Lagrange multiplier/surface
      penetration)
  - Speed?
  - Multi-platform/OS support?
  - Cost?

The one thing that seems clear is that we will only have a nominal
level of effort from within our group dedicated to development and
support of our simulation system.  So it is critical that we choose an
approach that delivers high-benefit with minimal-effort.

-- NoahCowan? - 10 Jun 2003