Robotic kinematics
-
Thanks for the super fast response. Next Monday I will give it a try, but also try to understand your solution. I will start simple e.g. two axis and gradually add more axes till the 5 axes + extrusion are running synchronously. I'm especially interested in your generic approach because we will add 2 more axes in future (tilt and rotation of the extruder). Wish you lots of success with your prototype.
-
@LexJames the forward kinematics is generic, with the exception of parallel kinematics, where the parallel axes are handles specifically, but the rest generic also.
The inverse is divided into so-called subproblems. The subproblems are itself generic again, but they have proconditions, e.g. intersecting axes. That's the main research region of me, to find more generic solutions with less restrictions. That's where geometric algebra is very strong: calculating intersections and distances between lines, planes, spheres, circles and more.
The current checked-in code is only the forward and inverse code for 5 axis with 2 rotary and 3 linear axes, which are perpendicular. That's relatively easy. I'll add the generic cases next (e.g. skewed axes and linear/rotary mixes in the chain. Not the linear axes standing together like now). They need more processing power. But the current version already supports the case that the AC axes do not need to intersect.
I've solved most of them already, but I use different methods, because they differ by usage of memory and performance. I've to sort them and add them.
If there is interest, I can explain the algorithms coarsly on the firmware page while I add them.
One of the main design ideas to have one global cache (currently 200 floats) to cache different values, depending on which sub-kinematics is used. The 6 axis robot will use cached values for PK1, two times PK2 and one time PK3. When changing to CoreXY 5 axis, it will instead cache some other data. A complicated collision detection will cache data to calculate object intersection/distance.
-
Thanks for making this intermediate version.
I added some error handling and reporting (just for myself), because it is very easy to make mistakes in configuring the parameters.
I'm working on a simulation environment in CAD to be able to test without having hardware. I found one bug which you may want to repair. If you forget to define a printer (M669 B"<printer type>"), but still define C parameters, the cache will be indexed with a negative index. -
@JoergS5
I would be interested in some more explanation of the algorithms, so yes please, add them to the firmware page. -
@LexJames said in Robotic kinematics:
ters, the cache will be indexed with a negative index
thank you for this report, I'll "harden" the code. I'll add explanations to the firmware page, as soon as I add the other parts.
-
@LexJames said in Robotic kinematics:
but still define C parameters, the cache will be indexed with a negative i
I thought about it. When booting, processing config.g doesn't output console messages. I'll make it other round and check the config parameters for completeness when trying to move, to call M669 or when calling the R parameter (report, will be implemented, mainly for performance testing).
-
There's news about robot kinematics: I've created a CoreXY 5 axis prototype now and can test the firmware (I'll post a description tomorrow). My build has experimentation in mind, however, so one will probably better use a Voron based printer like Brendon's (check brendonbuilds on social platforms). A Voron has it's Z axis connected to the top, not the bed, but that's no problem for the kinematics (the chain is the same).
From user feedback and my own experience, the configuration is a difficult task (it's easy to forget something or make a syntax error), so I add a report about the current configuration and check for completeness.
So the current steps this weekend are:
- test firmware with the CoreXY prototype and fix bugs
- add reporting
- work on RobotViewer to help to setup configuration (especially to calculate the endpoint for given angles/positions).
The code is still based on 3.5.0beta3, because I had problems to compile beta4. I build bins for Mini5, 6HC and Duet 2 (and 6XD in the future). Duet 2 is at it's memory limit, however, so I don't know how long it works. I'll build stripped-down versions for it, as long as I can.
-
undefined T3P3Tony moved this topic from Firmware developers
-
I am proceeding with robot kinematics now. I needed a break to allow my brain to process all this new mathematics and had to do something else.
My last action was to build a CoreXY AC prototype and deliver the kinematics in source and bins. It seems to work, but I'm not sure, because I am the only tester and the AC axes are not high quality for judging.
I want to start with the following plan:
- I will develop and implement only those configurations where a tester has committed to test and report the result.
- my prototype, i. e. tested by me, will be CoreXY AC with the Z moving the bed and AC being connected to the bed. For other combinations, I need testers.
- I'll make an overview matrix on the main documentation page, and who is testing
- another prototype will be a 6 axis industrial robot, but this takes time for building the necessary harmonic drives
If you're interested in robot kinematics, please think about supporting its development by being a tester. This would be of great help. Even if you have CoreXY AC in my configuration, it would increase trust if you can test also.
I develop for 3.5 beta 3 at the moment, but would like to see it integrated into 3.6. There are some topics like force calculation and optimization, path planning, a better segmentation of AC rotations (slerp based eg), collision detection, to name a few examples, which should be included and they are not started yet.
-
Dear @YuriConfessor , this here is the main thread about robot kinematics. If I shall implement your 4 axis palletized kinematics, please think about whether you want to be a tester and I implement it for you.
Currently I want to verify that CoreXY is working well, but then I can implement your 4 axis configuration. Maybe you want to post some information about it in the "My Duet controlled machine" section. Then we can implement and test the necessary RRF firmware together.
-
@JoergS5 I'm reading the discussion so I can know what kind of progress have already been made.
I've noticed that the robot viewer is not avaiable anymore, is there any specific reason for that?
-
@YuriConfessor said in Robotic kinematics:
robot viewer is not avaiable anymore, is there any specific reason for that?
The robot viewer was based on Denavit-Hartenberg, and I changed to screw theory. And second reason is, DWC is based on TypeScript now instead of JavaScript and I have not migrated yet. A third point is that I'd like to base all on C++ code. I'm still searching for a good solution to visualize. Qt (using C++) offers a web interface, which could be used in DWC, but unfortunately not in SBC mode (a Raspi connected to Duet).
-
@JoergS5 Hi, has there been any updates on this? I am seeing that in the documentation the parameters are still D and H. Is it still in the released version of RRF or has it already been changed?
-
@Toaster0042 D is a documentation mistake, I'll check and remove the wrong parts. It's all based on screw parameters. In respect to axis definitions the C parameter.
-
@JoergS5 I have tried using the 4 axis pelletized earlier and was unable, will you be releasing it soon? I am using this for a school project and tought it was working so I am in a bit of trouble now
-
@Toaster0042 I will make a release soon.
-
@Toaster0042 You can help me by providing
- some pictures of the robot arm. Special interest is how the parallelogram is built, i. e. is it a triangle or some other solution. How is the parallelogram connected to the endpoint?
- exact measures of arm lengths
- to which parts are the steppers connected
This allows me to build the same and verify the code before publishing.
-
@JoergS5 I can get the measurements to you a bit later but this is the arm I am using https://www.instructables.com/Build-a-Giant-3D-Printed-Robot-Arm/
-
@Toaster0042 I don't need the measurements, because it's not a 4 axis parallel robot.
It's like an industrial 6 axis robot, but without the 6th axis. Instead the 6th axis, the 6th actuator is used to grip.
I have code for the 6 axis robot, but not for your 5 axis plus gripper. I have to think about it. Your project is interesting, I want to support your robot type if possible. I will ask you to test code with your robot to verify the code.
-
@JoergS5 ah ok, I tought it would fall under the 4 axis robot with an aditional rotating joint, I am fine with testing it I simply need to finish printing it as I have not finished it yet and was trying to get the firmware set before but I will be happy to test the code
-
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.
