Thursday, December 22, 2016

Engraver Mark 4

P1180074

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.

Youtube



Gallery

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

http://www.legoism.info/p/mindcontrol.html

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
device=mindctrl.EV3('COM8')
device.rotate(90,-180,270,-360,speed=65)

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!