Tuesday, February 19, 2019

LEGO Technic Seismometer Prototype

Well, in its barest concept, a seismometer (device for measuring Earth's surface movement, namely quakes) is a rather simple thing. A large weight, suspended to move freely, attached to something that can note its movements - and that's it. And while assembling a rough one from parts scavenged from an old rusty car at the dump may seem just as simple, building one from LEGO Technic brings its own set of challenges along.

Although a group of dedicated weight bricks (such as 73090a) would have been a "purer" solution and possibly serve its purpose better, I went for the more pragmatic approach and connected a set of several battery packs together - thus indirectly using batteries as weights. Altogether, something the size of a large coffee mug ended up weighing well over one kilogram - more than enough to have the concept proven.

This weight is suspended, hanging on two rubber bands. I agree that, in theory, going for a more complex setup featuring six or eight bands (one for each corner) would have helped with force distribution and rotation, but would have been a nightmare to tune and set up. Two rubber bands allow for sufficient freedom of motion, however, and have a better chance of retaining the seismographer's sanity.

Furthermore, the weight is attached to two independent pieces of thread, one in vertical and another in horizonal plane, both forming a closed loop, which is led through a system of pulleys to translate the weight's movements into proportional movements of the threads. Finally, attaching pencils to the threads and letting a writeable surface slide perpendicularly underneath the pencils, completes the essential seismometer.

Hence, each pencil notes the weight movement in its own direction over time - one vertical, and other horizontal. This is a common approach with real life seismometers as well, because horizontal and vertical movements of the Earth surface lead to different effects and are measured separately. True, this weight could have included a third thread loop measuring the weight's movements in the third direction (sort of like X-Y movement) but that would add lots of complexity while bringing only marginal functionality, and likely go beyond the 48x48 baseplate I decided to use as a caliber for this project.

The writing surface, which is in this case a cascade of white Technic panels, is driven across the direction of the pencils via a rack and pinion system with variable speeds, controlled with a gearbox, allowing for 10 possible settings, balancing between precision in timing and total duration of a single "plate". With only minor adjustments, one could convert it so that a standard roll of paper (e.g. like those used in shop counter printers) can be used.

Finally, apart from dozens of accurately perpendicularly tuned pulleys (perpendicular pulleys retain linearity better), both threads pass through a simple, manually controlled tension mechanism employing a large 40T gear and a worm gear, allowing the seismographer to adjust the correct tension level finely once the seismometer has been set up. The aim is to keep it tense enough so that all weight movements are precisely translated to the movements of pencils running across the "writable" white panels, yet loose enough to avoid friction that would overly hamper the movement of the weights. With some experimentation, I've settled for the tension of about 1.5 Newton, roughly the tension you would get if you suspended your mobile phone off a thread.

The only active component in the entire mechanism is the motor driving the writable panels, mounted on springs to further isolate it along with its vibrations from the rest of the mechanism (though I admit it's not as bad with fixed mounting either). But this could even be done manually if one wanted - the motor at least assures that the graph movement speed is at least somewhat constant. The range of possible speeds, of course, increases if one uses regulated voltage at the input, like I did with the classic 9V train controller.

So, an obvious next question is - how does it behave? The good news is that it proves the concept indeed: having been set upon the table, it is sensitive enough to measure, at least with some consistency, average table bumps, and would surely have no problem measuring a mild earthquake. But it is, on the other hand, far too insensitive to actually measure micro-movements of the Earth surface which are typically imperceivable for people, and which real life seismometers are built to measure. Let alone even finer things like steps of people in the building, opening and closing faucets, bass kicks from someone listening to music somewhere, etc.

I don't say that the latter group could not theoretically be measured with LEGO, but that would require a different design, utilizing more specialized parts, and would likely be far too sensitive for actual quakes. It would probably revolve around a multi-reflection design, featuring a mirror on the weight, with a laser pointer pointed at it, and furthermore with the ray being reflected multiple times to artificially create distance and thus increase resolution. Finally, the laser spot's movements would be monitored by a camera, or by a cascade of Mindstorms' light detectors, or something similar. Such a setup's sensitivity can in theory be increased virtually infinitely, but at the cost of maximum measurable extents' window reducing. Id est, it may well measure the vibrations of the roof being shaken by the wind five stories above, and someone sorting out cutlery in the kitchen in the other wing of the house, yet go completely off scale if breathed into.

Finally, a bit of historical trivia: although commonly thought to be of modern origin, the first seismometers actually got built as early as 2nd century AD, in China. It was a rather simpler approach, with a precariously ballanced ball at the top of an inverted bowl. The fact that the ball dropped from the bowl indicated that there was an earthquake, while the direction of the ball's fall gave a rough idea about where did the earthquake originate from - letting the owners know in which direction should the help and rescue teams be sent.

Built for BrickStory 2019.

Tuesday, August 8, 2017

LEGO Aquatics lecture

A lecture I gave at Paredes de Coura Fan Weekend 2016 in Portugal. Enjoy!
I've always been attracted to various aquatic sets, but the game gets serious when we start dealing with real water.

Tuesday, January 3, 2017

Tolerances, accuracies and their sensible limits

Now with the Engraver v4 completed, as shown in the previous post, it's no secret that the large amount of its development had actually focused on improving its accuracy which, in turn, meant reducing tolerances wherever possible. So perhaps some of the experience and the lessons learned throughout may be of help for builders who are attempting build similar constructions. Keep in mind that these are merely my notes and thoughts, rather than something I believe should be set in stone.

First of all, it is important to be able to judge where should the tolerances be reduced for the maximum effect. In most situations, I've found that only about a dozen parts or so are responsible for well over three quarters of all inaccuracies in the system, and several carefully observed test runs should easily pinpoint them. There are a few standard culprits:
  • backlash between the gears
  • unwanted flexibility of the beams and axles (or similar supporting parts)
  • slack of the frictionless pins
  • friction (and therefore hystereses) all around
  • axles which do not fit into Technic pin holes snugly
  • overcomplexity of kinematics or control bars
All of these can be dealt with one way or another. Overflexible supporting structures can usually be easily reinforced, or the studless beams replaced with the studded. Axles can be replaced with the pins, and frictionless pins with the friction pins. Backlash cannot be fixed, but it can at least be controlled by keeping the entire system under a mild tension or resetting (recalibrating system with a run-up) ahead of each change of direction. The same is applicable for hystereses as well.

Combining all these techniques, in this case on the Engraver but basically applicable anywhere, I've managed to reach the final resolution down to about 60 µm, based on the linear actuators. The reasoning is simple: the Mindstorms motors are directly connected to the large linear actuators, and 15º is about the smallest angle they can be turned reliably. With the actuators' ratio of 240º/mm, it is clear that the smallest reliable linear movement amounts down to 0.0625 mm, i.e. a sixteenth of a millimeter.

The engraving head itself was levered at about 1:3, so its theoretical accuracy would be closer to 20 µm, were it not for the hystereses that bring it to about 100 µm, and which is perfectly enough for its purpose anyway.

The obvious question related to the point I'm trying to make: can the precision be improved further using downgearing to an arbitrary level, at the expense of speed? Theoretically yes, obviously. But I fear practicality gets in the way. The amount of reinforcements, pullbacks and tensioning mechanisms already required to take advantage of the 60 µm resolution is staggering, and pushing it further asks for even more such mechanisms which are heavy by design, in turn requiring even more compensations. Altogether I wouldn't exclude it as impossible if lots of resources and effort is invested, but for practical matters, I don't think going past, say, 10 µm makes any sense.

Even 60 µm sounds good (after all, many standard papers are thicker than that) as long as you keep in mind that we're talking about the resolution in the relative sense. Id est, we can know that our engraver, needle or something similar has moved specific 60 µm from its previous position. But the absolute accuracy is a different ball game entirely. At the best of times, having its resolution at 200 µm is very good, under controlled and stable conditions.

We are basically asking for plenty of accuracy from the parts that were not designed for it in the first place. Sort of like making a miniature engraving on a single bean using an old kitchen knife: possible, no doubt, but requiring a huge amount of "special techniques".

Thursday, December 22, 2016

Engraver Mark 4


Yes, it has already gone as far as the fourth iteration; I'm still convinced that the "proper" 3D CNC cannot be done using this design for a variety of reasons I've touched on in the earlier posts, but at least the engraving part seems to be more or less satisfactory now. I've experimented with about a dozen possible improvements, among which some made it to the final version (that is, final for this fourth one at least).

P1170650The one that made the largest difference was possibly the conversion from pure "vertical" rack mechanism that raises and lowers the drill into one based on parallelogram linkage. This means that the vertical movement of the drilling head is circular rather than perfectly vertical and linear, but if adjusted properly, it does not cause any problems, while it simplifies the mechanism a lot and also makes it more precise and sturdy.

The first design's parallelogram was controlled by a linear actuator fixed to a point on the drilling head itself. Although very practical and elegant, this had an unwanted side effect: the entire construction was strained which led to bending and therefore, inaccurate drilling points. Therefore the linear actuator was moved onto the "sledge", reducing the effect to a negligible level. This also offset the center of gravity of the sledge, but this turned out not to cause any problems, it seems even to have actually made the entire structure more stable.

P1170723Drill bit is now held by a structure that forces two rubber 2L connectors one next to the other, as the drill itself is squeezed right in between. Though I've got to admit being somewhat skeptical about this solution at first, it actually turned out to keep the drill bit nicely and reliably centered. And has the advantage of allowing nearly any sort of drill bit being used, at least as long as they are not overly thick, that is, over a few millimeters.

In order to conserve power and the classic 9V motor used to rotate the drill bit (without any gearing), it is run only when needed, i.e. during drilling, and turned off while moving the drilling head about. This is done indirectly, using a fourth EV3 motor which flicks the Power Functions switch directly through an axle. This also, after a few adjustments, turned out very reliable, and was dismantled only when I accidentally manually rotated the motor too much.

P1180078The results have altogether been pretty good - the engraved images are noticeably clearer and more precise than its predecessors. The critical parameter is the force by which the drill point pushes against the engraved surface, and this is something that needs to be accurately set manually. I suppose this could in theory be done by using contact sensors, but it would - because of very little distances involved - ask for a complete overhaul of the design. That might perhaps turn out to be the mission objective for the future Mark 5, should it ever turn out to see the light of day.

Finally, instead of controlling everything from the computer, now the engraver itself offers a green and a red button, the red one to terminate the process at any time, and the green one to firstly confirm the engraving area (the drill point makes a run around the to-be-drilled area to ensure there are no obstructions), and later to pause the drilling process.

P1180105The maximum engraved image size is still limited by the extents of the linear actuators, which turns out to about 5-6 centimeters in practice. This is more than enough for cutlery or bricks, of course. Shifting the approach over to the new linear racks could increase it to at least 8-9 centimeters square, but would require more compensating movements because of the backlash between racks and pinions and therefore perhaps reduce the accuracy a bit. I've written already elsewhere, and I still think, that a longer linear actuator or actually a linear rack as envisioned by MinuteBot would help a lot - if only it was viable for its makers.

Another thing this design has improved upon is reproducibility. Since it relies mostly on common parts and is a very barebone approach, it is rather easy to rebuild it on demand quickly and painlessly. Anyway, nearly all X-Y-Z control mechanisms tend to converge to similar designs after all, given the same premises. As a pure challenge I've thought of building it as an alpha-beta-Z mechanism, i.e. involving two rotors rather than X-Y axes, but I don't see any particular advantage over the existing design, except for perhaps looking better.

Friday, July 15, 2016

Competition Crawler Mk4

In the wake of the previous GT Crawler featuring an unconventional yet a slightly lacking chassis concept, for my next one I decided to get back to the roots a bit. Therefore this CC4 (Competetion Crawler, Mark 4) got a standard dual floating axle suspension, somewhat similar to the one seen in the official 9398 Crawler, though with a few modifications I wanted to try out.

For starters, although it is not easily visible on the photographs, this chassis is slightly (2-3 studs) shorter and narrower than the 9398's. The intention was to make this crawler more maneuverable and easier to sneak through the tight passages with. This, of course, in turn reduces the stability, which I attempted to compensate by mounting the heaviest parts (the batteries and the motors) as low as comofortably possible.

The other difference regards the suspension angles and tuning. A thing that bugs me for a while already, not only on 9398 but on majority of official Technic sets, are their suspension springs which are far, far too stiff. Typically they are hard enough to keep the entire chassis in the most expanded position at rest, and even requiring some force to start compressing them at all. Not only is it unrealistic, but significantly reduces the off-road performance as well. Having the suspension compressed about halfway at stillstand is the correct approach. True, the official LEGO approach with fully extended springs is perhaps useful in the specific case of the chassis violently landing on a surface, but this is not its purpose, despite it being very popular thing to film on YouTube.

That is why I chose to, apart from the hard yellow springs, use the gray medium ones, with the result being the chassis floating halfway up, just as intended. The springs' mounting points are narrower and further back, to allow the longer wheel travel and reduce the resistance of the bodywork to rolling. The chassis itself is raised by using the portal axle parts. Although I don't like those parts too much, I've got to admit that the other tries to make the same using the standard Technic parts turned out too fragile.

As typical for any crawler, CC features a four wheel drive. Three PF XL motors take care of that: one powers the front wheels without a differential, while each of the rear wheels has its own PF XL. They are attached to the axles and move along with them. As for the steering, it's only on the front wheels, attached to a standard rack and pinion rotated by the PF Servo, mounted as well on the axle. Actually, no mechanical work is done in the central chassis section ― it only carries two battery packs and their IR receivers.

Reducing the steering to the front wheels only somewhat hampers the maneuvrability, but I planned to counter that by introducing another, slightly "naughty" trick - controlling each drive motor independently. For exampole, if the front wheels steer right and drive fotware, while the rear right pulls back, the crawler is supposed to steer (with some slippage e.g. on the soil or sand) harder than if it had a four wheel steering.

Since, apart from the steering, there are three drive motors that need to be controlled independently, I was forced to build a sligthly adapted controller, with a lever that allows to let all three drive motors drive forward simultaneously, yet can be retracted for those rare maneuvres when each wheel needs to be controlled manually.

The bodywork serves no other purpose apart from the decorative one; as per old Technic off-road tradition, it is entirely held in place at only a couple of strongpoints and can be detached or mounted literally in five seconds. Since the wheels have plenty of vertical and longitudinal range of movement, the bodywork needed to be rather tall and retracted. Contrary to the GT Crawler and its shapely, rounded surface, this time I wanted to build something more utilitarian (not to say "Russian"). I don't mean to say this couldn't have been done better, and I've got to admit I was never very successful at form design. A lever inside the cabin allows turning on the headlights, but this is hardly a feature.

Well then, after all these technical descriptions, the logical question is ― how does CC4 perform in practice? I've got to admit that, even up to the point when I loaded the chassis for the first time with the batteries and started the first test drive, I did not know what to expect.

In the role of a climber-crawler, this experiment was pretty successful. Chassis at first, and later the entire crawler, had no problem handling the inclines, stairs, pits, downhills and other obstacles, and maneuvered well on the dirt, grass, sand, etc. The low center of gravity, high chassis ride, rather powerful four wheel drive and the long suspension travel helped a lot ― at almost all times were all four wheels on the surface, regardless of the obstacles in the path. The chassis also proved to be pretty strong. The first version was prone to detaching the rear springs while falling off the platforms, but that was easy to reinforce additionally with about ten parts.

What I'm not particularly satisfied with is the staright line drive. Because of a long suspension travel and low forces acting on the springs, the axles allow small side movements that, over longer distances, make the crawler turn slightly instead of making it drive straight. In comparison to the laser-like precision of 9398, CC4 almost looks drunk.

Fortunately, the idea about the independent drive control turned out to work ― for example, turning the forward wheel forward and steering to the right, with the rear left static and rear right turning backward, indeed made the CC4 to turn noticeably sharped than it could using even four wheel steering. Other combinations are possible as well. However, this works reliably only in the suitable conditions, when the grip of all the tyres is about equal, such as the wooden floor, a carpet or sand. But as soon as the surface becomes bumpy or unhomogenous, one or two wheels get more grip than the others and simply overpower them, returning the crawler to the "standard", no-tricks chassis.

The test drives have shown that we still have not got standard off-road wheels that could compete with the custom ones from the non-LEGO sources. The 54120 wheels, used in the official Crawler among other sets, are not a bad compromise of all roles ― they do not have unnecessary friction on the smoothe surface and are more or less useable for the off-roading. However, in the serious off-road conditions, regardless of how clever the chassis has been built, they are still the weak spot, especially when they pick up the layer of dust. It is not surprising that many are trying to compensate for it with the 8x8 configurations. But one needs to understand LEGO as well; it is not feasible to develop the extreme tyres only for a narrow community of Technic AFOL's dealing with extreme off-road vehicles. And even then, the most would not buy more than four.

Altogether, building the CC4 was an interesting experience, as well as driving it on various grounds. The concept itself is interesting, though I think that the option of sharp turning would not be that useful in the Truck Trials. A bit like crab steering ― fascinating from a mechanical point of view and a seemingly an ace in the sleeve, but unnecessarily complex and not that useful in real driving. But even without that, this would turn out to be a quite acceptable off-roader.



Sunday, June 19, 2016

Engraving Robot Mark III

Having received a small "order" for a few engraved pieces of cutlery and LEGO parts, I've built a new version of the engraving robot. This one has been rebuilt to avoid most disadvantages of the previous designs, and is smaller, more reliable, slightly faster, and puts parts under less strain.

As opposed the previous versions 1 and 2 ran by NXT, this one is based on EV3 controlled directly from the PC in realtime, via the MindControl Python library unveiled earlier. The reason behind it was the EV3's support for four motors. Beside the two required for X-Y movements and the third one that raises and lowers the drill, the fourth one actually drives the PF switch which turns the drill motor on only when needed. This approach lets it cool down during long movements into desired position. The drill motor itself is not controlled directly by EV3 ― it is a standard 74569 powered by an old train controller.

Similar to the previous versions, this Mark III employs long linear actuators for X-Y movements and compensates for backlash by over-turning the motors in one direction and then returning to the desired point. Drill is lowered by another linear actuator, connected via the parallelogram linkage connected by friction pins, in order to provide very accurate movement control.

The drill point, a standard diamond-tip sort bought in a local hardware store, is the only part which is not pure LEGO. It is connected to the motor shaft via a small holder which keeps two rubber 2L connectors tightly together. The entire module consisting of a drill point, holder, motor and its supporting structure is actually moving while lowering the drill, and it can also be raised and leaned aside to allow easy access to the platform and the object being engraved. As before, the movement mechanism had to be rather sturdy to minimize backlash as much as possible, and the standard Technic frames did just all right for the purpose.

The overall performance was satisfactory. I'd prefer the entire mechanism to work faster, though; the 4x2 tile with a design of average complexity took about 25 minutes. I think it can be reduced by at least a half, but running the risk of the drill moving too fast and not engraving deep enough. Interestingly, the overall results were slightly better on metal than on a plastic surface, mostly because of plastic's softness, allowing some slack and shake while drilling.

This was an interesting experiment. However, I guess the next direction to improve towards is not speeding the process up further, but rather expanding the drilling surface, which is currently limited to the extents of the linear actuators, i.e. approximately 40x40 mm. Employing the new sliding racks it should be possible to double that at the very least.

Friday, April 8, 2016

MindControl 1.0 for Python


Recent weeks I have been working on a Python module (library) for controlling Mindstorms EV3 and NXT, and ― here it is! I have set up a separate page for it as it may receive updates, documentation changes, etc., so head there to find more about it and download it. Of course, you can freely use it for your own projects.

Its name is MindControl and, briefly, it is a module that conveniently links Python, a programming language, to EV3 and NXT Mindstorms devices, letting you control motors, sensors, etc. directly from the scripts on your computer (or anything else you run Python on). It can control multiple EV3 and NXT devices simultaneously, communicates with them via Bluetooth, is synchronized, and is fully native on both sides, i.e. you can run it using standard LEGO firmware and without any exotic Python extensions.

For example, rotating four motors with various angles on EV3 is as simple as this:

import mindctrl

And add this to keep the motor 1 spinning step-by-step until the touch sensor on port 1 is pressed:

while not device.sensor(1): device.rotate(30)

You can use other functions and parameters (documentation is, remember, at the dedicated page along with the downloads and the rest) for controlling relative motor movements, sensor measurements, playing tones, logging, etc.

The aim was to provide a library which has sufficiently many features to cover 99% of Mindstorms projects, yet to be simple enough for nearly everyone to use and not burden the user with low-level communications and flow control. And Python (v 3.x in this case) is, in my humble opinion, just a perfect language for that.

Happy coding!