LogicCircuit

Description

LogicCircuit – is educational software for designing and simulating digital logic circuits.
Intuitive graphical user interface, allows you to create unrestricted circuit hierarchy with multi bit buses, debug circuits behavior with oscilloscope, and navigate running circuits hierarchy.

Official Web site

The official web site was created. Please visit it at: http://www.LogicCircuit.org

How does it work? How do you create your own?

Short user guide

There are two modes the program can be in: edit mode and running mode. To switch use power button on the status bar, checkbox on the sliding tool panel on the bottom or use short cut: Ctrl+W.

In edit mode on the left side you can see all available circuits. Just drag and drop them where you want on the diagram – right part of the window. In order to wire circuits just click connector – bold dot on the side of the circuits and then click where you want your wire be extended to. Wires are connected only if their ends are in the same location. If you just cross two wires they are not connected.

By double clicking items on the diagram you can start editing them. So double click on pin, constant, memory, or button will open dialog where you can change properties of the item. Double click symbol of logical circuit you’ve created will switch you to this circuit. To change properties of the entire project select menu Circuit/Project, to change properties of the currently edited logical circuit either double click anywhere in empty space on the diagram or select menu Circuit/Logical Circuit.

In order to select an item on diagram, just click it. To add an item to selection or remove it from - hold Ctrl and click. Press and move mouse you can select everything in marked area. Hold Shift and click wire to select entire conductor. Ctrl+A will select everything on the diagram. Edit menu contains some other useful commands to select and unselect symbols on the circuit diagram.

When you create a new circuit it becomes available for you to use on other circuits.

• Use input and output pins as interface with external circuits.
• Use probes to observe state of the circuits when it is in running mode.

When in running mode you can interact with you circuits through buttons and double clicking constants – which increment value of constant within it bit width.
If you have some probes connected on your circuits you can open oscilloscope and watch history of the states of your probes.

To switch between your circuits you can double click them on the left panel or pressing Ctrl + Tab or Ctrl + Shift + Tab to navigate through circuits in reverse historical order. Press Tab more than once while holding Ctrl to navigate further in the history.

Happy designing!

Logic Circuit - Editing circuits

When you first open LogicCircuit it will be one empty logical circuit visible on the right pane of the program window named "Main".

Following the above getting started guides, I had my first circuit running in seconds.

What can you build with?

I mentioned the source was available? Yep! And the latest check-in ran for me the first time... Here's a snap of the Solution.

That's right, you get all the source behind this cool tool.

If you want to play with building circuits but soldering iron phobia, want to quickly play with some design ideas or are looking for some really interesting code to spelunk, LogicCircuit is a project that's under active development and just a download away...

Kinect-Controlled Chess Playing Robot

As cool as that title was to write, the video is even cooler. This is one of those articles I post simply because of the purely creative and inventive end result of someone's hard work. I doubt the source code will be released any time soon and providing any sort of installation instructions or DIY tutorials is well beyond my skill set.

With that being said, a game of chess between a computer AI isn't anything new. However, controlling the chess piece using natural gestures while having your opponent (who just happens to be a robotic arm) do all "heavy lifting" certainly is.

The user is controlling the chess pieces with the Kinect as seen in the screen above. Once a move is completed, the robot will move the piece on the chess board according to your actions and then plays its own move afterwards. I can't help but wonder if the robot is plotting ways to enslave the human race while still thinking at least 3 moves ahead. Love this stuff!

Project Information URL: http://developkinect.com/news/robotics/playing-chess-using-kinect-controls-versus-robotic-arm

from Vimeo.

Occlusion detection and virtual object manipulation in augmented reality with the Microsoft Kinect

Augmented reality (AR) is limited by how you can interact with the virtual object displayed. Currently, the object can only be moved by moving the AR marker. In this project, we used the Microsoft Kinect sensor to allow one to virtually touch and manipulate the object displayed. In order to do this, we use the skeletal tracking of the sensor to allow the user to rotate and resize the object with his hands. While doing so, the user hands will inevitably get between the virtual object and the camera. To prevent the virtual object from being displayed wrongly over the hand, the depth map of the Kinect is used to find any obstruction and block rendering of pixels under occlusion. This is realized at the GPU level, using modified Shaders. The AR system uses the Unity3D game engine to display the 3D models with a custom plugin created at the CIMMI research center to enable the AR. The plugin computes in real time the pose of the Kinect using the color image while the depth map allow occlusion detection and hands tracking. The plugin was developed with the OpenCV library which allows easy analysis of the images. This work was realized at the CIMMI research center (cimmi.qc.ca) by two interns, Alexis Legare-Julien and Renaud Simard, under the supervision of Jean-Nicolas Ouellet, Ph.D.Eng.

 

Here are some additional details on the project:

It uses the Kinect color image and depth map to achieve augmented reality with occlusion and object manipulation. Without wasting time, here is the link to the demo (April 2012): http://youtu.be/OTmHtAaQD_c 

Now the description:

We work on augmented reality (AR) where a virtual object is added to a live video stream as if it was really part of the scene. Last year, we developed unity3d plugin that is able to create the AR illusion. Basically it grabs the webcam image and computes the camera position wrt. a marker. Unity then only shows the webcam image superimposed with a render of the virtual object from the correct view point. This video shows what it looks like: http://youtu.be/npuubLGpU1A 

Then we wanted to allow the user to manipulate the state of the object, rotate and resize, with his hands. The Kinect is perfect for that, the skeletal tracking measure where the user is relative to the camera (hand, head, etc). While doing so, we were confronted with the occlusion problem. That is, if the hand is closer to the camera than virtual object, the hand must be seen (we must not render the virtual object over the hand). Again, the Kinect measure the distance of everything it sees, the depth map, the z-distance. Similarly, when a video card renders a virtual scene it computes occlusion from the depth buffer, i.e. the z distance of every object in the virtual scene. The occlusion algorithm is then obvious, on the shader clip( z.real < z.virtual). 

Thus, we used the Kinect (with the Microsoft sdk, but any other sdk with skeletal tracking would do) to manage occlusion and manipulate the virtual objects interactively. Rendering is done in Unity3d free, occlusion is managed in a unity shader (this is very fast since computation is done on the graphic card), manipulation is done in Unity3d from skeletal information from the Kinect. 

The biggest problem we faced was speed, transferring the depth map to the shader was time consuming. We had to resize the depth map to 512x512 to allow faster manipulation. While doing so, we were confronted by a new problem; the occlusion clip was highlighting the object contours. So occlusion was correct but when the hand was behind the virtual object we could see through the virtual object at the object boundary. The effect was kind of cool but unwanted. 

