Senior Design II Spring 2013

Transcription

1 Senior Design II Spring 2013 Knightro Kart Group 20: Elizabeth Lyons Oscar Orihuela Michael Scherban i

2 Table of Contents 1.0 Executive Summary Project Description 2.1 Project Motivation and Goals Objectives Division of Labor Requirements and Specifications System Overview Research 3.1 Wireless Communication Research Motor Control and RC Car Research Microcontroller Research Android Operating System Research Power Supply Research External Communication Research Project Hardware and Software Design Details 4.1 Design Model and Related Diagrams Bluetooth MSP : Power and JTAG : UART : Motor Controls : Power Management : Infrared Signal : LED Network : Software : Hardware Motor Controls Infrared Communication LED Network Android Application Design Remote Control User Interface Project Prototype Construction and Coding 5.1 Parts List and Parts Acquisition PCB Design, Vendor, and Assembly Final Coding Plan Project Prototype Testing 6.1: RC Car Testing : Bluetooth Range Testing : Infrared Testing : LED Network Testing 82 ii

3 6.5: Microcontroller Testing : Software Test Environment : Android Remote Control Testing : Administrative Content 8.1: Project Milestones : Budget and Finance Discussion : Project Summary and Conclusions..93 iii

4 1.0 Executive Summary The following documentation intends to outline the goals and requirements associated with the design, construction, development, and testing of an interactive Android controlled vehicle race system. The system in its entirety will be referred to as Knightro Kart from this point forward. Knightro Kart s development required extensive research, which is also documented within. The system will be developed by a team of three engineering students, of which two are majoring in Electrical Engineering, and one in Computer Engineering. Knightro Kart consists of a series of cooperative subsystems that rely on and control other subsystems. The subsystems are divided into two main components, the vehicles and the remote controls. For the purposes of the system, the final design will consist of two vehicles and two remote controls. The vehicle comprises an RC car, an MSP430, a Bluetooth chip, infrared sensors, an LED network, a custom circuit board design, and a power supply. The MSP430 will be our central processing unit and is responsible for translating any information received through Bluetooth or infrared communication into the appropriate action on the vehicle. The remote control consists of an applicable Android mobile device as well as the custom developed remote control application. The remote control application is responsible for interfacing with the device s built in hardware sensors and Bluetooth capabilities in order to correctly interpret the user s intentions and to correctly send those intentions to the vehicle via its Bluetooth module. The vehicle and the remote control rely on communication from one device to the other to produce a functioning system. The system is expected to allow two users to simultaneously connect to one of two vehicles through Bluetooth pairing between the remote control device and the Bluetooth chip on the vehicle. Bluetooth communication will allow constant two way communication between the remote control device and the paired vehicle with relatively little impact to system power. Users will also be provided with an enjoyable experience due to several factors. One of these factors will be the well-designed user interface on the remote control application. Also, the user will be notified of the current state of their vehicle in the race by the LED network on the vehicle. The LED network will be designed to notify users of their progress. Similarly, the course will be designed to include an infrared start line, which not only adds to the system s aesthetics, but also to the functionality of the course. These features and more are discussed at length in this documentation. 1

5 2.0 Project Description 2.1 Project Motivation and Goals As passionate gamers the team decided on the idea of creating a live remote control racing car game called Knightro Kart. The team took on inspiration from RC car racing mixed with the competitive edge of video games such as Mario Kart. When the team was presented with the task of going out and creating a challenging project that would enhance the curiosity of the world of engineering, it was decided that whatever was picked would have to be fun. The team knew creating a racing game like Knightro Kart would keep their interest, result to be a challenging task to accomplish and be proud of. The team believed the best way that other people would take an interest and would get involved in this competitive racing game is by involving the one thing everyone tends to carry around with them in the modern day, their mobile devices. This was a great opportunity to mix old school play such as RC car racing with modern technology such as Android applications, and Bluetooth. But furthermore the greatest motivation towards the project is that once the project has technically been completed, it is possible to keep adding on new features to it. These new features could be implemented by either adding new specs to the racing cars or even the race track that they will have to maneuver through in order to reach the finish line. All engineering students always strive to never stop learning, and never stop trying to better their technically skills. The goals the team plans to achieve throughout this experience is to try and master all of the devices and skills that will be used to create Knightro Kart. The team will learn to design a functional Printed Circuit Board to run all of the components that will be used in the race cars. On the printed circuit board the team will have to program a microcontroller, in this case the team has picked TI s MSP430 a low power but highly effective tool to control and manage all the networks working around it. The team will learn to program the MSP430 to connect with a Bluetooth Module. This Bluetooth module will serve as the link between the Knightro Kart race car and an Android application located in a mobile device. That being said the team will learn to create an Android application that will have to manipulate the android device s accelerometer to become the race car s new remote. The goal of modifying the existing RC cars that will be used in Knightro Kart is to give them new features, like the new LED network signals the team will learn to implement and mount on the car, as well as adding infrared readings to the car. The goal of these infrared readings the team will implement on the car is to successfully display and keep count of the laps and placement of the car during the race. The Team will learn how to use Pulse Width Modulation signals or PWMs in order to command the cars directions. This Project though fun will not be taken lightly, and with the amount of work that must be done it will be a long process. 2

6 2.2 Objectives As a self-funded project the team plans to implement all the needs to create Knightro Kart as efficient as possible in order to reduce cost. Each Knightro Kart race car is being modified to receive its directional commands from a new transmitter that will serve as the remote for the car. This will be made possible by an application that has been specifically created for Knightro Kart, allowing the transformation of a competitor s android device into the remote that will be controlling their RC race car during the race. The application will have several features such as having the ability to link up the race car and the phone together Via Bluetooth. Another Feature of the application is that serving as the remote of the RC car, the phone s accelerometer will allow the RC car to move forward, in reverse, and have the ability to turn Left or Right by tilting the phone in the competitor s desired position. A Track will be created on which the races will take place in order to keep the cars in a controlled environment. The Track is being designed to test all of the application s features with infrared sensors that will identify how much of the race the car has completed, and will have different turns that will force the driver to maneuver through. Objectives layout Objective 1: Create Android Device Application Objective 2: Construct Printed Circuit Board Objective 3: Test to power supply, to see if all components work Objective 4: Program MSP430 microcontroller to send/receive commands to/from The RC car s motor controls The LED displays on the RC car The infrared lights on the RC car The Bluetooth module attached to the MSP430 on the RC car Objective 5: Link Android application to RC car s Bluetooth module Objective 6: Test Android application connectivity to the RC car by implementing motor control commands. Objective 7: Test RC car s motor control movements, FWD, REV, LEFT, and RIGHT Objective 8: Test infrared readings to identify how far along in the race the car may be Objective 9: Test LED displays on car 3

7 2.3 Division of Labor Elizabeth Lyons Android application programmer Bluetooth Hardware LED Network Programming LED Network Construction RC car Tester Oscar Orihuela RC Car Modification Design LED Network Construction Motor Control Hook up and Soldering Track Infrared Construction RC Car tester Michael Scherban MSP430 programmer PCB Design Bluetooth Hardware LED network programing Infrared counter programmer Component Soldering RC car Tester Ultimately all team members became familiar with and participated on all of the tasks above. However, each developer had different strong suits. Labor was divided unequally among members for each task in the system. Members with extra knowledge in a particular area spent a greater percentage of their time constructing that area. Elizabeth Lyons is the Computer Engineer working on the Knightro Kart Experience. She was the lead on creating the remote control application that links the RC race car and the android device together. Her expertise lies in high level programming especially Java language applications. Michael Scherban is one of the two Electrical Engineers working on the Knightro Kart Experience. He was the team lead on programming the RC car s new microcontroller. His expertise lies in embedded systems and C programming. Oscar Orihuela is the second of two Electrical Engineers working on the project. He was primarily responsible for the components that enable the vehicle movement, as well as modifications to existing systems to implement our design. His expertise lies in power systems. 4

8 2.4 Requirements and Specifications Systems: Phone o Android 2.2+ o Bluetooth enabled o Allow installation of non-market applications o Built in accelerometers o Broadcast range at least 50 feet o Touch Screen Car o At least 2 hour battery life o Bluetooth enabled o Wireless range of at least 50 feet o Hard terrain compatible o Capable of at least 2 mph o 4 inches tall & 6 inches wide o PWM controlled servos o Two battery packs o DC motor for forward/reverse o Either DC motor or servo for steering Subsystems: Microcontroller o UART supported o PWM supported o Low power o At least 6 I/O ports for other subsystems Bluetooth module o Transmit and Receive range of at least 50 ft o UART supported o Runs own Bluetooth stack Infrared o Non 38kHz modulated o Isolated from ambient light Motor controls o PWM controlled for intermediate speeds, turning o H-bridge for forwards/backwards o Secondary power supply for higher current motor requirements. 5

9 2.5 System Overview To use the Knightro Kart project each user must first connect to a vehicle of their choice. To do so, each user must first open their Knightro Kart application on their Android powered device. The application allows a user to connect to a Knightro Kart vehicle. A user can confirm a successful connection by viewing the app which shows which vehicle they are currently connected to, as well as viewing an LED on board the vehicle. These are explained in detail in section 4.8. After a successful connection the user is able to notify that they are ready through the application menu. The vehicles will only start racing once both have notified they are ready. After both vehicles are confirmed as ready, a countdown will begin before the cars are ready to race. After the countdown the cars begin to race. The track size is dynamic and a full lap is indicated by the placement of the starting line. The vehicles must race over the starting line to increment their lap counter on the vehicle and the remote control. The cars will shutdown after three laps. After shutdown the cars can be placed again and readied. 6

10 3.0 Research 3.1 Wireless Communication Research In order to communicate between the vehicles and the android devices, some sort of wireless communication was necessary. Ultimately, Bluetooth was chosen as the best method of communication for Knightro Kart. Before settling on Bluetooth for the application, it had to be determined that this was the best method for the completed system. The options considered were NFC, Wi-Fi Direct, and Bluetooth. Wi-Fi Direct allows two devices to connect without an intermediate access point. Transfer speeds for Wi-Fi Direct are 250 megabits per second (Mbps) maximum. Also, WiFi Direct is touted as being able to transfer data between two devices as far as 656 feet away from each other. However, Wi-Fi direct is only supported on Android 4.0 or higher. Since the target devices are those that run Android 2.2 or higher, this method would not work for us. However, the final nail in the coffin for Wi-Fi Direct was that the MSP430 does not support this kind of connection. Alternatively, there was NFC (Near Field Communication). This kind of communication would not be practical for the design because it only functioned over an extremely short range of 4 centimeters or less. It would have been very impractical to race several vehicles when the controller had to be within 4 centimeters of the vehicle. This requirement alone automatically disqualified NFC as the choice of wireless communication. Finally, research was done on connecting the vehicles to the Android devices via Bluetooth. This option was by far the most preferable. All Bluetooth chips must adhere to a set of standards, which made developing with it easier. Another benefit is that Bluetooth is considered low-power. Low power devices were preferable, because they help to increase battery life and reduce the likelihood of overheating. Bluetooth technology uses short wavelength radio transmissions in the unlicensed industrial, scientific, and medical (ISM) band in order to create very secure personal area networks. The ISM band exists at the 2.4 GHz to GHz frequency spectrum. This eliminated any concerns over interference from other devices. It also eliminated any concerns over network loss due to third party devices, such as Wi-Fi loss due to a failing router. Bluetooth uses a technique called spread-spectrum frequency hopping to transmit signals. Spread-spectrum frequency hopping works by using 79 randomly chosen frequencies within a prescribed range. Bluetooth specifically switches between those frequencies 1600 times per second. As a result, it is very unlikely that two devices will be transmitting the same frequency simultaneously, 7

11 thus helping to eliminate concerns about interference. It is now unnecessary to explicitly ensure that any two of the remote controls are accidentally sending signals to the wrong vehicle. The personal area networks created using Bluetooth can be as large as 50 meters (164 feet). While 50 meters may not seem very large, it is more than enough for the purposes of the design, as the course must be visible to the user at all times. Realistically, communication may not reach the complete 50 meter range due to several factors. Such factors include the Bluetooth iteration used (1.0, 2.0, etc.) and the capabilities of the Android devices sending the remote control signals. Adding to the list of Bluetooth benefits was that communication between paired devices (the remote control and the assigned vehicle) was automatic. A sort of network is formed between the vehicle and its paired remote control. This network is called a personal-area network (PAN) or more specifically a piconet. Bluetooth is also low power, which is desirable in the system. Each transmission signal from the remote control to the vehicles consumes approximately 1 milliwatt of power, making Bluetooth s short term effect on the system power virtually negligible. Bluetooth operates at special standards, providing a uniform environment for all Bluetooth enabled devices. The standards originate from the networking standard. One part of the standard governs the maximum transfer speed of the devices. Bluetooth 1.0 has a maximum transfer speed of 1 Mbps, Bluetooth 2.0 has a maximum of 3 Mbps, Bluetooth 3.0 has 24 Mbps maximum, and Bluetooth 4.0 has 25 Mbps maximum. All Bluetooth iterations are designed to be backwards compatible to previous versions, meaning Bluetooth 3.0 will work on Bluetooth 2.0 and so forth. The device chosen for its low power and ability to run the Bluetooth stack is the Roving Networks RN-41. Since the microcontroller used is going to be low power, it will not be powerful enough to run the Bluetooth stack. The RN-41 also has built in UART support and acts as an RX/TX pipe, where a byte it receives wirelessly from Bluetooth is automatically pushed to its UART transfer pin. UART (Universal Asynchronous Receiver/Transmitter) is a system for pushing a byte of data from one device to the other, so long as both have UART implemented. One important aspect that makes UART unique is the fact that both systems do not need to be on the same clock cycle, which minimizes the amount of wiring needed between each device. This is where the title asynchronous comes from. UART works by taking a byte of data and transmitting it serially, bit by bit to another device. The secondary device has a receiver which rebuilds the bits back into a complete byte. During this process the byte is converted from a parallel form, to serial, and back to parallel. Since 8

