Difference between revisions of "S14: Need For Speed"

Revision as of 01:01, 23 May 2014

Abstract

Android RC Car

This page contains design and implementation of our Embedded Software project, Need For Speed. It's about maneuvering an RC vehicle using the Acceleration Sensor in a smart phone. An Android Application is developed to transmit the Acceleration Sensor Signals to the vehicle via Bluetooth. The car is mounted with a Bluetooth module to receive data from the phone. And the acceleration and turning of the vehicle will be based on this data. The vehicle is also mounted with two Infrared Sensor modules for collision detection, one in the front and other in the rear.Detection of any obstacle in the vehicles path will bring the vehicle to a halt state immediately.

Introduction

Logo for our Android App

In this project we are using JY-MCU Bluetooth module to be the wireless link between the smartphone and the battery powered RC vehicle. The Android application is developed to transmit a particular byte for every threshold value of the Acceleration Sensor i.e. when the phone is one byte for front tilt and another for back. This received byte is compared by the SJOne board with few predefined values and accordingly PWM signals are given to the motors.

The input of the IR sensors is connected to the hardware interrupts on the SJOne board, the interrupt subroutine will be called every time there is an obstacle in the path of the vehicle, this subroutine will in turn stop the vehicle.

Objectives

As this project is both software and hardware based, our objectives were as follows;

• Hardware Objectives
  • To achieve a constant 6V DC supply for the motors and 5V DC for the board from the battery.
  • To interface the motors to the SJOne board via L298 motor driver.
  • To calibrate the IR sensors to sense obstacle in 6" proximity.
• Software Objectives
  • To develop an Android application to send the data from Acceleration Sensor via Bluetooth.
  • To develop a FreeRTOS code to receive these signals and process them.
  • To develop a FreeRTOS code to send PWM sigal to the motor for variable speed.
  • To develop a FreeRTOS code to accept interrupt from the IR sensors and take actions accordingly.

Team Members & Responsibilities

• Amey Patil
  • Hardware Design
  • Free RTOS (Part 1: To interface motors and LPC1758 using PWM)
  • Free RTOS (Part 2: To configure the Bluetooth module)
• Siddhata Patil
  • Free RTOS (Part 3: To send and receive data between Bluetooth module and LPC1758)
  • Android Application(Part1: To send data from Android Phone to LPC1758)
  • Android Application(Part2: To send results of accelerometer sensor from Android Phone to LPC1758)

Schedule

Parts List & Cost

Design and Implementation

The above Block Diagram shows the overall implementation of the project. The accelerometer values (x, y, z) are used as an input by the android application. Depending on the instantaneous values, tilt will be determined. This tilt value will be provided to the Bluetooth for transmission. At the receiver, this tilt data will be received by the Bluetooth Module and provided to the LPC 1758 board via an UART channel. The on board processor will compare the received data with the stored values and generate PWM signals accordingly. The motor driver upon reception of this will driver the vehicle in the respective direction. We will see detailed explanation of the hardware and software in their respective sections.

Hardware Interface

Let us understand the whole structure piece by piece.

1. LPC 1758 SJOne Board

This board was a part of our course on Embedded Software at San Jose State University. For more information on the SJOne board Click_me.

Power Supply Schematic.

2. Power Supply

We need to generate steady 5V supply for the board while 6V for the motors without any current limitation otherwise the motors will not give its optimum output. To our luck, LM7806 voltage regulators are also available in the market along with the LM7805. The circuit schematic is as shown in the figure above.

The total current requirement of the circuit is around 1Amp. If this much current is to be drawn through the regulators then we must make sure the heat generated is properly dissipated, so we use heat sink. Most of the current will be driven through the LM7806 regulator as it drives the motors hence, we made sure that it is not surrounded by any other component. As, the LM7805 regulator just drives the SJOne board and IR module, current flowing through it is around 100mA. Hence, this regulator won't heat as much as the other one.

Motor Driver Schematic.

3. L298 Motor Driver

You must be thinking why didn't I use L293D as it is best for 6V motors and much easy to interface. Well, one of our motor consumes 200mA of current, which makes the total current 800mA that too in no load conditions. With load it might have seared upto 1A. Now the maximum handling capacity of L293D is 1A while that of L298 is 2A. Hence, for safety reasons I went for L298 motor driver. The pin connect for this interface is as shown in the above figure. The functions of the pins are as follows;

IN1 receives 'PWM input for left motor +' from LPC 1758 and drives OUT1

IN2 receives 'PWM input for left motor -' from LPC 1758 and drives OUT2

IN3 receives 'PWM input for right motor +' from LPC 1758 and drives OUT3

IN4 receives 'PWM input for right motor -' from LPC 1758 and drives OUT4

SENSE A limits the current for Left Motor

SENSE B limits the current for Right Motor

VS: Supply voltage for the Motors

For more information on L298 Driver, Click_me.

IR Module Schematic.

4. IR module

The IR module we are using is custom made. It is is designed to output logic '1' if any obstacle is detected or else logic '0'. The output signal from the IR receiver is directly proportional to the amount of IR waves falling on it. Hence, the output voltage for an obstacle far from the receiver will be less than that of a closer object.

In any case this output is in millivolts hence, we gave it as an input to LM358 which is a dual op-amp IC. This op-amp is configured in comparator mode. When the input at the non-inverting terminal is higher than the threshold voltage provided to the inverting terminal, the op-amp will give a logic high output. Hence, the threshold voltage is inversely proportional to the distance of the obstacle. So we connected a potentiometer at the input of the threshold voltage by which we can vary the range of obstacle detection.

In the case of IR the sensitivity of the reciever is not sufficient to detect obstacle at a longer distance. We were able to acheive obstacle detection in 2 inches of proximity. If, you are looking for detection at a longer distance, we would suggest you to go for Ultrasonic sensor modules which can even give you the distance of the obstacle from the vehicle.

Figure shows the circuit schematic of the IR module. This is circuit for one of the IR module. Two such circuits are implemented for front and back.

Hardware Design

This section emphasizes on how all the modules we saw above were put together. It was really a task to accommodate all the devices on the chassis. The following image shows the hardware in progress followed by the final product.

Work in Progress.

Let the Beat Drop!!

Hardware Implementation

Frame and Inner Placement

[[]]For convenience, a New Bright toy RC car was purchased and disassembled. The motors and wheels were already pre-mounted onto the chassis. Motor controllers could easily control the motors to drive and steer the vehicle. On the chassis, slots above the wheel wells were large enough to house motor controllers while the center of the chassis provided enough room to include a small breadboard and the microcontroller. All wires were shortened to the shortest length possible to reduce clutter.

FreeRTOS Programming

The Bluetooth module is nothing but a UART device to the processor. The code is designed to generate an interrupt whenever data is received by the module. This interrupt calls the interrupt_Handler

Power Supply

The battery box beneath the car provided additional convenience. It housed five 1.5-volt AA batteries that supplied up to 7.5 volts in series. This power supply provided enough power to run all of the components of this project. Whenever existing batteries began to run low on power, new batteries could be swapped into place easily. The following list describes the power requirements of each part used:

Motion Sensor

[[]] The passive infrared sensor measures changes in the environment, using heat as an indicator. It signals the pin low when it detects a change in heat. Three pins, with associated wire colorings, are used: red for voltage source, brown for ground, and black for alarm signal. The alarm signal can be connected to any pin on the microcontroller that can handle GPIO. Also, a pull up resistor is needed on the pin to GPIO. The pull up resistor is required because the sensor alarm pin is an open collector. Without this resistor, the value of the alarm will merely fluctuate between low and high constantly. Shown below are the connections between the microcontroller and the alarm:

Distance Sensor

[[]] The SRF02 ultrasonic range finder (distance sensor) can operate through serial mode or I2C mode. This device carries five pins: +5V VCC, SDA, SCL, Mode, and Ground. Since the I2C mode is used, the mode pin doesn’t need to connect to anything. The SCL and SDA lines are connected to the pins that support SCL0 and SDA0 on the microcontroller. These pins also need a pair of resistors because I2C is an open collector.

5A Motor Controllers

The motor controllers were used to adjust speed on the motors. The controllers maintain a continuous 5A current while applying voltage. Interfacing the motor controllers requires three pins: PWM, direction, and ground. Pins were initiated prior to using the motor controllers. The rear motor used PWM while the front motor used GPIO in place of PWM.

Switch

[[]] A single-pole double-throw switch was added to the board to quickly connect and disconnect power to the system.

Android App Developement Design

Controller stage in Progress

Circled is our Android App

Using Android SDK

Android Application Developement was new to both of us. So we started with basic lectures on Android SDK. In our Android Application our objective was to pair bluetooth device on our phone with the bluetooth module that we used with SJOne Board. For pairing of devices we used the search and scan method of bluetooth devices insted of using IP address. Thus making it more User friendly. Once the pairing was done successfully we went to the next step, which was designing of Controller for the RC Car. In this process we designed lots of controllers like remote based controller, joystick based controller and finally settled to the motion controller with the help of the in built accelerometer sensor of the android device. This was done using tilting motion of the android device. Here the device was calibrated such that the parallel position with respect to ground was considered zero position.

Bluetooth Pairing

Testing the Android Application

Testing on Hercules

The Testing was carried out by using the android device in developement mode. In this mode, we had enabled USB debugging which allowed us to run our Android Application directly on our Android Device, thus saving lot of our time due to the slow emulator. When the project was build successfully, the APK file was then transfered to another android device and thus double testing was carried out. After the Android Application was ready, it was time to test the interface of the hardware. For this, we had to first check whether the android device was able to send data to the SJOne Board via bluetooth. This was done by connecting the SJOne Board to the Laptop. The result were seen on Hercules. If you enlarge the image you can see various numbers which show a successfull sending of the data. We have conditions like Forward, Backward, Right, Left and Halt. Each one is assigned a different integer value as seen in the screenshot.

ANDROID APP PACKAGE

In our Android App Package, CMPE_244_NEED_FOR_SPEED, we have developed two activities. Our first Activity is the MainActivity which searches all the Bluetooth Devices possibly available and pairs the one we click on. For this purpose we have used the scanning of devices method instead of the IP Address technique. Once the pairing is successful, it will go to the next activity which is JSActivity which sends charachters and integers via bluetooth to the SJOne Board. This different data are send with the help of accelerometer Sensor in the Android Device. This is done by tilting the device. These sensor values were calibrated using the code in JSActivity. For accelerometer results, we find values of x, y and z values. These values are thus converted into integers and send via Bluetooth. We have made many projects before, until we finalized this one. We also made one spare application, in which we had a joystick kind of controller. This was done using Android Widgets. But we liked the accelerometer android app more and decided to go with it. Thus for this app, we have two files in source folder, one is MainActivity.java and other is JSActivity.java. Their corresponding xml file were written in Relative Layout format. One is activity_main.xml and other is remote_active.xml. And finally in AndroidManifest we declare the MainActivity first and after that we declare the JSActivity.

Pulse-width Modulation

Pulse-width modulation, or PWM, allows a motor controller to govern the speed at which a motor turns. Two key features of a PWM driver are the frequency, which determines how often a cycle repeats, and the duty cycle, which controls the speed of the motor spinning. The PWM driver allows the microcontroller to send out pulses based on the frequency and duty cycle settings, similar to a person flapping a rope up and down with the other end of the rope attached to a wall. By changing the PWM's frequency, the vehicle's rear motors could be slowed down or sped up. The board pins were set up accordingly:

1. Reset P0.7
2. Assign P0.7 for PWM2
3. Assign P0.8 for direction (GPIO)
4. Set P0.8 direction as output

The PWM driver was initialized, too:

Initializing the PWM driver.

The PWM registers had to be set accordingly. Looking at the LPC2148 datasheet, the registers shown above were configured:

• PWMTCR: Timer control. Reset first with bit 1.
• PWMPR: Prescale. Increments every PCLK cycle. Set to zero.
• PWMMCR: Match control. Control if interrupt is generated. Will reset on MR0.
• PWMPCR: Control. Enables PWM in single-edge mode.
• PWMMR0: PWM period. Set to 48000 Hz to match CPU.
• PWMMR2: Duty cycle/PWM width. Compared to PWMMR0. Output duty is inversely related to PWMMR0.
• PWMLER: Latch enable. Latch in all PWMMRx.
• PWMTCR: Timer control (again). Enable counter with bits 0 and 3.

With the PWM registers initialized, the duty cycle could later be modified to change motor speed. PWMMR2 was used in this case. Therefore, if a change in motor speed was necessary, PWMMR2 could be set inclusively between 0 and 48000 to change the duty cycle.

Steering Control

At first, it seemed a good idea that PWM be used on the front motor controller. After attempting to establish PWM on the steering side of the car, Preet recommended that GPIO could handle the steering job just as well. The pins had to be initialized first:

1. Assign P0.9 as GPIO for controlling full or zero power
2. Set P0.9 as output
3. Assign P0.6 as GPIO for direction
4. Set P0.6 as output

The most difficult part of using GPIO for steering was mapping out which voltages corresponded to which steering direction. The motor controller could turn extreme left, extreme right, or stayed straight. To help determine the directions, a handy table was created:

Changing the motor between go/stop and left/right was done by either setting the P0.6 or P0.9 pins, respectively, to 1 or 0 using IOSET0 and IOCLR0. Using the help of LEDs, the correct directions and power distribution was mapped for the motor controller. It was interesting to note that to get back to center, a change of direction had to take place. For example, if the car was heading left, it had to be steered back to the right to "release" the left steering before returning to center position.

Distance Sensors: I2C

The distance sensors were designed for use on the I2C or serial buses. Based on pin availability and software convenience, I2C was used to gather distance information from the sensors. The next question was: How would the microcontroller distinguish between the three sensors? A glance at the technical specifications provided the solution. Each sensor was equipped with a handy LED that flashed its address in a recognizable sequence. Each sequence was one long flash, accompanied by a number of short flashes. The short flashes represented the difference in the current address from 0xE0 in increments of 0x02, up to 15 short flashes. Legal addresses ranged from 0xE0 to 0xFE.

