Tim O'Brien Photography– t413.com

I'm calling this quadcopter design The Crossbow because of the huge number of people who have thought that's what it was while I'm carrying it around campus.

Right now I'm just testing it and working on the software using only two rotors. This design is modular so I can attach whichever arms I want.

Here's an idea for what I started with in the design process:

This is the flight computer module:

And the body with the two arms attatched.

That title's a mouthful, any yet it's not enough. There are so many names for these modules, a better title would be Fast two way Xbee ZigBee Series 2 Znet 2.5 Serial AT Communication. In my trials and tribulations building my quadcopter remote (soon I'll post about it) I've run across problems getting two way, full speed, and reliable communication between my modules. Here's what I discovered after a lot of manual reading:

Fast two way Xbee ZigBee Series 2 Znet 2.5 Serial AT

The heart of the issue is that Xbee 2.5 modules are not designed (spesificlly) to be point-to-point direct communicators. Whereas Series 1 modules can communicate directly with zero configuration, these series 2 ZNET modules need some work. Here's a great article on the difference. There's a few great articles on how to setup these znet modules, however they're really hard to find. (I can't even find which ones I've already manged to run across). Here's the basic setup:

Basic Series 2.5 Setup

1. First get X-CTU from digi. It's windows only, however:
   1. Wine on (apt-get install wine for debian) linux will let it install and run perfectly.
   2. Wine also runs on Macs, try this.
   3. To get it to work correctly in wine, follow this tutorial.
2. Open X-CTU, select your COM port, (see that tutorial if you're running linux or os x) set the serial baud rate, and click on the Modem Configuration tab.
   
3. Read the current information from your xbee.
   1. Note: if x-ctu complains, it's likely missing the latest firmware. Try the Download new version button to automatically get them, but I've never had that work. Go to the digi download page and download the .zip file then give that to x-ctu.
4. Change the Function Set dropdown menu to ZNET 2.5 COORDINATOR AT. One and only one coordinator xbee is required for each series 2.5 network.
   
5. Check the Always update firmware box then click write.
6. Optional configuration:
   1. You can change the PAN ID to something unique if you'd like, but you'll also need to change the other module to match it exactly.
   2. Change your serial baud rate if you want to communicate faster then 9600 bps. Scroll down to serial interfacing to find that option.

Sweet, it's all set for automatically packetized, full-speed serial communication.

Fast, reliable two-way data: not what you get

The problem you may soon discover is that the communication from the coordinator to the ZNET 2.5 ROUTER/END DEVICE AT (I call this on the node) slows to a halt after a few dozen bytes and never catches up when there's regularly sent data. Data coming from the node to the coordinator is fine.

The Fix

Taking with the idea from this forum posting and mixing in lots of reading of the manual, I discovered that if the coordinator is told to only send to your one node it works flawlessly. I came up with this process after reading into the configuration options further.

1. Go back into X-CTU configuration and name each module (I called mine PICARD and RIKER) using the NI, or Node Identifier, option (+++ATNI PICARD WR if you know what you're doing).
2. Write the changes.
3. Power-on both modules, with the coordinator connected to the computer.
4. Click on the Terminal tab.
5. Type +++ to go into command mode, don't hit return. Be sure it outputs OK.
6. Type ATND (and return) to show connected modules, to be sure your NODE and all it's address information is there. All the commands start with AT, and the ND is Node Discover.
7. Type ATDN <your node's NI> (and return). That's the command for Destination Node, space, and the Node Identifier you created earlier and just confirmed in the previous step. It should return OK.This sets the DH and DL values to the SH and SL values from the node. This means the destination address (both High and Low halves) are automatically set to the serial number from the node. All communication will now only go to the node when coming from the coordinator.
   
8. Type +++ again to enter command mode then type WR (and return) to save settings. If it returns OK then You're done!

Por fin

Here's what JordanH said on the digi discussion boards:

[Not setting a destination address] will transmit each and every packet from the XBee module as a broadcast packet. Broadcast data is unreliable and unacknowledged so that may explain the behavior you are seeing.

Now that we've got the address set, go send some data!

Building any radio controlled vehicle is usually a money intensive endeavor. When you're building one that flies, is computer controlled (and will hopefully soon be autonomous) it goes to reason that it will be extremely expensive. Some quadcopters are literally tens of thousands of dollars because they use electronics like this. For my quadcopter I wanted to keep the cost as low as possible but still create a reliable platform for future development. I started with the aeroquad project and have done a lot of research on diydrones. Here's the spreadsheet I made before ordering everything (thanks google docs):

I broke a blade last Sunday and have been out of commission while I'm waiting for a new order (plenty this time) from hobbyking in Hong Kong. Meanwhile, I've taken the opportunity to redesign and strengthen the frame. Here's where I am: