Hello Dima!

Thanks for replying - I really admire your work with mrcal, and have used it for a while in my work. And lensboy is heavily inspired by mrcal.

> Is your splined representation compatible with the mrcal splined stereographic model?

No. It was a conscious design decision to only use pinhole models, at least to begin with. As I understand it, the tradeoff is that the pinhole model does not support ultra-wide lenses like the stereoscopic model does. But I have never used a lens that has a field of view close to the limits of pinhole models, so I just went with pinhole models.

However, if I understood your documentation correctly, the distortion model should be identical, it's just the core model that is different.

> Is your splined lens representation better in some way?

I'm pretty sure it's not - I based it entirely off yours, without trying to improve it. However, I did implement regularization slightly differently.

> I didn't see any documentation about it.

Unfortunately I have not written documentation as impressive as you have in mrcal, though I aim to. I wanted to get the project working as soon as possible to use it at work.

> If you think the mrcal distribution methods could be improved, and are willing to help improve it, I would be very amenable.

I actually did attempt this in this fork: https://github.com/Robertleoj/drcal (I'm sorry for the brazen phrasing in the readme, but I believe it is sligtly in the style of the name "numpysane").

The purpose of this was just to have functionality of mrcal but available on pypi, and with a build system I understand better.

However, I abandoned this, instead opting for making a library from scratch, partly because I had a hard time removing numpysane as a dependency (I want to have very minimal dependencies in this project). I'm not sure how to reconcile this, but I'm happy to chat about what I did there.

> Do you support mrcal .cameramodel files? If not, can you do that?

I don't support them currently. I'd love to chat about doing this, even if loading them would lose some information because of different data models.

Don't hesitate to send me an email, you can find it on my github profile.

Hello! I'm the creator of SlamDunk, and I use it daily in my day-to-day work for 3D visualizations.

I really like it, so I thought I'd share it.

Thanks! Exactly - I feel much more comfortable talking about the hardware at work now after having made this and feel more confident about making something more advanced.

This is my first printer so I don't have anything to compare it to, but to me it seems to "just work"

Right? I'm thoroughly enjoying that rush :D

Really cool 4dof robot - thanks for the reccomendation

Thank you, great to hear!

That's true - using numerical optimization was just the simplest/fastest way to get it working :P

Nice - did you just chuck it into wolfram alpha or sympy? How'd you get it?

It was a long long time ago. I don’t remember how I found it.

I do remember being frustrated by the endless papers on SCARA and the importance of the inverse kinematics but no mention of what they actually were. So here they are. (I just checked now, and there seem to be at least a few papers online with the derivation. Times have changed)

I also have this:

  def do(self, (x, y), (dx, dy)):
        """ Calculate o derivative (do1, do2) given position (x, y) and desired movement derivative (dx, dy)
        """
        xy2 = x**2 + y**2
        ll2 = self.L1**2 + self.L2**2
        lld2 = self.L1**2 - self.L2**2
        # do1
        N = x*dy - y*dx
        M = xy2
        P1 = x**4 + 2 * x**2 * (y**2 - ll2) + y**4
        P2 = -2 * ll2 * y**2 + lld2**2
        P = P1 + P2
        Q = xy2
        PQ = math.sqrt(-P/Q) 
        R = (xy2 - lld2) * (x*dx + y*dy)
        S1 = math.sqrt(xy2)
        S2 = P
        S = S1*S2
        # do2        
        T = 2 * (x * dx + y * dy)
        U1 = (2*self.L1*self.L2)**2 - (x**2 + y**2 - ll2)**2
        U = math.sqrt(U1)
        return -(PQ*R)/S + N/M, -T/U

For this I used a symbolic solver but I don’t remember what it was. I also don’t remember if it was a meaningful improvement over a simple interpolation between angles.

BTW if memory serves, parsing basic SVG is pretty easy. Though, these days it may be more useful to implement a gcode parser as there are so many freely available gcode generation tools.

I am currently doing something similar for an off-the-shelf drawing robot with two arms, each with a shoulder and an elbow joint - load svg, convert layers to numpy arrays, then get the angle configuration for each point and save them to a format the robot can read and draw. However, I am finding that the time required to compute the points is quite long.

The fastest way I have right now is a large look-up table (ie. precompute angles for each point of a canvas with a sufficient precision, then use the table to do fast searches for the nearest point).

That's odd, have you profiled it?

I took a look at the code that I started with and... it is kinda horrible.

https://github.com/AnykeyNL/Quincy/blob/master/coordcalc.py#...

There is a loop in a loop that goes through all the possible values of x and y to find the correct ones. No wonder it's so slow!

The scipy solver - inspired by the original article, I used https://docs.scipy.org/doc/scipy/reference/generated/scipy.o... - isn't much faster though (from reading the docs, it's just a smarter random search).

I guess it's time to learn some linear algebra (again!) and create a custom algorithm.

Did you try using the previous configuration as an initial guess to the numerical optimizer? If the next position is close to the previous one, the solver should be very quick.

Also, you can probably get much faster results if you obtain the gradient of the forward kinematics.

Thanks, much appreciated! I will try that.

I am trying multiple optimizations right now, mostly centered around reducing the amount of lookups required.

Thank you! I made it like that purely for fun, this project was not intended to be useful, or have the best mechanical design :P

Using Gcode is a good idea, though it does seem a bit overkill for this simple application

Oh wow that is refined indeed - I'll check it out, thanks!