nlamprian's profile - activity

You don't have any parameters set in the model you shared. Check the specification for the available parameters (they ar

You don't have any parameters set in the model you shared. Check the specification for the available parameters (they ar

You can access the friction by going from model to link to collision to surface to parameters. auto robot = world->M

I happen to have a blog post where I describe how to create a model of an aruco marker. Check it out at https://nlampri

Visualize the links and contacts, and check how they behave when you've sent a command, but the robot is not moving.

Check your inertias. Since you have primitive geometries, it's easy to calculate some valid values. Wikipedia can give y

Try storing the joint angles the plugin receives and letting gazebo itself update the positions during the world update

https://community.gazebosim.org/t/use-case-of-multiple-worlds-in-an-sdf/375

Each world has its own control topic where you can publish to reset it. For example (from the terminal): gz world -w d

The ros controllers were not developed for Gazebo. So, for a real robot, this code is valid. If this behavior is a prob

Positive Rotation of model is not anticlockwise? why? I am using melodic and ubuntu 18.04 and gazebo-9. Problem: When I

The model defines the right wheel on the left and the left wheel on the right. Swap the sign of the y-position in the wh

Try converting the collision mesh to STL. That might work better.

Try changing the controller type and see if it makes any difference. Then I would also look into the inertias of the lin

See if increasing the wheelTorque parameter in the diff drive controller configuration fixes your problem.

The two options are effectively the same. In the referenced plugin, a thread is created to spin the queue. The asyncspin

It seems to be true. To address this, you would need to create a sensor plugin, grab the image from the sensor, and publ

Go by example. Clone gazebo_ros_pkgs and check out the plugins there. They cover a range of sensors and controllers, so

If you are not targeting a model link, you may leave any related field empty. This will reference the world frame. If y

If you are not targeting a model link, you may leave any related field empty. This will reference the world frame. If y

Is it possible to get the sim time outside of the update callbacks in ignition gazebo? Ie is there an equivalent of physics::World::SimTime()?

How to get sim time in ignition gazebo Is it possible to get the sim time outside of the update callbacks in ignition ga

You can configure your camera sensor to generate 16bit images. Then you can just fork the camera plugin, and add a step

Look at the terminal for any errors when gazebo starts. A simple way to see if a (ros) plugin has been loaded is to chec

The distortion coefficients in your plugin description are wrong. See the plugins tutorial or the camera utils source f

You need to set the argument wherever you include this launch file.

Give unique names to the plugins <plugin name="camera_x" filename="libgazebo_ros_camera.so"> as well as camera

Give unique names to the plugins <plugin name="camera_x" filename="libgazebo_ros_camera.so"> as well as camera

Run gazebo with the debug flag to true and check the stacktrace after the crash to see at which point (in which plugin p

Ah, I reacted to the error and forgot about your problem description. Gazebo can indeed run headless. It needs an x serv

Try setting the DISPLAY env variable with the gazebo node <node name="gazebo" pkg="gazebo_ros" type="$(arg script_ty

Enable verbose and debug, and see if you get any more information.

You already have the answer in your link above. There is an example in ros_ign_gazebo_demos: <node pkg="ros_ign_ga

Probably. If you don't want to look into the details, you can also do a system call to gz log ....

Probably, but why not do a system call to gz log ...?

You are not supposed to use -d with -e. -d is for starting/stopping recording, and -e is for printing the contents of a

The planar move plugin works by assigning velocities directly to the model. Ie. the wheels do not move. I can only assum

This code shouldn't affect your simulation after the initialization. Did you maybe add the SetPosition call somewhere in

I deleted the code by now. Probably min depth is enough to get you going.

initial_position is probably not implemented. You can write a model plugin, access the joints directly, and set your in

surface is not part of the urdf spec, so when the description is parsed, the surface section is being ignored. You can v

Examine carefully the sdf you attached. For example, there is no min_depth. Please follow the instructions on the page I