Model of a generic reach stacker. Features drive, steering, elevated and extended boom, elevated cabin, rotated head and motorized jaws.  

Datasheet:

Completion date: 01/04/2012
Power: electric (Power Functions)
Dimensions: length 38 studs (not including the arm) / width 22 studs (not including the arm) / height 22 studs
Weight: 1.565 kg
Suspension: none
Propulsion: 1 x PF XL motor geared 1.4:1
Motors: 2 x PF XL motor, 3 x PF Medium, 2 x micromotor

Reach stackers are highly specialized industrial machines that can be considered a distant variant of a telehandler. They are being used primarily in cargo terminals in ports around the world, where their task is to transport and arrange containers. I have been planning to build such a machine for a very long time, and I finally succeeded.

The model showed a generic, typical reach stacker rather than some particular model. The interesting thing about reach stackers is that they are absent from the offer of most of the European machinery manufacturers, except for the Liebherr company which produces reach stackers with arched booms, which would be extremely difficult to model with LEGO pieces.

The model was intended to be as simple, small and functional as possible. I have used no suspension system in it; I was unable to determine whether real reach stackers have any suspension systems, but it seems unlikely for machines that are designed to carry heavy loads around perfectly flat asphalt areas. For example, most front loaders have no suspension on their front axles to make them more stable with loads, and they are supposed to work in rough terrain.

Most of the model was built entirely studless, with exception for the sides of the hull, consisting of studfull bricks connected to the bearing frame. Thus, they were used to strengthen the chassis in its crucial section between the mounting points of the boom and of the linear actuators.

The model’s front axle was driven by PF XL motor through a single differential, and its four wheels were mounted on two small Technic turntables which acted as bearings, taking load off the axle. It seemed to work, as the model proved to be very agile, with and without the load. The rear axle was steered by a PF Medium motor with a very simple steering mechanism lacking a clutch or a return-to-center function. It had an extreme steering lock, merely thanks to removal of any parts of the body that could collide with wheels.

The boom, made of studless panels and self-container, was elevated by two large linear actuators driven by a single PF XL motor. A PF Medium motor installed at the back of the boom was used to extend it, through a system of a worm gear meshed with racks on the boom’s extendable section. The head at the tip of the boom included two micromotors, one for rotating it and another one for closing and opening its jaws. Since the head was intended to balance itself under own weight, just like in real machines, a weighted brick was attached to its side opposite the latter micromotor to counter-balance it. The head’s rotation range was full 360 degrees, and its jaws had a gripping range from 9 to 31 studs. Finally, a PF Medium motor and a small linear actuator were used to elevate the cabin and move it forward, but due to lack of space in the hull, the range of movement was minimal and the function was quite unimpressive.

One function that I toyed with and eventually abandoned was tilting the head forward and backward. Real reach stackers have such function, although it appears to be very rarely used. I did not expect to really need it, and it added plenty of technical difficulties, requiring another motor near the boom’s tip, or a pneumatic system routed to its tip, or perhaps an extending driveshaft inside the boom.

There were few interesting technical solutions that I’ve tried – other than using turntables as bearings, they included the construction of the boom which can be made much longer, and the jaws extension mechanism which was very simple, compact and yet reliable. In general, the model had a sturdy chassis and boom, but rather delicate head and jaws. Despite that, the jaws worked flawlessly with any kind of load, and the maximum load capacity of the model proved to be almost 0.5 kg, limited only by the torque of the PF XL motor elevating the boom and by the clutches in the linear actuators.

I have also used this opportunity to test my IR Link sensor which allows the NXT brick to control Power Functions devices. I have built a simple NXT controller with one joystick, using three motors and two touch sensors and working in two modes: drive mode and boom control mode. The controller worked rather well using my program written in ROBOTC which is included below, but the IR Link sensor was a disappointment: its range was shorter than that of PF remotes, and it caused delays in the reaction of PF motors. Still, controlling the model in such way, definitely more realistic than with regular Power Functions remotes, was an interesting experience.

Control program:

#pragma config(Sensor, S1, HTIRL, sensorI2CCustom)
#pragma config(Sensor,S3,touch1,sensorTouch)
#pragma config(Sensor,S4,touch2,sensorTouch)
#include "drivers/HTIRL-driver.h"
bool sending = false;
bool drivemode = true;
tPFmotor DriveMotor = pfmotor_S1_C1_A;
tPFmotor SteeringMotor = pfmotor_S1_C1_B;
tPFmotor BoomElevationMotor = pfmotor_S1_C2_A;
tPFmotor BoomExtensionMotor = pfmotor_S1_C2_B;
tPFmotor CabinMotor = pfmotor_S1_C3_A;
tPFmotor HeadCatchMotor = pfmotor_S1_C4_A;
tPFmotor HeadRotationMotor = pfmotor_S1_C4_B;

task Buttons()
{
  nNxtButtonTask  = -2;
  nNxtExitClicks = 2;
  nxtDisplayCenteredTextLine(0, "Not sending...");
  while(true)
  {
    if(nNxtButtonPressed == 3)
    {
      PlaySound(soundBeepBeep);
      if(sending == false){
        sending = true;
        nxtDisplayCenteredTextLine(0, "Sending...");
      }
      else{
        sending = false;
        nxtDisplayCenteredTextLine(0, "Not sending...");
      }
    }

    if(nNxtButtonPressed == 1)
    {
        drivemode = false;
        nxtDisplayCenteredTextLine(2, " DRIVE [BOOM]");
    }

    if(nNxtButtonPressed == 2)
    {
        drivemode = true;
        nxtDisplayCenteredTextLine(2, "[DRIVE] BOOM ");
    }

    if(nNxtButtonPressed == 0)
    {
      sending = false;
      PlaySound(soundBeepBeep);
      wait1Msec(400);
      PFMotor(DriveMotor, 0);
      PFMotor(SteeringMotor, 0);
      PFMotor(BoomElevationMotor, 0);
      PFMotor(BoomExtensionMotor, 0);
      PFMotor(HeadCatchMotor, 0);
      PFMotor(HeadRotationMotor, 0);
      PFMotor(CabinMotor, 0);
      StopAllTasks();
    }

    wait1Msec(400);
  }
}

task main()
{
  StartTask(Buttons);
  nxtDisplayCenteredTextLine(2, "[DRIVE] BOOM ");
  int LeftMotor = 0;
  int RightMotor = 0;
  int UpperMotor = 0;
  int RightButtons = 0;

  while (true) {
    if(drivemode == true)
    {
      LeftMotor = (nMotorEncoder[motorA] / 7) * -1;
      if (LeftMotor > 7) LeftMotor = 7;
      else if (LeftMotor < -7) LeftMotor = -7;

      RightMotor = (nMotorEncoder[motorC] / 10) * -1;
      if (RightMotor > 2) RightMotor = 2;
      else if (RightMotor < -2) RightMotor = -2;

      if (SensorValue(touch1) == 1) RightButtons = 7;
      else if (SensorValue(touch2) == 1) RightButtons = -7;
      else RightButtons = 0;

      nxtDisplayTextLine(4, "Left motor: %d", LeftMotor);
      nxtDisplayTextLine(5, "Right motor: %d", RightMotor);
      nxtDisplayTextLine(6, "Buttons: %d", RightButtons);
      nxtDisplayClearTextLine(7);

      if (sending == true)
      {
        PFMotor(DriveMotor, LeftMotor);
        PFMotor(SteeringMotor, RightMotor);
        PFMotor(CabinMotor, RightButtons);
      }
    }
    else
    {
      LeftMotor = nMotorEncoder[motorA] / 20;
      if (LeftMotor > 0) LeftMotor = 7;
      else if (LeftMotor < 0) LeftMotor = -7;

      UpperMotor = nMotorEncoder[motorB] / 20;
      if (UpperMotor > 0) UpperMotor = 7;
      else if (UpperMotor < 0) UpperMotor = -7;

      RightMotor = (nMotorEncoder[motorC] / 20) * -1;
      if (RightMotor > 0) RightMotor = 7;
      else if (RightMotor < 0) RightMotor = -7;

      if (SensorValue(touch1) == 1) RightButtons = 7;
      else if (SensorValue(touch2) == 1) RightButtons = -7;
      else RightButtons = 0;

      nxtDisplayTextLine(4, "Left motor: %d", LeftMotor);
      nxtDisplayTextLine(5, "Right motor: %d", RightMotor);
      nxtDisplayTextLine(6, "Upper motor: %d", UpperMotor);
      nxtDisplayTextLine(7, "Buttons: %d", RightButtons);

      if (sending == true)
      {
        PFMotor(BoomExtensionMotor, LeftMotor);
        PFMotor(BoomElevationMotor, UpperMotor);
        PFMotor(HeadRotationMotor, RightMotor);
        PFMotor(HeadCatchMotor, RightButtons);
      }
    }
    wait1Msec(200);
  }
}
									

Work in progress photos:

Photos:

Video:

Click here to view the embedded video.

Media reference:

8studs (Polish only)

Share/Bookmark

Highly experimental, very simple creation illuminated with EL wire.  

Datasheet:

Completion date: 26/10/2011
Power: 12V (external transformer)

I have a soft spot for LEGO creations with working lights in them, which is why I started to experiment with an EL wire – basically, a wire that works like a single huge LED while being elastic available in various colours and lengths (that can be cut if needed). Even being a LEGO purist, I realize there is absolutely no way to achieve even a remotely similar effect with LEGO parts – hence the experiment.

