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

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

A mechanism that selects which of the RC motor’s two outputs is used, and can effectively work as a gearbox.

As you’re probably well aware, the RC motors are unique for having two outputs, with the inner output (the one closer to the middle) having roughly 35% more speed and less torque than the outer one. Usually when using an RC motor, one has to choose one output that seems better suited for the job. With this simple mechanism, it is possible to switch between one output and another, and since the outputs have different characteristics, it can effectively work as a gearbox.

Please note that I can’t claim the authorship of the very idea, which has been around for years. I know that such a mechanism was invented long ago, but I was unable to find the original author nor any documentation, not even a single picture. I have therefore created this mechanism the way I would build it, which is probably very close or even identical to the original concept, as this mechanism is so simple that it’s difficult to build it in an entirely different way.

Also note that even though I used two RC motors in the instruction, the mechanism can be used just as well with a single motor. It’s just that I and many other builders tend to use the RC motors in tandems. Additionally, two 6-studs long axles has been used as the output of the entire mechanism here, but you can obviously change it as you see fit.

Finally, you can notice that the instruction, despite its general simplicity, has been created with the wonderful Lpub software by Kevin Clague. Thanks to the use of it, the instruction is very similar to the instructions from the official Lego sets, with a parts list for each individual step and with lengths of the axles and beams clearly specified. This is the standard for all my instructions I intend to provide from now on.

Photos:

Share/Bookmark

Compact, simple gearbox designed for use in Truck Trial races and high-torque applications. Step-by-step instruction and a two drive motors variant included.

Last year, the continuous development of the Truck Trial vehicles in our country resulted in the common use of gearboxes. Since the power-to-weight ratio of each vehicle decides how much points it gets, it is favourable to reduce this power to minimum. This is where gearboxes come in handy – they allow to use less motors, or less powerful motors, increasing gear reduction when needed, and decreasing it when less torque is needed. Without the gearboxes, all vehicles would have to use a gear reduction high enough to climb obstacles, which results in reduced speed and in a waste of time when e.g. driving downhill.

The loads exerted on vehicles’ drivetrains in our races are so high that it’s very difficult to use a gearbox with driving rings. In most cases, it results either in the driving rings disengaging under load, or in mechanical damage to them. Therefore it’s a common practice to use simple linear gearboxes, with as few gears as possible, as most vehicles can do very well with just a 2-speed gearbox. The need for reducing amount of gears to minimum resulted in integrating the drive motors into the moving parts of the gearboxes, so that the motors slide as the gears are changed. The idea, introduced by Emilus in his Truck Trial models, eliminates the need for complex transmission mechanisms between sliding driveshaft and stationary motor, and has practically no disadvantages, except for slight shifts of the vehicles’ centre of gravity caused by motors’ weight.

The following gearbox has been developed from a version used in my Fiat SPA35 Dovunque model. The Fiat’s gearbox has failed during the race, but it has given me the opportunity to observe exactly what are the causes of its malfunction. Based on this experience, the new gearbox has been reinforced in all the crucial spots and is practically immune to mechanical damage, while still being relatively compact and simple.

I have provided schemes, views from various angles and a full instruction for the gearbox, as well as a scheme and views of a version using two drive motors instead one.  Note that the sliding mechanism has not been included, because my experiences with Fiat have shown that it’s best to make it part of the chassis close to the gearbox, that part of the gearbox itself. Still, building such a mechanism should be fairly simple, as all it has to do is to slide the central bracing a single stud back and forth, and keep it in place. The mini linear actuators are one of the many options that can be considered here.

Photos:

Share/Bookmark

Steered, non-driven suspension designed for truck models using 62.4 x 20 wheels, especially for heavy ones. Offers Ackermann steering geometry as well as pivot point located within wheels, resulting in their more realistic behaviour while turning, and in the possibility to place them inside a tighter structure (e.g. mudguards). Step-by-step instruction provided.

Lego 62.4 x 20 wheels are very popular with medium-sized models, and extremely popular with models of regular trucks. Having built a number of such trucks, and with more models to come, I was looking for a solution for a front axle that would solve two most common problems occurring with these wheels: the steering pivot point being located outside the wheel and the steering shaft being stressed under model’s weight. This is what I came up with.

