Gazebo | Ignition | Community
Ask Your Question

GoRobotGo's profile - activity

2017-02-27 03:34:13 -0600 received badge  Famous Question (source)
2015-07-02 04:25:09 -0600 received badge  Notable Question (source)
2015-07-02 04:25:09 -0600 received badge  Popular Question (source)
2015-03-11 06:17:08 -0600 received badge  Famous Question (source)
2013-07-24 21:01:01 -0600 asked a question DRCSIM / Gazebo Roadmap for DRC Trials

Is there a roadmap for DRCSIM / Gazebo to improve simulation of the DRC trials? We realize that:

  • you don't have an Atlas sitting in your office to help match simulations
  • the validation on Atlas HW is still a ways off
  • AtlasSimInterface may not be supported

Those issues kind of put you between a rock and a boiling hydraulic fluid place.

Our team (and I am guessing most of the others):

  • is willing to accept incremental changes (that may break things)
  • needs a good simulation of the hardware yesterday
  • will have Atlas HW soon
  • have ideas to help with some of the problems
  • don't have any excess people, but could provide some help

Do you have questions or requests for the teams? Is there a forum where we should submit our ideas for getting a good match to the HW?

Do you have date guestimates for:

  • improved urdf model
  • world files for the eight test courses
  • improved simulation of the physical robot (so gains more closely match between simulation and model)

Thank you!

2013-07-23 17:09:07 -0600 received badge  Famous Question (source)
2013-06-20 17:19:23 -0600 received badge  Notable Question (source)
2013-05-04 18:22:04 -0600 received badge  Popular Question (source)
2013-04-20 23:58:05 -0600 commented question DRCSIM - ROS interface to BDI WALK and STEP

Submitted issue about WALK as drcsim issue 212

2013-04-20 23:48:30 -0600 commented question DRCSIM - ROS interface to BDI WALK and STEP

Submitted issue about single STEP interface as drcsim issue 211

2013-04-19 09:27:13 -0600 received badge  Famous Question (source)
2013-04-18 16:54:42 -0600 received badge  Notable Question (source)
2013-04-18 13:32:33 -0600 commented question DRCSIM - ROS interface to BDI WALK and STEP

To be more specific - it sometimes falls down at the end with qual 1 world and the unmodified tutorial after taking steps as expected, but sometimes it fails to take the steps with the qual 1 world and just wobbles a bit.

2013-04-18 13:21:54 -0600 commented question DRCSIM - ROS interface to BDI WALK and STEP

Looking at my LD_LIBRARY_PATH, the only place where the library exists is in /usr/lib/drcsim-2.4/AtlasSimInterface_1.0.8 There is a libAtlasSimInterface.so that is 13037808 bytes in size. To verify that was the library used, I removed it and started the simulator and noted that there was an error about the plugin not found.

2013-04-18 12:52:01 -0600 commented question DRCSIM - ROS interface to BDI WALK and STEP

Yes, the robot falls down when using the qual 1 world with the unmodified tutorial.

2013-04-18 10:52:52 -0600 received badge  Popular Question (source)
2013-04-18 10:26:47 -0600 received badge  Editor (source)
2013-04-18 10:13:22 -0600 commented question DRCSIM - ROS interface to BDI WALK and STEP

I am using the BDI library released with DRCSIM 2.4.0. Is there a different one I should be using?

2013-04-17 00:00:39 -0600 asked a question DRCSIM - ROS interface to BDI WALK and STEP

The z value appears to be ignored for the foot placement to the 4 step (WALK) interface to the BDI library. In particular, different z values for foot placement make no difference during the actual walking.

The single step (STEP) interface to the BDI library has 2 apparent problems. First, the desired placement is ignored (even placements that work for the WALK interface). Second, it goes into a loop and keeps trying to take a step. The WALK interface takes four steps and returns to STAND on its own. The STEP interface doesn't do that and doesn't return to STAND even when commanded to.

As always, there is an x% chance of user error, but I wanted to ask the question to see if others were seeing the same issue.

To reproduce the first issue - modify this tutorial in three ways - alter the z position of the foot placements, use roslaunch atlas_utils atlas.launch gzworld:=atlas_AtlasSimInterface.world (so that the robot can actually walk and not fall over), comment out the publish in step 5 (so the robot is left in the standing mode - makes testing quicker)

