Model of the Kenworth T900 truck in the Australian road train variant. Features proportional steering using the NXT unit, remotely locked fifth wheel, working turn signals, three trailers, lights and custom stickers.  

Datasheet:

Completion date: 14/05/2012
Power: electric (Power Functions / NXT)
Dimensions: truck: length 67 studs / width 20 studs / height 31 studs, trailer #1: length 103 studs / width: 18 studs / height: 28 studs, trailer #2: length 122 studs / width 18 studs / height 9 studs, trailer #3: length 97 studs / width 18 studs / height 24 studs
Weight: truck: 2.891 kg, trailer #1: 2.378 kg, trailer #2: 1.440 kg, trailer #3: 2.194 kg
Suspension: none
Propulsion: 1 x NXT motor geared 3:1
Motors: 3 x NXT motor

This model was based on the Kenworth T900 truck converted to an Australian road train version. At the same time, it was an experiment on merging NXT functionality with a Model Team look.

I have started by modeling a pure T900 truck, adding some modifications typical for road trains along the way. The result is neither a stock Kenworth T900 nor a classic road train, but it still fits within the wide array of customizations popular among Australian drivers (and sheep).

The heart of the model was a NXT unit located at the back of the sleeper module. Since the chassis was entirely taken by two NXT motors (yes, they are this big), the sleeper was actually where almost all mechanical and electric elements were housed. Among them was a third NXT motor used to lock and unlock the fifth wheel, the 8878 rechargeable Power Functions battery for powering lights and turn signals, a Power Functions IR receiver for controlling the turn signals and HiTechnic IR Link sensor for allowing the NXT unit to send commands to the IR receiver.

It may come as a surprise that the model had an IR receiver housed inside next to the IR link sensor, but it resulted from sensor’s poor IR range. I was initially hoping to be able to install the sensor on an external NXT controller, thus having a chance to add IR receivers and turn signals in the trailers too, but with a model of that size the sensor simply wouldn’t reach the truck and all trailers at the same time. Also, with all the effort put into steering the model over a Bluetooth link, it would be a waste to be limited by the poor IR range.

The model had just a few functions. Both rear axles were driven by a single NXT motor geared 3:1, and the front axle was steered by another NXT motor without a clutch. There was no suspension, as it would affect the look of the model and it was hardly needed since it was never supposed to leave my apartment’s floor.  The fifth wheel was locked and unlocked using a horizontal 40-tooth gear with a short beam on its side, driven by the third NXT motor located in the sleeper. By rotating the wheel, the beam would block and unblock the fifth wheel’s only “exit”.

The front turn signals were controlled remotely and operated by the software, that is by the NXT unit turning them on and off repeatedly using the IR Link sensor. I did not install rear or any other turn signals for the fear of compromising the truck’s look with too many exposed wires and LEDs, but I have added working turn signals indicators on driver’s dashboard. I have also used the speaker of the truck’s NXT unit to honk (or rather beep) on command, and to beep while on reverse. It was a very simple thing and I have omitted it when trying to shorten the video.

The sleeper module was literally bursting at seams with electric elements and wires. There were three access hatches in it: top one for the 8878 battery, rear one for the NXT unit’s front panel, and a side one for taking the entire NXT unit out for battery replacement. The wires, especially the stiff NXT wires, proved problematic because they had to be arranged so as to allow moving the NXT unit out and back in. Eventually, the whole space at the back of the cabin was taken by wires and the side access hatch tended to stick out a little.

The entire set-up, that is the truck and three trailers, was controlled by a very simple external controller using another NXT unit. I have initially attempted to use the Hailfire Droid’s wheel as a steering wheel, but it proved unusable because using it to drive any regular gear wheel created very high gear acceleration which generated plenty of resistance. Gearing down in the latter stage was not an option, as a very considerable backlash in gear wheels was created. I was also tempted to build a pedal-like device to control the throttle, but with the NXT wires being quite short and impossible to connect in series, it proved pointless – I would have to keep such a pedal right next to the NXT unit.

The controller  was a variation of my NXT brick-to-brick remote, allowing proportional steering and drive with a speed control, as well as controlling all the remaining functions with touch sensors and NXT unit’s buttons. It was running the RobotC software, resulting in delay in the other NXT unit’s reactions over Bluetooth link. A secondary, more comfortable way of controlling the model was to use a computer with a gaming pad. Using a Bluetooth link and the RobotC software, it allowed to control the model with minimum delays and the gaming pad provided plenty of buttons and two analog joysticks which were used for speed-control for both drive and steering.

I was not fully happy with the model. Its functionality was troublesome, with a lot of effort required to start and connect the two NXT units, with delays in steering, and most importantly with the enormous amount of space taken by the NXT elements. Its look was somewhat compromised, with some simplifications in the bonnet and cabin’s roof area, and with the side air filters shortened to allow to open the bonnet up – the only alternative here was to cut the front bumper to move the bonnet’s hinge lower, which I didn’t want to do. I was afraid it was the kind of model that makes a good first impression, and goes downhill from there. Still, it was an interesting experience in using the NXT elements and in merging them with the PF ones.

Gaming pad control program:

#pragma config(Sensor, S4, HTIRL, sensorI2CCustom)
#include "drivers/HTIRL-driver.h"
#include "JoystickDriver.c"
tPFmotor SignalLeft = pfmotor_S4_C1_A;
tPFmotor SignalRight = pfmotor_S4_C1_B;

task Signals()
{
  while(true)
  {
    if(joy1Btn(2) == 1)
    {
      PFMotor(SignalRight, 7);
      nxtDisplayCenteredTextLine(5, " < [>]");
    }
    else if(joy1Btn(4) == 1)
    {
      PFMotor(SignalLeft, 7);
      nxtDisplayCenteredTextLine(5, "[<] > ");
    }
    else
    {
      PFMotor(SignalRight, 0);
      PFMotor(SignalLeft, 0);
      nxtDisplayCenteredTextLine(5, " <  > ");
    }
    wait1Msec(250);
    PFMotor(SignalRight, 0);
    PFMotor(SignalLeft, 0);
  }
}

task main()
{
  bMotorReflected[motorB] = true;
  bMotorReflected[motorC] = true;
  StartTask(Signals);
  while(true)
  {
    getJoystickSettings(joystick);
    motor[motorB] = 0;
    motor[motorC] = 0;
    motor[motorC] = joystick.joy1_y1 / 1.28;
    motor[motorB] = joystick.joy1_x1 / 1.28;
    nxtDisplayCenteredTextLine(0, "BATTERY: %3.1fV", nImmediateBatteryLevel / (float) 1000);
    nxtDisplayTextLine(2, "B: %d", motor[motorB]);
    nxtDisplayTextLine(3, "C: %d", motor[motorC]);

    if(joy1Btn(1) == 1)
      motor[motorA] = -100;
    else if(joy1Btn(3) == 1)
      motor[motorA] = 100;
    else
      motor[motorA] = 0;
  }
}
									

NXT-to-NXT control sender program:

#pragma config(Sensor,S1,touch1,sensorTouch)
#pragma config(Sensor,S2,touch2,sensorTouch)

bool leftturn = false;
bool rightturn = false;
bool soundhorn = false;

