Javier Perez's profile - activity

Sorry for double posting, but I think rviz uses a resource retriever: http://wiki.ros.org/resource_retriever have a look

UWSim expects to find a relative path from ~/.uwsim, while rviz expects a "package://XXX" or "file://XXX" prefix so the

I guess the misunderstanding comes from the fact that UWSim uses URDF files assuming the meshes are inside its autogener

Hi again, Sorry if I did not explain myself correctly but this is something that CANNOT be solved just modifying the scene file. If you want to do it visually you need to modify the osgocean source. If you want currents that move the vehicle you need to implement them yourself through dynamics.

Hi,

Unfortunately, it is not possible to create two oceanStates in UWSim, this is controlled by osgOcean that simulates the visual characteristics of the ocean thus it would require to modify osgOcean itself in order to be able to do it.

Anyway, this only controls the visual characteristics of the ocean, it has no effect in the vehicle physics that is controlled dynamically by underwater_vehicle_dynamics package when running a dynamic simulation as explained here. This node accepts an external forces input via ROS topic so you can add any perturbation force to it in order to simulation underwater currents for the vehicles.

Hi,

Actually setting the friction force to thrusters will not assure constant speed due to the vehicle inertia. Vehicle needs to accelerate from stop so it will slowly gain speed. Furthermore friction depends on the velocity the vehicle is moving so you will need to dynamically adjust it. So the best option is use a controller, the most basic is a PID: wikipedia. There is a tutorial about how to create it in UWSim using Matlab/SImulink here, but it is pretty straight forward to implement it yourself.

Edit:

Some comments after reading your problems, thrusters effort ranges from -1 to 1 so setting higher effort will not help. Also check keyboard controller is not running as it sends 0's to the thrusters effort (default dynamics launcher, runs this node). Anyway a big part of navigation involves controlling the vehicle speed, but if you are not testing this just use it in kinematic mode. About the oscillating speed in a PID try adjusting the parameters and use small values, obtaining good values is not trivial, there is a lot of research work about this. Just using a P controller with a small value should be enough to achieve a reasonable result like this: effort=(vel_reference-velocity)*P . It may not achieve the desired velocity or do it slowly but should work.

Hi, try to post a new question next time. I've seen there is a bug rounding numbers and eventually x/x != 1 so "NaN" results appear. I'm solving it and will upload it, but remember multibeam interpolates distances so you will get bad simulation with 10º increase, try using virtualrangesensors

Hi,

That message means the physics simulation is required and it is waiting for it to initialize. It can take some time depending on your computer (no more than twice the vehicle models loading time), the message will be displayed each second in any case. You can check if other scenes are running as the default one is the only one that uses that kind of sensors. Try running rosrun uwsim uwsim --configfile shipwreck.xml and see if that scene is correctly running.

Hi,

Having a look at your code files, it seems you are mixing the files in different packages. I'm not sure if something like that is supposed to work but I think there is no need to do it. So why are you putting header and member files in one package (uwsim) and the main file in a different one (underwater_vehicle_dynamics)?. Beyond that the CMakeLists is from uwsim package?, you shouldn't call a file from a different package in a CMakeList (first two lines). Finally if student classes do not work with uwsim core, as far as I can see they do not include a single file from it, there is no need to add them to the same library, I would create a new one for them or even a new package for them and left unmodified the uwsim package.

Anyway code from the new files is simple enough to work, problem is in the way you are building them.

Hi,

You are probably using an old version of robot-state-publisher and its interface changed after it was installed. Try updating it using:

sudo apt-get install ros-jade-robot-state-publisher

That should solve it.

Hi,

Your bash path is probably in the wrong folder. Scripts are executed in the console using "./NAMEOFFILE", but the script has to be in the same folder. If you want to run it from a different foler you can especify the path to it, for instance "./data/scenes/installScene.sh". Or change the working folder using "cd NAMEOFFOLDER".

Remember the script needs execution permissions, you can change them executing "sudo chmod u+x NAMEOFFILE". Anyway, this is a regular bash script, you should be able to find tons of information about how to execute it just browsing.

Hope it helps.

Edited:

Sorry, didn't realize you were using package-based installation. In this case problem is script copies the new scene file in the scenes folder. So if you want to add new scenes to the installed through the package, instead of creating a new scenes folder, you can run it with sudo.