By comparing the sequence emitted, a programmer could determine the sensor's set address. Also, its address could be altered to allow the I2C to accommodate additional sensors, though each sensor must be programmed individually, one at a time. This sequence was used to set each sensor:

1. Get sensor address
2. Send 0xA0 to address
3. Send 0xAA to address
4. Send 0xA5 to address
5. Send new address to address

For convenience, the following addresses were selected for the sensors: 0xE2 for the left sensor, 0xE4 for the center, and 0xE6 for the right. [[]] An I2C call is made when the microcontroller wants to retrieve information from the distance sensors. The I2C bus is shared, and the program allocates enough time to release slave devices when required. The "unit_command" variable was set to 81 to force the sensor to measure distances in centimeters. If the user wants to opt for measurements in inches, the variable can simply be changed to 80.

Locations 2 and 3 hold the newest reading in a 16-bit unsigned integer format. Through high and low bytes, the sensor readings could be retrieved. The datasheet warns that it is best to give a minimum of 65 milliseconds for the pings to fade away properly. In the code, a 75 ms vTaskDelay was added to accommodate for the wait.

Motion Sensor

As with the front motor, the pins for the motion sensor were initialized:

1. Assign P0.10 as GPIO
2. Set P0.10 as input

A GPIO input pin was designated on the microcontroller to interact with the motion sensor. The motion sensor dropped its voltage to zero whenever motion was detected, which registered sufficient data for the pin on the board.

To check for motion, the code looked for a zero on the P0.10 pin.

The system surveyed for motion eight times in 500 millisecond intervals. When motion was detected in five out of those eight intervals, the alarm was sounded. This prevented false alarms from occurring, in the event that stray, non-legitimate motion came across the sensor's environment. This diagram shows the motion surveying method: [[]]

Loading the Software

[[]]Once the program was built and compiled, a .hex file was generated, which contained the program that will be read by the microcontroller. The .hex file was transferred from computer to microcontroller through a USB cable. HyperLoad 1.1 was run on the programming computer to interact with the microcontroller via USB. Setting up HyperLoad 1.1 included changing the COM port speed to 500000 bps and target CPU frequency to 48000000. The .hex file was chosen, the proper port was opened, and the file was transferred.

Software Implementation

Task Flowchart

The program was designed to run by employing tasks that handled sensor readings and appropriate outputs. A "drive" task was assigned to handle vehicular driving, and a "SensorValue" task was assigned to continuously capture data from the distance and motion sensors. When combined, the tasks worked to drive the vehicle safely through a path. The below illustrates how the general function of the program used to control the Evil Watchdog: [[]] A timer, in conjunction with the vTaskDelay command, allowed the microcontroller to switch between driving mode and motion sensing mode. It is important to note that scanning for motion while the vehicle is moving is pointless. Unless there was a way to filter out motion caused by the vehicle, it was better to stop the vehicle briefly to look for motion before continuing driving.

Testing

Motor Controllers

The motor controllers were the first components tested once the PWM driver was written. At first, the assumption was that setting PWMMR2 to zero meant a full stop. That became untrue as the dog tried to run away at full speed. Once it was realized that a higher duty cycle corresponded to slower motion, the rear controller was successfully configured. The front motor controller was tested too. The main difficulty was in mapping out the voltage levels and voltage directions to see whether they corresponded to left, right, or center steering. Using LEDs helped figure out the mappings. An interesting point to note is that to return to center steering via GPIO, a change in steering direction must take place.

Distance Sensors

Prior to implementation, the distance sensors were placed on a breadboard to verify the accuracy of their readings. The sensors featured measurements at the centimeter level, allowing for more detailed integer readings compared to readings in inches. During testing, a tape measure was used to confirm sensor measurements. The error found was no more than 3-5% at distances up to 250 cm, which showed that the sensors were highly reliable for providing the vehicle's sight.

Motion Sensor

The motion sensor was tested independently with a voltage generator and a digital multimeter. During everything, the multimeter showed that the sensor was very sensitive to nearby movement. Another observation was that when higher voltage was applied, the motion sensor captured motion from further distances. Lastly, it was noted that there was a delay between returning from "motion detected" to "no motion detected." It turns out that the alarm signal stayed low when detecting motion for about 3 seconds before returning to high. An open collector circuit caused the delays observed.

Technical Challenges

Battery Life

Distance Sensor Placement

Motion Sensor Polling

Vehicle Weight

Conclusion

Finished Product

References

Thanks To...

• Preet Kang: Lecturer

Datasheets

• [1] Philips Semiconductors. LPC214x datasheet. August 2006.
• [2] Robot Electronics. SRF02 ultrasonic range finder datasheet. Retrieved from http://www.robot-electronics.co.uk/htm/srf02techI2C.htm

Appendix

• [Project source code is available at SourceForge]
• [Project Demonstration Video]