task BatLev()
{
  ubyte valueReceived[1];
  valueReceived[0] = 0;
  while(true)
  {
    cCmdMessageRead(valueReceived, 1, 1);
    nxtDisplayCenteredTextLine(0, "BAT: L%3.1f / R%3.1f", nImmediateBatteryLevel / (float) 1000, valueReceived[0] / (float) 10);
    wait1Msec(50);
  }
  return;
}

task Buttons() //0 = Gray Rectangle  1 = Right Arrow  2 = Left Arrow  3 = Orange Square
{
  nNxtButtonTask  = -2;nNxtExitClicks = 2;
  nxtDisplayCenteredTextLine(2, " <  > ");
  while(true)
  {
    if(nNxtButtonPressed == 1)
    {
      if (rightturn == false)
      {
        nxtDisplayCenteredTextLine(2, " < [>]");
        rightturn = true;
        leftturn = false;
      }
      else
     {
        nxtDisplayCenteredTextLine(2, " <  > ");
        rightturn = false;
        leftturn = false;
     }
    }
    else if(nNxtButtonPressed == 2)
    {
      if (leftturn == false)
      {
        nxtDisplayCenteredTextLine(2, "[<] > ");
        rightturn = false;
        leftturn = true;
      }
      else
     {
        nxtDisplayCenteredTextLine(2, " <  > ");
        rightturn = false;
        leftturn = false;
     }
    }
    else if(nNxtButtonPressed == 3)
    {
      soundhorn = true;
    }
  wait1Msec(350);
  }
}

task main()
{
  StartTask(BatLev);
  StartTask(Buttons);
  bFloatDuringInactiveMotorPWM = true;
  btConnect(1, "NXT2");
  while(true)
  {
    ubyte valueToSend[7];
    valueToSend[0] = nMotorEncoder[motorA];
    valueToSend[1] = nMotorEncoder[motorB];
    valueToSend[2] = SensorValue(touch1);
    valueToSend[3] = SensorValue(touch2);
    valueToSend[4] = rightturn;
    valueToSend[5] = leftturn;
    valueToSend[6] = soundhorn;
    cCmdMessageWriteToBluetooth(valueToSend, 7, 1);
    nxtDisplayTextLine(3, "Drive: %d", valueToSend[0]);
    nxtDisplayTextLine(4, "Steering: %d", valueToSend[1]);
    nxtDisplayTextLine(5, "Touch BLUE: %d", valueToSend[2]);
    nxtDisplayTextLine(6, "Touch RED: %d", valueToSend[3]);
    wait1Msec(50);
  }
}
									

NXT-to-NXT control receiver program:

#pragma config(Sensor, S4, HTIRL, sensorI2CCustom)
#include "drivers/HTIRL-driver.h"
tPFmotor SignalLeft = pfmotor_S4_C1_A;
tPFmotor SignalRight = pfmotor_S4_C1_B;
// config start
//bMotorReflected[motorA] = true;
//bMotorReflected[motorB] = true;
//bMotorReflected[motorC] = true;
bool buzzOnRev = true; // buzzing while on reverse
int steerAcc = 10; // steering accuracy margin (degrees)
// config end

int turnSignals = 0;

task Signals()
{
  while(true)
  {
    if(turnSignals == 1)
    {
      PFMotor(SignalRight, 7);
    }
    else if(turnSignals == 2)
    {
      PFMotor(SignalLeft, 7);
    }
    else
    {
      PFMotor(SignalRight, 0);
      PFMotor(SignalLeft, 0);
    }
    wait1Msec(250);
    PFMotor(SignalRight, 0);
    PFMotor(SignalLeft, 0);
  }
  wait1Msec(50);
}

task BatLev()
{
  while(true)
  {
    nxtDisplayCenteredTextLine(0, "BAT: L %3.1fV", nImmediateBatteryLevel / (float) 1000);
    ubyte valueToSend[1];
    valueToSend[0] = nImmediateBatteryLevel / (float) 100;
    cCmdMessageWriteToBluetooth(valueToSend, 1, 1);
    wait1Msec(50);
  }
  return;
}

task main()
{
  StartTask(BatLev);
  StartTask(Signals);
  nVolume = 3; // starting volume
  ubyte valueReceived[7];
  valueReceived[0] = 0;
  valueReceived[1] = 0;
  valueReceived[2] = 0;
  valueReceived[3] = 0;
  valueReceived[4] = 0;
  valueReceived[5] = 0;
  valueReceived[6] = 0;

  while(true)
  {
    cCmdMessageRead(valueReceived, 7, 1);
    nxtDisplayTextLine(2, "Drive: %d", valueReceived[0]);
    nxtDisplayTextLine(3, "Steering: %d", valueReceived[1]);
    nxtDisplayTextLine(4, "Touch BLUE: %d", valueReceived[2]);
    nxtDisplayTextLine(5, "Touch RED: %d", valueReceived[3]);

    // motorC (drive)
    motor[motorC] = 0;
    int afactor = valueReceived[0] / 5;
    if (afactor > 1 && afactor < 25)
    {
      afactor = afactor * 10;
      if (afactor > 100) afactor = 100;
      motor[motorC] = afactor;
      if (buzzOnRev == true) PlaySound(soundException);
    }
    else if (afactor > 1 && afactor > 25)
    {
      afactor = (51 - afactor) * -10;
      if (afactor < -100) afactor = -100;
      motor[motorC] = afactor;
      if (buzzOnRev == true) ClearSounds();
    }

    // motorB (steering)
    motor[motorB] = 0;
    int bfactor = valueReceived[1];
    if (bfactor > 1 && bfactor < 75) bfactor = bfactor;
    else if (bfactor > 1 && bfactor > 75) bfactor = (256 - bfactor) * -1;
    nxtDisplayTextLine(7,"Mtr B: %d/%d",nMotorEncoder[motorB], bfactor);
    bfactor = bfactor * 4;

    if (nMotorEncoder[motorB] < (bfactor + steerAcc)) while(nMotorEncoder[motorB] < bfactor) motor[motorB] = 10;
    else if (nMotorEncoder[motorB] > (bfactor - steerAcc)) while(nMotorEncoder[motorB] > bfactor) motor[motorB] = -10;
    else motor[motorB] = 0;

    // motorA
    motor[motorA] = 0;
    if (valueReceived[2] == 1) motor[motorA] = 100;
    else if (valueReceived[3] == 1)motor[motorA] = -100;

    // turn signals
    if (valueReceived[4] == 1) turnSignals = 1;
    else if (valueReceived[5] == 1) turnSignals = 2;
    else turnSignals = 0;

    // horn
    if (valueReceived[6] == 1) PlayTone(784, 50);
    else ClearSounds();

    wait1Msec(50);
  }
}

									

Work in progress photos:

Photos:

Video:

Click here to view the embedded video.

Media reference:

8 studs, The Brothers Brick, The LEGO Car Blog

Share/Bookmark

My first, very simple amphibious vehicle. Features a single propulsion system for land and water.

Datasheet:

Completion date: 22/04/2012
Power: electric (RC unit)
Dimensions: length 53 studs / width 52 studs / height 21 studs (not including antenna)
Weight: 1.709 kg (including camera)
Suspension: none
Propulsion: 4 x PF Medium motor geared 3:1
Motors: 4 x PF Medium

LEGO amphibious vehicles seem to be a challenge in the eyes of many, and I have been asked to build one more than once. It has been always my goal to make it as simple and as light as possible, because when it comes to letting things set out on a lake, I consider complexity and weight enemies of safety. The simplicity required a single propulsion system that would work on land and water alike, and I have eventually came up with one, using double Exo-force wheels, just like in my previous LIME vehicle.

The vehicle was build on two 51x12x6 floating hulls, which only have studs on top so I have added a simple studless central brace on their sides and bottom. Even with the brace, the whole construction was threatening to break in half. The propulsion consisted of four PF Medium motors geared down 3:1, because I expected each wheel to handle various stress when driving off the lake’s bank and back; some wheels would be operating in water while others would already be on the ground. One solution was to make a 4×4 propulsion system with differentials, but I decided it would be too complex. The 3:1 gear ratio was a necessary compromise and didn’t work very well. The vehicle lacked torque while driving and speed while sailing. A gearbox would be an ideal solution here, but again, it was too complex. In the end it turned out that I was right about keeping weight to minimum, because with the camera installed on board, one of the hull was on the very verge of sinking.

The entire construction was  designed for easy transportation, and each wheel could be easily detached together with the support which kept it away from the hull, minimizing the risk of splashing water on the hull. The whole vehicle was controlled by the RC unit to avoid problems with the IR link that would be inevitable with the Power Functions system. Skid steering was used on both land and water, with two left motors connected to RC unit’s primary output and two right motors connected to RC unit’s auxiliary output.

The vehicle was extremely simple and crude, but worked as intended, although with a very modest performance. Incidentally, its propulsion system proved to be completely litter-proof; the wheels have been able to clear the way out of any algae, sticks and other objects found near a lake’s bank, and they practically eliminated the risk of the vehicle being stranded. I consider it a proof of concept rather than a proper MOC, but it was an interesting experience.

Photos:

Video:

Click here to view the embedded video.

Share/Bookmark

My motorized variation of the LEGO Black Pearl set. Features drive and steering, rotating ship’s wheel, manual  anchor winches and lights.

Datasheet:

Completion date: 19/04/2012
Power: electric (Power Functions)
Dimensions: length 90 studs / width 34 studs / height 74 studs
Weight: 1.714 kg
Suspension: none
Propulsion: 1 x PF Medium motor geared 1:1
Motors: 2 x PF Medium, 1 x micromotor

I have been a fan of the LEGO 8184 Black Pearl set ever since it was released – it’s a jet black, shapely ship with an undead crew. However, since LEGO sets are usually cut down to meet certain budget restrains, I decided to build my own ship loosely based on it.

I don’t own the 8184 set, I simply bought a number of unique pieces from it, including black hull sections, sails and some minor pieces. I have also looked through the 8184′s building instruction to see how to build the bow and masts of my ship. The final result is in some parts very close to the original set, while quite different in others. It can be argued whether it was a custom construction or simply a modified set, but it should be noted that the ship was larger and much more complex than the original LEGO Black Pearl.

I was using only one inspiration when modeling the hull – the Revell’s Ghost Ship set,  which is somewhat exaggerated but still fairly realistic. The resulting ship lacked the nice shape of the original Black Pearl, instead it had a massive and tall rear superstructure, which was necessary to house all electric and mechanic components. The main problem was that side and rear walls of the superstructure had to be 3 studs thick each, to accommodate for windows with lights and red walls used as backgrounds.

The ship was able to drive and steer, and featured a ship’s wheel which rotated while steering. The propulsion system consisted of a single PF Medium motor installed under the hull, driving wedge belt wheels with 1:1 gear ratio. The steering was carried out by another PF Medium motor rotating a vertical axle at the back of the hull, with wheels with tires on the bottom end, and with a big decorative rudder attached. At the same time the ship’s wheel was rotated by a micromotor coupled with the second PF Medium motor, using a single knob wheel which proved able to mesh with it. I was very close to making the cannons fire remotely, by installing a motor that pulled their triggers with small sections of string. However, it turned out that the cannons’ triggers have to be instantly released to fire, and if there is any kind of delay resulting from the motor being unable to release all tension in an instant, the “cannonballs” stopped in the cannons’ exits. I was unable to find any simple solution to it, but at least by removing that mechanism I have gained more space – including space for the battery powering the ship, located under fake roof between the stairs at the back of the deck. I have been also toying with the idea of a chassis capable of rocking the entire ship, imitating waves, but I decided that such a chassis would have to be so tall that in the end it would barely look like a ship, more like a trailer with a ship on top of it.

Making the ship really float was out of the question, as the hull wasn’t even remotely watertight, and even if it was, the model would sink under its own weight. It was also way too top-heavy to float properly. Instead, I had a lot of fun working on the crew, which included, among others, an undead fisherman, a rotting cook, a joker farting fire, a painter with inclination to decorate ammunition, and even a pooping parrot, which could be considered an ex-parrot

The whole idea behind this model was slightly absurd, but making it come true was really fun. The ship looked truly majestic traveling across my room, and my only regret is that there was no simple way to take it out on a lake. It was also one of very few models to feature two hamsters in the video: Furball and Noodle.

Photos:

Video:

Click here to view the embedded video.

Media reference:

8studs (Polish only), Classic Pirates

Share/Bookmark

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

My second LEGO Mindstorms NXT MOC. Features a Bluetooth remote that controls motors connected to another brick with a speed control and a proportional steering.  

Datasheet:

Completion date: 03/03/2012
Power: electric (NXT brick)
Language: ROBOTC
Bricks: 2
Motors: 5 x NXT motor
Sensors: 2 x touch

One of the most interesting features of the NXT brick is that it can create a two-way Bluetooth link with another brick, which is in every way superior to IR link. I wanted to take advantage of this feature by creating a very simple, basic remote allowing to control motors connected to a brick inside a MOC with another brick. The remote was intended for typical wheeled vehicle, hence the drive control with a speed control feature and a proportional steering.

The actual remote is fairly simple, using two NXT motors and two touch sensors. Step-by-step instruction for building it can be found below. In order to work, it requires two-part program: one part is run on the sender brick, and another on the receiver brick. Note that for the bricks to create a Bluetooth link, they need to be first linked manually so that they keep each other in their Bluetooth contact list.

The drive motor, connected to receiver brick’s A port,  can be controlled with a speed control feature by rotating the knob on the remote’s left motor. Note that the movement of the knob is limited mechanically, thanks to which the programs are simpler. There is an option to make the receiver brick beep while on reverse, just like some trucks beep. Note that this is part of the program’s configuration, which is included entirely in the receiver part. Also note that the volume of the receiver brick can be changed remotely by using arrow buttons on the remote.

The steering motor, connected to receiver brick’s B port, is controlled proportionally, meaning that it’s synchronized with the steering wheel and it maintains the same angle. The steering wheel’s movement is also mechanically limited for simplicity. Note that the margin of 10 degrees is defined in the receiver’s configuration to avoid problems with motors’ inertia which are inevitable when the accuracy of synchronization is too high. Such a situation can lead to the receiver’s steering motor going forward and back endlessly, because it has too much inertia to stop exactly at the desired angle.

