I reread my documentation about setting up a robot and its DH parameters last week and must confess - I had problems to understand what I wrote a month ago. Setting up is complex and one can get confused fast.

So I thought about to help creating robot parameters visually base with the help of a DWC plugin.

Here it is, the first version of a working version to display a 6 axis robot configuration, based on Denavit-Hartenberg parameters, as described in https://docs.duet3d.com/User_manual/Machine_configuration/Configuring_Robot_DH_parameters

The plugin runs in DWC 3.4.0 and I tested it on Mini 5+.

The plugin is stored in github at https://github.com/JoergS5/RobotViewer, the downloadable and directly installable plugin is in the dist subdirectory.

After installation, a refresh in DWC was needed, then it was added to the Job folder:

On the right is a visual representation of the robot:

The robot can be turned and zoomed.

The buttons are:

• my PC is slow, so freeze allows to freeze the screen, so GPU is near 0%
• Gitter show or hides the coordination gitter
• Coords shows or hides the three axis coordinate system in the order of RGB: red X axis, green Y axis, blue Z axis. Rotations or prismatic movement is always around the Z axis (blue one)
• Axes show or hide white tubes representing the axes. For prismatic joints, the visualizations needs improvement
• Arms shows or hides the arms
• Angles: change angles for the 6 joints
• DH show or hide DH parameters: type rotary/prismatic, A0 is the base, DH1 to DH6 are the DH parameters, Tool ist tool XYZ
• Gui is currently only to change the screen size of the main screen

The first version has its weaknesses, I am still learning the used javascript libraries. I plan to improve the following points:

• save and load to 0:/sys/robot.g the parameters and settings, so they can be included as macros into config.g to set robot properties
• visualize min/max/home angles (rotational) or mm (prismatic) joints
• full screen mode like G Code Viewer
• tool offset better visualization
• flexible number of joints (between 2 axis to 7 axis)

A bit more in the future is:

• animate G1 moves
• animate an imported G-Code file
• verify inverse kinematics of the main firmware by asking and visualizing the segments
• visualization of the workspace and singularities

I have time in May and June now to proceed developing robot kinematics. The order is

• 4 axis parallel (the black robot arm), probably as a quick-and-dirty approach first for @YuriConfessor
• DWC plugin to design and analyse a given model
• CoreXY/Prusa/Cartesian 5 axis AC and BC
• 6 axis robot
• testing whether Qt is a possibility for a designer/slicer
• elaborate tool design. My personal priority is using robot for CNC, so I'll work on support for different tools (tool shape etc).

I'll use 3.5.1 as basis.

The next prototype will be a CNC 5 axis, and now may be a good moment to share my experience with manual tools, so I gathered some ideas:

one of the most valuable tools I have is this one, together with a good caliper:

which allows more exact graining(my model: Soba Optical Center Punch).

The next hint is to measure bought parts, there are surprises sometimes:

and sometimes a part which has a documented thickness of 31.5 mm has only 30.0. Aluminium extrusions are not flat in most cases. There's a reason why CNC people route them before using. Your construction should not rely on extrusion's flatness (if you have not routed it):

using a hair angle or hair lineal, great tools to check flatness.

An aluminium part is not necessarily 20 mm, but sometimes 20.2, and not 2 thick, but 2.15. Measuring deepness of the carriage holes is also a good idea (all holes), because they differ, to choose the right screws.

Talking about measuring, this is one of my favorite book titles:

I bought some waste aluminium for 3 EUR/kg, and my next hint is to practice a lot, using the failed attempts for washers and the like. After graining, boring etc many parts you have gained experience. Then it becomes quite easy to make a part.

One very useful tool is a band saw, I use a Proxxon MBS220, which is enough to saw 6 mm alu. But be careful, the parts become hot after sawing, especially with big drills like a drill to bore 16 mm holes (use coolant like cutting oil).

I try to achieve stable structures by using aluminium 3 mm or thicker, creating closed objects. I always try to use two connections to hold parts or shafts by ball bearings to hinder rotation or tilting.

A special topic is deburring, which I often do between single holes, because they level the parts wrong when not doing it (the next hole is not vertical any more). Burrs look ugly, but more important, they prevent good connections or alignment. For high precision, I use cone drills for final processing of a hole.

