ROCHESTER INSTITUTE OF TECHNOLOGY

Gaze-Controlled Robotic Platform

Independent Investigation -- Wireless communication between a PC and Arduino using two RF modules
Brief Overall Project Description
A system will be created that is capable of interpreting a scene layout and directing a robotic platform to a target location. The user will control the robot with two items, a laser pointer for indicating the target location and a push button to instruct the robot to move to that point. Upon pushing the button, software running on a laptop PC will take a snapshot of the field using a high-resolution webcam. Image processing algorithms will then determine how far and in what direction the robot must move. With this information known, instructions will be wirelessly communicated to the microcontroller controlling the robot. The microcontroller will interpret these instructions and convert them to signals to operate the wheel motors. Upon finishing the instructions, a second snapshot of the resulting scene will be taken and further adjustments will be made to correct any error in the movement. An LED will illuminate to indicate that the robot is completely done moving. An enhancement to the system, time-permitting, is the addition of eye tracking to accommodate users unable to easily reorient the laser pointer with high degrees of accuracy and range.

Author: Jeremy Thornton Submission Date: 1/6/2010 Instructor: Dr. Roy Czernikowski Course: Senior Design Projects I

Team Members Nick Harezga <neh5223@rit.edu> Investigating: Robot Movement System Phone: (716) 218-0449 Jeremy Thornton <jwt4997@rit.edu> Investigating: Wireless Communication Phone: (425) 318-2590 Matthew Wozniak <mrw5333@rit.edu>
Investigating: Coordinate Modeling and Computer Vision Phone: (440) 313-1556 1

Contents
Investigation Overview ................................................................................................................................. 3 Component Considerations .......................................................................................................................... 3 Nordic 2.4GHz Transceiver........................................................................................................................ 4 Holy Stone RF Link..................................................................................................................................... 4 XBee 1mW Wireless RF Module ............................................................................................................... 5 Proposed Solution ......................................................................................................................................... 6 Adapter Boards ......................................................................................................................................... 6 Communication ......................................................................................................................................... 7 XBee-XBee ............................................................................................................................................. 7 PC-XBee ................................................................................................................................................. 8 Arduino-XBee ........................................................................................................................................ 8 PC-Arduino ............................................................................................................................................ 9 Trade-offs ...................................................................................................................................................... 9 Testing and Validation .................................................................................................................................. 9 Performance Specification .......................................................................................................................... 10 Speed ...................................................................................................................................................... 10 Power ...................................................................................................................................................... 11 Price Breakdown ......................................................................................................................................... 11 Alternatives by component..................................................................................................................... 11 Appendix A: Resources ............................................................................................................................... 12 Appendix B: XBee Specification .................................................................................................................. 13

Investigation Overview
The purpose of this investigation is to mitigate the risk involved with wireless communication between the PC performing the image processing of the scene and the microcontroller controlling the robot. More specifically, this project requires a solution that can easily communicate with the Wee microcontroller (more compact Arduino prototype which became the Arduino Pro Mini) (Figure 1). This particular component is critical since the wireless interface is the only means to send instructions to the robot. There are several objectives to keep in mind for the wireless solution. First and foremost, it must be able to reliably transmit and receive data in a form that will make sense to the microcontroller. In addition, there should be a way to interface at least the transmitting node with a PC. Of course, simpler implementations are favorable. Secondly, since the robot is depending on a battery source for power, the lower power the wireless solution, the better, particularly when considering idle power consumption. And finally, while it is not 100% necessary, a bidirectional link would prove to be exceptionally useful for indicating when the robot is finished with its instructions.

Figure 1 Wee Microcontroller (Arduino Pro Mini 8MHz 3.3V)

Component Considerations
There are several wireless solutions that have been used in various publicly released Arduino projects. Because of this, provided the solution chosen fits the requirements set out for the project, it can be safely assumed that interfacing with the Arduino will be a relatively simple task. In this investigation, three possibilities were explored: 1. Nordic 2.4GHz Transceiver 2. Holy Stone RF Link Modules 3. XBee 1mW Wireless Modules

An important consideration in all this is the degree of simplicity in connecting to the microcontroller. All of these components were selected for investigation due to their price and availability. In addition, the operable range of communication for each solution more than exceeds the project requirements.

Nordic 2.4GHz Transceiver

==$20 with breakout, per module The nRF24L01+ wireless transceiver manufactured by Nordic Semiconductor is a compact, ultra-low power module designed specifically for embedded solutions. This particular transceiver draws a maximum of below 14mA when transmitting or receiving and as low as 26A when idling, though this is not a guarantee for the entire board. In addition, the operating voltage is identical to that of the Arduino, removing any need for special voltage regulation. As for the actual wireless capabilities, the built in hardware completely takes care of packet assembly, detection, validation and retransmission. If attempting to create a wireless serial link using this solution, SparkFun offers a serial interface board for an additional $20 as well as drivers and C code for interfacing the board with the computer. For communication with the microcontroller, a library for interfacing the nRF24L01(+) is openly available on the Arduino website.

Figure 2 Nordic nRF24L01+ with Ceramic Antenna

Holy Stone RF Link

==RX: $5 ==TX: $3 The 315MHz RF transmitter and receiver manufactured by Holy Stone Enterprise is a simple and inexpensive wireless solution compatible with AVR microcontrollers. This includes the ATmega168 used on the Arduino. Using the VirtualWire1 package for Arduino, turning these two modules into a wireless serial link using the digital I/O pins becomes trivial. However, there are two problems with this solution which would require special attention. The first is the fact that the RX module operates at 5V. Quick 4

research into voltage threshold information indicates that additional signal conditioning would be required to ensure that digital 0s fall below 0.3V and highs are no higher than 3.8V (the thresholds dictated by the ATmea168 I/O pins for 3.3 Vcc configuration). Logic high and low are cut off at much higher values for the RF receiver when compared to the Arduino. The second problem is that a second microcontroller would be required to interface the TX module to a PC while maintaining the reliability between TX and RX offered by the VirtualWire package. The alternative would be to come up with a custom solution which would be very time consuming. Power consumption by the RX module maxes out at roughly 3mA. The TX modules consumption is irrelevant to the project requirements.
1. VirtualWire is a software package developed for inexpensive RF communication between Arduinos. Package may be downloaded at http://www.open.com.au/mikem/arduino/VirtualWire-1.4.zip

Figure 3 RF Link Receiver (L) and Transmitter (R)

XBee 1mW Wireless RF Module

==$23 per module Digi (formerly MaxStream) makes a very compact and simple, low-power wireless module. The main model being considered is the 1mW XBee with wire antenna (Figure 4). At 3.3V operation, these modules allow for direct wiring with the selected 3.3V microcontroller. Current draw for this particular model ranges from about 50mA when transmitting and receiving to less than 50A when in its cyclic sleep mode. Unlike the Holy Stone RF link, each end has TX and RX capabilities. The biggest advantage to this module is its transparent mode of operation. When operating in this mode, the two modules act together as a wireless serial link. Because of this, no additional libraries are necessary for the Arduino to receive the data being sent. Also, even in this wireless serial link mode, the XBee will continue to take care of packet validation and retransmission of lost packets. 5

Figure 4 XBee 1mW RF Module

Proposed Solution
For this project, the XBee modules will be used for wireless communication. Referring back to the initial requirements outlined, the following is why this solution was chosen: Simplicity No additional packages or APIs are necessary to use the XBee as a wireless serial link. Reliability The XBee modules will completely take care of packet construction, transmission and validation. The specifications show that lost packets are automatically retransmitted. PC interfacing Through the use of a breakout board (more details below), the XBee can be directly connected to a PCs USB port and operated through ordinary serial port methods. Power consumption While the XBee is not the most efficient solution available, the use of sleep states will drastically reduce the total power requirement of the module. Bidirectional The XBee is fully capable of operating as a bidirectional wireless serial link.

The only explored solution that was easily eliminated was the wireless RF link by Holy Stone, as the operating voltages would require additional, potentially power hungry conditioning. That left the Nordic RF transceiver and the XBee. Although both Nordic and XBee have a plethora of documentation, tutorials and support packages developed for Arduino, the primary advantage the XBee brought to the table was the serial link mode. Additionally, this project has already been offered a pair of XBee modules by a colleague for the duration, free of charge.

Adapter Boards
The primary downside to the XBee modules is the non-standard pin spacing, making breadboard prototyping much more difficult. However, there are multiple solutions available to this. Sparkfun offers what appears to be a well-received solution in its XBee Explorer product (Figure 5a). In addition to 6

providing a spaced direct pinout, the board also provides signal conditioning and voltage regulation for devices up to 5V. There also exists a USB variant of this board for connection with a PCs USB port, though an FTDI breakout to USB cable or board would work just as well. A similar product is an adapter board created and sold by Adafruit Industries (Figure 5b). While functionality of the board is the same as the product offered by Sparkfun, this provides an external pinout of the most commonly used pins of the XBee module (including the necessary pinout for connecting to a PC) in addition to the wider spaced XBee pins. An FTDI breakout to USB allows standard serial communication with a PC when paired with the royalty-free drivers. Each of these costs around $10, and one will be required for each XBee.

