accelerometer controlled rc vehicle.pdf

7/27/2019 Accelerometer Controlled RC VEHICLE.pdf

1/50

1

CHAPTER-1

INTRODUCTION

1.1 PROJECT OVERVIEW

In this project we decided to build a vehicle controlled, using

accelerometers, by a remote control that wirelessly transmits, using RF technology,

data to the vehicle to move in any direction. The accelerometers will be mounted

on a steering wheel shaped remote control, such that if the user wants to move

forward they can lean the steering wheel forward and backward for reverse; to turn

left or right they need to turn the steering wheel like steering in an actual car, all in

manual mode.

In addition there is an automatic mode during which the vehicle goes in the

direction requested by the user for the length of the distance requested by the user.

A liquid crystal display (LCD) is located on the remote control and displays the

direction, distance and mode (manual or automatic), which is user choice using

potentiometers to decide the direction and distance and mode by using a button.

We decided on this project because of its ingenuity and similarity to game

console systems games, which will appeal to users especially with the ease of use

(physically moving the remote control).


2/50

2

CHAPTER-2

ACCELEROMETER OVERVIEW

2.1. WHAT IS ACCELEROMETER?

An accelerometer is a device that measures proper acceleration. the proper

acceleration measured by an accelerometer is not necessarily the coordinate

acceleration (rate of change of velocity). Instead, it is the acceleration associated

with the phenomenon of weight experienced by any test mass at rest in the frame

of reference of the accelerometer device.

An accelerometer thus measures weight per unit of (test) mass, a quantity

of with dimensions of acceleration that is sometimes known as specific force, or g-

force (although it is not a force).

2.2 MMA6261Q ACCELEROMETER:

The MMA6200 series of low cost capacitive micro machined accelerometers

feature signal conditioning, a 1-pole low pass filter and temperature compensation.

Zero-g offset full scale span and filter cut-off are factory set and require no

external devices. A full system self-test capability verifies system functionality.

2.2.1 FEATURES OF MMA6261Q ACCELEROMETER:

High SensitivityLow NoiseLow Power2.7 V to 3.6 V Operation6mm x 6mm x 1.98 mm QFN Integral Signal Conditioning with Low Pass FilterLinear Output


3/50

3

Ratio metric PerformanceSelf-TestRobust Design, High Shocks Survivability

2.2.2 FUNCTIONAL BLOCK DIAGRAM:

Figure.1.Simplified Accelerometer Functional Block Diagram

2.2.3 PRINCIPLE OF OPERATION

The device consists of a surface micro-machined capacitive sensing cell

(g-cell) and a signal conditioning ASIC contained in a single integrated circuit

package. The sensing element is sealed hermetically at the wafer level using a bulk

micro-machined cap wafer.

The g-cell is a mechanical structure formed from semiconductor materials

(poly-silicon) using semiconductor processes (masking and etching). It can be

modeled as a set of beams attached to a movable central mass that move between

fixed beams. The movable beams can be deflected from their rest position by

subjecting the system to an acceleration.


4/50

4

As the beams attached to the central mass move, the distance from them to

the fixed beams on one side will increase by the same amount that the distance to

the fixed beams on the other side decreases. The change in distance is a measure of

acceleration.

The g-cell plates form two back-to-back capacitors . As the center plate

moves with acceleration, the distance between the plates changes and each

capacitor's value will change, (C = A/D). Where A is the area of the plate, is the

dielectric constant, and D is the distance between the plates.

The ASIC uses switched capacitor techniques to measure the g-cell

capacitors and extract the acceleration data from the difference between the two

capacitors. The ASIC also signal conditions and filters (switched capacitor) the

signal, providing a high level output voltage that is ratiometric and proportional to

acceleration.


5/50

5

2.2.4 TYPICAL APPLICATIONS

Tilt Monitoring

Position & Motion Sensing

Free-fall Detection

Impact Monitoring

Appliance Control

Vibration Monitoring and Recording

Smart Portable Electronics


6/50

6

CHAPTER-3

ATMEGA32 MICROCONTROLLER

3.3.1 OVERVIEW

The ATmega32 is a low-power CMOS 8-bit microcontroller based on the

AVR enhanced RISC architecture. By executing powerful instructions in a single