12 the two devices are on different clock signals it is important for both devices to be configured the same. These configurations include: Baud rate (symbol Bd) which is a measurement for pulses per second. A common baud rate is 9600Bd, which means it supports 9600 pulses per second. It is important that the baud rate is high since one device can send the signal at any time, since they are not synchronized the other device needs to pick up the signal immediately. Another configuration is start bit, a signal that the byte has been completed. Data bits, which is the amount of bits that will be sent and received from each device, typically 5-8. UART works by holding the transmit and receive lines high, then once data is ready to be transmitted a start bit is sent, which is where the line is brought low for a cycle, the data and start bits are to follow. This means it will be important for the selected microcontroller to also have UART support. 3.2 Motor Control and RC Car Research A decision that impacted the way the RC race car was modified for Knightro Kart was the type of race car that was used. The team planned to use one of three different types of RC cars. The first type was an RC car with two motors that was controlled by two different H-bridges, that command the front and rear motors of the car to spin the wheels of the car in certain directions. The second type was an RC car with two motors, where the rear motor was controlled by an H-Bridge that would cause the car to move forward, or in reverse. Now the front motor of the car would be controlled by a servo, which depending on its pulse width modulations would turn the car, left or right. The third type of RC car that the team was considering was an RC car with 3 motors. The first motor is the rear motor, which again would have been controlled by an H-bridge that caused the RC car to accelerate forwards or in reverse. The second and third motors are located in the front of the car, each being controlled by a different servo. Keep in mind that the servos and the H-bridge both receive their instructions from the microcontroller. In order to take full control and direct the RC race cars used it was important to mount the microcontroller, in this case the MSP430G2553 with the Bluetooth module installed, on each of the race cars. Most RC cars carry the RX2C- ATS302R chip whose pin layout is displayed below in figure The Pin layout and Block Diagram of the chip is found on the 4 th page of the datasheet for the TX2C-ATS302T (transmitter) / RX2C ATS302R (receiver). 9

13 Figure 3.2.1: Courtesy of Actions Semiconductor Co. Datasheet An option to mounting the MSP430 microcontroller on the RC race car being modified would have been to solder wires from the MSP430 to the output pins of the RX2C that send over the instructions to the H-bridges or servos to move the car forward, in reverse, right, or left. By doing this, whenever the microcontroller would have received its commands Via Bluetooth from the Android application, it would have been able to send the commands over to the system connected to the motors in order to direct the car. The original RX2C chip on the car would still be functional but because it would not have been able to communicate with the car s new transmitter, the android device, it would not have been used. Another option to mounting the MSP430 on the race car was to completely take out the RX2C Chip and replace it with the MSP430. Due to the RC race car s manufacturing the RX2C chip came permanently attached to the RC race car s printed circuit board, so in this case the entire circuit board would have been replaced by the team s own custom board, that would include the MSP430 connecting the car s new H-bridge or servo. The H-Bridge was the circuit that was directly connected to the motor(s) of the car. When the RC car has two motors controlled by two different H bridges, the H-bridge connected to the rear motor would have controlled the Forward and reverse movement of the car. While the front motor connected to the second H- Bridge would have controlled the car s ability to steer to the left or right direction. An H-Bridge is usually made up of a circuit containing 4 transistors following the general schematic layout below. 10

14 Figure 3.2.2: Shows General structure of an H Bridge The H-Bridge follows the sequences below, where 1 = closed and 0 = open. S1 S2 S3 S4 Result Motor Moves Right Motor Moves Left Motor Free Runs Motor Breaks Motor Breaks Shoot-Through Shoot-Through Shoot-Through Table 3.2.3: H-Bridge Sequences Texas Instruments offers an integrated circuit chip called the SN which implements the H-bridge circuit just as well as if the H-bridge circuit had been implemented using only discrete components, giving us the option of saving space on the car and turning out to be overall more cost efficient seeing as the TI SN is available for $1.85 from the TI website. The SN has the ability to run two motors through it allowing it to be the ideal choice, so the H- bridge chip will be able to command the car to move forward, in reverse, left and right. 11

15 The planned layout for the SN is displayed below, and the non-custom layout may be found in the SN Quadruple Half-H Driver Datasheet. Figure 3.2.4: Courtesy of Eagle Circuit Builder, & TI datasheet The SN needs at least 4.5 Volts in order to work, so set VCC1 to a regulated +5V in order for the chip to work, when needed a capacitor was be added at the VCC1 input to clear up the feedback and keep a constant voltage. Once the chip was working the VCC2 needed to be activated by directly connecting the RC car s battery to it with a max voltage of 36V (which is way more than was needed for this specific project). The factor that enabled each pin was whether the pin was set to High (at least 5V) or Low (0V). In order to enable Motor 1 or Motor 2 their pins must be set on high, and setting the forward, reverse, left, or right Pin to high will enable that command, forcing the corresponding motor to act as instructed. 12

16 Path 1 Path 2 Transmitter (Android Phone App) Transmitter (Android Phone App) Receiver (Bluetooth Module) Receiver (Bluetooth Module) MSP430 MSP430 AS-RX2 H-Bridge H-Bridge Two 4 Transistor H-Bridge Ti SN H-Bridge Motor Motor Figure Available Paths for Modifying Race Car Type 1 The figure illustrates the flow and direction that the instructions of the Android application would take in order to reach the RC race car s motor controls and steer the car. The figure on the left part of the figure shows the MSP430 soldered 13

17 onto the RC car s original board, while the one right part of the figure shows the original RC car s PCB having been replaced by the team s design circuit board. Modifying a car with servos When using a car with servos it is important to understand that the servos must be directly connected to their own power supply because each servo requires between 4.8V 6V of power in order to turn on, and because the MSP430 was being used for Knightro Kart, it would not be have been able to power them. The rear motor of the RC car with servos would still have been an H-bridge who will receive its instructions from the MSP430 microcontroller and once the instructions are decoded the H-bridge will command the rear motor to spin in a certain direction, causing the car to accelerate forward, or move in reverse. The front motor of this type of car is part of a servo that receives its commands, in this project, from the MSP430 and the motor by applying on and off voltage signals to the motor. Depending on the length of the PWM signals being sent to the motor, it would have caused the servo s drive shaft that is attached to the wheel of the car to turn to a specific angle, turning the car s direction in the process. For a servo motor, there are three cable connections that bring the servo design to life. The first cable is the DC voltage usually ranging from 5 6 volts in order to power the servo, which means this cable should be directly connected to the RC race car s power supply, because the car s microcontroller in this case being the MSP430 will not be able to power it. The second cable is ground, and the third cable is the signal wire which must be directly connected to the MSP430 in order for the servo to receive its instructions. The Receiver talks to the Servo through the signal wire by using simple on and off pulse signals, so if there is no input signal coming in from the MSP430 then the servo will stay at rest and do nothing. These pulse signals are also referred to as Pulse Width Modulations or PWM. A PWM signal has three parameters that identify it, the first one is the wave s peak to peak voltage, the second is the square wave s frequency and the third is the wave s duty cycle. The signal s duty cycle is the duration of the positive pulse in a PWM signal. 14

18 Figure 3.2.6: Positive Pulse Width s depending on a wave s duty cycle The duty cycle would have directly influenced the position on the servo s drive shaft. In order to change the direction of the servo, which will ultimately turn the wheel of the RC car, one must change the length of the positive pulse from the PWM by changing the wave s duty cycle. By making the pulses longer, it would have caused the servo to align itself in one direction, and by making the pulses shorter, it would have caused the servo to align itself in the opposite direction. Figure 3.2.7: Servo process Flow Chart Inside of a servo there is the controller circuit that decodes the PWM Signal, and powers the motor by connecting it to the power supply. Depending on the voltage coming in from the PWM signal, the motor powers the gear box, which shifts the drive shaft to a specific angle. The last part of a servo is its feedback potentiometer that is attached to the drive shaft. Every time the drive shaft moves, the potentiometer moves with it, and the potentiometers main job is to read the angle it s in, calculate the voltage coming through the servo, and report it back to the controller circuit. Once the potentiometer does its readings and sends back the information to the controller circuit, if the potentiometer s voltage is greater than the servo s reference voltage, it will cause the motor to spin one way changing the direction of the wheel. If the potentiometer s voltage is less than the servo s reference voltage coming in from the PWM signal then it will cause the motor to spin the other way again changing the direction of the wheel. The figure below shows all the parts within a servo, in order to better understand the way a servo works. 15

19 Figure 3.2.8: Courtesy of PCB Heaven.com 16

20 Figure 3.2.9Available Paths For Modifying RC Car With an H-Bridge and a Servo The figure above illustrates the flow and directions that the signals from the Android application would follow in order to reach the RC race car s motor controls, when a car has an H-bridge and one servo motor. The third type of car that was described at the beginning of the section was an RC race car with 3 motors, which included one H-bridge at the rear of the vehicle controlling the RC car s forward and backward movement, and the two motors in the front controlled by 2 servos. These servos would only be necessary for large RC car s and would not be ideal to use for Knightro Kart s purposes. But if the team would have used an RC car with two servos in the front, both of the servos would have been soldered together at the input signals so that both of the servos 17

21 would have received the same command at the same time in order to turn the wheels correctly, making the larger RC car drivable. Figure Available Paths for Modifying and RC Car with an H-Bridge and Two Servo Motors The figure above illustrates the flow and directions that the signals from the Android application would follow in order to reach the RC race car s motor controls, when a car has an H-bridge and two servo motors, each powering only one front wheel. Types of Servos Because our team is self-funded, we were trying to keep this project as cost efficient as possible but at the same time we are trying to give our race cars the best hardware pieces that would allow them to serve their purpose. When dealing with Race cars that have servos on them it is also important to see the type of servo that will be implemented on the car. An RC race car can have either 18

22 a Digital or Analog Servo. There is no physical difference between a digital and analog servo, they both have the same parts. They both have a controller circuit decoder that gets its commands from the car s receiver and sends the signal to the motor, in order for the motor to spin in a specific direction, which aligns the gear box and drive shaft positioning the wheel of the car. The main difference between the two is the number of pulse modulation cycles they do per second. The Analog servo does an average of 50 Cycles per second, and works under the theory that if the PWMs have a high duty cycle then it causes the wheel to turn a specific way, and if the PWMs have a low duty cycle then it will cause the wheel to turn the opposite way. The Digital Servo is designed to increase the number of pulse signals that are sent to the servo motor. For the digital servo there is a small microprocessor that increases the pulses from around 50 pulses to about 300 pulses per second. The only difference here is that the scale at which the length of the PWMs are being judged by the servo in order to turn the wheel is adjusted, and because more signals are being read per second the response time for steering and changing directions is better in a digital servo than in an analog servo. Even though the digital servo gives a better response time than the analog servo, the digital servo is very power hungry and takes more power to run and is also more expensive. For the sake of Knightro Kart either type of servo would be of use, but as described earlier in motivations, this is a project you can keep improving for a very long time. Figure : Left: Long Pulse Signals, Right: Short & Frequent Pulse Signals 3.3 Microcontroller Research In an industry that is completely flooded with microcontroller options it is important to pick the best one. There are several companies that develop microcontrollers, from corporate giants like Intel or Texas Instruments, to smaller companies such as Microchip or Maxim. With tens of thousands of microcontrollers alone listed on component distributor websites, there are a high number of options, configurations, and even user preferences when it comes down to selecting the right microcontroller. Knightro Kart has many hardware interfaces that requires a well coded microcontroller to receive, interpret, and give commands to other systems of hardware on the vehicle. The microcontroller has the ability to communicate serially, has PWM outputs, and enough I/O. Other features to kept in mind are power usage, operating temperatures, and available memory. Since the group is 19

23 ran entirely on a self-funded budget, a giant consideration was placed on cost, and development boards can range from $50 to several hundred. The next consideration is documentation and community support. Then it was decided that the microcontroller will be a low power variant. Since a powerful CPU such as ARM would use more power than necessary. The Bluetooth module selected uses UART to communicate so that is how it was decided to use a microcontroller that supports it natively. By hardware support, it means that the feature requires minimal configuration to operate properly, as opposed to it being implemented as software which reduces reliability, requires more memory, and makes it unnecessarily more difficult. Since the option is available for a minimal notice in cost it was be taken. The project was expected to have at least one motor and either a secondary motor or servo. Since the project has multiple ranges for turning radius and operates on different speeds, PWM is a required feature. The microcontroller selected must have enough I/O ports to support the many hardware modules on board the car. The project is designed to be used outdoors and during daylight it is expected to be directly in the way of the hot sun, it is a requirement for the microcontroller to still be operational even on a hot day with high ambient temperatures. As a battery powered device, the microcontroller will be able to utilize low power modes to preserve as much of the battery life as possibly, this reduces the need to have a full battery as backup. There are two attractive development boards that fall into the category of low cost which narrow down the choices of microcontrollers to an ATmega328 or a variant of the MSP430. Both of these have variants which support our necessary features. ATmega328 with Arduino Bootloaders Arduino is a popular microcontroller platform for hobbyists and developers because it is easy to use and powerful. The Arduino board comes standard with an ATmega328. However, used with the Arduino environment, the chip will run Arduino bootloaders and not be programmable with the AVR Studio software from Atmel. The chip would instead have to use the Arduino IDE which is not as intuitive as a full fledge software suite from a manufacturer, although it is free of cost. C programming can be used to program the ATmega328 and Arduino bootloaders offer significantly easier programming, where functions are used to replace much of the work that goes into configuring ports and other hardware supported features. ATmega offers operating voltages of -40 to 85 degrees Celsius which equates to a max operating temperature of 185 Fahrenheit which will be sufficient enough for using in the sun. Other aspects include 8 bit processing and up to 20 MHz operating frequency, a 1.8 to 5.5V operating voltage, and 32kBytes of flash programmable memory. The ATmega328 natively supports UART as well as PWM. The power usage profile of the device is as follows: 20

