In early January, we were tasked with creating a unique, interactive experience for the SXSW Interactive launch party with Frog Design. We bounced around many ideas, and finally settled on a project that Rick suggested during our first meeting: boxing robots controlled via Kinect.

The theme of the opening party was Retro Gaming, so we figured creating a life size version of a classic tabletop boxing game mashed up with a "Real Steel"-inspired Kinect experience would be a perfect fit. Most importantly, since this was going to be the first big project of the new Coding4Fun team, we wanted to push ourselves to create an experience that needed each of us to bring our unique blend of hardware, software, and interaction magic to the table under an aggressively tight deadline.

Hardware

The BoxingBots had to be fit a few requirements:

1. They had to be fun
2. They had to survive for 4 hours, the length of the SXSW opening party
3. Each robot had to punch for 90 seconds at a time, the length of a round
4. They had to be life-size
5. They had to be Kinect-drivable
6. They had to be built, shipped, and reassembled for SXSW

Creating a robot that could be beaten up for 4 hours and still work proved to be an interesting problem. After doing some research on different configurations and styles, it was decided we should leverage a prior project to get a jump start to meet the deadline. We repurposed sections of our Kinect drivable lounge chair, Jellybean! This was an advantage because it contained many known items, such as the motors, motor controllers, and chassis material.  Additionally, it was strong and fast, it was modular, and the code to drive it was already written.

Jellybean would only get us part of the way there, however.  We also had to do some retrofitting to get it to work for our new project. The footprint of the base needed to shrink from 32x50 inches to 32x35 inches, while still allowing space to contain all of the original batteries, wheels, motors, motor controllers, switches, voltage adapters. We also had to change how the motors were mounted with this new layout, as well as provide for a way to easily "hot swap" the batteries out during the event. Finally, we had to mount an upper body section that looked somewhat human, complete with a head and punching arms.

 
Experimenting with possible layouts

The upper body had its own challenges, as it had to support a ton of equipment, including:

• Punching arms
• Popping head
• Pneumatic valves
• Air manifold
• Air Tank(s)
• Laptop
• Phidget interface board
• Phidget relay boards
• Phidget LED board
• Xbox wireless controller PC transmitter / receiver
• Chest plate
• LEDs
• Sensors to detect a punch

Brian and Rick put together one of the upper frames

Punching and Air Tanks

We had to solve the problem of getting each robot to punch hard enough to register a hit on the opponent bot while not breaking the opponent bot (or itself). Bots also had to withstand a bit of side load in case the arms got tangled or took a side blow. Pneumatic actuators provided us with a lot of flexibility over hydraulics or an electrical solution since they are fast, come in tons of variations, won't break when met with resistance, and can fine tuned with a few onsite adjustments.

To provide power to the actuators, the robots had two 2.5 gallon tanks pressurized to 150psi, with the actuators punching at ~70psi.  We could punch for about five 90-second rounds before needing to re-pressurize the tanks.  Pressurizing the onboard tanks was taken care of by a pair of off-the-shelf DeWalt air compressors.

The Head

It wouldn’t be a polished game if the head didn’t pop up on the losing bot, so we added another pneumatic actuator to raise and lower the head, and some extra red and blue LEDs. This pneumatic is housed in the chest of the robot and is triggered only when the game has ended.

To create the head, we first prototyped a concept with cardboard and duct tape. A rotated welding mask just happened to provide the shape we were going for on the crown, and we crafted each custom jaw with a laser cutter.  We considered using a mold and vacuum forming to create something a bit more custom, but had to scrap the idea due to time constraints.

Sensors

Our initial implementation for detecting punches failed due to far too many false positives. We thought using IR distance sensors would be a good solution since we could detect a “close” punch and tell the other robot to retract the arm before real contact. The test looked promising, but in practice, when the opposite sensors were close, we saw a lot of noise in the data. The backup and currently implemented solution was to install simple push switches in the chest and detect when those are clicked by the chest plate pressing against them.

Power

Different items required different voltages. The motors and pneumatic valves required 24V, the LEDs required 12V and the USB hub required 5V. We used Castle Pro BEC converters to step down the voltages. These devices are typically used in RC airplanes and helicopters.

Shipping

So how does someone ship two 700lb robots from Seattle to Austin? We did it in 8 crates. . The key thing to note is that the tops and bottoms of each robot were separated. Any wire that connected the two parts had to be able to be disconnected in some form. This affected the serial cords and the power cords (5V, 12V, 24V).

Software

