Any suggestions on avoiding the NaN explosion in DRC sim?

asked 2013-03-28 08:49:11 -0500

dcconner
298 ●18 ●22 ●31

I've started seeing issues when we bring our controller online.

The joint commands being sent are valid. Position and velocity commands are continuous with default commands (0.0); effort values are valid but discontinuous.

About 50% of the time, the robot will fall into heap and start to report NaN values for joint velocities and efforts.

I'm going to experiment with using an initialization state that will ramp the efforts a bit more slowly.

One issue that concerns me is that this does not occur if I run the controller alone. It seems to be more of an issue when the larger system is connected. This may point to a timing issue, or something deeper within Gazebo.

Have others seen this issue specifically with DRC sim, and are there suggestions for avoiding or debugging?

edit retag flag offensive close merge delete

Comments

Initializing and slowly ramping the joint command effort didn't help. It turns out I am getting the NaN from drcsim after connection, but before any joint commands are published. Is it possible that drcsim reads a bogus joint command if connected, but nothing published yet? (FYI: drcsim-2.2 release)

dcconner ( 2013-03-28 10:00:33 -0500 )edit

add a comment

1

answered 2013-04-05 15:41:32 -0500

hsu
1873 ●14 ●19

I've seen instability that I suspect to be due to bad chopping of joint commands and possibly states over udp, so this patch was created to make sure the udp message is not fragmeneted. If possible, can you try running from the udp_tweak branch and see if problem persists?

There is a separate issue involving contact, and bad treatment of fdir1 params that leads to NaN's too, but less likely to be your problem here.