(a) Sparkfun XBee Explorer (b) Adafruit XBee Adapter v1.1 Figure 5 XBee Adapter Boards

Communication
There are three distinct communication links that must exist and remain stable for this wireless solution to work: the link between XBee modues, the PC and an Xbee, and the Arduino and the other Xbee.

Figure 6 3 Communication Links XBee-XBee For use in this project, the XBee wireless RF modules will be used in the transparent (wireless serial link) mode. By default, XBee operates in transparent mode. In this mode, any data written to the modules 7

data-in (DI) pin will be immediately queued, packeted and transmitted, provided the module is not currently receiving wireless data. Similarly, as soon as wireless data is received, the data will be sent out on the modules data-out (DO) pin. Some important specifications are outlined below for this portion of the link. Up to 100 ft. indoor range (300 ft line-of-sight) 250,000 bps RF data rate Receiver sensitivity of -92dBm (claimed to result in 1% packet error rate)

PC-XBee Either of the two adapter boards mentioned earlier will make interfacing with the PC a trivial matter. XCTU is a piece of software supported by Digi that can be used to configure the XBee modules and ensure that all configuration parameters are written to non-volatile memory, a crucial factor in fitting the projects ease-of-use constraint. Unfortunately, this software is only compatible with Windows. However, this should not be a problem for two reasons. First, the modules will only need to be configured once, and it will not be up to the user to accomplish that task. Second, freely available work has been done in creating a Python-based terminal to make the modules easily programmable universally. Also, because the communication will be handled in transparent mode, the module connected to the PC only needs to be addressed as a serial port. This serial interface can be set up using the PySerial2 API developed for Python, for example. From the XBee specification, acceptable serial bit rates range from 1200-115,200 bps and include non-standard baud rates.
2. PySerial can be found at http://pyserial.sourceforge.net/pyserial_api.html