I wanted to try integrating the wire into something, just to test how elastic is it, how far can it be shaped and how well does it “sit” with LEGO pieces. Being a fan of Razer gaming products, I caught a sudden inspiration to build a 1:1 model of a fictional Razer-inspired headset. Hence the name, because Razer names its products after animals, the headsets are named after aquatic ones, primarily sharks, so Oxyrinchus is a Latin name of one of the sharks species.

The creation was extremely simple, to the point of being crude, but it allowed me to test both the wire and my camera while taking photos of a MOC illuminated this way against a black backdrop. It was therefore an opportunity to get some valuable experience, but it had absolutely no functions beyond that – hence the “expert headset for hearing inner voices” caption

Photos:

Share/Bookmark

Model of a pushback tug. Features a powerful propulsion system, elevated cabin and lights.  

Datasheet:

Completion date: 07/08/2011
Power: electric (Power Functions)
Dimensions: length 40 studs / width 16 studs / height 35 studs
Weight: 2.07 kg
Suspension: none
Propulsion: 2 x PF XL geared 24:1
Motors: 2 x PF XL, 1 x PF Medium

Pushback tugs, also called pushback tractors, are low-profile vehicles used to push and tow aircraft around the airport. They are in common use, as using a pushback tug is cheaper than having an aircraft move under its own power, and safer than having an aircraft move using jet engines. Pushback tugs come in two variants: the older one, with tractor connected to the nose gear by a tow bar, and the newer one which scoop up the nose wheel and lift it off the ground, effectively attaching themselves to it. I have chosen to model the newer variant, which is much more complex and more interesting. It was not modelled after any particular make of a pushback tug, just after the typical look of a vehicle of the newer variant, as I wanted to focus on performance rather than on accurate look.

My goal was to make a model capable of towing 20 kg of load on a wheeled trailer. The trailer was essential to reduce the friction – according to my tests, the model was able to tow roughly 6 kg without a trailer, with the load being simply moved on the floor. As I was unable to determine whether the real tugs have suspension systems of any kind, I decided not to use any suspension in the model. There are two reasons for it: first, the suspension of any kind would make the drivetrain more likely to fail under tension, and second, a suspension system seems needless in a vehicle designed to drive solely on the perfectly flat areas of the airports.

The front axle of the model was steered and the rear axle was driven. The model steered poorly, as its center of gravity was close to the rear axle and as the rear axle had no differential. The propulsion system consisted of two PF XL motors geared down 24:1 each, generating a total torque of 696 N.cm, that is 48 times the torque of a single non-geared PF XL motor. The rear axle was reinforced to handle this kind of torque: it consisted of a number of short axles rather than a single long one to limit twisting, and the gear wheels on it were doubled and connected together with four pins each in order to lower the risk of physical damage.

Tests ran on the model have shown that its construction can handle the required tension (it was built around a massive frame, and the area around the rear axle was heavily reinforced) and that it has plenty of torque (I was thinking of adding another two PF XL motors if needed). Thus the limit of its towing capacity depended only on the traction of the rear axle’s four wheels. I’ve equipped the model with massive body and installed six weighted bricks around the rear axle to make the model heavier and thus improve the traction. The weighted bricks added extra 0.33 kg while taking relatively little space.

The body of the model was simple and had little functions (I decided to make the nose gear attachment mechanism non-functional, and one of several reasons was that it was very difficult to observe how it works in real vehicle). The cabin was elevated, just like in many real tugs, using a motorized scissor lift mechanism and a single small linear actuator.

The model was very simple, but turned out able to achieve its goal: it towed the trailer with 20 kg of load on it. At this point the model was already having problems with traction, depending on the area of the floor, and the trailer was so heavily burdened that its wheels kept slipping off axles every couple of minutes. I was afraid to physically damage the trailer, even though it was built around two layers of massive 16x8x1 bricks, and hence I did not test heavier loads. It would be interesting to see how much such a vehicle could handle if it was carrying the load directly on it, as this would ensure sufficient traction, but such a solution involves plenty of problems resulting from a huge load being placed on the model’s structure. I suppose it is possible to make a Lego vehicle that can carry 20 kg of load on it, but it should be probably significantly different, e.g. with tracks or with wheels with no tires on them.

Photos:

Video:

Click here to view the embedded video.

Share/Bookmark

A model of a sentry turret from the Portal game. Features two motors and two sensors and is computerized with the Lego WeDo software.  

Datasheet:

Completion date: 11/05/2011
Power: electric (Power Functions)
Dimensions: length 26 studs / width 18 studs / height 36 studs
Weight: 0.788 kg (together with the launcher)
Suspension: none
Motors: 1 x PF Medium, 1 x micromotor

I was halfway through the Portal 2 game when this idea came to me. As you probably know, there are many Lego models of the famous Portal sentry turret and other “characters” from the game, especially after the release of Portal 2, but they are usually just that – models, with zero functionality.