24 Active Mode CPU and all clocks 200 ua active Powersave Most clocks off.75 ua Power down All clocks off.1 ua Table 3.3.1: ATmega328 power profile There are up to 23 available I/O ports and is available in PDIP or surface mount options. MSP430G2553 The MSP430G2553 is one of the options of microcontroller to choose from in the Launchpad developer kit. The Launchpad kit is a board similar to the Arduino but uses an MSP430 and is manufactured by Texas Instruments. Since it is manufactured by T.I. the suite of tools for programming their processors is available to use, Code Composer Studio. Albeit the coding is more difficult in Code Composer Studio, it offers useful tools for debugging the software which includes a memory browser and disassembly viewer. It can pause the processor at any time or at a predefined line of code and view the contents of memory addresses and registers. Although this software is expensive, there is a free license that allows up to 16kBytes to be written to the MSP430. Code Composer Studio has macros defined for specific memory locations and bit masks for convenience. The MSP430G2553 is a 16 bit microcontroller with 16kBytes flash memory for programming, which is the code limit for the freeware version of CCS. It has an operating voltage of 1.8 to 3.3 V, up to 16 MHz operating frequency, and a max operating frequency of 185 Fahrenheit. It natively supports UART and PWM. The graph in figure outlines the power profile of the MSP430G2553 Figure 3.3.1: MSP430G2553 power profile, Courtesy of T.I. The MSP430G2553 has up to 24 I/O ports based on packaging and comes in surface mount and DIP options. 21

25 Comparison and Decision Since this is the first time some of the group members are doing a project on microcontrollers and interfacing with other hardware, it would be preferable for the microcontroller to have excellent documentation and community support. At the time of writing this there can be found over 40 user guides and over 200 app notes on the T.I. website alone for the MSP430 version of the Launchpad. Along with this is T.I. s wiki with material and workshops from beginner to expert level development. T.I. also hosts the E2E forum to correspond directly with engineers at T.I. Arduino has plenty of libraries and resources available, websites dedicated to projects built with it and acquiring parts specifically compatible with the kit. The Arduino has a massivefollowing, although both kits are aimed hobbyists. The Launchpad is just a younger brand. The comparisons of both microcontrollers is outlined in table MSP430G2553 ATmega328 Coding C, Assembly C, Assembly *Contains functions unique to Arduino to make coding easy UART support Yes Yes PWM suport Yes Yes Clock Speed 16MHz 20MHz Operating Temp 185 F 185 F Operating Voltage 3.3 V 5 V Flash Memory 16 kbtyes 32 kbytes Active Mode Power 300 ua 200 ua Low Power Mode.1 ua.1 ua I/O Ports Up to Table 3.3.2: Device Comparison Based on table it doesn t appear that the differences are too significant. Both have the required features for the project and utilize low power modes, in fact the ATmega328 uses less power in active mode and has more flash programmable memory. However, it was concluded that the difference in power and memory was not significant enough to have an impact on the overall goals of the project. It was decided to go with the MSP430G2553 because of the advantages Code Composer Studio has when it comes to coding and debugging. Although Arduino offers methods for easier coding, using Code Composer Studio will give valuable experience in embedded programming. MSP430G2553 has hardware UART supported in the form of the Universal Serial Communication Interface (USCI) and PWM available in the Timer_A subsystems. UART is going to be utilized to communicate with the selected Bluetooth module. So it is required for both to have the same configuration to be effective. The 22

26 configuration the project will be using is a 9600 Baud Rate, 8 data bit length, no parity, and 1 stop bit. These settings are well within the means that the microcontroller can support. A functional diagram of the MSP430G2553 is given in figure Figure 3.3.2: MSP430 functional diagram, courtesy of T.I. While the MSP430G2553 is connected to the Launchpad it will be in a 20 pin PDIP package. It will be programmable via USB with a PC. The Launchpad has on board emulator support for connecting to the PC with the USB cable. Only PDIP packages are compatible with the Launchpad. One option when programming the prototype would be to use a 20 pin socket on the circuit board and just switch the packages between the Launchpad and the prototype circuit board. This would eliminate the need for more circuitry to interface with chip while it is connected to the circuit board, but that would require for the chip to be on the Launchpad to be programmed, PDIP packages also have less ports. This would eliminate the benefits of using Code Composer Studio to debug. So it was decided the project will use a surface mount package that offers extra ports, CCS debug perks, but also require extra circuitry to interface with a PC. The extra circuitry required will use the Joint Action Test Group (JTAG standard) that uses a 14 pin header and an external emulator to interface with the chip. It only needs to interface with a few pins on the MSP430. The selected surface mount package is the 28 pin TSSOP, which also uses less circuit board real estate and is permanent till unsoldered. 23

27 3.4 Android Operating System Research The developers chose to use the Android operating system as the basis for the remote control for several reasons. These reasons included cost, availability of knowledge, and access to the systems. There were several systems that the developers considered before deciding on Android, principle among them was Apple s mobile platform, ios. Ultimately, the developers knew it would be more user friendly and novel to use a mobile device as the platform for the remote control. However, deciding between ios and Android was slightly more difficult. First, developers took into account the programming language used on each operating system. The remote control application requires high level programming, the construction of GUIs (graphical user interfaces), as well as interfacing with built in hardware. ios uses Apple s own Objective-C language. This language can easily be figured out by programmers who are familiar with C and C++ programming languages. Unfortunately, the developers had never used Objective C, and were unfamiliar with C++. On the other hand Android uses Java and XML to program mobile applications. This was a plus for the development team, as the developers were already familiar with Android programming as well as traditional Java programming. Another factor that was considered when choosing a mobile operating system was the availability of reference material and the openness of the developer environment. Android is well known to be an open source development platform. So Android s parent company, Google, has provided hundreds of pages of reference materials on various Android features. The Android developers website has seemingly endless reference documents on the separate classes, types, and structures built into the Android ecosystem. Similarly, there are many resources for developers on subjects like setting up the development environment, as well as tips for designing the best user interface. Android developers are also free to use any development software they choose. On the other hand, Apple s development process is more restrictive. The developer must use the development tools they are given. However, there is a wealth of technical resources and reference material on Apple s developer website similar to those on the Android developer website. Unfortunately Apple requires developers to enroll in the ios Developer Program to create fully functioning applications. The enrollment fee is currently $99 per year. The enrollment fee was a significant deterrent for us when it came to choosing an operating system. Android does not charge developers to develop, but they do charge a registration fee for developers who want to put their applications on the Market. However, Android allows developers to download their application directly from the development environment to their personal devices. Therefore, for the purposes of the system there will be no need to 24

28 publish the application to the Android Market, and development of the remote control will essentially be free on the Android OS. A final factor that influenced the developers decision to choose Android s OS over Apple s ios was the availability of hardware devices. None of the system developers have immediate access to Apple s mobile devices, which are often expensive to come by. Alternatively, all developers have immediate access to at least one Android mobile device. Given the previous knowledge of the developers, the cost of development, and the availability of hardware, it was decided that Android s mobile OS was the best choice for the remote control in the system. Choosing an OS was only the first step in researching it. Next developers had to determine the various features and intricacies of the Android OS. Android has gone through several iterations over the years, adding new features every time. However, not all users receive the updates. Even amongst the team s developers, no two devices were running the same iteration of the Android OS. As a result it had to be determined which versions of the OS would be developed for. The developers decided to develop the remote control for the platforms that the Android devices were most likely to contain. Figure below details the percentage of users who use devices at each operating system iteration. It can be seen that by targeting devices at Android OS or higher, it is possible to develop for approximately 94.2% of the Android ecosystem. By developing for OS and higher, developers have also eliminated device compatibility concerns within the completed remote control application. Figure 3.4.1: Breakdown of User Distribution Over Android s Mobile OS Ecosystem; image taken from Android s open source developer website, see Appendices for explicit permission 25

29 Choosing the target OS iteration was also not enough. Developers also had to ensure that the operating system supported the various features required for the remote control. These features included Bluetooth communication and sensor support for the accelerometer. Fortunately Bluetooth support was introduced as a new platform technology in Android 2.2. Android 2.2 also introduced improved multi-touch gesture recognition. Android expanded on the Bluetooth support with additional security features. Sensor support already existed in previous iterations of the OS, so the accelerometer was still supported. 3.5 Power Supply Research After taking into account all the requirements and all of the components that the Knightro Kart RC race cars powers, the team decided that each RC car would have to carry three different power supplies. Each RC car must be able to power a front motor for steering, a rear motor for accelerating the car forward and in reverse, an H-bridge, a Bluetooth module, an LED display and a microcontroller. The team decided that the best way to power all of those components would be with two battery packs that would produce 9V each, and another external power supply to power the two motors. Once we have our battery packs in place, Linear Regulators would have been used to dial down each power supply s voltage to the specific amount needed to power each part of the car. The Bluetooth module and the MSP430 microcontroller both require a constant voltage of 3.3V to power them. The first battery pack s objective was be to give off 9V that was connected to a linear Regulator which dropped the voltage from 9 volts to 3.3 Volts, in order to meet the power requirements of the Bluetooth module and MSP430. Since there are micro servos, standard servos and giant servos, the second battery pack s voltage could have varied in potential but generally each standard servo motor used required a constant 5V input voltage in order to get its system working, so again to be on the safe side the team used a 9V battery pack to power the servo(s). The team s SN H-bridge chip would have also been powered by the second battery pack and like a standard servo requires a constant input voltage of 5V. The team used TI s Linear Regulator UA78M05 to step down the second battery pack s voltage from a 9V input to a 5V output which connected to the H-bridge and servo motor(s) of the car. An outline of the Linear Regular UA78M05 is displayed below, and can be found on the first page of the Regulator s Texas Instrument Datasheet. 26

30 Figure 3.5.1: Courtesy of Texas Instruments The figure above is the general layout for both of the linear regulators that could have been used for this project due to their Specification package shown below, which can be found on page 2 of the Regulator s Texas Instrument Datasheet. Figure 3.5.2: Courtesy of Texas Instruments Moving away from the discussion of how to power the RC race cars, there were infrared sensors at the starting line of the race that needed their own power supply as well to power on. The purpose of the infrared sensors at the starting line was to signal the lap counter that is programmed into the MSP430 to send a signal back to the Android application in order to tell the RC car driver how many laps the RC car has travelled in the race. Since the requirements to finish a race in Knightro Kart is to go around the race track 3 times the infrared sensors allowed to keep track of how much of the race is left. 27

31 Types of Battery Packs There is a large variety of battery packs that would have given the team a working race car. The most obvious one would have been a combination of 6 AA Lithium batteries each generating a voltage of around 1.5 volts, therefore meeting the 9V requirements to power the RC race car. Though keep in mind that since two battery packs are needed it would bring the AA battery count up to 12 different batteries that would have to be mounted on the car taking up a lot of unnecessary space. The reason a lithium battery was picked over an alkaline battery for this project is because even though lithium batteries are more expensive, they have the ability to last longer than the alkaline battery and can operate in different environment conditions. Another power supply battery pack option was to purchase two 9V Lithium batteries. These batteries would power the entire car and they would not take up much space when mounted on the car. Taking the cost of purchasing 12 AA Lithium Batteries compared to the cost of purchasing only two 9V Lithium Batteries is significant, and due to the team being self-funded purchasing the 9V Lithium Batteries benefited us financially. Figure 3.5.3: 9 volt battery It is always good to have a way to turn your system off to save energy and in this case, it is very beneficial to install a toggle switch to the circuit in order to save battery power. The Switch was installed in between the linear regulator input and the 9V battery. Below is the switch that was used. Even though the infrared LEDs only required 1.5V in order to function their battery pack was also another 9V lithium battery with its own toggle switch that way we could use as many IR LEDs we wanted without worrying about voltage distribution or worrying whether the battery could handle the load. 28

32 Figure 3.5.4: Toggle Switch This switch has three main cables that were connected to the circuit, the first cable is connected to a common ground, the second cable is connected to the 9V battery, and the third cable is connected to the input for the linear regulator that is connecting to either the servo motor(s), or the H-Bridge depending on the type of RC race car that was modified. Figure 3.5.5: Represents Power Supply Distribution 29

33 3.6 External Communication Research The project introduces a more dynamic experience. So it was decided to have an external element to interact with the cars, giving a boost of speed, in the form of a station on the track. This can also be used as a form of timekeeping and counting the number of laps. The project also benefits from implementing this at the start line to be able to keep track of how long it took for the car to lap. The project has many options available to us to achieve this: Infra-red, RFID, or magnets. Infra-red: Have a station with a powered infra-red emitter, and a detector on the car. When the car detects an infra-red signal, run the appropriate response on the car. o Pros: Cheap, simple to implement (only needs to detect a signal on the MCU) o Cons: Need to make sure there is nothing emitting more infra-red than our emitter (interference) RFID: Have RFID tags at the start line and detectors on the car. When the car gets into the proximity of a RFID tag, run the appropriate code on the MCU. o Pros: Could possibly give each tag a different ability for the car to use. o Cons: Expensive, RFID is close proximity, harder to code and implement Magnets: Have magnets across the start line, and a reed switch on the car. When the car passes the start line it will close the reed switch, which would trigger the appropriate code on the car. o Pros: Cheap, easy to implement. o Cons: Need to make sure enough magnets are used to close the reed switch. Considering the pros and cons of each option, it was decided that the project will use infra-red. Infrared LEDs are relatively cheap, costing just a few dollars for a pack. Two options are available for the sensing of infrared light: receiver modules and phototransistors. The following displays the difference between the two: Receiver module: Modulated at 38kHz. o Pros: Accurate at filtering out light other than the intended source o Cons: Requires the source to be at a frequency of 38kHz. Would require additional circuitry or another MCU to achieve this. Phototransistor: Transistor that is biased by infrared light. o Pros: Easy to implement, requires minimal circuitry with only a power source and resistors. o Cons: Sensitive by all sources of light. 30

34 Based on the pros and cons, it was decided to use a phototransistor. A phototransistor will minimize cost and reduce complexity. The device will have to be placed strategically to reduce the ambient light from the environment. The phototransistor chosen is from Lite On Electronics and the infrared source chosen is EL-IR908-7C from Everlight. 31

35 4.0 Project Hardware and Software Design Details 4.1 Design Model and Related Diagrams The following is diagram of the project including all the subsystems required for operation and the interconnections. Figure 4.1.1: Project diagram The subsystems are broken down as follows and their design will be explained further in detail following in this section. 32

36 Bluetooth: Includes the phone and the module on the car. Microcontroller: Includes the microcontroller, its interconnects, and software. Power supplies: for providing the necessary voltages for each subsystem in the project. Motor controls: interprets signals for the motors to function Infrared: provides the microcontroller the ability to sense infrared in the environment 33

37 4.2 Bluetooth Communication between the remote control and the vehicle relied completely on Bluetooth communication. Some features of Bluetooth were discussed previously in section 3.1 Wireless Communication Research. The Knightro Kart system uses a Roving Network RN-41 Bluetooth Module. The RN-41 was beneficial to the system, because the MSP430 was not powerful enough to run a Bluetooth stack and natively support UART out of the box. So, in order to transmit and receive serial communication, the RN-41 module was used. The Bluetooth module acted as the middleman between then remote control application and the MSP430. This relationship is described by Figure below. Note that the figure is created from the Bluetooth module perspective. Figure 4.2.1: Bluetooth Module Relationship to System Communication The Bluetooth module was configured to match the settings of the MSP430 and the remote control device s Bluetooth. The Bluetooth module was serially connected to another device for configuration. On the connected device, $$$ was entered to access the command line. Within the command line the baud rate could be changed. For the purposes of the system, the baud rate was set to The Bluetooth module also had 8 data bits with 1 stop bit and no parity. The Bluetooth module was connected to the MSP430 in the final system. To do so, the Bluetooth UART_TX line will go to pin 3 on the MSP430. Similarly, the Bluetooth UART_RX line will go to pin 4 on the MSP430. The Bluetooth module contains a single data buffer that holds data until it is used. The Bluetooth module will have hardware flow control. Flow control checks that the data buffer is not overwritten, and is a form of handshaking between connected devices. However, the Knightro Kart system depends on continuous data transfer, so the system will be function more efficiently without flow control on the data buffer. Flow control would impede continuous data transfer. In order to bypass hardware flow control UART_CTS and UART_RTS must be shorted. UART_CTS represents clear to send while UART_RTS represents request to send. Also, the GPIO2 pin will be connected to an LED and a 330 ohm resistor. This LED will represent whether something has been paired. When the LED is on, the Bluetooth module has been paired to another device. When the LED is off the Bluetooth module has not been paired to another device. Similarly, the GPIO5 pin will be connected to another LED. This LED will blink when the Bluetooth module is not paired. Likewise this LED will not light up when the device has been paired. The addition of the LEDs to the GPIO2 and GPIO5 pins will assist in 34

38 debugging the Bluetooth related code. These connections are illustrated in the Eagle schematic for the system. The Bluetooth portion is shown in Figure Figure 4.2.2: Bluetooth Module Schematic The Bluetooth module will be powered by a 3.3V regulated power input line that is shared with the MSP430. Bluetooth module will draw 30 ma when connected. As close as possible to the Bluetooth module on the power input will be a 0.1 micro Farad decoupling capacitor. The decoupling capacitor will filter noise. All ground pins on the Bluetooth module will be grounded. At the top of the Bluetooth module is a chip antenna. It is imperative that the chip antenna not suffer from interference. To ensure interference does not occur, the chip antenna cannot have any routing, ground planes, or vias underneath it. Also, all wires and signal carrying components must be routed around the antenna chip in order to avoid interference from other signals. 35

39 4.3 MSP430 The microcontroller our project uses is the MSP430G2553. The package used is a 28 pin TSSOP surface mount. The pinout diagram is listed below which is found on page 3 of the data sheet for the MSP430x2x53 line of microcontrollers: Figure 4.3.1: Pinout of Microcontroller, Courtesy of T.I : Power and JTAG The microcontroller is powered by 3.3V. A.1 uf capacitor is used to decouple the device from the power supply. The Eagle schematic below shows how this will be set up. Figure 4.3.2: Power schematic, Eagle The MSP430 was prototyped on the Launchpad which has onboard emulator support. When the device is built onto a board, it no longer has the onboard emulator to program and debug. This is now done via JTAG interface. It requires only three connections to the MSP430 to allow programming, and powers the device while it is connected. The following image from the T.I. wiki shows how this is connected on the board. The image is licensed under Creative Commons that allows for reprinting for any reason with a cite to the original source. 36

40 Figure 4.3.3: JTAG connection schematic, T.I. Wiki From the image, connection J2 is used that will provide power to the device while it is connected to JTAG : UART The G2553 variant comes with hardware UART support which is a major factor in the decision for using it. The device must be configured through several address registers for UART to work properly. Configurations that are considered are the baud rate, number of bits, parity, and the number of stop bits. These can all be configured by simply writing a value to a specific address. UART support comes in the form of the Universal Serial Communication Interface (USCI). There are two USCI modules, only one supports UART which is called module A0. When configured properly, the RX and TX pins on the device will be set to ports P1.1 and P1.2, respectively. UART is set up with the following configuration: 9600 baud rate, 8 bit data, no parity bit, and 1 stop bit. The following process sets up the UART with the projects configuration: Set the DCO clock to 1 MHZ. The device has a max clock speed of 16 MHz, but using a lower clock speed will give an added benefit of reducing power consumption. Select alternate function for P1.1 and P1.2. This is done by setting P1SEL and P1SEL2 to 0x06. P1.1 and P1.2 are hardwired to have UART RX and TX as alternate functions. Set UCA0CTL0 to 0. This is the address register that determines the UART configuration. Setting it to 0 assures it will be set to no parity bit, 8 37

41 bit data length, 1 stop bit, and UART mode. The following is an outline of this register: UCA0CTL Parity disable Parity LSB First Length Stop Bits USCI Mode Async Figure 4.3.4: UCACTL0 register Next the UCA0CTL1 register is set to put UART in a reset mode and select the clock source UART will run off. The outline of this register is below: UCA0CTL Clk source Reset Figure 4.3.5: UCA0CTL1 register The project uses the sub-main clock (SMCLK) and by default this is equal to the DCO clock which is set to 1MHz. This is used to calculate the baud rate divisor as below: 1 = = The divisor value is stored in the baud rate registers UCA0BR0 and UCA0BR1. The latter holds 8 MSB of the divisor, and since our divisor is 7 bits long this register is set to 0. The former is set to 104. This will give UART the baud rate of The USCI is configured and must be taken out of reset. So the reset bit of the UCA0CTL1 bit is cleared. After this setup UART is configured properly with the projects requirements and can be interfaced with the Bluetooth module. Below is an Eagle schematic of how this will be correctly connected to the Bluetooth module. 38

42 Figure 4.3.6: MSP430 interfaced with Bluetooth, Eagle schematic BT_TX and BT_RX are the transmit and receive pins of the Bluetooth module, respectively. The schematic only shows how to interface between devices to utilize UART. Data from the device can be transmitted by writing to the address register UCA0TXBUF and received from UCA0RXBUF. A status register, IFG2, exists for the purpose of knowing when the buffers are ready for data. This register is described below: IFG2 1 0 UCA0TXIFG UCARXIFG Figure 4.3.7: IGF2 status register Only the first two bits of the status register are available to the G2553 device. UCA0RXIFG is set to 1 when UART receives a byte. UCA0TXIFG is set to 1 when the transmit buffer is empty. This register is used to make sure a byte is transmitted or received in a full, complete byte. Figure 4.3.8: TX/RX Buffers and Pins Figure is a visual graphic depicting the internals of the transmit and receive buffers. The transmit buffer is associated with pin 4, and whenever data is written to the transmit buffer it is pushed to pin 4 via UART. The receive buffer is associated with Pin 3. When data is received it is automatically put in UCA0RXBUF for retrieval. This is the point when UCARXIFG goes high. 39

43 The microcontroller receives a constant stream of bytes while having to process other sets of data. When transmitting the device runs in a loop which will poll UCA0TXIFG till it goes to one then writes data to UCA0TXBUF. This same approach cannot be used for receiving. If the microcontroller polls UCA0RXIFG till it is set, indicating a byte has been received, it runs into a loop till a byte is received. This can happen for transmitting since that process is relatively fast. But it is not optimal to hold the code till a byte is received, since other parts of the project are required to function at all times. In this case interrupts are used. The microcontroller is free to execute code, and only interrupt when a byte is received. To enable this feature bit 0 of register IE2 must be set. Figure 4.3.9: UART RX State Diagram Figure is a state diagram of how the MSP430 receives a byte over UART. It executes code in Main() till UCARXIFG triggers an interrupt. After that point the interrupt code executes to fetch the byte from the receive byte. At this time code in Main() is not executing till the interrupt trigger is cleared via software : Motor Controls To control the motors for forward and reverse, pulse width modulation (PWM) will be used to add different speeds. It is supported natively in the form of the Timer_A system on the G2553. It requires configuration through registers similar to UART. Two ports are required, one for forward and one for reverse. The project uses the second Timer_A system, TA1.1, which is set to the alternate functions of port 2.1 and 2.2. These ports are set to use their alternate functions by P2SEL, and the direction to an output by P2DIR. Set the Timer_A1 clock source and counter mode through TA1CTL. The clock is sourced from SMCLK and the counter is set in up mode. In up mode, the counter counts up to a defined value and reset to zero, specifying the period length. Set PWM mode by register TA1CCTL1. PWM is defined by output mode 7. 40

44 The period length is set by TA1CCR0 and the duty cycle is set by TA1CCR1. The following diagram from the MSP430x2xxx User Guide page 372, courtesy of T.I., shows the output of the Timer_A system when configured correctly. Figure : Timer_A output, courtesy of T.I. In up mode the counter counts to the value specified in TA1CCR0 and resets back to zero, and continue to count again. In output mode 7, the output is active for the length specified in TA1CCR1 and zero for the length outside that value. The following is an Eagle schematic of how the fw/rv motor is attached to the device. Figure : Eagle schematic for Timer_A1 outputs 41

45 Digital I/O ports are used to control the DC motor attached to the car for steering. The two outputs from this system are used since they will be connected to an H- bridge to allow left and right movement. The MCU will send either a high/low, low/high, or low/low signal to the H-bridge. The outputs used are connected to ports P1.6 and P3.5. They are connected as such in the following Eagle schematic. Figure : Eagle schematic for digital outputs The outputs go across 1kOhm resistors, and connect to a header to be interfaced with the H-bridge : Power Management The MSP430 is a processor known for its low power usage and multiple low power modes. These are utilized to maximize battery life when the car is not in use. After initializing UART and PWM the car immediately goes into a low power mode where the CPU and clocks are turned off and unable to execute any code, but still capable of receiving interrupts and executing code within them. To remove the car from its low power state, the received signals from the phone will execute interrupt code. When the proper wake up signal is received, the car will be free to execute code again. Low power mode can be entered with an instruction native to the MSP430, bis_sr_register(lpm4_bits), where 4 is the low power mode desired. During the time that the car is idle, it is not necessary to execute any code or use any of the clocks. The command used sets certain bits 4-7 of the status register, which is detailed as followed: Status Register SMCLK Off DCO Off Oscillator Off CPU Off Interrupts Figure : Status register Bits 4-7 are set to 1 in low power mode, and care needs to be made sure that bit 3, the interrupt enable bit, is set to 1 or else interrupts will not work, which is how the device wakes up. Once the device is in low power mode the only way to leave and allow the device to execute code again through an interrupt. Once the signal interrupt is triggered it executes another similar instruction which clears bits 4-7 and enabling the CPU 42

46 and clocks. When the code returns from the interrupt the device is able to continue executing code within main. The following is a state diagram between low power and active mode. Figure : Power mode state diagram The state diagram goes between two modes, low power and active, depending on the lap count and the wake up signal. The signal moves the low power state to the active, where it stays while the lap count is 3 or under. Once the lap count surpasses 3 it moves back to the low power state until the pushbutton is pressed : Infrared Signal The HIGH signal from the infrared subsystem is input into the microcontroller at P1.3. Since this signal occurs at any time, while other code is being executed, it makes catching this signal a priority. Therefore, and interrupt are used when this port goes HIGH. The interrupt is enabled by setting BIT3 of P1IE high, this causes BIT3 of P1IFG to be set when the interrupt is received. After each lap the microcontroller will increment a counter and send a signal to the phone via UART and Bluetooth. The following is an Eagle schematic of where the interrupt button and infrared signal is interfaced with the microcontroller: 4.3.6: LED Network Figure : Schematic with IR/Button inputs. After all the important peripherals were added for functionality (i.e. the Bluetooth module, Infrared signal, push button, servos and motor ports), LEDs were added for aesthetics and status information. The 28 pin MSP430G2553 variant was chosen for its extra set of general purpose I/O known as Port3. Five of these ports were used to attach the LEDs as shown in the following image: 43

47 Figure : LEDs schematic For convenience purposes, the five LEDs were named LED_0-4. Where each number LED was interfaced at the respective port number. When deciding which LED to light up, the software only needed to set the respective bit of Port3 to high using the command P1OUT : Software The software begins executing at power on or if the device is reset. It initializes all ports, UART, and PWM. These initializations only need to happen once after every power on or reset. After initialization it enters a low power mode till the wake up signal is received. This allows time for the user to connect to Bluetooth and also not let the car trip the lap counter accidentally, and save power where it is otherwise unused. After the wake up is received it is ready to race. However it will wait for the other car to be ready as well, so it hangs in a loop and waits for a signal from the other car. This signal is a low to high transition on port 2.3. To indicate the device is ready to race it will set its own port 2.4 to high. Once this transition is received, the cars double check that each other is ready. Then a countdown is initiated before the cars can race. The cars then begin to write the speed values to the motor and the turning values to the secondary motor. The values are assigned when the processor receives characters over UART. Direction and speed is associated with a given bit assignment as described in Table Each time a lap is completed a counter is incremented and a signal is sent to the phone. Once the counter has reached 3 laps, the car will stop, send a final signal to the phone, and bring itself back to low power mode ready to be raced again. The following flowchart graphically explains the software process. 44

48 Figure : Project software flow 45

49 4.3.8: Hardware The following is the schematic of all the important connections for microcontroller for the project to function as described and laid out in the previous sections: 4.4 Motor Controls Figure : Microcontroller schematic For the Knightro Kart experience the team decided on the use of an RC race car that had 2 D.C motors. Both the first / rear motor of the car was controlled by an H-bridge, and the second / front motor of the car was controlled by a different H- bridge. The team decided that instead of soldering on the MSP430 onto the already existing printed circuit board of the RC car, it was more beneficial to take out the already existing PCB and replace it with a newly designed one to fit the Knightro Kart s specifications. The MSP430 was at the heart of the PCB board and it served as the middle man between the Android application that was created and the RC race car s motor controls. The printed circuit board with the MSP430 was directly connected to the two H-bridges that would control the front and rear D.C motors of the RC vehicles. H-Bridge Functions The rear motor that was controlled by one of the H-bridges controlled the RC vehicle s forward movement, and reverse movement. The team decided to use 46

50 TI s SN H-bridge chip to control the rear motor. The SN needed constant 5V input in order to power itself, so it was connected the RC car s second battery pack. The second battery pack consisted of a 9V battery whose voltage had to be downgraded by a 5v Linear Regulator. This Linear Regulator was the UA78M05 that has the capability of receiving an input voltage of up to 36V and step down the voltage to have an output voltage of 5V. This linear Regulator is located between the RC car s 9V battery voltage supply and the H- bridge. The SN was also directly connected to the RC car s printed circuit board with the programmed MSP430 in order to receive its instructions. When the H-bridge received its high or low signals from the MSP430, it decoded them and depending on the command, the H-bridge caused the rear motor to spin clockwise or counter clockwise moving the back wheels of the car. The same process was applied to the front motor which was connected to the second H- bridge on the RC vehicle. Once these connections were established and both chips had been set, the RC race car was able to accelerate forward, and in reverse, and steer left and right. Figure Courtesy of TI The figure above is a layout of the TI SN H-Bridge; this layout can be found on the SN s datasheet. This chip has the ability to power both motors of the car, but two of the SN H-bridges were used due to the automatic thermal shutdown in each chip. One H-bridge powered the rear motor controlling the car s forward and reverse motion while the second H-bridge controlled the RC car s ability to maneuver left and right. 47

51 Figure Courtesy of Eagle The figure above is the layout of the SN with both motors mounted on one chip Figure courtesy of Circuit Lab The figure above is the detailed schematic of the interior of the car. In the schematic above it is displayed that each motor is using their own H-bridge with 48

52 a 5V voltage regulator attached to it and each H-bridge is directly connected to the car s printed circuit board containing the Bluetooth module and the MSP430 microcontroller which sent high and low signals over to each H-bridge to move the vehicle is a specific direction. Since the MSP430 used PWM signals, the team varied the duty cycle for the PWMs that were sent to the H-bridge controlling the rear motor of the car in order to manipulate the acceleration rate of the car. 4.5 Infrared Communication The infrared subsystem on the project is in two parts: the static source, and the sensor which is placed on the car. The static source is placed at the start line. It consists of infrared LEDs, enough to cover an entire line of the track, resistors, and a power source. The goal of the infrared source is to cover a line of the track, indicating the start/finish line, so when the car passes the finish line it detects that it has. Because of the decision to use an infrared phototransistor, it means that the source will have very minimal, noncomplex circuitry, since the LED does not need to be at a certain frequency and can just be on. The following schematic is how the circuit is built: Figure 4.5.1: IR Source Schematic The infrared LEDs are just ~940nm light outside of human visual spectrum, so these LEDs are treated as regularly by giving each a resistor. The amount of LEDs required is undetermined, so it is currently labeled n. Enough will be used so that an entire line of the track can be defined as the finish line. Double 49

53 checking is needed to match up 940nm LEDs with 940nm sensitive phototransistors. The LEDs that were chosen were done so because they have a 60 degree beam angle, which requires less LEDs to cover more space. The resistors are 180 ohm resistors and these were chosen to follow the equation V = IR, where the voltage source used is 9 volts and the forward current of the LEDs is 50 ma. The phototransistor is physically connected on the car. It is required to be strategically placed to reduce the effects of ambient light in the environment, while also being able to see the finish line. So naturally it is placed on the bottom of the car. To reduce the surrounding ambient light from the peripherals, either 35mm photo film, or a cylinder of a material can be placed around the phototransistor to block light from the sides. The following is a schematic of how the phototransistor will be wired: Figure 4.5.2: IR Receiver Schematic The voltage source is from the onboard battery of the car and regulated through a 3.3V linear regulator. Output is connected to the I/O of the microcontroller on port P1.7. In this design a pulldown resistor is used to keep the voltage LOW or near ground. The phototransistor is not conductive while there is no infrared source so the output will remain LOW everywhere but the finish line. Once the car runs over the infrared light line the output is driven HIGH from the 3.3 V source. This HIGH signal will be picked up by the MSP430 and designated code will be executed. A pulldown resistor is used instead of a pullup resistor because most of the time the signal will be LOW, it saves battery by not having a voltage applied to it most of the time. The phototransistor that was decided to be used is part number LTR-301 from Lite-On Electronics. Since the window of time the car sees the track is very low, 50

54 it was important to pick a photoresistor that has a fast rise time. According to the data sheet the LTR-301 has a rise time of about 100 microseconds. 4.6 LED Network The system design called for a small network of LEDs on the vehicles. The LEDs benefited the aesthetics and overall user enjoyment of the system. The network was designed to activate certain patterns when specific events occurred on the vehicle. These events were a starting countdown, a pattern for crossing the lines, and a race finished pattern. Each pattern utilized the six LEDs hard wired onto the vehicle s body. The general layout of these LEDs can be seen in Figure below. Figure 4.6.1: Six available LEDs on vehicle. As discussed previously, the start line was embedded with a series of infrared lights. The vehicles will be able to detect the infrared. In this way a counter can be established to determine the number of laps completed. Before each race the counter is reset to zero. As discussed previously, the user selects start to tell the vehicle that they are ready to start. When both vehicles have sent the start signal, the countdown pattern will occur on the LEDs. This pattern is a cascade through the six available LEDs as shown in Figure below. This is beneficial to the system because it produces a uniform start environment for both vehicles. Figure 4.6.2: Start countdown pattern, from left to right. Each time the vehicle crosses the start line, the lap counter is incremented by 1. When this occurs, a signal is sent using the free I/O ports on the MSP430 to the 51

55 LED network. Each time the vehicle crosses the start line, the infrared signal again increments the counter. The system is designed to encompass a race of three laps. Therefore, every time the vehicle crosses the start line the set of six LEDs will increment to show the current lap as in Figure Figure 4.6.3: Lap countdown sequence, from left to right. Finally, after the third lap is completed the LED network will receive instructions to complete a new pattern. The pattern can be seen in Figure below. This pattern represents that the vehicle is going to sleep. The middle LED will stay lit after this event to represent the vehicle is asleep. Figure 4.6.4: Sleep pattern, from left to right. The vehicle also contains two additional LEDs that are reserved for Bluetooth connection status. These LEDs will blink as in Figure below when the vehicle is disconnected. When the vehicle establishes a connection, the LEDs, will stop blinking, and the left LED will remain solid as in Figure Figure 4.6.5: Disconnected sequence. Figure 4.6.6: Bluetooth connected LED. 4.7 Android Application Design The vehicles in the system must be controlled by some kind of remote. In order to present a richer user experience, the cars were controlled by a custom Android application. The remote control application, called the remote control 52

56 from this point forward, was designed to work on specific Android devices. These devices were any running Android operating system (Gingerbread) or higher. As a result, programming will be done using minimum software development kit (SDK) 10, but designed to target SDK 16. SDK 16 was the most up to date package at the time of programming and represented the most modern and user friendly interface available. However, since the minimum package was SDK 10, the application was not able to use any classes or features present only in newer SDKs. In order to increase user satisfaction, a graphical use interface (GUI) was implemented. The GUI was a forward facing interface that allowed users to control the application through a series of images and shapes. As a result of implementing the GUI, the user did not need much, if any, training on how to use the remote control. A menu was used to make decisions. Examples of such decisions are enabling Bluetooth, selecting another device to pair with, and exiting the remote control application. The GUI was implemented using a combination of XML and Java programming languages. Shapes were defined in the application s XML code. However, defining the XML objects does not instantly make them perform any action when they are selected by the user. In fact, if the GUI objects are only defined in the XML and not in the Java, then the object would be displayed to the user, but it would perform no action when selected by them. By implementing the GUI objects in the Java portion of the code, actions for each object were be defined. For example, buttons are written in Java by using the OnClickListener( ) instruction. In this way the developer can write into the code what action will be performed as a result of the button being selected. In the case of passive GUI components, such as text areas, Java code must also define the objects. If a text area was defined in XML, but not implemented in Java, it would not be populated in the program. Therefore, for passive GUI objects, Java code would still be needed to update text, or display a dynamic value, such as the current values of the accelerometer axes. In addition to running a minimum of Android 2.3.3, eligible devices also required Bluetooth pairing capability using Bluetooth 2.0 or higher, an accelerometer, and a touch screen. Users were given a qualified Android device with the remote control application already downloaded onto it. Once the application was opened a series of events occurs before data could be transmitted to a vehicle, these steps are organized in an easy to read flow chart at the end of this section in Figure First the remote control checked that both Bluetooth and accelerometer hardware existed on the device. If both hardware components existed, the application would immediately check that Bluetooth was enabled. If it was not, the software would prompt the user to do so. The user should select yes, and Bluetooth would automatically be enabled without having to leave the application. Figure below shows how the notification to enable Bluetooth would appear. 53

57 Figure 4.7.1: Early Prototype Bluetooth Permission Request Notification However, enabling Bluetooth was not enough to start sending information from the device to the vehicle. The Android device must pair with one and only one vehicle. To do this the remote control must first discover the vehicle. The Android device will act as a client in a client-server type connection. In this way, the Bluetooth chip connected to the MSP430 will constantly broadcast a signal acting as a server until it is connected. The Android device acts as a client and searches for a service to connect to. Connecting as a client in Android requires a series of steps. First, the remote control used BluetoothDevice to get a BluetoothSocket using the createrfcommsockettoservicerecord(uuid). Now the necessary UUID (universal unique identifier) is known to the application. Next, the connection is initiated through the connect( ) command. Connect( ) works by performing an SDP lookup to match the UUID to the correct remote device. If the lookup is successful a connection is made. Otherwise no connection is made and discovery will have to be attempted again. Once the remote control has been paired to a vehicle, the user is ready to race. Control of the car is achieved through the accelerometers, turning the Android device into a kind of steering wheel. The software was designed to read the movement of the device via accelerometer and translate that movement into specific values. These values were then sent via Bluetooth to the MSP430 controller in the paired vehicle. Bluetooth sends data as a series of bytes. In order to send this data the application gets the InputStream and OutputStream using the getinputstream( ) and getoutputstream( ) commands. Once this is completed, data is read and written using the read(byte[ ]) and write(byte[ ]) commands. The remote control works by reading the current accelerometer values and sending a specific byte to designate the range that those values fall within. 54

58 Figure below shows an early prototype of the remote control application when the device is laid flat on a surface. On the bottom of the screen the accelerometer values are displayed. Farthest left is the current x-axis value, center is the y-axis value, and on the right is the z-axis value. The accelerometer hardware in the device works by reading the acceleration including the force of gravity. As a result, the developers applied a low pass filter to isolate the force of gravity on the device. Then the developers applied a high pass filter to remove the force of gravity from actual acceleration, giving the true acceleration on the device at any given time. The result is similar to the following operation, where Gravity = -9.81m/s 2. =! " $% Figure 4.7.2: Early Prototype Accelerometer Output Example As you can see in the prototype screenshot above, Figure 4.7.2, the values being read are not exact. For a device laid on a table, the exact values should be (0, 0, 9.81) to show that the only acceleration on the device is that of gravity. However, this is not the case. The reason for this has to do with the choice of alpha in the low pass filter. As a result, the values never leave the range -8.0 < acceleration < 8.0. However, for the purposes of the system, these values are correct enough to provide a precise user experience. Figure below shows the code required to implement the low and high pass filters in order to read the correct accelerometer values. This code is from an early prototype of the remote control. 55

59 Figure 4.7.3: Prototype Code Showing Low Pass and High Pass Filter Implementation Table below shows the Ascii symbols that will be sent by the remote control to the MSP430 on the vehicles via Bluetooth. Each value represents the degree to which the user has moved the device in a certain direction. The accelerometer is constantly updating, and the application constantly sends new values over Bluetooth to the vehicle. In this way the MSP430 can interpret the byte it receives, and translate that into the appropriate action on the vehicle. The remote control will be able to detect left, right, forward, and backward movements. Action (Conditions) Speed 1 (2 < ZAccel < 3.5) Speed 2 (3.5 < ZAccel < 4.5) Speed 3 (4.5 < ZAccel < 5.5) Speed 4 (5.5 < ZAccel) Reverse (ZAccel < -2) Stopped (-2 < ZAccel < 2) Left (YAccel < -2) Right (YAccel > 2) Straight (-2 < YAccel < 2) 0x84 0x44 0x04 0x88 0x48 0x08 0x90 0x50 0x10 0xA0 0x60 0x20 0x81 0x41 0x01 0x82 0x42 0x02 The design of the remote control was dependent in part on the Android definition of the accelerometer axes relative to the device. The accelerometer reads data 56