I prefer nut stones with spring, because they can be inserted without disassembly of the frame. Hammer stones alway rotate into the wrong direction, but sometimes they are needed because they need less space.

An example of a failed nutstone usage is here, where the angle recess conflicts with the nutstone height. The connection is very loose as result:

When designing parts, holes to access screws (eg the pulley screws) is important. At the same time I try to make closed structures for stability.

The carriages of the linear guides need to be protected against moving over the guide edges. I you already searched the balls, you know what I mean. Even worse for ballscrew.

For rotating parts, I often insert washers. This special 8x12x0.5 washers between the F608 make the connection only at the inner (not rotating) part, not the outer, so the F608 can rotate without friction:

Talking of washers, the old locking washers DIN 127A, 127B, left were withdrawn because they are unreliable:

I use the right one DIN 6797 Form A, but there are many options with different capabilities like DIN 6797 form J, 6798 multiple forms, 7980 etc. I choose 6797 because they shall protect against vibrations.

Firmware organizes all axis movements in time frames (X moves n mm in 0.1 seconds, Y m mm in the same time etc.). A continuous movement doesn't have a time frame (because it's infinity time), so it's a problem.

A solution could be to add a separate FreeRTOS task which makes the continuous movement for a (stepper-)motor by generating own stepper signals without any time frame planning. It would run isolated from all other movements, but this needs to be added to the firmware, something for the wishlist.

@dc42 if you decide to remove those kinematics from core RRF, I offer to take a lead for source and documentation for 5-bar scara, 5 axis robot, 6 axis robot and later this year for stewart/hexapod kinematics.

My proposal are dedicated github repositories on Duet3D (so the repositories can be found) for those kinematics with source and binaries, so users who want to use them can easily install them. I propose to offer binaries for Duet 3 based hardware (6HC CAN, Mini Eth, Mini WiFi, 6XD) for main releases and maybe for a part of the beta versions.

Some time since last update, so I want to give some update information. Had Covid and recovered, hope you are all well too.

Robot kinematics will be included in RRF 3.5, after talking with David and Tony. I have agreed to have a working version end of August, so the integration will start after this date.

I am currently working on

• performance optimizing and testing
• implementing additional kinematics like CNC 5 axis and 4 axis palletizing robots which are built like ABB IRB 460
• documentation. Starting point is https://docs.duet3d.com/User_manual/Machine_configuration/Configuring_RepRapFirmware_for_a_Robot_printer and I tagged the documents with robot tag, currently 4 documents. Detailed descriptions e.g. of orientation, RobotViewer, Config. Please ignore misspelling, but if you find logical errors, please tell me to correct it
• still working on a good prototype, but this takes eternal

I've built my CoreXY 5 axis now, 90% finished (it will never end, I have new ideas every day).

This is a build with experimentation as design goal, not productive use or a high WAF. If someone wants to have such a machine, using Voron and modify it (like BrendonBuilds) will probably be the better choice. I've reread the very useful Mark Rehorst's blogs about his CoreXY. I tried hard to not be member of his hall of fame (a collection of CoreXY design errors).

Aluminium 45x45, F608 ball bearings, THK linear guides.
There are two carriages on the THK linear guide each. I'll use the second for a router solution for abrasive work.

The reason to build it is to

• verify the robot kinematics firmware
• give examples how to configure, home and print
• discuss problems with optional recreation

The A and C axis are belt gear based:

The C axis has long belts and long distance between A and C axis intentionally to check the firmware correctness. It will be better for productive use that the C axis is above the A axis with a counterweight (eg stepper) below it, so it's balanced to avoid falling down when steppers power off.

The belt gears are 12/60 teeth in two stages each, so 1:25 each.
To calculate the distances of the gear axes, I used https://www.technobotsonline.com/timing-pulley-distance-between-centres-calculator.html

The C axis with 8 mm steel rod is too weak, it bends too much for my taste, I'll have to use an alternative or support it.

The X axis has a linear guide below it. In my current understand, thermal expansion is not the main problem why it's necessary, but one cannot calibrate the two rails exact enough (few micrometers necessary in all planes), so they would stuck fast:

The clamps for the XY belts were complicated, there are always screws in the way! I'll use Mark's belt clamp probably in the future:

XY belt tensioner is using linear guides and weights. I can fix the position by the clamp. It's good to have a protection against wire tear:

The weights can be changed to calibrate XY. Better than those steel weights would be something like high density gold bars, but I didn't have them on hand. The wire is fishing line 40 lbs. I will probably use this construction to use weights for other tasks too, where I need a defined force.

The "print bed" is polystyrol and a paper hotend to avoid damage while testing:

Some first test results are:

• when A axis is rotating, there are crashed with the frame which are unexpected. To build in collision detection may be a good idea
• same with A rotating and RTCP XYZ compensation means that eg Z remains at its position, but the motorPos not! A configuration of motorPos range may be necessary to avoid the crash.

I used 2 steppers for Z axis:

The reason is, I tried the belt solution to connect the two axes, but the belts are in the way of the rotating A axis. Routing the belts around the area was a complex task. The second reason is, the two steppers for Z will allow a small tilting (at AC, this means a third rotating axis around B), this may be useful in the future for slerp 6 axis based (Yan, Jeng, Chieng Five-Axis Slerp for Tool-Orientation...).

To test different Duet boards, I used Wago connectors:

Crimping was again my "favorite task".

I search a solution to allow free rotation of the table. I'll probably design something similar to "RS Pro 176-0897" for the bed heater.

That's for the moment. I am currently testing my setup and will describe it later, same as my thoughts about homing and then trying FullControl for sample prints.

I'll make new bins this evening with my firmware corrections for Mini5, 6HC and Duet2.

One hint at the end: set stepper speeds low while testing, so you have enough time to press the emergency stop button...

@zapta dear zapta, are you still interested in a DWC plugin for this motor analyzer? I can begin developing it next week (slowly). Whether I can manage to use bluetooth without https or how to find a workaround, I am unsure and have to check.

I've finished the robot 6 axis inverse kinematics now with Paden-Kahan algorithms, the time measured on a 2 GHz laptop is 30 microseconds to get the 8 solutions. Maybe factor 10 for a Duet. Optimization is possible by calculating only the nearest angle solutions. (maybe in Limitposition calculating all solutions, and in segmented calculations only one solution).

I'm constantly updating the screw theory page, especially the literature links, if someone is interested following the underlying theory.

Next will be to implement linear axes with screw theory for the CNC/Prusa/CoreXY like 5 axis. Then I'll try to implement PK2 Dimovski et al solution (for 6 axis robot first three axes).

I've installed a new longer (18 cm) hotend for less crashs (see below)

and created new binaries and checked in the current code. I rewrote the RTCP code and tested it. This builds have all limits like M208, angle and speed limits deactivated.

To give an impression, my current configuration part for setting robotic is:

M669 K13 B"CoreXY5AC"

M669 A"C=-179:179:0"
M669 A"A=-179:179:0"
M669 A"Z=0:300:0"
M669 A"X=-150:150:0"
M669 A"Y=-150:150:0"

M669 C"C=0:0:1:0:0:0"
M669 C"A=1:0:0:0:140:-70"
M669 C"Z=0:0:1:0:0:0"
M669 C"X=1:0:0:0:0:0"
M669 C"Y=0:1:0:0:0:0"

M669 C"Mnoap=1:0:0:0:1:0:0:0:1:0:0:0"
M669 C"Mreference=0:0:0:0:0"

G92 X0 Y0 Z0 A0 C0

The most important is the Mnoap endpoint. If I home all 0 values to this endpoint, calibration is easiest. A good endpoint is the middle of the bed, on the Z0 surface of it. This is cartesian coordinate (0,0,0) also. The axis points are next important and the need to measure them more exactly is an open task.

BTW I really don't understand why Z is axis orientation (0,0,1), because the positive Z should point down. Another point is that the Voron is opposite direction of traditional CoreXY: Voron platform down means less distance hotend-endpoint. Traditional bed up means less distance. So Z axis orientation may need to be opposite for Vorons.

With G92 I set homing for all axes, and the M114 Count values are 0 each because the endpoint is 0. Controlling motor and machine positions is easier.

RTCP seems to work ok, only C has some inexactnesses. But I suspect this is the missing exact calibration. A, X, Y and Z move nicely RTCP according to the AC rotation. One open issue is at X0Y0, where the rotation by C is undefined for the inverse kinematics. I currently set rotation to 0, but the new C angle is stored.

The tool length parameters are removed, because it's only necessary to change the endpoint when changing tools. This is imho safer than trying to detect a tool change.