I had a very ambitious plans for this construction, and I’ve spent a lot of time trying to realize them in vain. Among other things, I was trying to make the turret stand on its own legs and I wanted it to have Lego cannons inside it, with ability to extend and fire. The legs turned out too weak and the body of the turret turned out too small to house all the necessary mechanics – it was just 7 studs wide.

The size of the turret was determined by my decision to equip it with a studful, possibly accurate body. It was quite a challenge, as the original turret is egg-shaped. I was able to achieve the look I wanted using a variety of uncommon parts, and because of the parts it couldn’t be any bigger. This is because almost every Lego piece used for its body has no larger counterpart. If the turret was to be made bigger, I would have to use several pieces instead of each single one used here, and it would pretty much ruin the look of the model. The elements that would be extremely hard to re-create at larger scale include the eye, the hole for the eye, entire legs – even the curved slopes the major part of the body is built with don’t come in larger size. Which pretty much means that a larger model would have to use an entirely different body.

The body, which was quite a challenge to build, consists of five separate panels attached to a central studless skeleton. There are two identical extended side panels,  rear panel, front panel with the eye and the proximity sensor and the top panel with the tilt sensor. It took a lot of planning to arrange them into one construction and to make it look as a whole.

As for my work on the model, I have reached the point where I was able to have four Lego cannons inside it, together with a mechanism and a motor that could extend and retract them. However, I was unable to make them fire – I’ve tried a number of solutions, including most compact ones such as a string pulled by a motor. None worked.

I have toyed with the idea of making only one side of the turret open, but the prototype firing mechanism I developed turned out so large, that even this was a problem. Eventually, I decided to remove the cannons from the turret and put them together as an auxiliary launcher, together with the custom laser pointer that didn’t fit inside the turret either. This way I was able to make both sides of the turret extend and retract, and the turret could control the launcher. Building the launcher has shown yet another problem – the recoil from the four Lego cannons fired at once. It was quite significant and I had to add large stabilizers for the launcher to make it stop tipping over while firing.

The number of wires coming out of the turret (total: 7) and its inability to stand on its legs made me create a stand for it. The stand supported the turret entirely, and housed the Lego WeDo USB hubs, as well as helped to arrange the wires. I was trying to make the stand look like a fragment of the Portal test chamber’s floor.

The turret was connected to a computer running the Lego WeDo software, which controlled the turret. There were two Lego WeDo sensors inside the turret: a proximity sensor located in front, below the eye (I was actually trying to install it behind the eye and make it look through it, but I was unable to stop it from detecting the pieces in front of it), and a tilt sensor located inside the turret’s top panel for increased accuracy. The side panels were extended or retracted by a micromotor rotating an axle with a simple system of levers attached to it. The launcher was controlled by PF Medium motor rotating another axle with a simple connector on it. When rotated, the connector would push the vertical beams at the back of the launcher and pull all its four cannons’ triggers back. It was a very simple mechanism, but it required large torque to work, which was one of the reasons why I was unable to fit it inside the turret with some smaller motor.

The WeDo program controlling the turret is the most complex one I have created up to date. It uses the voice files of the original turret from the Portal game – I had to extract them, find the sound files of the Lego WeDo software and swap them to make it work, as the WeDo software doesn’t allow to use custom sound files. The turret is capable of recognizing direction it’s tilted in and can check if the target that appeared in front of it is still there – which is quite an achievement given the fact that the WeDo programming language doesn’t support conditional instructions.

The turret is my first MOC to use white as the primary colour. The portal 2 game theoretically introduced turrets in various colours, but the turrets we meet in the game are almost exclusively white, and the white version has become iconic since the first Portal game. Every white Lego piece the model uses was bought specifically for it, as I had no white Lego pieces in good condition (that is not yellowed). As I expected, a white model with black addition was a difficulty when it came to taking photos. I have even used a light tent with backdrops in a number of colours, but I wasn’t quite satisfied with the result. I guess I should have used a large piece of paper in some neutral colour, but I did not have one.

Despite the fact that the turret did realize a whole list of ideas, I was happy with it. I liked the look of it, and I had great fun working on the video. Using the sound files from the game turned out to work very well too, and I think that even if it’s not very successful compared to my other MOCs, it’s still very good in terms of Portal-inspired Lego models.

Photos:

Video:

Click here to view the embedded video.

Media reference:

GadgetSin

Share/Bookmark

Simple vehicle built for fun. Features 4 driven rubber tracks, chassis elevation system and remote-controlled Zamor cannon.  

Datasheet:

Completion date: 24/02/2011
Power: electric (Power Functions)
Dimensions: length 36 studs / width 23 studs / height 50 studs
Weight: 1.14 kg
Suspension: none
Propulsion: 2 x PF Medium motor geared 1:1
Top speed: 1.60 kmph
Motors: 4 x PF Medium, 2 x PF XL