In other case, you can create a scenes folder copying UWSimScene.dtd from the other scene folder and installScene script. Then just run it and it should work. Problem is you will need to run uwsim from that folder or specify the path to it in --configfile option.

Sorry again for the misunderstanding!

edit 2:

In this case the name of the scene is missing, the error message is far from clear, I should change that. Just execute it with "-s dredging.uws" (or any other available scene).

edit 3:

There is no need to catkin make, as you said there is no source code. Just running "rosrun uwsim uwsim --configfile dredging.xml" after installing the scene should be enough. Check the scene "dredging.xml" downloaded to the right place "/opt/ros/indigo/share/uwsim/data/scenes".

Hi,

The friction force with the water (drag) is already simulated. You can change the paremeters modifying the .yaml file. The parameters used are based on the Fossen dynamics model described in guidance and control of ocean vehicles. You can also check the UWSim paper where it is explained.

It should be, just left the PID working after you reach the setpoint and if it is well designed it should remain stable around 0 velocity.

Hi,

It really depends on what is your goal. If you want a realistic simulation you shouldn't stop the controller as in real life situation you should keep the position (station keeping). But if you want to stop it anyway you can call the service '/dynamics/reset' which will stop the inertias, but eventually the vehicle will start moving again as it happens at the beginning of simulation. The last option is killing the dynamic simulation node, just have a look at how to stop a ros node and kill: for instance "rosnode kill /dynamics_g500" on a terminal should do it.

btw, my computer did not connect internet

Hi,

That is the reason why. Resource retriever tries to connect to internet. If your internet connection is faulty it takes some time as every 3D model loaded calls the resource retriever. I suggest solving connection problems or just disable it.

Hi Janet,

This warning is only saying KDL does not support root links with inertia. But UWSim only uses KDL to publish the TF tree using the URDF provided to build the robot. The robot is NOT simulated through KDL so that is the reason the warning can safely ignored. I tried to find a way to hide it, but I didn't find it. In the case of UWSim is used for simulated force sensor that, obviously, need a mass to produce a simulated force, if there are no force sensors can be safely removed from URDF.

If you are experimenting a crash it should have another cause. If you provide us more information about the crash maybe we can help you ;).

Hi,

I'm not an expert in control but as far as I know a P controller can reach an stable control depending on the model itself. In my opinion this is happening in your case because of three reasons:

• Drag force helps the control making the system more stable with a force that opposes to the movement.
• There are no perturbation forces as underwater currents are not modeled by default. You can add a node to add perturbation forces and publish them on "/g500/external_force" of type wrenchstamped so it is harder to control.
• IMU has some noise that may add some difficulty to control the vehicle, but it is usually too small to have some impact on the system, you can add some more modifying std tag on XML config file for the IMU.

Hi,

The pose topic (I guess you are talking about /g500/pose) is used to send information between dynamics and simulator. So the dynamics is sending the pose to the visualizer. This pose is referenced from robot initial position (stated in the URDF, or 3D file). Meanwhile IMU topic is a simulated sensor that provides rotation with respect to the simulated world (plus some noise), so the quaternion you obtain from here has an additional rotation which is dependant on the world to initial robot position (offsetr inside simParams in config .xml files).

Short answer is they are different because they mean different things.

The IMU is publishing a quaternion from world coordinates to IMU.

Actually, it was fixed, but at some point reintroduced, Should be fixed again for indigo source, I'll merge changes to jade source right now.

keyboard controller sends periodically the readings from the keyboard. If it reads nothing it sends 0 to the thrusters. So some simulation steps were "wasted" with 0.0 thruster speed instead of the speed you were sending.

I think I need more information in this question. I guess you are already using the underwater_vehicle_dynamics. Your controller is publishing to the thrusters topic?. If you are running the default launch, have you disabled the keyboard controller?. Also note g500 thrusters have a 1.0 max effort.

Hi,

I guess you are using the uwsim underwater_vehicle_dynamics package as the vehicle is "falling" (z increasing). When using the vehicle_dynamics package the initial position must be stated in it (no matter what you set in the uwsim XML config file) as that package is the one who sets the vehicle position in uwsim. Just set the position in the yaml file (g500/dynamics/initial_pose: ). We are still working to integrate the dynamics inside UWSim so everything is easier...

You also have to send messages to the thrusters_input, if you send velocities or positions to UWSim expect weird results as two nodes will be sending different information to UWSim.

Hi,

