Patrick,

Hopefully, I can ramble enough to explain to you how useful the Serializer Robot Controller is, and help you and your son get started (quickly) with robotics.

I’m going to post this on our forum as well, so others can leverage this information.

So, to control robots, you have to obviously have some control software.   The software has quite a few tasks to perform, but basically it has to do the following:

1.)    Control Motors/Actuators/Servos

2.)    Read Sensors and interpret their meaning

3.)    Perform an action based on the sensor input

I know the list above is very elementary, but it’s a good starting point for discussion.

Interfacing Motors/Actuators/Servos:

Regarding point 1, everyone interfaces microcontrollers to DC motors using a h-bridge.  This requires some low-level bit twiddling to send a PWM (Pulse Width Modulated) output to the h-bridge, which then makes the motors work.  So, typically, you have to purchase an additional h-bridge to interface your motors (costing $50-$100).  In addition, you have to write(and debug) the low-level software to control the h-bridges.   The Serializer has built-in dual 4 Amp h-bridges, AND also has the ability to interface external H-Bridges, if the onboard 4 Amp h-bridges aren’t enough.  So, you’re not stuck w/ the onboard h-bridges.   Thus, you could spend time re-implementing the control software for the h-bridges, but why?  It’s been done a million times, including by ourselves.

Almost all hobbyist based robotics kits use standard hobby servos.  To interface a servo, you basically just need an I/O line from your microcontroller, power, ground, and write some control software to send the correct pulse width to the servo, so that it goes to the desired position.   While this is pretty easy to do, it’s yet another piece of code that you have to write (and debug).  The Serializer supports control of up to 6 servos, and implements this code for you.  In addition, we’re launching a new product at the end of the month to allow you to control up to 25 servos from the Serializer’s I2C port.   The board will plug into the Serializer, and our firmware and libraries will support the interface to allow you to immediately use it.

We are also launching a new product at the end of the month to allow you to control up to eight relays from the Serializer’s I2C port, which are useful for turning on devices that require larger currents that microcontrollers can’t handle.  Again, the Serializer firmware, and our libraries will support control of this device.

We are also launching a new product at the end of the month to allow you to control up to 10 sonar sensors from the Serializer’s I2C port.  And, you guessed it, the firmware and our libraries support it too. J

By the way, the Serializer’s I2C port is a perfect way to expand the functionality of the Serializer, without using up a lot of I/O lines.

Interfacing Sensors:

In order for your robot to sense and “see” it’s surroundings, it obviously needs sensors.  There are many sensors available for measuring distance to an object, temperature, direction/heading, distance traveled, and many more.   In addition sensors have different ways to interface them to query the information, which includes analog, pwm, i2C, SPI, and others.

As you can see, you’ll have to write (and debug) software to interface all of these sensors, which can be a real pain (and can be VERY time consuming).   So we decided to take all of the most popular sensors on the robotics market, and provide a physical and software interface for them via the Serializer.  The Serializer can read up to five 10-bit analog sensors, up to 127 I2C devices, and up to ten I/O sensors.  

Once you have written software to read the values of the sensors, you have to interpret it.  This might mean converting a 10-bit analog value to a meaningful distance, or converting the number of ticks your wheel encoders reported to a distance.

Again, all of this sensor interfacing & interpretation is packaged for you within the Serializer firmware and libraries.

A very powerful sensor is a Camera.  We’ve worked with www.RoboRealm.com to provide some cool vision processing examples via their software as well.  We are currently trying to find a quality wireless camera that we can offer to our customers at a reasonable price.  So far, most wireless cameras have been pretty junky. L
Nonetheless, the camera will be a very key sensor for robotics going forward.  Once we find a camera, we will be leveraging the RoboRealm software a lot more.

Making decisions:

Once you have collected all of the sensory inputs, and have translated them to a meaningful value, you need to make decisions on what action to perform (if any).

This is actually the fun part of software development, because you are adding intelligence to your robot.   Obviously as a beginner, you could start out with simple behaviors to allow your robot to follow a line, navigate through a maze, etc.  Eventually, you can add higher intelligence to allow you robot to plan out a path to take, recognize objects (via vision), and perform useful tasks.

Before I get too deep into this subject, lets’ summarize what the Serializer does for you, and how to interface to it.

Utilizing the Serializer:

As you have read, the Serializer interfaces the most common robotic sensors on the market (under Devices/Sensors tab), and converts the signals returned from the sensors into a meaningful value (such as distance, temperature, etc.).

So, how do you get that information from the Serializer and/or control it?  Well, there are a few ways:

1.)    Your application uses the Serializer Protocol, which is defined in the Serializer User Guide, to query these values and/or control motors/servos via a serial connection

2.)    You use our Serializer .NET library to implement the protocol for you, and you just use the simple to use .NET object interface to query sensors and/or control motors/servos

3.)    You use our Serializer Microsoft Robotics Studio(MSRS) Services to query sensors and/or control motors/servos - Advanced

4.)    You use our upcoming C++ library (written by James Y. Wilson) to query sensors and/or control motors/servos

Point 1 requires you to open a serial port, and send the various commands (e.g. ‘pwm, ‘sensor’, ‘pping’), defined in the Serializer Protocol to the Serializer to query sensor values and/or control motors/servos.  You can also open up a ‘Hyperterm’ session, and send the same commands to the Serializer for debugging purposes.

Points 2 thru 4 implement the protocol for you, and handles all of the communications behind the scenes.  What does this mean?  Well, it means we made it even EASIER for you to control your robot via the Serializer! J  You don’t have to worry about the communications portion of the software,  which implies coming up w/ a useful scheme for querying the sensors, whilst not blocking other code that needs executing.

Regarding the .NET Library, we have examples for every supported component embedded in the MSDN help, under each component topic (called ‘Example Source Code’).   You can download the library, as well as download instructions for installing the library on the Serializer page, under the Docs/How-To/Library tab.

You will also need to install the .NET 2.0 Framework on your computer.

To use the Serializer Services for MSRS, you can go here for info.  This is pretty advanced, and I would suggest starting w/ the .NET library first.

Programming Environment:

If you plan on developing an application under Linux, then you’re sort of on your own.  We will be adding support for Linux/FreeBSD/OSX apps later this year.

While we don’t offer support, it is still pretty simple to interface the Serializer under Linux, as you only need to open a serial port, and send commands/handle responses (e.g. point 1 above).

However, if you plan on developing an application under Windows, then you’re in luck.

You can download one/or both of the Visual Studio Express Editions for free:

·         Visual C# Express Edition

·         Visual Basic Express Edition

Currently, our examples are in C#, so I would suggest starting out programming with C#.

Serial Connection:

There are four ways to physically connect your Serializer to your PC/Laptop/PC104 to communicate with it:

1.)    RS-232 serial connection/cable

2.)    USB connection/cable

3.)    Bluetooth/wireless

4.)    XBEE/wireless

No matter which physical connection you choose, your application sees these devices as serial ports, and thus you can simply send the same command to all four interfaces w/o a code change (except for changing the COM port that the OS has assigned to that specific serial port).

The life of a command:

So, let’s say you decide to use the Serializer .NET library…How exactly does that work?  Well, I’m going hide most of the details, but give you enough to fully understand what happens in the life of a command:

Let’s say you create a GP2D120 object using the .NET Library.  Once you do, you’ll want to set a few properties regarding the Analog input line that it is connected to on the Serializer, as well as the frequency for which you want to query the sensor.  Here’s a sample application to create a Sharp GP2D120 sensor connected to Analog Pin 1, and query it every 50msec.    The app also specifies a threshold of 0.5, which means that you don’t want the .NET library to notify you that the value of the sensor has changed, unless it has changed by a value of more that 0.5.  The app also signs up to hear an event, called ‘DistanceChanged’, which will occur if the value changes by more than the specified threshold amount.

using RoboticsConnection.Serializer;

using RoboticsConnection.Serializer.Ids;

using RoboticsConnection.Serializer.Sensors;

using RoboticsConnection.Serializer.Components;

using RoboticsConnection.Serializer.Controllers;

using System;

namespace test

{

        class Program

        {

               static Serializer serializer;

               static GP2D120 irSensor;

               static void Main(string[] args)

               {

                       serializer = new Serializer();

                       irSensor = new GP2D120(serializer);

                       irSensor.Pin = AnalogPinId.Pin1;

                       irSensor.UpdateFrequency = 50;

                       irSensor.DistanceChangedThreshold = 0.5;     

                       irSensor.DistanceChanged += new SerializerComponentEventHandler(irSensor_DistanceChanged);

                       serializer.Run();

               }

               static void irSensor_DistanceChanged(SerializerComponent sender)

               {

                       Console.WriteLine("new gp2d120 distance: {0}", irSensor.Distance);

               }

        }

}

You will also see that there is a method called irSensor_DistanceChanged(), which is basically an event handler, to catch the DistanceChanged event as it occurs.

Once the event occurs, this method will be executed, and in this instance, we’re just printing the distance that the sensor is reading.  Of course, you could make decisions to slow down the motors, turn the robot, or whatever.

So, if you run this application, and have the GP2D120 sensor connected to the Serializer (and it is powered up), you will be able to move your hand in front of the sensor, and see the line “new gp2d120 distance: XXX” printed to the screen.

How does this happen???

Well, to begin with, when you create a GP2D120 object in the .NET library, the .NET library knows that it needs to send a ‘sensor <id>’ command to the Serializer via the serial port specified, where the <id> is the specified Analog input pin id (since the GP2D120 has an analog interface).

Once you invoke Serializer.Run() (or you can call Serializer.PumpEvents() from a while loop), the library is sending that command down to the Serializer at the frequency we specified above, and it waits to hear the response.  Once it receives the response from the Serializer, it stores the translated sensor value into the GP2D120s Distance property, which you are free to use at any point.  It also stores the raw analog value in the Value property, in case you want to do something with it.   

Thus, your .NET application doesn’t have to block (although it can) to wait on the round-trip query to/from the Serializer for sensors. 

The same exact thing happens for all sensors and components within the .NET library.  Thus, all communication to/from the Serializer is handled for you, and you’re just left to read the properties of the .NET objects you’ve created.  It just doesn’t get any easier than this…

This frees your app up to perform useful work, such as navigation, mapping, etc.

Summary:

So, after all of this rambling, to use your Serializer, just:

1.)    Download and install the .NET 2.0 Framework

2.)    Download and install Visual C# Express Edition

3.)    Download and follow the Serializer .NET Library QuickStart Guide

4.)    Peruse through our examples in the Serializer .NET Library Documentation

5.)    Modify our existing sample apps to make your own.

So, hopefully, this has explained the usefulness of the Serializer, and given you a good starting point for getting an application up and running.

I’m sure I’ve missed something, and I’ll be glad to answer any questions that you may have.