Whether you are looking to control an RC helicopter or a full-sized car, this system will work for you. By facilitating communication between a base station and a vehicle, the system enables an operator to process commands and receive data.
Anyone who lives near a model airplane club can attest to two things： the annoying buzzing of nitro engines and the amazing abilities of some of the scale models. Along with planes， model helicopters are sometimes encountered at these clubs. They are more maneuverable than their larger brethren， capable of performing aerobatic maneuvers and inverted flight. A characteristic that scale-model and full-sized helicopters share is their difficulty to pilot， especially for inexperienced technology students. So， when it came time to develop our final project in our technology program at Camosun College， we chose to work on an autonomous， self-balancing model helicopter.
An important part of this project involved developing a communications system for sending commands to the helicopter and receiving status information in return. Using simple， readily available hardware and extensive software， we successfully implemented the communications system to keep the base station connected to the helicopter.
In this article， we‘ll describe our communications system. It comprises firmware and a communications protocol.
Our communications system was originally designed to control an RC helicopter. The system uses software，firmware， and a communications protocol to send commands to the helicopter and receive information from it. The command packets and data packets are transmitted between a base station connected to a laptop computer and a receiving module on the helicopter. Sensor data and user commands control an array of servo motors. With the right modification of servos and sensors，this concept for control could easily be implemented to aid in the control of other types of RC or fullscale vehicles， including boats， planes，or cars.
Who can use a system like ours？ A search and rescue team could send out multiple autonomous helicopters equipped with cameras. The smallerscale autonomous helicopters would have a better chance of finding people in distress than a single full-scale helicopter. Also， the smaller-scale autonomous helicopter would come with a smaller price tag than the fullscale version. But the applications for this communications system are not limited to search and rescue. This system could be used to help remove human involvement with virtually any vehicle‘s operation. You can use the system to control vehicles for cinematography，aerial mapping，law enforcement，surveillance， inspection， and more.
The communications system is designed to transfer data between the base station and the target device. Our target device is an electric RC helicopter. The communications system consists of PC software at the base station，hardware on the base station，hardware and firmware on the helicopter，and a communications protocol to tie everything together.
The PC software consists of three subsections： the communications class library， the indicator user control library， and the Google Maps user control（see Photo 1）。 The communications library links the GUI to the helicopter. It is built around a serial port connection and it provides a simple interface for the GUI coder. The indicators library shows the user telemetry data from the helicopter. It can display customizable dials， a compass control， an artificial horizon， and indicator lights. The overall indicator design mimics a helicopter or airplane instrument panel. The Google Maps user control defines way points for the helicopter and shows its position.
For base station hardware， we used an antenna， a USB-to-Serial module，and a transceiver module mounted to a PCB. The hardware on the helicopter for the communications system consists of an antenna， a transceiver module， and a Microchip Technology dsPIC30F3011 microcontroller. The communications protocol is a rule set that governs the transmission of data between the base station and the helicopter.
We knew from the start that the most difficult aspect of this project would be the software. For this reason， we used simple pieces of proven hardware to get the job done so we could have more time to focus on the software. The communications system hardware on the helicopter is virtually the same as the hardware in the base station.
We used a pair of Low Power Radio Solutions ER900 TRS 900-MHz transceiver modules to send data between the base station and the helicopter （see Figure 1）。 We chose the modules for their simple serial interface， their operation in an unlicensed band， and their ability to take care of error handling. The transceiver modules are mounted to PCBs， which we designed and manufactured at Camosun College （see Photo 2）。 The base station board， which holds one of the transceiver modules， also holds a USB-to-serial converter. The USB-to-serial converter is the link between the transceiver module and the software on the PC.
The helicopter radio module is coupled to a 4″omni-directional whip antenna and interfaced to the USART of the onboard microcontroller. This antenna works well on the helicopter because it is small and fairly lightweight. For a base station antenna，we started with a second 4″omni-directional whip antenna. The signal was somewhat limited using this antenna， so we chose to upgrade to a 12-dBm， 4′long， nine-element Yagi- Uda antenna. This gave us increased range and better signal quality. Plus， we got it for free because one of our instructors purchased it on the condition that we give it to him （for one of his evil schemes） when we were done.
We tested the communications system and determined the data rate was 517 bps. We calculated this with a measured time per byte of 17.4 ms， which is close to the datasheet‘s minimum specified value of 15.978 ms. The latency of the packets varied depending on packet length， with an average delay of 46.75 ms. We measured this delay as the time from when a set of outgoing data is loaded into the radio's buffer to when an acknowledgement is received. Our latency measurement does not take into account the unpredictable delay caused by the non-real-time nature of Windows XP.
The message throughput can vary depending on which error rate is considered acceptable. We made two measurements. At 3.03 packets per second， we determined the error rate was 2.05%. At 4.08 packets per second， the error rate was 2.33%. The two packet rates were used to illustrate the trade-off between the packet throughput and the number of errors that occur. As packet throughput increases， the error rate also increases.
The protocol we developed is a set of rules that enables us to maintain reliable communication between the base station and the helicopter. Work on the communications protocol began even before the official start date of our project. This was a large task， which we needed to complete quickly so we could use it to test other aspects of the helicopter‘s operation. The full code communications protocol is available on the Circuit Cellar FTP site.
The communications protocol is fairly simple in the sense that we did not incorporate any error checking. This was possible because the radio modules we used have some good error-checking routines of their own. There are several bytes within the protocol that have specific tasks. The header bytes are used to"wake-up" the receiver so it can begin recording and decoding the incoming transmission. The length byte tells the receiving station how many bytes are in the data portion of the packet and includes the command group， command，and payload portions. The command group byte tells the receiving station （either the helicopter or the base station）what type of command is being sent. For example， it might be a testing/tuning command， in which case the command group byte would be 0x54. We included a command group to make decoding simpler and better documented. Another programmer looking at the state machine can easily go to the group in question and have fewer commands to sift through.
We use command bytes that make sense. For example，the hexadecimal number 0x50 is an ASCII character"P." This is the character used in the command to change the pitch servo pulse width （"P" for pitch）。However， "P" is also the command byte for the base station to request a preflight packet （"P" for preflight）。The command group byte differentiates the two. The command byte then tells the receiving station exactly what command is sent. In Table 1， 0x45 indicates an engine speed change. （Hexadecimal number 0x45 is an ASCII character "E，" for engine speed.） The checksum is used to verify that the data received is the data that the transmitter intended to send. It is defined as the two least significant bytes of the sum of all the bytes in the length and data portions of the packet. The footer simply indicates the end of a transmission.
In our master/slave system， the base station is the master and the helicopter is the slave. This has a number of implications. The base station initiates all communications，and the helicopter doesn‘t transmit unsolicited data. The only exceptions are error messages， because the base station can‘t know when an onboard error will occur. To ensure that all transmissions from the base station are received， each one is acknowledged by the helicopter in one of two ways. Command packets are acknowledged by the helicopter by transmitting the entire packet， plus an ACK byte （0x06， which comes after the length byte）。 Information requests are acknowledged by simply sending the information requested. If an error is detected in the packet， the packet is ignored and no ACK is sent. It is the master's responsibility to retransmit any commands or information requests that are not acknowledged.
Table 2 is an overview of the complete communications protocol. For a detailed description of all packets and payloads， refer to the Communications Protocol document posted on the Circuit Cellar FTP site.
The data sent via our protocol has to be decoded and used once it is received by the helicopter. This task is performed by our firmware program. The firmware handling our communications is loaded onto a dsPIC30F3011 on the helicopter. We chose this microcontroller because it has powerful processing abilities，which we use in our helicopter for control calculations，and because we happened to have a stash available to us at school.
The firmware， which is essentially an onboard packet parser， comprises two separate state machines. The first state machine checks the packet header and data length，copies the data into a buffer， verifies that the checksum is correct， and checks if the footer is valid. If everything is fine， it sets a valid data flag. This starts up the second state machine， which parses the valid data packet. It checks the first byte to determine which command"family" the command belongs to and checks the actual command. It then determines which action is appropriate to take based on the command. Table 1 shows a complete example of an engine speed packet.
The PC software is designed to keep you in control of the helicopter and informed of its status. It has three main components： the communications class library， the indicators user control library， and the Google Maps user control. All parts of this software are coded in C# using the .NET framework and the Microsoft Visual Studio 2005 IDE.
The communications library is used to link the GUI to the helicopter. It is built around a serial port connection. The library provides a simple interface for a GUI coder to use the communications protocol. It enables all packets to be sent by a simple function call and each received packet raises an event for the GUI to handle. All other functionality，such as error checking and packet parsing，is dealt with internally by the communications class library. The library is centered on a .NET serial port object and a high-speed timer. Each time the timer event is raised， the library checks the serial port buffer to see if its contents are a valid packet or if there is a transmission error. The serial port object raises an event when bytes are received， but we found the event was not raised reliably on every byte. Additionally， using the event forced us to pass the event data across threads. This is because the serial port‘s events are on a separate thread from the GUI. Because the PC software initiates most communications with the helicopter， it is essential to receive the helicopter's acknowledge packet to verify that the desired data has gone out. For this reason， each time a packet is sent， a timer is started. If the timer expires before the expected response is received， a timeout event is sent to the GUI.
The indicators library is used to show the user telemetry data from the helicopter. It is highly customizable： we use it to create the indicators from a real aircraft control panel （i.e.， a compass， an artificial horizon， and indicator lights）。All user controls are scalable in size，enabling them to be resized on a form size change or other events. Dial indicators can be customized easily for many different applications. The numeric range， labels， number of ticks， color ranges， and other aspects can be modified to suit any application. The left-most dial in Photo 1 is an example of a temperature dial that has been set up with a-40° to 100°C range and warning bands for "under" and "over" temperature.
We drew all of the indicators using the graphics device interface （GDI）。 We started by making the gauge class， which inherits the basic Windows user control and implements all features that are common to center dial， artificial horizon， and compass classes. In turn， each of the classes inherits the gauge class. An important thing we learned was the value of using double buffering to prevent flickering of the things drawn using GDI.
If you have the time and money， we would recommend adding error （parity and redundancy） checking to the communications protocol. We were limited on time， so we skipped this aspect of the project because our radio modules had error checking built in. Adding error checking to the communications protocol would enable the protocol to be used on any radio module. Users of the communications system would not have to worry about finding a radio module with error checking built in. They would be able to find any radio module and plug it in.
Another important improvement would be to modify the protocol to allow for multiple slave devices，enabling the multiple helicopter scenario described in the introduction. This would require changing the protocol packets and firmware to include an address byte （or bytes）。
We also have some recommendations to improve the indicators class. Currently，it is made to simulate an aircraft control panel. It would be beneficial to make it more general-purpose as far as how it looks. Also， adding more controls，such as thermometers， seven-segment displays， or redline range events，would add to the functionality.
Michael Ghazi‘s （firstname.lastname@example.org）six years as a naval communicator in the Canadian Forces prompted him to undertake the task of designing the RF system for the helicopter. After completing his studies at Camosun College， he will be relocating to the greater Toronto area to find work in his field.
Stefan Kaban‘s （email@example.com）interest in helicopters was piqued during a co-op job with the B.C. Ministry of Forests， where he was regularly exposed to helicopter operations. He plans to complete his degree in Electrical Engineering at the University of Victoria.
Scott Morken （firstname.lastname@example.org） is a graduate of the Computer Engineering Technology program at Camosun College. He discovered his new favorite programming language while working for two co-op terms as a C# developer. Scott has also worked on many other hobby software projects. Updated versions of some of the project software are available on his web site （www.red79.net/Projects.html）。
Carl Philippsen （carlphilippsen@hotmail. com） is a graduate of the Electronics Technician Common Core program at North Island College and the Electronics Engineering Technology program at Camosun College. He is interested in a career in biomedical engineering and plans to further his education at the University of Victoria.
Kyle Wong （email@example.com）worked as an electronics technologist for several years. He plans to attend the University of Victoria and enroll in the Electronics Engineering degree program.
To download code, go to ftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2008/212.
1] G. Schmidt， "Don‘t Flicker！ Double Buffer！，" The Code Project，2007， www.codeproject.com/ csharp/DoubleBuffering.asp.
 Microsoft Developer Network，"HtmlDocument.InvokeScript Method （String），" https://msdn2. microsoft.com/en-us/library/ be9zzz62（VS.80）.aspx.
R. Scammell, Power Map, https://hobbiton.thisside.net/advmap.html.
ER900 TRS 900-MHz Transceiver modules
Low Power Radio Solutions
Microchip Technology, Inc.
Visual Studio 2005 IDE