After some investigation we found out that opencv was using bilinear interpolation to resize the depth map image. This was creating intermediate values between the background and the object boundaries. Forcing to nearest neighbor interpolation was the solution, but the contours were still there. The shader was interpolating the values when we extracted the depth value from the texture. The coordinates are indexed from 0 to 1 instead of 0 to width (or 0 to height). We had to crop the decimal value of the coordinate to make wure it was falling at the center of the texture pixel to avoid interpolation. While doing so we found out that unity3d is indexing pixels coordinates from the pixel corner, not the center. An offset of 0.5 must be added to the coordinate in the native image range. 

Project Information URL: http://www.youtube.com/watch?v=OTmHtAaQD_c&feature=youtu.be

Use the power of Azure to create your own raytracer

The power available in the cloud is growing every day. So I decided to use this raw CPU power to write a small raytracer.

I’m certainly not the first one to have had this idea as for example Pixar or GreenButton already use Azure to render pictures.

During this article, we will see how to write our own rendering system using Azure in order to be able to realize your own 3D rendered movie.

The article will be organized around the following axis:

1. Prerequisites
2. Architecture
3. Deploying to Azure
4. Defining a scene
5. Web server and workers roles
6. How it works?
7. JavaScript client
8. Conclusion
9. To go further

The final solution can be downloaded here and if you want to see the final result, please go there: http://azureraytracer.cloudapp.net/

To get started there's just a very pre-req's;

Prerequisites

To be able to use the project, you must have:

• a Visual Studio 2010 version (Express version is supported): http://www.microsoft.com/visualstudio/en-us/products/2010-editions
• Windows Azure SDK: http://www.windowsazure.com/en-us/develop/downloads/

You will also need an Azure account. You can get a free one just there: http://www.windowsazure.com/en-us/pricing/free-trial/

What is the big picture of this project?

Architecture

Our architecture can be defined using the following schema:

 

While you can play with the instance David is already running, having your own, where you can tweak it to your hearts content is key. The good news is that this article walks you through all the steps to deploy the solution to your own Azure instance.

Deploying to Azure

After opening the solution, you will be able to launch it directly from Visual Studio inside the Azure Emulator. You will be so able to debug and fine tune your code before sending it to the production stage.

Once you’re ready, you can deploy your package on your Azure account using the following procedure:

• Open the “AzureRaytracer.sln” solution inside Visual Studio
• Configure your Azure account: to do so, right click on the “AzureRaytracer” project and choose “Publish” menu. You will get the following screen:

...

Once he gets you online, he then describes the schema of the XML file he's using to define the scene that the code we draw.

Defining a scene

To define a scene, you have to specify it using an xml file. Here is a sample scene:

The file structure is the following:

• A [scene] tag is used as root tag and allows you to define the following parameters:
  • FogStart / FogEnd : Define the range of the fog from the camera.
  • FogColor : RGB color of the fog
  • ClearColor : Background RGB color
  • AmbientColor : Ambient RGB
• A [objects] tag which contains the objects list
• A [lights] tag which contains the lights list
• A [camera] tag which define the scene camera. It is our point of view, defined by the following parameters:
  • Position : Camera position (X,Y,Z)
  • Target : Camera target (X, Y, Z)

All objects are defined by a name and can be of one of the following type:

• sphere : Sphere defined by its center and radius
• ground : Plane representing the ground defined by its offset from 0 and the direction of its normal
• mesh : Complex object defined by a list of vertices and faces. It can be manipulated with 3 vectors:Position, Rotation and Scaling:

Now that we have our own instance, and a feeling for how scenes are created, next the makeup of the two Azure roles are covered.

Web server and worker roles

The web server is running under ASP.Net and will provide two functionalities:

• Connection to worker roles using the queue in order to launch a rendering:
• Publish a web service to expose requests progress:

...

The WorkingUnit works according to the following algorithm:

• Loading the scene
• Creating the raytracer
• Generating the picture and accessing the bytes array
• When the picture is rendered, we can save it in a blob and we update the job progress state
• Launching the render

...

Finally the raytracer itself is discussed (and remember you get the source too all of this!)

The raytracer

The raytracer is entirely written in C# 4.0 and uses TPL (Task Parallel Libray) to enable parallel code execution.

The following functionalities are supported (but as Yoda said “Obvious is the code”, so do not hesitate to browse the code):

• Fog
• Diffuse
• Ambient
• Transparency
• Reflection
• Refraction
• Shadows
• Complex objects
• Unlimited light sources
• Antialiasing
• Parallel rendering
• Octrees

The interesting point with a raytracer is that it is a massively parallelizable process. Indeed, a raytracer will execute strictly the same code for each pixel of the screen.

...

Let's take a peek at the Solution.

As the article covers, there's three basic parts, the Azure Web, Worker and the raytracer.

What I thought kind of cool is that the raytracer was complete and had no external references at all.

So okay, you don't want to create your own instance, you just want to raytrace stuff? David's got an instance already running which you can play with.

http://azureraytracer.cloudapp.net/

If your interested in raytracing, cloud development or just looking for some interesting code to check out, there's a little for everyone here...

Monster Mixer - Medialogy Aalborg University P2 2012 - Kinect Unity game for dyslexia

Monster Mixer is a game made by students from the 2nd semester of Medialogy, Aalborg University.

TARGET GROUP: Danish kids age 6-8

PROBLEM STATEMENT: How can Kinect be used in order to create a game that reduces the impact of dyslexia by training phonological awareness?

Monster Mixer is a Kinect game developed using Unity game engine. Its purpose is to raise children's phonological awareness and thereby preventing dyslexia that they might develop in the future.

The game uses monsters and nonsense words to train phonological awareness. It requires gestures to catch monsters. The goal is to combine the right monsters into a new monster/sound. Nonsense words are used to make it impossible for the kids to just recognize already-known words.

...

We used the Zigfu Unity wrapper to make Kinect work with the Unity engine.

Project Information URL: http://www.3dbuzz.com/vbforum/showthread.php?192900-Monster-Mixer-a-Unity-Kinect-game-my-university-group-have-made

That's cool, what's even cooler is that this project takes a HTML5 project we've covered before,XNA Platformer, HTML5 Style and using the magic of PhoneGap puts it on Windows Phone...

How to create HTML5 apps on Windows Phone with PhoneGap

We will first see in this article what the added values of PhoneGap for HTML5 applications are. We’ll then discover how to create our very first project where we will retrieve the accelerometer’s values from our JavaScript code. At last, we will review a complete HTML5 gaming sample almost ported as-is to PhoneGap to use the accelerometer available on the Windows Phones.

1. Introduction
2. PhoneGap: a framework filling the gap
3. Let’s create our first PhoneGap project
4. Getting the accelerometer’s values from JavaScript
5. Review of a complete sample with the HTML5 Platformer game
   1. Forcing the landscape orientation
   2. Handling various resolutions
   3. Loading the levels with calls to the file system instead of using XHR
   4. Modification of the gameplay to use the accelerometer
   5. Screenshots of the result and FPS on some phones
   6. Complete Visual Studio Solution to download
6. Conclusion