The idea for this vehicle has evolved quite a bit. Initially meant to be a successor of my Moon Rover, since I am deeply fascinated by all the robotic contraptions NASA sends into space, it has gradually became something built rather for fun than for pretending my room’s floor is another planet. It was also important to me to build it without having to take apart my previous construction, which meant that I could use 3 IR receivers and 6 motors at best.

The Prowler has become an opportunity to experiment with a HD video. Having finally a full-HD-capable camera at hand, I was eager to try producing some high quality panoramic video. I have chosen to use Ulead Video Studio to do so, a decision which I severely regretted later, and I started by trying to produce a full HD video, which turned out to require a machine much more powerful than my PC. Having decided on regular HD instead, I proceeded to work on the video, which became increasingly frustrating, as the Ulead software turned out to work really slow.

It seems that the frustration over the video, which I felt compelled to finish against all odds, has affected the work on the model itself. For instance, the two Medium motors geared 1:1 proved incapable of driving over any serious obstacle, and I didn’t want to modify the drivetrain, because it would mean reworking the whole chassis. The live feed camera, which worked flawlessly the day before I started filming, proved unwilling to co-operate with my PC when I needed it to. I’ve tried for a couple of times, but I was unable to get a signal from it, which is why there is no single image from this camera in this video – I just didn’t manage to film it when it worked. Finally, the Zamor launchers proved quite difficult to control remotely. I wanted to have two of them, launched one after another continuously by a single motor with an eccentric mechanism. For some reason – perhaps because my Zamor launchers were brand new – it turned out to require an enormous amount of torque, rendering the eccentric mechanism completely useless, as it would yield to the launcher’s resistance regardless of how much reinforced it was. I have tried a couple of solutions, and eventually settled down on a single launcher with a primitive control system consisting of a single motorized linear actuator. It meant that the launcher control system could not work continuously, but required switching back and forth. In the end, the Zamor launcher proved largely inaccurate anyway. Since the spheres would not always sit in the launcher in exactly the same position, there was a significant spread when firing them. It was acceptable for just having fun and shooting large targets, but it still took me over an hour to get the short at the beginning of the video right.

I would say that it’s a clearly unimportant construction, perhaps something I needed to relax after a long and tedious work on the previous one.  Still, I have learned something from building it, which means that it was worth building anyway.

Photos:

Video:

Click here to view the embedded video.

Share/Bookmark

A very special construction set in the world of Monty Python and the Holy Grail. Only read if ye be men of valour!

I’m a huge fan of Monty Python in general, yet it did not affect my Lego constructions up to date (largely because the blueprint for the Trojan Rabbit is hard to come by). However, one evening I came back from work having an increasing fever, I administered myself a handful of medicines and went straight to bed. I was on the brink of falling asleep when the Idea came.

The Idea required an unorthodox building components: a couple of skeletons plus some skeleton heads, my slippers (which served as the rocky walls of the Cave of Caerbannog), two Bundeswehra-issued bandanas (mimicking the surrounding ground) and – last but not least – a single Lucius. The co-operation of Lucius was secured by an insanely large amounts of plucked sunflower seeds, which he has carefully collected and stuffed into his pouches to such point that his eyeballs were almost entirely out.

While the complexity of this construction may appear not-so-impressive, and its functionality limited, I urge you to appreciate the model’s acting skills (and the efforts of the photographer who had to work with an animal in constant motion, and barely made it out alive).

On a more serious note, rest assured that all blood and red eyes effects were added digitally to the original photos, and that Lucius enjoyed this little adventure thoroughly.

Photos:

And the original movie scene, for those of you unfortunate enough to have never seen it before:

Click here to view the embedded video.

Share/Bookmark

Datasheet:

Completion date: 17/12/2010
Power: electric (Power Functions)
Dimensions: length 40 studs / width 12 studs / height 16 studs
Weight: 0.787 kg
Suspension: pendular bogies
Propulsion: 2 x PF Medium motor geared 2:1
Top speed: 0.8 kmph
Motors: 2 x PF Medium, 1 x 71427

This is a very simple articulated tracked vehicle, loosely modelled after the Swedish Hagglunds BV 206. My inspiration came obviously from Peer “mahjqa” Kreuger and his Stilzkin Igniz offroad vehicle. Since Peer’s model was really hard to top technically or aesthetically, I decided to go for simplicity and small size, a size fit for Lego full-rubber tracks I never had a chance to use before.

The vehicle is composed of two parts kept together by a complex articulated joint. The joint has the ability to change the horizontal angle between the two parts, which is controlled by a 71427 motor geared down substantially. It also has ability to rotate around transverse and longitudinal axis, freely, with the only constraint being the space between two parts of the vehicle. Initially, I wanted to control its rotating around transverse axis with another motor, thus gaining the ability to elevate or lower both ends of the vehicle, but it proved to perform very well without it.

Both parts have identical chassis, with two separate drive motors – PF Medium motors geared down 2:1. I was going to use a single drive motor located in one part of the vehicle and transfer the drive to another by universal joints, but that would require making the central joint much more complex or restrict its movement, so I used two separate motors instead. This solution, coupled with small weight of the model and the excellent traction of the full-rubber tracks, results in outstanding climbing abilities, shown on the video below.

The bodies of the both parts of the vehicle, despite being similar in size, have entirely different internals. The first part houses a 71427 motor with its gearing, and a lot of wires due to three parts of Lego LEDs used. The second part is literally built around the rechargeable battery and a single IR receiver, with the addition of a single pair of Lego LEDs. There are three wires connecting both parts.

The model was very fun to play with, and performed quite well in the snow, even though the steering system was struggling hard to work  with tracks buried in snow. Also, despite its good ground clearance, the model would pile up some snow in front of it while driving, until the point at which the pile was large enough to stop it. Still, its performance against obstacles was extraordinary, and its climbing abilities astonishing given its size. Two disadvantages degrading its performance was the tall silhouette, resulting in the centre of gravity located so high that the vehicle had a strong tendency to tip over, and the small weight which made it difficult to control, as it would change its direction on obstacles sometimes.

Photos:

Video:

Click here to view the embedded video.

Share/Bookmark

Simple table soccer game for two players, computerized and controlled with the WeDo kit.

Datasheet:

Completion date: 28/06/2010
Power: electric (Power Functions)
Dimensions: length 54 studs / width 36 studs (not including axles) / height 45 studs
Weight: 1.88 kg
Motors: 2 x PF Medium

A spontaneous build which started as a joke with my co-workers. It’s a simple realization of the classic table soccer game adjusted for Lego minifigures and automated with WeDo components. Since I have completely no interest in soccer whatsoever, I didn’t pay real attention to keeping the number of players or size of the pitch accurate. My goal (sic!) was rather to demonstrate an innovative use of the WeDo components that to render a realistic model of a table soccer game.

Counting the game score and returning balls to a box are both fully automated. The actual game remains, obviously, fully manual, with eight players on two axles for each team, and a single goalkeeper on a separate axle. The goalkeeper’s sideways movement is limited so that the gate is not accidentally left empty. The players’ axles use different colors for improved distinction. The game is played on a pitch paved with large tiles and surrounded with solid walls build of classic bricks. Both gates have WeDo motion sensors inside, arranged in such a way that incoming ball must pass in front of the sensor. The ball then falls into a simple system of hanging rails, with one rail for each gate and a single central rail that receives all balls and directs them to a box.

The motion sensors trigger a simple algorithm: there is a sound played, an announcement displayed on computer’s screen, and then a second sound follows. Finally, there is a sliding beam above the respective gate which is moved by a given distance.  Both gates have such beams above them, each with a sticker representing numbers from 0 to 10. The beam is concealed behind a wall with a 2×1 stud window, and the desired number is shown through the window. Every time the algorithm is triggered, the beam is moved by a single number, on an obvious assumption that only one goal can be scored at a time. Both beams are controlled by PF Medium motors with a substantial gear reduction – it is possible to control the motor’s speed precisely with the WeDo software and thus eliminate the need for a gear reduction, but it was easier to keep the beam’s movements accurate with a high gear reduction. Additionally, there is a clutch gear at each motor – thanks to this, it is possible to reset the beams’ positions with a single key press, regardless of their current position. Upon pressing R, there is an announcement displayed, both beams are  returned to the ‘zero’ position, and once the procedure is completed another announcement follows.

The construction has seen little of actual gameplay, as it was completed during a holiday weekend and it was difficult to find another player. It was, however, successful in using the WeDo elements exactly how I intended to. Additionally, it was my first opportunity to shoot a video using my new camera with a high-speed filming mode. Therefore a large portion of the final video is composed of a footage shot at 210 FPS.

Photos:

Video:

Click here to view the embedded video.

Media reference:

Ekstra Bladet (Danish only), Engaget.com, Fascinating LEGO Model of the Day, Gadgets Now, Gizmologia (Spanish only), Hobby Media (Italian only), Hogargeek (Spanish only), Makezine, Omgunmen (German only), Sema Geek (French only), Technabob, Technoblogia (Polish only)

Share/Bookmark

Simple arm with 4 motors, controllable and programmable with the LEGO Education WeDo software.

Datasheet:

Completion date: 19/06/2010
Power: electric (Power Functions) / pneumatic (fed from internal compressor)
Dimensions: height 58 studs / full length of the arm: 113 studs
Weight: 1.53 kg
Motors: 4 x PF Medium

I had access to the LEGO Education WeDo kit for some time, but it was only after I bought second USB hub that I was able to come up with some ideas on how to make use of it. The kit is in a way similar to the LEGO Mindstorms, except it employs the PF system’s components and it needs a computer to be run on. Therefore it is not as mobile as the LEGO Mindstorms with its separate CPU brick, but it’s much more flexible as it needs a computer and PF components that most of the builders already have.

One of the limitations of the WeDo system’s architecture is having just two independent outlets on each USB hub. While it is consistent with how the PF IR receivers work, it also means that you can only control 2 motors/sensors with the basic kit, and up to 6 motors/sensors maximum as the software can control up to 3 USB hubs at once. This is still, however, better than 3 motors that can be plugged to a single NXT brick.

The first version of the arm was built in a couple of hours to be displayed on the same public event as my Caterpillar excavator was. It was controlled by 4 PF switches, to allow viewers to control it manually. It was, however, built with the WeDo software in mind from the very beginning (hence just 4 motors) and after the event I fixed some minor shortcomings and plugged it to my notebook.

It was easy and convenient to control all the motors using a simple keyboard layout as presented below. Basically, there were two keys for each motor, for running it in one direction or another, and there was a single universal stop key. A separate key was responsible for executing complex programs, and I have prepared one such program for the video (it was a time-consuming task due to the need to manually pre-adjust range of each movement).

Another shortcoming of the WeDo software is that it controls motors using a timeout function and not a rotation counter like the Mindstorms do. The advantage of this solution is the ability to use any motor – the PF extension wires make it possible to plug any 9V motor into the PF system and thus to make it WeDo-controllable. The disadvantage is that motors are friction-sensitive, which means that a motor that is run forward and backward for exactly the same time rarely returns to the exact starting position because of the differences in friction it encounters. With the executable programs, I solved this issue by pre-adjusting every movement manually.

The arm itself consists of a simple grabber with 4 independent fingers, each with a rubber tip for improved grip. The fingers are controlled by an autovalve and thus are capable of adjusting to the shape of the grabbed object. The grabber has a wrist that can be rotated through 360 degrees and uses a safety clutch. The arm is elevated with two linear actuators, with the arm’s level being maintained throughout the elevation process. Two battery boxes are mounted on the rear side of the arm to act as a counterweight for the grabber and its load. Finally, the entire arm can be rotated through 360 degrees by a turntable at the top of the tower it sits on. It felt like something innovative to build, and had certainly a huge potential for various programs and arm’s modifications.

Photos:

Video:

Click here to view the embedded video.

Media reference:

Fascinating LEGO Model Of The Day, Robótica recreativa y educativa (Spanish only)

Share/Bookmark

Model of a human arm. Features 4 electric and 4 pneumatic functions.

Datasheet:

Completion date: 28/02/2010
Power: electric (Power Functions) / pneumatic (fed from external pneumatic compressor with an airtank)
Dimensions:  unknown
Weight: unknown
Suspension: none
Motors: 3 x PF Medium, 1 x PF XL, 1 x RC

Just another weekend build – this is basically a late realization of an idea I had back when I was a kid. The goal was to build a model of an entire human arm, with palm included, that would have as much realistic functions as possible while being of more or less accurate size. The look of the arm was considered insignificant.

The most complex part of the arm is obviously the palm with 4 fingers and a thumb. The thumb can be bent and raised/lowered, whereas the remaining 4 fingers have two joints in each of them. The index finger was operated independently, and it was fairly possible to operate every finger individually, except that it would take two times more pneumatic hoses, which were already quite numerous (8 of these was going through the arm). The palm can be theoretically rotated through full 360 degrees, but I never actually tried it for the sake of the hoses in the wrist. The whole arm was heavy and a bending under its weight a bit, but it worked well. I think it was pretty satisfactory for something that was built in just two days.

Photos:

Video:

Click here to view the embedded video.

Media reference:

Brick Tales, Bricks in my Pocket, crave,  CrunchGear, Engaget, Fascinating LEGO Model Of The Day, Hack N Mod, Le Journal du Geek, NowhereElse, Sema Geek, Switched, Tamasindo, The Awesomer, The Geek Church, Tinkerology, Tom-Style

Share/Bookmark

Functional model of a chainsaw. Features on/off trigger and an integrated speed control.

Datasheet:

Completion date: 01/10/2009
Power: electric (Power Functions)
Dimensions:  length 58 studs / width 16 studs / height 21 studs
Weight: 0.615 kg
Motors: 1x PF Medium

A completely spontaneous and unplanned construction. I wanted to make a model of a regular chainsaw for some time, but I didn’t have any idea on how to build the blade until recently. When I got the blade to work, the rest followed in just a couple of days.

The blade is basically a 1 stud thick layer of bricks. On the tip of it, there is a 40t gear with no apparent means of support. Between it and the blade, there are two freely rotating 8t gears that let the 40t gear roll on them. The 40t gear is pushed against the 8t gears by the chain – so basically the whole blade is kept together by the tightness of the chain.

The saw is loosely modeled after some standard Husqvarna machine. I did not calculate its dimensions, it was built just roughly. Inside the saw, there is a single PF Medium motor powered by the Lego battery. The battery can be turned on or off by a trigger inside the saw’s rear handle. The speed control system implemented in the battery is utilized as well – the speed can be controlled by a lower grey gear on the saw’s side (the upper gear is just a mock-up). The saw was extremely fun to build, but doesn’t really cut well. Firstly the plastic chain was simply unfit for cutting, and secondly it tended to come apart when pushed against some hard surface, which resulted in the 40t gear falling off immediately.

Photos:

Video:

Click here to view the embedded video.

Share/Bookmark

Overview of the new rechargeable Power Functions battery box along with its dedicated transformer.

The Lego company rarely releases new battery boxes, and a rechargeable battery is something entirely new. So far the battery boxes have been unsophisticated containers for regular batteries, usually of AA type. For builders who used a lot of electrified functions it meant firstly buying a set of rechargeable batteries (for economic reasons and for generally better performance), and secondly removing the entire box from the construction whenever a recharging was needed. Now, with the 8878 box, we witness a new and fresh approach.

The 8878 box will please both PF users and Trains builders. Both groups will benefit from its small size and weight, and the latter one should find the integrated speed dial rather useful. From my personal point of view the new box is interesting for its size and weight alone. Since my main activity covers mobile models of vehicles, the PF battery box was the only large and heavy element whose presence was inevitable in every model. Its size often limited the functionality of a model, and its weight degraded its performance. The 8878 finally enables me to have basically similiar performance while using much less internal space and reducing weight by approx. 160 grams.

The 8878 box comes in a thick foil film, and – somewhat surprisingly – already fully charged. The attached documents contain some pretty obvious notes about not putting it into fire and not throwing away along with the regular garbage, but they also state that it should be charged with the 8887 transformer only. There are two semi-transparent stickers on the sides of the box – one of these summarizes the aforementioned warnings, while the other one includes basic specification of the box. According to it, the box contains a lithium ion polymer battery with 7.4V voltage and 1100 mAh capacity. The dimensions of the box are 4x5x8 studs, and the weight is 75 grams.

Atop the box, there are 4 elements. There is a transformer plug-in socket with a red LED indicator (which flashes during charging and remains constantly alight when the charging is done), a master on/off button with a green LED indicator (remains constantly alight when the box is on), an integrated speed dial and a perfectly usual PF power point. The dial offers 7 forward and 7 reverse speeds just like the 8879  Speed Control Remote does, but here it has fixed neutral and extreme positions, plus a small position indicator. An axle can be put inside it a single stud deep, just like with PF XL and Medium motors. The dial does not return to a neutral position, and operates regardless of the master button – which means that the box can be turned on or off at any dial’s position. This is a pretty comfortable solution if someone doesn’t really need the integrated speed dial (which will be probably the case of almost all mobile remote-controlled PF-powered constructions).

The box has obviously no pin holes, and is only compatible with studs. The speed dial is located perfectly in its center, which should prove comfortable. I was somewhat unsure about the master on/off button, which will be difficult to operate via some mechanism (which was easy with the 8881 box thanks to it’s switch with a pin hole), but I guess that the top of the box will in most cases require a manual access just to handle the recharging, so the box can be turned on or off manually with only little effort.

As for the pros and cons of the box, I’ve made two comparisons in the video. First is a comparison with a set of six AA GP 2500 rechargeable batteries, which I’ve been using as the main power source so far. The 8878 box offers 7.4V voltage (versus GPs’ 7.2 V), 1100 mAh capacity (versus GPs’ 2450 mAh) and 4 hours of full charging time (versus GPs’ 16 hours, which can be greatly reduced with a proper charger). We can easily see that the box sacrifices capacity for the sake of voltage and charging time. Since there is no need to take the box out to recharge it anymore, I consider it profitable – the need to take the entire box out of a model has been most bothersome.

The second is a comparison with the previous 8881 PF box, that is a simple container for six AA batteries. Here the 8878 box offers 4x5x8 studs size (versus 8881′s 4x8x11 studs) and 75 grams weight (versus 8881′s 235 grams). It should be noted that the weight of the 8881 box is greatly determined by the batteries used, and perhaps with another make of batteries this difference would be smaller.

As for the 8887 transformer, it comes in a cardboard box and has a fairly long (over 1.2 m) wire. The one I got was fitted with the UK type plug and marked ver. 3 – I believe there are versions for other plug standards too (e.g. there certainly is an USA version).  It looks pretty ordinary and there are only two places where the Lego name appears.

I believe the new box has an enormous potential, in particular for the model builders. In some cases it should make it possible to build models which were too small for the 8881 box. It has, however, one important downside – the price. Not only is it expensive, but it also requires another product to function properly – the transformer, which is being sold separately and for a considerable price too. Hence I believe that the box will be popular mainly with builders who find the 8881 box way too large and too heavy, and with the ones who have been just about to buy a set of rechargeable batteries for regular use, and who now face an interesting alternative.

Photos:

Video:

Click here to view the embedded video.

Share/Bookmark