-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sensor data format in Phobos #11
Comments
Thanks for the reply! I will keep an eye on phobos sensors editing implementation. |
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. |
Is there anything new we have to speak about in this Issue? |
Good news. 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. Suggestions for other formats requiring sensor support are welcome, please open a new feature issue for each! |
Silvio raised a very valid point in #5 about the way sensor information is encoded in Phobos. I quote:
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.
The text was updated successfully, but these errors were encountered: