Legoism reskinned

As you may have noticed, the dark-themed Legoism is no more. The reason is not that I got bored of it or have ended some depressive period in my life, but that it should be more eye-friendly to the photos with the white background I'll try to make for the new posts. It should look cleaner, and now that Sariel has published a comprehensive photo processing tutorial for exactly the purpose, I've got no more excuses to stick with the 1990's web look (the only thing that was missing was an animated GIF of fireworks).

By the way, this is just the first step of the face-lift; the second one, coming up shortly, will change all of the fonts used in the blog to Comic Sans.

On an unrelated note, some minor additions to Technic Tips have been done.

Iridium: Simple file-based sequential NXT motor control

After a bit of typical Summer-induced inactivity for which I beg pardon, here is something possibly useful for the NXT fans.

First of all, a bit of introduction to the problem wouldn't harm. NXT smart brick is a great device, but its architecture and software imply some limits. For many implementations, those limits are completely irrelevant, but in some special cases they can become a nuisance. One of them is inconvenience and inefficiency of creating long sequences of independent motor moves within the NXT-G programming platform, and difficulty of creating them automatically. There are certain tricks that can help, such as flashing the firmware with custom code, Bluetooth-mailbox instruction systems, but these are usually cumbersome and require a lot of hassle for just a simple task.

Therefore, there is some space for a solution in between. Take, for example, a plotter: if manually aligned, in its simplest implementation it requires no sensors neither any logic structure; all that is required is to move motors in a specific, but rather long controlled sequence. Far too long to create (or even worse, debug) directly within NXT-G, but still too simple for many to go through the battle with firmwares, messaging, etc.

So I've opted to make a simple file-based solution. Create a file with lots of numbers and upload it on the device, then have an NXT program read it and move the motors accordingly. Don't let me be misunderstood: this is not a workaround or even something completely new in the NXT sphere - all these functions are normally supported by NXT (i.e. NXT-G supports reading raw, linebreak separated numbers from a text file). This is just an example of implementing them for the purpose in question.

The file structure is really easy to understand. It consists of successive number pairs, with the first one always indicating the type of instruction, and the second being the "value" of the said instruction. Specifically, instruction types 1, 2 and 3 refer to moving the three motors, for a value that follows them. In other words, a sequence "1, 45, 2, -360" will rotate the first motor 45° in positive direction, and then rotate the second motor one full circle in negative direction.

Obviously, this sequence can continue as long as the NXT brick's internal memory allows which, taking in account the storage requirements per instruction, can extend to 10000 or even more instructions, probably more than its batteries and owner's patience can last anyway.

Besides the motor movement instructions, there are some others that may prove useful: number 11 followed by a number between 1 and 100 will set the motor power of all the upcoming movements to that value (that is, all until the next number 11 instruction). Likewise, number pairs 12, 0 and 12, 1 will choose whether the system will proceed or, respectively, wait for the current instruction to finish before executing the next. Number 13 followed by a number allows to set amount of milliseconds to wait between each instruction.

Finally, when encountering instruction 0, the sequence will terminate. If it was followed by a 1, it will also play a sound to notify the user.

