Robotic kinematics
-
Hey @wieman01,
If you're interested in building your own 6 axis arm, I'd recommend looking into AnninRobotics. Chris Annin has done an awesome job putting together a pretty capable, open source, robot arm. It certainly doesn't meet your reach requirements, and having built one, the backlash is substantial enough that I don't think 3D printing would make sense / be practical (at least with traditional nozzles < 1mm).
I have version 4 of his robot arm running on 6 HCL's and a 6XD at the moment. There's more info and videos on my GitHub repo if you're interested.
It's not the cheapest build, but it was certainly fun.
-
undefined dc42 referenced this topic
-
@JoergS5
Hi Joerg, we are building a 5 Axis printer, XYZAC, very close to robot type 'Open5x'. I was happy to see that you already did a huge amount of work to get robot kinematics work on Duet, so I would like to build on your work.
I took the sources from v3.5.0-beta.3 and added your 'RobotKinematics' files. With some minor updates I managed to generate a binary. Unfortunately the system crashes (reboot) when I try to set the D parameters. The configuration itself looks ok, but the crash occurs as soon as 'RobotKinematics::getForward' is called. I have the following questions:
1 - Did I take the correct set of sources
2 - Should robotType='Open5x' work with your code base of December 2022 ?
3 - If yes, can you give me some hints how to find out what I do wrong.
4 - If no, do you have any advice, what the best starting point is to develop the XYZAC kinematics.
Thanks in advance ,
Lex James -
@LexJames the code you reference is based on Denavit-Hartenberg configuration parameters, but I changed to Screw Theory. The reason for the change was, that some positions didn't iterate correctly, so the change is from iteration to closed form (i. e. algorithmic solution).
The sources changed. I currently build a CoreXY 5 axis prototype to validate the code and then publish the code on github, together with binaries.
Sorry for your waste of time of the old source. I'll delete the repository until the new build, which is based on 3.5.0beta3.
-
@LexJames
Thanks for your prompt reply.
I will wait for the implementation based on Screw theory. Can you say something about the timing?
Can I help to speed things up? I don't have a development environment for Duet but I can test and develop in Windows.
Is there an old branch that worked for XYZAC?
Thanks again for all your good work. -
@LexJames of course it will be great if you can test the build. Developing and testing in Windows is not necessary currently, as I do it myself a lot, unit testing.
It's better to wait for the new build, because in the old ones I've tried different methods and I lost the overview (I tried everything like Euler angles, Euler axis, Jacobian with inverse, random iterations, quaternion slerp). The great thing about geometric algebra is that it integrates and explains them all.
I build the prototype as fast as I can. The build will be soon after.
-
@LexJames
Understand. Sorry to ask again about the timing because we have to decide to build on your generic solution versus building our own kinematics dedicated for our purpose. We prefer the first but do you need days, weeks, months...? -
@LexJames I make a build and post tomorrow morning for a first test.
I check it in and make binaries.
-
@JoergS5
Great ! I'm using a Duet3HC6 + 5x Duet Expansion 1XD, however if you check-in the source code, I can compile myself. Keep you updated on my findings. Thanks. -
@LexJames I've uploaded to https://github.com/JoergS5/RepRapFirmware_robot
I could not finish my prototype however. I'm out of office until Tuesday, then I can proceed.
In the Readme I explained how to compile, but I compiled a 6HC bin.
If you have and want to try a toolchanger, please set the defaultToolLength and the M position (the end position of the reference angles) explicitly after a tool change. I need a prototype with toolchanger before I can test it. Maybe I should change to this explicit setting anyway. The risk that a tool is changed unrecognized and a tool crash if the new tool is longer than before is high.
-
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).