The steering pivot point is the point (or, more accurately, a vertical axle) around which the wheel is turned by the steering system. In real-life vehicles, this point is almost always located right in the middle of the wheel, so the wheels can be easily turned in place, the tyre wear is reduced and the wheel requires a minimal margin of free space around to turn. In Lego vehicles, only the 8448 set’s wheels allow to model it exactly. Still, the closer we place the pivot point to the wheel’s centre, the better. With the 62.4 x 20 wheels the best solution is to mount the wheels with the recessed side in (which matches the set-up of the front wheels in most of the large trucks) and to use the 87082 part to turn them. The resulting pivot point is located within the wheel, almost at the inner edge of the tyre. While it’s still not as good as having it exactly in the wheel’s centre, it still makes the wheels behave in a more realistic way while turning, and it reduces the margin of the free space they need to do so, thus allowing to build tighter, more realistic mudguards.

As for the model’s weight issue and the way it affects the steering shaft, I have adapted the solution used in many Truck Trial models, with the axle attached to the chassis by a large Technic turntable in a vertical set-up. This way the model’s weight is supported by the turntables and does not press on the steering shaft, thus not increasing the amount of torque needed to make the wheels turn. The friction on the steering shaft is significantly reduced and the steering motor doesn’t need to struggle against model’s weight.

As a side-effect of how the wheels are mounted, the suspension provides the Ackermann steering geometry.  In terms of Lego models it is generally superior to a standard steering geometry, and with the suspension 15 studs wide (just like shown in the instruction below), the geometry will work best for a vehicle whose centre of turning cycle is located just 10 studs behind this suspension’s rear turntable. With the centre of turning further away, the geometry will slightly degrade, and with very long models it will probably work somewhat worse than a standard steering geometry would.

The suspension I’ve developed is 15 studs wide, and with the wheels added it’s slightly over 18 studs wide. While 18 studs is the most common width of a regular truck scaled down to these wheel’s size, the suspension can be made 13 studs wide instead, allowing for a slightly narrower front axle.  The suspension has only a single stud of ground clearance, but it should be sufficient for most regular, non-offroad truck models. Different types of wheels can be used too, perhaps to a better result. With relatively light models (i.e. less than 3 kg of total weight) the turntables may prove not needed, and removing them should save plenty of space inside the chassis, especially above the axle. With the turntables, there is still some space inside for some stability measures such as shock absorbers – I didn’t put these here because the trucks I intend to use this suspension in should be sufficiently stabilized by their rear suspensions. With very heavy models, there is a risk that the steering system may pull the wheels off their axles – this should be largely preventable depending on how the wheels are  connected to these axles. Finally, please note that regular Technic turntables should be used, and the instruction only shows halves of the turntables because I was unable to find a complete model of this part.

Photos:

Share/Bookmark

New and improved version of my earlier design, a little more parts-costly, but free from its disadvantages.

One of the areas of building I enjoy the most are very accurate, faithful models of wheeled vehicles. I have a special thing for trucks, which are not only fun to play with, but usually also offer plenty of internal space for mechanics. One of the ways of using this space to improve model’s authenticity is to install a working trafficators system, which I have first achieved with my Kenworth Mammoet model using my early idea for an automated trafficators system. I could call the system automatic because it was controlled by the steering motor and it did not affect it its functioning, thus being seamlessly integrated with the steering system. It did, however, have two serious disadvantages: firstly, there was delay is switching between left and right trafficators, and secondly there was a risk of both left and right trafficators blinking at the same time as high as 50%. I didn’t come up with any efficient solution to this problem until now, by developing a new version of the mechanism whose internals were significantly rearranged.

The new system uses three PF switches in a hierarchic set-up: there is a single master switch and two child switches connected to it. The master switch is powered from the same power outlet as the steering motor, so turning off the motor cuts off the power from the trafficators system. The master switch is also being switched continuously by the motor all the time the motor runs. The same motor switches the two coupled child switches, which have a gearing between them, making sure than when one switch is on, the other is off. A clutch gear is used between the child switches and the motor to prevent them from stopping the motor when an extreme position is reached. Unlike the master switch, which is switched through all three positions (on/off/on), the child switches need to be switched only through two (on/off). This is achieved by partially blocking one of the child switches, which subsequently affects the other child switch too, as they are coupled at all times.

The resulting mechanism is capable of controlling any number of trafficators and switching between the left and right ones instantly. Thanks to the gearing between the child switched there is no risk of left and right trafficators blinking at the same time (still, a very short initial blink of the ‘wrong’ trafficators may occur if the respective child switch is not switched fast enough), and powering the master switch from the same power outlet as the steering motor prevents the whole system from staying on when the motor goes off. Below is an electrical/mechanical scheme of the whole mechanism, which may look messy on the photos but is in fact rather neat. Since its only practical disadvantage is taking up as much as three PF switches, I intend to use it in several truck models and perhaps in some supercars if a sufficient amount of internal space is available.

Photos:

Video:

Click here to view the embedded video.

Share/Bookmark

Compact gearbox design, with two linear shifters, fixed input and output shafts, and large span of gear ratios provided.

This particular idea started with the Truck Trial vehicles in mind. As the trucks used in the Polish Truck Trial are being constantly developed, more and more of them became equipped with simple gearboxes. Such vehicles have the obvious advantage of being able to adapt their drivetrain’s gear ratio to the requirements of the track, sacrificing speed when more torque is needed and gaining extra speed when less torque is needed. Developing a gearbox that would last through a Truck Trial race is quite a challenge, which is why gearboxes only became popular recently.

Aside from highly experimental or lightweight vehicles, all gearboxes currently used in our races are linear gearboxes. There are two reasons for this: firstly, a linear gearbox usually has more compact and thus more robust structure, and secondly the transmission driving rings used in more sophisticated Lego gearboxes are much less torque-resistant than the gear wheels are. Since linear gearboxes only use gear wheels, no transmission driving rings at all, this problem is eliminated. Additionally, with very simple, usually 2-speed linear gearboxes the shifting mechanism is typically very simple too, making the general complexity level of such a gearbox fairly low.

As Truck Trial races involve a significant torque to be handled, the gearboxes are made as simple and robust as possible, rarely using more than 2 speeds. We stick to the rule than any mechanism can be complex or robust, but not both – and it works very well for the Truck Trial constructions. Even a gearbox with just two gears is quite an advantage; a vehicle that can gain extra torque to drive uphill and extra speed to drive downhill will always beat the one that has no gearbox and drives at constant torque and speed. Since the amount of torque required to overcome any given obstacle is more or less the same for every truck, the gearbox-equipped trucks win by simply jumping to high gear and driving faster whenever possible.

There are two basic problems involved when building a torque-resistant linear gearbox: the choice of the gear wheels that will engage and disengage, and the length of the axles that will transfer the drive. As for the first problem, the double bevel gears are a very common choice because the shape of their teeth makes them engage and disengage easily, and also because they are strong (the smallest double bevel gear wheel, the 12-teeth one, is many times stronger that the smallest regular gear wheel, the 8-teeth one). As for the latter problem, the solution is simple: the axles have to be as short as possible and reinforced in as many places as possible to prevent them from bending under torque. Additional protection from the torque for the gearboxes is achieved by using gear reduction between the gearbox and the wheels. Thus a gearbox is placed directly on the drive motor’s output shaft, and it only handles motor’s nominal torque, not the torque multiplied by the gear reduction.

With this said, I started to work on a gearbox for my next Truck Trial vehicle. I wanted it to have fixed input and output shaft, with the only moving elements located somewhere between, to eliminate possible weak points. It meant that I had to use separate shifter axles. Moreover, to keep the axles short I had to keep the moving by a single stud only, so a single shifter axle could only provide two gears. That’s why I used two shifter axles, looking for a gearbox that would provide at least three gears.

