klowrey's profile - activity

If you reset the world/model pose, and then run 5steps.py again, it works (for me at least). Not that this is all that helpful, but if you just needed to collect some data...

I can't answer all your questions but can offer two helpful points. If you set the handbrake value to 0.1, it can get the car moving. This is probably a plugin error where they check for >0.0; so setting it to open doesn't work. Also, there are no side rails in the collision geometry; the Atlas robot cannot collide with it (also no overhead rails, for that matter), so it cannot impede your movement.

It is fantastic to have DRCSIM 2.0 and Gazebo 1.4, thanks! Obviously a huge part of the DRC competition is rectifying data between stereo and laser, but these produce differing results. Robots can only interact with collision boundaries based on objects; if it can't collide it can't affect.

The disparity is that the /multisensesl/camera/points2 data produces point clouds based on visual elements, while /multisensesl/laser/scan produces point clouds based on collision boundaries.

Visual data is not useful if it doesn't lead to a means of interaction.

However, if i run atlasutils drcsimv0.launch, the terrain map loads correctly. this terrain map i cannot delete (it should just be another model, right?) and I get the "no mesh specified" error if I try to load the terrain heightmap again.

I'm also getting this problem, even with the DRCterrain. I will run atlasutils atlas.launch, and try to import the drc_terrain model to get this problem. Custom heightmaps similarly will not work.

The following link is some captured point cloud data visualized in Rviz following the DRCSIM tutorials. The robot is in the golf cart, set to drive in a circle, with a box placed nearby to try and "see".

http://www.youtube.com/watch?v=lM2UZ-6tRaQ

In the video, the multisense output produces a huge amount of spurious point cloud data. My guess is that it is the approximately synced cameras: when the multisense head moves around any amount, the stere_image_proc picks up too many correspondence points with the not synchronized cameras. I am hoping to do visual odometry and point cloud manipulation asap, but this makes things a bit difficult.

Is this the general experience with the multisense head so far?

Warning [parser.cc:377] SDF has no <sdf> element in file[/usr/share/drcsim-1.3/models/atlas/model.urdf] Error: SDF parsing the xml failed

hum... that's interesting. Is the urdf parsing binary your code links to possibly corrupted? I've purged all of ros as well before re-installing...

The outputs to env are posted above in the initial post. This is after a vigorous scrubbing of all things ros, gazebo, and drcsim on my workstation. If there's no other idea for a solution, I'll just fall back on re-installing 12.04 to continue work.

Your suggestion is appreciated. I've since run apt-get purge on every ros-fuerte-* package as well as gazebo and drcsim, apt-get clean, apt-get autoclean, apt-get update, and then finally apt-get install drcsim to reinstall. The same error persists.

yes, after uninstalling, I reloaded the URLs, did an apt-get update, and reinstalled. The model.urdf at the url is idential to the one under /drcsim-1.3/model, and even urdf files newly generated through xacro have the same parsing error. Is there more debug info I can provide?

After working with gazebo/drcsim all day yesterday with only the occasional crash/freeze, I started up my projects today to find that the atlas model.urdf will not load.

If I were to run:

roslaunch atlas_utils atlas.launch

I get the following Errors:

Warning [parser.cc:377] SDF has no <sdf> element in file[/usr/share/drcsim-1.3/models/atlas/model.urdf]
Error [parser.cc:619] Unable to read file[/usr/share/drcsim-1.3/models/atlas/model.urdf]
Error [parser.cc:686] Error reading element <world>
Error [parser.cc:369] Unable to read element <sdf>
Error [Server.cc:235] Unable to read sdf file[atlas.world]

And gazebo/drcsim exits cleanly. This similarly happens if the Atlas model is loaded from the Gazebo gui (with roscore running as well).

The solutions I've tried:

• Complete uninstall of ROS/Gazebo/DRCSIM and reinstallation, including wiping the keys/repositories of these packages.
• Regenerating the model.urdf under a different name using the rosrun xacro command to encounter the same error
• Renaming world files, model files, running gzsdf to update SDF files

Any assistance to get gazebo up and running would be very appreciated.

EDIT: env | grep GAZEBO:

GAZEBO_MODEL_PATH=/usr/share/drcsim-1.3/models:/usr/share/drcsim-1.3/models:
GAZEBO_RESOURCE_PATH=/usr/share/drcsim-1.3/worlds:/usr/share/gazebo-1.3:/usr/share/gazebo_models
GAZEBO_MASTER_URI=http://localhost:11345
GAZEBO_PLUGIN_PATH=/usr/lib/drcsim-1.3/plugins:/usr/lib/gazebo-1.3/plugins
GAZEBO_MODEL_DATABASE_URI=http://gazebosim.org/models