The software and architecture went through a variety of iterations during development. The final architecture used 3 laptops, 2 desktops, an access point, and a router. It's important to note that the laptops of Robot 1 and Robot 2 are physically mounted on the backs of each Robot body, communicating through WiFi to the Admin console. The entire setup looks like the following diagram:

Admin Console

The heart of the infrastructure is the Admin Console. Originally, this was also intended to be a scoreboard to show audience members the current stats of the match, but as we got further into the project, we realized this wouldn't be necessary. The robots are where the action is, and people's eyes focus there. Additionally, the robots themselves display their current health status via LEDs, so duplicating this information isn't useful. However, the admin side of this app remains.

Sockets

The admin console is the master controller for the game state and utilizes socket communication between it, the robots, and the user consoles. A generic socket handler was written to span each computer in the setup. The SocketListener object allows for incoming connections to be received, while the SocketClient allows clients to connect to those SocketListeners. These are generic objects, which must specify objects of type GamePacket to send and receive:

public class SocketListener<TSend, TReceive> where TSend : GamePacket                                                
                                             where TReceive : GamePacket, new()

GamePacket is a base class from which specific packets inherit:

public abstract class GamePacket
{
    public byte[] ToByteArray() 
    {   
        MemoryStream ms = new MemoryStream();           
        BinaryWriter bw = new BinaryWriter(ms);
                
        try
        {           
            WritePacket(bw);
        }
        catch(IOException ex)
        {
            Debug.WriteLine("Error writing packet: " + ex);
        }
        
        return ms.ToArray();
    }
        
    public void FromBinaryReader(BinaryReader br)
    {        
        try
        {    
            ReadPacket(br);       
        }
        catch(IOException ex)       
        {
            Debug.WriteLine("Error reading packet: " + ex);
        }
    }
    
    public abstract void WritePacket(BinaryWriter bw);
    public abstract void ReadPacket(BinaryReader br);
}

For example, in communication between the robots and the admin console, GameStatePacket and MovementDescriptorPacket are sent and received. Each GamePacket must implement its own ReadPacket and WritePacket methods to serialize itself for sending across the socket.

Packets are sent between machines every "frame". We need the absolute latest game state, robot movement, etc. at all times to ensure the game is functional and responsive.

As is quite obvious, absolutely no effort was put into making the console "pretty". This is never seen by the end users and just needs to be functional. Once the robot software and the user consoles are started, the admin console initiates connections to each of those four machines. Each machine runs the SocketListener side of the socket code, while the Admin console creates four SocketClient objects to connect to each those. Once connected, the admin has control of the game and can start, stop, pause, and reset a match by sending the appropriate packets to everyone that is connected.

Robot

The robot UI is also never intended to be seen by an end user, and therefore contains only diagnostic information.

Each robot has a wireless Xbox 360 controller connected to it so it can be manually controlled. The UI above reflects the positions of the controller sticks and buttons. During a match, it's possible for a bot to get outside of our "safe zone". One bot might be pushing the other, or the user may be moving the bot toward the edge of the ring. To counter this, the player's coach can either temporarily move the bot, turning off Kinect input, or force the game into "referee mode" which pauses the entire match and turns off Kinect control on both sides. In either case, the robots can be driven with the controllers and reset to safe positions. Once both coaches signal that the robots are reset, the admin can then resume the match.

Controlling Hardware

Phidget hardware controlled our LEDs, relays, and sensors. Getting data out of a Phidget along with actions, such as opening and closing a relay, is shockingly easy as they have pretty straightforward C# APIs and samples, which is why they typically are our go-to product for projects like this.

Below are some code snippets for the LEDs, relays, and sensor.

LEDs – from LedController.cs

This is the code that actually updates the health LEDs in the robot's chest. The LEDs were put on the board in a certain order to allow this style of iteration. We had a small issue of running out of one color of LEDs so we used some super bright ones and had to reduce the power levels to the non-super bright LEDs to prevent possible damage:

private void UpdateLedsNonSuperBright(int amount, int offset, int brightness)
{
    for (var i = offset; i < amount + offset; i++)
    {
        _phidgetLed.leds[i] = brightness / 2;
    }
}

private void UpdateLedsSuperBright(int amount, int offset, int brightness)
{
    for (var i = offset; i < amount + offset; i++)
    {
        _phidgetLed.leds[i] = brightness;
    }
}

Sensor data – from SensorController.cs

This code snippet shows how we obtain the digital and analog inputs from the Phidget 8/8/8 interface board:

public SensorController(InterfaceKit phidgetInterfaceKit) : base(phidgetInterfaceKit)
{    
    PhidgetInterfaceKit.ratiometric = true;
}

public int PollAnalogInput(int index)
{
    return PhidgetInterfaceKit.sensors[index].Value;
}

public bool PollDigitalInput(int index)
{
    return PhidgetInterfaceKit.inputs[index];
}

Relays – from RelayController.cs

Electrical relays fire our pneumatic valves. These control the head popping and the arms punching. For our application, we wanted the ability to reset the relay automatically. When the relay is opened, an event is triggered and we create an actively polled thread to validate whether we should close the relay. The reason why we actively poll is someone could be quickly toggling the relay. We wouldn't want to close it on accident. The polling and logic does result in a possible delay or early trigger for closing the relay, but for the BoxingBots the difference of 10ms for a relay closing is acceptable:

public void Open(int index, int autoCloseDelay)
{   
    UseRelay(index, true, autoCloseDelay);
}

public void Close(int index)
{
    UseRelay(index, false, 0);
}

private void UseRelay(int index, bool openRelay, int autoCloseDelay)
{
    AlterTimeDelay(index, autoCloseDelay);
    PhidgetInterfaceKit.outputs[index] = openRelay;
}

void _relayController_OutputChange(object sender, OutputChangeEventArgs e)
{
    // closed
    if (!e.Value)
        return;

    ThreadPool.QueueUserWorkItem(state =>
    {                                          
        if (_timeDelays.ContainsKey(e.Index))
        {                                              
            while (_timeDelays[e.Index] > 0)                       
            {
                Thread.Sleep(ThreadTick);           
                _timeDelays[e.Index] -= ThreadTick;
            }                                            
        }
                                            
        Close(e.Index);
                                        
    });
}

public int GetTimeDelay(int index)
{
    if (!_timeDelays.ContainsKey(index))
        return 0;
    return _timeDelays[index];
}

public void AlterTimeDelay(int index, int autoCloseDelay)
{
    _timeDelays[index] = autoCloseDelay;
}

User Console

Since the theme of the party was Retro Gaming, we wanted to go for an early 80's Sci-fi style interface, complete with starscape background and solar flares! We wanted to create actual interactive elements, though, to maintain the green phosphor look of early monochrome monitors. Unlike traditional video games, however, the screens are designed not as the primary focus of attention, but rather to help calibrate the player before the round and provide secondary display data during the match. The player should primarily stay focused on the boxer during the match, so the interface is designed to sit under the players view line and serve as more of a dashboard during each match.

However, during calibration before each round, it is important to have the player understand how their core body will be used to drive the Robot base during each round. To do this, we needed to track an average of the joints that make up each fighter's body core. We handled the process by creating a list of core joints and a variable that normalizes the metric distances returned from the Kinect sensor into a human-acceptable range of motion:

private static List<JointType> coreJoints = newList<JointType>( 
    newJointType[] {
        JointType.AnkleLeft,
        JointType.AnkleRight,
        JointType.ShoulderCenter,
        JointType.HipCenter
    });
private const double RangeNormalizer = .22;
private const double NoiseClip = .05;

And then during each skeleton calculation called by the game loop, we average the core positions to determine the averages of the players as they relate to their playable ring boundary:

public staticMovementDescriptorPacket AnalyzeSkeleton(Skeleton skeleton)
{           
    // ...

    CoreAverageDelta.X = 0.0;
    CoreAverageDelta.Z = 0.0;
    foreach (JointType jt in CoreJoints)
    {
        CoreAverageDelta.X += skeleton.Joints[jt].Position.X - RingCenter.X;
        CoreAverageDelta.Z += skeleton.Joints[jt].Position.Z - RingCenter.Z;
    }

    CoreAverageDelta.X /= CoreJoints.Count * RangeNormalizer;
    CoreAverageDelta.Z /= CoreJoints.Count * RangeNormalizer;

    // ...

    if (CoreAverageDelta.Z > NoiseClip || CoreAverageDelta.Z < -NoiseClip)
    {
        packet.Move = -CoreAverageDelta.Z;
    }

    if (CoreAverageDelta.X > NoiseClip || CoreAverageDelta.X < -NoiseClip)
    {
        packet.Strafe = CoreAverageDelta.X;
    }
}

In this way, we filter out insignificant data noise and allow the player's average core body to serve as a joystick for driving the robot around. Allowing them to lean at any angle, the move and strafe values are accordingly set to allow for a full 360 degrees of movement freedom, while at the same time not allowing any one joint to unevenly influence their direction of motion.

Another snippet of code that may be of interest is the WPF3D rendering we used to visualize the skeleton. Since the Kinect returns joint data based off of a center point, it is relatively easy to wire up a working 3D model in WPF3D off of the skeleton data, and we do this in the ringAvatar.xaml control.

In the XAML, we simply need a basic Viewport3D with camera, lights, and an empty ModelVisual3D container to hold or squares. The empty container looks like this:              

<ModelVisual3D x:Name="viewportModelsContainer2">                   
    <ModelVisual3D.Transform>
        <Transform3DGroup>           
            <RotateTransform3D x:Name="bodyRotationCenter" CenterX="0" CenterY="0" CenterZ="0">      
                <RotateTransform3D.Rotation>             
                    <AxisAngleRotation3D x:Name="myAngleRotation" Axis="0,1,0" Angle="-40"/>                 
                </RotateTransform3D.Rotation>           
            </RotateTransform3D> 
        </Transform3DGroup> 
    </ModelVisual3D.Transform>
</ModelVisual3D>

In the code, we created a generic WPF3DModel that inherits from UIElement3D and is used to store the basic positioning properties of each square. In the constructor of the object, though, we can pass a reference key to a XAML file that defines the 3D mesh to use:

public WPF3DModel(string resourceKey)
{
    this.Visual3DModel = Application.Current.Resources[resourceKey] as Model3DGroup;
}

This is a handy trick when you need to do a fast WPF3D demo and require a certain level of flexibility. To create a 3D cube for each joint when ringAvatar is initialized, we simply do this:

private readonly List<WPF3DModel> _models = new List<WPF3DModel>();
private void CreateViewportModels()
{           
    for (int i = 0; i < 20; i++)
    { 
        WPF3DModel model = new WPF3DModel("mesh_cube");
        viewportModelsContainer2.Children.Add(model);

        // ...

        _models.Add(model);
    }

    // ...
}

And then each time we need to redraw the skeleton, we loop through the skeleton data and set the cube position like so:

if (SkeletonProcessor.RawSkeleton.TrackingState == SkeletonTrackingState.Tracked)
{
    int i = 0;  

    foreach (Joint joint in SkeletonProcessor.RawSkeleton.Joints)
    {
        if (joint.TrackingState == JointTrackingState.Tracked)
        {
                                        
            _models[i].Translate(                                        
                joint.Position.X * 8.0,                                    
                joint.Position.Y * 10.0,
                joint.Position.Z * -10.0);

            i++;
        }
    }

    // ...

}

There are a few other areas in the User Console that you may want to further dig into, including the weighting for handling a punch as well dynamically generating arcs based on the position of the fist to the shoulder. However, for this experience, the User Console serves as a secondary display to support the playing experience and gives both the player and audience a visual anchor for the game.

Making a 700lb Tank Drive like a First Person Shooter

The character in a first person shooter (FPS) video game has an X position, a Y position, and a rotation vector. On an Xbox controller, the left stick controls the X,Y position. Y is the throttle (forward and backward), X is the strafing amount (left and right), and the right thumb stick moves the camera to change what you're looking at (rotation).  When all three are combined, the character can do things such as run around someone while looking at them.

In the prior project, we had existing code that worked for controlling all 4 motors at the same time, working much like a tank does, so we only had throttle (forward and back) and strafing (left and right). Accordingly, we can move the motors in all directions, but there are still scenarios in which the wheels fight one another and the base won't move. By moving to a FPS style, we eliminate the ability to move the wheels in an non-productive way and actually make it a lot easier to drive.

Note that Clint had some wiring "quirks" with polarity and which motor was left VS right, he had to correct in these quirks in software :

public Speed CalculateSpeed(double throttleVector, double strafeVector, double rotationAngle)
{
    rotationAngle = VerifyLegalValues(rotationAngle);
    rotationAngle = AdjustValueForDeadzone(rotationAngle, AllowedRotationAngle, _negatedAllowedRotationAngle);

    // flipped wiring, easy fix is here  
    throttleVector *= -1;
    rotationAngle *= -1;
    
    // miss wired, had to flip throttle and straff for calc
    return CalculateSpeed(strafeVector + rotationAngle, throttleVector, strafeVector - rotationAngle, throttleVector);
}