60 on an x-axis, y-axis, and z-axis. The y-axis can be thought of as going vertically through the device, the x-axis as going horizontally through the device, and the z- axis as going perpendicularly through the device. All three axes meet at the center of the device. A graphical representation of the accelerometer axes can be seen in Figure below. As a result, it makes sense that the y-axis values determines the left and right movement of the vehicle, and that the z-axis values determine the forward and backward motion of the vehicle. Figure 4.7.4: Accelerometer Axes Representation; image taken from android developers open source website, see Appendices for permissions The final application design also displayed a series of non-essential information components. Included in these components is a timer that displays the user s total racing time. When the remote control receives the signal to activate the race communication, the timer starts from zero. When the user has completed the race the timer stops counting. The remote control knows when the race has ended when it receives an end signal from the MSP430. The MSP430 sends this signal when the infrared counter reaches 4, signifying that the vehicle has completed three laps and the race is over. Other non-essential elements include an appealing screen layout. 57

61 Figure 4.7.5: Block Diagram Representing Program Process 58

62 4.8 Remote Control User Interface Upon startup the user is presented with the main page. On the main page important information is displayed to the user. In the center of the screen is the current lap count. The lap count is updated during the race as a result of Bluetooth communication from the connected vehicle. At the bottom of the screen is the Bluetooth connection status. When connected, the message at the bottom of the screen will update to display the name of the connected Bluetooth module. At the top of the screen are the x-axis, y-axis, z-axis accelerometer values respectively. The user also has access to a menu. In the menu the user can connect to a vehicle. If the user decides to connect to a device a popup window will show any previously paired devices as well as the option to look for unpaired devices in range. Once the user selects a device, connection will be attempted and the user is returned to the main page. If connection is successful, the main page will be updated with the current device connected. 59

63 Once connected, the user can select start from the menu. This will send a signal to the vehicle, signifying that the user is ready to race. The user also has the reset option, which will reset the application variables, and sever any current Bluetooth connection. Finally, the user can select exit from the menu, this option will sever any current Bluetooth connection and close the application. This was added to the menu, because the back button was disabled to prevent accidental exit from the application. 60

64 5.0 Project Construction and Coding 5.1 Parts List and Parts Acquisition Part # / Name Manufacturer Price $ Molex Category: Headers & Wire Housings Specifications: 2.5mm KK Term, with Ear 2.2mm Description: Wire creating tool that helped with the compressing of the wires while they were made Molex $ Category: Headers & Wire Housings Specifications: HSG 2P with LKG ramp Description: Helped hold the wires created for the Knightro Kart Experience in place Molex $ 0.09 Category: Headers & Wire Housings Specifications: 2P STRAIGHT HEADER Description: Wire Arrangement for the wires made for the Knighto Kart Project 61

65 UA78M33CDCYR Texas Instruments $ 0.56 Category: Linear Regulator Specifications: 3.3V OUT Description: This Linear Regulator helped drop down and produce a constant voltage from the battery to the MSP430, and Bluetooth Module on the car UA78M05CDCYR Texas Instruments $ 0.56 Category: Linear Regulators - Standard Specifications: 5V OUT Description: This Linear Regulator helped drop down and produce a constant voltage from the battery to either the servo motors used on the car, or from the battery to the race car's H-bridge connected to the motors. MF1/4DC1800F KOA Speer $ 0.04 Category: Metal Film Resistors Specifications: 100PPM, 180 Ohm, 1% 62

66 CRCW121010K0JNEAHP Vishay / Dale $ 0.17 Category: Thick Film Resistors - SMD Specifications: 3/4 watt, 10k ohm, 1% RN41-I/RM Roving Networks $ Category: Bluetooth / Modules Specifications: Class 1, Mod version 2.0+EDR, w/ Antenna Description: Bluetooth Module that created the connection between the Knightro Kart Race car, and the application on the android phone being used as the remote for the race car. This module was powered by voltage coming from a 9V battery and moving through a linear regulator that will step down the battery's power because the module only requires an input voltage of 3.3V T0807LF FCI $ 0.64 Category: Headers & Wire Housings Specifications: Unshroud Header Vertical Description: These unshrouded or uncased headers, are the headers for JTAG the team used for the project. Each of the headers has 2 rows with 7 pins for it and they are soldered on the board that will be mounted on each race car. These headers will make it possible for the MSP430 to be programmed and debugged. 63

67 CRCW RJNEAHP Vishay / Dale $ 0.17 Category: Headers Thick Film & Resistors Wire Housings, - SMD Specifications: 2.5mm 3/4 watt, KK 330 Term, ohms, with 5% Ear 2.2mm Description: CRCW121047K0JNEAHP Vishay / Dale $ 0.17 Category: Thick Film Resistors - SMD Specifications: 3/4 watt, 47k ohms, 1% CRCW12101K00JNEAHP Vishay / Dale $ Category: Thick Film Resistors - SMD Specifications: 3/4 watt, 1k ohms, 1% 64

68 VJ1210Y222KXEAT Vishay / Vitramon $ 0.19 Category: Multilayer Ceramic Capacitors MLCC - SMD/SMT Specifications: 2200pF, 500V, 10% C1210C106M6PACTU Kemet $ 0.24 Category: Multilayer Ceramic Capacitors MLCC - SMD/SMT Specifications: 10uF, 35V, 20% C1210C104K5RACTU Kemet $ 0.14 Category: Multilayer Ceramic Capacitors MLCC - SMD/SMT Specifications: 0.1uF, 50V, 10% 65

69 MSP430G2553IPW28 Texas Instruments $ 2.23 Category: 16-bit Microcontrollers - MCU Specifications: Mixed Signal MCU Description: This MSP430 chip is our low power mode microcontroller which interprets the Bluetooth communication between the Android Device and RC race car, sends high and low signals over to the RC race car's motor controls like the H-bridge that is in charge of accelerating the car forward or in reverse. This chip was also programmed to interpret infrared signals on the track in order to keep track of the RC car's position in the race. This chip utilized Pulse Width Modulation to command H-bridges of the RC vehicle EL-IR908-7C Everlight $ 0.32 Category: Infrared Emitters Infrared LED Specifications: 940nm wavelength, side looker Description: This piece of equipment is posted up at the START line of the course, and it allows the phototransistors on the car read how many laps the race car has done, and how many laps the race car has left in order to finish the race. LTR-301 Lite-On $ Category: Infrared Photo-transistors Clear Specifications: 940nm wavelength, side looker Description: This piece of equipment is on the bottom and the side of the car and it will read whenever the car does a full lap of the race track during the race, which will help keep track of the number of laps that have been completed and how many more laps the racer has to do in order to finish. 66

70 MSP-EXP430G2 Texas Instruments $ 4.60 Category: Specifications: Description: Development Boards & Kits - MSP430 This Launchpad is where the testing of the MSP430 was done, along with the testing of the connections between the MSP430 and the Bluetooth module, this launch pad was eventually be replaced by the actual circuit board that has the Bluetooth module, LED Lights, infrared lights, MPS430 and the above components such as the JTAG headers soldered onto it, so this launch pad will only be used for testing purposes. 5.2 PCB Design The entire circuit board was compiled within CadSoft Eagle. The schematic was captured in the CadSoft editor, and the components was placed and routed in the user interface. Because of the limitations of the freeware version of Eagle the printed circuit board is limited to 4 inches by 3.2 inches. The custom printed circuit board with all the components laid out is as followed. Care had to be taken not to place the components too close to each other since all parts will be hand soldered. 67

71 Figure 5.2.1: Project PCB In figure only the most important parts are routed and the yellow lines are unrouted connections. The board has two layers; red lines are on the top layer whilst blue lines are on the bottom layer. Since the auto router cannot make important distinctions for certain components these are done manually. The critical parts where special attention is needed is followed: Figure 5.2.2: Bluetooth Antenna Routing In figure manual routing is needed to avoid the portion highlighted with the blue rectangle. The component that this is a part of is the Bluetooth module with a built in antenna. According to the datasheet for the module this plane should be avoided by traces to reduce interference. The routing that goes from the Bluetooth to the PCB headers is the wiring for the Bluetooth status LEDs. 68

72 Figure 5.2.3: MSP430 Power Routing Figure is the MSP430G pin device. Capacitor C3 is used to decouple the MSP430 from random fluctuations in the power supply. The capacitor needs to be placed as close as possible to the MSP430 with routed VCC and GND. Manual routing is required since autorouting may attach the decoupling capacitor to other VCC and GND lines attached to other components. Figure 5.2.4: Bluetooth Power Routing Figure is the power circuit for the Bluetooth. Similar to figure x.3 a decoupling capacitor is used to protect the Bluetooth device from voltage fluctuations Figure 5.2.5: Power Supply Routing Figure is the routing for the power supply. The component on the left is the header where a 9V battery plugs into and the component on the right is the 3.3V voltage regulator. Pin 1 from the header to pin 3 of the voltage regulator is the positive voltage from the 9V battery. Pin 2 from the header to pin 1 of the regulator is GND. Pin 4 of the regulator is the 3.3V output line. Manual routing is done on the power supply to make sure the 3.3V line goes directly to the VCC 69

73 lines of the MSP430 and Bluetooth module, since these components are important. There are several other important parts of the circuit board which explained in the following: Figure 5.2.6: JTAG header This portion of the circuit board is the JTAG header and required resistors and capacitors for it to function properly. These are routed to pins 1, 24, and 25 on the MSP430. Figure Figure is the LED bank, rotated 90 degrees for visual purposes. Each resistor has a value of 330 ohms. Each of these headers are connected to a bit of port 3 on the MSP430, specifically pins 8, 9, 13, 14, and 15. Figure 5.2.8: Motor Headers 70

74 Figure 5.2.8, rotated 90 degrees for visual purposes, shows the headers that are attached to the motors. The resistor values are all 1k ohms. These headers are not grounded but are used to send signals to H-bridges so forward and reverse motions are achievable. The header on the left connects to the motor and is interfaced on the MSP430 on pins 19 and 22. The header on the left connects to the secondary motor and is interfaced with pins 11 and 12. Figure 5.2.9: Infrared Signal Header Figure is where the infrared is interfaced on pin 5 on the MSP430. The resistor is 10k ohms and used is used as a pulldown for the pin to keep it at ground when there is no infrared signal. The other header pin is connected to the 3.3V power line. Figure : Pushbutton Header Figure is the header for the pushbutton which will be connected to the MSP430 at pin 6. The 10k ohm resistor is used as a pulldown for keeping the pin at GND while the pushbutton is not pressed down (or closed). The other pin header is connected to the 3.3V power line. The following design is the rest of the connections autorouted. 71

75 Figure : Complete Circuit Board Routed A ground plane is used to simplify the design and reduce noise. The ground plane is on the top layer. This simplifies the circuit in that there is no need for GND traces, so each GND signal on the components will go into the board. 72

76 Figure : GND Plane and Complete PCB Figure is the completed custom circuit board with the ground plane. Consideration has to be made with the antenna again to not let the ground plane cross over it, so that part was removed from the plane. Each white section is where a ground plane cannot exist since they are completely outlined by other non-ground signals. Eagle has a special, but important, feature of only letting limited amounts of the ground plane converge around a ground pin. This is important for soldering since it takes longer for the ground plane copper to heat up. Since less copper is around the pins they can heat up faster and let solder apply efficiently. A close up of the ground plane, signals, and GND can be seen in figure : Figure : Close Up of Connections 73

77 Above, pin 1 shows the signal line with ground plane surrounding it. Little room is given as a buffer between the signal line and ground. Pin 2 is GND signal. Less of the ground copper converges around this pin to allow efficient heating. Figure shows the +3.3V line highlighted. It only goes to the MSP430, Bluetooth, JTAG, pushbutton, and infrared phototransistor; which is exactly where it needed to go. For the most part this shows the PCB is routed correctly. 5.3 Final Coding Plan Figure : 3.3V Line. Knightro Kart has two main code components. Those are the code for the vehicle as well as the code for the remote control application. Of these two, the remote control code can be considered high level. This means that the code must not only produce the correct information in the correct way, it must also present this information in a way that is easy for the user to understand and interact with. High level code is also machine-independent, meaning that the remote control code itself can be run on any machine that supports Java programming languages. On the other hand the vehicle code consists of the code implemented on the MSP430. The MSP430 family instruction set is considered low level. This means that code for the MSP430 can only be implemented on an MSP430 device. Also, the MSP430 code must take into account the MSP430 architecture instead of focusing on the pure logic behind the required operations. 74

78 The remote control code should be completed within the first quarter of the allotted development time. This means that the code must be ready for test by the end of January. Detailed timeline breakdown can be found in the Project Milestone section. The completed code is important, because no communication or vehicle control testing can be done without the remote control. The remote control code should be approached as a series of blocks. These blocks can be completed relatively independent of the other blocks. Below are illustrated the blocks required for the remote control. Blocks on the same horizontal level can be completed at any time regardless of blocks on the same level or below it in the diagram. However, blocks at a higher horizontal placement in the diagram must be completed before the lower blocks can be coded correctly. See Figure Figure below. Figure 5.3.1: Block Diagram Demonstrating Order of Remote Control Application Coding The MSP430 vehicle code needed more development time. Part of this is that the MSP430 code relies on input from the remote control, which was not completed until the end of January. Also, the MSP430 must control and listen to several other components, including the Bluetooth module. All of the extra components must be interfaced with the MSP430 and accounted for in the code. For this reason, the MSP430 was not completed until 60% of the development time has passed, meaning the MSP430 code was not ready for test till the middle of March. Below in Figure 5.3.2, is the block diagram for the MSP430. The figure follows the same premise as Figure above where blocks at higher levels must be completed before lower levels can be completed, and horizontal blocks can be developed independent of each other. The MSP430 code has a similar coding structure to the remote device where a vertical coding plan is needed for each feature for them to be functional. 75

