Knightro Kart

1. Knightro Kart Liz Lyons Mike Scherban Oscar Orihuela

2. What Is Knightro Kart? An interactive, Android controlled vehicle race system consisting of two independent cars and controllers. • Vehicles are controlled by Android powered mobile devices or tablets • Consists of two independent vehicles, a track utilizing infrared, and two independent remote controls

3. System Block Diagram

4. Walkthrough

5. System Specifications

6. Remote Control Mobile device is used in landscape mode. It utilizes hardware level sensor data, and interprets it to tell the MSP430 how to direct the vehicle.

7. Why Android? • Essentially free – No new hardware costs, free SDK, familiar languages • Open source platform, easy to learn

8. Target APIs 10 (Android 2.3.3 Gingerbread and higher), approximately 94.2% of Android market Jelly Bean Ice Cream Sandwich Eclair Honeycomb Froyo Gingerbread

9. Target APIs 10 (Android 2.3.3 Gingerbread and higher), approximately 94.2% of Android market Jelly Bean Ice Cream Sandwich Eclair Honeycomb Froyo Gingerbread

10. Wireless Communication Choices

11. Remote Control Requirements Android device must: • Have Bluetooth capability • Contain accelerometer sensors • Have touch screen • Run Android 2.3.3 Gingerbread or newer OS

12. User Interface • Home screen displays current lap, accelerometer values, and connected devices (if any) • Menu allows user to control the state of the remote control application • Connect A Device – connect to a vehicle • Start – send signal to BT module signifying ready to race • Reset Remote Control – reset application variables, sever connections • Exit – close the application and disconnect any active Bluetooth connections

13. User Interface • When user selects “Connect a Device” from the menu they are presented with a list of paired devices. • User can also search for unpaired, discoverable devices in the area • If connection is successful, the name of the connected device will be displayed on the main remote control screen.

14. User Interface • Home screen displays current lap, accelerometer values, and connected devices (if any) • Menu allows user to control the state of the remote control application • Connect A Device – connect to a vehicle • Start – send signal to BT module signifying ready to race • Reset Remote Control – reset application variables, sever connections • Exit – close the application and disconnect any active Bluetooth connections

15. Handling Accelerometers Accelerometers are seen by the devices relative to an imagined coordinate system. • We use the Y (left/right) and Z (forward/back) axis values to control the cars

16. Bit Assignment Special Signals WAKEUP: 0xFF RESET: 0xBB

17. Bit Assignment

18. Bluetooth Module Roving Networks RN-41 • Minimal configuration • Baud rate • Auto slave, SPP • Built in antenna • Automatically pushes & pulls data via UART RX/TX pins • Runs own Bluetooth stack • Low power • 3.3V • 100m range

19. Microcontroller 2.75” 2.75”

20. Microcontroller • Same voltage as Bluetooth module • No voltage level shifting • More feature rich IDE • Viewable registers • Real time setting/variable adjustment • Disassembly • SW breakpoints • G2553 variant • HW UART support

21. Microcontroller

22. Programming and Debugging • Code Composer Studio free license • JTAG used to take advantage of IDE debugging features • Connect through TI USB FET device to 14 pin header

23. Motor Signals • LEFT/RIGHT uses digital signals • FWD/REV take advantage of hardware PWM support • PWM used to add variable speed Slow Fast!

24. Microcontroller Comm. • MSP430Module: UART, 9600 baud rate, interrupts* • TrackVehicle: Port interrupt*, debounced • VehicleVehicle: Watch for port low to high change • *Interrupts: To catch events when they happen, opposed to hanging code and waiting to catch them • Interrupt code is ran regardless of which code is currently being executed

25. Low Power Mode • Bluetooth module separate from MSP430 • Allows BT pairing while MSP430 is asleep • MSP430 goes to sleep at power on and when not in race mode • Turns off clocks and CPU • Command from phone will wake the car for use • Only executes code in an interrupt

26. MSP430 Software Flowchart

27. Printed Circuit Board • Most components will be on a custom printed circuit board designed in Eagle

28. Printed Circuit Board Motors BT Module and status LEDs LEDs Track signal JTAG Power MSP430 Ready signals

29. Infrared Features • Each race vehicle contains IR phototransistors • Biased by IR light • START line consists of an array of IR LEDs • Triggers phototransistors on vehicle, enables lap counter • Infrared also used for vehicle to vehicle communication

30. Race Vehicle • 9.6V battery packrequired • Potential to travel20 mph • 2 D.C. motors • 1st Motor controlling FWD and REV motion • 2nd Motor controlling turning left and right • 17 inches long • 7 inches wide • 8 inches tall

31. Motor Options • Race car requires 2 motors • 1st Motor controls – FWD & REV motion – D.C. motor • 2nd Motor controls – Turning - D.C. or Servo

32. H-Bridge • MSP430 does not have sufficient voltage to run motors • H-bridge directs secondary power supply to motors • High/low signals received by H-bridge cause motors to spin in a certain direction • Ex: Clockwise / Counter-Clockwise / Stand Still

33. H-Bridge - Typical • Typical H-Bridge configuration • Motor represented by inner circle • Switches represent transistors • Motor is at a stand still

34. H-Bridge - Clockwise • The H-bridgeis causing the D.C. motor to spinclockwise

35. H-Bridge – Counter Clockwise • The H-bridgeis causing the D.C. motor to spincounter clockwise

36. SN754410 vs. L298N

37. SN754410 • Cost efficient : $2.16 per chip • Detailed documentation • Manufacturer: Texas Instruments • 2Chips per car needed due to current restrictions • Each motor takes up to 1 Amp

38. SN754410 Pin Out

39. Car Interior Schematic

40. Cooling • SN754410 includes built in thermal shutdown • Generates enough heat to trigger shutdown • Aluminum heat sinks added to prevent shutdown • Fans to assist in cooling

41. Power Supply

42. Testing • Had LEDs light up at certain events. • Connection successful • Byte received • Once we knew communication was successful, we tested with LEDs, SW breakpoints, and the register viewer to confirm correct bytes. • LEDs were used to confirm the correct motor output from PCB, using the tilt of the phone • Tested that the H-bridge received the correct logic and output the correct signals using a multimeter and motors • Finally tested that the car moved in accordance with the orientation of the phone

43. LED Notifications MSP430 asleep. Awaiting wake up Ready to race, waiting for other car Racing!

44. Issues Encountered • UUID assignment varies based on device receiving connection, had to look for the UUID corresponding to hardware (not android devices) • Surface mount devices smaller than anticipated • Overheating of the H-Bridge, heat sinks required • Syncing vehicles to start at the same time

45. Roadblocks • App occasionally takes more than one attempt to make a connection • Track LED spacing may be too large to trigger phototransistor 100% of the time • Cars slow down after continuous usage • Heat issue: heatsinks and fans multiplied the usage time • Needs a few seconds to cool down and run at normal speed • Unavoidable infrared light occasionally triggers phototransistors

46. What We Would Do Differently • For a more successful project we could have combined headers on the PCB to make the wiring easier and less cluttered • Use modulated infrared to prevent accidental triggers and allow outside usage • Use an H-bridge that supports more current and heat

47. Expenses

48. Questions?