protected Speed CalculateSpeed(double leftSideThrottle, double leftSideVectorMultiplier, double rightSideThrottle, double rightSideVectorMultiplier) 
{ /* code from Jellybean */ }

Conclusion

The Boxing Bots project was one of the biggest things we have built to date. It was also one of our most successful projects. Though it was a rainy, cold day and night in Austin when the bots were revealed, and we had to move locations several times during setup to ensure the bots and computers wouldn't be fried by the rain, they ran flawlessly for the entire event and contestants seemed to have a lot of fun driving them.

Awesome job Don and thanks for telling us about it! 

Update:  Don has shared his sequence file with us!

Getting Started

I'll start with the Hardware and then move on to the main application and engines that run the robotics.

To get started, all you need are the parts and software listed above, and some basic DIY skills. I found my parts at many different places, one of the best of which was Trossen Robotics (which also has a great forum site). I found automotive relays and wiring harnesses at All Electronics website, cheap Power Wheels ($15) at garage sales, and additional parts at the local junk yard.

If your Power Wheels car is in need of repairs, check out the Modified Power Wheels website for more info.

The video below shows pictures I started taking on the first day—they continue all the way through the prototyping life cycle.

Hardware

Modifying the Cars

To modify the car, I removed all the existing controls from my Power Wheels Barbie Jeeps and wired their rear motors together. (Keep in mind that in order for the car to go forward or in reverse, the wires on ONE of the motors has to be reversed. Otherwise, when you connect the two red wires together and the two blue ones together and give it power, one wheel will spin forward while the other one spins backwards.)

Next, I attached the motors to a set of automotive relays, forming a DPDT switch. This was in turn connected to a Phidgets four relay board. Two of the Phidgets relays will control the transmission.

For the steering, I used the tracks from an electric car seat to move the tires from right to left. Any 12 volt electric car seat should work—you can get them at an auto salvage yard, usually at a reasonable price. You could also use an old cordless drill, as seen here.

Note that you'll have to modify your car for the steering unit. To do this, I fitted a 2x4 into the front section of the car. On the board, I screwed in the seat track, giving it something solid to sit on.

The wiring for the steering motor was the same as the transmission, except I needed to add limiting switches to keep the tires from going too far left or right. I tied these to the automotive relays. Then, I wired the relays for steering to the Phidgets 4 relay board. (See wiring diagram. Or, for more on automotive relay, see here.)

I had two different versions of the jeeps and my process was a little different each time, so you might have a little trial and error to find the right fit for the car.

The plastic and drywall screws work great to hold everything in place but you might have a few extra screw holes when you're finished. I call that “character”.

Also, relays and motors can cause EMI noise. For ways to control it, read this.

You can now drive the car forward, reverse, left and right. To test this, try running the Phidgets test program or use my code. For a Phidgets test, right click on the Phidgets item in the tray on your computer. Then, select the 004 device and right click to bring up a screen that lets you manually control the device.

Remember to NEVER turn on both relays to transmission or steering at same time, or you will blow your motors, Phidgets and possibly the USB port to your computer. You can turn on one from steering and one from transmission—just turn them off before you switch to the other relays. My program does all of this for you. (The Phidgets driver also does all this for you, but beware: it gives you total control, so you can turn all relays on at once. As mentioned, this would cause bad things to happen.)

Adding a Gun Turret

To control the gun, we'll use three more Phidgets devices: the 888 interface IO board, the voltage board, and dual relay daughter boards. The voltage board will tell the 888 board when it sees a voltage spike, which happens when one gun hits another. The dual relay board acts like a simple switch; it fires the gun and allows it to reload ammo.

To aim the gun and move it from right to left, we'll use the Phidgets servo controller. As a cheaper option, you could replace the laser tag guns with just about anything else. (In a prior version, for example, I used only a relay and was able to shoot water from a windshield washer pump by using the relay as a switch and turning the power to the pump on and off.) We now have our hardware in place.

The gun is mounted in a holster that can be turned by the servo. I used the “lazy Susan” concept, the same as what most people have in their houses. I made a wooden box that the gun fits in and mounted it on a ball bearing swivel. The servo is mounted directly below it, and everything is control from the Xbox controller (you can buy them from Sparkfun.com). It's now time to control the car with the computer.

Computers

I used Asus EeePCs models 904 and 1000HE, but any computer with XP or newer installed on it will work. You can pick up a used Netbook (a great and cheap option for robotics) from EBay for little to nothing—I recently bought one that had a 32GB SSD and the 1.6 GHz Atom processor for $250. If possible, get one with a shock-resistant SSD drive. The ones we used at PDC all had standard hard drives and worked fine, but you have to watch for hard hits, which can damage the hard drives.