Finally the additional motor, connected to receiver brick’s C port is controlled by pressing and holding one of the two touch sensors.

Note that the orange button on the sender brick enables and disables sending of the data. This function is initially disabled when program starts, so that the position of the remote’s controls can be adjusted without affecting the receiver brick. Also note that upon disabling, the remote resets all values except volume, meaning that it stops all motors and returns the steering motor to center. However, once enabled, it will sends again the current values, making the receiver’s motors react accordingly. For example the steering motor is synchronized back, meaning that it moves from the central position to the current position of the steering wheel.

Finally, note that the first line of the remote’s display shows current voltage of remote’s and receiver’s battery, allowing to monitor if either of the two bricks is running low on power. The sender program can be aborted by pressing the sender brick’s default exit button twice.

Sender program:

#pragma config(Sensor,S1,touch1,sensorTouch)
#pragma config(Sensor,S2,touch2,sensorTouch)

bool sending = false;
int soundLevel = 1;

task BatLev()
{
  ubyte valueReceived[1];
  valueReceived[0] = 0;
  while(true)
  {
    cCmdMessageRead(valueReceived, 1, 1);
    nxtDisplayCenteredTextLine(0, "BAT: L%3.1f / R%3.1f", nImmediateBatteryLevel / (float) 1000, valueReceived[0] / (float) 10);
    wait1Msec(50);
  }
  return;
}

task Buttons()
{
  nNxtButtonTask  = -2;
  nNxtExitClicks = 2;
  nxtDisplayCenteredTextLine(1, "Not sending...");
  while(true)
  {
    if(nNxtButtonPressed == 3)
    {
      PlaySound(soundBeepBeep);
      if(sending == false){
        sending = true;
        nxtDisplayCenteredTextLine(1, "Sending...");
      }
      else{
        sending = false;
        ubyte valueToReset[5];
        valueToReset[0] = 0;
        valueToReset[1] = 0;
        valueToReset[2] = 0;
        valueToReset[3] = 0;
        valueToReset[4] = soundLevel;
        cCmdMessageWriteToBluetooth(valueToReset, 5, 1);
        nxtDisplayCenteredTextLine(1, "Not sending...");
      }
    }
    else if (nNxtButtonPressed == 1 && soundLevel < 3) soundLevel = soundLevel + 1;
    else if (nNxtButtonPressed == 2 && soundLevel > 0) soundLevel = soundLevel - 1;
  wait1Msec(350);
  }
}

task main()
{
  StartTask(BatLev);
  StartTask(Buttons);
  bFloatDuringInactiveMotorPWM = true;
  btConnect(1, "NXT2"); // connection: port, brick
  while(true)
  {
    ubyte valueToSend[5];
    valueToSend[0] = nMotorEncoder[motorA];
    valueToSend[1] = nMotorEncoder[motorB];
    valueToSend[2] = SensorValue(touch1);
    valueToSend[3] = SensorValue(touch2);
    valueToSend[4] = soundLevel;
    if(sending == true){cCmdMessageWriteToBluetooth(valueToSend, 5, 1);}
    nxtDisplayTextLine(3, "Drive: %d", valueToSend[0]);
    nxtDisplayTextLine(4, "Steering: %d", valueToSend[1]);
    nxtDisplayTextLine(5, "Touch BLUE: %d", valueToSend[2]);
    nxtDisplayTextLine(6, "Touch RED: %d", valueToSend[3]);
    nxtDisplayTextLine(7, "Volume: %d", valueToSend[4]);
    wait1Msec(50);
  }
}
									

Receiver program:

// config start
//bMotorReflected[motorA] = true;
//bMotorReflected[motorB] = true;
//bMotorReflected[motorC] = true;
bool buzzOnRev = true; // buzzing while on reverse
int steerAcc = 10; // steering accuracy margin (degrees)
// config end

task BatLev()
{
  while(true)
  {
    nxtDisplayCenteredTextLine(0, "BAT: L %3.1fV", nImmediateBatteryLevel / (float) 1000);
    ubyte valueToSend[1];
    valueToSend[0] = nImmediateBatteryLevel / (float) 100;
    cCmdMessageWriteToBluetooth(valueToSend, 1, 1);
    wait1Msec(50);
  }
  return;
}

task main()
{
  StartTask(BatLev);
  nVolume = 1; // starting volume
  ubyte valueReceived[5];
  valueReceived[0] = 0;
  valueReceived[1] = 0;
  valueReceived[2] = 0;
  valueReceived[3] = 0;
  valueReceived[4] = 1;

  while(true)
  {
    cCmdMessageRead(valueReceived, 5, 1);
    nxtDisplayTextLine(2, "Drive: %d", valueReceived[0]);
    nxtDisplayTextLine(3, "Steering: %d", valueReceived[1]);
    nxtDisplayTextLine(4, "Touch BLUE: %d", valueReceived[2]);
    nxtDisplayTextLine(5, "Touch RED: %d", valueReceived[3]);
    nxtDisplayTextLine(6, "Volume: %d", valueReceived[4]);
    nVolume = valueReceived[4];

    // motorA (drive)
    motor[motorA] = 0;
    int afactor = valueReceived[0] / 5;
    if (afactor > 1 && afactor < 15)
    {
      afactor = afactor * 10;
      if (afactor > 100) afactor = 100;
      motor[motorA] = afactor;
      if (buzzOnRev == true) ClearSounds();
    }
    else if (afactor > 1 && afactor > 25)
    {
      afactor = (51 - afactor) * -10;
      if (afactor < -100) afactor = -100;
      motor[motorA] = afactor;
      if (buzzOnRev == true) PlaySound(soundException);
    }

    // motorB (steering)
    motor[motorB] = 0;
    int bfactor = valueReceived[1];
    if (bfactor > 1 && bfactor < 75) bfactor = bfactor;
    else if (bfactor > 1 && bfactor > 75) bfactor = (256 - bfactor) * -1;
    nxtDisplayTextLine(7,"Mtr B: %d/%d",nMotorEncoder[motorB], bfactor);

    if (nMotorEncoder[motorB] < (bfactor + steerAcc)) while(nMotorEncoder[motorB] < bfactor) motor[motorB] = 10;
    else if (nMotorEncoder[motorB] > (bfactor - steerAcc)) while(nMotorEncoder[motorB] > bfactor) motor[motorB] = -10;
    else motor[motorB] = 0;

    // motorC
    motor[motorC] = 0;
    if (valueReceived[2] == 1) motor[motorC] = 100;
    else if (valueReceived[3] == 1)motor[motorC] = -100;

    wait1Msec(50);
  }
}
									

Photos:

Video:

Click here to view the embedded video.

Share/Bookmark

My first MOC using the LEGO Mindstorms NXT. Features a simple 4-speed gearbox that shifts automatically based on changes in the speed of the motor driving the gearbox.  

Datasheet:

Completion date: 25/02/2012
Power: electric (NXT brick)
Language: ROBOTC
Bricks: 1
Motors: 3 x NXT motor
Sensors: none

Having recently finally bought the LEGO Mindstorms NXT set, I have been looking for an opportunity to practice some programming. The default NXT-G software was a nightmare to me, so I was hesitating between leJOS and ROBOTC, finally settling for the latter.

The gearbox uses my 4-speed compact gearbox design, together with two motors that change speeds and a third motor that drives the gearbox and whose speed is being monitored by the program.

The program, which can be found complete below, consists of three task: one main and two subtasks included in it. One subtask monitors the use of the NXT brick’s buttons (because the program replaces their default functionality), while the other monitors the voltage of the brick’s battery (which can change quite a lot, depending on the load on the motors).  This is my first ROBOTC program, and I suppose I will be using these two subtasks on a regular basis.

The main tasks launches the two subtasks and controls all three motors. Once the propulsion motors is started, it monitors its speed counting the amount of degrees of rotation 10 times per second. Thus the basic speed unit is degrees/0.1 second, and depending on the condition of the batteries I’m using it’s usually around 70. There are two threshold speed values declared in the program, and if the motor exceeds one of them, the gearbox shifts up or down accordingly. Then it waits for a given interval to allow the motor to work a while with the changed gear ratio, and gets back to monitoring its speed.

The three values – lower and upper speed threshold value and the shifting interval –  are declared right at the beginning of the program for easy adjustment. I found it to be convenient and I will be probably doing so in my future programs as well.

The gearbox is synchronized and non-sequential, so it can be switched from any speed to any other speed. For simplicity, or more specifically to limit the number of possible combinations, I have designed the program to switch only between “adjacent” speeds – so it can swicth from 3rd to 4th or from 3rd to 2nd, but not from 3rd to 1st. There is one exception: shutting down. The program can be instructed to shut down by pressing the brick’s default exit button, and upon doing so it shifts the gearbox down to 1st. Obviously, to do so it needs to keep tracks of the currently selected gear – this information is stored in the variable gear, and updated when shifting down or up.

Programming the gearbox was an interesting experience and it taught me a lot about ROBOTC. I was surprised to found that rotating the “control” motors by a given degree proved less accurate than rotating them for a given time interval. By adjusting precisely their running time, I was able to achieve great accuracy needed to shift the transmission driving rings in the gearbox without pushing them too strongly into other parts of the gearbox.

Program:

// config start
int mspeed_high = 78;
int mspeed_low = 75;
int shift_time = 3000;
// config end

int gear = 1;

task Buttons()
{
  while(true)
  {
    nNxtButtonTask  = -2;
    nNxtExitClicks = 2;

    if(nNxtButtonPressed == 0)
    {
      eraseDisplay();
      motor[motorA] = 0;

            switch(gear)
            {
              case 1:
                break;

              case 2:
                motor[motorB] = -100;
                wait1Msec(120);
                motor[motorB] = 0;
                break;

              case 3:
                motor[motorC] = 100;
                wait1Msec(60);
                motor[motorC] = 0;
                wait1Msec(500);
                motor[motorB] = -100;
                wait1Msec(70);
                motor[motorB] = 0;
                break;

              case 4:
                motor[motorC] = -100;
                wait1Msec(60);
                motor[motorC] = 0;
                wait1Msec(500);
                motor[motorB] = -100;
                wait1Msec(70);
                motor[motorB] = 0;
                break;
            }

      StopAllTasks();
    }
  }
  return;
}

task BatLev()
{
  while(true)
  {
    nxtDisplayCenteredTextLine(0, "Brick up @ %3.1fV", nImmediateBatteryLevel / (float) 1000);
    wait1Msec(50);
  }
  return;
}

task main ()
{
  StartTask(Buttons);
  StartTask(BatLev);

  motor[motorA] = 0;
  bool mstatus = false;
  nMotorEncoder[motorB] = 0;
  nMotorEncoder[motorC] = 0;
  nxtDisplayCenteredTextLine(2, "MOTOR A OFF");
  nxtDisplayCenteredTextLine(4, "GEAR 1");
  wait1Msec(50);

  while(true)
  {
    if(nNxtButtonPressed == 3)
    {
      if (mstatus == true)
      {
        PlaySound(soundBlip);
        motor[motorA] = 0;
        mstatus = false;
        nxtDisplayCenteredTextLine(2, "MOTOR A OFF");
        nxtDisplayClearTextLine(5);
        nxtDisplayClearTextLine(7);
        wait1Msec(500);
      }
      else
      {
        motor[motorA] = 100;
        mstatus = true;
        nxtDisplayCenteredTextLine(2, "MOTOR A ON");
        wait1Msec(500);
        int mspeed = nMotorEncoder[motorA];

        while(nNxtButtonPressed != 3)
        {
          nMotorEncoder[motorA] = 0;
          wait1Msec(100);
          mspeed = nMotorEncoder[motorA];
          nxtDisplayCenteredTextLine(5, "Speed: %d", mspeed);

          if (mspeed > mspeed_high) // gearing up
          {
            nxtDisplayCenteredTextLine(7, "Gearing up...");
            switch(gear)
            {
              case 1:
                motor[motorB] = 100;
                wait1Msec(110);
                motor[motorB] = 0;
                gear = 2;
                nxtDisplayCenteredTextLine(4, "GEAR 2");
                wait1Msec(shift_time);
                break;

              case 2:
                gear = 3;
                motor[motorB] = -100;
                wait1Msec(60);
                motor[motorB] = 0;
                wait1Msec(300);
                motor[motorC] = -100;
                wait1Msec(60);
                motor[motorC] = 0;
                nxtDisplayCenteredTextLine(4, "GEAR 3");
                wait1Msec(shift_time);
                break;

              case 3:
                motor[motorC] = 100;
                wait1Msec(110);
                motor[motorC] = 0;
                gear = 4;
                nxtDisplayCenteredTextLine(4, "GEAR 4");
                wait1Msec(shift_time);
                break;

              case 4:
                nxtDisplayClearTextLine(7);
                break;
            }
          }
          else if (mspeed < mspeed_low) // gearing down
          {
            nxtDisplayCenteredTextLine(7, "Gearing down...");
            switch(gear)
            {
              case 4:
                motor[motorC] = -100;
                wait1Msec(110);
                motor[motorC] = 0;
                gear = 3;
                nxtDisplayCenteredTextLine(4, "GEAR 3");
                wait1Msec(shift_time);
                break;

              case 3:
                motor[motorC] = 100;
                wait1Msec(60);
                motor[motorC] = 0;
                wait1Msec(300);
                motor[motorB] = 100;
                wait1Msec(60);
                motor[motorB] = 0;
                gear = 2;
                nxtDisplayCenteredTextLine(4, "GEAR 2");
                wait1Msec(shift_time);
                break;

              case 2:
                motor[motorB] = -100;
                wait1Msec(110);
                motor[motorB] = 0;
                gear = 1;
                nxtDisplayCenteredTextLine(4, "GEAR 1");
                wait1Msec(shift_time);
                break;

              case 1:
                nxtDisplayClearTextLine(7);
                break;
            }
          }
        }
      }
    }
  }
}
									

Photos:

Video:

Click here to view the embedded video.

Share/Bookmark

Datasheet:

Completion date: 19/02/2012

Small vignette inspired by the frustration following yet another Diablo 3 release delay. It was a quick, spontaneous build without any particular goals. It allowed me to experiment a little with using and combining smallest LEGO pieces possible. Many of them weren’t even fixed in place, and the entire vignette was extremely fragile. Almost as fragile as my trial trucks

Photos:

Share/Bookmark

Model of the legendary 60′s racing car. Features full suspension, remote-controlled drive, steering and turn signals, lights and custom stickers.  

Datasheet:

Completion date: 17/01/2012
Power: electric (RC unit)
Dimensions: length 67 studs / width 31 studs / height 17 studs (not including antenna)
Weight: 2.35 kg
Suspension: full independent
Propulsion: 2 x RC motor geared 5:1
Motors: 2 x RC motor, 1 x PF Medium, 1 x micromotor
Top speed: 2.2 kmph

Ford GT40 is a classic racing car with a beautiful history. It was built for one purpose only: to defeat the Ferrari team in the Le Mans race – a goal set by Ford after failure to buy out the entire Ferrari company (Enzo Ferrari changed his mind in the last second). To understand the gravity of this challenge you should know that the Ferrari team won Le Mans six times in row starting from 1960.

The basic design of the car was purchased by the Ford from Lola Cars company owned by Erica Broadley and located in Huntingdon, UK. It can be therefore considered originally a British car. However, Ford spent several months working on car’s aerodynamic properties, under supervision of former CEO of the Aston Martin company, before it was considered race-ready. The finished car was the fastest car of its time, and it won Le Mans race four times in a row between 1966 and 1969 year. When it debuted in 1966, three GT40s have won three first places in the race. Keep in mind that we are talking about race that involved brands such as Ferrari or Porsche – it’s difficult to think of any modern Ford car completing such a task.

The original GT40s were built in a limited number, and the number of “civil” versions was even smaller, making it one of the world’s most often copied cars in the years to follow. It can be roughly estimated that the number of replicas today is several times greater than that of the original cars. Around 2002 the Ford company decided finally to create a new edition of the car, which was supposed to be as close to the first GT40 as possible. In reality, it was largely different, including being taller than 40 inches – a number the GT40′s name originated from – and it was therefore named Ford GT. Due to many differences some Gt40 enthusiast consider the new edition “softened” or completely ignore its existence. You can see the differences between new version (in front) and the old one (in back) below:

If you are looking to learn more about this legendary car, you can see a dedicated Top Gear episode here, and you can listen to how it sounds here.

Ford Gt40 is called the most beautiful car ever made by some – which is arguable, given the fact that its look does not stand out so much from the look of other cars of its era. In fact, it’s strikingly similar to some cars built around the same time (e.g. Lamborghini Miura P400 version S) or even slightly earlier (e.g. Porsche 904 GTS). As large models of supercars give little room for functions (no space) or for performance (weight), my goal was to make the model look real and authentic. Out of many versions of the GT40, with many details looking much differently, I have chosen the Mark II version – one that had a history of engine failures, but that also included many interesting and unique details, including air intakes on top of the rear bonnet. Some other details, such as the absence of side mirrors, show that it’s a racing version of the car. My decision to build the body of the model fully studless was strengthened by seeing a Ford GT40 model by Arvo brothers. I consider them to be among the world’s top studfull builders but their studfull model does not appeal to me – and I don’t think I could possibly top it.
Most of all I wanted to model the shapes of the car properly, looking for a balance between using beams, panels and flexible axles. I was looking for something between the approach of the LEGO 8448 set (body made of just general contours with gaping holes) and that of some older cars by Crowkillers (fully enclosed bodies made primarily of beams).  Some compromises proved necessary – the roof was a single part, without parts of it being attached to doors, because I was unable to find a good-looking solution to that. The front bonnet did not open and the rear bonnet was inaccurate – it should open with all side air intakes attached to it, but it only opened with the top two.

Most difficult part of modelling the body was the front of it, particularly the front mudguards and headlights. If you look at front of the Gt40, its mudguards follow a complex curve which slightly rises towards the sides of the car. I wanted to model this feature, which I consider crucial in making the model look accurate, and I think I achieved that using large panels set at complex angles, with flexible axles drawing the outer body contours. The headlights, on another hand, are nearly rectangle-shaped and come with vertical ribbing, typical for headlights of all cars of that time. I eventually used blocks of 1×2 trans-clear plates, which I think look accurate, but they absorb much of the light of the Lego LEDs behind them.

The model had only driver’s seat in the cabin, and it was moved to the side because of the RC unit occupying the center. The dashboard was completely inaccurate – it rested on top of the bearing frame, so there was no space to experiment with shaping it. The exhaust pipes were tilted downward a little more than they should, allowing the rear bonnet to open up further. Behind the cabin, there was a simple, static mock-up of the engine with some details, but less than I intended to include – I didn’t want to make the model heavier than it already was.

The construction of the model was 95% studless, with only rear axle using studded bearing structure around the differential. The bearing frame was built around the RC unit which was moved forward into the cabin, practically right next up to the front axle. The frame was rigid, but not completely – therefore the rear bonnet could be locked to the back of the cabin, thus providing extra stiffness to the top-rear part of the body.

While the model was not technically complex, it was challenging to integrate all the functions I wanted it to have with the RC unit and with the way it works.

The propulsion system consisted of two hard-coupled RC motors connected to the rear axle’s differential with 5:1 gear reduction (that is larger reduction than shown on photos – I had to increase it after taking photos). The transmission system also included a Lego speedometer, with the display integrated into passenger’s side of the dashboard. The model is rather slow – I was hoping to keep its weight under 2 kg, and with the final weight being much larger the motors were so strained that the batteries in the RC unit lasted about 5 minutes.

The suspension used typical Lego double wishbone independent suspension, with two short yellow shock absorbers per each wheel. It was soft, particularly the rear axle which carried most of the model’s weight. Just like in the original car, the front suspension is slightly narrower and the rear wheels wear bigger tires – in this case, tires were enlarged by putting two rubber treads over each of them. It should be noted that the model drove better without the treads that with them.

The steering system used steering output of the RC unit. The RC steering module could not be used because it was much too narrow. The steering wheel was attached to the RC unit’s output too through a series of gears. The steering lock was small – the RC steering unit rotates by small angle, and I couldn’t gear it up because there was no space for large gear wheels under the low bonnet.

The front and rear lights, using three pairs of Lego LEDs, were connected to the same output as the propulsion motors. They only shone when the model was driving, and they blinked when it started because of the RC motors taking all the power available.

The turn signals system, which took quite a lot of work to include, was based on my earlier mechanism. This time, however, it was remote-controlled rather than automated. I simply wanted to try remote-controlling it freely, and besides it would be nearly impossible to use it with the RC unit’s steering output. Instead, it was connected to the RC unit’s auxiliary output and it consisted of two parts connected only with wires – which was necessary to fit it in. First part was a micromotor driving an old 9V switch, located vertically at the back of the cabin, between the RC motors. The second part was a PF Medium motor rotating two PF switches, coupled with old toothed half-bushes so that turning one switch on turned the other one off. I wanted to control them with another micromotor, leaving enough space for passenger’s seat, but it proved too weak.  The turn signals could be made with just two pairs of Lego LEDs, except that their wires were too short. I had to use four pairs instead, and since the GT40 has single turn signals, I ended up with two spare LEDs in front and two in back. I have installed the front LEDs into the dashboard, creating turn signals indicator in front of the driver, and I have simply hidden the two rear ones.

The model had its imperfections and compromises, but in general it was fun, looked good and it was a great experience in studless building. I can say it was slower than I expected but looked better than I hoped. I think the photos of it are among the best I’ve ever made, and I also put a lot of work into the video, with a good effect. It was a good lesson for my future supercars, because it was example of a very typical supercar, with central engine, low ground clearance and rear axle drive.

Work in progress photos:

Photos:

Video:

Click here to view the embedded video.

Media reference:

8 studs (Polish only), TechnicBRICKs, Technic Delicatessen, The LEGO Car Blog

Share/Bookmark

A static Monty Python themed vignette with a slightly customized minifigure.  

Datasheet:

Completion date: 14/01/2012

I’ve been a big fan of anything related to the Monty Python group for years. Having recently learnt that the famous Black Knight from the no less famous “Monty Python and the Holy Grail” movie was played by not a bit less famous John Cleese, I sort of felt compelled to bring that scene into the world of Lego minifigures.

Click here to view the embedded video.

The main point about making this vignette was to make it instantly recognizable while using minimum customization on the minifigures. I’ve spent a while carefully choosing minifigures’ outfits and faces (well, a single face actually). I only customized what I absolutely had to: the Black Knight’s helmet was originally metallic silver and I painted it with two layers of Revell black matte paint. This was the most fitting LEGO helmet and it does not originally come in black. I have also used two tiny bits of black plasticine to keep the “blood” in place of the Black Knight’s arms.

The creations, simple as it was, provided me with a good opportunity to practice taking close-up photos inside a light tent. It was also my one and only creation up to that that I’ve built with no intention of taking it apart after.

Photos:

Share/Bookmark

Summary of another year of building and plans for the year ahead.

2011 was a good year for building and for being a fan of LEGO in general, with many new pieces becoming available and an amazingly ambitious 8110 Unimog set being released. For me personally, it was a busy year because I’ve spent large part of it working on my book that will be released in 2012, and therefore I had less time for building that usual. Still, 2011 resulted in 26 MOCs, which is quite a nice number.

The 2011 started with my biggest and most complex MOC so far: the Tow Truck 2, with 17 motors and nearly 19 meters of wires on board. In February I have undergone a surgery and it took me a couple of weeks to recover, resulting in just one simple MOC until April. In April I have started exploring a completely new area of building with the LEGO Monorail system, which is somewhat closed but still brings new challenges and possibilities, different than the ones associated with typical vehicular models. Later, in May, I have created first outdoor video of my MOC for a very long time, and one that I consider very nicely edited, so I will take the liberty of showing it here.

Click here to view the embedded video.

Also in May I have ventured into yet another building area: the marine vessels built entirely out of LEGO, first with my Quadramaran, and then with a demonic Trimaran one month later. The latter was also my first opportunity of making use of the LEGO RC unit – an element I have long wanted to have and finally managed to purchase. Sending it out on a lake for start was perhaps not the safest idea, but luckily it survived

June was an interesting month even without the Trimaran – I have failed at building a hamster-powered crane (the power supply was unwilling to cooperate)  and then I failed again at building a motorized sentry turret from the Portal game – I managed to make it look the way I wanted it to look, but I had to give up on most of the functions I wanted to include in it. Which is, I hope, a lesson for the future. The turret also happened to be my 100th MOC in my adult building career, and it also marked the moment when my YouTube accout hit 5,000,000 total views.

After not doing much in July, I have set my personal record by releasing 6 MOCs  in August. Among them was a Pushback Tug that has reached my goal of towing 20 kg of load with a LEGO vehicle, and two off-road vehicles (one using the 8110 set’s new suspension pieces) which failed to perform as expected, thus prompting me to finally quit participating Truck Trial races. I feel it’s a change for the better, especially since I keep filming these races and I can now focus on it  entirely. It’s worth mentioning than one of these two vehicles included a tiny vehicle inside it, controlled remotely through it, thus being something like a MOC inside a MOC. The rest of the year was less building-intensive with my book requiring more and more time; there were two small-scale tanks, a Monorail creation with 100 minifigures included, and my first vignette.

2011 was also a year I’ve become a YouTube partner. It does not change much in the way my videos are published – some of them will simply be released with some lame, royalty-free background music. I hope you can put up with this, as thanks to this I am able to get some money from YouTube, and they cover at least part of my LEGO expenses. It also seems that I’m getting more views being a YouTube partner, because I have over 7.2 millions of them now, at the end of the year, and that means 2.2 million views just since June.

At 5,999,598 total views halfway through September, the Rodent Overlord was pleased with my progress

All in all, I feel happy with how this year turned out – I have built more than I expected, and I think I’ve reached the goal of building more diversely than the year before. One thing I’m certainly unhappy about is the fact that I haven’t managed to finish a single supercar model, even though I got one mostly complete by the end of the year.

As for the 2012, some of my plans simply include building what I failed to build in 2011 – for example, the K2 Black Panther tank model and a model of the Rusich tank transporter to accompany it. I want the two of these to work together and perhaps I will manage to build them both in matching colours, which should look really well. It’s possible that K2 will be my last tank, at least for a longer while, and I’m planning to put together a roundup of all my tank after its release, because I feel that tanks are particularly good at showing my progress as a builder.

Among other 2012 plans are: a reach stacker, which I’ve been planning to build for really, really long, and an articulated Caterpillar hauler with unique ejector system. I would also like to make another try at building a huge model of a bucket wheel excavator, something I have abandoned two years ago when my model reached 7 kilograms and its chassis couldn’t support it properly. I think I’m now better prepared for such a challenge, and if I succeed, the result can be a truly impressive MOC, probably my biggest one ever.

Other “large” plans include an articulated Solaris Urbino city bus, the type I’m using to commute on a daily basis – I want to build it at large scale, which should be an interesting challenge. Just building a frame that will hold it together is challenging already. I would also like to try to work on something aesthetically pleasing by building a large model of the famous Mercedes Benz 540K Special Roadster, and finally I would like to build a large and complex fire engine based on the Volvo FH16 truck. I want to make it actually shoot water, and it should result in a good-looking and very functional model, something a little close to my aforementioned Tow Truck 2.

LEGO Technic Control Center

The 2012 is also the year of some new possibilities. I have recently managed to buy the LEGO Technic Control Center, which opens up a lot of options, including installing it on some large vehicle (such as the Caterpillar hauler mentioned earlier) and programming it to drive on its own. I have also acquired an EL wire, which can be interesting on the aesthetic side, and has, in fact, already inspired me to make two small and simple MOCs.

EL wire

I intend to keep trying out new things and new areas; some Monorail creations are very likely to come, and I would also like to try to build an amphibious vehicle – something that was suggested many times when I started with the marine vessels. As usual, I keep a few secret projects that are bound to come out into the daylight sooner or later, and I reserve the right to build things on a spontaneous impulse.

