Nuclear armageddon

Or possibly sponge-tipped minor annoyance

In this post, I’m going to show you a little bit of interfacing the Gadgeteer system with the real world.  I’m going to do this by hacking an old USB-controlled rocket launcher which I picked up (from Marks and Spencer of all places) some years ago.

The Gadgeteer system has a lot of plug-in components available, but none of them fire missiles (a major failing, in my book).  I, on the other hand, have a USB-controlled missile launcher which is useless because it has no drivers for Windows 7.  This is clearly a marriage made in heaven, and the nuptials start here.  Firstly, we need to understand the missile launcher. 

P1020272

Its mechanics are quite primitive, and based on three electric motors.  One rotates the launcher, one tilts it up and down and the third drives a mechanism which causes the spring-loaded foam missiles to fire in a strict, mechanically controlled sequence.  The base contains some control electronics, including a USB interface and drivers for the motors.  I’ve stripped all that out, because I want to control the motors directly.  The reason for this is that there is a rather nice Gadgeteer motor control board (the GHI Motor driver L298 module) which is ideal for the purpose.

P1020259

This module allows direct control of two motors.  You can set speed and direction for each, and it even has the ability to set the rate at which motor speed changes, so you can do nice gentle starts and stops.  The board also takes an external power supply for the motors (because USB power isn’t enough), so you can use it to drive motors at 12V or higher and use separate batteries.  This is very useful for robotics projects, where you generally don’t want to run the robot’s brain from the same batteries as its motors.  The only disadvantage for my missile launcher project is that it only control two motors – I’ll have to do without the ability to fire the missiles.  As long as the enemy does not know this, it’s still a deterrent.

The wiring for the motors is so simple, I’m not going to bother with a diagram.  A pair of wires runs form each of the M1 and M2 terminal blocks on the board direct to the motors in the missile launcher.  A battery pack with 4 AA batteries in it connects to the power terminal block, and that’s it for the output side of things.  I need some way of directing my weaponry, of course, and I’m going to use a joystick for this.  GHI do a little joystick module very like those on game controllers:

P1020260

The hardware, fully wired-up and ready to wage war, looks like this:

P1020266

To get the components to work together takes only a very simple bit of code.  In Visual Studio, create a Gadgeteer project and add the two components.  Auto-connection should give you something like this:

gadgeteer_1

In the code, you’ll find an object called joystick and another called motorControllerL298.  The Joystick class offers a method called GetJoystickPostion(), (N.B. this is not a spelling mistake – at least, not mine – the SDK method really is called this) which returns a Position object with members X and Y.  X and Y are doubles, and vary from 0 to 1 as the stick is moved up and down or left and right.   The joystick also has a button, which you trigger by pressing it down, but I’m not using that for the moment.  Notice that it’s necessary to query the joystick to get its values – there is no event which is fired when they change, because they are analogue values and the conversion process is noisy, which means that the values are changing very slightly all the time.  A sensible way to monitor the joystick is to use a Timer, set it to fire an event fairly frequently and check the joystick values during this event.

The motorControllerL298. object exposes a number of methods, the easiest of which is  MoveMotor().  This takes two arguments – an enum which identifies the motor you want to control, and an integer representing the desired speed of the motor.  The speed varies from –100 (full speed reverse) to 100 (full speed ahead), with zero being stopped.  It’s perhaps worth pointing out that with the SDK and hardware I have, setting the speed of MotorControllerL298.Motor.Motor1 actually changes the output marked M2 on the hardware, and vice versa.  It took me a while to figure this out while I was testing only one motor.  It’s possible that this has been fixed, or that I have early software.  I only mention it in case you run into the same issue and it saves you some head-scratching.

Here is the full code of the missile launcher control program.  It’s not particularly large or complex.

public partial class Program
{
  GT.Timer updateTimer;
 
  void ProgramStarted()
  {
    updateTimer = new GT.Timer(100);
    updateTimer.Tick += 
      new GT.Timer.TickEventHandler(updateTimer_Tick);
    updateTimer.Start();
  }

  void updateTimer_Tick(GT.Timer timer)
  {
    Joystick.Position pos = joystick.GetJoystickPostion();
    int motor1Value = (int)(pos.X * 200) - 100;
    int motor2Value = (int)(pos.Y * 200) - 100;

    motorControllerL298.MoveMotor(
      MotorControllerL298.Motor.Motor1, motor1Value);
    motorControllerL298.MoveMotor(
      MotorControllerL298.Motor.Motor2, motor2Value);
  }
}

The timer ticks every 100ms.  When it does, it gets the latest position from the joystick, and converts the 0.0 to 1.0 values for X and Y into the –100 to 100 range of values used by the motor controller.  Then it sets the motor controller’s drive values.  And that’s it.  You’ve probably spotted that all I am doing is setting the speed of the drive motors – I’ve got no way of (automatically) knowing where the missiles are actually pointing.  That’s because there are no sensors in the missile launcher.  Actually, there are a couple of limit switches on the rotation and elevation mechanisms, but that’s all.  So it’s strictly manual control a present.

There’s a terrifying video of the system on YouTube, showing its barely-restrained destructive capability.   All that remains is to wire up the firing mechanism, then my enemies will be quaking in their boots.  Or would be, if I had any.

Next time, (mutually-assured destruction permitting), I’ll demonstrate the use of a Gadgeteer camera, and we’ll see if it’s any good for target tracking.

One thought on “Nuclear armageddon”

Leave a Reply

Your email address will not be published. Required fields are marked *