28-08-2012, 04:56 PM
BLUETOOTH CONTROLLED CAR
BLUETOOTH.doc (Size: 313 KB / Downloads: 176)
Abstract
Today’s RC toys are controlled by a single dedicated (and often proprietary) controller. We endeavored to develop a remote control car that would be controlled via Bluetooth wireless technology. Since Bluetooth is a standardized and relatively reliable wireless protocol, we hoped to create a car controllable by any Bluetooth device. Additionally, Bluetooth consumes low power and has a larger bandwidth than the standard 900MHz RF link which drives most toys. This added benefit allows for sending of complex information from the car to the controlling device—something unseen in consumer grade RC cars. Our computer-controlled Bluetooth car demo showed the feasibility and practicality of Bluetooth controlled devices while also revealing limitations in the amount of data transmission capable by commercially available Bluetooth options.
PROJECT DESCRIPTION AND OVERVIEW
Bluetooth Car
The core of our project (and also the component required for completion by the end of the semester) was a Bluetooth car. The requirements for the Bluetooth car were that it must connect wirelessly to a Bluetooth host and that the host must be able to control the car’s movements: forward, backward, left turn, right turn and stop.
Cell Phone Interface
Once Part I had been completed, we desired to control the car from a second Bluetooth device such as a cell phone. Many cell phones currently on the market are equipped with Bluetooth technology and some provide access to their Bluetooth hardware via J2ME: a small java virtual machine distributed with mobile devices. As an extra flashy feature of our car, and to further demonstrate the interoperability of Bluetooth, we wanted to write a J2ME MIDlet (mobile application) to replace the PC from Part I.
Video Stream
If time permitted, we wanted to explore transferring large amounts of data over a Bluetooth link. In order to best push the Bluetooth protocol to the edge, we wanted to attempt a live video stream from the car back to the host PC or cell phone. This was certain to be challenging because: 1) Bluetooth does not have the bandwidth for anything close to full resolution VGA video, 2) the lack of inexpensive digital video cameras on the market required us to decode analog NTSC video into a digital format for transmission, and 3) Our prior experience with video was limited.
Car Chassis/Motors
Due to time constraints and the fact we are electrical and computer engineers (not mechanical engineers), we choose to purchase a cheap RC car from Toys R’ Us and use it for the existing motors and chassis. An identical car is not necessary to reconstruct our design, however when shopping for a car try to insure that both motors are brushed DC motors. Specifically, ensure that the front motor is NOT a servo. A servo motor would require motor control design modifications that are not discussed here within.
Bluetooth Module
We began the hardware design process by finding a suitable Bluetooth module. Initially, our only requirement was the module would need to handle the wireless portion of the protocol by converting the raw Bluetooth data to/from a 2.4GHz wave allowing us to simply deal with the digital bits. Had we settled with this solution, we would have also needed to implement the entire Bluetooth Serial Port Profile (BSPP) in software on the PIC microcontroller. However, after some research we found the BlueRadios BR-SC30A available from Sparkfun Electronics.
This BR-SC30A module satisfies the original requirement, implements a Bluetooth stack and also provides the BSPP. The module is a dual inline package with an integrated antenna convenient for breadboard development. The hardware interface consists of power, ground, reset, factory reset, connection status, operation status, and a 3.3V RS232 interface. Needless to say, we opted to use this module as our Bluetooth solution.
Initial design with the BlueRadios module was successful despite the poor spec sheet provided by the company. In order to isolate debugging, we worked with the UART interface on our PIC by using a logic level converter and a serial cable on the PC. Once the UART interface was working, we then replaced the level converter with the BlueRadios module. At this point, we could say with certainty that any issues with connectivity and data transfer were confined to the BlueRadios module. This approach resulted in speedy development with no major complications.
After weeks of testing and building a complete car control circuit with the BlueRadios module, we copied the hardware to a different breadboard on the car chassis. It was at this point we discovered something very peculiar. With the wiring exactly the same—diode for diode, wire for wire, color for color, wire length for wire length—we were unable to establish Bluetooth communication with the BlueRadios module while it was on any other breadboard. However, moving the configuration BACK to the original breadboard resulted in Bluetooth communication that was immediate and stable. Eliminating variables, we placed the new breadboard in the exact physical location of the working breadboard: no luck. Eventually we determined the Bluetooth module could not source enough current for the status LEDs, but for some reason this did not surface as a problem on the original breadboard.
PIC Microcontroller
In our initial foray into remote control car development we learned that most cars use a two motor system, one in the back to push the car forward and one in the front to turn the wheels left and right. We also discovered that the front motor is usually a servo motor which requires a pulse width modulator (PWM) for control. Since we had thought about controlling the rear wheel with a PWM as well, we needed a PIC capable of driving two PWMs independently and without software control, if such a PIC existed. We also wanted to have hardware UART to communicate with the Bluetooth module. This led us to find the PIC 18F4320.
The PIC 18F4320 maxes out at 10Mips with a 40MHz oscillator, has two independent PWM controllers, 34 I/O pins, hardware controlled I2C, hardware controlled UART, is capable of external interrupts, and is way overkill for just a remote control car. It was perfect. The final design with the onboard video was going to use two of these chips, one for receiving commands and controlling the motors and the other for buffering and streaming the compressed video. See Figure A.1 in appendix A for the main circuit diagram.
The firmware for the motor control PIC is very simple and straightforward. On boot up, the PIC initializes the UART port and the PWMs. It then sits in a tight loop waiting for a flag called TXIF in a special register to go high. This flag signifies that a serial byte has been received. Once the software receives this signal, it copies the byte from the UART register and compares it to the list of acceptable commands. If it matches one of the commands the corresponding code is executed before going back to the loop that waits for serial bytes. This PIC uses PORTB to control the four lines leading to each motor’s H-bridge.