Controller Application

First, I have to give credit Joel Ivory Johnson, whose article and sample will make understanding the controller code much easier. His sample is also great for testing functionality and making sure the drivers are working properly for the Xbox 360 controller.

The main controller app is a simple program: an action happens (a button pushed, joystick moved, etc). Then, a call is made to the proper method. Finally, the method fires off a message to its queue and goes back to waiting for the next action (fire and forget). I created two methods: “Drivecar” and “GunControl”. The names pretty much tell you what's going to happen.

In addition to the two main functions, there are two timer events. One controls the main loop; the other allows feedback to be given back to the main program. The feedback can come from any of the engines, or from the scoreboard. I use the feedback timer to supply the players' vibrations to their controllers when they get hit. I also use it for beginning and ending a game.

I used Microsoft message queue to send messages from the application to the different engines.

So to summarize: I have feedback, 888 IO interface, servo, and relay interface queues that are installed on each Netbook. The queues operate on their own; we'll discuss them more below.

I have 3 cars and 3 computers (you could use more or less). I can bring on more cars or switch the computers around to different cars. I do this by using the DNS name of the computer and syncing it up with a configuration file. The engines will pull all their configuration data in from this file. Below is an example of one of the nodes, along with the code I use to read the node:

<Car>    
    <carnumber>TimCar2</carnumber>
    <relaycar>FormatName:DIRECT=OS:timcar2\private$\relaycar</relaycar>
    <servocar>FormatName:DIRECT=OS:timcar2\private$\servocar</servocar>
    <interface888>FormatName:DIRECT=OS:timcar2\private$\interface888</interface888>
    <feedback>FormatName:DIRECT=OS:timcar2\private$\feedback</feedback>
    <ok2reload>Y</ok2reload>
    <relayserialnum>8694</relayserialnum>
    <serialnum888>30448</serialnum888>
    <servoserialnum>88630</servoserialnum>
    <scorecard>FormatName:DIRECT=OS:timcar3\private$\scorecard</scorecard>
    <scorecardnolimit>False</scorecardnolimit>
    <scorecardnolimittime>1800</scorecardnolimittime>
</Car>

Each node (Car) has a “Carnumber” that's equal to the DNS name of the computer. The other information you see is the location of the private queues, the serial numbers of the different Phidgets devices, and some additional configuration data on how the game operates. The file is in XML format and the values are read in with the following code:

ProjectUtils.Utilities x = new ProjectUtils.Utilities();

whatcar = System.Net.Dns.GetHostName();
scorecard = x.ReadXMLFile4CarElementValue("c:\\deploy\\carconfig.xml", whatcar, "scorecard");
relaycar1 = x.ReadXMLFile4CarElementValue("c:\\deploy\\carconfig.xml", whatcar, "relaycar");
servocar1 = x.ReadXMLFile4CarElementValue("c:\\deploy\\carconfig.xml", whatcar, "servocar");
interface888car1 = x.ReadXMLFile4CarElementValue("c:\\deploy\\carconfig.xml", whatcar, "interface888");
feedbackque1 = x.ReadXMLFile4CarElementValue("c:\\deploy\\carconfig.xml", whatcar, "feedback");

Another function of the controller program is to determine how many players (1 or 2) are attached to this receiver. If there are two players, player 1 will be the driver and player 2 will be the gunner. If there is only one player, he will need to press the “A” button to switch back and forth between the different modes of play, since it's not safe to drive and shoot at the same time.

if (this.gamePadState1.IsConnected == true)
{
    player1active = true;
    numberOfPlayers++;

    //what if only one player let them choose if they want to be in driver or
    // gunner mode
    if (this.gamePadState2.IsConnected == false)
    {
        if (!this.gamePadState1.Buttons.Equals(this.previousState1.Buttons))
        {
            if (this.gamePadState1.Buttons.A == Input.ButtonState.Pressed)
            {
                if (player1Driver == true)
                {
                    player1Driver = false;
                    lbT1Player1.Text = "Gunner";
                }
                else
                {
                    player1Driver = true;
                    lbT1Player1.Text = "Driver";
                }
            }

        }
    }

}
else
{
    lbT1Player1.Text = "Not Connected";
    player1active = false;
}

if (player1active == true)
{
    if (player1Driver == true)
    {
        lbT1Player1.Text = "Driver";
        DriveCar(gamePadState1, previousState1, 1);
        PlayRadio(gamePadState1, previousState1, 1);
    }
    else
    {
        lbT1Player1.Text = "Gunner";
        GunControl(gamePadState1, previousState1, 2);
    }
}

if (this.gamePadState2.IsConnected == true)
{
    player2active = true;
    numberOfPlayers++;
    GunControl(gamePadState2, previousState2, 2);
    lbT1Player2.Text = "Connected";
}
else
{
    lbT1Player2.Text = "Not Connected";
    player2active = false;
}

In XNA programming for the Xbox controller, there are previous and current states. For the most part I care only about the current state of the controller, but I do use the previous state to see if the button or joystick has moved between the last loop and the current loop. The loops happen every 100 milliseconds for the main loop (10 times a second, 1000 milliseconds = 1 second).

Below is the code for the “DriveCar” function. As you can see, it's pretty straightforward—I simply pass in the previous and current states of the game controller. For steering, I interrogate the state of the right joystick. If it's a different value than the last time we were here, I send a message to the “InterfaceIO” (004 Phidgets interface board) message queue, passing the current state value of the joystick. The drive engine will take the value and determine the action. The transmission is handled the same way, except that we check the left joystick.

private void DriveCar(GamePadState gameController, GamePadState prevState, int player)
{
    //either player 1 or 2 will send their current GamePadState
    int xStickCurrent;
    int xStickPrev;
    int yStickCurrent;
    int yStickPrev;
    string steerPos = "";

    if (allstop == false)
    {
        //Steering
        xStickCurrent = (int)((gameController.ThumbSticks.Right.X + 1.0f) * 100.0f / 2.0f);
        xStickPrev = (int)((prevState.ThumbSticks.Right.X + 1.0f) * 100.0f / 2.0f);

        steerPos = xStickCurrent.ToString();

        if (xStickCurrent != xStickPrev)
        {
            queueCount++;
            //6 = servo number , steerPos = joystick position
            listBox1.Items.Add("steering" + steerPos);
            qM.SendMsgNoTransaction(3, "3" + steerPos, relaycar1);
            xStickPrev = xStickCurrent;
        }

        //Transmission
        //0-49(backward) 51- 100(forward) 50 = Neutral

        yStickCurrent = (int)((gameController.ThumbSticks.Left.Y + 1.0f) * 100.0f / 2.0f);
        yStickPrev = (int)((prevState.ThumbSticks.Left.Y + 1.0f) * 100.0f / 2.0f);

        if (yStickCurrent != yStickPrev)
        {
            queueCount++;
            listBox1.Items.Add("transmission " + yStickCurrent.ToString());
            qM.SendMsgNoTransaction(3, "4" + yStickCurrent.ToString(), relaycar1);
            yStickPrev = yStickCurrent;
        }
    }
    else
    {
        //we are in all stop do not allow any sends to car...
        //if we have not sent all stop to relay engine do it..
        if (sentallstop == false)
        {
            sentallstop = true;
            //tell transmission to go to neutral
            qM.SendMsgNoTransaction(3, "450", relaycar1);
        }
    }
}

Each of the queue engines (feedback, drivetrain, 888interface) is set up pretty much the same way. The “Main” function sets up the Phidgets device it will control. It then goes into an endless loop until you cancel the program. In the loop, it checks the Message queue for any new messages and calls the proper function based on the content of the message. Then, it gives the processor back to the computer via the do events call while it waits for the next message.

Below is the “Main” function from the drivetrain queue engine. It sets itself up based on the configuration file and creates the events that the Phidgets devices require. The code then enters its loop and waits for messages to process.

