Is LEGO inadvertently pushing Technic towards CAD?

Even though I haven't considered the Technic part spectrum poor at any time since the 80's, a compliment I must give LEGO is their subtle yet highly important ability to introduce new parts sensibly. It is still very much an ongoing process, and when I see a new part announcement somewhere, I frequently find myself thinking "Ha! That's exactly what was missing". Various new flavors of pins, axles, connectors, etc. may not seem like a big deal to an outsider, but they usually allow new approaches and techniques, and indirectly, new functionalities.

And, season by season, by today we've reached the point where possibilities are virtually endless. An example that comes to mind right away are gearboxes. Compare what was possible in the 8865 Test Car to the modern 7+R models packing triple the functionality in a similar volume, thanks to only a few specialized, but cleverly thought-out parts. Nowadays one can take an engineering catalog of typical linkages and mechanisms, and the question is no longer whether it can be recreated with Technic, but rather which of the possible routes to take.

From one standpoint, that is a great situation to be in, and I am not going to deny it―after all, that is one of the main goals of the entire Technic theme. But this enormous flexibility has, at least to my mind, begun forming a rather different type of a problem. Namely, that of a spiraling complexity.

In the recent years, whenever building a flagship Technic set or any kind of a very sophisticated mechanism (which there is no lack of in the specialized community web), I had an increasing feeling that the mechanical complexity possible now is at a level which is no longer feasible to design directly, using hands, parts, trial and failure. Some state-of-the-art Technic gearboxes and linkages today are so clever and optimized into such an incredibly tiny volume, that I cannot imagine ever designing them at my LEGO workstation only.

Yes, I am fully aware that sketching and planning constructions elsewhere has been a must for top-notch Technic models for a long time already. I've even written so myself on this very site. But what I feel now is that the possibilities have been brought up to a level where everything but the final construction needs to be done elsewhere, if one intends to do a perfect job. And that "elsewhere" is no longer a paper, but one of the available LEGO CAD programs, which have become really good.

As if the top-class Technic building is undergoing the same transition as industrial mechanical engineering did some decades ago. The most advanced mechanisms designed today are so complex that building them at a workbench and testing them would be far too expensive, and take insane amounts of time. Therefore, right up to the first prototype, everything gets designed and simulated on a computer. It saves time, manpower, resources and money, and has revolutionized mechanical engineering.

My point is that something similar is now happening for our beloved Technic. With its extremely flexible and versatile parts, it is no longer feasible to find the best design by building it with real parts, iteration after iteration, but by turning on one's computer and trying them in a CAD. This can also be seen as some sort of "revolution", but the question here is—is it a desired one?

Possibly, but it means that the sophisticated Technic building will no longer follow the classic "open your box of parts and unleash your ideas", but rather become a hybrid of CAD and building, with the latter starting only at the mature prototype stage. I don't personally mind it, but I also don't necessarily like it. One can surely construct things of jaw-dropping complexity, but isn't one of the points of LEGO to keep us away from the screens, rather than keeping us bound to them?

Revisiting automatic embroidery

It's been quite a while since the first posts about my LEGO embroidery experiments saw the light of day, but the project as such has not been closed. To the contrary, I have recently started working on a more advanced version, and this time on a one that could at least rival the output of the hobbyist dedicatged embroidery machines, except for speed. It is still largely a project in progress, as many components get designed, redesigned, scrapped and reimplemented in a different way, but some points have surfaced indeed and are worth mentioning for those interested in building their own machines.

Obviously, the precision of the embroidered material's movement is of high importance: embroidering lines (satin), especially if they are only a few millimeters thick, looks very clumsy if the exact points where the needle struck the thread are not perfectly aligned. Imprecisions as small as 0.5mm can be annoying, whereas those in the range of 0.1-0.2mm are still noticeable.

This is, I'm afraid, where the precision of the LEGO movement mechanism was put under maximum strain (already in the first instance of the machine) simply because it was expected to do something it was not designed for in the first place. There are several factors in play, subtly braided together.

In order for the movement to be precise, the embroidery fabric frame has to be strong and resist any kind of deformation. This as such is not a big problem because multiple Technic beams with lots of reinforcements can bring the frame up to the required level of stiffness. But it causes another one: lots of reinforcements necessarily make everything heavier and larger, in turn increase the friction between the frame and its movement (X-Y) mechanism. Taking into account that the frame has to be squeezed very precisely into its rails (otherwise its accuracy would be sacrificed again), this causes the amounts of friction that prevent smooth travel. To be more precise, it causes tiny hystereses where the frame needs to overcome the tiny amount of friction before it finally moves, but then does so momentarily, until the next such friction point. All that results in a somewhat rough movement, unless the whole structure is reinforced even more.

The other, and in my experiences the more troubling problem, is the inherent backlash of the movement mechanisms. The moving parts themselves can, to some degree, be designed with minimal backlash, mostly using friction pins and sacrificing some smoothness in return for precision, but the actual NXT/EV3 motors suffer from it quite a lot, mostly due to their unavoidable internal gearboxes. (To wit: these are not stepper motors, but standard DC motors connected to a gearbox and a position sensor.) Precise movements - that is, at the order of magnitude of 10-20° - are rather unreliable. One way to approach this problem is to reduce the motors' output themselves by a large factor using gearboxes, but that ends up introducing just as much additional backlash.

A more promising approach is to always enforce "recoil" between movements, i.e. make sure that the correct position is always reached from the same direction. That ensures that the relative positions are retained correctly. E.g., if we always want to reach the target point by moving to the right, in case the target position is left from the current one, the machine will travel left a bit further than needed, and then return to the correct position towards right.

Exactly that approach I employed for my previous machines, but it turned out to cause yet another problem: the fact that, while embroidering, the thread tension plays a major role in the final pattern looking tidy and clean. If a recoil technique is employed to guarantee precision, all recoiled movements pull a bit more thread than needed, and loosen it as the fabric returns to its correct, intended position. More thread than needed results in a wobbly pattern.

Therefore, for comparison, I'm currently repurposing the X-Y movement mechanism of a laser cutter (powered by GRBL commands transmitted through a virtual serial COM port over USB) to move the fabric, while the LEGO EV3 takes care of driving the sewing machine through three NXT motors connected to a common shaft.

The controlling software (which is currently a custom script I slapped together in Python) is therefore a bit more complex, as it has to coordinate the loading of the embroidery, the EV3 control via Bluetooth, and the GRBL serial commands to the X-Y hardware.

Let's see if this will work... keep fingers crossed.