Open Discussion on RiSE Simulation Environment

I created this page as a working document to keep track of everybody's feedback on our current list of potential simulator options. I suggest we adopt a "threaded" discussion, where we can use the nesting feature of Twiki (see TextFormattingRules) to add content. If you would like to bring up a point which is previously not mentioned, you can add it to the end of the page.

Note that a detailed summary of our various options can be found in SimulationComparison. I have started a couple threads below for initial discussion

• UlucSaranli - Most of the systems that I have looked at, including Adams and other widely used commercial ones, do not support accurate detection of collisions. Instead, they allow initial penetration of colliding objects and rely on "restoring forces" for gradual correction. Arachi engine is the only package that does iterative refinement to accurately detect the collision instant using Mirtich's TimeWarp algorithm ( see Mirtich's TimeWarp Rigid Body Simulation).
  • add comments here

• UlucSaranli - Integrator accuracy is definitely one of our major concerns. Major commercial packages such as Adams tend to offer a wider variety of options, but libraries such as Arachi and CMLabs Vortex engine offer semi-implicit methods which may perform acceptably for our simulations. OpenDE is definitely weak in this regard as they use an unstable explicit first order integrator.
  • add comments here

• UlucSaranli - Many people confirmed the importance of the software architecture and ease of integration with our control software. In this regard, "engine" libraries are definitely the choice because they offer the most flexibility for integration with existing software. This is definitely the weakest aspect of Adams, as we have experienced in our attempts to control the LGC cockroach model.
  • HaldunKomsuoglu (21 Aug 2003) - I just wanted to point out one thing concerning ADAMS. I have a paper written by Andrew S. Elliot (aelli@adams.com) titled "a general purpose approach for co-simulation with ADAMS" which outlines the implementation of an interface between the simulation states of ADAMS and an external program. I believe I got this paper from Richard Altendorfer (altendor@eecs.umich.edu) who has been working on implementing a controller for the LGC model that is simulated by ADAMS. He has been assisted by Joe Raisanen (jraisane@eecs.umich.edu). I am not following their progress closely but last time I talked to them they mentioned that they got the controller code to work with ADAMS simulation and their most annoying problem was the slow execution caused by the very high degree of freedom of LGC model. It was my understanding that their approach allows them to access all the states of the simulation (read and write). Provided that this API is effective and the simulator engine in ADAMS satisfies our requirements ADAMS can be a very effective (and widely accepted) tool. To better assess I suggest we refer to Richard Altendorfer before he leaves for Germany. Of course, Uluc might have already covered this which renders this comment irrelevant...

• HaldunKomsuoglu (21 Aug 2003) - Although it is not a crucial point we should also think about the visualization tools. A cool animation can have a very significant effect in getting the idea through. Hence, I would like to add the "availability and performance of visualization tool" as a low priority criterion for the simulation environment selection discussion. For instance, as far as I know ADAMS allows you to design complex 3D structures for visualization in a comperatively user friendly GUI. On the other hand, if we choose to go with a tool that has no visualization capability then we will need a second program to convert state information to animation. This could be a program that we write which utilizes openGL or Geoview like libraries, or it could be a thrid party application such as those listed in here.
  • UlucSaranli (25 Aug 2003) - Visualization is definitely something we need. ADAMS is definitely strong in terms of its GUI based editing and visualization capabilities. Unfortunately, that is also one its worst points architecturally. Most of the other libraries I had mentioned in my summaries are OpenGL-friendly and it is relatively straightforward to implement basic visualization of the simulation. They are all based on rigid bodies and constraints among them, which eliminates the need for any custom transformation from generalized coordinates to object coordinates for visualization. Granted the interface and GUI will not be as useful or complete, but we will have visualization capability.

• HaldunKomsuoglu (23 Aug 2003) - Another conveniance issue is the ease of mechanical modeling. The initial discussions of mechanical design of RiSE suggests a rather complicated structure with many degrees of freedom some actuated, some passive and some free. Hence, modeling this system may prove to be a serious issue if we lack proper tools. For instance in a simulation environment built upon a library providing only an integrator engine we would need to manually derive the equations of motion. Note that this is a hybrid dynamical system with many many DOF whose parts have varying machanical properties. On the other hand integrated tools such as ADAMS and WorkingModel provide us with intuitive design tools to describe the system model which would decrease the possibility of error in modeling and cut the design time.
  • UlucSaranli (25 Aug 2003) This is not so much of an issue. Even though the libraries lack user interfaces, the way mechanical systems are defined is by creating rigid bodies and constraints between them. There is no need for manual derivation of equations of motion. The dynamics are computed automatically once the object hierarchy and the associated constraints are defined. We will probably put together a fairly general "creature description language" to ease experimentation with different structures and designs. It will probably not be as "intuitive" as a GUI, but I think the architectural simplicity of using libraries by far outweighs the pains of interfacing with "integrated" design systems.

• ClarkHaynes (26 Aug 2003) - I think it would be safe to whittle our choices down to the following three: ADAMS, CMLabs Vortex Engine, and Arachi's Dynamics Engine (DE). ADAMS is the obvious choice if our only care was accuracy. Unfortunately, it isn't, as we are looking for a cross-platform, portable, lightweight simulation library that we can build a complete "virtual robot world" upon. Between Vortex and DE, I would vote for DE. They are extremely similar, and while Vortex is fleshed out a lot than DE (being a 2.x, almost 3.0, product vs. a pre-1.0 product), it seems like DE's integrator/collision methods are more in tune with our needs. Another advantage of DE is the code size: doing similar tasks between the two libraries seems to take about twice as much code with Vortex. DE uses a philosophy very akin to programming OpenGL, so anyone with any experience doing OpenGL programming could be up and running with DE in a matter of minutes.

• add more threads here

-- UlucSaranli? - 14 Aug 2003