79 However, many of the features are shared with a neighboring structure, which needed to be implemented before a feature can become implemented correctly. Figure 5.3.2: Block Diagram Demonstrating Order of MSP430 Coding Pulse width modulation and LED control were the only features that are independent enough so they do not rely on anything else for them to be fully functional. UART and the GPIO take advantage of interrupts which each require their own block of code. The interrupt generated by the wake up signal has a direct influence on the state of low power modes. So these share a similar data coding structure. The transmit function on UART is independent from receive, and is operational without the need of interrupts. The receive function, on the other hand, requires its interrupt to be functional and shares the interrupt coding structure. Infrared was not functional until its GPIO interrupt is coded as well. 76

80 6.0 Project Prototype Testing 6.1 RC Car Testing In order to ensure that the RC race car s features were fully functional throughout the entire race; the finished modified RC race cars must be tested. Without testing the finished product and trying to expose any missed flaws in the Knightro Kart project, it is impossible to conclude that the project can be truly finished. As this will be a competitive racing game, it would be unfair for one of the competitor s RC car to break down or not function properly in the middle of a race. When completed every Knightro Kart RC race car had to have the following working Bluetooth link up with Android application LED Display Infrared sensors Established motor controls Bluetooth and Motor Controls In order to test the Bluetooth connectivity of the RC car, the car s power supplies had to be turned on in order to allow the Android application to have the chance to connect to the RC vehicle. Once the supposed connection has been established test the RC car s motor controls to ensure connectivity, follow the following steps Step 1: Tilt remote to the left o Android device s accelerometer conditions should automatically send a signal to the RC car to turn it s wheel to the left Step 2: Tilt the remote to the right o Android device s accelerometer conditions should automatically send a signal to the RC car to turn it s wheel to the right Step 3: Tilt the remote forward o Android device s accelerometer conditions should automatically send a signal to the RC car to accelerate and move forward Step 4: Tilt the remote backwards o Android device s accelerometer conditions should automatically send a signal to the RC car to make the car move in reverse By successfully executing the above procedures the RC car s Bluetooth connectivity, and motor controls have been tested and approved. Infrared Sensors 77

81 Once the RC car is mobile it is important to verify that its other features are also functional, such as the infrared sensors. To successfully pass this test the RC car must be able to enable the race track lap counter programmed into the MSP430. Step 1: Turn on Infrared Sensors located at the starting line of the race track Step 2: Align RC car to be able to pass through infrared sensor Step 3: Drive RC car through turned on infrared sensors o Lap counter should be active and lap 1 should be displayed on Android application Step 4: Complete a full lap of the course and pass the infrared sensors at the starting line for the second time o Lap counter should have increased by 1 and lap 2 should be displayed on Android application Step 5: Complete the second lap of the course and pass the infrared sensors at the starting line for the third time o Lap counter should have increased by 1 and lap 3 should be displayed on android application Step 6: Complete the final lap of the course and pass through the infrared sensors a fourth time o This should signal the end of the race and the MSP430 should automatically turn to low power. By successfully executing the above procedures the RC car s infrared sensors have been tested and approved. LED Display The next feature of the completed RC race car is the LED display that is programmed to display different patterns for every passing lap that is completed, including a different pattern once the race has come to an end. Step 1: Complete one full lap of the course o LED pattern display should match the patterns displayed on figure 4.6.2, on page number 44 Step 2: complete the second lap of the course o LED pattern display should match pattern 4.6.3, on page number 45 Step 3: complete the third lap of the course o LED pattern display should match pattern 4.6.3, on page number 45 Step 4: complete the race o LED pattern display should match pattern 4.6.4, on page number 46 By successfully executing the above procedures the RC car s LED pattern displays have been tested and approved. 78

82 Multiple RC Race Cars Knightro Kart is designed to be a racing game, and multiple RC vehicles will be used at the same time, so it must be clear that all the connections and features on the RC cars work properly all at the same time. Step 1: Connect all RC race car s available Via Bluetooth to Android application Step 2: Once a connection has been established with each car, perform the motor control test on all vehicles at the same time Step 3: Have each car maneuver around each other in order to make sure they have no connectivity problems with each other. Step 4: Drive cars on race track and finish all 3 laps o This should enable all the features of the RC cars including their infrared sensors and LED displays By successfully executing the above procedures all of Knightro Kart s RC race cars should be ready for an official race. 6.2 Bluetooth Range Testing In order to ensure that the remote controls will be able to control their vehicles throughout the entire course, the Bluetooth range must be tested. The maximum Bluetooth ranges are specified in the Bluetooth standard. However, actual Bluetooth range is victim to several unknowns that may significantly limit the communication range between two paired devices. To test our devices we must first acquire an eligible Android device and a Bluetooth chip connected to an MSP430. The MSP430 should already be programmed to accept bytes of data from the Android device via the Bluetooth chip. For the purposes of testing, an LED should light up when the Android device sends a byte equivalent to any rightward movement. The devices should be paired as they would be in the completed system using the remote control. Two testers will be needed to perform the test. The basis of the test is to sequentially move the MSP430 and the remote control farther and farther from each other. The LED should light up at each point in the test. One tester will monitor the MSP430 while the other moves the remote control. The goal is to ensure that the devices communicate properly for at least 25 feet. To begin, the MSP430 should be placed within 1 foot of the remote control being tested. The tester in charge of the remote control should then tilt the remote control to the right as a user would likely do. As soon as the remote is tilted to the right, an LED on the MSP430 should light up. The remote control 79

83 tester should make sure to also tilt the device to the left, forward, and backward in order to ensure that the LED only turns on when the appropriate movements are received. Next, the MSP430 tester should move the MSP430 and its attached components away from the remote control by exactly 5 feet. The steps above should be repeated, with the remote control being tilted several directions, and the proper LED being monitored for correct action. These steps should be repeated in 5 foot increments until a distance of 25 feet is achieved with proper communication. If at any point in the test the LED does not light up when it is supposed to, corrective action should be taken. First, make sure the mistake is not a result of human error, such as lost connection between the Bluetooth chip and the MSP430. Next, if an error continues to persist, attempt to determine if the error is indeed a communication error, or an error in the code of either the MSP430 or the remote control. If neither of these are the cause of your error, then the range is the problem. To correct this, it must be determined if the Bluetooth chip on the MSP430, the Bluetooth chip on the device, or both, is causing the range shortfall. In order to determine which chip is at fault try swapping Bluetooth chips on the MSP430 using the same remote control, then try using the same Bluetooth chip on the MSP430 with a different remote control device. If either the Bluetooth chip for the MSP430 or the remote control fail further testing, then that chip will have to be replaced with another one. In order to correct the Bluetooth chip for the MSP430, simply switch in another chip of the same Bluetooth iteration or higher. For instance, a Bluetooth 2.0 chip should be replaced with a Bluetooth 2.0 or Bluetooth 3.0 chip. If the remote control is the issue, that Android device cannot be used, as its Bluetooth chip is not powerful enough to communicate over the necessary distance. Otherwise, if the Bluetooth range test is completed successfully, move on to test the other Bluetooth enabled MSP430s as well as any other Android devices that may act as remote control devices in the completed system. 6.3 Infrared Testing Infrared is used as an outside source to trigger events within the microcontroller. It consists of two parts that needed to be prototyped and tested. One part, which remains static and at the finish line of the track, is built using a battery, several resistors and LEDs. It is built on a breadboard according to the schematic in figure Since infrared is out of the visual spectrum the light can be visually seen through a camera. The phototransistor is attached to the moving car. It acts similar to a switch that closes in the presence of infrared light. To test this it is build according to schematic What needs to be tested is its ability to switch fast enough. 80

84 The car will be in motion and the window in which it sees the infrared line is incredibly small. The voltage needs to go to 3.3V in this short time frame. To test this the following schematic is made: Figure 6.3.1: Infrared Switching Test Timer_A of the MSP430 is set to switch from and about every half second. The data sheet claims the rise time of the phototransistor is about 100 microseconds. Observing and measuring the switch on an oscilloscope shows even better results and a switching speed of about 6 microseconds. This is long enough for the car to pick up the signal while in motion. Another important aspect is to test the effects of ambient infrared light in the environment. This is important for not tripping the lap counter when the car is not near the infrared line. For testing the phototransistor is built as shown in the schematic in figure x.1. There is no need for the infrared LED. The phototransistor circuit is then taken outside and measured with a multimeter. One feature of the photoresistor chosen is that is has a raised bulb where the effects of infrared light at the most significant. The results of the ambient light testing are as follows in table 6.3.1: Positioning Voltage (V) Indoors 0 Direct Sunlight 3.3 Shadow (bulb facing open light) 1.5 Shadow (bulb facing no light) 0 Table 6.3.1: Ambient IR Testing According to the results in table 6.3.1, positioning the phototransistor on the bottom of the car will be sufficient enough for blocking out ambient IR light in the 81

85 environment. This result can be concluded from the fact that when the bulb of the phototransistor was not in direct sunlight, and not facing open sunlight (i.e. facing a wall) the voltage at the output was 0 V. When the prototype of the car was constructed more testing was required. These tests included: Ensuring sufficient power to the infrared LED strip. Ensuring sufficient power to the phototransistor. Test the ability of the infrared phototransistor to switch reliably. Make sure no ambient light triggers the phototransistor. From our additional testing it was found that the LED strip and phototransistor do receive sufficient power for our purposes, and they do switch fast and reliably. One of our issues is the ambient infrared light that occasionally triggers the phototransistors. 6.4 LED Network Testing As discussed in the LED network section, the LED network is designed to produce a certain pattern at certain events. These events included the start of the race, each successive lap, and a final lap victory pattern. However, the MSP430, which controls the LED network through its available I/O ports, does not know whether the race is starting or ending or just lapping. What the MSP430 knows is the current value of the infrared communication counter. That counter is designed to start at 0, and count up each time the start line is crossed. At certain counter values the MSP430 will send signals to the LED network defining the pattern. The counter values and their associated LED network patterns are shown in Table below. Infrared Counter Value Associated LED Network Pattern 0 None 1 Start Pattern 2 Regular Lap Pattern 3 Regular Lap Pattern 4 Finish Pattern Figure 6.4.1: Infrared Counter Values and Correct Corresponding LED Network Pattern In order to test the LED network the tester will artificially increment the infrared counter value from zero to four and then decrement is from four to zero at least three times on each MSP430/LED network hardware connection. Once the MSP430 and LED network have been constructed and coded, the test can begin. First it will be ensured that the infrared communication counter contains value zero. At this point the tester will ensure that no LEDs are on. Next, the tester will 82

86 increment the infrared counter artificially using the programming software for the MSP430. Once the counter value is incremented to one, the LED network will immediately display the start pattern. The tester will first ensure that the LEDs have turned on. If this is the case the tester will then refer to the pattern description in Section 4.5, LED Network Design, and ensure that the pattern displayed was the correct start pattern for the correct number of cycles. If this was not successful, the tester will refer to the software and LED layout to check for errors. This will be the case if any patterns fail to be produced correctly. If the first increment occurs successfully, the tester must again artificially increment the infrared counter value. The test will first ensure that the LEDs have turned on. If this is the case, the tester will ensure that the pattern shown follows the regular lap pattern discussed in Section 4.6. Again, if successful the tested will increment the infrared counter value and ensure that it follows the regular lap pattern definition. Next, the tester will increment the infrared counter to its final value, four. Again the tester will ensure that the LEDs are active. However, this time the tester will ensure that the finish pattern is being produced for the correct number of cycles. The finish pattern is described in Section 4.6 of this document. If all of the above steps were successful the tester must cycle through the possible counter values in descending and ascending order, zero though four, four through zero at least three times. Along the way the tester must ensure that the proper patterns are being produced at the correct infrared counter values. 6.5 Microcontroller Testing Custom printed circuit boards can be costly so it is a better budget decision to do all the embedded prototyping with a development board. Since the microcontroller used is the MSP430G2553 the board to be used is the MSP430 Launchpad, pictured as shown from the Texas Instruments website. The Launchpad is convenient because it allows us to interface the microcontroller to a PC and be programmed and debugged in the Code Composer Studio Environment. The Launchpad gives us direct access to the pins of the microcontroller which can be interfaced with the different hardware the project requires. Using Code Composer alone, many of the functions and features of the microcontroller can be tested. Combining the Launchpad with a breadboard much of the hardware can be tested. This pre-prototype testing is not sufficient enough for the final design, of which more testing will be required. 83

87 Pushbutton is on P1.3 on newer revisions Figure 6.6.1: MSP430 Launchpad, courtesy of T.I. The MSP430G2553 uses all 20 DIP positions on the Launchpad, but it has 28 pins on the printed circuit board. Prototyping on the Launchpad will include UART, PWM, interrupts, and low power modes. UART UART is configured as shown in design section and a small test program is written to only receive and transmit over UART from the microcontroller. This test is not fully functional for our requirements and is only for testing. The program just simply echos whatever is received in the receive buffer. The Launchpad uses an on board emulator that supports UART and the computer only needs to connect to the right COM port for sending data serially. The terminal program used to send data is TeraTerm. A picture of the terminal output is as follows: Figure 6.6.2: Terminal Output After a prototype of the car has been constructed we would have to do more testing to ensure UART is configured and working properly. However the circuit board will not have access to the UART over PC. The testing will have to be 84

88 conducted through Bluetooth after it has been confirmed to be working. UART will have to be tested to make sure data is reliably received and transmitted from the microcontroller. PWM PWM is configured as described in design section To test PWM LEDs will be used. The brightness of the LEDs will be configurable with a small program that will adjust TA1CCR1 from a 100% duty cycle (LEDs at full brightness) to 0% duty cycle (LED off). The following picture is a capture from an oscilloscope. Figure 6.6.3: Oscilloscope capture of PWM During prototype testing of the vehicle, pulse width modulation will need to be tested again after it has been interfaced with the servos and motors. These tests include: Ensuring PWM is working. It can reliably control the motors. Finding the duty cycles required control the motors for different speeds. PWM was tested originally on the vehicle using LEDs, since we got them blinking or with a lowered intensity, that was our confirmation PWM was working correctly. It was also found that when connected to the H-bridge, the microcontroller could reliably control the motors for different speeds. 85