I've moved the bed deeper, because by testing A rotation, I constantly crashed the Z axis at the top. A terrible noise. Talking of A, I have to fasten the pulleys better, they were loose after a few hours. I'll connect the pulleys by screws and make notches into some shafts.

I added a reporting of the current configuration. When M669 is called (after setting robotic K13), it is output to the console, e.g.:

=== M669 K13 current config ===
numOfAxes 5 axisTypes RRPPP chain CAZ_corexy(XY) (normal CAZ.. special XY)
axis C ori: 0.00 0.00 1.00 point: 50.00 -50.00 0.00 angles min/max/home: -179.00 179.00 0.00
axis A ori: 1.00 0.00 0.00 point: 0.00 120.00 -75.00 angles min/max/home: -179.00 179.00 0.00
axis Z ori: 0.00 0.00 1.00 point: 0.00 0.00 0.00 angles min/max/home: 0.00 300.00 0.00
axis X ori: 1.00 0.00 0.00 point: 0.00 0.00 0.00 angles min/max/home: -150.00 150.00 0.00
axis Y ori: 0.00 1.00 0.00 point: 0.00 0.00 0.00 angles min/max/home: -150.00 150.00 0.00
Screw values:
   reference angles/positions:  0.00 0.00 0.00 0.00 0.00
   endpoint axis X: 1.00 0.00 0.00
   endpoint axis Y: 0.00 1.00 0.00
   endpoint axis Z: 0.00 0.00 1.00
   endpoint point: 0.00 0.00 0.00
special kinematics set: CoreXY
abSign: 0  (0 means A (B) positive angle preference)
cache used: 80 maximum: 200

I'll add a summary check for completeness.

@o_lampe no, it's the crossing point of the three last axes of the industrial robot. The calculation of the inverse kinematics is much easier when they cross. The nozzle will simply add with his length and orientation.

@MihaiDesigns this robot type is very similar to Gantry Robot (eg ABB IRB 6620LX), discussed in the book Pardos-Godor Screw Theory for Robotics. It is 6 axis. The book's approach finds all solutions by calculation (no iterations needed).

It can be described by the order of the axes (linear, then rotational etc) and the tool orientation and position.

The inverse calculation is described in the book, which divides the calculation into subproblems. You will have to handle multiple solutions for the inverse kinematics.

I tried different approaches, starting with Denavit-Hartenberg and Euler angles, but those calculations have many special cases like Gimbal lock and special handling when 90 degrees are crossed etc. This is "local calculation", meaning the axes are calculated one after another. The "global calculation" method by using screw theory is much better and avoids some of the special cases (the singularity situations).

I currently develop a general approach which will cover your case, but I don't want to make a promise about the time frame. Robot kinematics is planned for RRF 3.6.

An important aspect which I want to add is that those kinematics need to take into account the orientation of the tool, in addition to the position. Some RRF code expects the tool to be vertical, eg mesh compenstation (probably same with baby steps). It doesn't work with non-vertical tools. It is currently a workaround to include the tool into the calculation tool chain, so you have control over the calculation, and set the tool to 0 length.

Last comment: with two rotational axes you will not be able to make all rotational movements. 3 rotational axes would be better (like the Gantry robot I mentioned above). Easiest to calculate is if they are mechanical built as spherical, i. e. the three axes cross in one point. Similar to how most industrial robots are built with axes 4 to 6 in the head.

@OttoJiang I don't recommend it, because this kinematics is only one of several ones of robotics kinematics. When they are complete, we can github it.

As an overview please see https://docs.duet3d.com/User_manual/Machine_configuration/Configuring_RepRapFirmware_for_a_Robot_printer with additional documentation pages.

@OttoJiang said in voron5x with RTCP:

This kinematics approximates linear motion by means of segmentation

thank you that you found the solution of a problem I was not aware of.

@dc42 could you please add this code to the GCodes part, maybe with some flag condition for specific kinematics?

@OttoJiang

I am confused a bit by your mp4 video file, because the printer behaves exactly as expected. Is the video with your bug code correction?

Maybe you means the Z moving up and down a bit during the movement. This may also be because of Z backlash *) in the construction. How is your Z axis built? It needs to be without backlash. The requirement of Z movement is much higher now than a simple movement in one direction for a 3-axis printer.

