After answering a question about URDF exporters for the umpteenth time, and having half a dozen relevant tabs open on my desktop, I put together a short guide on URDF exporters for docs.ros.org. There’s some really great discussion in the pull request that’s worth checking out. If you haven’t noticed lately we’re making some - slow - and steady - progress on docs.ros.org, and we really appreciate the community’s help!
The CAD to robot simulation / visualization part of ROS has always seemed like black magic, and I wanted to see if we could shine some light on the process. My question for the community is this: What does your CAD to simulation / visualization pipeline look like? How do you handle updating your robot’s geometry? What tools do you use to translate your robot’s CAD files into simulation / visualization assets? How do you handle differences between hardware versions? Are there other tools or guides that you use all the time that we should we add to the list?
If you are interested in expanding on this topic we would love to have your contributions over on docs.ros.org.
It’s a bit tedious to write the SDF but I don’t often change my robot so for me there’s no sense in searching and experimenting with export scripts etc. Also it is not that tedious either, you just have to look up the relative coordinates of your parts in CAD or Blender.
As an alternative to designing in CAD (especially for the environment of the simulation, e.g. inside a warehouse) it can be interesting to buy a model online, e.g. on cgtrader or similar websites. Use search terms ‘low poly PBR’.
Don’t expect these to be ready to use though, you will typically still need to load them in Blender, apply textures, bake, etc.
I can’t commit to writing a tutorial or example for docs.ros.org because of time constraints, but if someone wants to give it a go, I’d be glad to answer specific questions wrt. the procedure, if needed.
For us it’s mainly having a single source of thruth. So we have one urdf model which represents the robot. It also contains some meshes for (rviz) visualization purposes.
This urdf is then used in simulation as well.
For this reason we do not have Blender or Webots proto or SDF as source of truth. As that would mean our dependency tree for the real robots contain simulation packages/models.
Although this might be because our simulations are rather simple. I can imagine textures and lighting becomes more important as sensor input needs to be more realistic for your usecase (picking up things?, machine learning in simulation?).
So for us it would be ideal if the ‘base model’ of the hardware could be extended for simulation purposes.
@Timple Indeed I have not yet run into that, as my application is currently still simulation only.
In my ideal world, there would be no real difference between Gazebo and RViz, i.e. you’d launch a limited Gazebo (only the GUI, without physics/simulation etc) if you just want to visualize your hardware, or you’d launch full Gazebo if you want to run simulation.
At some point, work has been done on gz-rviz, but it has not evolved beyond a proof of concept.
In our system, the single source of truth is a collection of Xacro files. We have a separate robot_description package that contains the basic model for RViz, laser filtering and similar use-cases, and then we have robot_gazebo package which adds simulation-related things (by specifying a new top-level xacro file that includes the _description xacro). Each sensor/removable part provides its own xacro that is conditionally included in the final Xacro.
Everything is generated on the fly when the nodes are starting and is configured by a hierarchical collection of YAML configs (similar to what some people described in Handle unique parameters for robot instances ). The fused YAML is passed both as parameters to the Xacro renderer and is also pushed to roscore as parameters so that other nodes can access these values later.
One of the parameters the Xacro received is also rendering_target, which can have values urdf, sdf-classic or sdf, which allows us to specify parts of the models that only make sense when you render the model for Rviz, Gazebo Classic or new Gazebo. For example, closing of kinematic loops can be done so that you just omit the last link in urdf target, but add it in sdf. We even have further parameters that tell the pipeline e.g. that the model will be used for laser filtering, so that it can inflate the links accordingly. Other parameters specify presence and calibration of various sensors, which we change a lot.
The pipeline the runs (simplified a lot) cat robot_model.xacro | print_robot_urdf | print_robot_sdf where print_robot_urdf is a script responsible for collecting and fusing the YAML configs, pushing them to param server and converting them to Xacro args, and then calling xacro on the correct .xacro file. print_robot_sdf is basically gz sdf that gets the URDF with <gazebo> tags on input and outputs the SDF file.
When adding a new sensor, you have to add it at multiple places (_description, _gazebo, configs) and it’s not easy to maintain consistency.
The YAML params cannot be easily passed to roslaunch, so that it’s not possible to have a single file configuring which sensors are on the robot that would both define the model and also the drivers to launch. We hope this limitation will not apply when we switch to ROS 2.
We also have a dynamic_reconfigure for all model YAML params which allows us to interactively play with the model while the driver is running.
The model is consistent between simulation, laser filtering, RViz etc.
It allows fine-tuning the model for each of the “outputs” - e.g. solid color rendering works differently in rviz and new Gazebo, so we can have a different color for a link for Rviz presentation and for Gazebo presentation.
As we automatically save all params when recording a bag, both the final robot model and the parameters it was rendered from are available at a later point.
This means the model can be re-assembled with different configs later. If you e.g. figure out you had a wrongly calibrated part on the robot when recording data, you can fix the calibration later, overwrite the recorded params file and regenerate the model.
My personal belief is that our long term goal should be to build something like gz-rviz. It would be less code to maintain and less complexity for end-users. I think we’re slowly headed in the right direction for that to happen but it isn’t an explicit goal … yet.
The big reason I’ve been against a total rewrite of RViz using Gazebo libraries is because of rviz plugins. There are many dozens of plugins (not all of them in ROS 2 core), and they tend to be deeply integrated into RViz. Migrating them over to a new API is going to be very time consuming. If someone steps up to do the work of this, then I’d be interested in where this could take us.
Hi all, very passionate about this because these tools are something I use almost every day putting my robots into ROS 2. That being said, I didn’t know about them until I did my own searching, so big thanks to you Katherine for making it part of the docs. Writing a URDF from scratch and putting meshes in is time consuming and shouldn’t be the standard. It’s confusing to beginners how to use ROS 2 with their robot.
I propose that there should be a central repository for integrating CAD platforms with ROS 2 so that these plugins aren’t scattered and can be maintained effectively. Most of these plugins haven’t been maintained in years, and don’t work well with new features of their CAD platforms, and/or don’t generate ROS 2 packages to immediately have the models ready to launch into RViz. There is no “one script fits all” here unfortunately because every CAD handles joints/mates differently (and it’s often proprietary, so you have to use their API).
I’ve used all of these CAD platforms and don’t mind starting the work on something like this, but wanted to hear others’ thoughts first.
I did not know it. Neither google search on ‘blender gazebo sdf’ nor on ‘blender export to sdf’ show phobos as a clear search result, and I have no knowledge of any official tutorial or other reference on the Gazebo site that mentions phobos.
And in general: there always is a tradeoff between spending time to learn/install/use something which is assumed to automate a taks, vs. just doing the task.
As @daviddorf2023 writes: as long as you have not sucessfully used a tool, you are not sure it will work for your use case, that it isn’t outdated, etc. So I’m not a priori convinced I want to learn how to define a joint/sensor/etc. in Blender to have it exported to the SDF automatically by phobos, while I can just manually edit the SDF.
I wonder in how many robots people use on average. In my case it is just two; both are 5-axis manipulators with a different configuration. It’s not really a big deal to define 5 links and 5 joints in an SDF. Boring, yes, but a lot of work, no…
That being said, phobos seems to be a well-developed and documented tool, and given you mention it, I assume it is worth checking out.
Perhaps my comment was harsher than it should have been. I’m sorry for that. I knew how tedious the task of maintaining the visual part of the robot and the urdf is because I’ve been able to look over the shoulders of several engineering students who have done this for our robot.
In my experience, a lack of good tutorials and instructional material is usually a feature of open source software. To be honest, even I’m not that good with Blender.
I’m curious to see if a standard procedure will emerge in this case. ROS2 is a big toolset with a lot of features and a lot of work to do.
I’ve been working on a central repository for CAD to URDF conversion over the weekend: GitHub - daviddorf2023/ExportURDF: Scripts to convert CAD to URDF files.. I wrote a Fusion360 to URDF script from scratch that works well so far, as well as bringing in a popular OnShape script as a framework, and a rough outline for SolidWorks. These are the three most popular CAD platforms for robotics currently.
This is all so that the ability to convert to URDF isn’t scattered across the internet, with projects being left unmaintained. For example, the most popular SolidWorks URDF exporter has been dead for 4 years, it was made only to support SW 2021. This should be core to ROS 2 in my opinion, because without CAD to URDF, writing a complex URDF by hand is cumbersome.
I’m hoping for others to contribute their thoughts and code on the project because I think it could benefit a lot of users.
Over the years I’ve attempted to convert a dozen or so CAD files to URDF and this has consistently been a struggle, with any tool. Doing it by hand is sometimes the fastest and definitely the most consistent approach, but also tedious and annoying to change.
The Onshape-to-robot tool simply doesn’t work for more complicated robots (like the NASA-JPL Open-Source Rover) and the Onshape plugin that someone launched about a year back never even loaded for me.
For the entrepreneurial I would even go as far to say: Please take my money (we all know us roboticists are famously stubborn in doing everything themselves so hopefully this means something)
I’ve been working on a central repository for CAD to URDF conversion over the weekend
This is all so that the ability to convert to URDF isn’t scattered across the internet, with projects being left unmaintained.
Is there any guarantee that you can keep maintaining this over the next 5 years or that the community will? I definitely applaud the effort, but open-source projects often get abandoned shortly after seeing the light.
This should be core to ROS 2 in my opinion, because without CAD to URDF, writing a complex URDF by hand is cumbersome.
Couldn’t agree more. I would even think this deserves a working group.
@daviddorf2023 once you feel like you are ready for a “beta” release of your work feel free to send over a pull request to the documentation. I am reticent to point the community your way until your project is ready for it.
@Achllle
I certainly think there is a market opportunity for making an URDF plugin. However, I know that a few of the CAD plugin developers seem to oscillate between having a ton of work and requesting community support. I would love to hear @brawner 's opinion on the matter.
Everyone:
I don’t have a complete grasp on the open-source CAD landscape. Would it be possible to build a core open-source Python library that takes in one or more open CAD standards and spits out URDF / SDL? Once we have a lingua franca from CAD to URDF, it would see like we could start tackling all of the proprietary formats assuming they export to the open source CAD format. Once that common library is in place it seems like all you need to do is hook it in as a CAD plugin. I haven’t done work like that since about 2005 so I don’t know if it is gotten easier or harder in the past 20 years.
I do think making progress on this front is existential for the entire robotics community. The world we want to live in is one where you can build a robot in any CAD tool, potentially using components / assets from upstream vendors, and then export those resources to your simulation / functioning robot. What’s unclear to me is what steps we would need to take to get from where we are now to where we want to be. I would be willing to go advocate to CAD vendors, and robot / component vendors, for use a common standard, but I don’t think we have a clear picture yet on what that would look like. This certainly seems like it would be a great topic for a community group / special interest group.
I was going to add to this thread and now see we’ve had a mention Last year we released an extension to Onshape called Roboforge. After 6 months we reverted Roboforge to a private Beta because there was little engagement. There were some technical issues too, yes it definitely failed to load quite a bit, and we were taken by surprise by the size of models (1000s of parts and 100s of joints) that were being imported into it.
Our expertise is in CAD and simulation, not robotics, so our aim for Roboforge in 2024 is to work with some early-adopters to make Roboforge a good fit for their workflow before we re-release it. I’d be happy to add more people to the Beta list.
Roboforge automates the translation of CAD assemblies in Onshape for RViz, Gazebo and MuJuCo, with a user interface that includes preview of the robot model and control of the translation settings. Roboforge takes a different approach to the open-source translators we’ve seen which tend to require models to be built in a particular order with a given naming convention - instead Roboforge creates an intermediate graph representation of the parts and joints and applies algorithms to reduce to the minimum degrees-of-freedom.
This is awesome, and it sounds like y’all are working towards the end-user experience we all want!
I would need to speak with the other maintainers, but assuming you have a free-tier for the product, I wouldn’t haven’t any objections including RoboForge on our list. My goal with the list was to get people back to actually building robots and this seems to fit the bill.
I would love to hear your thoughts on the complexity of this problem. What do you think would need to happen to make universal URDF / SDF from CAD a reality?
Thank you so much, it will definitely take some community efforts though because even if I write a plugin for every CAD, I can’t test it as much as an entire community can. I also don’t have every CAD because some are expensive . I can definitely maintain the Fusion360 side of things since it’s my everyday work station.
I think the largest barrier is the way that each platform allows you to upload plugins and use their API. For example, OnShape requires private key generation. CAD platforms have different default units. However, most of these scripts can be written in Python and C++, which is nice. SolidWorks is a bit of a pain since it’s quite expensive, separate versions come out every year, and the API is somewhat confusing.
What I’ve currently done for Fusion360, OnShape, and SolidWorks is divided them up into directories within the repository. Each directory has its own README.md with instructions on how to upload the scripts to their respective CAD platform. I’m hoping that people can fill out these things with PRs and issues.
@Achllle I can’t guarantee that I will personally be maintaining everything for 5+ years, but if it grows enough as a community project, I see it being much more maintainable by a team from the community than scattered individuals maintaining their own isolated repositories. I think it’s largely the idea that “this is the only repository you have to come to if you want to put your robot into a URDF” that makes things clear and simple for using and maintaining these scripts. I also agree that there should be a working group for something like this, especially if CAD companies could collaborate and offer some of their time to it. For now, open source community efforts will probably suffice.
I had to make a few phone calls, and while I was on hold I grep’d through all of the weekly updates for the past file years and compiled a list of every item that mentions URDF. I figured I should drop that here for anyone to comes to this thread from a Google search. I may add a few of these to the list on docs.ros.org.
The Fusion360 script was relatively straightforward to develop, but likely has a few bugs that I haven’t found on my own yet. The OnShape script is about halfway completed - I can access an assembly through its document link using their REST API and sort out the links and joints from it. SolidWorks is still something I am actively searching for assistance with because I do not own SolidWorks. It’s arguably the most essential though, since it hasn’t been maintained for years and has a large user base.
Hope to have the project ready for a beta release later this month!
Last year we released an extension to Onshape called Roboforge. After 6 months we reverted Roboforge to a private Beta because there was little engagement. There were some technical issues too, yes it definitely failed to load quite a bit, and we were taken by surprise by the size of models (1000s of parts and 100s of joints) that were being imported into it.
. I can definitely maintain the Fusion360 side of things since it’s my everyday work station.