clock cycle, the ATmega32 achieves throughputs approaching 1 MIPS per MHz

allowing the system designer to optimize power consumption versus processing

speed.

3.3.2 FEATURES

High-performance, Low-power 8-bit MicrocontrollerAdvanced RISC Architecture

131 Powerful Instructions

Most Single-clock Cycle Execution

32 8 General Purpose Working Registers Fully Static Operation Up to 16 MIPS Throughput at 16MHz On-chip 2-cycle Multiplier

High Endurance Non-volatile Memory segments 32Kbytes of In-System Self-programmable Flash program memory 1024Bytes EEPROM 2Kbytes Internal SRAM


7/50

7

Power Consumption at 1MHz, 3V, 25C Active: 1.1mA Idle Mode: 0.35mA Power-down Mode: < 1A

3.3.3 PIN CONFIGURATIONS:

VCCDigital supply voltage.GNDGround.Port A (PA7..PA0)

Port A serves as the analog inputs to the A/D Converter. Port A also

serves as an 8-bit bi-directional I/O port, if the A/D Converter is not

used. Port pins can provide internal pull-up resistors (selected for each

bit). The Port A output buffers have symmetrical drive characteristics

with both high sink and source capability.

Port B (PB7..PB0)Port B is an 8-bit bi-directional I/O port with internal pull-up resistors

(selected for each bit). The Port B output buffers have symmetrical

drive characteristics with both high sink and source capability. The

Port B pins are tri-stated when a reset condition becomes active, even

if the clock is not running.

Port C (PC7..PC0)Port C is an 8-bit bi-directional I/O port with internal pull-up resistors

(selected for each bit). The Port C output buffers have symmetrical

drive characteristics with both high sink and source capability. As


8/50

8

inputs, Port C pins that are externally pulled low will source current if

the pull-up resistors are activated.

Port D (PD7..PD0)Port D is an 8-bit bi-directional I/O port with internal pull-up resistors

(selected for each bit). The Port D output buffers have symmetrical

drive characteristics with both high sink and source capability.

RESETReset Input. A low level on this pin for longer than the minimum

pulse length will generate a reset, even if the clock is not running.

XTAL1Input to the inverting Oscillator amplifier and input to the internal

clock operating circuit.

XTAL2Output from the inverting Oscillator amplifier.

AVCCAVCC is the supply voltage pin for Port A and the A/D Converter. It

should be externally connected to VCC, even if the ADC is not used.

If the ADC is used, it should be connected to VCC through a low-pass

filter.

AREFAREF is the analog reference pin for the A/D Converter.


9/50

9

3.3.4 USART OPERATION

The Universal Synchronous and Asynchronous serial Receiver and

Transmitter (USART) is a highly flexible serial communication device.

The main features are:

Full Duplex Operation (Independent Serial Receive and TransmitRegisters)

Asynchronous or Synchronous OperationMaster or Slave Clocked Synchronous OperationHigh Resolution Baud Rate GeneratorOdd or Even Parity Generation and Parity Check Supported by

Hardware

Data Over Run DetectionFraming Error DetectionNoise Filtering Includes False Start Bit Detection and Digital Low

Pass Filter

Three Separate Interrupts on TX Complete, TX Data Register Empty,and RX Complete

Multi-processor Communication ModeDouble Speed Asynchronous Communication Mode


10/50

10

3.3.4.1. BLOCK DIAGRAM OF USART TRANSMITTER:

Figure.3 Block Diagram of USART Transmitter


11/50

11

3.3.4.2. C CODES:

3.3.4.2.1. USART Initialization

void USART_Init( unsigned int baud )

