ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

ROS Additive Manufacturing (RAM)

ROS Additive Manufacturing (RAM) provides a set of tools (mostly algorithms and GUIs) to help end users create complex trajectories for additive manufacturing. The project is especially focused on printing metallic parts with industrial robots. This project contains multiple tools: path planning algorithm able to generate complex trajectories, visualisation tools, editing tools, etc.

The application contains an algorithm that we found in a thesis, it allows to generate continuous trajectories from the start of the process to the end of the part (the whole part is built in one shot), this is very interesting for many aspects (material health, no dead-times) but also has some drawbacks (heat management). We developed a set of ROS messages, services, actions, nodes and GUIs that enables this whole application to work.

Here are screenshots of the application as of today:

The user can modify each pose of the trajectory: robot speed, feed rate, robot pose, laser power, feed rate etc…
Example, deleting pose:

Here is a video demonstrating a use case with arc welding 3D printing:

We are actively developing the application and are already using the application on 3 of our robot work-cells! One for arc welding and the two others are confidential projects.

The code is available here:

If you are willing to test the application, help with the development or just curious about the functionalities please leave a message here!


Hello, @VictorLamoine!
First of all, congratulations for this Project, I’ve been following it and its developments and it is amazing!
I’m doing a Project and I think ROS AM can be helpful, but I’m a newbie.
It is a FDM 3D printer with a robot arm holding a movable base and a fixed head.
Is it possible to implemente FDM 3D printing with ROS AM? And what about robot parameters and kinematics, that has to be added with a diferente package, right?
I don’t know if this is the best place to post this questions, however, I would be grateful if you could answer.

Best Regards,
João Sobral

Plastic FDM? If so I would recommend using already existing slicers to generate the trajectory, such as Slic3r. The problem is that they are not compatible with robots. Integrating Slic3r into ROS AM is in our plans but nothing has been done yet;

You could also convert the GCode output of Slic3r into a robot program directly but then you don’t get the editing abilities of ROS AM and the possibility to simulate the trajectory in ROS (you could simulate the trajectory with the robot manufacturer off-line programming software).

The robot parameters etc goes into an other package, for example if you are using a Fanuc robot you would probably want to use the ROS-I fanuc or fanuc_experimental packages.

Yes, it is plastic FDM.
My initial references (and problably I’ll end up doing like that) were to follow a regular 3D printing process, using a slicer to generate GCode and then to convert those targets into robot movement.
However, as I found ROS I was trying to implement the Project using its packages, as it seems to be really powerful. My robot arm is a 5 DOF Igus Robolink. As far as I know, there is few development of Igus packages.
How can I convert the Slic3r GCode output into a robot program? Is there any developed package/software to do that (like Moveit?) or that has to be done from scratch?

I don’t know much about Igus robots nor about a bridge to ROS.

You should write a program that reads the GCode and transforms it into robot program (depending on the programming language used on the Igus robot). This is not best as this is a conversion. You could also modify Slic3r so that it does not output GCode but instead directly Igus compatible machine code.

MoveIt will allow you to simulate the robot and do the path planning. It is not MoveIt that does the connection to the robot or a possible conversion.

You might want to have a look at

Or it’s newer cousin/evolution: Machinekit.

Thanks for your responses!
I’ll ckeck out those links.

How its can development for ROS Indigo?

Hey all! Anyone here part of the ROS meetup in Seattle, WA, USA? I’m launching Women in 3D Printing in the city and involved in a ROS robotics company here. Was curious to see if there were people working on a 3D printer. Way cool, thank you!

Meetup here:

I have not tested ROS Additive Manufacturing with ROS Indigo but it should work fine.

I’m in France so I won’t attend to the meeting in Seattle. It would be nice if you could share with us who was interested in 3D printing, what has been done for metallic 3D printing etc. !

1 Like

Here is the meetup!

There is also one in Paris:

We have meetups all over the world, check the website:

Thank you for your interest!

Hello! I am working now in a similiar project, but with a KuKa youBot. How’s your progress on the conversion from GCode into robot trajectory so far? I would like to know more about that. Thank you!


We are not working with GCode at any stage of the software.
ROS Additive Manufacturing generates a trajectory that is a ROS message (defined here:

If you want to move a robot there are two options:

  • Generate a robot program, upload it on the robot and run it.
  • Use a ROS driver, connect to the robot and use MoveIt to move the robot.

For the first option you need to write a post-processor, that will convert the ROS Additive Manufacturing trajectory into a Kuka (in your case) program that contains the right instructions for your process.
This process is explained here:

For the second option you need to read the ROS Additive Manufacturing trajectory and feed it to MoveIt (we are not using this approach as of today).

There are post-processors for the Kuka robots inside the repository, I have started a repository that allows to use these post-processors as ROS services: (I’m focusing on Motoman now but merge requests for Kuka are more than welcome!)

1 Like

Just a clarification: you don’t need MoveIt necessarily. If your trajectory is compatible with what your driver accepts (ie: a JointTrajectory or some driver-specific representation), then it should be possible to send the trajectory to the driver immediately. No need for MoveIt as an in-between.


hello thank you for your reply.

for the second option, how can I get the generated trajectory ROS message? In the example GUI, do I have to export the trajectory message into a bag file and then read the bag file to feed it to MoveIt topic?

I am new to ROS and hope you can clarify this. Thank you.

The trajectory is published on a topic.
Every module publishes a new trajectory after it’s done working with the trajectory.

So for example if you modify the trajectory, the output of this operation will be the full trajectory (ram_msgs::AdditiveManufacturingTrajectory type) being published on the ram/trajectory topic.

All you need to do is create a subscriber that listens to the trajectory topic. Each time a new trajectory is generated, modified etc… you’ll get a new message containing the latest trajectory.