Sensor data format in Phobos

[kavonszadkowski]

Silvio raised a very valid point in #5 about the way sensor information is encoded in Phobos. I quote:

Hi, congratulations for the great software.
I read here that you plan to add sensors information to your model editor. Which kind of format you
plan to use for encoding sensors information in the URDF ?

In the urdfdom repository there is an open discussion [1] for new URDF specifications regarding
sensors. Do you think it could be worth to share your proposal for simplify integration and
interoperability of different software using sensor information from URDF?

[1] : ros/urdfdom#28

My short take on this issue is that we are aware of this problem, but have so far have been working with our historic restrictions and the need to get things done without waiting for URDF to be extended.

The long version would be that we mainly use Phobos with the MARS simulation and have thus adapted the description of our sensors to the one previously used in MARS for quick integration of our new description format SMURF. It would absolutely be worthwhile to integrate URDF sensor definitions as soon as they are decided upon, the main problem being that URDF thus far is not meant to be particularly extensible, which is something we definitely strive for and somewhat rely upon. What I do not fancy is a scenario where some sensors are encoded in URDF and other still have to be added in our SMURF extensions if URDF does not provide definitions for them similar to the problem that now already exists with URDF and SRDF both defining collision data.

Either way, we should obviously be keeping tabs on URDF's solution to sensors.

[traversaro]

Thanks for the reply! I will keep an eye on phobos sensors editing implementation.

[kavonszadkowski]

Thanks for your interest!

I can quickly explain our current sensor implementation. In MARS, we use a generic data structure resembling Python dictionaries to parse YAML files in which we export our additional data. From this, MARS extracts the information associated with the existing sensor classes it knows.
Any unused information is saved together with the robot, so that custom-built plugins for MARS can use it to add e.g. custom-built sensors. A user can therefore create a new sensor type, add all the necessary information in the model and generically export that information to the SMURF format.
So the Phobos editing and export part is very generic. It's mostly the operators simplifying sensor creation that define which properties get created and how they are named.
Changing the sensor format in Phobos would boil down to changing the templates for said operators and extending the existing URDF export.

[SamuelYaron]

Is there anything new we have to speak about in this Issue?

[Amudtogal]

Good news.
Some weeks ago, I reintroduced sensor objects to Phobos (e.g. 50e65c3).

The new look on the topic is really generic:

We have a definition yaml file (defaultSensors.yml) residing in the users ~/.config/phobos/definitions folder. The user can add own files on demand as long as they follow the syntax properly.

From these files, the general settings (like visual representation, material etc) are parsed for the use in the Phobos operator (aka Button in the Blender GUI).

Along with these parameters, the user can specify an unlimited amount of sensor parameters in the definition file. These are parsed and added to the sensor operator without further action from the user. As they are imported, they are exported in the same generic matter.

This gives us the possibilities to create new sensor categories and sensor templates alike.

Therefore, we can write any required export file we need from the internal Phobos definition. I will do this for the upcoming SDF import/export and the existing SMURF export.
If we want a new export format for sensors (or add sensors to an existing format), we can do so by using derived information from the internal dictionary.

Suggestions for other formats requiring sensor support are welcome, please open a new feature issue for each!