{

/* Set baud rate */

UBRRH = (unsigned char)(baud>>8);

UBRRL = (unsigned char)baud;

/* Enable receiver and transmitter */

UCSRB = (1


12/50

12

/* Put data into buffer, sends the data */

UDR = data;

}

3.3.4.2.3 DATA RECEPTION :

unsigned char USART_Receive( void )

{

/* Wait for data to be received */

while ( !(UCSRA & (1


13/50

13

CHAPTER-4

4.1 RF MODULE:The RF module, as the name suggests, operates at Radio Frequency. The

corresponding frequency range varies between 30 kHz & 300 GHz. In this RF

system, the digital data is represented as variations in the amplitude of carrier

wave. This kind of modulation is known as Amplitude Shift Keying (ASK).

Transmission through RF is better than IR (infrared) because of many

reasons. Firstly, signals through RF can travel through larger distances making it

suitable for long range applications. Also, while IR mostly operates in line of sight

mode, RF signals can travel even when there is an obstruction between transmitter

and receiver. Next, RF transmission is more strong and reliable than IRtransmission.

RF communication uses a specific frequency unlike IR signals which are

affected by other IR emitting sources. This RF module comprises of an RF

Transmitter and an RF Receiver. The transmitter/receiver (Tx/Rx) pair operates at

a frequency of 434 MHz

Figure.4. RF TRANSMITTER AND RECEIVER


14/50

14

4.1.1 WIRELESS HI POWER TRANSMITTER MODULE (RF ASK)

4.1.1.1 FEATURES

Frequency Range: 433.92MHz Modulate Mode: ASK Circuit Shape: SAW Date Rate: 8Kbps Supply Voltage: 1.5~12V Output Power : 14dBm Working temperature: -20~+85 Solder temperature: 230 (10 seconds). High sensitivity is designed.

4.1.1.2 PIN DETAILS

PIN FUNCTION DESCRIPTION

1 GND Transmitter Ground. Connect to ground plane.

2 DATA_IN Digital data input3 Vcc 5V for Power supply

4 ANTENNA 50 antenna output.

4.1.1.3 THEORY OF OPERATION

OOK MODULATION

OOK modulation is a binary form of amplitude modulation. When a logical

0 (data line low) is being sent, the transmitter is off, fully suppressing the carrier.

In this state, the transmitter current is very low, less than 1mA.


15/50

15

When a logical 1 is being sent, the carrier is fully on. In this state, the

module current consumption is at its highest, about 4.5mA with a 3V power

supply.

OOK is the modulation method of choice for remote control applications

where power consumption and cost are the primary factors. Because OOK

transmitters draw no power when they transmit a 0, they exhibit significantly better

spower consumption than FSK transmitters.

OOK data rate is limited by the start-up time of the oscillator. High-Q

oscillators which have very stable center frequencies take longer to start-up than

low-Q oscillators. The start-up time of the oscillator determines the maximum data

rate that the transmitter can send.

4.1.1.4 USE OF INVERTER WHEN RF COMMUNICATION:

Data should be inverted when using the transmitter with a UART. The

normal marking state of a UART is a logic 1, which will cause constant

transmission. By inverting the data, the transmitter will be off in a marking state

and on in a spacing state (logical 0), ensuring that the transmitter is on only when

data is being sent. The output of the receiver would also need to be inverted to

properly recover data.

4.2 RF RECEIVER

The RCR-XXX-RP is ideal for short-range remote control applications

where cost is a primary concern. The receiver module requires no external RF

components except for the antenna. It generates virtually no emissions, making

FCC and ETSI approvals easy. The super-regenerative design exhibits exceptional

sensitivity at a very low cost.


16/50

16

4.2.1 FEATURES

Low Cost3MHz receiving bandwidthworks with any LC or SAW based

transmitter5V operation4.5mA current drainNo External Parts are requiredSmall Size: 1.76 x .434800 baud operation

4.2.2 PIN DETAILS

PIN NAME DESCRIPTION

1 ANTENNA 50 antenna input.

2 GND Receiver Ground. Connect to ground plane.


4,5 Vcc Pins 4 and 5 are electrically connected and provide

operating voltage for the receiver. VCC can be

applied to either or both.

6 ANALOG Analog receiver output. This is the audio signal

prior to the data slicer.7 DATA Digital data output. This output is capable of

driving one TTL or CMOS load. It is

a CMOS compatible output.



17/50

17

4.2.3 THEORY OF OPERATION

SUPER-REGENERATIVE AM DETECTION

The RCR-XXX-RP uses a super-regenerative AM detector to demodulate the

incoming AM carrier. A super-regenerative detector is a gain stage with positive

feedback greater than unity so that it oscillates. An RC-time constant is included in

the gain stage so that when the gain stage oscillates, the gain will be lowered over

time proportional to the RC time constant until the oscillation eventually dies.

When the oscillation dies, the current draw of the gain stage decreases,

charging the RC circuit, increasing the gain, and ultimately the oscillation starts

again. In this way, the oscillation of the gain stage is turned on and off at a rate set

by the RC time constant.

This rate is chosen to be super-audible but much lower than the main

oscillation rate. Detection is accomplished by measuring the emitter current of the

gain stage.


18/50

18

CHAPTER-5

5.1.LCD OVERVIEW

An HD44780 Character LCD is an industry standard liquid crystaldisplay(LCD) display device designed for interfacing with embedded electronics.

These screens come in common configurations of 8x1 characters, 16x2, and 20x4

among others. These screens are often found in copiers, fax machines, laser

printers, industrial test equipment, networking equipment such as routers and

storage devices, etc. These are not the kind of screens one would find in a cell

phone, portable television, etc. They are limited to text only, with 8 customizable

characters..

Character LCDs use a standard 14-pin interface. If the screen has a

backlight, it will have 16 pins. The pin-outs are as follows:

1. Ground

2. VCC (+5V)

3. Contrast adjustment

4. Register Select (R/S)

5. Read/Write (R/W)

6. Clock (Enable)

7. Bit 0

8. Bit 1

9. Bit 2

10. Bit 3

11. Bit 4

12. Bit 5


19/50


20/50

20

When the LCD is in the off state, light rays are rotated by the two polarisers and

the liquid crystal, such that the light rays come out of the LCD without any

orientation, and hence the LCD appears transparent.

When sufficient voltage is applied to the electrodes, the liquid crystal molecules

would be aligned in a specific direction. The light rays passing through the LCD

would be rotated by the polarizers, which would result in activating / highlighting

the desired characters.


21/50

21

CHAPTER-6

SOFTWARE DETAILS

1. EAGLE 5.6.0

2. AVR STUDIO 5

3. SINAPROG

6.1.AVR STUDIO INTRODUCTION

AVR Studio is an Integrated Development Environment for writing and

debugging AVR applications in Windows 98/XP/ME/2000 /7 and Windows

NT environments.

AVR Studio provides a project management tool, source file editor and chip

simulator. It also interfaces with In-Circuit Emulators and development boards

available for the AVR 8-bit RISC family of microcontrollers. Simplifying the

development tasks, AVR Studio allows customers to significantly reduce time-to-

market.

6.1.1 FEATURES OF AVRSTUDIO

Integrated Development Environment for Writing, Compiling andDebugging Software

Fully Symbolic Source-level DebuggerConfigurable Memory Views, Including SRAM, EEPROM, Flash,Registers, and I/OsUnlimited Number of Break PointsVariable Watch/Edit Window with Drag-and-drop Function


22/50

22

Extensive Program Flow Control OptionsSimulator Port Activity Logging and Pin Input StimuliFile Parser Support for COFF, UBROF6, UBROF8, and Hex FilesSupport for C, Pascal, BASIC and Assembly Languages

6.2 EAGLE

EAGLE Software was used for creating the schematic and PCB layout of the

transmitter and receiver circuit.

6.3 SINAPROG

SINAPROG software was used to transfer the hex file to the

microcontroller.


23/50


24/50


25/50

25

7.2 CAR

The car circuit consists of an Atmega32 circuit, an RCT-433-AS RF

receiver, a 7404 inverter chip, a servo motor, a main motor for the wheels and an H

bridge for the main motor. The car circuit repeatedly checks for an incoming

wireless data packet. When it gets a data packet, it checks the mode, which is the

3rd byte of data in the data packet. The mode number tells the car circuit what to

do with the other two bytes of data.

If the mode number is 0, then it means manual mode. The first byte of data

is used for determining the direction that the servo motor will direct the car. The

second byte of data is used to determine whether the car goes forward, backward or

doesnt move at all. The current motion of the car is updated accordingly.

If the mode number is 1, then is means automatic mode. In this mode, the

first byte represents the command cardinal direction that the car must move in.

The second byte represents the distance in that direction that the car shall move.

The servo motor will change the cars direction until the car is facing the desired

direction; then the car will continue in that direction until it has traveled the whole

distance. While the car is traveling, it does not accept any inputs from the

accelerometer. If the user decides to switch back to manual mode, then the car will

immediately start to move according to the accelerometer values regardless of

whether it reaches its final destination in automatic mode.


26/50


27/50


28/50


29/50


30/50

30

8.1.1.2 FLOW CHART FOR RECEPTION

Figure .8.1.2. Flow chart of Transmitter


31/50

31

8.1.2 CAR CIRCUIT PROGRAM DETAILS

The main code for the car initializes everything, then runs on an endless

while loop. The action of the main motor is represented by pins 0 and 1 of

PORTB. Pin 0 represents reverse direction. Pin 1 represents forward direction.

For the car to not move, both pins are set to 0. Because of how they are being used,

these pins are configured as output.

The servo motor is connected to pin 3 of PORTB, which is the output

compare value of the pulse width modulator (PWM). Timer0 is configured as fast

PWM, prescaled by 1024, and the output compare pin is cleared on a compare

match. OCR0 is varied to control the direction that the servo motor moves the car.

Because varying OCR0 at high resolution makes the servo motor too shaky, we

discretized the OCR0 values so that OCR0 could be only 1 of 5 possible values.

These values are in a lookup table called servo_array. The lookup table would

eliminate the need for if-then statements when determining the OCR0 value. The

specific OCR0 values chosen for the servo_array were calibrated by varying OCR0

and looking at how far the servo motor turns with each value of OCR0. We found

that OCR0 going from 10 to 40 covered the extremes in servo motor angular

position.

Pin 0 of PORTD is configured as an input so that it can receive the RF

signal.The compass is connected to pins 3-6 of PORTD, which are configured as

inputs. The compass is, by design, divided into 8 cardinal directions. When the

direction is N, S, E, or W, two of the output pins read high and two read low.

When the direction is NW, NE, SW, or SE, three of the output pins read high. A

separate function in another c file called get_direction checks the pin values in

PORTD and uses a series of nested if-then-else statements to determine which


32/50

32

cardinal direction is being represented. It is okay to assign each cardinal direction

to an arbitrary combination of PORTD pin values because the compass can be

placed on the car in such a direction that when the compass reads north the car is

actually facing north. For the purpose of easier program design, the cardinal

directions are numbered 1 to 8 where 1=N, 2=NE,,8=NW.

The main function first calls the initialization function, then goes into an

endless while loop. For each iteration of the while loop, it constantly checks for a

new input packet of wireless data. An if statement is used to give separate sets of

instructions to the car in manual mode versus automatic mode. In manual mode,

the first byte of the data packet is used to index the lookup table of OCR0 values to

update OCR0 for the servo motor. The second data packet is used to determine

whether the motor goes forward, backward or doesnt move at all. Here, an if-then

statement is used to set the pins of PORTB accordingly. If the last two bits of the

second RF input byte is 01, it means 0 for forward and 1 for backward. If they are

10, it means 1 for forward and 0 for backward. If it is 00, it means 0 for forward

and 0 for backward, meaning dont move. An input of 11 should never beencountered. If encountered, then no statements in the if-then-else statement will

be met and the activity of the main motor will not change.

When the 3rd received byte of data is a 1, the program stops entering the

code for mode = 0, and enters the code instructions for mode = 1. The first time

this set of instructions is executed, the motor is set to move forward and a timer is

initialized to keep track of how much time the car has been moving so far. Thetotal travel time for the car is a function of the second byte of wireless input data

(command distance) and the measured speed of the car. After the timer and main

motor are started, a variable, start, is set to 0, meaning that the next time this set of


33/50

33

instructions executes, it will no longer be the first time of execution. The variable,

start, is reinitialized back to 1 in the mode 0 instructions.

In the remainder of the instructions for automatic mode, the program

determines how far away the current direction is from the command direction.

First the get_direction function is used to obtain the current direction that the car is

facing based on the values of the PORTD pins. The results are stored in

current_dir and stored in a temporary variable called temp. Temp is incremented

in a while loop until it matches the command direction. Each increment makes

temp go 45 degrees clockwise or to the right. If temp has to be incremented more

than 4 times, it means that the car can more easily match the command direction by

turning left. An if-then-else statement is used to set OCR0 so that the car turns in

the desired direction or remains going straight if the current direction is close

enough (within 45 degrees) of the command direction.

The timer is incremented in a compare interrupt that is set to 1 millisecond

timebase (prescaled by 64, OCR2 = 250). If we know the cars speed in miles per

hour, we can multiply by 5280 to get feet per hour and divide by 3600 to get feet

per second. To get milliseconds, we multiply by 1000. This will give a conversion

factor of 1/[speed(mph)/3600*5280]*1000 that the command distance is multiplied

by to get the travel time in milliseconds.

When the timer variable, t, reaches the value of travel_time, the motor is

turned off (PORTB.1,0 = 00). If per chance the command distance is so short that

the car travels the command distance before reaching the command direction, then

the car will also be required to face the command direction before the main motor

turns off. Once the main motor is turned off, the program will enter a while loop

that executes until the mode changes back to mode 0. Even when the cars motor


34/50

34

has not turned off yet, the program still constantly checks for incoming data

packets during each iteration to check for changes back to mode 0. If the mode

changes back to 0, then the instructions for mode = 0 are executed once again. To

the user, this means he/she has regained manual control of the car despite whether

the car ever traveled the whole command distance. This will keep the user from

accidently sending the car off a cliff or something by making command distance

too large.

It is possible for the car circuit to be powered when the remote controller is

not. In this case, the car will receive no input packet instructions. Certain

variables must be initialized in case there is no RF reception. Mode is initialized to

0, the servo motor OCR0 value is set to its middle value so that the servo motor

makes the car face forward. The PORTB pins 0 and 1 are both set to 0 so that the

car is stationary. Command distance is set to 0.

At some point, the user may turn off the remote controller when the car is

still on. The prevent the car from moving indefinitely, the cars motor is

automatically turned off after 2 seconds of no incoming data packets. This is done

with a variable t_stop, which keeps track of the amount of time passed since a data

packet from the remote was received. When the get_data function detects a data

packet with the correct ID value, t_stop is initialized to 0. From there, it is

incremented in the timer2 compare interrupt, which goes every millisecond. When

a data packet comes in that is the wrong ID (interference), the command variables

(command direction and command for the motor) are set so that the car facesstraight forward and the motor turns off.


35/50

35

8.2 WIRELESS PROTOCOL FUNCTIONS

txrx_init(tx,rx,baud rate,led):o Initializes the UART control register to specify whether the circuit is

transmitting (tx), receiving (rx) or both. Also initializes the baud rate

control register to give the inputted baud rate.

tx_me(data,data_length,tx_id):o Transmits a characters string, data, of length data_length that has a

transmit ID tx_id. tx_id is an ID number that represents from which

transmitter the data packet came. This is useful for when more than

one transmitter is being used or when other people present are using

transmitters.

DecodeOne(msbyte):o Uses a lookup table to find the true transmit ID associated with the

numerical value presented in the received packet

rx_reset():o

Sets up the system to wait for another incoming data packet tx_done():

o Returns 1 when the transmission is complete; 0 otherwise rx_done():

o Returns 1 when a data packet has been received; 0 otherwise init_getrx():

o Initializes the current index value to 0 for when the data packet isbeing read

get_next_rx_data():o Gets the next char value in the received data packet. Index value is

incremented


36/50

36

CHAPTER-9

9.1 HARDWARE DETAILS

9.1.1 REMOTE CONTROLLER HARDWARE DETAILS

The remote controller circuitry is mounted onto a steering wheel. The

Atmega32 circuit, accelerometer, inverter chip, potentiometers, transmitter and

LCD are all powered by a 5V power supply. The accelerometer outputs are each

connected to a pin of PORTA. Each potentiometer (for command direction and

command distance) is connected to another pin of PORTA. PORTA is the port

that has the ADC inputs and is configured as all inputs.

Pin 1 of PORTD is used to output the signals that are to be transmitted

through the RF transmitter. Meghans wireless protocol requires that an inverter

be placed between the MCU and RF transmitter. Therefore, pin 1 of PORTD is

connected to one of the inputs of the inverter chip. The output goes to the

transmitter.

The RF transmitter has 4 leads: one power, one ground, one input and one

antenna. Meghan Desais wireless protocol specs require that the antenna by

wavelength long. The RF transmitter is 433 MHz. The speed of light in meters

per second divided by 433X10^6, then divided by 4 yields a length of about 8

inches.

The LCD has 14 pins. The first two pins are connected to ground and

power. Seven of the other pins are connected to PORTC. PORTC must therefore

be configured as all outputs.


37/50


38/50

38

9.1.2 CAR CIRCUIT HARDWARE DETAILS

The Atmega32 circuit, receiver, inverter chip and compass are all powered

by the same 5V power supply. The servo motor runs off of a 3.7V power supply,

but must still be grounded from the same ground as the MCU. The main motor

runs off a separate power supply all together. An optoisolator protects the rest of

the circuit from the noise of the main motor. An H bridge is used to channel a

sufficient amount of current into the motor in either direction to allow the motor to

rotate in either direction. A 10uF capacitor is used to filter out noise on the power

line due to the two motors.

The RF receiver has 8 leads. The first lead is the antenna, which like the

transmitter must be wavelength long. Pins 2,3,8 are grounded and pins 4,5 are

powered. Pin 6 is the analog output, which is not used. Pin 7 is the digital output,

and is connected to pin 0 of PORTD through an inverter. This inverter inverts the

signal back to what it was when it was outputted from pin 1 of PORTD on the

remote controller.

The servo motor has 3 leads: power, ground and signal. The signal lead is

connected to pin 3 of PORTB where it is fed the PWM signal whose duty cycle

determines the angular position. The servo motor was assembled into the Lego car

in such a way that when it makes a complete rotation, the wheels turns from all the

way left to all the way right.


39/50


40/50


41/50

41

system not working. At one point there were people nearby transmitting in GHz.

Our data never showed up on the LCD then because we were receiving their data at

a much higher rate.

We also seemed to get interference from other sources of wireless

transmissions, such as laptops and Wi-Fi routers. We are not completely sure

about it, but our hypothesis is based on that fact that project would work perfectly

in areas without any wireless traffic and would always stop working in places high

in traffic, and additionally Professor Belina suggested that Wi-Fi would interfere

with our transmissions. Additionally, we had another problem that whenever we

lost transmission due to interference or anything like that our chip would

completely shut off until we either reset it or completely reload the program back

onto the chip.

When we tried to achieve bidirectional transmission, we ran into even more

difficulties. We figured that if we programmed the Atmega to alternate between

transmit and receive mode every so many times a second, then one direction of

transmission could be achieved at a time. We found during testing that when we

got a block of code to receive successfully, then added another block of code to

transmit a few times a second, that the receiver would just stop receiving.

This is a problem because we want to remote controller to constantly send

accelerometer data to the car to move it adequately without having to allow long

periods of time in between to receive data for the cars speed and direction. If the

remote controller needs a large block of time to adequately receive a data packet

from the car, then the user would not be able to alter the motion of the car very

quickly. It would only cause frustration to the user, only for the purpose of giving

the user information about the cars motion that he/she may not even care about.


42/50

42

We found out the hard way that the wireless protocol system that we were

using was insufficient for the fast bidirectional communication that we wanted for

a playable remote controlled car.

Another major source of difficulty was in the main motor. We had

tremendous difficulty in getting the proper power supply (voltage and current) to

the motor. We could not power the motor adequately off the proto board because

it did not deliver the proper amount of current. When we used this other power

supply, the motor started to get overpowered.

When we finally did get the main motor to rotate, we found that when we

touched it slightly it would stop rotating. Not only that, it needed a push just to get

rotating again. When we got a more powerful motor, we found that the Lego car

that we built was far too heavy even for the powerful RC motor we found.

We had to make a smaller less impressive looks car without all the fancy

shocks and gears we had before. Even then the car barely moved when we put it

onto the floor.

It also took hours to get the H Bridge to draw the right amount of current.

This was extremely difficult to figure out the reasoning behind why this was not

working. We tried many basic H Bridge designs from many websites trying to get

the motor to start moving. However, every single design we tried never seemed to

draw enough current or enough voltage and sometimes both were lacking.

As a result, we decided to try having more and more complex circuits with

higher gain power transistors such as the TIP 31 and TIP 32. This did not work as

well even though these transistors were rated at around 4 Amps they still would not

draw more than 1.5 Amps, which our motor needed. Then we decided that we


43/50


44/50


45/50

45

10.3 RF FREQUENCY LAWS AND SAFETY REGULATIONS

In our robotic vehicle design project, we will need to take a few safety

issues into consideration. Firstly is the controller for the robotic vehicle, which

will be manipulating the vehicle wirelessly. We will be using an RF (radio

frequency) protocol that will follow all safety regulations instituted by ANSI and

IEEE for using such wireless technologies without affecting humans at all since the

FCC does not mandate any federal regulations as of yet and recommends using

these as the federal standards. This will be done by limiting the frequency between

100-300 MHz and using 0.1-0.4 W/kg as stated by ANSI and the IEEE


46/50

46

CHAPTER-11

RESULTS

Data is transmitted from the remote controller to the car at about 4 timesper second. Therefore in manual mode, the direction of the car is updated at about

4 Hz. Because of the shakiness of the servo motor, the direction of the car cannot

be chosen by the user to a very high accuracy. The direction is only discretized

into 5 possibilities.

Because of difficulties in just getting the motor to move, we decided it

would be too much to ask for the user to determine the direction of the main motor

with the accelerometer. Instead, we decided to only determine whether the motor

moves at all and in what direction.

The user also can only determine the command direction to a limited

accuracy because the compass only has 8 cardinal directions on it. For instance,

the user cannot choose a command direction halfway between NW and W.

Therefore, the maximum discrepancy between the desired command direction and

the closest possible command direction is 22.5 degrees.

The whole system is fairly playable aside from the unreliability of the main

motor. The user simply turns on the remote control and the car. The default

starting point is manual mode, which is how users usually operate remote

controlled cars. The user can steer the wheel left or right and the car will move left

or right. A simple turn of the knobs on the steering wheel allows the user to adjust

the command direction and command distance. A push of the button sends the car

off. An additional push of the button stops the car from moving on its own.


47/50

47

The safety considerations are fairly minimal. The biggest concern we can

think of is what may happen if the equipment got soaked with water. Perhaps there

may be a risk of the holder of the remote getting electrocuted. As such, we would

recommend placing a clear warning on the car and remote controller that the

device should be kept dry at all times. In addition, we think that the circuitry

should be covered preferably by an insulator to prevent the user from touching the

inner circuitry, which may get pretty hot.


48/50

48

CHAPTER-12

CONCLUSION

We had experienced much more difficulty than we had anticipated.Overall, we thought that the whole project seemed straight forward, but there were

many complications from the unreliability of wireless reception to power supply

problems with the main motor. We thought that we were going to have a nice big

fancy Lego car with shocks and huge gears (10:1 gear ratio) moving at 25 mph

possibly. Instead we found surprising difficulty just getting the motor to move at

all, more difficulty in getting it to move the wheels with the gears and even more

difficulty getting the car to move when it was placed on the ground.

We had to make many adjustments, particularly to the motor we were using

and to the design of the Lego car. The Lego car had to reduce in size dramatically

so the RC motor could move it. The RC motor, which can go up to 25 mph, had to

be cleaned out. There still was difficulty after it was cleaned out. Now instead of

the big robust fast-moving car we pictured, we have a little car with 3:1 gear ratio

that moves a little if we are lucky.

We also needed to make adjustments with how the servo motor was

controlled so that it would not be so shaky. As a result, we did not get that nice

continuous control of direction by the user that we had expected. We also could

not allow the user to continuously control the speed with the accelerometer as we

had thought we could because it was so hard just to get the motor to move the car

at all.

For a while we went around in circles, but once we committed to

unidirectional transmission alone, there was progress to a working product. The


49/50


50/50

REFERENCES

Wireless protocol page:o http://instruct1.cit.cornell.edu//courses/eceprojectsland/STUDENTPR

OJ/2005to2006/mpd25/report.html

H Bridge design page:o http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2007/djd3

3_tm253/final/final.htm

Description of LCD pinouto http://instruct1.cit.cornell.edu/courses/ee476/labs/s2008/lab1.html

ATMEGA32 datasheetMMA6261Q datasheetRCT-433-AS datasheetRCR-433-RP datasheet7404 datasheet

accelerometer controlled rc vehicle.pdf

Documents