What do we want to achieve?

Create a urdf model for the Sensia PT & camera

How do we plan to do it?

How can it be tested?

The device will be visible in RVIZ
The device will be consistent in terms of pan and tilt joints

What do we want to achieve?

Answer the question of: It is worth to have inertia simulated for sensors?

This is the visualization of RB-Vogui inertia with no sensors:

This is the visualization of RB-Vogui inertia with sensors:

The box is rotated mainly because of the GPS inertia.

When creating a new model, it is far more easy to debug using the first visualization.

What is happening?

If two links with inertia are connected through a fixed joint, Gazebo computes the overall inertia, so if something is displaced, the whole thing looks weird.

How do we plan to do it?

• Look for a solution where Gazebo does not join inertia,
• Or remove inertia from sensors.

It is worth to simulate inertia of a sensor weight one kg, that is fixed to a base of 100Kg?

How can it be tested?

For Indigo-devel, urdf.xacro files must be edited. You must replace prefix by name like Kinect-devel version, because without this, you will have an error. For example, at hokuyo_urg04xl.urdf.xacro file !

<xacro:macro name="sensor_hokuyo_urg04lx" params="name parent *origin min_angle:=-2.0943 max_angle:=2.0943">





<xacro:insert_block name="origin" />

Cross referenced from:

https://github.com/RobotnikAutomation/rb1_base_robot/issues/3

I have not tested it yet, but it looks like commit 64dc8dd introduces some bugs:

• Setting the camera name as a literal ('robot') is not the best practice, since the robot prefix may change.
• Realsense cameras do not publish the image using the rgb namespace. color is used instead, so this change should be reverted.

Check the following urdf sensors:

• Vectornav
• Sick Nanoscan
• Sick Tim 551
• Sick Tim 571
• RS Lidar
• etc

Just follow this instructions:

http://gazebosim.org/tutorials?tut=ros_gzplugins#Laser

Using the Gazebo-Simulation for the Summit_XL with ROS-Noetic on Ubuntu-Focal,
I noticed that the simulated Hokuyo UTM30LX-Sensor does not publish its Laser-Scans.
So in RViZ one cannot see any Laser-Points.

To solve this problem you just have to change Line 43 in hokuyo_utm30lx.urdf.xacro

from <sensor_hokuyo_utm_gazebo/>
to <xacro:sensor_hokuyo_utm_gazebo/>

I hope this hint will be useful.

What do we want to achieve?

After uploading a new sensor to pearl_test branch and test it in Melodic, it will be necessary to test it also in Kinetic to check that is working correctly.

How do we plan to do it?

Testing the whole lidar configuration in a Kinetic version.

How can it be tested?

The lidar, through Gazebo and Rviz, will be able to detect objects within 90x360 degrees FOV.

Entre cada palabra del nombre de cada elemento del URDF tiene que haber un guión. Por ejemplo: base**_**link.

Como cada modelo se puede instancias varias veces, existe un prefijo para añadirle un nombre al modelo y que no colisione con otros. Por ejemplo: **summit_xl_**base_link.

En los sensores, en el URDF ese guión entre el prefijo y el nombre base se añade hardcodeado. Por ejemplo:

<joint name="${prefix}**_**rgb_joint"> (este viene de la orbbec)

Sin embargo, en un modelo de un robot, el guión se añade dentro del prefijo, dejando los nombres de los elementos del URDF sin ninguna coletilla. Por ejemplo, del Summit XL.

<xacro:arg name="prefix" default="summit_xl**_**"/>
<xacro:summit_xl prefix="$(arg prefix)" publish_bf="true" hq="true"/>

Consecuencias:

• Si instancias un modelo de sensor sin añadirle un prefijo, queda con un guión delante. No suele ocurrir esto, pero puede.
• Hay una incongruencia en la manera de usar el prefijo entre robots, ruedas (hay ruedas que el guión va incluido y otras que no), elevadores, sensores... Una misma variable debería de usarse siempre igual.

When generate deb package for ros2 foxy, checks the package version and changelog.