search

osrf / drcsim

Repository for the DRC project.
16 stars 6 forks source link

Increase number of iterations in VRC worlds #166

Closed osrf-migration closed 11 years ago

osrf-migration commented 11 years ago

Original report (archived issue) by Jesper Smith (Bitbucket: jespersmith).

In the VRC qualification worlds, the number of iterations for the ODE engine is set to 40. Increasing this number to 50 leads to large improvements for our walking controller, while not greatly impacting the simulation speed.

It seems that the default Gazebo settings for the physics engine have better performance than the settings in the VRC worlds, aka

#!xml

<ode>
        <solver>
          <type>quick</type>
          <dt>0.001</dt>
          <iters>50</iters>
          <sor>1.0</sor>
        </solver>
        <constraints>
          <cfm>0.0</cfm>
          <erp>0.2</erp>
          <contact_max_correcting_vel>100.0</contact_max_correcting_vel>
          <contact_surface_layer>0.0</contact_surface_layer>
        </constraints>
      </ode>

I propose that it gets changed to the gazebo defaults for now.

#!xml

<ode>
        <solver>
          <type>quick</type>
          <dt>0.001</dt>
          <iters>50</iters>
          <sor>1.3</sor>
        </solver>
        <constraints>
          <cfm>0.0</cfm>
          <erp>0.2</erp>
          <contact_max_correcting_vel>100.0</contact_max_correcting_vel>
          <contact_surface_layer>0.001</contact_surface_layer>
        </constraints>
      </ode>

I do think more testing is necessary for the final parameters of the physics engine.

osrf-migration commented 11 years ago

Original comment by Jesper Smith (Bitbucket: jespersmith).

osrf-migration commented 11 years ago

Original comment by Jesper Smith (Bitbucket: jespersmith).

osrf-migration commented 11 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

Hi Jesper,

Before we make the change permanent, is it possible for you to quantify the amount of improvement in simulation error reduction?

Thanks, John

osrf-migration commented 11 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

osrf-migration commented 11 years ago

Original comment by Chris Atkeson (Bitbucket: catkeson).

I am working on a standing balance test where the feet slide with iters < 70. I want to make sure I am not doing something stupid, and then I will send OSRF the code.

osrf-migration commented 11 years ago

Original comment by DavidC (Bitbucket: DavidC).

Given that BDI interface currently requires 90, is there any reason that any world should have less than that.

Have you been able to reduce the BDI requirements?

osrf-migration commented 11 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

@DavidC: Yes, we've been able to reduce the BDI requirements, AtlasSimInterface_1.0.5 now runs with 40 iterations at 1ms.

osrf-migration commented 11 years ago

Original comment by Jesper Smith (Bitbucket: jespersmith).

John,

We'll try to get some data the coming week, I started to work with the hands and I think the simulation parameters are even more critical for that.

Generally, our walking controller fails within a few steps if the number of iterations is 40, while it walks stable with 50 ( controller time step: 5ms).

osrf-migration commented 11 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

@catkeson: That would be great! Thanks.

osrf-migration commented 11 years ago

Original comment by Chris Atkeson (Bitbucket: catkeson).

I was doing something stupid.

osrf-migration commented 11 years ago

Original comment by Chris Atkeson (Bitbucket: catkeson).

Just to be clear. Iters = 40 with no hands is not the same as iters = 40 with a fully functional pair of hands and with objects such as rubble. When you tested the BDI controller, did it have hands and rubble? The test needs to be done in the VRC environments.

osrf-migration commented 11 years ago

Original comment by Scott Kuindersma (Bitbucket: skuinder).

To date we have been testing our walking controller with dt=0.001, iters=100, SOR=1.2, and a 200Hz asynchronous control loop. I agree that using Jesper's suggested parameters is a significant improvement over the defaults, but I still see undesirable foot vibrations that cause the feet to slide over time while standing. Increasing the iters to 70 as Chris previously suggested seems to remove the foot sliding problem.

FWIW, I get a realtime factor of ~0.96 simulating Atlas without hands using iters=70, SOR=1.3 in the quals 1 world.

I think it's important to point out that the BDI controller isn't a good reference point for selecting appropriate VRC parameters since it isn't running using the same (asynchronous, low-rate) interface as the team walking controllers.

I will also echo Chris' comment about the importance of testing in VRC environments with the hands attached. We will make an effort to relay working parameter values from our tests in these worlds too.

Scott, Team MIT

osrf-migration commented 11 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

yes, we are test the BDI walking controller with Sandia hands, making sure the robot can perform nominal walk behavior and is able to get through some basic dynamic balancing behaviors.

As for number of iterations, testing with

roslaunch atlas_utils atlas_sandia_hands.launch

indicates increasing iterations from 40 to 50 cuts down the rate of feet sliding-while-standing by a about 43% (24mm/min to 13.5mm/min). If SOR is increased from default value of 1.0 to 1.4 simultaneously, overall feet sliding rate is reduced by about 60% (down to 9.6mm/min). The real-time factor suffers by about 7.5% (0.95X to 0.88X real-time) on my desktop. Going from 50 iterations @ SOR=1.4 to 60 iterations @ SOR=1.4 did not produce significant reduction in feet sliding rates for me.

John

osrf-migration commented 11 years ago

Original comment by Maurice Fallon (Bitbucket: mauricefallon).

John: Are you also considering the effect of requesting perception data?

When we subscribe to lidar and vision data the simulation real-time factor hits the floor (e.g. below 0.1 for complex VRC worlds). Have you been able to achieve real time simulation when requesting (and processing) sensor data?

osrf-migration commented 11 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

@faller: I think the laser sensor induced slow down you are describing might be related to issue #186?

osrf-migration commented 11 years ago

Original comment by Jesper Smith (Bitbucket: jespersmith).

Besides walking, I think it is also important to consider noise on the force/torque sensors and stability of contact (especially grasping objects) when deciding good parameters for the physics engine.

I haven't done enough testing on the grasping to be able to tell what values for iterations/SOR should be workable.

osrf-migration commented 11 years ago

Original comment by Jesper Smith (Bitbucket: jespersmith).

Simple tests for measuring joint forces show that for a relatively noise-free torque measurement you need about iter=250 at sor=1.4, depending on the mass of the links. Increasing the CFM parameter might reduce that.

See this bug: https://osrf-migration.github.io/drcsim-gh-pages/#!/osrf/drcsim/issues/199/force-torque-sensors-are-extremely-noisy (#199)

osrf-migration commented 11 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

synchronization implemented in pull request #249

osrf-migration commented 11 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

closed wrong issue

osrf-migration commented 11 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

Please see pull request #494, turned off constraint random reordering, and reduced SOR for contact joints. I believe the physics behaves much better.

osrf-migration commented 11 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

recommendation to use control synchronization approach