static void Main(string[] args)
{
    whatcar = System.Net.Dns.GetHostName();
    relaycar = projectUtils.ReadXMLFile4CarElementValue("c:\\deploy\\carconfig.xml", whatcar, "relaycar");
    ioboardserialnum = projectUtils.ReadXMLFile4CarElementValue("c:\\deploy\\carconfig.xml", whatcar, "relayserialnum");

    //write to the console what is happening, useful for debugging
    Console.WriteLine("Configured Car number - " + whatcar + "\r\n");
    Console.WriteLine("Configured Relay serial number - " + ioboardserialnum + "\r\n");

    //Wiring up the Phidgets devices with their events
    ifKit = new InterfaceKit();

    ifKit.Attach += new AttachEventHandler(ifKit_Attach);
    ifKit.Detach += new DetachEventHandler(ifKit_Detach);
    ifKit.Error += new ErrorEventHandler(ifKit_Error);

    ifKit.InputChange += new InputChangeEventHandler(ifKit_InputChange);
    ifKit.OutputChange += new OutputChangeEventHandler(ifKit_OutputChange);
    ifKit.SensorChange += new SensorChangeEventHandler(ifKit_SensorChange);

    ifKit.open(int.Parse(ioboardserialnum));

    while (true)
    {
        try
        {
            // get the message from the message queue 
            o = qM.PullMsg(relaycar);

            //body will have for servo 1 to 7 rest of string is position to move too.
            if (o != null && o.QueMsgBody != "")
            {
                mycount++;
                Console.WriteLine("process body and count " + o.QueMsgBody + "  " + mycount.ToString() + "\r\n");
                inputDeviceNum = Int32.Parse(o.QueMsgBody.Substring(0, 1));
                msgMainBody = int.Parse(o.QueMsgBody.Substring(1));

                switch (inputDeviceNum)
                {
                    case 3:
                        steering(msgMainBody);
                        break;
                    case 4:
                        transmission(msgMainBody);
                        break;
                }
            }
            else
            {
                Console.WriteLine("null or 0 length queue message" + "\r\n");
            }

            Application.DoEvents();
            Thread.Sleep(100);
        }
        catch (Exception ex)
        {
            projectUtils.WriteEventToApplicationLog("PhidgetsIO", "Main -> " + ex.ToString());
        }
    }
}

This snippet of code is the “transmission” function, which allows the car to move forward, in reverse or stop. This is where I determine what action I need to do based on the joystick's position.

private static void transmission(int myPos)
{
    try
    {
        if (myPos < 20)
        {
            myMsg = "Moving transmission to => Reverse";
            currentSteerPos = "R";
        }
        else if (myPos > 80)
        {
            myMsg = "Moving transmission in Forward";
            currentSteerPos = "F";
        }
        // giving most range from the joystick to stop the car, being safe
        else
        {
            myMsg = "Moving Transmission to =>  Neutral";
            currentSteerPos = "N";
        }

        Console.WriteLine(myMsg + "\r\n");
        //first stop motor, then wait  and finally do new command.
       // we stop only long enough for the electricity to stop energising the relay
        //since we are turning both relays to off (false) that is the same as Neutral so we
        //do not need to check for it.

        if (ifKit.Attached == true)
        {
            //set relay 3 to not be engerized, relays start with 0 base count
            ifKit.outputs[2] = false;
            Thread.Sleep(20);
        }

        if (ifKit.Attached == true)
        {
            //set relay 3 to not be engerized, relays start with 0 base count
            ifKit.outputs[3] = false;
            Thread.Sleep(20);
        }

        if (currentSteerPos == "F")
        {
            if (ifKit.Attached == true)
            {
                // turn on relays to power motors forward
                ifKit.outputs[2] = true;
            }
        }
        else if (currentSteerPos == "R")
        {
            // turn on relays to power motors reverse
            if (ifKit.Attached == true)
            {
                ifKit.outputs[3] = true;
            }
        }
    }
    catch (Exception ex)
    {
        projectUtils.WriteEventToApplicationLog("PhidgesIO", "Transmission -> " + ex.ToString());
    }
}

Notes

First, remember to always turn off relays before changing direction, so you never have both relays running at the same time.

Also, there is more code in the “main” function (instead of in a timer routine) because of performance issues. When I created a timer and added all the code to the event, the processor showed like it was redlined at 100%. When I put the “do events” in the timer event everything worked fine, but it still looked like the process was redlined. However, when I moved everything into the “Main “ function and added a “do events”, everything worked fine and the processor dropped to about 8% usage—even with all of the engines running and the main program processing the Xbox controller commands.

Conclusion

This was a fun project that gave me a better understanding of robotics and C# functionality. Like I said in the beginning, there are many things you could do to make it better and even faster—I simply gave you a starting point. Questions to ponder: Why console apps and not Windows services? Why MSMQ and not WFC?

If you have any questions or thoughts, feel free to ask them here or over at my blog.

About The Author

Tim is an IT Director in the Enterprise Architect Group for Maritz, a sales and marketing services company. He has developed many systems in numerous languages over the years and is currently working with C#. In his off time he enjoys coming up with off the wall ideas and then seeing if he can make them happen. Tim's blog is finally getting started and can be seen at Waterhobo.com where he tries to explain them; he can be emailed at tbh726@gmail.com.