Robotic kinematics
-
@toms BTW I'm currently reading Colapinto (master thesis, thesis, and articles), it's an exceptionally good source of information about geometric algebra - and free. He clarified some of my open questions.
-
Hello Joerg,
First of all, thank you for your continuing support & effort, this is really impressive work you have accomplished so far. Looking forward to the first final release (although it will probably never be final I reckon)!
I was wondering if you had any recommendations as to what robot you would take into consideration that works best with the Duet boards. I am new to this, and I don't really know where to start and particularly what I need to pay attention to.
What I am looking for is a robot arm that would allow for a "build volume" (if you can even use that terms in this regard) of approximately 1500x1000x1000mm (1500mm being the maximum height) for 3D-printing. I know there are lots of commercial options out there, but I was wondering what criteria a second-hand robot would have to meet in order work with your code and the Duet 2 (or 3). I don't want to spend 10K plus EUR before I know what I am doing.
Would be great if you could share a few ideas, but I totally understand you're a busy man.
Looking forward to hearing from you.
wieman01
-
@wieman01 hello,
this is a big robot you're planning to buy (or maybe build?). I have no experience with big robots, so I can only give you some thoughts without guarantee, but maybe on the forum are users with experience.
My thoughts are, if it shall be Duet based:
- it will use probably servos with high current, so a 6XD board is probably the right choice, with a 3HC extension card for optional more axes for endpoint functionality if necessary
- those robots use a lot of energy to operate. It depends on your requirements, but I would personally try to buy a low enery one which is slower or smaller or has less payload capability, but this depends on what you're planning to do with it. For palletizing e.g. the 5 axis robots have counterweights, they should need less energy compared to the 6 axis ones. The palletizing robots use a parallelogram structure for one axis less.
-
@JoergS5 said in Robotic kinematics:
@wieman01 hello,
this is a big robot you're planning to buy (or maybe build?). I have no experience with big robots, so I can only give you some thoughts without guarantee, but maybe on the forum are users with experience.
My thoughts are, if it shall be Duet based:
- it will use probably servos with high current, so a 6XD board is probably the right choice, with a 3HC extension card for optional more axes for endpoint functionality if necessary
- those robots use a lot of energy to operate. It depends on your requirements, but I would personally try to buy a low enery one which is slower or smaller or has less payload capability, but this depends on what you're planning to do with it. For palletizing e.g. the 5 axis robots have counterweights, they should need less energy compared to the 6 axis ones. The palletizing robots use a parallelogram structure for one axis less.
Hello, @JoergS5,
Thank you, that is a starting point.
We will be using that robot for 3D-printing. The overall payload it will have to carry won't exceed a few kilograms. So there is no heavy lifting involved.
Buying vs. building one myself... that is the question. I will need to see what is available first and then decide. It's tempting through to start designing one from scratch now that you are asking...
wieman01
-
@wieman01 said in Robotic kinematics:
It's tempting through to start designing one from
When I restart prototyping again, I'll document it in the forum, and you can decide whether you want to join!
For 3D printing, you need higher precision than usual, and the typical 6 axis industrial Kuka robot has too low precision for 3D printing (if I remember correctly, they have around 70 micrometer precision or accuracy). It will be very difficult to achieve the required precision with 1.5 m added arms (maybe impossible). If possible, I expect a parallel arm based printer can achieve it.
For your case, a CoreXY or Cartesian will probably be better: high precision, high possible build volume. 5 or 6 axis support can be implemented by combining it with a 3-axis print bed (AC, BC or ABC axis). The TUM (munich university) in Garching has a printer in your desired print volume, I saw them printing clay as well. Here in the forum is a current thread about a high volume printer.
Edit: this thread: https://forum.duet3d.com/topic/31228/dr-d-flo-s-big-build -
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).
