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 feel the need today to tell that robot kinematics development is still alive. It takes only some time to learn about geometric algebra... I've created a new documentation page about it at https://docs.duet3d.com/User_manual/Machine_configuration/robot_geometric_algebra with some literature links. Geometric algebra is a great geometric approach, which unifies many different mathematical and physical areas and those areas are under constant development, so there are many things to detect for researchers.

I want to model the robot kinematics and inverse kinematics with geometric algebra, transform them into easier Paden-Kahan subproblems and implement them in RRF with limited memory.

I am currently half through the Dorst book, which is IMHO the best book to begin with if one wants to learn about it. Hildenbrand has also a very nice style, but it needs more pre-knowledge. Hestenes and Vince have also a very clear language. I am thankful that all those authors write books without typos, I know other books...

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

@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).

@latexcupcake Nice that you have a solution now and can print now.

If you want to optimize in the future, you can consider using only one stepper and connecting the Z axes with a belt. Then a calibrated horizontal X axis will stay horizontal. Using two steppers, there can occur desynchronization after you turned off the printer.

Just for completeness of my comment: I read that the trapezoid spindles have tolerances, so a 8x2 is not exactly 2 mm. To have two identical spindles, I read one can buy one large one (600 mm)and cut it in half. Then you have two identical 300 mm ones.

@infiniteloop said in suche deutschen support Großformat 3D-Drucker DUET2 WIFI-Board:

consider to get rid of down-voting

what I do against downvoting sometimes is to upvote the thread, so it becomes 0.The downvoter can only downvote one time.

@tsxfire the M350, M92, M566, M203, M201, M906 may have only one value for Z, because XYZ are axis defined, so only one value each, E may have multiple values. The two Z actuators must have the same properties, M92 different steps per mm is not possible.

m208 x0:350 y-168:267
can be removed, because you define M208 some lines lower.

G31 in most cases for BLTouch the P should be 25. The X and Y values must be set, otherwise mesh compensation will compensate at the wrong XY coordinates.

You have the same name e0temp for two termistors. For termistors P is used for the pin name: https://duet3d.dozuki.com/Wiki/Gcode#Section_M308_Set_or_report_sensor_parameters "P"pin_name" The name of the control board pin that this sensor uses. For thermistors it is the thermistor input pin name." There are examples at the end of the M308 documentation.

I feel the need today to tell that robot kinematics development is still alive. It takes only some time to learn about geometric algebra... I've created a new documentation page about it at https://docs.duet3d.com/User_manual/Machine_configuration/robot_geometric_algebra with some literature links. Geometric algebra is a great geometric approach, which unifies many different mathematical and physical areas and those areas are under constant development, so there are many things to detect for researchers.

I want to model the robot kinematics and inverse kinematics with geometric algebra, transform them into easier Paden-Kahan subproblems and implement them in RRF with limited memory.

I am currently half through the Dorst book, which is IMHO the best book to begin with if one wants to learn about it. Hildenbrand has also a very nice style, but it needs more pre-knowledge. Hestenes and Vince have also a very clear language. I am thankful that all those authors write books without typos, I know other books...

I am not sure what the reason is for the flexibility, but I hope you find it out. I'm sure the commecial producers are using finite element methods to find out the best balance between stability and flexibility.

@michaelr123 said in 5 bar scara on duet3!:

print the spline without the cup at the bottom

The advantage is that you can replace the teeth-part fast when it is worn out, if you find a good connector between the two parts. And exchange ratios fast.

PLA is even lower e-module than ABS. PLA has between 1 and 3 GPa, ABS has 2.3 GPa. I would recommend to make it thicker, but use a flexible material like PP (polypropylen). Thermoplast, but very difficult to glue. An example application is Hylite (see Zatsit).

final thought:

I find harmonic drives fascinating because of the following idea in the image:

• green is the force of the wave generator pressing the flexspline teeth against the circular spline teeth. This defines the position of the teeth and is with low pressure. It also hinders position change with low force (detent torque of stepper may be enough as brake).
• red arrow is the force of your arm sideways to the flanks of the teeth

The different direction of the forces allow to optimize them separately. Your current problem is with the red arrow. but maybe the green one has not pressed the teeth enough.

@michaelr123 I'm constantly working at the same questions like you: where does the flex come from and what to do against it. Your ideas are all valid and worth a try. My own ideas, which overlap with yours partly:

• calculate and decide where the flex comes from. Some possibilities:
• long arm length => high torque => more vibrating/flexing => against: shorter arm
• material of flex spline teeth flex => against: material mix flex spline outer to flex, teeth harder, connection to shaft harder. Teeth harder e.g. metal/epoxy or similar containing on top of teeth or in direction teeth-to-middle of shaft
• hinge where the harmonic drive is mounted on flexes => press hinge to one side with eg spring so it doesn't change position when direction changes (ball bearings are pressed to one side always)
• my preference so far is a doubled arm (vertical)

Plastic has an E-module of about 3 GPa, compared to aluminium of 70 and steel of 210. E-module is a number to calculate how much material bends under force, so choosing something harder may fix the flexing. Of course you want a flexspline to flex, so the teeth shall be hard and the inner ring flexible. There are thermosplasts to be 3d printed and hard at the same time, this would be an option, besides using alu/steel. My own path is the (spring-)steel way.

Some of the commercial harmonic drives have about 200 teeth, and this a number which pleases me, because one can produce them easy with 200-step steppers. But this will not solve the flexing, only make it more precise.

I can't remember whether I have already written it, I tend to separate hinge mechanical construction from the actuator part:

• hinge, arm as stable as possible
• actuatator, teeth as precise as possible

This separate handling makes analyzing where flex comes from easier.
In your case, I suspend the flex of the teeth and/or flex of the big ring (= the flexspline part which is between teeth and shaft). Maybe it helps to make it stronger (=thicker and reinfoces by eg spring steel) to flex less.

A final thought: it always help me to imagine that I am a part of the mechanism and how do I act/react: when there is force to the arm, where does the force go? Here it goes to the circular-spline versus flexspline teeth ("horizontal" in respect to teeth, to the flanks of the teeth), so how to enforce it and remove play? Maybe there is teeth-teeth play also, then there needs to be more force from flexpline in direction of circular spline (vertical to shaft in direction outer). More engaged teeth (as described in the patents) will help as well. Another possibility is to make the teeth steeper (but not too steep, as they need to meet them), because steeper meens to have more force and precision. You can start mixing steep with less steep (steep for force and precision, less steep to make sure the teeth meeth each other. One tooth off would be a desaster for precision*)).

*) when mixing, be aware to jump the right amount after each round into the same kind of teeth (eg 200-204 and two kinds of teeth, this should work).

@o_lampe said in Compiled Firmware with 5bar-Scara / Dual-Arm-Scara:

customizer tool on top of eclipse

that's a good idea IMHO, analgoue to the RRF configurator which produced a config.g, this customizer tool would produce the binaries. With additional options like to configure how many drives are needed => optimizing performance vs memory need (additional options: remove or add mesh compensation for those who don't need or need it etc).

You don't need Eclipse, only to run the make exe and Arm toolchain. But a server on which it runs is needed and a responsible person who wants to invest time to do it.

@Phospherus I'd wish you open it in a iFixit style and post some images to discuss the quality. Unfortunately - I completely understand it - you'll not want to do it because of the guarantee. But if it's damaged in the future, this would be valuable. They are out of stock and a bit too expensive to buy it just for testing.

@o_lampe DH configuration and screw configuration parameters are similar, so I want to store it only one time in RRF, because RRF is limited by memory.

Screw theory as such has advantages compard to calculations based on DH:

• closed form calculation of inverse kinematics, i. e. no iterations and all 8 (16) robot solutions
• no usage of Euler angles, which have singularities like gimbal lock from local calculations. Screw calculates globally.

And to answer your question: I want to support DH, because it was the standard method for industrial robots, so some users may be used to it. For me it offers the possibility to double check the algorithms by calculating both ways and comparing the results. The DH code will not be included in RRF, however, to spare memory.

In RobotViewer, I'll support both input methods and I'm thinking about a simple geometric algebra editor to support a third, visual approach to assemble the robot elements.

I want to start in RobotViewer with a selection of robot type like 6 axis industrial, 4 axis palletized, 5 axis CNC/Prusa/CoreXY and I like the robot type called Gantry robot (ABB IRB6620LX like with one linear and 5 rotary axes) and add this kinematics. It is mentioned and calculated in the Pardos-Gotor book, because it is valuable to route big parts like a wood door.

I have a coarse understanding of geometric algebra now and start changing the robot code RRF and RobotViewer DWC plugin next week.

After talking to the Duet team, it is clear that the memory gives me some restrictions to implementation, but I had the following idea:

• Denavit-Hartenberg (DH) code and configuration will move to RobotViewer DWC plugin, so it can be tested and configured there. DWC has the advantage that it runs on PC/table/Raspi with lot of RAM.
• in RobotViewer, the DH config can be translated into screw code there and can be copied to the config.g of Duet (first version will be manual, but I want to transfer it later to some robot.g as macro or into config.g on Duet).
• screw config can be input in Duet directly
• in Duet, only screw configuration will be set and stored in RRF for minimal storage need.

DH is a subset of screw (and with the Y extensions of DH is a 1:1 with screw), so this procedure should work.

If someone is against this proposal, now is the time to tell me.

@michaelr123 said in 5 bar scara on duet3!:

student license aga

I bought the matlab with some toolboxes (Simulink, Vision, Image, Robotics). The Corke book (on his homepage) about robotics includes freeware toolboxes of vision and robotics (simpler versions of the matlab toolboxes) for matlab, because Corke developed the source of them.