The resulting gearbox was supposed to be mounted vertically, but is shown laid on a side in the pictures and video in order to show its internals better.  First video shows bare gearbox and its construction, while the second one shows a version with remote-control already integrated into it, and reinforced adequately. The gearbox provides a wide span of gear ratios, from nearly 8:1 reduction to nearly 1:3 overdrive. It is reasonably small and can shift from any gear to any other gear. Unfortunately it needs two separate motors for remote control and has a rather unusual switching pattern. As shown in the videos, the shifting time is reduced to as short as possible in order to make the gears engage and disengage seamlessly every time.

Eventually, I kept this gearbox for practical testing in some more ordinary vehicle and choose a much simpler 2-speed one for my Trial Truck. I do, however, find it very useful and convenient to control remotely, and I will certainly look for more than just one opportunity to use it in my future models, most likely some at least medium-sized trucks. If it proves successful, it may very well be installed on a Truck Trial vehicle, as intended from the beginning.

Photos:

Videos:

Click here to view the embedded video.

Click here to view the embedded video.

Share/Bookmark

New compressor design, using reciprocating motion instead of a rotary one. Smaller, stronger and more adjustable than traditional compressors, it can run up to 18 pumps.

I have presented some ideas for compressors earlier – they used at least two sets of alternatingly working pumps to keep the airflow fluent and the vibrations minimal. The problem, however, was that they all used a rotary motion to run the pumps, which made them large and structurally weak (e.g. because no central axle could be used to run the pumps, there had to be an empty space for the pumps to move). Both these problems increase rapidly with the growing number of pumps.

Having recently bought an extra supply of pumps, I was looking for a solution that would result in a compact and strong compressor. I have found it by replacing the traditional rotary motion by a reciprocating one. The compressor I’ve developed can use any even number of pumps between 2 and 18 (this limits results from the 12-studs long axle being the longest one we can use to put the pumps on), while being much smaller and stronger that the traditional ones. It can work with any motor, and has integrated gearing that can be adjusted to your needs by picking one of 4 available combinations. The only tradeoff is the fact that it generates more vibrations that the rotary compressors, but it still makes it a useful alternative. Even with 18 pumps, this compressor is only 14 studs long (not including the motor). The exemplary variant I’ve built for the video uses 8 pumps and its dimensions are just 9x6x7 studs (again, not including the motor).

You can find a complete instruction below, and the video is pretty explanatory. While many people tend to choose large compressor based on RC motors for large models, I dislike this solution because RC motors are noisy and difficult to use with the Power Functions system (they run at a current so high that it makes the battery boxes and batteries go off). Therefore for me, this solution will be a much better alternative in the future.

Photos:

Video:

Click here to view the embedded video.

Share/Bookmark

New gearbox concept – a 3-speed sequential synchronized pneumatic gearbox that can be operated entirely remotely.

The gearboxes are very useful even today, with the speed control feature available with the Power Functions system. They are even more useful when they are remote-controlled, because this way the vehicle doesn’t need to stop to shift gears – instead, the gears can be shifted while driving. This type of gearboxes can work just like the real ones: it can have some gears that are unable to start the vehicle, but can speed it up once it has some momentum already.

The easiest type of a remote-control gearbox is a 2-speed one, because it can be easily motorized like an end-to-end device; it can shift between 2 gears with a single motor easily. I always wanted to build a remote-controlled gearbox that would have more than 2 speeds and still require only a single motor to be operated. It was eventually achieved with the AeroShift gearbox (I made up that name because the ’3-speed remote-controlled sequential synchronized pneumatic gearbox’ didn’t sound too catchy ).

This gearbox is, as mentioned above, sequential, which means that it can’t shift from any gear to any gear. Instead, it has to shift through gears in a sequence, e.g. from 1st to 2nd and then from 2nd to 3rd. This type of gearbox is quite popular in motorbikes. The gearbox is also synchronized, thanks to the use of the driving rings, on assumption that it would be troublesome to watch for grinding gears in a gearbox that’s supposed to be operated remotely.

If you look closely enough, you’ll notice that the gearbox consists of two identical modules set as ‘mirrors’ of each other. It is perfectly possible to build more than two modules – the first one will provide two speeds, and each next module will provide one extra speed (hence 3 speeds with two modules). The gearbox would have 5 speeds with four modules, 7 speeds with six modules, and so on. I did not attept to use more modules, because for me 3 speeds with a gearbox of this size was a good solution, while 5 speeds with a gearbox twice as large was not. Additionally, it would require more than a single pneumatic cylinder to be operated, and thus greatly complicate the pneumatic system.

