pbeeson's profile - activity

I am using the DRC sim, and upon coloring a pointcloud (aggregated from the spinning laser) with the camera data, I noticed really weird issues on the table model that gets automatically downloaded into my .gazebo directory. After hours of debugging, we realized that the model sdf file (both model.sdf and model-1.3.sdf for table) has a different collision geometry than visual geometry (like 10 cm difference in length and some small diff in height), which completely explains why I was seeing floor pixels on both sides of my table top in the colored clouds.

I would like to suggest/request that OSRF go through all models and make sure that visual and collision dimensions for DRC models and standard models downloaded from the Gazebo URI are consistent so that we don't have two different sensing modes seeing different things.

I think the real answer is to try and model the noise as well as the real sensor. Obviously the underlying physics plays a large part in the noise of these sensors, so until the physics settles down I think having having an option to filter noise would be good.

Thanks John, but here's the issue from a User's perspective. You are doing this in the AtlasPlugin.cpp. I don't have access to that in the competition, so I have to run such a filter on the robot machine, which requires a node of my own listening to this message at 1000Hz and publishing filtered data. This isn't a huge issue, but if the BDI sensor has onboard filtering, this really should be done in AtlasPlugin to match the real sensor output, not by users.

I put this as a comment on another thread, and on the DRC Forum, but I was told to start my on question here.

Essentially, we need a definitive writeup on the force torque sensors. A) the frame of reference seem to now be in a non-world frame of reference that is not the foot link or the hand link. B) the hand values seem to be just noise, with values changing wildly even when the robot has no motion at all.

having documented/working force torques sensors is one of the most important issues we have right now. We cannot continue with balancing and walking without them, and right now, we cannot make sense of the data we are seeing.

What is the origin/frame of reference for this? It seems like it's not rfoot link or lfoot link. Also, the lhand and rhand torque and force values (all except Force Z) seems to just be wrong. Getting wildly fluctuating values whenever we start the atlassandiahands.launch simple world (no motion, just unpinned and standing there, arms outstretched).

As of 2.0 thi swas fixed, but as of DRCSim 2.2, this is a problem. The AtlasPlugin tacks "pelvis" on as the link of the IMU, but apparently, the urdf stills defines the imu as living on the imu_link, which is offset from the pelvis. So now, the imu (if you believe it's from the pelvis) is simply wrong.

This pull request works so much better than before, as tuning PID gains on joints doesn't cause the robot to collapse or Gazebo to error due to high effort/velocity values. When can we get this into the Debian repository version so that all my VRC team can start tuning controllers?

This may not be a "bug", but it is an unfortunate situation where Nominal mode (which is difficult to use for control tuning because the robot easily falls/collapses) has steady state offset that requires constant, non-zero force to remain stable, whereas "pinned mode" (which is easy to use for control tuning) does not. More documentation on this at the bitbucket issue above.

We have found a bug where if we keep the Atlas robot pinned, that joint_states reported are correct. however, when switched to Nominal mode (the default when launching Atlas in an empty world after 10 seconds or so), that joint_states starts sending incorrect values but it seems like the internal joint controller sees the correct values, so any kind of closed loop control cannot be performed correctly.

To Reproduce:

Make a node that can sends a position to the neck joint through /atlas/joint_commands.

Launch atlas and watch /atlas/joint_states/positions[3] (the neck) start at 0, then after the robot becomes unpinned, it goes to -0.05 (or similar). Send the joint_command to ask the neck to return to 0. It doesn't, because we think the controller internally believes that it is already at zero.

Now, send the service message to repin Atlas, and watch the joint value go back to 0.

While pinned, you can send the neck joint a new position goal, let's say 0.3. It will go there using the PID in the Gazebo plugin. Unpin the robot, and watch the value go to 0.25. So, because the joint_states for the neck joint are off by -0.05 radians, any closed loop control gets confused because it's always chasing this offset.

I've noticed that because there is no limit checking going on, if you are tuning the PID controller, and choose a bad value for a PID gain, you can easily cause Gazebo to crash (presumably because the effort it commands is too high or low).

In the DRCSim 2.0, I have noticed that when sending position commands (to say for example the neck_ay joint), that the velocities reported by /atlas/joint_states are much higher than the velocity_limits defined in the URDF.

Can we expect this to be fixed for the VRC, or should we continue to assume that we can see velocity and/or effort values that exceed the URDF limits?

I understand why you did this, and I've already got a dropin replacement for the FollowJointTrajectoryAction controller. I just needed to know whether I just spend time doing the same for grasping. Looks like I do. Thanks.

Seems to be fixed in DRCSim 2.0

Is the SimpleGrasp controller used on the DRC Tutorials page supposed to an API for grasping that will be used in the VRC, or is it just a demonstration on how we might write our own controller to send JointCommands to the hands? It is unclear whether I need to write my own, or (supposing this is sufficient for VRC tasks) whether I can rely on this service being run during the VRC.

If this is just an example, then it would be very helpful to explicitly state this in the tutorials so as to not cause confusion. We are still in recovery mode after the dropping of the FollowJointTracjectoryAction controller, and I don't want to have to do the same if/when the grasp controller goes away.

Thanks.

We've noticed that DRC sim 1.3 and earlier) have an IMU that is sending reasonable (yet understandably noisy) data, but there is no transform being published between the pelvis and the imu_link, so that data can't be used. Currently , we are publishing a static transform every second or so between these, but we need to know (A) if this is reasonable, (B) if this will be fixed in 2.0, (C) why the imu_link is set to be a revolute joint in the model and not a fixed joint (goes back to (A)).