electronics project - brock university

15
Electronics Project Nathan Eddy and Calvin Joy April 27, 2010 Abstract The purpose of this project was to create a device that would interact with its environment independently from human interface. The device constructed was a robotic car which utilized lightsensors to detect the differences in surrounding infrared light intensity. Then, based on the car’s operating state and a preprogrammed set of instructions, the car would react with a preprogrammed response such as fleeing or approaching the light source. Mechanical difficulties included the building of a photoamplifing circuit for the IR LED’s and the interfacing of this into the car, the light intensity of the flashlight (powered by a 555 timer circuit) and making the PIC board interface with the car cross plateformable with other PIC boards (to allow for the car to become multi-plateformable). Software difficulties included the creating of an operating system that would allow for a change of operating states and would compile sensor data for an appropriate mechanical response by the car. If there had been more time allotted, the device would have had more sensors to be further aware of its physical surroundings while operating software would have been augmented to allow for better control of the device. Moreover, the device could have also been programmed with an algorithm to take specified commands (such as run away or come here) from a frequency modulated IR light source. Contents 1 Hardware 2 1.1 The Car ......................................... 2 1.2 The Photosensor .................................... 2 1.3 The Infrared Emitter .................................. 2 2 Software 7 2.1 Software Overview ................................... 7 2.2 Programs ........................................ 11 1

Upload: others

Post on 13-Mar-2022

0 views

Category:

Documents


0 download

TRANSCRIPT

Electronics Project

Nathan Eddy and Calvin Joy

April 27, 2010

Abstract

The purpose of this project was to create a device that would interact with its environmentindependently from human interface. The device constructed was a robotic car whichutilized lightsensors to detect the differences in surrounding infrared light intensity. Then,based on the car’s operating state and a preprogrammed set of instructions, the car wouldreact with a preprogrammed response such as fleeing or approaching the light source.Mechanical difficulties included the building of a photoamplifing circuit for the IR LED’sand the interfacing of this into the car, the light intensity of the flashlight (powered by a555 timer circuit) and making the PIC board interface with the car cross plateformablewith other PIC boards (to allow for the car to become multi-plateformable). Softwaredifficulties included the creating of an operating system that would allow for a change ofoperating states and would compile sensor data for an appropriate mechanical response bythe car. If there had been more time allotted, the device would have had more sensorsto be further aware of its physical surroundings while operating software would have beenaugmented to allow for better control of the device. Moreover, the device could have alsobeen programmed with an algorithm to take specified commands (such as run away orcome here) from a frequency modulated IR light source.

Contents

1 Hardware 21.1 The Car . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 The Photosensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 The Infrared Emitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Software 72.1 Software Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1

1 Hardware

1.1 The Car

The car used for this project was chosen based on its size, operation interface and price. It wasdecided that a fair sized car (large enough to mount the PIC board) that had four channels(forward, reverse, left, right) was the desired choice. Price, always a factor, was stressed to bekept low.

Initially the desired plan was to solder connections from the PIC board directly into the car’sdrive circuitry. This interface however, was abandoned for two significant reasons; primarily thisinterface could destroy the remote control receiver chip and second, it was difficult to see whereto interface since there was no datasheets available for the chip used to drive the car. The secondreason was not of too much concern since many devices utilize an H-bridge set up (see figure 1)to operate. However, after examining the ionternal circuitry of the remote control it was veryapparent that interfacing with the remote conrol was the simplest way to control the car.

The remote control operated by having the user press buttons that sent a signal to ground.Essentially, control could be taken over by having the PIC act as the user and short out theseconnections by bypassing the buttons. Simply, the PIC could send a high voltage signal to atransistor, completing the remote control’s signal circuit. Below are two pictures of how the PICwas interdfaced with the remote.

1.2 The Photosensor

For the car to drive itself apart from human interface, it had to have some form of sensors tobe able to read its environment. The original proposal was to use ambient light to send signalsto the PIC, but after revision it was decided that an infrared signal would be directed towardsthe car which would attempt to follow it. This task was to be accomplished with the help ofphotodiodes.