I'm not sure what the problem is. But I would say is not an issue totally related with UWSim and maybe something is wrong with ros installation. Have you checked the folders actually exist? ( /opt/ros/indigo/share/uwsim ). Have you tried other installed ROS packages?, for instance you can try osg interactive markers which is installed with uwsim.

You can get it using TF, just look for the transform from world to [nameofvehicle]. And check WorldToROSTF is configured in the scene (default scene has it).

Hi,

Even if your files are inside UWSim they are just sending messages to each other through ROS, so no simulation is involved (That is the reason why you are getting CPU time). Unfortunately, as you said, UWSim does not offer this kind of simulation capabilities at this moment.

So, depending on the precision required I would suggest to implement it yourself adding delays, missing packages... depending on the position of both AUV's. Adding a accoustic signal sim node that receives messages, keeps track of the vehicle's position and resends messages to the possible listeners, so each AUV should have a publisher and subscriber that will send/receive to the sim node.

Hi,

Problem is you are adding a main function in each file you are adding. Besides this, I'm not sure if that is what you want to do as you are adding code to the UWSim core and I guess you are not accessing UWSim internal information or modifying its behavior.

But as I said I'm just guessing you do not need to modify UWSim core, so adding a publisher and subscriber to your AUV code should be enough (outside UWSim) unless you want to do something more "realistic" simulating communications through water requiring access to vehicle positions, scene, environment... (In that case I would suggest reading wiki it is still incomplete but a good starting point).

Hi,

I usually use this code in my launch files:

<arg name="scene" default="cirs.xml" />
<node name="uwsim" pkg="uwsim" type="uwsim" args="--configfile $(arg scene)" output="screen" respawn="false" />

And launch it like this, using just the name of the scene (stored in uwsim/data/scenes):

roslaunch {package} {launchfile} scene:=shipwreck.xml

Hope it works.

Hi,

Multibeam sensor provides the distance of obstacles from the sensor. You can visualize the rays using the visible tag "<visible>1</visible>" just after relativeTo tag. Unfortunately this feature is not in the deb packages yet (next version), so you need to use UWSim from source. You should see something like this (right image is a zoom):

Hi,

as aak21566 said, you just need to create a publisher and subscriber between the two robots. You don't need to modify UWSim at all, as UWSim uses ROS as middleware to publish sensor readings and subscribe to orders. So I guess what you need is to create your own ROS nodes for each vehicle which can communicate with UWSim and between them.

True, there was a bug on TF publishing for some sensors. I've just updated git main branch, thanks for the catch and sorry for the late response!.

True, I edited the previous answer ;)

Hi,

In order to have collision responses you need to launch the dynamic module and use a force sensor as input for external forces on it. You can directly launch it using the launchfile in underwater_vehicle_dynamics using "roslaunch underwater_vehicle_dynamics UWSim_g500_dynamics.launch", The results should be the same as in this video.

Hope it helps!

Edited: As you experimented in your comment I forgot to say you will need to send messages to the thrusters input ("/g500/thrusters_input" by default) it's a Float64Multiarray setting the effort to vehicle's thrusters from -1 to 1. In the case of girona 500 model it uses 5 thrusters first two forward/backward, the second pair up/down and the last one for lateral movements, this can be configured through a yaml on the underwater_vehicle_dynamics package although is not straight forward. SetVehiclePose and setVehiclePosition won't work in this mode of work as dynamics module is controlling positions and velocities.

As I said on my previous message you need "catkin_make install" without install you are loading the old xml file which was copied to your shared folder

Hi, The lines that mario posted as code should be in your config file (by default cirs.xml). You can, and should, edit cirs.xml as this is the scene configuration file. After editing it you will need a catkin_make install in order to move these config files to a place where uwsim is able to findthem

Hi,

It is possible to handle multiple vehicles, please have a look at shipwreck.xml scene, where two vehicles are placed in the scene and can be controlled through "/dataNavigator_G500TRIDENT" and "/dataNavigator_G500RAUVI". Not sure where is the error is in your case, your config file looks OK.

By now it is not possible to spawn vehicles, we are working on it.

Hi,

Scale tag is working in URDF meshes since May 21, version 1.3.1-1. Please check if you have an older version because it should be working. As an example:

<mesh filename="robot/ARM5E/ARM5E_part0.osg" scale="3 3 3"/>

About xacro, URDF can be generated through xacro, but UWSim does not allow xacro input yet, it's still in TO-DO list.