Welcome! Log In Create A New Profile


Delta heightmap (and more) Simulator

Posted by corry 
Re: Delta heightmap (and more) Simulator
October 15, 2015 02:03PM
Despite your general unexplainable standoffishness about this, I do accept I'm not a genius. What I can say is intuitively, I can see there's an interdependence of variables. As long as they are accounted for, least squares should solve with them and generate a correct solution, but I don't have the rigid definition for it. To prove/disprove my theory, I decided to go to math. Fixed some bugs in the sim, didn't fully include all corrections, I'll get the new version in a few hours, I gotta run to physical therapy...but wanted to say, after correcting things, verifying correct operation of all variables, etc, I made a "model" or a printer with radius errors in repetier, fit the 3 point tangent circle to it, used inventor to calculate the angle errors, and new radius, fitting the towers to a perfect circle, and running the sim with those parameters. The result was impressive, but not accurate. Its close, but there is an interdependence not being included.I'll post pics, new software, etc when I get back from PT so you can check my work and prove to yourself there is more going on than you think. Its human nature to oversimplify, thus the reason software projects are the worst at predicting time to complete (its more complex, and oversimplification leads to a strong belief it will take far less time than reality dictates....its an evolutionary mechanism because if we understood the complexities of problems we wish to solve, it would appear insurmountable, and thus become depressing, and would result in our non-starting of solving the problem.

I know, you want proof, I just really have to run...I was willing to admit I am wrong if I was.

Also, kindly don't put words in my mouth. I never said you cant fit a circle to 3 points. Ok? I said you're missing something, not about a circle. Don't treat me as a moron, and I might not be so pissed back at you. This principal works for everyone
Re: Delta heightmap (and more) Simulator
October 15, 2015 03:52PM
Ok, lots of pictures means lots of posts. Code will be on SF shortly.

First is the inventor drawing of the 7 factor model. Note this shifts the origin, obviously since the points are no longer around the origin. I chose a relatively small error to use, .4 and .6 mm on the a and b towers. Note the radius increase as it should be...
I then zoom in to let you see the angle differences
To start with, I put the ideal calculated values into the sim. The results weren't actually stellar, so I sat there fiddling with parameters the 7 factor algorithm can use to minimize the error, this is the next set of pictures. Z is pretty good. X and Y suffer a bit. For most, this is realistically enough. I want to add additional capabilities to the machine though. I want more accuracy. Thus, why I'm working.

Next post will show the errors from inserting the parameters as shown in inventor...
open | download - New-Single-Radius-Correction-Circle-with-Old-Tower-Positions-and-New-Angles.png (13.1 KB)
open | download - New-Single-Radius-Correction-Circle-zoomed-in.png (14.7 KB)
open | download - 7-Factor-Z-Least-Squares.jpg (387.2 KB)
open | download - 7-Factor-X-Least-Squares.jpg (319.5 KB)
open | download - 7-Factor-Y-Least-Squares.jpg (314 KB)
open | download - 7-Factor-XY-Least-Squares.png (321.1 KB)
open | download - 7-Factor-XYZ-Least-Squares.jpg (314 KB)
Re: Delta heightmap (and more) Simulator
October 15, 2015 04:01PM
Now we have the "ideal" values moving the circle and fitting it....

And then we have matching all parameters as the are in reality. The only error looks to be floating point error.

It kinda makes sense when you think about it. You're increasing your radius without lengthing your rods....this is why I say, everythings interrelated in the model. You can't simplify down as much as you'd like to get a truly accurate model. Perhaps close enough for most. But I don't see the reason not to try for an ideal solution, if one exists and is attainable. Is that really something to ridicule/insult?

Now I'm sure you're going to assume some sort of trickery, so I'll upload the source code now. If there are errors, I'm more than willing to fix them! If I'm wrong, I'm willing to admit it! All I want is for my printer to be calibrated as close as possible. I also want others building custom printers with little to no idea about delta kinematics to have to learn all about it. I didn't want to get into it this much. I was under the impression this was all done when I started designing back in January. That's my goal here. Nothing more. No can we please act like colleagues and get along, work towards an ideal solution if one is available?
open | download - 7-Factor-Z-Ideal.jpg (336.1 KB)
open | download - 7-Factor-X-Ideal.jpg (352.3 KB)
open | download - 7-Factor-Y-Ideal.jpg (315.1 KB)
open | download - 7-Factor-XY-Ideal.jpg (328.8 KB)
open | download - 7-Factor-XYZ-Ideal.png (351.9 KB)
open | download - True-Factor-Z.jpg (513.4 KB)
open | download - True-Factor-X.jpg (491.4 KB)
open | download - True-Factor-Y.jpg (487.8 KB)
open | download - True-Factor-XY.jpg (534.1 KB)
open | download - True-Factor-XYZ.jpg (496.6 KB)
Re: Delta heightmap (and more) Simulator
October 15, 2015 04:31PM
Everything is updated. I'd love to be proven wrong. It would be far less work!
Re: Delta heightmap (and more) Simulator
October 15, 2015 04:33PM
Yes the factors are interrelated. In particular, the rod length and delta radius can be changed together in such a way as to maintain flatness over the whole bed except at points that are approximately opposite a tower and so far out that on most delta printers they are outside the bed if it is circular. Hercek posted a model on the Delta printer forum that demonstrated this, which explained my observation that the least squares solution matrix is on the verge of being ill-conditioned when solving for the diagonal rod length. So I now advise against auto calibration of the diagonal rod length on typical delta printers.

I remain unconvinced that moving the bed origin (which is what your additional parameters provide for) serves any useful purpose for any shape delta printer I have heard of, and I remain convinced that adjusting it during auto calibration is a dreadful idea. You would need a very badly built delta printer not to end up with an ill-conditioned solution matrix. The more accurate the printer is, the more ill conditioned the matrix will be. Just think about it: in a printer that is perfectly built apart from the tower positions, after it is perfectly calibrated, the printing plane is flat all over; therefore shifting the bed origin has zero effect on calibration. In a slightly less than perfect printer, small probe errors will give rise to large translations of the bed. I read a post recently in which a person using a different auto calibration algorithm experienced exactly this effect. Now that you have a model, I expect you will see this for yourself.

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: Delta heightmap (and more) Simulator
October 15, 2015 06:13PM
So if that were the case, I should see a constant error in x and y. If the origin were simply shifted, each point should be off by the same value right? How about you look at the images.

Note the max/min is still on the Z error in those pics...sorry about that. I'll again update SF, but nothing is changed in the image generation. Just in the interest of full disclosure, the origin offset of the test "printer" in the examples is x= 0.1154701mm, y=-0.3333333mm.

Now once again, I'll ask for civility. I'm honestly trying. My inclination is, as a normal human, to treat malice with malice. I'm actively blocking that at the moment. Perhaps that last response wasn't meant as snippy, but because of past posts, that's how it reads to me. Its certainly dismissive, and it sure seems like you didn't check the images, which is more dismissiveness, and just as rude as being snippy.

I don't understand why you'd treat this as some sort of personal attack. Do you do this at work in code reviews? If so, well, I won't comment further. If not, then why here? Because you don't know me? Because of the anonymity of the internet? Are you acting different online than you do in person?

Anyhow, As far as I'm concerned, I've proven to myself there is something worth further study here, and will continue to work on it, regardless of what you or Hercek may think about it. His was the name I couldn't remember, but I read your original post, so when I refered to the wxmaxima script, its his model I've been referring to the entire time.

I'm always under the belief that there is no such thing as a failed experiment since each experiment adds to a knowledge base. This is why I was willing to humor you despite the seething malice, and attempt to prove myself wrong with your "guidance". If I get through to the end, and there was a bug in the model, or I misinterpreted data, or some other unknown unknown, I can at least document fully why that is the case, adding to the collective knowledge so the next person to come along doesn't waste his/her time. As of right now though, I see non-constant error on X/Y in a least squares style fit. So that says to me, 7 factor is a non-optimial fit, and I should continue.

If you see an error I've made in the models I've presented, by all means, point it out. I know I'm not perfect, perhaps you need to learn that you might not be either, and Hercek might not be. If you're going to spew malice and discontent without citing any of the model data pointing out a hard, concrete error I've made, just don't bother, I'm through replying to those. As I said, I'd like to be wrong. For me, being wrong is the easy path. I don't mind it one bit. When I see something wrong though, I'm going to try and fix it.
Sorry, only registered users may post in this forum.

Click here to login