Arduino-XBee When using the XBee in transparent mode, interfacing between the Arduino and XBee also becomes trivial. In this case, the data out (DO) pin of the XBee may be directly connected to the serial data-in port of the Arduino. Below is some sample code that causes the Arduino to loop back any data received on the serial link. Note that the same range of serial data rates apply here as for the PC-XBee link.
void setup(){ // Start up the serial port, this value matches the data rate the XBee was configured for Serial.begin(9600); } void loop(){ // handle serial data, if any if(Serial.available() > 0){ myData = Serial.read(); if(myData == '\n') Serial.print(myData,BYTE); else Serial.print(myData + 1, BYTE); } }

Figure 6 Example Loopback Code for Arduino 8

PC-Arduino While this doesnt involve the wireless solution to the same degree as the other links discussed, it is worth mentioning. The instructions sent from the PC to the Arduino will be encoded into single bytes of data. The upper 3 bits will encode which operation should be performed (i.e. turn left, turn right, move forward, illuminate LED, etc), and the lower 5 bits will hold information defining parameters for the command. Depending on if it turns out that the movement range per instruction (or resolution of each unit) must be improved, a scheme can be implemented to allow movement instructions to have a 6 th bit available for the parameters. In addition to the instruction encoding, an encoding for diagnostics may be useful for reporting back to the PC. Being able to indicate that the serial buffer is full, instruction queue is empty or movement is complete would prove incredibly useful for debug purposes and simplify command issuance and movement error correction for the integrated system.

Trade-offs
As mentioned before, XBee does not offer the most inexpensive or lowest power solution. However, it was decided that the capabilities offered, combined with the two modules already on-hand, outweighed the benefits of the alternate solutions explored. The primary goal was to keep the implementation as simple as possible in order to eliminate as much of the risk as possible. While the RF link modules were by far the most inexpensive and least power consuming option at face value, the amount of work that would be required to implement a reasonably robust and reliable system for command issuance would have been far too costly. There would be large time investments required for the interfacing circuitry and the software running on the PC and Arduino. Had the XBee modules not been on-hand already, the Nordic transceivers would have been much more difficult to rule out, being a slightly less expensive and less power hungry option. However, as it turned out, using the nRF24L01+ would have required using additional libraries to easily communicate with the microcontroller and PC. Odds are this would have placed further restrictions on the usable platforms. That aside, the Nordic modules would still not offer the same degree of usability as the XBee modules in transparent mode, despite the openly available libraries for Arduino. Ultimately, lower power consumption was sacrificed for ease of use and cost to obtain the remaining required components.

Testing and Validation

Several tests will need to be developed to ensure the functionality of each component in this subsystem. Because of the nature of this subsystem, testing will likely require an incremental integration approach. Arduino serial communications In order to isolate this feature from the system, the Arduino will be connected directly to the PC. Code much like that present in Figure 6 would effectively test both the TX and RX capabilities of the Arduinos serial data pins.

XBee transparent mode This testing will require that either 2 PCs and 2 FTDI breakout boards be used or that the Arduinos serial link has been sufficiently validated. In either case, a PC and either a PC or the Arduino will be connected to the configured XBee modules. In the event of the latter, code similar to Figure 6 can be run on the Arduino while the PC writes data to the serial port and prints out the response. o If no response is being received, testing between two PCs is a good alternative. One PC would act as a transmitter, the other as a receiver. o An alternative to two PCs would be to have the Arduino perform a simpler task, such as illuminating an LED, when it receives a message. By doing that, confirmation can be made as to whether or not the initial transmission is being received. If it turns out to be the case that the Arduino is receiving data but not looping it back, reverse the roles of the PC and the Arduino for debug. Have the Arduino send data at set intervals and the PC simply listen for it. o If all fails, switch what is connected to each XBee to determine if the modules are the problem. Arduino command recognition Once again, utilizing similar loopback code or an array of LEDs, the Arduinos recognition of movement instructions will be validated. The PC may be directly connected to the Arduino for initial testing of this. XBee Cyclic Sleep Mode There is no mode which allows automatic wakeup of a remote XBee upon receiving RF data. However, the transmitting module will continue to retransmit until it receives acknowledgement. This testing will be to ascertain that a sleeping module will not end up resulting in a loss of data and will receive what was sent while in its sleep mode. o In addition to testing the feature, the ideal values for the timers must be determined through experimentation to achieve an optimal balance of power consumption and response time. Interference One final area of concern that must be tested to determine tolerances is that of external and internal noise. This system will need to be tested in the presence of other operating wireless devices for reliability. In addition, similar testing will be done in the presence of components (such as motors) that generate larger amounts of electromagnetic interference.

Performance Specification
Speed
Because the encoded commands will ideally be no longer than a single byte, the serial data rate will have no noticeable effect on the speed of the wireless communication. However, what must be taken into consideration is the duration of the XBees sleep cycle and the timeout before going to sleep. Compared to the speed of the image processing algorithm, the latency incurred by waiting for a wakeup should be negligible.

10

Power
After a set amount of time of inactivity, the XBee should enter its low power cyclic sleep mode. When in this mode, the XBee will periodically wake up to check for incoming RF data. If it detects data, it will wake up and remain in idle/receive mode until the inactivity timer elapses once again. As mentioned before, the crucial component in this is determining the values for both the cyclic wake up and inactivity timers. Both the XBee and the Arduino will rely on the same power source and should be capable of at least 9 hours of standby time and over 1 hour of regular user interaction.

Price Breakdown
As mentioned before, a large motivating factor for using the XBee modules is the fact that a pair was lent for use in this project. Since all but the adapter boards are already owned, the total price for this subsystem falls to $20 for the pair of XBee adapter boards. Component XBee 1mW Module XBee adapter board FT232R breakout board with USB Available at www.sparkfun.com www.sparkfun.com www.adafruit.com www.sparkfun.com Obtained? Yes No Qty 2 2 Price (ea) $23 $10 $14 $80 $20

Yes 1 Total Cost Less owned parts

Alternatives by component
Component nRF24L01+ Transceiver Modules Nordic Serial Interface Board Holy Stone 315MHz TX RF Module Holy Stone 315MHz RX RF Module Available at www.sparkfun.com www.sparkfun.com www.sparkfun.com www.sparkfun.com Obtained? No No Yes Yes Qty 2 1 1 1 Price (ea) $20 $20 $3 $5

11

Appendix A: Resources
Arduino website <http://www.arduino.cc> ATmega 168 Datasheet <http://www.atmel.com/dyn/resources/prod_documents/doc2545.pdf> Holy Stone RF Link Receiver Module Datasheet <http://www.sparkfun.com/datasheets/Wireless/General/MO-RX3400.pdf> Holy Stone RF Link Transmitter Module Datasheet <http://www.sparkfun.com/datasheets/Wireless/General/MO-SAWR.pdf> nRF24L01+ Datasheet <http://www.nordicsemi.com/files/Product/data_sheet/nRF24L01P_Product_Specification_1_0.pdf> XBee Datasheet <http://www.digi.com/pdf/ds_xbeemultipointmodules.pdf> XBee Manual <http://ftp1.digi.com/support/documentation/90000982_B.pdf>

12

Appendix B: XBee Specification

Figure 7 Xbee Specification from XBee Manual

13