89 Interrupts Interrupts are enabled as described in design section The two interrupts needed to be tested are ones from when the MSP430 receives data from the UART receive buffer and the when a bit from a port goes high. A program is designed to blink the on board LED in an infinite loop. Also in the program are two interrupt vectors that will run when their respective interrupts are generated. While the program is in the infinite loop, unless the interrupts are working properly, it will not do anything else except blink the LED. So the interrupts are configured to echo back everything typed, and write back a! character when the on board switch at P1.3 is pressed. Enabling the interrupts for certain events isn t just enough for interrupts to work, they need to be enabled in the status register as well. The output for this test program is similar to figure when the same phrase is typed in the terminal, but includes several! for when the button is pressed. Low Power Mode Low power modes will be useful for saving power and extending battery life. A program is written that enables low power mode as described in design section Since the CPU and clocks are disabled the device will no longer be able to execute any code except if it receives and interrupt. The program is designed to enable low power mode, then blink the on board LED in an infinite loop. However, once it enters low power mode it will not be able to blink the LED until low power mode is left, since the CPU is off and no instructions are being executed. Since the processor is able to execute code when an interrupt is triggered, the button at P1.3 is set to trigger an interrupt when pressed. When this program is tested, the processor does not blink the LED since it has entered low power mode. When the button is pressed the LED begins blinking, indicating the interrupt worked and that low power mode was left. The prototype testing for interrupts and low power modes show they work together. It needs to be ensured that the device can reliably enter low power mode and leave it. After the project was completed low power modes were tested and they worked exactly as they should. 6.6 Software Test Environment The remote control application is a critical part of the KnightroKart design. As a result, extensive testing will be done throughout the development process in order to ensure a high quality end product. Whenever a new feature is implemented in the design, it will be tested to ensure stability of preexisting application elements, as well as the functionality of the newly implemented software component. 86

90 As noted extensively in other areas discussing the remote control in this document, namely 4.7 Android Application Design, the remote control will be developed using Android s mobile OS and design platform. It is the choice of the developers to use Eclipse Juno with the Android IDE installed as the compiler for the remote control. The Android IDE comes equipped with a Virtual Android Device emulator in which to safely test unfinished applications for bugs and functionality. However, at the time this documentation is written the emulator does not support sensor hardware, such as the accelerometer, nor does it support Bluetooth functionality. The emulator also has a reputation among mobile application developers as being extremely slow and difficult to work with. As a result, the emulator is not of much use in testing for anything beyond aesthetics. Fortunately, Android supports direct download of developer applications to personal mobile devices. As a result, the developer s mobile device can be used as the test environment. The developer s device must meet the criteria set forth previously in the document, meaning that it will have an accelerometer and Bluetooth capability built in. In this way the device can be used to test the accelerometers. The device can also be used to test Bluetooth enabling, discovery, pairing, and communication. Also, the device will be used to test fine grain aspects of the design. These aspects include accelerometer responsiveness to movement, and to what degree the accelerometer responds. The effect on battery life as a result of the application itself as well as of Bluetooth communication will also be observed. All tests regarding the remote control done using the physical device must be repeated across any and all devices that may act as a remote control. Due to the availability of Android devices to the developers, making them virtually free to come by and present in many forms, extra devices must be tested. While the final system is designed to use only two remote controls, and thusly two Android devices, it is always a good idea to have backup remote controls. At least two backup devices will be tested for functionality. The best performing of the four or more devices tested will be chosen as the final system s remote controls. Testing of the individual features of the remote control, such as Bluetooth accuracy and connection, are already discussed in specific test plans later in the documentation. It will be noted that throughout the development process the developer must consider the user s interaction with the final system. For instance, the developer must consider the position in which the remote control will be held, including the probable angle. The developer must also take into account how the user will use their remote control. This includes the likelihood that the user will be focusing more of their attention on the racing vehicle than on the remote control itself. As a result, the developer will avoid relying on in-race pop up notifications to describe a problem or status. Odds are the user will not even notice the notification until it is too late. The developer will rely on haptic or audible feedback to notify the user of imperative information during a race. 87

91 All software related tests must take into account a wide range of potential user behaviors. One such behavior is the propensity for users to mishandle the device. Testers will test for this by pushing the software to its extremes. Testers must try to replicate probable user behaviors. One example is to violently shake the device while testing features such as communication and accelerometer values to replicate extreme user movements that may occur in the completed system. Developers will also develop with the goal of minimizing user errors. For example, the application will be designed to be hard to close accidentally, as a user may mistakenly close the application when their hand touches one of the menu buttons on the device. 6.7 Android Remote Control Testing In order to ensure the remote control is functioning correctly, it must be tested. Due to the lack of support for accelerometers and Bluetooth communication in the Android development emulator, the remote control application must be tested on a physical Android device. To begin the test, an Android device that is to be used in the system will receive the remote control application via USB connection to the development computer. Once the application has been downloaded, testing can begin. First, it must be determined whether the accelerometers are reading the correct values. Testers must keep in mind that the values displayed on the remote control are not completely exact. However, the values displayed must be within 1.0 of the recommended testing values discussed in this section. To determine if the accelerometers are functioning, lay the device on a flat, stable surface in the horizontal position, face up. The accelerometer values must be displaying the x- axis as 0, the y-axis as 0, and the z-axis as approximately 7.5. From this point forward the axes values will be denoted as (x,y,z). Next slide the phone to the right, pushing from the left hand side. The x-axis value will now be a positive number, while the z-axis value remains at approximately 7.5, giving (+, 0, 7.5). If any of these actions result in values outside of the recommended range, the program must be evaluated. Next the remote control will be tested for correct communication. To do this, close the application, and make sure Bluetooth has been disabled on the device. The test will begin by opening the application, and observing whether the tester was asked to turn Bluetooth on via pop up notification. If they were not asked to enable Bluetooth, there has been an error in the application that needs to be addressed. If the request to enable Bluetooth was received, the tester will first select no, and determine whether the Bluetooth is still disabled. If Bluetooth has been enabled when the tester selected no, there is an error in the program. If not, the program has worked properly so far. 88

92 Next, the tester will reopen the remote control application and wait for the Bluetooth enable request to come up again. This time, the tester will select yes. After the selection is made, the tester will exit the application to determine whether Bluetooth has been enabled. If it has not been enabled, there is an error in the program. If Bluetooth has been enabled, the application is functioning properly so far. Now the tester must again disable Bluetooth and return to the application. Once in the application the tester will again select yes when notified to enable Bluetooth, but this time they will stay in the application and wait for Bluetooth discovery and pairing to occur. At this point the tester will be shown a list of available Bluetooth devices nearby. The tester will select a Bluetooth device that corresponds to a vehicle. If no devices are shown, there is again an error in the program. Once a device is connected, the tester must attempt to communication with the vehicle by tilting the remote control. It is important to note that at this point in the design process, the infrared communication will not have been implemented, so the remote control will not have to wait for a go signal. While the tester tests communication between the remote control and the vehicle, they must take care to determine whether the remote control movements are matching the direction and degree of movement seen on the vehicle. The vehicle must slow down, stop, speed up, reverse, turn left, turn right, or go forward only when directed by the remote control. If the vehicle makes a movement or stops without the remote control s direction there may be a problem in the program, or possibly a communication disruption. However, this test must be done after the Bluetooth Range test and Bluetooth communication loss will no longer be an issue. Finally the Bluetooth communication test portion must be repeated using two devices and two vehicles at once. This will test for any potential issues with pairing and communication as a result of multiple vehicles. 89

93 8.0 Administrative Content 8.1 Project Milestones Week 1: Order all parts Order printed circuit board Order RC cars Begin coding remote control application Week 2: Assemble printed circuit board (PCB) Week 3: Complete remote control application code Begin coding MSP430 RC car analysis Week 4: Test remote control Bluetooth pairing Synchronize MSP430 code with Android remote control application Week 5: Test remote control Bluetooth communication with MSP430 Begin MSP430 code testing Mount PCB to RC car Test RC car motor controls Week 6: Construct test track Apply infrared lights to test track Test remote control accelerometer accuracy Complete Bluetooth range testing Week 7: Complete LED network testing Begin RC car testing Begin infrared system testing Week 8: Complete Android remote control testing Complete MSP430 testing Complete infrared system testing 90

94 Week 9: Finalize MSP430 code Finalize Android remote control code Complete RC car testing Week 10: Optimize vehicle battery life Construct second vehicle Week 11: Test second vehicle Begin Final Documentation Week 12: Test completed system Miscellaneous system testing Finalize vehicle construction Week 13: Finalize MSP430 code Finalize Android remote control code Week 14: Final tests including reliability tests Complete Final Documentation 8.2 Budget and Finance Discussion Knightro Kart consists of several components. Table below breaks the vehicles into their main components with expected costs per component. The figure represents one vehicle, so all costs will be doubled to accommodate the two vehicles in the completed system. Extraneous costs, such as extra components, are included in the pricing estimate. The completed system is expected to cost approximately $

95 Component Estimated Cost Bluetooth Module $25.00 PCB $22.00 Battery Pack $10.00 Passive Components $10.00 MSP430 $3.00 RC Car $60.00 Android Devices Tools (Crimping/Soldering) Free (already acquired) Free (already acquired or borrowed) Total Per Car: $ Table 8.2.1: Knightro Kart Cost Breakdown All developers will contribute to the financing of the system. Since there are three developers, the $300 cost will be split equally at $100 each. All parts used for the system were carefully selected due to the fact that the system is self-funded. Estimated costs were generated by taking into account the current pricing for the components that are expected to be used, as well as an additional percentage of the actual cost. The additional percentage covers any unforeseen expenses. These expenses may include damaged components, components that do not meet the required specifications, potential redesigns, etc. In the worst case scenario of a completer redesign requiring a complete reordering of parts, the design team is willing to spend an additional $200 split among the three developers at $66.67 each. However, this option should be considered for emergency use only. All reasonable efforts will be made to ensure that the $300 budget is not exceeded. Such efforts include extensively researching the parts that may be used for not only the correct specifications, but also for signs of oncoming obsolescence. It is imperative that the parts used in the system will be available throughout the design and build process. Other efforts to avoid redesign include thorough modeling of the printed circuit board design. Similarly software should rigorously be evaluated so as to best utilize the hardware components present in the system. Especially in the case of the MSP430, the surrounding hardware architecture must be taken into account. By carefully researching and modeling the completed system before construction begins, redesign can be avoided. In this way the Knightro Kart design team will be able to keep costs within the estimated $300 range. However, in case of emergencies, a $200 backup fund is available. 92

96 9.0 Project Summary and Conclusions In summary, Knightro Kart satisfied the goals and requirements for a complete design. The system utilizes several components of hardware and software to implement the design. After extensive research, the team decided on the best construction, parts, and programming languages. In terms of hardware, Knightro Kart is wealthy. Within a single vehicle subsystem several hardware components are physically connected into one integrated unit. The hardware components include the central processing unit of the MSP430, the ears and mouth of communication, commonly referred to as the Bluetooth module RN-41, and the body that is the motor controls on the RC car. Also contained in the hardware is a unique printed circuit board layout made especially for Knightro Kart, as well as a network of LEDs designed to enhance user experience. There are also power supplies for the vehicles and the infrared start line. All of the hardware components are tied together by the brain that is the MSP430. The MSP430 reads signals and messages from the various hardware components, and orchestrates the action that the user will see as their vehicle moving in the desired direction. Outside of the vehicle is the remote control device. The device is actual an Android mobile device that contains its own accelerometer and Bluetooth module. In terms of software, Knightro Kart relies on two fundamental pieces. The first belongs to the MSP430. The MSP430 has a unique instruction set. It utilizes information received from the Bluetooth module, infrared sensors, and other hardware components in order to propel the vehicle in the correct direction, at the correct speed, with as little lag as possible. The MSP430 was also able to send information back to the other software component in the design, the remote control application. The remote control application is the user s most hands on interaction within the system. The application is loaded onto the Android mobile device. It was programmed using Java and the Android IDE. The remote control reads information from the accelerometer and sends a byte of data using the phone s Bluetooth communication to the MSP430 for interpretation. Knightro Kart went through an extensive test environment. Each individual component was put through an individually focused test before the system was completely integrated. In this way, many errors were avoided, which made the Knightro Kart experience more reliable than if those tests had not taken place. The completed design is best represented by a race track circuit. Within the race track all components interact. The vehicles interact with the course via the infrared start line. Also the vehicles interact with each other in order to enact a countdown sequence for the start of the race using infrared. Similarly the vehicles interact with the remote controls. Finally the remote controls interact with the user. In this way the user has the ability to control the system. Below, Figure 93

97 9.1 illustrates the final design of the system. This design can be considered as the user s view of the design, as the user will not be immediately aware of the various subcomponents that make up the vehicles, remote control application, or infrared start line. Figure 9.1: User s View of the System In conclusion, Knightro Kart is a fully functioning interactive race system. Users are able to easily implement its features. Hardware components can interact with software components and vice versa at all levels. The completed system consists of several key parts. These key parts are represented as blocks in Figure 9.2 below. Two vehicles, two remote controls, and thusly two users are able to utilize the system at once. This is also illustrated in the Figure 9.2 below. 94

98 Figure 9.1: Block Diagram of Final Design Components and Their Interactions 95

99 Appendices Appendix A: Copyright Permissions All unoriginally authored diagrams and tables in this documentation is free for use under Open Source permissions. Screenshots of the applicable permissions are shown below for reference. The licenses can also be viewed at developer.android.com/license.html/#terms and er+ot+footer_copyright.

100