Home | Tutorials | Wiki | Issues
Ask Your Question

PMilani's profile - activity

2018-07-24 06:45:04 -0600 received badge  Famous Question (source)
2018-07-24 06:45:04 -0600 received badge  Notable Question (source)
2017-02-26 22:05:57 -0600 received badge  Enthusiast
2017-02-25 17:41:27 -0600 commented question joint don't moves as expected

What are your joint limits in sdf/urdf. The model should conform to those limits if they are set lower than your controllers output.

2017-02-23 17:59:25 -0600 answered a question Set Odometry in a new robot in ROS

Calculating the odometry is typically done via a plugin, that is a piece of code inserted into the model that can do calculations and change the model based on an interface defined here

A Model plugin will give you access to joint information usually useful for calculating your odometry. For special arrangements its usually better to calculate your odometry and publish as you see fit, typically via a ros odometry message.

Alternatively for common arrangements there are some existing plugins available that might suit your purpose. I am thinking specifically of the differential drive ros plugin, skid steer plugin and planar drive plugin. They will give you a control interface (for issuing commands) as well as output odometry information.

2017-02-23 17:52:02 -0600 commented question Set Odometry in a new robot in ROS

does this model describe an ackerman steering arrangement for the robot? Asking as the better way is to implement in code.

2016-09-02 06:32:28 -0600 received badge  Self-Learner (source)
2016-05-13 10:36:32 -0600 received badge  Famous Question (source)
2016-05-13 10:36:32 -0600 received badge  Notable Question (source)
2016-04-04 11:41:53 -0600 received badge  Popular Question (source)
2016-04-03 08:44:02 -0600 asked a question Loading heightmap.world fails in gazebo7

Hi All,

I'm having some problems loading the following worlds in the gazebo-7 package: worlds/heightmap.world worlds/heightmap_dem.world

as in:

$ gazebo worlds/heightmap.world

My GAZEBO_MODEL_PATH is pointed at /usr/share/gazebo-7

Gazebo fails to load any splash screen and returns straight back to command prompt. When I add --verbose no relevant information is provided.

My Gazebo was installed from the gazebo-7-ros-packages and works correctly otherwise.

is this a common problem as I have not been able to load other heightmaps of my own either.

cheers

Peter

2015-10-31 12:30:55 -0600 marked best answer Effect of Stiffness and Mass on Gazebo Simulation stability

Hi All,

I've been developing a model that has hydraulic actuators that are as a result very stiff in that a small change to either the load on the actuator or on the valve spool will result in a relatively instant and relatively large change in the states of the actuator. These motors are represented by a class hydmotor;

//Hydraulic motor models
    private:
        hydmotor motor_joint1, motor_joint2, motor_joint3, motor_joint4, motor_joint5, motor_joint6, motor_joint7, motor_gripper;

during the update of the plugin the motors are run through a simulation step of their own based on their own states for pressureload using Gazebo provided dt (from get sim time) and GetVelocity(), returning the result (the force on the joint) via SetForce(axis, value):

    motor_joint1.dt=dt;
    //motor_joint1.u = 0.5;
    motor_joint1.thetaspeed =joint1->GetVelocity(0)*motor_joint1.gearratio;
    //Calculate the Motor Dynamics
    motor_joint1.updateinput();     


    joint1->SetForce(0, (motor_joint1.getTorque()*motor_joint1.gearratio));

dt is calculated from sim_Time. the method:

motor_joint1.updateinput();