Photodiods would detect an IR signal and emit a voltage or back current proportional to theamount of IR they recieved. It was found that there were two methods of using photodiodes assensors: photovoltaic and photoconductive modes.

The photoconductive mode has the diode reversed biased against a voltage. When light isapplied the diode hasa back current created. Though this design is preferred for high speedapplications it also has a high DC noise and must have very clear signals. When this mode wastested on a breadboard, it could not produce a clear signal. This mode of operation is displayedin figure 4. The second mode of operation was the photovoltaic mode. The diode builds up avoltage across it in this mode, akin to a solar cell. This design is preferred for high precisionapplications but is at the mercy of its overall capacitance. After testing this mode, it was foundthat it could produce a very cleawr signal given enough resistance. This mode is displayed infigure 5.

Four photodiodes were to be placed across the front of the car to give approximately 1800 ofsight for the car. The final circuit is displayed below.

1.3 The Infrared Emitter

The signal to be received by the photodiodes was to be supplied by an IR LED flashlight.However, instead of sending a constant DC voltage, it was decided to send a very rapid butshort pulse of high voltage to the LED’s with no current limiting resistor. This rapid pulsewould provide a very bright illumination for a moment, but limit the power to be dissipatedthrough the LED’s since the duration would be a very short moment. A 555 timing circuit wasbuilt to pulse the LED’s at 1000kHz but have less than half their maximum power dissipation.

2

Figure 1: H-Bridge3

Figure 2: PIC with Transistor set-up and pin connector to remote interface

Figure 3: Remote Interface

4

Figure 4: Photodiode Amplifier in Photoconductive mode

Figure 5: Photodiode Amplifier in Photovoltaic mode

5

Figure 6: Photodiode Amplifier

Figure 7: 555 Infrared LED Light Source

6

Figure 8: 555 Infrared LED Light Source

2 Software

2.1 Software Overview

The programing for this project utilizes a top down processing methodology in a PIC programingenvironment. All steps were constructed to flow logically in order of importance, and attemptedto use the least processing needed to preform the tasks required. Flow charts are provided in thenext subsection to provide a view of how the program is divided and how the different sectionsof the code interact. The main program can be effectively broken down into Search for light andFollow light algorithms which are chosen on the Menu screen.

The Menu screen, as shown in figure 9, is simply a starting point for the user to chose whataction they would like to preform. The options include both the main light related programs aswell a user driving mode and a trick. The user driving mode simply changes the keypad on thePIC board into their corresponding controller functions. Therefor up corresponds to moving thecar forward, down is backwards and the two side buttons are directional. In order to return tothe menu screen the user inputs the center keypad button. The trick program simply executesa preloaded trick and has the car preform it, such as a burnout. Once this is completed the carreturns to the menu screen.

The Search for Light mode sets the car on a predetermined path, checking often to notice ifit has wandered into an area of high infrared intensity. This program is displayed in figure 10.The path dictated is alike to a spyrograph. This path is followed until a given area has beensearched where the car moves forward and starts the same search again. When any of the carsfour detectors find an infrared light source of a predetermined intensity, the programing willjump to the Follow light mode in order to move towards that source. Since this may not bewhat the user intended there is a delay between finding the light and following it in which the

7

Figure 9: Menu Flowchart8

car waits for user interaction. The user can interrupt the ‘Follow Light’ routine by pressing anykey on the PIC key pad; if the user interrupts the car returns to the menu screen, if not theFollow Light sequence begins.

Figure 10: Search Program

The Follow Light portion of the code sets the car reading values from each of it’s infraredphotodiodes. It’s operation is displayed in figure 11. The program then compares those val-ues, determining which is the highest at that moment. This value is then checked against apredetermined the error or noise value. While an error measurement in the calibration stagewas originally considered, this plan was eventually abandoned as it was found that the infraredbackground values change to much over the course of a classroom to be a usable comparison.The solution was to take the largest background value that was found and this voltage was usedas an absolute comparison to the photo-detector readings. If the detected value is above thispredetermined value then the car moves in the direction that detector represents. If however thedetected value is lower then the preset error the readings are repeated. If on this second time thedetector readings are still lower then the error then the car will return to the Search for Lightsequence.

