PC Controlled Lego Car over Bluetooth

Downloads

Note: .NET Framework 4.0 or above is required to run the PC binary program. Visual studio 2012 is required to open the PC source files.
Sources – http://hostr.co/sByckOPFF3ni
Binaries – http://hostr.co/rwewe6XU9dFc

Youtube Demo

Introduction

RobotProgram

We will look at how to control a Lego car using a PC via Bluetooth communication. The system presented here consists of a PC, a Lego car (picture above, left), and a program (picture above, right) to be run on the PC to connect to the Lego car and to send commands to the Lego car. This program is written in C# on .NET Framework 4.0.

Unlike conventional systems where commands are generally sent from the PC to a “slave” program that has to be be explicitly executed on the Lego car, the presented system allows a PC to send commands directly to the firmware layer of the Lego car. That being said, no “slave” program has to be explicitly executed on the Lego car, thereby making this system “cleaner” and “neater.”

Overview

Overview

There are 3 major parts in this system: Connect, Command, and Control.

The connect part allows the PC to establishes a Bluetooth communication channel to the firmware of the Lego car. After the communication channel has been set up (I.E. the PC has connected to the Lego car), the PC can now send commands to the firmware of the Lego car. Upon receiving each command, the firmware of the Lego car will process the commands and control the motors accordingly.

Connect

In the connection procedure, the outgoing COM port of the Lego car is required. You can find out what this port is under Bluetooth Settings > COM Ports, only after you have paired your Lego car to your PC. Note that you will NOT be able to find the COM ports if you have not done the pairing.The COM port looks something like “COM12”, “COM2”, “COM5”, etc.

After acquiring and inputting the outgoing COM port into the program running on the PC, the program will create and open a SerialPort using the specified COM port. By doing so, we essentially establish a Bluetooth communication channel between the program and the firmware of the Lego car. With this SerialPort up and ready, the program can now send commands over the SerialPort to the firmware of the Lego car.

Command

As per (almost) all communication channels, arrays of bytes (which are called packets) are sent from the PC to the firmware of the Lego car. In our case, these packets contain commands which “tells” the firmware of the Lego car what to do. We will be adhering to the Lego Mindstorm NXT Communication Protocol (http://mindstorms.lego.com/en-us/support/files/default.aspx) to generate these packets.

The packets, as defined in the Lego Mindstorm NXT Communication Protocol, consists of two segments, the header and the command.

The header consists of two bytes which includes information about the length of the command. These two bytes are written and read in reverse, that is, the first byte is the Least Significant Byte (LSB) and the second byte is the Most Significant Byte (MSB). Because we are only making use of one command (“SetOutputState”), the length we use will always be the same, which is 13 in the case of “SetOutputState”. As such, our header will contain the two bytes {0x0D, 0x00}.

The command comes after the header in the packet. In the Lego Mindstorm NXT Communication Protocol, a command (“SetOutputState”) as been specified which causes the firmware of the Lego car to set the state of the motors. This makes it possible for the PC to command the firmware of the Lego car to run a specific motor at a specific power, or to brake a specific motor.

Whenever a button in the program on the PC is pressed or released, the program will generate the respective packets and send it to the firmware of the Lego car, over the Bluetooth communication channel. In essence, any user input on the PC will translate to a command from the PC to the firmware of the Lego car.

Control

After the firmware of the Lego car receives a packet from the Bluetooth communication channel, it will process the command contained in the packet and adjust the motors accordingly to the information contained in the received packet. Because the firmware should have already implemented the Lego Mindstorm NXT Communication Protocol, there is no need for us to worry about this step. The firmware has it all done nice and neatly.

Conclusion

In this project, we see how it is possible for a PC to communicate with a Lego car using the Lego Mindstorm NXT Communication Protocol, without having any “slave” programs to be explicitly executed on the Lego car. It is possible to extend this system to NXT-NXT, Android-NXT, Mac-NXT, and similar systems, as long as the controlling device is capable of Bluetooth communications and the controlled NXT uses a firmware which implements the Lego Communication Protocol,

Through this project, we see that the utilization of existing communication protocols allows for an efficient and modular way to get communication operations up and working. Though having to go through, understand and utilize/implement such protocols might be a huge trouble, the benefits evidently outweighs such troubles. The DNS Protocol (which is unrelated to Lego, by the way) is a very good example.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s