Skip to content
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

SDFormat #31

Open
willstott101 opened this issue Apr 11, 2022 · 11 comments
Open

SDFormat #31

willstott101 opened this issue Apr 11, 2022 · 11 comments

Comments

@willstott101
Copy link

The URDF and SDF file formats are very similar in a lot of ways - any start to an sdformat parser would likely be a fork from this work (case in point).

Would you be willing to accept contributions to add SDF parsing alongside URDF parsing to help maximise code-reuse?

@OTL
Copy link
Collaborator

OTL commented Apr 12, 2022

@willstott101 Great work!

What is your plan to reuse the code?

@willstott101
Copy link
Author

That link was something someone else had worked on as a fork from this repo. But it looks abandoned and incorrectly licensed to me.

My initial bit of work was here: willstott101@03a64c8

Basic idea was to split this crate up into three main modules: pub urdf, pub sdf and common, then I moved utils to ros_utils too cause they're very ROS-specific.

What we can end up re-using is Error types, some of the simple structs, and the vector parsing code.

There would also be scope to convert from one->other for particular constrained files, to make it easier to create programs which can import both.

@willstott101
Copy link
Author

Resource resolution (stuff currently in utils is generally very shareable).

@willstott101
Copy link
Author

Opened #32 as it's easier to keep track of and comment on changes.

@hardesh
Copy link

hardesh commented Apr 15, 2022

Hi,
I would like to push any contributions to add this feature. Please let me know if there are any open tasks

@willstott101
Copy link
Author

Hi, that would be most welcome. My branch with a pull request open is the latest thing I've worked on. Step one towards being able to have multiple people work on this would be to have a few tests for loading very simple SDF strings in the funcs.rs file.

If we can have a few small tests for each basic part of an SDF it should be easy for people to contribute the parsing of elements they're interested in. I think very rarely do people require the entire spec, so small tests should help us grow the functionality at whatever rate we need.

@willstott101
Copy link
Author

I'm happy to merge PRs into my fork for now, if that's the most convenient.

@hardesh
Copy link

hardesh commented Apr 15, 2022

Hi @willstott101,

Great. I think it makes sense to start adding tests which only have the main model of the robot. Later we can start adding sensor in the SDF. Let me know if this works for you.

I'll start going through your code

@willstott101
Copy link
Author

Lovely. What's there is pretty much a suggestion for crate layout more than anything functional. As a warning :)

@willstott101
Copy link
Author

I've pushed a version which is actually able to parse an SDF file now. Lots to learn about serde_xml_rs... but finally got a top-level enum for different kinds of SDF files working. Could alternatively always return a list of Worlds, and just create a World for files without one, if the enum proves to be a bit awkward.

@hardesh
Copy link

hardesh commented Apr 18, 2022

Thanks. Will take a look at it. I was on vacation over the past few days. Haven't had a chance to look at the code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants