What are the possible outputs of a tesseract trajectory?

[kwint]

Hi,

I'm investigating if tesseract and trajopt can be used in our workflow.
Currently we create a motion plan and convert this to either a RAPID file or a KRL file (depending on what robot brand we are going to use). Then an operator uses this file (or sometimes multiple files if the path is really long) to start the robot.

Would this be possible and viable with tesseract? I noticed that the trajectory published to /tesseract/display_tesseract_trajectory holds an huge amount of joint states, even for simple and straight moves. Translating these to robot commands is that hard, but it would create huge amount of lines, and therefore files (most robots cant handle more then 30k lines per file). Does tesseract have something that lower the amount instructions?

For context, we plan to use for 3d printing complex shapes

[Levi-Armstrong]

Would this be possible and viable with tesseract?

We currently do this on several of our projects leveraging robodk_post_processors for writing the native program. You are correct that the display joint trajectory can be huge but the underlining output of the process planners can provide finer resolution. I assume for 3D printing you need to execute a series of rasters which is similar to grinding, sanding, and painting. In several of our applications we leverage one of the raster process planners which returns a composite instruction which is a vector of composites instructions starting with the transition from home, first raster, transition, ..... repeats for all rasters then a transition to home. We would then write a separate program for each of the sub composite instructions (from home, raster, transition, ...) and FTP to the robot. If a single raster, transition, etc is too large I would then use the trajectory interpolator found within tesseract_visualization to resample the trajectory at a courser resolution. Hope this is helpful.

[kwint]

Thanks Levi, that's absolutely helpful! So to summarize, you create a file for each raster, wrapped in a function (for us this would probably be one layer of a part) and then call these one by one?

If I may ask, do you directly convert the joint states to Joint moves (MoveJ for ABB or PTP for Kuka) instructions or do you use something else?

[Levi-Armstrong]

So to summarize, you create a file for each raster, wrapped in a function (for us this would probably be one layer of a part) and then call these one by one?

That is correct we created a file for each raster then at the end we create the main program which calls the files in the correct order.

If I may ask, do you directly convert the joint states to Joint moves (MoveJ for ABB or PTP for Kuka) instructions or do you use something else?

For freespace I use MoveJ but for the cartesian moves I have used both depending on the process. If you need to ensure it follows a straight line between the two points then I would use MoveL but you still include the position as a joint position. If you use a MoveJ usually it will not deviate far from the line because the waypoints are relatively close except when it moves through a singlularity.

[kwint]

Thanks for the insights! Really appreciate the swift response!

[dbdxnuliba]

@Levi-Armstrong,could you show some example how to convert tesseract plan result to native program such as ur or kuka using robodk_post_processors,thanks a lot

Would this be possible and viable with tesseract?

We currently do this on several of our projects leveraging robodk_post_processors for writing the native program. You are correct that the display joint trajectory can be huge but the underlining output of the process planners can provide finer resolution. I assume for 3D printing you need to execute a series of rasters which is similar to grinding, sanding, and painting. In several of our applications we leverage one of the raster process planners which returns a composite instruction which is a vector of composites instructions starting with the transition from home, first raster, transition, ..... repeats for all rasters then a transition to home. We would then write a separate program for each of the sub composite instructions (from home, raster, transition, ...) and FTP to the robot. If a single raster, transition, etc is too large I would then use the trajectory interpolator found within tesseract_visualization to resample the trajectory at a courser resolution. Hope this is helpful.