env | grep ROS:

ROS_ROOT=/opt/ros/fuerte/share/ros
ROS_PACKAGE_PATH=/usr/share/drcsim-1.3/ros:/usr/share/drcsim-1.3/models/atlas_irobot_hand:/usr/share/drcsim-1.3/models/sandia_hand:/usr/share/drcsim-1.3/models/powerplant:/usr/share/drcsim-1.3/models/fire_hose:/usr/share/drcsim-1.3/models/atlas_sandia_hand:/usr/share/drcsim-1.3/models/atlas:/usr/share/drcsim-1.3/models/sandia_hand_left:/usr/share/drcsim-1.3/models/standpipe:/usr/share/drcsim-1.3/models/golf_cart:/usr/share/drcsim-1.3/models/sandia_hand_right:/usr/share/drcsim-1.3/models/irobot_hand:/usr/share/drcsim-1.3/models/multisense_sl:/usr/share/drcsim-1.3/models/drc_terrain:/opt/ros/fuerte/share:/opt/ros/fuerte/stacks
ROSLISP_PACKAGE_DIRECTORY=/opt/ros/fuerte/share/common-lisp/ros
ROS_MASTER_URI=http://localhost:11311
ROS_DISTRO=fuerte
ROS_ETC_DIR=/opt/ros/fuerte/etc/ros

I'm trying to collect sensor data from the DRC robot in Gazebo (fresh Ubuntu 12.04 install, DRCSIM 1.1, and Gazebo 1.3.1), and following the visualization tutorial for DRC, or creating a laser assembler node both throw the same error:

Exception [MultiRayShape.cc:113] index[0] out of range[0-18446744073706480025]

Is there a suggested way around this bug, or might there be a better place to submit a bug report? This did not occur on <1.3 versions of gazebo...

After writing some code to pull LIDAR data and induce simple movement control for gazebo-1.2, the update rendered these problematic.

I've re-installed gazebo, drcsim, ros-fuerte, and the boost 1.46 libraries in an attempt to find the problem, but I can still deterministically crash gazebo1.3 by following these steps:

**. /usr/share/drcsim-1.1/setup.sh
roslaunch drc_robot_utils drc_robot.launch
rosrun pr2_teleop teleop_pr2_keyboard**

Pressing a movement key exits gazebo without any thrown errors.

Attaching to the laserScan publisher in Rviz induces an exit with the following error as well:

Exception [MultiRayShape.cc:113] index[0] out of range[0-8742677509569]

Running roswtf gives the following output, but everything seems to be functional and happy in rxgraph.

ERROR Communication with [/rosout] raised an error: 
ERROR Communication with [/robot_state_publisher] raised an error: 
ERROR Communication with [/drc_robot_controller_spawner] raised an error: 
ERROR Communication with [/pr2_mechanism_diagnostics] raised an error: 
ERROR Communication with [/fake_joint_calibration] raised an error: 
ERROR Communication with [/gazebo] raised an error: 
ERROR Communication with [/tf2_buffer_server] raised an error:
ERROR The following nodes should be connected but aren't:
 * /gazebo->/robot_state_publisher (/clock)
 * /fake_joint_calibration->/drc_robot_controller_spawner (/calibrated)
 * /gazebo->/drc_robot_controller_spawner (/clock)
 * /drc_robot_controller_spawner->/rosout (/rosout)
 * /gazebo->/pr2_mechanism_diagnostics (/clock)
 * /tf2_buffer_server->/rosout (/rosout)
 * /gazebo->/robot_state_publisher (/joint_states)
 * /gazebo->/tf2_buffer_server (/clock)
 * /gazebo->/pr2_mechanism_diagnostics (/mechanism_statistics)
 * /pr2_mechanism_diagnostics->/rosout (/rosout)
 * /gazebo->/gazebo (/clock)
 * /gazebo->/rosout (/clock)
 * /robot_state_publisher->/rosout (/rosout)
 * /gazebo->/rosout (/rosout)
 * /robot_state_publisher->/tf2_buffer_server (/tf)

If anyone has a better idea than me with regards to what might be the problems in communications between ros and Gazebo, or what I could do to find out the problems, I would appreciate them very much.