osrf / vrx

Virtual RobotX (VRX) resources.
Apache License 2.0
389 stars 178 forks source link

Increasing obstacle penalty in acoustic tracking task #685

Closed caguero closed 12 months ago

caguero commented 1 year ago

As discussed offline, we're bumping the penalty for hitting obstacles from 0.1m to 1m.

M1chaelM commented 1 year ago

This looks like a very straightforward change, so I'm not sure if it's related to the problems I'm experiencing, but it seems like too many collisions (or collisions that are too violent?) cause the simulation to crash. The error I get on runs with more than a couple collisions (e.g. 6-12) seems at least superficially to have something to do with collisions:

[ruby $(which gz) sim-1] ODE INTERNAL ERROR 1: assertion "aabbBound >= dMinIntExact && aabbBound < dMaxIntExact" failed in collide() [collision_space.cpp:460]
[ruby $(which gz) sim-1] Stack trace (most recent call last):
[ruby $(which gz) sim-1] #31   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7efc233a2c96, in 
[ruby $(which gz) sim-1] #30   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7efc2339ffc5, in 
[ruby $(which gz) sim-1] #29   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7efc2339dc34, in 
[ruby $(which gz) sim-1] #28   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7efc232e9a1e, in 
[ruby $(which gz) sim-1] #27   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7efc232149ac, in rb_protect
[ruby $(which gz) sim-1] #26   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7efc233acc61, in rb_yield
[ruby $(which gz) sim-1] #25   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7efc233a830c, in rb_vm_exec
[ruby $(which gz) sim-1] #24   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7efc233a2c96, in 
[ruby $(which gz) sim-1] #23   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7efc2339ffc5, in 
[ruby $(which gz) sim-1] #22   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7efc2339dc34, in 
[ruby $(which gz) sim-1] #21   Object "/usr/lib/x86_64-linux-gnu/ruby/3.0.0/fiddle.so", at 0x7efc1f10344b, in 
[ruby $(which gz) sim-1] #20   Object "/lib/x86_64-linux-gnu/libruby-3.0.so.3.0", at 0x7efc2336b088, in rb_nogvl
[ruby $(which gz) sim-1] #19   Object "/usr/lib/x86_64-linux-gnu/ruby/3.0.0/fiddle.so", at 0x7efc1f102d6b, in 
[ruby $(which gz) sim-1] #18   Object "/lib/x86_64-linux-gnu/libffi.so.8", at 0x7efc1f0f4492, in 
[ruby $(which gz) sim-1] #17   Object "/lib/x86_64-linux-gnu/libffi.so.8", at 0x7efc1f0f7e2d, in 
[ruby $(which gz) sim-1] #16   Object "/home/mrmccarr@ern.nps.edu/gazebo_ws/install/lib/libgz-sim7-gz.so.7.0.0", at 0x7efc1e60396a, in runServer
[ruby $(which gz) sim-1] #15   Object "/home/mrmccarr@ern.nps.edu/gazebo_ws/install/lib/libgz-sim7.so.7", at 0x7efc1e26299c, in 
[ruby $(which gz) sim-1] #14   Object "/home/mrmccarr@ern.nps.edu/gazebo_ws/install/lib/libgz-sim7.so.7", at 0x7efc1e27563a, in gz::sim::v7::SimulationRunner::Run(unsigned long)
[ruby $(which gz) sim-1] #13   Object "/home/mrmccarr@ern.nps.edu/gazebo_ws/install/lib/libgz-sim7.so.7", at 0x7efc1e274dd0, in gz::sim::v7::SimulationRunner::Step(gz::sim::v7::UpdateInfo const&)
[ruby $(which gz) sim-1] #12   Object "/home/mrmccarr@ern.nps.edu/gazebo_ws/install/lib/libgz-sim7.so.7", at 0x7efc1e26b7e9, in gz::sim::v7::SimulationRunner::UpdateSystems()
[ruby $(which gz) sim-1] #11   Object "/home/mrmccarr@ern.nps.edu/gazebo_ws/install/lib/gz-sim-7/plugins/libgz-sim-physics-system.so", at 0x7efc04723b88, in gz::sim::v7::systems::Physics::Update(gz::sim::v7::UpdateInfo const&, gz::sim::v7::EntityComponentManager&)
[ruby $(which gz) sim-1] #10   Object "/home/mrmccarr@ern.nps.edu/gazebo_ws/install/lib/gz-sim-7/plugins/libgz-sim-physics-system.so", at 0x7efc0470e6c3, in gz::sim::v7::systems::PhysicsPrivate::Step(std::chrono::duration<long, std::ratio<1l, 1000000000l> > const&)
[ruby $(which gz) sim-1] #9    Object "/home/mrmccarr@ern.nps.edu/gazebo_ws/install/lib/gz-physics-6/engine-plugins/libgz-physics-dartsim-plugin.so", at 0x7efbec8b0e9c, in gz::physics::dartsim::SimulationFeatures::WorldForwardStep(gz::physics::Identity const&, gz::physics::SpecifyData<gz::physics::RequireData<gz::physics::WorldPoses>, gz::physics::ExpectData<gz::physics::ChangedWorldPoses, gz::physics::Contacts, gz::physics::JointPositions> >&, gz::physics::CompositeData&, gz::physics::ExpectData<gz::physics::ApplyExternalForceTorques, gz::physics::ApplyGeneralizedForces, gz::physics::VelocityControlCommands, gz::physics::ServoControlCommands, std::chrono::duration<long, std::ratio<1l, 1000000000l> > > const&)
[ruby $(which gz) sim-1] #8    Object "/lib/x86_64-linux-gnu/libdart.so.6.12", at 0x7efbec4f5e73, in dart::simulation::World::step(bool)
[ruby $(which gz) sim-1] #7    Object "/lib/x86_64-linux-gnu/libdart.so.6.12", at 0x7efbec4db705, in dart::constraint::ConstraintSolver::solve()
[ruby $(which gz) sim-1] #6    Object "/lib/x86_64-linux-gnu/libdart.so.6.12", at 0x7efbec4d9fe1, in dart::constraint::ConstraintSolver::updateConstraints()
[ruby $(which gz) sim-1] #5    Object "/lib/x86_64-linux-gnu/libdart-collision-ode.so.6.12", at 0x7efbec6dd1cb, in dart::collision::OdeCollisionDetector::collide(dart::collision::CollisionGroup*, dart::collision::CollisionOption const&, dart::collision::CollisionResult*)
[ruby $(which gz) sim-1] #4    Object "/lib/x86_64-linux-gnu/libode.so.8", at 0x7efbebfd8266, in dxHashSpace::collide(void*, void (*)(void*, dxGeom*, dxGeom*))
[ruby $(which gz) sim-1] #3    Object "/lib/x86_64-linux-gnu/libode.so.8", at 0x7efbebfe07b7, in dDebug
[ruby $(which gz) sim-1] #2    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7efc22f6e7f2, in abort
[ruby $(which gz) sim-1] #1    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7efc22f88475, in raise
[ruby $(which gz) sim-1] #0    Object "/lib/x86_64-linux-gnu/libc.so.6", at 0x7efc22fdca7c, in pthread_kill
[ruby $(which gz) sim-1] Aborted (Signal sent by tkill() 10188 766438638)

I also tried a run without moving the WAM-V at all and one with only 2 collisions and it didn't crash.

caguero commented 1 year ago

I managed to reproduce this issue on main, so I think it's not related with this PR.