2012 is, last but not least, the year my book hits the shelves, and I hope it will live up to your expectations. I am often unable to share my knowledge in an accessible or efficient manner – there is a lot of people who expect me to somehow transfer it by e.g. YouTube comments – so it is my personal wish that the book can help you, guide you, teach you and inspire you, thus being of more use than any comment could be.

Finally, I should mention that I have developed a secondary hobby during 2011: playing a bass guitar. It’s something I enjoy no less than building with LEGO pieces, and while I’m unlikely to become skilled enough to pursue a musician’s career, it will certainly be taking some of my time. Who knows, it may even become a part of some MOC someday?

The culprit – Yamaha RBX 270 J

I feel good looking back at 2011 and even better looking forward at 2012. I want to thank you for following my work through this somewhat though and busy year, and I hope that 2012 will bring you at least some of the MOCs you wish to see.

Happy New Year 2012!

Paul

Share/Bookmark

Model of the famous WW2 German heavy tank. Features drive, steering, rotated turret, elevated main cannon and lights.  

Datasheet:

Completion date: 21/12/2011
Power: electric (Power Functions)
Dimensions: length 25 studs (36 studs including main cannon’s barrel) / width 14 studs / height 11 studs (not including antenna)
Weight: 0.694 kg
Suspension: none
Propulsion: 2 x PF Medium geared 1:1
Motors: 3 x PF Medium, 1 x micromotor

The Tiger tank is the probably most famous German WW2 tank, and one of the most famous tanks in history. It entered service as a heavy tank in 1942, and it was exceptionally advanced for the time, as well as deadly effective. The tank’s powerful gun and thick armour made it an unprecedented threat to both Soviet and Allied tanks. There is also another side to the Tiger, which states that the tank was over-engineered, extremely expensive and time-consuming to both produce and to maintain, and its fuel consumption was monstrous, especially for the crumbling economy of the after-1942 Nazi Germany. It was also designed in accordance with a doctrine of armoured warfare that was already obsolete – it was intended to win by superior firepower and thick armour, while the Soviet tanks, much cheaper and easy to produce in large numbers, were already winning by manoeuvrability, sloped armour and by working in groups. To make things worse, the Tiger was rushed into service without proper quality control and on-site technical support, resulting in many tanks disabled by technical malfunctions or being abandoned after getting stuck because there were no means to haul them out. Still, it was an impressive and fearsome tank, even if its significance has been exaggerated by the Nazi propaganda. One could say that it was a great tank itself, but it required maintenance and logistics on a level its creators were unable to provide.

As for the model, I was initially going to build it in large scale, with tracks of the newer type, but my primary goal was  to properly model its distinctive overlapping road wheels. This element is often ignored and simplified in the models of the Tiger, and I wanted to get it right. It turned out difficult to do at large scale, but I figured out that I could simply use Technic discs at a smaller one. Since there pieces don’t exist in dark bluish grey colour, I had to settle on next closest to it, that is pearl dark grey.

The model has undergone a rigorous technical control. 

After deciding on a small scale, the main challenge was to make the model fully remote controlled despite its very small size; the finished model’s hull was only 20 cm long and it could fit on the palm of my hand. My secondary goal, besides that, was to properly model the shape of the air filters on the rear of the tank, which are half-round but Lego builders often make them all-round or even rectangular. I achieved this by using four 6191 bricks, which was also a challenge as they only appear in dark bluish grey in a single Lego set, one brick per set.

Eventually, the model had to house four motors, two IR receivers, a battery and approximately 2 meters of wire, plus the large Technic turntable which would provide a stable base for the turret while allowing to install a motor in it. I won’t be dwelling on how hard it was, let’s just say that there were times when the functionality of the model depended on whether I can move some element half stud further or not.

The model was quite simple technically. It was driven by two PF Medium motors located in the middle of the hull, which drove rear sprockets with 1:1 gearing (the only ratio possible as there was no space for any large gear wheels). There was a battery in front of the hull, and a third Medium motor next to it, which drove the turret’s turntable through a worm gear. There was a single wire that entered the turret and powered a micromotor installed inside it, which drove another worm gear and thus controlled the elevation of the main gun’s barrel. There was no suspension whatsoever, and the two headlights on top of the hull had Lego LEDs inside them and shutters made of the bases of Lego levers.

The look of the model was not meant to be consistent with one particular of many versions of the Tiger, I just wanted it to be characteristic, which means that it’s close to the tanks from the early production batches. Its side number – 131 – was not random; the 131 Tiger tank can be found in the Bovington Museum in UK, and it’s probably the world’s only Tiger tank in driving condition today.

The model did not look perfectly; the hull was too tall by roughly 3/4 of a stud, and the turret had a gap beneath it to allow the worm gear to mesh with its turntable. This could be avoided if there was enough space in the hull to ‘sink’ the turntable inside it, but there wasn’t. The turret was 9 studs wide, built around a micromotor and held together by its roof rather than by its bottom. Its look was affected by mechanical parts inside it – its front was too tall and its rear end is a little too far to the back. Finally, the main gun’s barrel’s dimensions had to be heavily approximated at this scale – for example, the longest section of it should be 0.75 stud thick while the thickest section should be 1.5 stud thick. There are simply no Lego pieces with such dimensions that would have the required look.

The model was fun to play with, but clearly suffered from small size and low weight. It’s almost my lightest tank model ever, one third lighter than my T-72M tank and almost as light as my very simple Mark I tank – and it has more road wheels than any of those; 24 to be exact, with only 16 visible from the sides. Therefore its traction was poor and it was difficult to drive over my floor, where any unevenness (and there are many) affected its direction. I believe it would perform much better with more weight, stronger chassis and a simple suspension system, as proved by my earlier T-72 tank model, which had exactly the same tracks and propulsion system. This means that this model is probably example of the level of “miniaturization” that is already bad for its functionality.

Work in progress photos:

Photos:

Video:

Click here to view the embedded video.

Share/Bookmark

Two interesting mechanical solutions for transmission systems.  

The Oldham coupling and Schmidt coupling are two various mechanical solutions for transmitting drive between two parallel axles that are not aligned in line. That makes them alternative to universal joints, which are long, and to gear wheels, which only fit in specific spacings and affect power/speed ratio if not meshed at 1:1 ratio.

The Oldham coupling consists of two identical rotors, each connected to one axle, and a sliding element between them. The coupling shown here can handle input/output displacement of 1 vertical and 1 horizontal stud. It can be expanded to allow larger displacement by using longer axle in its sliding element, but that increases its diameter drastically. In short, the Oldham coupling is short and maintains 1:1 ration, but is complex, fragile and has large diameter.

The Schmidt coupling consists of three discs or triangles connected with links – three links per disc/triangle, giving six links total. The first and last discs/triangles are connected to the axles while the middle one simply hangs in mid-air. The unique property of this coupling is that it can work while its input and output are moving relatively to each other. That makes it an interesting solution for transferring drive to the moving elements of your construction. The Schmidt coupling is also extremely robust and can handle high torque while generating minimum backlash. Its main disadvantage is the length – in this case 5 studs – and the fact that it’s built around a rare LEGO piece.

Photos:

Video:

Click here to view the embedded video.

Share/Bookmark