Is basically where the next state iteration is calculated for the motor (where the states are pressureload, and rotationalspeed and the input is the valve position.

These have been incorporated into a Gazebo model via a plugin so that it can talk to ROS. To get it to work required a dt value of around 0.1 ms in the solver. Anything larger and the model ( a serial robot made of a number of links) would end up as a jumbled heap. I tried increasing the iter value about 100 times and can see that the model works for a short time before becomming unstable and flying apart.

My question is why would stability be affected if I only add an additional variable of type hydmotor?

I would expect it to run slower sure, but not to affect the overall stability.

The stability issue can be corrected by making the solver timestep even slower. at the moment it sits at about dt = 0.000044 with iters = 95.

Cheers

2015-10-31 12:30:42 -0600 marked best answer How to implement a Force Sensor

Hi All,

I am wondering how you would implement a simulated force sensor to measure joint torques if the method physics::joint::GetForce(int) is not implemented. If anyone has done this with Gazebo any help would be appreciated.

cheers

Peter

2015-10-31 12:30:27 -0600 marked best answer How to locate joint axes in SDF 1.3

Hi All,

I'm trying to build a simple gripper. Simple in that a palm and finger are part of the same rigid body and the other finger simply swivels into it, like crocodile jaws.

However I'm having difficulty getting the movable part to rotate about the desired axes. When I switch on view->joints in the menu, the joints gyph (black writing) shows where the joint ought to be as in the picture below: image description

I am trying to get it rotate about the rigid part of the gripper is as shown in orange. However, my gripper actually seems to be rotating about the green icon which is neither where the joint is shown or where it is intended to rotate.

To demonstrate a picture of the gripper closed is shown below, as you can see Joint8 has moved about the apparent axis of rotation: image description

My model file pertaining to the gripper is shown here (link:Tool is the rigid part, link:gripper is the moving part):

<link name="Tool">
                <pose>  1.52148 0.96296 -0.654121 0 0 0</pose>
                <visual name="Tool_visual">
                    <geometry>
                        <mesh>
                            <uri>file://gazebo_ros_plugin/models/meshes/gripper_v2_static.stl</uri>
                            <scale>1 1 1</scale>
                        </mesh>
                    </geometry>
                    <pose> 0  0 0 0 0 0</pose>
                    <material>
                        <script>Gazebo/Grey</script>
                    </material>
                </visual>
                <collision name="Tool_collision">
                    <geometry>
                        <mesh>
                            <uri>file://gazebo_ros_plugin/models/meshes/gripper_v2_static.stl</uri>
                            <scale>1 1 1</scale>
                        </mesh>
                    </geometry>
                    <pose>  0  0 0 0 0 0</pose>
                </collision>
                <inertial>
                    <inertia>
                        <ixx>0.34</ixx>
                        <ixy>0.000039</ixy>
                        <ixz>-0.001386</ixz>
                        <iyy>0.0649</iyy>
                        <iyz>-0.000114</iyz>
                        <izz>0.296312</izz>
                    </inertia>
                    <pose> 0.000 0.000 0.0 0 0 0</pose>
                    <mass>2.414</mass>
                </inertial>

            </link>
            <link name="Gripper">
                <pose>  1.60148 1.212 -0.654121 0 0 0</pose>
                <visual name="Gripper_visual">
                    <geometry>
                        <mesh>
                            <uri>file://gazebo_ros_plugin/models/meshes/gripper_v2_movable.stl</uri>
                            <scale>2 1 1</scale>
                        </mesh>
                    </geometry>
                    <pose> 0 0.00 0 0 0 0</pose>
                    <material>
                        <script>Gazebo/Yellow</script>
                    </material>
                </visual>
                <collision name="Gripper_collision">
                    <geometry>
                        <mesh>
                           <uri>file://gazebo_ros_plugin/models/meshes/gripper_v2_movable.stl</uri>
                            <scale>2 1 1</scale>
                        </mesh>
                    </geometry>
                    <pose> 0 0 0 0 0 0</pose>
                </collision>
                <inertial>
                    <inertia>
                        <ixx>0.00182</ixx>
                        <ixy>0.0000</ixy>
                        <ixz>-0.000192</ixz>
                        <iyy>0.00907</iyy>
                        <iyz>0</iyz>
                        <izz>0.007607</izz>
                    </inertia>
                    <pose> 0.000 0.000 0.0 0 0 0</pose>
                    <mass>2.447</mass>
                </inertial>
            </link>

And the joint8 location:

<joint name="joint8" type="revolute">
            <pose>0 0 0 0 0 0</pose>                
            <parent>Tool</parent>
              <child>Gripper</child>
                <axis>
                    <limit>
                        <lower>-0.5</lower>
                        <upper>1.1</upper>
                        <effort>4000</effort>
                        <velocity>0.171</velocity>
                    </limit>
                    <dynamics>
                        <damping>100</damping>
                        <friction>100</friction>
                    </dynamics>
                    <xyz>0 0 1</xyz>
                </axis>
            </joint>

The majority of the model has been exported from a sdf-1.0 file. all the other joints and meshes work pretty much correctly.

Can anyone suggest some adjustments to my pose arrangements ... (more)

2015-10-31 12:30:26 -0600 marked best answer Changes to model behavior when converting between Gazebo 1.0 and Gazebo 1.8

Hi All,

I've been modelling an arm which uses a plugin that models hydraulic actuators and valves. The model is a state representation that uses actuator velocity and acceleration as states and outputs force.

to link to gazebo model I get my velocity state from the joints using joint::GetVelocity() in the model and apply my actuator force to the joints via joint::SetForce().

These are both done on the plugin's OnUpdate()

This works fine with Gazebo 1.0 and the model was controllable.

I recently converted over standalone Gazebo 1.7, and the joint response was no longer sufficient to defeat gravity and my actuators that previously responded correctly now can no longer lift the links of my manipulator.

My gravity vector is (0, 0, -9.8)

Additionally my model's joints jerk around quite a bit without input from any controller to the plugin.

I'm just wondering if there have been any changes that may be causing this behavior in the new Gazebo. I haven't significantly modified my models or plugins other than to convert them for Gazebo 1.7. As a result the plugin did have to be outside ROS as per the Tutorials1.5/ros_plugin. but was functionally unchanged.

Any suggestions as to what may be wrong?

2015-10-31 12:30:12 -0600 marked best answer Multithreading gzserver

Is it possible to run gzserver over multiple cores does gzserver incorporate multithreading?

When running gzserver all the physics and plugin modelling is really only run over a single core, my computer has 4 cores and 8 threads and I was wondering if it were possible to run gzserver across more than one core inorder to get better performance. If gzclient is run a the same time, it spreads itself over the remaining cores, but for my application the gui is not really that important.

when running htop with gazebo running the gzserver runs over two threads, utilising one at 114% and the other at 98% but still only getting a real time factor of 0.08

Any suggestions?

2015-10-31 12:12:53 -0600 marked best answer How do I update from the Fuerte Gazebo release to version 1.3

Hi All,

My version of Gazebo came packaged in the Fuerte release of ROS which I believe is 1.0. How do I go about updating it to 1.3. Because in the Gazebo installation tutorials, the ROS users are told not to install from here but are instead directed back to the ROS installation page, which as far as I know only packages Gazebo 1.0?

Is there a way to upgrade gazebo without touching or changing the remainder of my ROS files?

cheers

Peter

2015-10-31 12:11:56 -0600 marked best answer Roslaunch utilising Gazebo 1.0 not Gazebo 1.3

Hi All

I've installed Gazebo 1.3 to replace the Gazebo 1.0 as suggested here.

However when I go to run previous roslaunch files (for a gazebo 1.0 model) instead of launching Gazebo 1.3 and parsing the model to 1.3, it instead launches Gazebo 1.0 with no changes to what I had before installing Gazebo 1.3. I've followed the directions given, and my launch file is based on the old rosplugin.launch. However it doesn't seem to specify a version:

<launch>
  <!-- set use_sim_time flag -->
  <param name="/use_sim_time" value="true" />
  <node name="gazebo" pkg="gazebo" type="gazebo" args="$(find HMMv2)/worlds/HMMv2withGripper.world" respawn="false" output="screen"/>
  <node name="gazebo_gui" pkg="gazebo" type="gui" respawn="false" output="screen"/>
  <node name="imageviewhead" pkg="image_view" type="image_view" args="image:=/gazebo/cam_sensor1" />
  <node name="imageviewRH" pkg="image_view" type="image_view" args="image:=/gazebo/cam_sensor2" />
</launch>

now I take from the above launch file that it is using the simulator from the gazebo package in /opt/ros/fuerte/stacks/simulator-gazebo/gazebo.

How do i change it to direct to where the gazebo 1.3 files are stored, the binaries are located in usr/bin, with the rest of the parts spread across the /usr/ folders

Cheers

Peter

I can run Gazebo 1.3 from the commandline no problem.

2015-01-15 12:39:00 -0600 received badge  Nice Question (source)
2014-12-02 15:36:42 -0600 received badge  Self-Learner (source)
2014-12-02 15:36:33 -0600 received badge  Popular Question (source)
2014-11-13 15:20:57 -0600 answered a question Issues importing Autodesk dae file - Segmentation Fault

I had been running the spawning process without graphics card support. When enabling graphics card through the "optirun" prefix (a purely Nvidia on Ubuntu solution) the mesh is displayed correctly.

2014-11-13 06:46:09 -0600 asked a question Issues importing Autodesk dae file - Segmentation Fault

I'm trying to import a model with a texture on it. I developed it with Autodesk 3Ds Max, with a .gif file as the texture. Both the dae file and the .gif are colocated in the same directory. I believe the .gif is correctly referenced in the .dae file.

Here is the definintion of the first couple of lines of the .dae file:

<?xml version="1.0" encoding="utf-8"?>
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.1">
  <asset><contributor><author></author><authoring_tool>FBX COLLADA exporter</authoring_tool><comments></comments></contributor><created>2014-11-13T11:33:17Z</created><keywords></keywords><modified>2014-11-13T11:33:17Z</modified><revision></revision><subject></subject><title></title><unit meter="0.001000" name="centimeter"></unit><up_axis>Y_UP</up_axis></asset>
  <library_images>
    <image id="Map #19-image" name="Map #19"><init_from>./4x4_384_73.gif</init_from></image>
  </library_images>
  <library_materials>
    <material id="Material #57" name="Material #57">
      <instance_effect url="#Material #57-fx"/>
    </material>
  </library_materials>
  <library_effects>
    <effect id="Material #57-fx" name="Material #57">
      <profile_COMMON>
        <technique sid="standard">
          <phong>
            <emission>
              <color sid="emission">0.000000  0.000000 0.000000 1.000000</color>
            </emission>
            <ambient>
              <color sid="ambient">0.588000  0.588000 0.588000 1.000000</color>
            </ambient>
            <diffuse>
              <texture texture="Map #19-image" texcoord="CHANNEL0">
                <extra>
                  <technique profile="MAYA">
                    <wrapU sid="wrapU0">TRUE</wrapU>
                    <wrapV sid="wrapV0">TRUE</wrapV>
                    <blend_mode>ADD</blend_mode>
                  </technique>
                </extra>
              </texture>

The file on the 5th line <init_from>./4x4_384_73.gif</init_from> is where I reference the file for the texture and its is used further down as a texture.

The error I'm getting from gazebo is:

[INFO] [WallTime: 1415881614.977695] [0.090000] Spawn status: SpawnModel: Successfully spawned model
[ INFO] [1415881614.988141528, 0.090000000]: Physics dynamic reconfigure ready.
 Segmentation fault (core dumped)
[gazebo-4] process has died [pid 17741, exit code 139, cmd /opt/ros/hydro/lib/gazebo_ros/gzserver worlds/empty.world __name:=gazebo __log:=/home/arm1/.ros/log/5950b11e-6b30-11e4-be80-128cf6640207/gazebo-4.log].
log file: /home/arm1/.ros/log/5950b11e-6b30-11e4-be80-128cf6640207/gazebo-4*.log
[spawn_urdf-6] process has finished cleanly
log file: /home/arm1/.ros/log/5950b11e-6b30-11e4-be80-128cf6640207/spawn_urdf-6*.log

Has anyone successfully spawned a model with this type of file in this way? Any help would be appreciated. It is with Gazebo 1.9 as per the Hydro install.

cheers Peter

2014-10-23 01:10:55 -0600 commented answer Joints Drift when they are not being driven or have a set velocity of zero

Sorry for the late reply, I guess you're using ROS Control right? Effectively Gazebo seems to work in a dynamic environment, so when you go to apply an instantaneous change in velocity, this means that acceleration therfore force needs to be very large. If you are having problems try adjusting your joint effort limits in gazebo so they can take large numbers. Alternatively, implement a control loop for velocity using the gazebo joint effort interfaces to control velocity.

2014-09-04 19:36:07 -0600 received badge  Famous Question (source)
2014-08-26 14:17:07 -0600 received badge  Notable Question (source)
2014-08-26 14:17:07 -0600 received badge  Famous Question (source)
2014-08-23 07:40:44 -0600 received badge  Famous Question (source)
2014-08-11 03:35:03 -0600 marked best answer Joints Drift when they are not being driven or have a set velocity of zero

hi all,

I've a model that represents a serial manipulator, with hydraulic actuators. I've modelled the actuation of the joints in two ways: 1. one using a hydraulic actuator model that is calculated every call to update() in my plugin. It gets joint velocity from the gazebo model, a valve setting from a ros topic and outputs a torque which is applied to the joint. and 2. Simply applying the valve setting as a velocity directly to the joint using joint::SetVelocity(). ensuring that joint::SetMaxForce() is a non-zero (and quite large) value of 10000.

However when my valve setting is zero, a particular joint in the arm always seems to drift regardless of method. Now this would be realistic if the joint were truly undriven, however if I set my joint velocity to zero, it would help if it stayed zero (within the bounds of the SetMaxForce() parameter). I cant seem to find a method to set the joint to static as this would accurately model counterbalance valves with zero leakage, but it doesn't seem to be implemented yet.My preference is for an open loop solution to this problem to replicate the real world.

Any ideas or workarounds?

2014-06-29 05:53:48 -0600 received badge  Popular Question (source)
2014-06-29 05:53:48 -0600 received badge  Famous Question (source)
2014-06-29 05:53:48 -0600 received badge  Notable Question (source)
2014-06-27 00:06:15 -0600 asked a question Implementing Lights on a robot

Hi

I'm trying to implement a light on a robot to replicate a laser pointer dot in the scene. Is there a way to do this so that a camera will be able to pick it up, and so that it moves with a robot link as if attached?

I tried implementing a spotlight but gazebo wouldn't recognise my links as being valid references for the light. Has anyone been able to do this?

cheers

Peter

2014-06-18 06:51:00 -0600 received badge  Popular Question (source)
2014-05-14 12:29:52 -0600 received badge  Notable Question (source)
2014-05-10 22:21:50 -0600 edited answer Simulating suspension in rear wheel drive vehicle when turning

Removing the specification of <slip1> and <slip2> probably had no effect, but on the rear wheels only, reduction of <mu2> to a lower value of around 0.1 allowed the inside rear wheel to slide sideways as required. This reduced transient forces that seemed to be producing pressure upwards.

Additionally and possibly more importantly, the wheel's collision shape was modelled as a cylinder. as the rear suspension joints were free only one direction (z direction), when the body of the vehicle tilted during turning, this caused the wheels to tilt resulting in a collision with the edges of the cylinder which represented the wheel and the ground plane.

It was the reaction forces from these collisions that was causing the observed behaviour. Changing the shape of the wheel's collision geometry to a sphere stopped the collisions and the subsequent reaction forces

Finally, the number of contact of the wheels and where they were is important, as I also had a problem with the steering working intermittently at low speeds. This resulted in the front wheels sliding across the surface. Looking at the EV Ranger model, I noticed that the cylinders forming the wheels were slightly canted so that they ran on the inside edge of the cylinder modelling the wheel. This was done by specifiying the joint axis for the wheel to be <xyz 0="" 1="" 0.05=""/> for the left side and <xyz 0="" 1="" -0.05=""/> for the right. Implementing this in my own model improved low speed steering.