As you can see, despite offering no real logic or dependency on sensors, this is a rather simple way to automate many successive motor movements. Such files can be very easily edited on any computer with a simple text editor, or automatically created by some software or using a dedicated library (I'm working on one for my favourite language - Python). It can even be automated further, using e.g. an external software such as NeXTTool by John Hansen to upload the instruction file to the NXT and run it, allowing the user to control everything from the computer, at least if it is all right to have the NXT connected to the computer all the time.

Here you can download (File > Download original) the .RBT and .RXE file for NXT and a sample instruction file. It must always be Iridium.txt, unless you're ready to slightly modify the RBT file.

If you like it, and find some cool usage for it, I'd be glad if you would drop a link or a description in the comments. Have fun!

(One final note, if you are interested, the name of this project has nothing to do with LEGO. It is just a coincidence I have had a periodic table on my desk at the time I started making it, and one minifig was standing on the Iridium's box.)

Truly horrible Technic supercar failure

EDIT: Forget about this failed experiment. Meanwhile I've built a racing car more worthy reading an article about - click here.

Being fascinated by supercars both in the Technic sphere and in the real world, it was about time I started building another one. Unfortunately, the fascination itself is by no means sufficient to build a good Technic supercar, as is easily demonstrated by this terrible failure - probably the worst MOC I've done for quite some time. Despite it being awful, I've at least decided to document it here as it may help other builders to avoid all classic sevety-six mistakes I've done designing it.

It's powered by NXT electrics: one motor provides the drive to the rear wheels, other handles the steering, and the third flicks a PF switch to turn on the lights, to avoid requiring more than one remote control. It also has full independent suspension based on the parts from the 8070 Supercar, which works nicely. The doors are openable manually, and the steering wheel works as well.

So, you can already notice how scarce it is with functionality: good builders can easily cram infinitely more stuff into a car of this size (69x29 studs footprint). It is a consequence of my anomalous obsession with as strong and ideally weight-distributed chassis as possible, leaving very little possibility to change the components layout later. In other words, I've done a mistake by treating a chassis as a local problem, which it certainly isn't in a supercar that has to use every cubic centimeter of space wisely and well-coordinated with other components. Of course, the chassis thus limited the scope of possibilities regarding the bodywork. That's why there are large pointless empty areas within the bodywork (especially right behind the nose and under the rear wing). The chassis could have been reworked, but I've decided rather to keep it and keep the intelligent approach for the next car.

I'm not satisfied with the looks either. While the rear could be acceptable, the engine cover is rudimentary, the doors are too small and long, the windshield and the seat are out of proportion, and the whole nose of the car is a bit too small (looks like an old VW Beetle somewhat), and ugly. Again, I have not had a sufficiently clear vision of what should the car look like when finished, and it shows.

 

A point of interest is perhaps the steering which bases the inner points of the asymmetric ball-jointed control rods on a rotating beam for a very pronounced Ackermann geometry. The beam is rotated by a worm gear producing some backlash, but on the other hand, providing also sufficient torque to turn those grippy tyres accurately. Also I don't find the seat design bad (though it is too large), and it could be perhaps used as a base for some future large-scale projects.

But other than that, this is just an oversized, ugly, fragile and slow wheelie bin with functionalities on a level of a 8090 set car. But it prooves the point which, ironically, I've already written in the Technic building tips and have now violated: for a tight and difficult machine such as a supercar, you really need a clear vision of what exactly are you going to build, before you even pick the first brick up.

I sincerely hope the next one will be better, to appease the Gods of Lego, though I may need to rehabilitate on Classic Space for a while.

Classic Space: Surveying & Geology Research Squad

Having a brief break from Technic (and waiting for a couple of parts), I got into a cosmic mood and came up with this little space surveying & geology team.

I'm a huge fan of Sci-Fi and Lego Space theme, particularly the Classic one. Though I have no choice but to agree that the newer Space sets look brilliant and have more functions than a Swiss Army knife, I actually prefer the old-school "raw finish" spaceship and vehicle design, relying on lots of standard parts borrowed from the Town theme. It has undeniable sui generis aesthetics; I find a 6929 Starfleet Voyager set, which I am lucky to own, perhaps the best-looking example of this streamlined simplistic approach relying on contours and subtle proportions rather than boom-bang-whiz details.

That's the line I've tried to follow building this little geology squad, though I don't even want to insinuate that its look could rival the TLG Classic Space sets. It consists of a single-seater surveying craft, a small offroad vehicle, a communication station, a few field tools and a quartet of fellows (un)lucky enough to do this complicated job.

Although I'll be the first to agree that there is no need for spaceships to be aerodynamical, resemble an aeroplane in any way or have wings as they are designed to travel through vacuum, I find the general streamlined and wingy look simply nice, and consistent with the other unexplicably aerodynamic original TLG Classic spaceships. However, in this case one may argue that some of the planets being researched may have a rare atmosphere, and with speeds those machines can fly at aerodynamics may play a role, while the wings are actually streamlined radiators (let us not forget how difficult task cooling is in vacuum, without any contacting matter to transfer the heat to!). The general concept here is to have a small, fast and nimble craft equipped with lots of sensors to measure and survey large areas, and a buggy-like vehicle to get the equipment to a discovered place of interest, or access the areas unsuitable for the spaceship to land. If the results are urgent or there are no bases nearby, an extra communication station can be taken along, with its long-range parabolic antenna. There is an extra lamp available too, if the excavation site happens to be on a celestial body's dark side, should the craft and vehicle headlights be insufficient.

At this scale it is difficult to combine plenty of functionality with attractive design. I gave up a bit of functionality (trying to implement variable geometry wings into a craft of this size was just too much) to have more design and construction freedom. I particularly like using the old-style square transparent cockpit cover rather than the newer, curvy ones, because they need not to close completely (i.e. it  not retract to full horizontal position), allowing a more level and aerodynamic canopy, smooth design and keeping the "roof" actually tilted backwards, as you can see on the side photograph. Large engines (both main and auxiliaries under the wings), plenty of angled edges and long, pointy canards are simply a consequence of my taste. Most Classic Space sets rely on grey-black-blue hull colours, while reserving the brighter and warmer ones for details, especially in transparent versions. I've tried to keep up with that tradition.

This short stray off (back?) into Classic Space was so much fun, even for something this small, I'm almost sure there is more to come in the future.

Housekeeping: A new Links section

A website without external links is just like a sportscar with an automatic gearbox: it can work, but one just feels something is missing. So as of today, on Legoism you can find the new section with links to the Lego sites I like and recommend. Don't get too excited, though; the fact that you are here, reading this, means you probably know the most of them well.

Lego Technic 8070 Super Car Review: A serious road beast

Supercars have always had a distinguished position in the Technic world, often pushing the boundaries of what was achievable, introducing new parts and techniques, and being among the largest available models. It all began in 1977 with the set 853 which was built without friction pins and dedicated steering parts, continued through a couple of studded models culminating in 8880 and continuing in the studless era with ever more advanced models. The newest, recently launched member of the family is the 8070 Supercar, reviewed here.

Expectations from this type of a set are undoubtedly high, as the supercars are one of the toughest models to design. They need to cramp as many functions as possible within a limited volume, be sturdy, and yet be modelled to look nice, though not as much to hide the underlying mechanics. And above all that, they need to introduce new ideas and concepts, rather than just recycle some previously seen chassis.

This machine did not fail to do so. Already first half an hour into building, it is obvious that 8070 means business. The gearbox in the middle of the chassis and its surrounding area must be one of the most tightly packed systems one can hope to see. The gearbox isn't actually here to provide various ratios for the drive, but to choose between four motorized functions around the car: operating the left and right gullwing doors independently, opening the bonnet, and extending the rear wing. The PF motor serves only these purposes, not the drive or steering which are still manual.

There is a V8 engine under the bonnet powered by the rear wheels, and the car is steered by the knob behind the cabin (a well-known Hand-of-God method). All wheels have fully independent double wishbone suspension. The rear wheels' parts actually theoretically allows them to steer too, but they are fixed in place ― however it may be useful for your MOC's. The rear hood opens manually, and is cleverly designed to allow the wing underneath it to slide freely.

Looks are a matter of personal taste, but I find them fantastic. It is so nicely modelled and features many subtle angles and triangular structures in the bodywork, that I could easily believe it is an accurate model of a real-life sportscar. As usual, the chassis is built very strongly, while the bodywork panels usually connect to an axle or a friction pin, for the possible collisions not to incur too much damage.

With all these functions, there is hardly any remaining free space in the car. As a result, it is not the easiest to build either, with lots of delicate parts and components, mechanisms that need fine adjustments and many moving parts. By no means should it worry an experienced Technic builder (it took me about 4:30 from the unboxing to the finish), but you ― moms who are idolizing your 6-year-olds, please don't just rush buying the 8070 to your children as it doesn't ask just for dexterity, but plenty of patience too. Even more, dare I say.

But it is a great experience and a mechanical lesson, though at first you may be a bit confused about the seemingly unlogical steps you have to make, but after a while, it just comes all together into a great machine. The unusual steps in the beginning are just a normal consequence of the inside-out studless construction.

Therefore, a great set, whether you just like cars, want to play with an interesting one, need useful parts, or want to learn from it.

▪ BUILDING, IDEAS AND CONCEPTS

Fantastic construction ― nice, efficient and strong, though not the easiest to build. So tightly packed with functions, it is almost impossible to put a sugarcube anywhere in the model. Interesting concepts too with the motorized panels around the car controlled by the centralized gearbox. Although there is not anything we haven't seen yet, the feat of putting all that within the given volume (quite small in sportscars) is in itself a very good learning material.

It is not overly difficult for disassembly either, avoiding difficult parts (half-width 2L Technic beams) as much as possible.

▪ PARTS SUPPLY

You will find some very useful parts for any car, such as the suspension wishbones, hubs, engine, racing tyres, etc., and the set contains also a PF battery pack and a medium-size motor. The rest is a standard Technic building material with plenty of beams, pins, axles and a couple of panels. And with a bit over 1200 parts, it is a good amount, too.

▪ EXPANSIONS

Since the machinery is so deeply integrated, there's not much freedom to modify the car without having to rebuild some components entirely. A most basic addition would be to introduce PF lights in the headlights (this is so obvious that I'm somewhat confused TLG did not do it already). But there's little else to add.

▪ GENERAL PROS & CONS

+ Clever construction, great to learn strong and efficient Technic design
+ Lots of functions
+ Considerable supply of parts
+ Really nice to play with
+ Superb looks, very realistic

- Not trivial to build, needs some patience
- Steering wheel in the cabin does not work

▪▪ VERDICT ▪▪

With its complexity, advanced ideas and intelligent construction, the new addition to the Technic Supercars line up is certainly up to standard. It is not among the cheaper models, but one really does get a lot in return. Highly recommended, especially if you're into building MOC cars ― in that case you will find some very useful specialized parts here.

Small NXT CNC machine: A bit too ambitious, really

Since the NXT 2.0 set contains three motors, it should be possible to build a Lego CNC machine with a little help from some external parts. Its construction would be quite straightforward and use most concepts we are already well familiar with. Based on those assumptions, I've tried to build one ― or more precisely, its early prototype.

I'm sure it could be built very nicely on a large scale, but the intention was to make it smaller ― that is, small and brick-economical enough to fit entirely on a 48x48 baseplate, yet provide at least 10x10 studs (8x8 cm) of grinding area.

So here it is! Its components are quite self-explanatory. On one end of the platform we've got two motors; each moves a pair of beams along a rail via rack&pinion system, that move the cradle. The X-rail is stationary, while the Y-rail is mounted on the X-beams. Thus, the cradle easily moves in both axes. It is nothing more than a simple little "pool" where I have fitted a thick piece of bakelite, and which slides freely over the surface thanks to the tiles on its bottom.

A bridge is built above the cradle area, heavily reinforced with four rows of interconnected studded beams. It carries a large moveable cradle built specifically for this standard-issue electric drill. The cradle is attached to four strong arms, and there is significant counterweight on the other side, with four large old Technic wheels attached to long arms. The counterweight compensates for the drill weight (approx. 2.2 kg), so the bridge needs to withstand only vertical force, and not the sideways too, which would complicate construction.

The drill is raised and lowered by just a few millimeters at full extents, but it is more than enough for a sheet of bakelite. Its height is actually controlled by raising and lowering the counterweight arms with one linear actuator, connected to an NXT motor. Since the drill and the counterweight are in a fine balance, the actuator doesn't need to produce much force, but I've opted to use it for its precision. (To increase precision of X-Y movements, the motors are also directly connected to the driving pinions ― no gears that would introduce backlash.)

A simple clutch holds the electric drill at a desired power, and a very fine yet hard grinding drill bit with a 0.8 mm head diameter is mounted in it. The NXT module that controls all three motors is resting on the side, connected to a laptop that sends the machining data.

Obviously, this is a quite limited CNC contraption, as the drill can access the surface only from above, so it acts more like a carving machine. The input is really straightforward: a simple script analyses a greyscale bitmap (which is a depth map), calculates the area that needs to be grinded out for each layer, and then "carves" them out, layer by layer. The X-Y resolution is 80x80 pixels, so the pixel amounts to 1 mm ― less would anyway make little sense with the grinding bit of this size, and while the depth could theoretically reach 256 layers, that would be insane ― 10 is more than enough. Or to be very precise, we're not dealing with pixels here, but voxels. Anyway, such configuration amounted to approximately 5500 instructions (motor movements) for an averagely complicated desired result: a tiny physical model of Iceland with scaled altitudes I chose as a first test.

So I've built the prototype (yes, please excuse the horrible colours, but facing running out of beams I've had little choice), programmed the script and happily pushed 'Start'. And quickly learned that the above idealism works only in theory, while in practice, this CNC design has serious flaws, serious enough to classify it as a failure.

