Tutorial | "draw" and "paths"

[kevinAlfsen]

Hello!

First of all, thank you for hosting and managing these tools to the public. Karel seems very limited out of the box and these tools are going to be very helpful.

I am eager to start using Ka-boost to in our Fanuc applications, but I as there is limited documentation, I am having some struggles getting started.

Are you able to provide some form of guidance to help me start using the libraries? Any information is very appreciated, and I think I will be able to figure out a lot on my own if I get a little nudge in the beginning.

The packages I think I am most interested in are the ones called "paths" and "draw".

The way I understand it, "draw" contains methods 2D geometry, polygons, methods for contouring, intersections, infill-lines and so on. As well as a canvas which is used in combination with the python scripts located in "viz" to display a 2D canvas.

Is my assumption correct? And if so, could you give me a short walkthrough of how this is used? Especially the visualization part. If I am able to visualize the geometry, I think I can test my way through the geometric functionality.

Otherwise, or in addition. Do you have any examples or an explanation of the intended usage of these packages?

Like I said, any information is greatly appreciated.

[kobbled]

Hey @kevinAlfsen, sorry for the late reply, was dealing with some personal things where I was unable to look at this.

"Paths", and "Draw" are really the main packages that I am working on in order to achieve a platform for building apps with more complicated toolpathing. Paths should be split into 10 different packages, as it has grown over time to be the most complicated. Draw needs to be patched and refactored, as I realize some of the data structures I was using are incorrect, and the clipping functionality needs to be fixed, and expanded.

The other packages are support packages that are either Library packages (i.e. Math, Pose, etc..), or implement some algorithm, or data structure not included in ka-boost (i.e. graph, iterator, hash, etc...). Other packages are simply wrapper packages for existing karel functionality (i.e. registers, display, tpelib), or to build on top of pre-existing karel functionality (i.e. xmlib, sockets, regmap etc..).

In terms of learning, currently going through the tests folders are the best way (when the tests compile ...). Most of them are in a unit test format, but some are just programs that you have to run on the controller (i.e. test_pth_mtn.kl), as they are motion programs. For test_pth_mtn and test_pth_rot you would go down to the entry point, and uncomment one of the functions:

  -- t_hexagon
  -- t_pvert_ID
  -- t_pvert_OD
  -- t_pvert_pad
  t_pvert_pdid

Build and send it to the controller, and then run it (or if you are on roboguide using the "play" button/cycle start to draw the path out for you).

For the paths tests I have a folder called "config" that holds the robot cell configuration, or functions that are workcell specific and need to be templated, as they will change from workstation to workstation. It is important to go through this as if the test doesn't work it's most likely a configuration issue.

• config/rotary/defaultrot.kl contains all of the configurations for the robot cell are included in here. Where toolframe, userframe, external rotary group settings, tool orientations are set.
• rotary.motion.impl.klt provides a template interface for how motion is handled based on the workstation. The two functions at the bottom ROUTINE approachPath, and ROUTINE retractPath specifies the motion moving into, and out of a path. In rotary.motion.interface.klt this is done in cylindrial coordinates, as the path is wrapped around a rotary.
• rotaryPath.impl.klt/pathmake.interface.klt includes template functions for handling the tool while moving through the path. ROUTINE speed_blending can parametrically control how the speed is handled through the path. ROUTINE path_blending is used for how the orientation of tool is handled through a path segment, and whether it should be dampened in some axes, or limited in some axes. ROUTINE convertOrientation is primarily used to handle z-rotational axis should be constrained to the path or not (i.e. if the tool head is directional or not). and ROUTINE linkingTransition is the motion used to link two disconnected path segments together (i.e. through one-way raster lines)
• rotaryPlan.impl.klt, and rotaryPlan.klt are for the pathplanning module which I can go over at a later time, but it is basically dijkstra's algorithm for planning a set of disconnected path segments.

For the tests in the drawing module, "test_draw.kl" is setup as unit tests that can be ran through kunit. However, if you need to debug something visually, for instance the clipping over shapes, I have a python script in "utils/plot_drawing.py" to plot the lines in matplotlib. The python script basically just takes the structs from test_draw and plots them. In test_draw comment out all of the kunit_test's except for the one you want to run to visualize. Its usage is python plot_drawing.py test_draw -t where -t is optional and shows the tangent vectors.

The Pathlib package also has a "viz" folder with a script called "plot_path.py" this is for visualizing the 2d paths in matplotlib, but also visualizing what they look like in 3d using robodk. A basic cell is included in "viz/path.rdk".

"viz_data.py" is an extra script to visualize the csv, dxf, and svg examples in "test/assets". The "utils" folder contains all of the scripts for generating those assets. The dxf scripts convert to a csv, or yaml format. "svg2csv" converts a svg file to a csv format. and "slices2csv" converts DLP 3d print image slices to csv. For the DLP slicing generation, Chitubox was being used. The purpose of this is to basically convert to a format that the fanuc controller can read, i.e. csv, where the paths and draw modules will parse, and process the csv files. This section is not finished yet, as I am backtracking around to refactor paths, fix the draw module clipping, handling the csv imports, and adding an interface for parametric layering. After that it should be fairly straight forward with the use of these scripts to use dxf, svg, chitubox, convert to csv, then use those csv files for processing on a fanuc workcell.

I will try to put together some docs, or videos on running this stuff in roboguide in the near future. There is one thing you should be aware of, and that is loading the programs onto the controller. It is probably the worst part about this whole system. Dynamic linking on the controller is a nightmare, but can normally be worked out fairly easily for everything outside of the path and draw packages. If the programs are not loading on the controller properly, I have a folder called "scripts" in ka-boost. If you run master_del.bat <ip-address> it will delete all of the ka-boost program on the controller. Then build everything with rossum .. -s -t- b and send it to the controller, and it should load properly. For TP interfaces this is a little worse where you have to rebuild all the tp interfaces. I will typically build from the "pose" package with rossum .. -i- b. This will build all of the tp interfaces, to use these functions in a TP program.

[kobbled]

Aside from getting the cylindrical slicing working, the other main priority of Ka-Boost is to build out interfacing it with PCDK. I should be putting together a repo of PCDK samples, and samples using some Ka-boost functionality in the future. Then a C# utility library for interfacing with Ka-Boost.