LeggedSim integration in USARSim 2.x - Scale issue

[2006.07.04]

 

Last days I worked to integrate LeggedSim in USARSim. I planned the integration in several steps:

  1. Merge LeggedSim and USARSim 2.0.5 unreal scripts
  2. Take a note of any code difference
  3. Verify that all work properly
  4. Scale robots and maps
  5. Verify that all work properly
  6. Discuss changes in the code with other USARSim developers
  7. Merge with the last USARSim release
  8. Verify that all work properly
  9. Commit

Ok, I thought it was easy, but actually I'm stuck on point 4 :-) The reason is that the new USARSim scale (1m = 52.5uu) appears to be too small. There are unreal engine parameters that don't scale, like frustum near clipping plane fixed to 6uu (more or less). Although we don't have the Karma engine source code, I observed that even this engine has some fixed parameter as the accuracy of the physics simulation seems to decrease at lower scales.

When I scaled and tested the AIBO in the yellow map I experienced a very unstable simulation. So I built a new, simple map where to carry out KSP (Karma Simulation Parameters) tuning. After a lot of testing I was able to improve the situation, however I never matched LeggedSim performance (that uses the old scale, 1m = 250uu). To show you the results I'll include here some testing session:

Test A

KSPdefault.mpg
The simulation is absolutely unstable.

Test B

KSPusarsim.mpg
Same results as Test A.

Test C

KSPlegged.mpg
Simulation is much better, however legs and other parts still penetrates a lot in the ground, movements are not correct and scripted sequences show that the physical behavior is far from optimal. With the same params LeggedSim performs very well (see the Legged movies: Physics, Soccer, QRIO)

Test D

KSPtestD.mpg
This test uses the same params as Test C but tries to reduce penetration in the ground using a higher PenetrationScale. The result is almost identical to Test C, penetration is smaller but the ground still appears to be "soft". It seems like the resulting force exerted from the ground is Fground = penetration * PenetrationScale * alfa, where alfa is some constant, perhaps it's more like Fground = f(penetration, PenetrationScale, ...) where f() is some "not so simple" function :-). I want to point out that there's always some penetration and, what's worse, it doesn't scale: if you use a smaller scale for the simulator it will be deeper and unavoidable. If you decrease the robot mass the simulation becomes unstable, that's why I was able to decrease the AIBO mass only at 65%.

Test E

KSPtestE.mpg
I increased PenetrationScale in order to decrease another bit the penetration. I also set a different gravity scale for the robot parts because I cannot increase AIBO mass, as it causes the robot to sink in the ground, but I also need higher forces to act on the parts due to gravity. The result is that the penetration is a little smaller (not so much) but the behavior of the AIBO is almost unchanged.

I made a lot of other tests but this report is becoming quite long (and I have other things to say) so I'll link here the movies of only other 3 tests where I tried to minimize penetration, correct AIBO rotation and increase gravity forces, but without much success (I never set manually the inertia tensors so this is the last thing I can try).

KSPtestF.mpg

KSPtestG.mpg

KSPtestH.mpg

I made all these tests only with the AIBO as I believe that QRIO would have been a much harder challenge. Moreover I used UT in client only mode as server+client configuration involves replication that introduces other noise in the simulation.

However physics is not the only problem. I already mentioned the near clipping plane. Here you can see what happens:

     
Near clipping plane cuts the ball and the floor (color buffer is never erased to optimize performance, that's why you see odd things on the ground).
At this scale the clipping plane acts at long distances.

Even with LeggedSim I have the same problem, but as the scale is bigger there, clipping acts at a much lower distance. Jijun had the idea of moving back dynamically the camera to avoid clipping, however at the current scale adopted by USARSim 2 the camera would go behind the head itself! The only solution to this problem is to use a bigger scale, otherwise no one would ever be able to use vision on AIBO or other similar robots.

I suppose you chose the actual scale factor after you have read this page: http://wiki.beyondunreal.com/wiki/General_Scale_And_Dimensions. However I don't agree on that choice because I experimented that a larger scale works better with physics and replication (and is easier to work with). The only advantage of reducing the scale is to have a greater world (or I'm missing something?). As the map size in UT2004 is fixed to a maximum of 524288 uu, with a scale of 1m = 52.5 uu you could make a world 10Km x 10Km wide. But who could ever build such map? And I'm sure that it would be far too large for the unreal engine 2. Even with the LeggedSim scale (1m = 250uu), derived from USARSim 1, you have 2Km x 2Km at your disposal. I would even like to try the scale 1m = 500uu and verify if the physics accuracy improves (at least I could solve the clipping problem).

Is it too late to change USARSim scale? I suppose it is...

Any suggestion is welcome! Tomorrow I'll try QRIO, I'm curious to see how it behaves in the new scale.

If you're still reading I want to warn you about an error in the Zerg model: it has self colliding primitives. Watch this video: Zerg.mpg, the new camera model generates a lot of self collisions.
Another question is: why you use almost always triangle meshes as collision primitives? It would be much better to use high performance objects like spheres, cylinders and boxes. Triangle meshes are computationally very expensive and slow down the simulation. Besides you use even non convex meshes (that are split in convex hulls by Unreal Editor), this is not recommended.