This is an old revision of the document!


group1.jpg

Weekly Reports

Topic selection

Traffic monitoring system

Design

Proof-of-principle

Final Reports

1.Project Objectives

The original objectives of this project were to construct a traffic monitoring system. The system was required to use optics to measure the velocity of both automobiles and pedestrians on a quiet street, count the number of each that pass through the system, and keep a log of the data. Later in the project development, these objectives were altered to include only pedestrians. The system was intended to work under all normal environmental conditions such as rain, snow, and of course, in daylight. The system could not pose any threat to the health and safety of those who entered it. The project was limited to a budget of $200 CDN for all component and construction costs.

2. Final Design

The final design consisted of four subsections that combined to produce a system: the optical system, the modulating circuit, the comparator circuit and the microcontroller system.

2.1 Optical System

In the optical design, infrared light was chosen over visible light because longer wavelengths are less likely to be scattered due to Rayleigh scattering and therefore can be transmitted farther. Infrared light also experiences less ambient interference from the sun because the spectral flux of the sun is smaller in the infrared region[1]. The final design consisted of two collimated infrared LEDs, approximately 1m apart, directed across the hallway, at waist level, to two infrared receivers in the following configuration:

Infrared LEDs with a small emission angle were required for this application to reduce beam divergence. Diverging beams would interfere with the other receivers, and a highly diverging beam may be wider than a person, making the system ineffective. For this reason, an infrared LED (wavelength 935-955 nm) with an emission angle at half power of eight degrees was selected; Digikey model number 1N6264. The typical emission pattern of this LED is shown below.[2]

The wavelength range of the LED was chosen based on the pre-selected receiver; Digikey model TSOP852. As can be seen from the spectral sensitivity graph below[3], the wavelength of the LEDs corresponds to the highest possible receiver sensitivity.

The receiver was selected primarily for its high immunity against ambient light, such as fluorescent lights and, most importantly, sunlight. The receiver uses two lenses with an epoxy cap that acts as an infrared filter, cutting out almost all unwanted light. The two lenses increase sensitivity and receiving angle. While it is desirable for the LEDs to have a very small angular displacement, it is important that the receiver’s receiving angle is not too small, as this will make alignment nearly impossible. At the same time, in this application, if the receiving angle is too large the receiver may pick up signals from neighbouring LEDs, causing errors. The chosen receiver has a fairly large receiving angle of 50 degrees; however small blockades such as pieces of cardboard placed beside the receivers are effective at blocking out unwanted signals from neighbouring LEDs.

The receiver attains its extremely high insensitivity to ambient light by distinguishing between data and disturbance signals according to their carrier frequency, burst length and envelope duty cycle. The TSOP852 model is configured as a bandpass filter centred at 38kHz. However, to further decrease ambient interference, the receiver will not accept any continuous signal, even those at 38kHz. This feature effectively blocks out all ambient light sources, including fluorescent lights and sunlight. In order for the intended signal to be detected as discontinuous, the 38kHz carrier frequency must be contained within an envelope where the signal ‘burst’ of 38kHz signal must be between 10 and 70 cycles long, and for each burst there must be a minimum rest period of 10 cycles. This required the LEDs to be modulated using a 555-timer circuit. The receiver outputs a digital high signal during the rest periods, and a digital low during the ‘burst’ cycle, as shown in the figure below[4].

When the signal is blocked, the receiver detects a very long rest period, and therefore the output of the receiver output is digitally high for the duration that the beam is blocked.

[1]Spekkens, Kristine. “How do we know that sunspots are associated with the Sun's magnetic field?” Ask an Astronomer, http://www.thermalphysics.org/graphics/sun.jpg (accessed September 12, 2008).

[2]1N6264 Datasheet, Fairchild Semiconductor. http://www.fairchildsemi.com/ds/1N/1N6264.pdf. (accessed September 2008).

[3]TSOP852 Datasheet, Vishay Semiconductors, http://www.vishay.com/docs/81764/tsop852.pdf (accessed September 2008).

[4] Ibid.

2.2 Modulating Circuit

2.3 Comparator Circuit

2.4 Microcontroller System

The 20-pin 8-bit PIC16F690 microcontroller was selected for use in the final design. The key features of the PIC for this design were the interrupt-on-change feature in Port A, and the timer1 overflow interrupt, both of which will be described below. The microcontroller also contained an internal clock and inverter, reducing external components and greatly simplifying the microcontroller circuit. This PIC was easier to work with and debug compared to larger PICs considered for the design. The pin and circuit diagrams can be seen below [1].

The final code was designed in accordance with the modified scope, therefore it assumed that the object was a pedestrian, and under this assumption could determine their speed and direction, and log the data into a text file. The program works in the following manner: Within the main function there are two interrupts: ‘timer1interrupt’ and ‘extinterrupt’. An interrupt is a function outside of main that is called only under specific circumstances. ‘Timer1interrupt’ is called whenever timer1 overflows, and ‘extinterrupt’ is called every time there is a falling edge, as seen in Figure 8. Timer1 was programmed to increment once every eight microseconds by setting the internal clock to 4Mhz and the prescaler to 8. A prescaler of eight indicates that the clock will increment once every 32 cycles [2].