The article provides a good getting started guide and gets you quickly up and running with PhoneGap. One thing to note is that the PhoneGap project moves very fast. The current version is v1.7.0 and while this article is only a few months old it's on v1.3.0. The good news is that everything pretty much works, no matter the version.

PhoneGap: a framework filling the gap

While waiting on real standardized specifications, we don’t have the choice: we need to create some bridges between JavaScript and the native code of the targeted platform to have access to its capabilities. The idea is then the following one: taking the native languages of each platform (C#, Objective-C and Java) and creating a framework with these languages that will expose interfaces to the JavaScript developer.

This is exactly what PhoneGap is doing. Let’s take the Windows Phone case which is the main topic of this article. A Windows Phone’s PhoneGap project is simply a Silverlight application hosting the WebBrowser control (and thus IE9) as well as a Silverlight Assembly written in C# which does the job to access to the accelerometer, GPS, contacts, camera and so on. In this way, as a JavaScript developer, you will use a DLL named WP7GapClassLib.dll (the PhoneGap core runtime) without even knowing it via the usage of the code embedded in the phonegap-1.3.0.js file. This DLL contains some C# code which does calls to the Silverlight runtime available on the phone. As the runtime has access to all the capabilities of the phone, the JavaScript will do also. The JavaScript library will then act as a gateway between both worlds. Moreover, the good point of using this library is that your code will most of the time works as-is on the PhoneGap versions of Android or iOS. PhoneGap offers then an interesting form of portability.

Please note by the way that the PhoneGap support for Windows Phone is now totally complete since the recent 1.3.0 version:

The article then moves onto a "Hello Phone" app, showing you how to start your first app and how to get started using the accelerometer.

Let’s create our first PhoneGap project

Prerequisites

Here are the very first steps you need to follow:

1. Download the Windows Phone SDK: Windows Phone SDK
2. Download the last version of Phone (1.3.0 today) on their site: http://phonegap.com/
3. Unzip the downloaded file
4. Copy the PhoneGapStarter.zip and PhoneGapCustom.zip files into \Documents\Visual Studio 2010\Templates\ProjectTemplates

File->New project

Once the previous steps are done, you will be able to create your first PhoneGap project. Start Visual Studio 2010, select the "Visual C#" templates and filter them via the "Gap" keyword. You should then see a new type of project named PhoneGapStarter:

...

Getting the accelerometer’s values from JavaScript

We’re going to see here how to get the values sent back by the accelerometer (of the emulator or the real device) in a very simple way.

Open the "index.html" page and change its default body by this one:

...

Then, best of all, starts talking about the port of the HTML Platformer game, including tweaking it to use accelerometer to control the movement (i.e. tilt the phone to the left to run to the left, right to run to the right).

Review of a complete sample with the HTML5 Platformer game

Let’s now review a more complex sample. My idea was to start from the game I’ve written before. It’s exposed in this article: HTML5 Platformer: the complete port of the XNA game to <canvas> with EaselJS . I wanted to see what I should do to make it works on the phone.

First step is to simply copy/paste the different .js, .png, .css files into the "www" directory and to mark them as "Content". Here are the others steps to follow.

...

Complete Visual Studio Solution to download

You’ll find the complete source code of the HTML5 Platformer for PhoneGap here: HTML5GapPlatformer.zip

Other useful resources

• Full Support for PhoneGap on Windows Phone is Now Complete!
• PhoneGap on Windows Phone Tips from Glen Gardon who has written several very interesting tutorials to follow
• Lot of good tutorials in the Wiki section of PhoneGap: http://wiki.phonegap.com/w/page/35501397/Tutorials

Conclusion

PhoneGap offers interesting perspectives to help you writing applications on the phone. It lets you using your existing skills in JavaScript, HTML and CSS. PhoneGap won’t necessary cover all the scenarios currently available with the native development stack (Silverlight or XNA). But this could be something to have a look to if you’d like to capitalize on the HTML skills of one of your team. You will have to pay attention to properly identify the kind of project to work on.

You can also think about mixing both environments to create hybrid experiences: the main branch would be written using "HTML5" and some specific parts into native code. Using this idea, some plug-ins have been created to push a bit further the integration into the Metro UI: PhoneGap Plug-ins for Windows Phone . You’ll find for instance one of them allowing a JavaScript code to update the Tiles.

At last, PhoneGap and HTML5 could allow a relative portability to other platforms… with some limitations. But this is a vast subject with passionate debates that would need a complete dedicated article.

If you're thinking about developing app's for Windows Phone 7, but are also interested in other mobile platforms and are not afraid of HTML5 and JavaScript, then you should check out PhoneGap today...

Here’s a few more links you might find interesting:

• PhoneGap
• XNA Platformer, HTML5 Style
• Simply create a PhoneGap application for Windows Phone 7.5 in Visual Studio 2010

Overview

The external lighting system for Project Detroit is run on a web server on a Netduino Plus, which uses the .NET Micro Framework (NETMF). To get an accelerated start, we leveraged code from the CodePlex project Netduino Helpers to control the AdaFruit LPD8806 LED strip, and the web server base code from the Netduino forums. They have been tweaked slightly for our project.

Controllers, Routes, RESTful oh my!

We wanted the NETMF web server to have the exact same routes as the full-blown REST service layer in Detroit. With compiler conditionals, this allowed the same code to use the same routes on both the full .NET stack and NETMF. Since we couldn't use the ASP.NET MVC framework here, we had to make something close to it.

Controllers

Controllers implement an interface with a method named ExecuteAction. When GetController is called, we return the correct controller but cast as the interface IController. This lets us figure out what controller should be executing the request and continue to work generically in the context of the request connection thread. If new functionality is needed, we create a new controller that inherits from IController and update GetController:

private static void RequestReceived(Request request)
{
    // url comes in as /foo/bar/12345?style=255
    //
     // /CONTROLLER/ACTION/
    //
    // LIGHTING SAMPLE URL: /0/1/?r=255&g=255&b=255&zone=EnumAsInt
    // /0/... 0 = NetduinoControllerType.Lighting
    var validResponse = false;
    try
    {
        Logger.WriteLine("Start: " + request.Url + " at " + DateTime.Now);
        var urlInParts = request.Url.TrimStart(UriPathSeparator).Split(new[] {'?'}, 2);
        string[] uriSubParts = null;
        string[] queryStringSubParts = null;
        if (urlInParts.Length > 0)
            uriSubParts = urlInParts[0].Split(UriPathSeparator);
                
        if (urlInParts.Length > 1)
            queryStringSubParts = urlInParts[1].Split(QueryStringSeparator);
        if (uriSubParts != null && uriSubParts.Length > 1)
        {
            var targetController = GetController(uriSubParts[0]);
            if (targetController != null)
            {
                var action = (uriSubParts.Length >= 2) ? uriSubParts[1] : string.Empty;
                var result = targetController.ExecuteAction(action, queryStringSubParts);
                validResponse = true;
                request.SendResponse(result.ToString());
                Logger.WriteLine("Result: " + result + " from " + request.Url + " at " + DateTime.Now);
            }
        }
        if (!validResponse)
        {
            SendIndexHtml(request);
        }
    }
    catch(Exception ex0)
    {
        Logger.WriteLine(ex0.ToString());
    }
}

Routes, strings and enums on NETMF

NETMF can't parse an enum from a string, which is something that can be done in the full .NET Framework. But what does this actually mean? It means the routes for the NETMF web server are a bit unreadable. Here is the same route but with the parsing issue exposed:

Detroit's REST service route with ASP.NET MVC:
http://…/Lighting/Solid/?zone=all&r=255&g=0&b=0

Detroit's NETMF route:
http://…/0/3/?zone=0&r=255&g=0&b=0

This issue made direct device debugging a bit harder.

Parsing the Action and query string

Parsing the route is broken into two parts. The first is determines what controller to target. For Project Detroit, that meant the lighting system or the rear glass system. Once we know the controller, we still need to parse the query string and action into something more useful:

#if NETMF
private static readonly char[] QueryStringParamSeparator = new[] { '=' };
public static LightingData ParseQueryStringValues(string action, params string[] queryStringParameters)
#else
public static LightingData ParseQueryStringValues(string action, Dictionary<string, object> queryStringParameters)
#endif
{
    var data = new LightingData {LightingZone = LightingZoneType.All, LightingAction = ParseLightingActionType(action)};
#if NETMF
    if (queryStringParameters != null)
    {
        foreach (var queryString in queryStringParameters)
        {
            var valueKey = queryString.Split(QueryStringParamSeparator);
            if (valueKey.Length != 2)
                continue;
            var key = valueKey[0];
            var value = valueKey[1];
#else
        foreach(var key in queryStringParameters.Keys)
        {
            var value = queryStringParameters[key].ToString();
#endif
            switch (key.ToLower())
            {
                case ZoneHuman:
                case ZoneComputer:
                    data.LightingZone = ParseLightingZoneType(value);
                    break;
                // more stuff
            }
        }
#if NETMF
    }
#endif
    // more stuff
            
    return data;
}

Turning on the lights

Individually addressable LED strips allow us to tell each individual LED what color to be. To adjust the colors of the LED lights, we loop through all the LEDs, set their color value, and then call LedRefresh() on our LED strip. There's no need to set all of them, only the ones being updated:

private static void SolidAnimationWorker()
{
    var leds = GetLedsToIlluminate();
    var dataCopy = _data;
    for (var i = 0; i < leds.Length; i++)
        SetLed(leds[i], dataCopy.Red, dataCopy.Green, dataCopy.Blue);
    LedRefresh();
}

Zones / Animation Threads

A solid color is boring, but we can use procedural animations to add some flair. The current code supports the following animations:

• Solid - A single solid color.
• Fill - Goes from black to the desired color. The color stays lit. Much like filling a glass of liquid.
• Random - LEDs are set to a random value.
• Pulse - A glowing effect from bright to black.
• Snake - A one way lighting effect with a fading tail that moves left to right.
• Sweep - This effect was inspired by KITT and a Cylon robot and is similar to a snake pattern. The effect can also handle being split in two while maintaining a continual line for items such as the grill or the wheels.
• Police - Each side flashes a red and blue light.

Since we know the LED strip is a single strand, we can be clever with offsets and create groupings. By having a dedicated animation thread in each zone, we can have the grill of the car in Police Mode while the bottom fades to red and the vents fill to blue at different refresh rates.

To run an animation, we need to first kill the old animation thread, spin up a new thread, mark LEDs in the "All LED" zone as do not touch, and execute the new pattern. Without a way to mark the LEDs as "bad" in the "All" zone, the two animation threads would compete for setting the color and result in a flickering effect. Other zones don't have to worry about this since there is zero overlap of LEDs: 

public bool ExecuteAction(string action, params string[] queryStringParameters)
{
    var data = LightingDataHelper.ParseQueryStringValues(action, queryStringParameters);
            
    SignalToEndAnimationThread(data.LightingZone);
    int counter = 0;
    while (counter++ < 5 && IsThreadAlive(data.LightingZone))
        Thread.Sleep(10);
    if (IsThreadAlive(data.LightingZone))
        AbortAnimationThread(data.LightingZone);
    // moving data bucket into public so new threads can leverage it
    _data = data;
    if (_data.LightingAction == LightingActionType.Police || _data.LightingAction == LightingActionType.Sweep)
    {
        _data.LightingZone = LightingZoneType.Grill;
        if (IsThreadAlive(_data.LightingZone))
            AbortAnimationThread(_data.LightingZone);
    }
    // cleaning up just incase
    if (data.LightingZone != LightingZoneType.All)
    {
        for (var i = 0; i < _zoneAllAnimation.Length; i++)
        {
            var leds = GetLedsToIlluminate();
            for (var z = 0; z < leds.Length; z++)
            {
                // flagging item as bad in animation lib
                if (_zoneAllAnimation[i] == leds[z])
                    _zoneAllAnimation[i] = -1;
            }
        }
    }
    switch (_data.LightingAction)
    {
        case LightingActionType.Solid:
            Debug.Print("Solid");
            ExecuteThread(SolidAnimationWorker);
            break;
        // more patterns
    }
    return true;
}

We can now do something more interesting, like Police Mode:

private static void PoliceModeAnimationWorker()
{
    var leds = GetLedsToIlluminate();
    var dataCopy = _data;
    var length = leds.Length;
    var half = length / 2;
    var index = 0;
    while (IsThreadSignaledToBeAlive(dataCopy.LightingZone))
    {
        int redIntensity = (index == 0) ? 255 : 0;
        int blueIntensity = (index == 0) ? 0 : 255;
        for (var i = 0; i < half; i++)
            SetLed(leds[i], redIntensity, 0, 0);
        for (var i = half; i < length; i++)
            SetLed(leds[i], 0, 0, blueIntensity);
        LedRefresh();
        index++;
        index %= 2;
        Thread.Sleep(100);
    }
}

Improvements

Hindsight is 20/20. Nothing is ever perfect and there are of course items we'd love to change. At the start, the goal was to make this fairly generic and not Project Detroit "aware." As you can see by looking at the source, that wasn't accomplished due to time constraints.

We would use a different LED system for two reasons: data transfer speed and power. The longer the LED strip is, the longer it takes to address an item further down the line. Project Detroit, having 15 meters of lighting in it, was impacted by this issue. It works well, just not as well as we hoped. The voltage requirements of the LEDs are another consideration. They are 5V, while a car uses 12V. Had we used 12V LEDs, our wiring would have been far simpler and wouldn't have required multiple transformers to get the required amperage needed at the correct voltage.

Conclusion

We think the lighting solution, coupled with the time and material constraints, worked out pretty well.  Project Detroit was a ton of fun to build out and working with West Coast Customs was the chance of a lifetime.

Key Design Decisions

It’s important to keep in mind that this car was built for a TV show with a set schedule. As a result, there are a number of unique design decisions that came into play.

Schedule

Working backwards, the reveal for the car was set for Monday November 28, 2011 at the Microsoft Store in Bellevue, Washington. We started the project in early August, which gave us approximately 12 weeks for research, development, vehicle assembly, and testing. This was by far the #1 design decision as any ideas or features for the car had to be implemented by the reveal date.

Off the Shelf Parts

Another key design decision was to, where possible, use off-the-shelf hardware and software in order to allow  interested developers to build and reuse some of the subsystems for their own car (at least the ones that don’t require welding). For example, instead of buying pricey custom sized displays for the instrument cluster or passenger display, we used stock Samsung Series 7 Slate PCs and had West Coast Customs do the hard work of building a custom dash to hold the PC.

Hardware and Networking

The car is packed with a variety of computers and networking hardware.

• Instrument Cluster Slate – This slate is on the driver's side and manages the instrument cluster application and the On-Board Diagnostic (OBD) connection to read telemetry data from the car.
• Passenger Slate – This slate, which is built into the passenger's side, runs a custom Windows 8 application (see Passenger slate below).
  
• Laptop 1 – This laptop runs the REST service to control different parts of the car, the Kinect socket service for the front Kinect, and the user message service to display messages on the rear glass while driving.
• Laptop 2 – This laptop runs the Heads Up Display (HUD) service, the Kinect socket service for the back Kinect, the OBD-II database, and Azure services.
• Windows Phone – A Nokia Lumia 800 connects via WiFi and a custom Windows Phone 7 application (See Windows Phone application below).
• Xbox 360 – The Xbox 360 displays on either the passenger HUD or the rear glass display.
• Networking – A NETGEAR N600/WNDR3700 wireless router provides wired and wireless access for everything in the car, which is used in conjunction with a Verizon USB network card plugged into a Cradle Point MBR900 to provide an always-on 3G/4G LTE internet connection. The slates, laptops, and Xbox 360 are connected via CAT5e cable, while the Windows Phone 7 connects via WiFi.

Note: One of the limitations of the Kinect SDK is that if you have multiple Kinects plugged into one PC, only one of those Kinects can do skeletal tracking at a time (color/depth data works just fine). Because of this, we decided to have a dedicated laptop plugged into the front Kinect and another laptop plugged into the back Kinect in order to allow front and back skeletal tracking at the same time. If we'd not used simultaneous skeletal tracking, we could have combined all of the systems onto a single laptop.

Architecture

Here is a quick overview of the application architecture.

REST Service Layer

The REST Service Layer allowed different systems talk to one another. More importantly, it allowed different services to control hardware they normally wouldn't be able to access.

1. Thin client approach
   The solution we chose was to have all the services that control different parts of the car reside on the laptops and have client applications like the Windows Phone application send REST commands to execute an action so the service layer would execute the request.
   
   
2. REST-enable hardware
   Controlling hardware should be invisible to the consuming clients. For example, hardware that requires USB communication would be impossible to control with a Windows Phone. The service layer allowed us to control hardware in a way that was invisible to the end user.
   
   
3. Helper Libraries
   To simplify communication with the service layer, we built a set of helper classes to abstract out repetitive tasks like JSON serialization/deserialization, URI building, etc. For example, to get the list of car horn “ringtones”, the client application can call HornClient.List() to get back a list of available ringtone filenames. To set the car horn, the client calls HornClient.Set(filename), and to play the car horn, it then calls HornClient.Play(filename). The Helper libraries were built to work on Windows 7, Windows 8, and Windows Phone 7.

OBD-II

We have already released an article and library on the OBD-II portion of the car.  In short, OBD-II stands for On-Board Diagnostics. Hooking into this port allows one to query for different types of data from the car, which we use to get the current speed, RPMs, fuel level, etc. for display in the Instrument Cluster and other locations. OBD can do far more than this, but it's all we needed for our project. Please see the linked articles for further details on the OBD-II library itself.

For the car, because only one application can open and communicate with a serial port at one time, we created a WCF service that polls the OBD-II data from the car and GPS data from a Microsoft Streets & Trips GPS locator, and returns it to any application that queries the service.

For the OBD library, we used a manual connection to poll different values at different intervals. For values critical to driving the car—like RPM, speed, etc.—we polled for the values as quickly as the car could return them. With other values that weren’t critical to driving the car—like the fuel level, engine coolant temperature, etc.—we polled at a 1-2 second interval. For GPS, we subscribed to the LocationChanged event, which would fire when the GPS values changed.

Rather than creating a new serial port connection for every WCF request for OBD data, we created a singleton service that is instantiated when the service first runs. Accordingly, there is only one object in the WCF service that represents the last OBD and GPS data returned, which is obtained by the continual reading of the latest OBD data using the OBD library as described above. This means that calls to the WCF service ReadMeasurement method didn’t actually compute anything, but instead serialized the last saved data and returned it via the WCF service.

Since WCF supports multiple protocols, we implemented HTTP and TCP and ensured that any WCF service options we chose worked on Windows Phone, which, for example, can only use basic HTTP bindings.

To enable the ability to change the programming model later and to simplify the polling of the service, we built a helper library for Windows and Windows Phone that abstracts all the WCF calls.

The code below creates a new ObdService class and signs up for an event when the measurement has changed. The Start method does a couple of things: it lets you set the interval that you want to poll the ObdService, in this case every second (while the instrument cluster needs fast polling, the database logger can poll once a second). It also determines what IP address the service is hosted at (localhost), the protocol (HTTP or TCP), and whether to send “demo mode” data. Since one of the main ways the car is showcased is when it’s stopped on display, “demo mode” sends fake data, instead of always returning 0's for MPH, RPM, etc., so people can see what the instrument cluster would look like in action.

_service = new ObdService();
_service.ObdMeasurementChanged += service_ObdMeasurementChanged;
_service.Start(new TimeSpan(0, 0, 0, 0, 1000), localhost, Protocol.Http, false);

void service_ObdMeasurementChanged(object sender, ObdMeasurementChangedEventArgs e)
{
  Debug.Writeline("MPH=” + e.Measurement.MilesPerHour);
}

OBD-II Database & Azure Services

To record and capture the car telemetry data like MPH, RPM, engine load, and throttle (accelerator) position, as well as location data (latitude, longitude, altitude, and course), we used a SQL Server Express database with a simple, flat Entity Framework model, shown below. The primary key, the ObdMeasurementID is a GUID that is returned via the ObdService.  Just like above, the database logger subscribes to the ObdMeasurementChanged event and receives a new reading at the time interval set in the Start() method.

The Windows Azure data model uses Azure Table Services instead of SQL Server. The data mapping is essentially the same since both have a flat schema.

For Azure Table Storage, in addition to the schema above, you also need a partition key and a row key. For the partition key, we used a custom TripID (GUID) to represent a Trip. When the car is turned on/off a new TripID is created. That way we could group all measurements for that particular trip and do calculations based on that trip, like the average miles per gallon, distance traveled, fastest speed, etc. For the row key, we used a DateTimeOffset and a custom extension method, ToEndOfDays() that provides a unique numerical string (since Azure's row key is a string type) that subtracts the time from the DateTime.Max value. The result is that the earlier a DateTime value, the larger the number.

Example:

Time=5/11/2012 9:14:09 AM, EndOfDays=2520655479509478223 //larger
Time=5/11/2012 9:14:11 AM, EndOfDays=2520655479482804811 //smaller

Since they are ordered in reverse order, with the most recent date/time being the first row, we can write an efficient query to pull just the first row to get the current latitude/longitude without needing to scan the entire table for the last measurment.

public override string RowKey
{
    get
    {
        return new DateTimeOffset(TimeStamp).ToEndOfDays();
    }
    set
    {
        //do nothing
    }
}

public static class DateTimeExtensions
{
  public static string ToEndOfDays(this DateTimeOffset source)
  {  
    TimeSpan timeUntilTheEnd = DateTimeOffset.MaxValue.Subtract(source);
    return timeUntilTheEnd.Ticks.ToString();
  }

  public static DateTimeOffset FromEndOfDays(this String daysToEnd)
  {
    TimeSpan timeFromTheEnd = newTimeSpan(Int64.Parse(daysToEnd));
    DateTimeOffset source = DateTimeOffset.MaxValue.Date.Subtract(timeFromTheEnd);
    return source;
  }
}

To upload data to Azure, we used a timer-based background uploader that would check to see if there was an internet connection, and then filter and upload all of the local SQL Express rows that had not been submitted to Azure using the Submitted boolean database field. On the Azure side, we used an ASP.NET MVC controller to submit data. The controller deserializes the data into a List<MeasurementForTransfer> type, it adds the data to a blob, and adds the blob to a queue as shown below.

A worker role (or many) will then read items off the queue and the new OBD measurement rows are placed into Azure Table Storage.

public ActionResult PostData()
{
    try
    {
        StreamReader incomingData = new StreamReader(HttpContext.Request.InputStream);

        string data = incomingData.ReadToEnd();
        JavaScriptSerializer oSerializer =
            new JavaScriptSerializer();

        List<MeasurementForTransfer> measurements;
        measurements = oSerializer.Deserialize(data, typeof(List<MeasurementForTransfer>)) as List<MeasurementForTransfer>;

        if (measurements != null)
        {
            CloudBlob blob = _blob.UploadStringToIncoming(data);
            _queue.PushMessageToPostQueue(blob.Uri.ToString());
            return new HttpStatusCodeResult(200);
        }
        ...
    }
}

Instrument Cluster

Much of this is also covered in our previously released OBD-II library where the instrument cluster application is included as a sample. This is a WPF application that runs on a Windows 7 slate. It contains three different skins designed by 352 Media—a 2012 Mustang dashboard, a 1967 Mustang dashboard, and a Metro-style dashboard—each of which can be "swiped" through. This application queries the OBD-II WCF service described above as quickly as it can to retrieve speed, RPM, fuel level, and other data for display to the driver. The gauges are updated in real-time just as a real dashboard instrument cluster would behave.

HUD

The HUD (or Heads Up Display) application runs on one of the two Windows 7 computers in the car. This is a full-screen application that is output via a projector to a series of mirrors and a projection screen. This is then reflected onto the front glass of the windshield of the car. To install these, we altered the physical car's body and created brackets to mount mirrors and the projectors. In the picture on the left, you can see the dashboard's structural member pivoted outward. You can see the 12" section we removed and added in the base plate to allow light to be reflected through to the windshield. Bill Steele helped design and implement the physical HUD aspect into the car.

The HUD application has several different modes.  The mode is selected from the Windows Phone application.

• POI / Mapping – This uses Bing Maps services. The phone or Windows 8 passenger application can choose one of a select group of categories (Eat, Entertain, Shop, Gas). Once selected, the REST service layer is contacted and the current choice is persisted. The HUD is constantly polling the service to know what the current category is, and when it changes, the HUD switches to an overhead map display with the closest locations of that category displayed, along with your always updated current GPS position and direction. The list of closest items in the category is requested every few seconds from the Bing Maps API and the map is updated appropriately.
  
• Car telemetry - In the car telemetry mode, the OBD data from the WCF service described above is queried and displayed on the screen.  This can be though of as an overall car "status" display with the speed, RPMs, real-time MPG, time, and weather information.
• Weather – We use the World Weather Online API to get weather data for display on the HUD. This API allows queries for weather based on a latitude and longitude, which we have at all times. A quick call to the service gives us the current temperature and a general weather forecast, which we display as an icon next to the temperature in the lower-left portion of the screen.
  
• Kinect – Using our Kinect Service, with the standard WPF client code, we can display the rear camera on the HUD to help the driver when backing up. See the Kinect Service project for more information on how this works and to use the service in an application of your own.

Windows Phone Application

One of the main ways to control the vehicle is through the Windows Phone application. 

The first pivot of the app allows the user to lock, unlock, start the car, and set off the alarm.  This is done through the Viper product from Directed Electronics.

The second pivot contains the remaining ways that a user can interact with the car.

• Kinect – This uses the Kinect service much in the way the HUD does. It can display both the front and rear cameras as well as allow the user to listen to an audio clip and send it up to the car while applying a voice changing effect.
  
• Voice Effect – When the Talk button is pressed, the user can record their voice via the microphone. When released, the audio data is packaged in a simple WAV file and uploaded to the REST service. The user can select from several voice effects, such as Chipmunk and Deep. On the service side, that WAV file is modified with the selected effect and then played through the PA system. The code in this section of the app is very similar to the Coding4Fun Skype Voice Changer. We use NAudio and several pre-made effects to process the WAV file for play.
• Lighting – This controls the external lighting for the car. The user can select a zone, an animation, and a color to apply. Once selected, this is communicated through the REST service to the lighting controller.
  
• Messaging – This presents a list of known pictures and videos for the user. The selection is sent to the car through the REST service and displayed on the projector that is pointed at the rear window, allowing following drivers to see the image, video, or message. 
• Point Of Interest – As described earlier, this is the way the user can turn on the Point of Interest map on the HUD.  Selecting one of the four items sends the selection to the REST service where it is persisted. The polling HUD will know when the selection is changed and display the map interface as shown above.
• Telemetry – This is a replica of the instrument cluster that runs on the Windows 7 slate. OBD data is queried via the WCF service, just like the slate, and displayed on the gauges, just like the slate.
   
• Projection Screen – This will raise and lower the projection screen on the rear of the car.
• Horn – This displays a list of known horn sound effects that live on the REST service layer. Selecting any of the items will send a command through the REST to play that sound file on the external sound system of the car. This selected audio file would play when the horn was pressed in the car.
• Settings – Internal settings for setting up hardware and software for the car.

Passenger Application

The passenger interface runs on a Samsung Series 7 slate running the Windows 8 Consumer Preview. This interface has a subset of the functionality provided by the Windows Phone application, but communicates through the same REST service. From this interface, the passenger can set the car horn sound effect, view the front and back Kinect cameras, select a Point of Interest category to be displayed on the HUD, and select the image, video or message that will be displayed on the rear window.

External Car Lighting

The external lighting system was controlled by a web server running on a Netduino Plus using a Sparkfun protoshield board to simplify wiring, and allow for another shield to be used. The actual lights were Digital Addressable RGB LED w/ PWM. We'll also have a more in-depth article on this system on Coding4Fun shortly.

The car is broken down into different zones—grill, wheels, vents, etc. It also has a bunch of pre-defined procedural animation patterns that have a few adjustable parameters that allow for things like a snake effect, a sensor sweep, or even a police pattern. Each zone has its own thread which provides the ability to have multiple animation patterns going at the same time. When a command is received, the color, pattern, zone, and other data is then processed.

Here is a basic animation loop pattern.

private static void RandomAnimationWorker()
{
    var leds = GetLedsToIlluminate();
    var dataCopy = _data;
    var r = new Random();

    while (IsThreadSignaledToBeAlive(dataCopy.LightingZone))
    {
        for (var i = 0; i < leds.Length; i++)
            SetLed(leds[i], r.Next(255), r.Next(255), r.Next(255));

        LedRefresh();
        Thread.Sleep(dataCopy.TickDuration);
    }
}

Rear Projection Window

The rear projection system consists of two 4” linear actuators, a linear actual controller, the NETMF web server from above, a Seeed Studio Relay Shield, the back glass of a 1967 Ford Mustang, some rear projection film, a low profile yet insanely bright projector that accepts serial port commands, and a standard USB to serial adapter.

The REST service layer toggles the input of the projector based on the selected state.  This would allow us to go from the HDMI output of an Xbox 360 to the VGA output of the laptop.  While doing this, the REST layer sends a command to the NETMF web server to either raise or lower the actuators.

Here is the code for the NETMF to control the raising and lowering the glass:

public static class Relay
{
    // code for for Electronic Brick Relay Shield
    static readonly OutputPort RaisePort = new OutputPort(Pins.GPIO_PIN_D5, false);
    static readonly OutputPort LowerPort = new OutputPort(Pins.GPIO_PIN_D4, false);

    const int OpenCloseDelay = 1000;

    public static bool Raise()
    {
        return ExecuteRelay(RaisePort);
    }

    public static bool Lower()
    {
        return ExecuteRelay(LowerPort);
    }

    private static bool ExecuteRelay(OutputPort port)
    {
        port.Write(true);
        Thread.Sleep(OpenCloseDelay);
        port.Write(false);

        return true;
    }
}

Messaging System

This is a WPF application that leveraged the file system on the computer to communicate between the REST service layer and itself.  Visually, it shows the message/image/video in the rear view mirror but it actually does two other tasks, it operates our car horn system and plays the recorded audio output from the phone.

• Displaying Messages
  To display images, we poll the REST service every second for an update.  Depending on the return type, we either display a TextBlock element or a MediaElement.
  
  
• Detecting and Playing Car Horn
  When someone presses the horn in the car, it is detected by a Phidget 8/8/8 wired into a Digital Input. In-between the car horn and the Phidget, there is a relay as well. This isolates the voltage coming from the horn and solves a grounding issue. We then feed back two wires from that relay and put one into the ground and the other into one of the digital inputs. In the application, we listen to the InputChange event on the Phidget and play / stop the audio based on the state.
  
  
• Detecting new recorded audio from the phone and car horn changes
  When someone talks into the phone or selects a new car horn, the REST service layer places that audio file into a predetermined directory. The Messaging service then uses a FileSystemWatcher to detect when this file is added. The difference between the car horn detection and recorded audio is the recorded audio will play once it is done writing to the file system.

External PA System

To interact with people, we installed an external audio PA or Public Address system. This system is hooked into the laptop that is connected to the car horn, and can play audio data from the phone. Having a PA system that is as simple as an audio jack that plugs into a PC enabled us to have different ringtones for the car horn and to talk through the car using Windows Phone.

Conclusion

After months of planning and building, the Project Detroit car was shown to the world on an episode of Inside West Coast Customs. Though it was a ton of work, the end product is something we are all proud of. We hope that this project inspires other developers to think outside the box and realize what can be done with some off-the-shelf hardware, software, and passion.

MayhemVolumeStart.zip file contains the class library project all set up with the NuGet package references and the reaction that increments the volume.

The first step we are going to take is to add the additional references we need to be configurable. The first reference is MayhemWpf from the same NuGet feed MayhemCore is from. (http://makemayhem.com/nuget). Add a reference to the following assemblies:

• PresentationCore
• PresentationFramework
• System.Runtime.Serialization
• System.Xaml
• WindowsBase.

Next, we switch the code from incrementing the volume to setting the volume to 50%.

To do this, replace the line:

device.AudioEndpointVolume.VolumeStepUp();

with

device.AudioEndpointVolume.MasterVolumeLevelScalar = 50 / 100.0f;

The reaction now works successfully to set the volume to half way. The next step is to make that setting configurable, and persist between application runs. Let’s make that 50 a variable. Add a private integer to the class (I’m calling it level) and change the above line to be:

device.AudioEndpointVolume.MasterVolumeLevelScalar = level / 100.0f;

Since that variable will be user configurable, we want to be able to show a string on the main window that says what the reaction is doing. To do this, we have to tell Mayhem that our reaction is configurable by implement the IWpfConfigurable interface from MayhemWpf.

In order to set that configuration string we have to implement the method GetConfigString. The implementation of this method should return some string that provides a look into what the configuration settings are for the reaction.

I will make the GetConfigString method be the following:

public string GetConfigString()
{
   return string.Format("Set the volume to {0}%",level);
}

Now, in order to make the module save the configured state when the application is shut down and restarted, we need to add a little bit of data contract code. We are going to add the [DataContract] attribute to our class. This attribute comes from the System.Runtime.Serialization framework.

Our class header now looks like:

[DataContract]
[MayhemModule("Set Volume", "Sets the master volume level")]
public class SetVolume : ReactionBase, IWpfConfigurable

Note that I also changed the MayhemModule attribute’s name and description to reflect the new functionality.

We also need to mark the configurable variables to be saved as well. To do that, add the [DataMember] attribute to our level variable:

[DataMember]
private int level;

In order to set a default value for this variable, we shouldn’t initialize it using a constructor. Constructors should never be used in modules. Instead, we have a method that should be overridden that you get from ReactionBase. OnLoadDefaults is to load the settings you want to have by default.

protected override void OnLoadDefaults()
{
   level = 50;
}

Now when you use the SetVolume reaction in Mayhem, it will at 50%, but if that value is changed and the application is restarted, it will be set to the value it was at before it was closed!

The next step is to make the configuration window that actually enables that variable to be modified.

Add a new WPF UserControl item to the project named SetVolumeConfig.xaml.

Replace the contents of the XAML file with:

<src:WpfConfiguration x:Class="Volume.SetVolumeConfig"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"   
   xmlns:src="clr-namespace:MayhemWpf.UserControls;assembly=MayhemWpf"
   Width="300">
   <Grid>
      <Grid.ColumnDefinitions>
         <ColumnDefinition Width="100" />
         <ColumnDefinition Width="200" />
      </Grid.ColumnDefinitions>
      <Grid.RowDefinitions>
         <RowDefinition />
      </Grid.RowDefinitions>
      <TextBlock Style="{StaticResource ConfigLabel}" Grid.Column="0" Grid.Row="0">Volume:</TextBlock>
      <Slider Grid.Column="1" Grid.Row="0" Height="23" HorizontalAlignment="Left"  Name="VolumeSlider" VerticalAlignment="Top" Width="200" Maximum="100" />
   </Grid>
</src:WpfConfiguration>

This configuration window simply has a volume slider allowing values between 0 and 100. WpfConfiguration handles the display of how the module asks for information. As you hopefully notice, it doesn’t contain the save button, or the title of the window. All that is handled for you so that we can maintain consistency between configuration windows. We also provide default styles that further maintain consistency and user expectation.

We now need to create the backing code that makes the configuration window come together. Change SetVolumeConfig.xaml.cs to extend the base class WpfConfiguration instead of the default UserControl base class.

In the constructor, we should ask for all the information we need to populate the config window with the current settings. In this situation, that only means the current volume level setting. Add an int parameter to the constructor called level. Also add a public property on the class with a private setter called Level. In the constructor, set this property with the parameter passed in to the constructor.

Your class should now look like this:

using MayhemWpf.UserControls;
namespace Volume
{
   public partial class SetVolumeConfig : WpfConfiguration
   {
      public int Level
      {
         get;
         private set;
      }
      public SetVolumeConfig(int level)
      {
         this.Level = level;
         InitializeComponent();
      }
   }
}

WpfConfiguration gives us some handy hooks that we can use. We need to set the value property on our slider. This could be done with data bindings, but for simplicity we will just be doing this with code. Also, there is a Boolean flag in the WpfConfiguration class that enables the Save button on the dialog. When handling user input, the save button should only be enabled if the input is valid. Since the slider always has a value in our range, the Save button can always be enabled. We will set this flag in the OnLoad method.

Override the OnLoad method as follows:

public override void OnLoad()
{
   VolumeSlider.Value = this.Level;
   CanSave = true;
}

We then also override the OnSave method to set the property to the value the SetVolume class will expect.

public override void OnSave()
{
   this.Level = (int)VolumeSlider.Value;
}

Lastly, we need to set the title that shows up on the configuration window. To do this, override the Title property and have it return “Set Volume”:

public override string Title
{
   get { return "Set Volume"; }
}

Now we need to go back to the SetVolume class and implement those configuration related methods.

The ConfigurationControl property needs to return an instance of the SetVolumeConfig class. Remember that its constructor expects the current volume setting:

public WpfConfiguration ConfigurationControl
{
   get
   {
      return new SetVolumeConfig(level);
   }
}

Lastly, OnSaved takes the instance of WpfConfiguration control we just returned in the above property. We need to cast this back to SetVolumeConfig to be able to get access to the Level property:

public void OnSaved(WpfConfiguration configurationControl)
{
   var config = (SetVolumeConfig)configurationControl;
   this.level = config.Level;
}

That’s all it takes! This code provides us with a complete reaction that enables us to set the volume level on the computer. As you can see, we provide a very straightforward API enabling you, the developer, to write user configurable modules for Mayhem.  You can click the download link at the top of the screen to get the final code in MayhemVolumeFinal.zip.

We have more documentation available on the available methods and APIs on our CodePlex documentation page.

The OBD-II Manager project is the OBD-II sub-system and instrument cluster application from the Project Detroit Mustang we built with West Coast Customs.  If you're not familiar with this project, you can find out more about it here and here.

OBD stands for On-Board Diagnostics.  In the world of cars, this can be thought of as the computer which has a variety of data points which can be queried, such as speed, fuel level, and even trouble codes that relate to the check engine light.  If you've ever taken your car in for service, your service center has hooked up the car to a computer via the OBD port to get the status of the car and what may not be working properly. 

This project contains a library you can use to integrate OBD data into your application, as well as a modified version of the actual Instrument Cluster application used in the Project Detroit car which shows how the library can be used.

More Information

• Coding4Fun Article
• Project Detroit
• OBD-II to USB cable (ELM323/327-based OBD-II to USB cable)
• More information on OBD-II
• ELM323/327 Datasheet

Instrument Cluster Screenshots

At the SXSW Interactive Opening Party hosted by Frog Design and Microsoft, the Coding4Fun team has unveiled their latest invention, BoxingBots!

With BoxingBots you are the controller except this time, forget the screen. You’re controlling a 6-foot tall metal robot that’s trying to punch out your opponent’s 6-foot tall machine. It’s Real Steel in real time.

Video Demo

Watch Laura Foy's video of the BoxingBots in action!

BoxingBots combines Kinect’s motion sensing technology with pneumatic robots in a 6-foot square ring. Two players face off to try to knock each other’s blocks off.

Each robot has

• 1 On-board laptop PC
• 70 programmatic LEDs in the head and chest controlled by a Phidgets LED controller board
• 2 2.5 gallon tanks of compressed air @ 150 PSI
• 8 12-volt 17amp batteries
• 2 Roboteq motor controllers that power the four omni-directional wheels
• 2 5" stroke cylinders that punches/retracts the arms
• 1 6' stroke cylinder that lifts the head when the robot is knocked out
• 2 button switches on the chest that are triggered by punches and a Phidget 8/8/8 interface board that controls the relays and buttons switches

How gameplay happens

• Each robot's on-board PC receive commands over the network from the Admin PC for movement, punches, score, etc
• Each player stands in front of a Kinect for Windows-enabled PC that interprets their gestures (punch, move in a direction, strafe, rotate) and sends that as a command to the Admin PC
• The Admin PC manages the game, including pausing, reset, starting, sending commands to the robots and receiving damage data from the robots when the robot has been punched

Photos

WPF Sample Screenshots

Windows Phone Sample Screenshots