It should be mentioned that this gearbox can be operated without pneumatics. It would, however, require a number of gears, including gears with clutches, as well as a mechanism that would work like a stepper motor. Since a single pneumatic cylinder can replace all these mechanic parts, I have chosen this solution as a significantly simpler one.

The picture above shows a testing setup. The pressure gauge and speedometer are obviously not needed for the gearbox to work, and the pneumatic valve is supposed to be operated by a motor. The parts that are important for the proper functioning of the gearbox and may not appear so on the photo include the rubber band which makes sure that the driving rings are switched sequentially, not simultaneously, and the grey thin plates described as ‘limiters’ above, which make sure that the movement of the pneumatic cylinder is contained within a desired range. The cylinder can be mounted with its inlets pointing downwards to take less space, but it requires placing the pneumatic hoses in such way that they don’t interfere with the moving parts of the gearbox. I believe that this photo along with the ones that follow it are sufficient to build a copy of this gearbox, so I will just list the pros and cons of this gearbox according to my observations.

Pros: relatively small size,  ability to handle huge torque (the critical elements are the driving rings that tend to disengage when too much torque is applied), convenient location of the input and the output, identical functionality for the driveshaft rotating clockwise as well as counterclockwise, and a minimal chance of the mechanical failure in the gearbox (e.g. because all the gears that transfer the drive are encased in solid bricks).

Cons: uses pneumatics, doesn’t work well with high air pressure (it causes strain on the driving rings and thus slows the gearbox down, so use of an airtank with this gearbox is not recommended), is sequential (impossible to omit the middle gear, though it can be switched through it really quickly) hitting the medium gear precisely can be tricky (depends mainly on the proper calibration of the rubber band and the pneumatic pressure in the cylinder), the gears are shifted relatively slowly,  and there is a number of dead gears that generate additional friction.

The gearbox offers the following gear ratios: 1:1, 3:1 and 9:1. If these differences are too large for your use, it is perfectly possible to replace the 8t & 24t gears pairs with 12t & 20t gears pairs. It will result in the gear ratios changed to 1:1, 1.66:1 and 2.77:1, while the functioning of the gearbox will remain the same.

Photos:

Video:

Click here to view the embedded video.

Media reference:

TechnicBRICKs

Share/Bookmark

Explanation of the functionality of automated trafficators mechanism. Step-by-step instruction and a video tutorial provided.

Probably the most acclaimed feature of my Kenworth Mammoet model was the automated trafficators system, which made the model’s turn signals blink automatically whenever it made a turn. I’ve spent some time making the mechanism more compact and simplier than it originally was, which was eventually achieved with a sliding worm gear solution, the same that was used in my pneumatic autovalve.

The advantages of this mechanism  are: compact size, easy implementation and efficiency thanks to which it uses only a very limited amount of the motor’s torque to function. The mechanism can be used in a number of different setups – the example shown below was installed on the axle connecting motor to the steering mechanism, but it can be installed after the steering mechanism as well.

The disadvantages are: a small delay in blinking while changing direction, which can be helped by gearing up the axle that drives the mechanism, and a large chance that one of the switches stops in ‘on’ position. In this case one sets of lights will blink while the other one stays on instead off. It should be possible to use rubber bands to reset a switch to ‘off’ position once the direction is changed, but I found it difficult to select a rubber band of the exact desired strength. The rubber bands are not quite reliable in such applications, so I suppose it’s simply not worth the effort.

Photos:

Video:

Click here to view the embedded video.

Share/Bookmark

Three types of custom casings for worm gear and gears of various size.

There is a special Lego casing for a worm gear, which is nice and strong, but also large and only useful with a 24-teeth gear. To broaden the number of gears which can be encased along with the worm gear, I have developed three simple custom casings for a 8-teeth gear, 24-teeth gear and finally 40-teeth gear.

Photos:

Share/Bookmark