Time in increment= [increments per cycle]/ [frequency]

               = [32 increments/cycle] / [4,000,000 cycles/s]
               = 8ms

Timer1 calls an interrupt every time it overflows, which is every 65,535-clock increments for a 16bit timer. This means that timer1interrupt will be called every 524.26ms.

Timer1 interrupt time= [time per increment] x [increments to overflow]

		          = [8ms/increment] x [65,535 increments]
		          = 0.52428s
		          = 524.28ms

Each time ‘timer1interrupt’ is called, an outside integer variable called ‘counter’ is incremented by one, so that each “tick” of ‘counter’ represents 524.26ms. Counter, being an 8-bit integer, will overflow when it reaches a count of 256, which corresponds to 134.21 seconds, or 2.24 minutes.

Counter overflow time= [time per increment] x [increments to overflow]

			=  [0.52428s/increment] x [256increments]
			= 134.22s
			=2.24 minutes

Upon re-examination this was an error made in the code since if the first beam were to be blocked before rollover, and the second after, the direction and speed calculated would be incorrect. However, when the final code was implemented, the rollover appeared to be happening much more often than it was programmed to, closer to every two seconds than every two minutes. The cause of this malfunction is due to an error in either the clock or timer settings, however the exact source within the code is unknown. ‘Extinterrupt’ was programmed to interrupt whenever a falling edge was detected in either of the input pins. Pseudocode for the interrupt follows:

  • if pin A0 is low and a time1 has not been recorded, record and output time1
  • if pin A2 is low, and a time2 has not been recorded, record and output time2
  • if both time1 and time2 have been recorded calculate velocity using 1metre/(time1-time2)
  • reset time1 and time2 to zero and ‘unrecorded’
  • output velocity

A trial version of CCS PCW C Compiler was used to compile the code, and the PICC C Plus program available in the lab was used to program microcontroller. The segmented code can be seen in the figures below.

[1]PIC16F690 Datasheet, Microchip, http://ww1.microchip.com/downloads/en/DeviceDoc/41262E.pdf (accessed September 2008).

[2]Dubuc, Martin. “Programming Tips.” http://mdubuc.freeshell.org/Robotics/Tips.html (accessed October 2008).

3. Proof-of-Principle Tests

3.1 Optical Proof-of-Principle

The first part of the proof of principle test conducted was to detect a strong signal from a 38kHz modulated LED from a distance of 20ft. The tests were conducted in ambient light sources in order to imitate the ambient light of the sun that will be encountered outside. The LED was modulated according to the receiver specifications (38kHz, 70 cycles on, 10 cycles off) using two function generators. The second part of the proof of principle test was to block the signal and ensure that the system could detect the blockage and redetect the signal once the object had been removed from the beam path.

The IR receiver successfully detected a modulated signal from the LEDs from 20ft away, though this distance could be increased if necessary. Optical alignment was a sensitive procedure, which was improved with the addition of collimating lenses. Once aligned, the mechanism worked perfectly without fault, with the receiver able to distinguish between a blocked and unblocked signal for every trial. Tests with multiple oscilloscopes deemed that the response time of the receiver was negligible.

Given that the signal was easily detectable from 20ft in an environment with high levels of ambient light, the proof of principle test results demonstrated that the optical system was feasible, provided that the modulation of light accomplished using function generators was reproducible using the proposed modulation circuits.

3.2 Electronic Proof-of-Principle

4. Final Completed Product Description

5.Final Demonstration of Completion

5.1 Performance

The final product was tested in the lab, under ambient light conditions. The testing demonstrated that the project was successful at determining when a beam was blocked, which beam was blocked, and outputting the time of the block to the PC screen and text file. The project was also successful at implementing the speed calculations only after both beams had been passed in succession. There was, however, a problem with the timer within the microcontroller program. No solution was found to the rollover problem, and therefore a number of the speed calculations were inaccurate, due to the fact that the clock had rolled over in the time between the first beam being blocked and the second beam being blocked.

5.2 Objectives Met

Despite the microcontroller timer problems, many of the objectives of the design were met. The completed project met the following objectives:

  • Able to detect when a beam was blocked.
  • Able to determine which of the two beams was blocked.
  • Able to record the microcontroller timer time when a beam was blocked.
  • Able to use recorded beam blockage times and use them to calculate the speed of the pedestrian.
  • System was fully portable for outdoor use.
  • System was able to attach and function with any PC.
  • System met all safety standards.
  • System stayed within required budget.

5.3 Objectives Not Met

There was only one final design objective not met, and this was the ability of the microcontroller to run a timer without rollover for a long enough period to enable accurate time recordings and therefore output correct speeds. The rest of the microcontroller program functioned as intended. Unfortunately, the accuracy of the time recorded was instrumental to the speed calculation, and to the overall performance of the system.

6. Budget

The allocated budget for the project was $200 CDN, including all component, construction and shipping costs. The following table is a comprehensive list of all components used in the completed product and their individual costs. Components that were used but not ordered are marked by an asterisk(*).

Parts Used

Parts Ordered But Not Used


Personal Tools