To reproduce the second issue - start as above, change the WALK to STEP, assign values to the step parameters. An easy way in the loop is:

 - if (i==0):
 -       walk_msg.step_params.desired_step = step_data
 -       walk_msg.step_params.use_demo_walk = False

(the 2nd and 3rd lines should be indented, but I couldn't get that formatting to stay)

Add a call to return to stand mode at the end (repeat the second half of step 2)

2013-04-09 18:22:28 -0600 asked a question Integral tie-back in AtlasPlugin.cpp seems wrong - causes control glitches

The code at roughly line 1066 in AtlasPlugin.cpp appears to be wrong. Specifically, it generally will invert the kiq_i term on a step change and saturate in the opposite of the commanded direction.

If a negative step is applied that results in a clamped force then the code can result in a kiq_i that is clamped at the positive limit. This results in a joint excursion in the opposite of the desired direction.

This is not a desired behaviour. I would recommend simply removing the problematic code.

// lock integral term to provide continuous control as system moves
// out of staturation
this->errorTerms[i].k_i_q_i = math::clamp(
        this->errorTerms[i].k_i_q_i + (forceClamped - forceUnclamped),
2013-03-13 00:41:03 -0600 received badge  Notable Question (source)
2013-02-09 10:04:46 -0600 received badge  Popular Question (source)
2013-02-05 16:34:34 -0600 received badge  Popular Question (source)
2013-02-05 16:34:34 -0600 received badge  Famous Question (source)
2013-02-05 16:34:34 -0600 received badge  Notable Question (source)
2013-01-14 20:23:11 -0600 received badge  Nice Question (source)
2013-01-14 11:42:22 -0600 received badge  Student (source)
2012-12-17 13:55:46 -0600 asked a question DRC Robot splits - possible friction and joint torque issue

Interesting results come from running the following line in traj_data.yaml using the example at whole body trajectory tutorial

splits:
  - [0.1, "0 0.1 0 0 0 0                   0 -0.1 0 0 0 0                 0    0   0 0   0 0    0    0   0  0   0 0    0 0 0 0" ]

This moves the left and right leg_mhx joints outward. After the motion is completed the feet continue to slowly slip along the ground until the joint motion limit is hit. Effectively the robot does the splits. This brings up two issues:

  1. It seems like the friction between the feet and ground should be sufficient to prevent this from happening.
  2. It seems like the leg_mhx joints should have sufficient torque to prevent this from happening.

This doesn't seem like a critical issue. I wanted to bring it up so it could be considered as the simulator development moves forward.

2012-12-17 13:54:50 -0600 asked a question Gazebo IMU Noise, possible IMU bug - Gazebo 1.3.1 drcsim 1.1

If I start the simulator with: roslaunch drcrobotutils drc_robot.launch and then look at the imu data with rostopic echo imu I see some noisy data. The orientation quaternion isn't too noisy. The angular velocity is moderately noisy and the linear acceleration is REALLY noisy. Below are the last two messages from rostopic echo imu. The linear accelerations show noise of tens of meters per second^2. Is that much noise intended?

If I filter the linear accelerations, there does not appear to be a gravity bias. The filtered x,y and z values are all near zero. This seems like a bug.

If I start the simulator with no controllers, the linear acceleration noise is less (plus or minus a couple of m/s^2). That makes good physical sense (no noise introduced from the joint actuators), but the noise is still a bit high for an IMU that is basically sitting still on the ground. I am running Gazebo 1.3.1 and drcsim 1.1.

header:
  seq: 1009
  stamp:
    secs: 30
    nsecs: 231000000
  frame_id: ltorso
orientation:
  x: -0.000210851714159
  y: 0.00537853825869
  z: 0.00260686848786
  w: 0.999982115392
orientation_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
angular_velocity:
  x: -0.213459557358
  y: 1.11656030945
  z: -0.10369653941
angular_velocity_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
linear_acceleration:
  x: 43.7205490223
  y: 1.95472301411
  z: 24.9619571066
linear_acceleration_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
---
header:
  seq: 1010
  stamp:
    secs: 30
    nsecs: 232000000
  frame_id: ltorso
orientation:
  x: -0.000113038247571
  y: 0.00516812886021
  z: 0.00264492049874
  w: 0.999983140889
orientation_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
angular_velocity:
  x: 0.181580284794
  y: -0.406282167622
  z: 0.0735962328701
angular_velocity_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
linear_acceleration:
  x: -61.0915878999
  y: -5.83879068239
  z: -49.4699278427
linear_acceleration_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]