Namely, I have terribly, horribly, enormously underestimated the forces that act on the cradle during grinding. Not only does the whole X-Y beam structure bend significantly under lateral forces during the drilling, but the drill itself has the tendency to "dance" around as well, and miss its targets by 2-3 millimeters at least. Of course, the bakelite looks massacred rather than accurately carved.

Theoretically, this problem could be overcome by forcing the drill to always act vertically, and drilling each target pixel separately. Again, this is just a theory: not only would drilling a millimeter from the already drilled area push the drill there to the path of least resistance, but the operation would have to be done for each pixel that needs to be grinded. And that would also last forever, and breach one of the primary rules of engineering ― that the machine should not be as inefficient to actually get the job done slower than an averagely inexperienced person would manually. Finally, even if I was like the Master from the Exile of the Eons (Arthur C. Clarke, 1950) and waited several dozen billion years in suspended animation until it is done, this approach would make very rough, spiky surface on the material.

I guess these problems could be solved by using much more stable X-Y beams, both probably having large pinions on both ends and tighter rails, and attaching a different drill. Perhaps a faster, specialized one would do the job better, but I've intentionally tried to use one of type almost everybody has somewhere at home. These improvements will be the objectives for the second prototype, significantly larger and architecturally different.

P.S. I've tried carving other materials since, such as the brittle spongy plasticky material I've found and can be seen on the photos (a white block), but that didn't seem to solve the mentioned problems.