As I wait for parts for the
Omnicopter, one of the things I’m getting started is the
XBee radio communications between the remote/computer and the copter. My initial design will attempt to use XBee radios for all control of the copter as well as in sharing diagnostic & control data between the base station [remote & or PC] and the copter. I fear that XBee may end up not being responsive enough and have enough throughput to accomplish all things but that’s where I’m going to start before attempting traditional R/C radio techniques.
I want to be able to control the Omnicopter both by a remote control I’m building based on a
NETMF microcontroller and with software on a PC. The most basic of things is to make sure that the NETMF microcontroller I’ve chosen for the copter, a
GHI FEZ Panda-II, can communicate with my PC.
For the
Panda-II I have bought and assembled an
Adafruit Protoshield and an
Adafruit XBee Adapter. I already have some XBee Modules (series 1) from a previous project. So, I’m using them for now. Once I’ve proven the copter can fly and I’m brave enough to push the range limits of the XBee series 1 (300 ft.) then I can simply buy new
XBee Pro radios and drop them in place of the existing radios to get a range of 6-15 miles (line of sight).
To test communications, two things are required – an XBee connected to the PC and a NETMF microprocessor with an XBee and the necessary software on both sides.
Setting Up An XBee on NETMF
An XBee radio communicates using basic
RS232 type of communications. All that’s required to connect it to the Panda-II is to give it 5V power, ground, and transmit & receive signals.
For a better view of the wiring connections, I drew it up in
Fritzing.
Note that the receiver (RX) on the XBee is connected to the transmitter (TX) on the Panda-II and vice-versa. This may not be obvious to those first getting started.
Next, we’ll need a NETMF C# program to install on the Panda-II. Visual Studio 2010 (VS2010) Express or better can be used to compile and deploy the program. GHI has a great
tutorial on getting started if this is your first time to create a NETMF program. So, I’ll jump straight to the code. I’m using the
MFToolkit open source code by
Michael Schwartz to simplify the code required considerably. An alternative assembly that is somewhat easier to understand and seems to satisfy basic XBee needs is
Grommet. Since I expect this project to get much more sophisticated over time, I’ve decided to stick with the MFToolkit.
Once you download the MFToolkit (or Grommet) code from
Codeplex and create a new NETMF C# project, you can simply copy this code into your project to have the NETMF device send a “ping” every 5 seconds. The ping is basically the word “Hello” plus the current time in Ticks. The following code is not meant to be “production ready”. It’s just enough to test that the XBee is working.
public static void Main()
{
var ledBlinkerThread = new Thread(BlinkOnboardLed);
ledBlinkerThread.Start();
var pingThread = new Thread(SendPingWithMFToolkit);
pingThread.Start();
}
private static void SendPingWithMFToolkit()
{
var xbee = new SerialPort("COM1", 115200, Parity.None, 8, StopBits.One);
xbee.Open();
xbee.DataReceived += XBeeDataReceived;
while (true)
{
string output = "Hello " + DateTime.Now.Ticks;
byte[] bytes = System.Text.Encoding.UTF8.GetBytes(output);
xbee.Write(bytes, 0, bytes.Length);
xbee.Flush();
Thread.Sleep(5000);
}
}
static void XBeeDataReceived(object sender, SerialDataReceivedEventArgs e)
{
int bytesReceived = ((SerialPort)sender).BytesToRead;
var bytes = new byte[bytesReceived];
((SerialPort)sender).Read(bytes, 0, bytes.Length);
var received = new string(System.Text.Encoding.UTF8.GetChars(bytes));
Debug.Print(received);
}
Note that the second parameter of the SerialPort constructor in SendPingWithMFToolkit() specifies the baud rate of the XBee radio. By default, the radios will be set to 9600. I have changed mine to 115200 prior to this writing. If this is your first attempt with XBee then you should change this parameter to 9600 or whatever your actual baud rate is if yours have been changed to something different. The important thing to know is that both radios must be set to the same baud rate and the software on both sides is configured likewise.
At this point you should be able to compile and run your code from the Panda-II without issue and it will start sending it’s “ping”. Also, although I am using the Panda-II for this post just about any Arduino shield compatible NETMF device such as the
netduino should also work w/o any change to the code or wiring.
Setting Up An XBee on a PC
Setting up an XBee on a PC is a bit simpler since all we really have to do is connect the XBee to a breakout or dev board with a USB cable and install the
X-CTU software by Digi. No reason to write our own code for this test since there already exists this great utility that does everything we need to test & configure an XBee. I am using Windows 7 Ultimate (x64) but the steps are basically the same for any OS.
I have a MaxStream (now Digi) XBIB-U-Dev (Rev 3) XBee development board from a previous project that I’m using, but you can use just about any XBee adapter including the one from Adafruit that we used on the NETMF. On my board, I’m able to plug a USB cable directly into it. On most of the basic adapters, you will need an
FTDI cable to convert the serial communications to USB. You will also need to locate and install the appropriate drivers for your OS.
Once you have your hardware all figured out, we need to download and install the
X-CTU software.
After you install X-CTU, run it and it should come up with something similar to this except the Baud setting will probably be at 9600. Set the baud rate to match that of your modem and hit the “Test/Query” button to see if X-CTU can connect to your XBee radio. Assuming you can connect and all is good then we’ll now see if we are receiving the “ping” from our NETMF device. Click on the “Terminal” tab and wait 5 seconds. You should see some text appear in red on the screen and more to be added every 5 seconds.
If we have this then we know we are properly sending from the NETMF device and receiving by the PC. Next thing to test is that we can send from the PC and receive from the NETMF device.
First make sure that we are running our program on the NETMF device through the VS2010 debugger and not just on the board itself. You’ll notice on our NETMF code that we are capturing XBee received data with the XBeeDataReceived() handler function. Anytime data is received, it will be simply printed to the Output Window.
To send a packet of data from the PC we hit the “Assemble Packet” button in the X-CTU Terminal screen. We’ll send a simple “Hello World” packet. Type that in the textbox and hit “Send Data”. You should see “Hello World” printed in blue text in the X-CTU console and in the VS2010 output window you should see the same text also printed there.
Mission accomplished. We have established the most basic of communications and know that all of our hardware is setup properly and is working. Now the challenge is for you to figure out how to best utilize this power in your project by designing the data you will send and how to handle it properly when it is received.
If you are still having issues with hardware or software, you should start by checking the forums at any of the following sites.
Good luck and happy transmitting!
Although I am currently only using four motors and one battery, I knew this was one part of the project that would be a lot easier to only do once. Also, because of my electrical current requirements I decided to use 12 gauge wire which is thicker and less flexible than the smaller gauge wires. Getting all the wire in my 1/2” thick frame proved to be a bit of a challenge.
So, after researching and doing a lot of thinking I decided on what I believe is going to be an excellent design. I found an example on the net that served as inspiration where he twisted the ends of the wires together into a loop. That seemed it would be a bit difficult to solder and then you would also have to add an insulator between the positive and negative rings which would add bulk. I finally got the idea that a ring of double-sided PCB would serve the purpose marvelously.
Using a whole saw, I cut out a 1” circle of the PCB. Because I wanted to be able to run a wire up the center to feed the microprocessor, I then drilled a 1/2” hole in the center. After washing and roughing up with some fine sandpaper on both sides of the board, I then put a heavy tin of solder on both sides to help thicken the metal and allow it to handle the higher current and to ease in soldering the wires. Next, I spent most of the afternoon soldering… After this was all completed, I ran across an article that pointed out that making a closed loop like I did risks the possibility of creating inductance which may later cause me problems. If I had it to do all over again, I would have removed a thin slice from each side of the PCB to break the loop. But, once the copper is tinned and the liquid tape is on it's a bit more hassle to do. So, I'll keep this in mind if any problems should arrise that I think may be due to this. If I were starting over, I would have definitely put this into the original design.
Once all the wires were connected to the PCB loop, I soldered on all of the XT60 connectors. I used female yellow plugs for the motor connections and male plugs for the battery connections. Using a red Sharpie, I colored the battery connections also for easier identification. 
The battery wires were run in parallel and leads were run to the outside of the frame to allow for a switch to be connected between the batteries and the rest of the harness.
Once all the soldering was complete, I painted on plenty of liquid electrical tape on all the exposed metal surfaces including the entire PCB ring.