*) you will probably know what I mean with backlash. But for other readers: I mean when the Z axis motor changes direction, some steps are lost because there is play in the gear/ball gears/axes with the effect that the opposite movement is later than expected. Some steps are lost. The 3-axis printers don't have backlash because they move only upward and gravity assures that the gear/beal gear are always at one flange of the machanics.

@OttoJiang said in voron5x with RTCP:

It should actually move in a curve to keep the nozzle's XYZ coordinates in the workpiece coordinate system constant during the movement.

Hello,

correction of the XYZ, so the nozzle stays at the position when BC changes, is exactly what the code shall do, and it worked in my tests. Please tell me where you mean the error in the code lies.

Your other post, you want constant velocity:
Segmentation works to linearly segment every axis movement/rotation angle. To achieve what you want, you need a change of the segmentation code. First to change is the BC angle change. As an example, to rotate in 10 segments 45 degrees, segmentation is 4.5 degrees for every segment. But needed is something like the Slerp algorithm to divide the BC into a constant velocity. But the code needed is located outside of the kinematics code. Currently angles are simply divided for segmentation, B divided and C divided.

(to be more exact: you cannot make all rotation movements with BC alone, you would need 3 rotation axes. There is an article to approach the correct movement with BC, missing the A axis, with minimal error. The code uses Slerp code also. Slerp is easiest calculated using Quaternions)

To make it worse, if you need true constant velocity, you must know your path and combine the movements of the linear axes with the rotation Slerp-based calcuation and then calculate the segmentation needes of every axis. Calcuation of the exact path needs a lot of mathematical calculation. It is better made in advance by a slicer and sending the single segments as G-Code, instead of letting Duet calculate the segmentation. You need in the range of 10 microseconds for every segment to have an efficient movement. (You want a low millisecond for a movement, with maybe 100 segments). The current code is in this range, but a path movement (including BSpline, Bezier and such) calculation will add time.

The current RRF code is based on time framed calculation: how many steps needs every axis, then put them together into the time frame, then try to send one step signal to as many axes as possible at the same time (Duet sends one signal to multiple motor drivers). You requirement needs separate signal calcuations and step signals for every axis at his own, each one at a given time. It's not impossable, but needs more caculating power.

@Toaster0042 you're right, I should inform, I will prepare an update.

@Mafco77 thank you for using the kinematics and nice to hear that you're using it successful.

I probably have implemented the homing of CoreXY wrong somewhere. I'll check it. But please be patient for solving this, it's not the highest priority and you have a workaround.

Hello @Mafco77 your homeall is:

G91 ; relative positioning
G1 H1 X255 Y255 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 X-5 Y-5 F1800 ; go back a few mm
G1 H1 Y255 X255 F360 ; move slowly to X axis endstop once more (second pass)
G92 X120.94 ; set x position to the center of bed (you may want to adjust this)
G90

and the documentation in https://docs.duet3d.com/User_manual/Machine_configuration/Configuration_coreXY says to home the X and Y separately.

In my understanding, your procedure will stop at X or Y, which is reached first, then ends. So one endstop will always be unhomed. If you starting position is near to the Y endstop, your X endstop will remain unhomed. If it's near X, the Y will stay unhomed.

The move back and fine home doesn't help, because it will trigger one endstop again and stop, the other endstop being unhomed.

The homeall in the documentation moves X and Y in two commands separately. This makes sure that both axes are homed.

Documentation:

G91 ; relative mode
G1 H1 X-240 Y-240 F3000 ; coarse home X or Y
G1 H1 X-240 ; coarse home X
G1 H1 Y-240 ; coarse home Y
G1 X4 Y4 F600 ; move away from the endstops
G1 H1 X-10 ; fine home X
G1 H1 Y-10 ; fine home Y

So X will be homed first, then Y is moved until homed.

Your homall will move both X and Y, until one of the endstops is triggered, then stops.

@OttoJiang I have not added any special code to the kinematics regarding homing or interpretation of G1 H commands (G-Code handling is out of my reach).

@jwilo in the source code of the firmware is the comment in Move.cpp for the method MotorStepsToCartesian (the method calculates the cartesian coordinate from the current stepper positions):

// Convert motor coordinates to machine coordinates. Used after homing and after individual motor moves.

So this method is called after each individual move and probably interrupts the movement merging.