In the Follow the Light flow chart there are some steps that need clarification. Firstly, Thereason that whether the front right or front left detector (photodiode) is highest, the car still

9

Figure 11: Follow Light Program

10

goes one step forward. The reason for this is the field of view each detector has. Both forwarddetectors will be highest if the light is incident in the forward direction more than on either ofthe sides. If the light is strongest of the front left detector, the car takes a small step forward.Now the incident light may be strongest on the left side detector, causing the car to step forwardleft. The steps the car makes are deliberately small so that the most control can be achieved inthis design. While this build could have been duplicated using only three detectors the range ofdetection would have been much less, leading to larger errors when the light was incident on thecar from a forward angle.

The second note of clarification is what is meant when the car moves a ’step’. A step is a smallseries of motion meant to move the car approximately ten centimeters in whichever directionspecified. This movement is composed of quick firings to the motor control, which results in asmooth short burst. Built into each step is a short delay, in order to keep the speed of the carsmovement low. There are two reasons for this form of movement. The torque of the car motorand a more accurate sensing system. The motor can not be run on full because the way the caris designed out of the box, the wheels spin too quickly on the tile floor, losing control and anyability to know where the car will end up going. The delay in the programing also helps keepthe tire speed from reaching this point; however it’s main purpose is to keep the speed of thecar low, since that means that each detection and movement will correspond to each other moreaccurately. If the car is moving too fast then the results it measures will be applied later thenneeded. The car will not be able to follow a light source very accurately and most likely willsimply crash into many walls.

This brings to the last clarification needed, the interrupt crash button. This is the button onthe front of the car which goes high when the bumper hits an object. The program runs quicklyenough that if the car has found a wall is will not continue to drive into it. Upon setting off thecapacitor switch the car returns to the menu and waits for user interaction.

This programing covers what was expected of the car for the project. Future changes willhopefully include the ability to control the car from a USB interface. Instead of Needing toreload a predetermined course for the car to follow a USB could be connected to the PIC andone line instructions could be dumped to drive the car. Such an instruction would be composedof a Direction and a number of drive steps for the car to take. The PIC would read this valueand use an on board library to convert the instructions and drive the car, then wait for thenext directions. This was a hopeful goal for the project that never got completed due to timemanagement and an under appreciation of the time requirements for the other components.

2.2 Programs

Below is one of the programs used to test the driving functions of the car.

;sets portc 0 - 3 as outputs

bsf STATUS RP0 ;page onebcf PORTC,0 ;sets as outputbcf PORTC,1bcf PORTC,2bcf PORTC,3bcf STATUS RP0 ;page zero

;driving test, go three seconds in each direction

seconds equ 0x20

11

count equ 0x21count1 equ 0x23

movlw 3movwf seconds

drivecall forwardcall backwardcall Frightcall Fleftcall Brightcall Bleftreturn

forwardbsf PORTC,1call SecondsWaitbsc PORTC,1return

backwardbsf PORTC,0call SecondsWaitbsc PORTC,0return

Frightmovlw 10movwf PORTCcall SecondsWaitreturn

Fleftmovlw 6 ;whatever high bits control a forward Left pulsemovwf PORTC ;move to output portcall SecondsWaitreturn

Brightmovlw 9 ;whatever high bits control a backward right pulsemovwf PORTC ;move to output portcall SecondsWaitreturn

Bleftmovlw 5 ;whatever high bits control a backward left pulsemovwf PORTC ;move to output portcall SecondsWaitreturn

;wait call takes number entered and waits that many seconds

12

SecondsWaitmovlw 32 ;FOR 200 TIMES 32 MOST OF THE ONE SECOND COUNTmovwf count1

decfsz secondsgoto startreturn

startmovlw 200call Waitdecfsz count1goto startmovlw 50call Waitgoto SecondsWait

Displayed in figure 12 is an example of one of the programs used to drive the car (withoutsensors).

13

Figure 12: Test Drive Program

14

References

[1] E. Sternin. Physics 2P32 (Digital Electronics) Laboratory Manual. Brock University, 1994.

[2] R.E. Simpson. Introductory Electronics for Scientists and Engineers. Allyn and Bacon;Boston, 1987

15