Gazebo | Ignition | Community
Ask Your Question

jetdillo's profile - activity

2018-06-22 17:02:34 -0500 received badge  Famous Question (source)
2017-05-10 16:07:01 -0500 received badge  Notable Question (source)
2017-04-19 05:16:15 -0500 received badge  Popular Question (source)
2017-04-12 11:02:23 -0500 received badge  Nice Answer (source)
2017-04-03 09:20:11 -0500 answered a question How can I dynamically get the coordinate of a model in gazebo?

If you are running the gazebo_ros_laser plugin(or similar), it publishes a sensor_msgs/LaserScan.msg to /scan just like a real laser in ROS. Check out the LaserScan Message page for details on the format of the messages published by the /scan topic. One of the data elements in a LaserScan.msg is an array of range values:

float32[] ranges

This has the range data you're probably looking for. It's up to you/your code to determine how to use it, what makes up an object, filter out noise, etc.

You can find the position of the TurtleBot by subscribing to the /tf topic: (About which see here and here, and of course, The ROS Wiki tf Tutorial)

If you don't know how to work with the rospy publish/subscribe framework, there are tutorials on ros.org: Writing Publishers and Subscribers in Python

HTH and please mark this as an answer if it helped you!

2017-04-02 12:39:53 -0500 commented question Problem connecting to docker container using gzclient

Are you running gzserver and gzclient on the same machine or different ones ? There may be port-forwarding and IP routing issues that need to be dealt with if you're not on the same machine(even if the remote machine is on the same subnet as the one running the container)

2017-04-02 12:39:52 -0500 received badge  Enthusiast
2017-04-01 18:29:41 -0500 received badge  Necromancer (source)
2017-04-01 18:29:41 -0500 received badge  Teacher (source)
2017-04-01 18:29:41 -0500 received badge  Self-Learner (source)
2017-04-01 15:01:59 -0500 received badge  Editor (source)
2017-04-01 14:59:55 -0500 received badge  Scholar (source)
2017-04-01 14:59:39 -0500 answered a question Groundplane in Gazebo vs. Rviz

Just following up a few months after the fact.

The answer here is that I needed to provide a base_footprint <link> for the robot to raise it above the "floor". I added an empty link:

<link name="base_footprint" />

and then a corresponding joint to fix it to the robot.

<joint name="base_joint" type="fixed" >
   <parent link="base_link" />
   <child link="base_footprint" />
   <origin xyz="0 0 -0.57325" rpy="0 0 0" />
</joint>

The Z offset is from the geometric center of base_link. Yay! Now the Rviz mapping representation matches the Gazebo visualization.

2017-04-01 14:46:01 -0500 received badge  Famous Question (source)
2017-04-01 14:46:01 -0500 received badge  Notable Question (source)
2017-04-01 14:46:01 -0500 received badge  Popular Question (source)
2017-04-01 14:44:08 -0500 asked a question Is a <transmission> tag necessary for non-motorized joints ?

I'm working on the Gazebo model for a robot arm which consists of a couple servos with links attached to the servo horns at off-center joints, which drive the arm, which itself is mostly a series of "passive"(un-motorized) joints with some end-effector attached at the end. Do I need a <transmission> tag for each joint, even if doesn't have an actuator ?

Most of the "robot arm" tutorials and examples I've found in code or online seem to assume that there will be stepper or servo or some sort of motor in each joint of the arm. What would be the correct way to specify something like, say, a scissor-lift ?

This is being done in Gazebo 7.

2017-01-19 10:14:19 -0500 asked a question Groundplane in Gazebo vs. Rviz

I'm having some problems with how Gazebo and Rviz treat the simulated world our robot is running in. In Gazebo, our robot appears on the groundplane and moves and navigates successfully between goals either by teleop or program. It will programmatically recognize obstacles with the laser_plugin and some basic obstacle avoidance code I've written. I can even use gmapping to create a map of the simulated space. When I bring up that map in Rviz though, the robot is below the map and won't successfully proceed to an arbitrary goal picked out in Rviz w/ the "Set 2D Nav Goal" function.

When I load in another map(and world), say, the Willow Garage willow.yaml map, the robot shows up on the groundplane both in Rviz and in Gazebo.

The point where my map and or simulated robot intersect is at the Z-height of base_link. I know this should be telling me something, but I'm stuck as to what. I've attached pictures below of the situation. The robot model is a Gazebo-ized URDF, not SDF.

Gazebo simulation image description