re: ensc 440 post mortem for an automated high beam...

December 17, 2012

Dr. Andrew Rawicz

School of Engineering Science

Simon Fraser University

Burnaby, British Columbia

V5A 1S6

Re: ENSC 440 Post Mortem for an Automated High Beam System

Dear Dr. Rawicz,

The attached document describes the post mortem for the Automated High Beam System designed

by Lumos Technologies. We have developed a system that will automatically adjust a driver’s high

beam headlights by detecting nearby vehicles through real-time video processing to prevent the

bright light from blinding other drivers.

This post mortem summarizes our project, budget and timeline. It includes a list of some of

problems we have encountered, and as well as description of each individual reflection and

knowledge we have learned over the past months.

Lumos Technologies consists of five talented and motivated engineering students: Alex Huang,

Claire Liu, Linda Zhao, Sujin Lee, and Victor Mateescu. If you have any questions or concerns about

our proposal, please do not hesitate to contact me by phone at (778) 233-8586 or by e-mail at

[email protected]

Sincerely,

Linda Zhao

Chief Executive Officer

LumosTechnologies

Enclosure: Post Mortem for an Automated High-Beam System

Simon Fraser University 8888 University Dr. Burnaby, BC Canada Email: [email protected]

Post Mortem

Automated High Beam System

Post Mortem for an Automated High Beam System

Contact Person: Linda Zhao

[email protected]

Submitted To: Dr. Andrew Rawicz– ENSC 440

Dr. Steve Whitmore– ENSC 305

School of Engineering Science

Simon Fraser University

Issued Date: December 17, 2012

Linda Zhao

Chief Executive Officer

Sujin Lee

Chief Finance Officer

Victor Mateescu

VP Research & Development

Alex Huang

VP Software

Claire Liu

VP Operation


i

Table of Contents

TABLE OF CONTENTS ............................................................................................................................................... I

LIST OF FIGURES ..................................................................................................................................................... II

LIST OF TABLES ..................................................................................................................................................... III

GLOSSARY ............................................................................................................................................................. IV

1. INTRODUCTION .................................................................................................................................................. 1

2. SYSTEM OVERVIEW ............................................................................................................................................ 2

2.1 HIGH BEAM CIRCUIT OVERVIEW .................................................................................................................................. 3

2.2 SOFTWARE OVERVIEW ............................................................................................................................................... 3

2.3 HARDWARE INTEGRATION .......................................................................................................................................... 4

3. FINANCE ............................................................................................................................................................. 5

4. TIMELINE ........................................................................................................................................................... 7

5. BUSINESS ASPECTS ............................................................................................................................................. 9

5.1 TARGET MARKET ...................................................................................................................................................... 9

5.2 COMPETITORS.......................................................................................................................................................... 9

6. TEAM BREAKDOWN ......................................................................................................................................... 10

7. LESSON LEARNED ............................................................................................................................................. 11

7.1 LINDA ZHAO .......................................................................................................................................................... 11

7.2 SUJIN LEE .............................................................................................................................................................. 12

7.3 ALEX HUANG ......................................................................................................................................................... 13

7.4 VICTOR MATEESCU ................................................................................................................................................. 14

7.5 CLAIRE LIU ............................................................................................................................................................ 15

8. CONCLUSION ................................................................................................................................................... 17


ii

List of Figures

FIGURE 1: SYSTEM OVERVIEW ............................................................................................................................... 2

FIGURE 2: DEVELOPMENT TIMELINE SCHEDULE ..................................................................................................... 7


iii

List of Tables

TABLE 1: EXPECTED DEVELOPMENT COST .............................................................................................................. 5

TABLE 2: ACTUAL DEVELOPMENT COST ................................................................................................................. 6


iv

Glossary

DSP Digital Signal Processing

FPGA Field-Programmable Gate Array

FPS Frames Per Second

PWM Pulse-Width Modulator

USB Universal Serial Bus


1

1. Introduction

In the past 4 months, Lumos Techonolgies researched and developed a product that can potentially save

drivers a great deal of trouble when driving at night. The product is called the Automated High Beam

System. Our system is designed for drivers who find themselves driving on poorly lit roads and highways

or in hazardous areas. Unfortunately, most drivers don’t seem to know the true function of the high

beam system so either they neglect the usage completely or they use them in inappropriate situations.

The latter can create very hazardous situations for other drivers sharing the road.

This post-mortem document is our overall reflection of this project. It outlines some of the deviations

we made from the original plan in our final proof of concept model. This document also goes into details

about our budget, timeline and market analysis. Finally, we conclude by providing our own personal

review of what we have accomplished and parts that can be improved in the future.

The Automated High Beam system consists of a camcorder, an FPGA, and the relay switch circuit. It was

designed to be an easy to install, stand-alone product for essentially any car currently on the road.

Lumos Technologies believe that we have come up with a system that can create a much safer driving

experience for all drivers.


2

2. System Overview

An overview system diagram outlining several components and interconnects between each other for

the Automated High Beam System is shown in Figure 1 below. A more detailed explanation of individual

hardware and software components is presented in the following sections.

Figure 1: System Overview


3

As shown in Figure 1, the Automated High Beam System concept model comprises of two main

components: the software board detecting vehicles and controlling the high beam light intensity, and

the hardware system executing the decision output from the software system.

Decisions to dim or toggle the high beam will be made by the video processing system and will be based

on the estimated distance and the light intensity of the surroundings. The system will revert the high

beams to their original intensity when the high beam range is clear of other vehicles. The driver will have

three options to control high beam headlamps: “on”, “off”, and “auto”. The “on” and “off” states will

remain and function as any traditional headlamp controls. This will grant the driver manual control over

the headlamps, thus completely overriding our system.

When the system is activated in the “auto” state, the video camera will constantly record the front view

of driver’s vehicle and send the information to the processing unit. This information will be analyzed to

decide when to open and close the switch. As soon as an oncoming vehicle is detected to be within

range, the video processor signals the high beam circuit to reduce the intensity of the headlamps. When

the range in front is clear of vehicles, the circuit restores the headlamp intensity.

2.1 High Beam Circuit Overview The hardware circuit development progressed at a steady pace throughout the entire process. The initial

design was drawn out once we understood how car relays, relay drivers, and multifunction switches

function. With the initial circuit done, we began to build the circuit on a breadboard with toggle

switches as relays. After verifying that the logic functioned as expected, we began to purchase

components to be used for the proof of concept. We had to keep in mind that with real car parts, we

would be working with very large currents. As the model was being constructed, we began to notice

small design flaws that we weren’t aware of. The main issue arose after we realized that a regular

resistor would not work in the circuit we designed because of the large currents. We had to research on

the best and most efficient way to dim the high beam headlight. In the end, we decided to use a pulse-

width modulator. We purchased the PWM board and tried it on our circuit before we realized several

features would not work.

One issue was that the negative output is not connected directly to the board’s ground plain. This will

cause the high beam headlight to stay in the dimmed mode. The other issue was our user high beam

override didn’t work. Eventually we resolved this issue, but we realized how different the design had to

be when large currents are involved.

2.2 Software Overview Designing the software component of the project was an ongoing process of research and

experimentation to constantly improve performance. After reading through various journal papers on

the topic, it was decided that a relatively simple approach had to be taken. Each frame of the input


4

video would be individually operated on and vehicles would be detected based on their headlamps or

tail lights. A dynamic thresholding procedure is applied to each frame to identify the bright objects. Pairs

of bright objects are grouped and matched as vehicle lights and the horizontal distance between their

outside edges determines the width of the car. The algorithm uses the width of a car to determine its

distance from the user; a car`s apparent width is larger the closer it is to the camera. Furthermore, an

override feature is included that analyzes the video to determine if the surroundings are too bright for

high beam use. The vehicle detection software will only execute if high beams are found to be

appropriate for the particular situation; otherwise, the software will forego any further video processing

and keep the high beams off.

Overall, we are pleased with the performance and accuracy of our vehicle detection system. However,

we found that it is very difficult to detect cars at distances of upwards of 150m away. This is a difficult

aspect of vehicle detection and is apparent throughout the various available methods we surveyed. If a

larger timeframe were given, it may have been possible to include motion information of other vehicles

in the detection process. Although based on our research, temporal, motion-based algorithms are very

complex and computationally expensive.

2.3 Hardware Integration

The FPGA was meant to be a link between the video camcorder, the software, and the high beam

circuitry. At first glance, we expected this portion of the project to be the least problematic. An Altera

DE2-70 board would be used to take live analog video, buffer the frames into memory at 30 FPS. The

Nios II processor on the board would then run the software algorithm on each frame and output a

decision to the high beam circuitry.

We first encountered problems when we found we didn’t have access to the lab containing the

necessary software to program the boards. Furthermore, we didn’t have licenses to this software or

account logins for the machines in the lab, which significantly slowed progress down. After going

through the bureaucratic process and obtaining these things, we began the surprisingly painstaking

process of programming the board. Ultimately, the board was far too slow to accomplish our goals. The

only alternative with this board would’ve been a hardware implementation of our software algorithm,

which was completely unfeasible in the time given. If we were to do things all over again, we would’ve

tried using a PC instead of an FPGA. The frame-grabber could be used to stream live video from the

camera onto the PC using a USB port. Some sort of GPIO connector or microcontroller would output the

3 -bit decision to the high beam circuitry after the software on the PC processes the video.


5

3. Finance

During the funding presentation to the ESSEF in September, we provided the following financial

breakdown for our $900 budget, summarized in Table 1 below:

Table 1: Expected Development Cost

Components Price

Development Board $ 200

Car Camcorder $ 150

2 Headlight Bulbs $ 60

Battery $ 150

Vehicle Accessories $ 100

Other Components (wires etc.) $ 100

20% Contingency Fund $ 152

TOTAL $ 912


6

The actual cost of our project was around $600, which came in under budget. The budget detail is

shown in Table 2. We were fortunate to borrow an FPGA board from one of the professors and most of

the components were purchased from junk yard, which reduced expenditures considerably. The

camcorder was the only expensive product that we purchased for this project.

Table 2: Actual Development Cost

Components Price

Development Board Free

Video camera $ 315

2 Headlight Bulbs $ 23

Battery $ 17

Vehicle Accessories $ 238

Other Components (wires etc.) n/a

20% Contingency Fund n/a

TOTAL $ 593


7

4. Timeline

The following timeline in Figure 2 illustrates the progress of our project over the past months:

Figure 2: Development Timeline Schedule

A Gantt chart in Figure 2 illustrates the comparison between our predicted timeline indicated in blue

and our actual timeline indicated in red.

As shown in Figure 2, all the deadlines for the documentations, such as proposal, functional and design

specification, and process report were met. A 3-day extension was used for the design specification,

which caused a delay from the expected due date.


8

Aside from the documentation, some unexpected delays occurred throughout the schedule. We found it

was necessary to constantly update our system for better accuracy and functionality; hence research

was an ongoing process for almost the entire duration of the project. Furthermore, integration was

significantly delayed because of problems with lab access and software licenses that were previously

mentioned. Finally, our original predicted start time for assembling the modules proved to be unrealistic;

more research had to be done before implementation could take place.


9

5. Business Aspects

5.1 Target Market

The Automated High Beam System is designed for any driver, especially for those who frequently drive

during the night, such as truck drivers. It is also ideal for people who live in sparsely lit, rural areas. Our

product can be sold to local auto shop owners, who can advertise and re-sell the product to their own

customers.

5.2 Competitors

There are many similar systems or products out in the market. The luxury car brand, such as Mercedes-

Benz and BMW, has this kind of built-in package for their customers. The cost for their high beam

system is $1000.00, which is expensive and only available for their vehicles as a built-in feature. One of

complains from their customers is that the user requires to drive at the speed of 55 km/hour to activate

the system fully. Our automated high beam system does not have this kind of speed requirement.

Furthermore, It is a stand-alone product and can be installed on any vehicle at lower cost.


10

6. Team Breakdown

Lumos Technology consists of five highly skilled members which specialized in different areas. During

the whole project, we assigned tasks according to each specialty. A brief team breakdown is given as

follows:

Linda Zhao (CEO)

Hardware system design research

Meeting management

Sujin Lee (CFO)


Hardware design and development

Alex Huang (VP Software)

Altera development board

Video quality control

Vehicle detection research

Victor Mateescu (VP Research and Development)

Vehicle detection research

Software design and implementation

Claire Liu (VP Operation)


Altera development board

Overall progress management

Financing


11

7. Lesson Learned

We learned many lessons over the four months working on our project. We realized that research needs

to be performed as early as possible in order to compare and search different ways to approach our goal.

We also learned about the importance of time management – working under pressure in a very tight

schedule in order to get everything done properly.

7.1 Linda Zhao

This was a very interesting project. I’m at the end of my degree and have taken many courses that

involved team work and spending hours on end on something that just did not work. Yet, Ensc 440/305

put us in a completely different working mode. We had to decide on what our project will do without

knowing much about how many of the components available to us functioned. We had to decide on

features of the product before we even knew what approach was feasible. This project’s development

process made me realize the importance of project management, communication skills, and overall

professionalism. This was such a key factor in the success of any project that I can’t believe we weren’t

taught this skill much early on in our educational career.

As Lumos Technologies’ CEO, I was in charge of organizing meetings by sending out agendas and taking

minutes during the meeting. Although there were times when the team did not see the importance of

these regular meetings, I felt like it was the best time for everyone to have an idea of what their other

teammates are working on and have a better idea of the overall progress of the project. I was also

heavily involved with the hardware research and development portion of this project. I had a lot of

experience testing and debugging hardware circuitry through my past coop terms and current job and I

think those experiences helped move the project along more smoothly. From this project, I have a

better idea of how higher power circuits had to be designed very differently from the breadboard

circuits that we worked with in our previous lab courses. I also learned to consider design constraints

such as using car relays to reduce the use of high current wiring only for battery to the headlights. All

other signals can be transmitted through much thinner wires.

If time was turned back to September and I had to redo this project again, I would definitely change the

way we planned this project and the overall organization. I felt that the technical portion of this project

was interesting and required a lot of research and digging around, but if this task was given to anyone at

the end of their engineering degree, many should have the skills to complete the technical portion.


12

What I find the most delicate and challenging is the human aspect of the project. Communication is a

key factor and I realize that emails (especially angry emails) can sometimes be counterproductive even

though it’s more convenient than having a meeting in person. Another change I would make would have

been to set more detailed deadlines on whatever part we are working on. Basing the progress of the

project on documentation deadlines was probably way too lenient for us. Looking back at our own

timeline, we could have completed many of our milestones much earlier than we actually did.

Overall, this was an awesome project to work on. Although we didn’t have a fully integrated product, we

did have a lot of interesting moments together every time we met up in Lab 1. (We said we could have

always defaulted back to our automated curtain system, would have been done in a month, but thank

goodness we didn’t). I think we picked a very interesting project and we all learned a great deal from

doing so.

7.2 Sujin Lee

ENSC 305 and ENSC 440 were the most challenging and interesting courses I have taken at SFU. These

two courses have provided me with great teamwork experiences with amazingly talented and

passionate team members. Furthermore, the research and development involved taught me many

different aspects with newly introduced components that cannot be learnt from previous academic

courses.

My role at Lumos Technology was the Chief Financial Officer. Although the large portion of my effort

went toward development of the prototype hardware, I had been monitoring the budget to spend prior

to any acquisition of items. Just as planned, all the components we expected to buy were purchased

under the budget line.

As part of Lumos Technology, I undertook the task of designing and implementing the prototype

hardware. From the beginning of the course, a lot of research had to be done prior to taking any action

due to lack of knowledge on high-current circuitry. Relays were fairly new to me, though I learned that it

had extremely interesting features, which turned out to be one of the most essential components in our

prototype hardware. Another most challenging obstacle I faced was finding a replacement for a variable

resistor for 50% light intensity dimming on a high current circuit branch. This obstacle has taught me

that a rheostat is bulky and power consuming resistor to handle 10 amps of current, however, a pulse

width modulation (PWM) can be used instead with minimal power loss. At the moment when the pre-

assembled PWM was bought, I expected the hardware part to be done in an hour with ease.

Nevertheless, the PWM circuit required two grounds, from the battery and the headlight, to be

separated. To overcome, brainstorming with partners was needed to come up with a solution of

equipping 2 extra to switch between the grounds and for the high beam to override the PWM circuit.


13

Throughout the time my partners and I spent on the project, we have faced various difficulties where it

could eventually be solved through brainstorming and researching together. I appreciate the professors

of ENSC 305/440 for offering such valuable courses, but also thank to the members of Lumos

Technology for giving me an unforgettable experiences that would positively affect on my future careers.

7.3 Alex Huang

As VP software at Lumos Technology, I was responsible for the software development and the system

integration. Throughout the first half of the semester, I had worked closely with Victor on researching

and designing the algorithms for vehicle detection. Since the quality of the videos is the most significant

factor to our software algorithm, I have spent a lot of time setting up and filming the test sequences at

various conditions. However, there are just way too many possibilities to consider, for example, the

winding of the road, weather, and unusual light sources. Eventually we decided to use simple cases,

such as a straight road with minimal environment lighting.

One of the biggest constraints to our project was getting the access to the lab. After losing about two

weeks waiting for the access to lab1a and the license for Altera programs, Claire, Victor and I began

working on the FPGA board to integrate our hardware and software together. Although we have taken a

course related to another version of this board, we still had difficulty knowing where to even begin.

Fortunately, a professor and a graduate student were willing to give us a hand and some useful guides. A

very big portion of our time was invested into developing the bridging for our system. The development

progress was moving forward only except that later we found out the limitation of the board was

stopping us. A simple task to buffer the frame into the memory without even applying our software

algorithm takes way too long than we expected. This part of our project was very time consuming and

difficult. It can only be described as another 440 project alone by itself. During the stage of pitching

ideas, we could have chosen a much easier project to work on. Instead, I believe that a more interesting

and challenging project can force us to learn more

Overall, I felt that the greatest challenge was fighting for time. I was enrolled in three other upper level

project courses and things became really busy especially near the end of the semester. However, I still

gave everything I got and managed to work on this project as my first priority. In the past four months,

this project gave me more experience in programming with C++, MATLAB, and FPGA board, knowing

how to work under limited time and pressure, as well as working in a team. I admit that it is a huge

disappointment to not be able to finalize our systems as one. It is a lot more depressing than handing in

an incomplete assignment. If only more time were given, our product would have been much more

complete. However, the amount of time and work we contributed into this project and the result has

already approved our capabilities.

ENSC 440 Capstone project is definitely one of the most valuable courses in my engineering degree at

SFU. It has been a pleasure working with my teammates at Lumos Technology in the past four months. I


14

would like to thank them for all the effort and energy they put into this project making it a reality rather

than an idea.

7.4 Victor Mateescu

ENSC 440 is like shopping for wallpapers and home décor at a third rate retailer while blindfolded with

your hands tied behind your back after browsing through a catalogue containing only word descriptions

of said products. You read through the descriptions as best you can and attempt to visualize what it will

all look like. But in the end, you just have to take a leap of faith. You fork over the cash and get

everything delivered into your home and then painstakingly re-arrange everything over and over to

mask the inevitable clash of colors and mismatches made by your bad decisions.

During the course of this project, I was primarily involved in designing and implementing the software

system. Throughout the semester, I was continuing the work I had done during my NSERC co-op in the

field of image and video processing under the supervision of Dr. Ivan Bajić. As such, I already had a fair

amount of experience in this field, and I had also grown accustomed to reading research papers for

relevant information. However, I had no knowledge on vehicle detection in video. By perusing various

journal papers, I obtained a good understanding of the numerous methods available for vehicle

detection and could begin prototyping through MATLAB.

After doing all my research, I came to the conclusion that a truly effective vehicle detection system

should have both, spatial and temporal components. Spatial refers to content in a single frame, whereas

temporal refers to content along multiple frames (i.e. in the time domain). Unfortunately, algorithms

featuring significant temporal components, although robust and accurate, were widely determined to

be very complex and slow-performing. Due to time constraints and the pressure of delivering a working

product, I decided to play it safe and form the basis of the system from spatial analysis. In retrospect,

this proved to be a wise decision. Developing and debugging the system proved to be difficult and time-

consuming and in the end, I was quite satisfied with its performance. Ultimately, there was no single

algorithm to accomplish our goals. Bits and pieces from various different methods were selected along

with our own original ideas in order to create the software system.

The largest disappointment in this project came from the FPGA component, which was meant to link the

software to the actual high beam circuitry. We gave some serious thought to the method of linking the

two, but finally decided on a DE2-70 FPGA with the advice of a professor and a graduate student who

had previously done a project on object recognition. It seemed like a good choice: Multiple codecs

wouldn’t need to be developed and synchronized since the video would be taken in analog form, no

operating systems were necessary, and the GPIO output pins would be readily available and easily

operated on by the processor. Little did we know, this graduate student’s project was implemented

almost entirely in hardware using pre-designed components from Altera. Re-implementing our software

system entirely in hardware is an absolutely immense task. It can hardly be described as an ENSC 440


15

project in itself since a four month semester wouldn’t even come close to the time necessary for such an

undertaking. I decided to give a helping hand to the teammates who were responsible for getting this

component up and running, but our efforts proved to be futile. Our leap of faith left us with bright

orange walls in our living room although the color was described as “sandy dune”.

Overall, I can’t blame any team members for any of the project’s shortcomings. We could easily have

chosen a very simple project, but instead picked something more challenging. As far as my contributions

go, I feel fairly satisfied that I helped accomplish one of our primary goals: develop a reasonably

accurate system of detecting vehicles in video that is capable of running in real-time. This project gave

me more experience with vehicle detection, programming in C++/MATLAB, and working in a team.

Although it would be nice to have a fully integrated final product, I feel that the large amount of work

and effort we put in along the way is of greater importance.

7.5 Claire Liu

The past four months have been a memorable and challenging experience in my university life. As VP

Operation at Lumos Technology, I was responsible for planning, organizing, and directing the activities

happened throughout the development progress, such as coordinating work flow and managing

documentations. I established deadlines and procedures for documentation to avoid procrastination

and ensured everyone was responsible for their tasks.

Aside from management, I worked with Alex to film several sample videos (special thanks to our

significant others who were there to help us). This was when I realized the project was way more

complicated than we expected. Originally, we wanted to use a car camcorder to do recording since it is

more affordable and smaller in size. After filming sample videos with car camcorder and high-definition

camcorder, I realized the quality and settings of a camcorder have significant impact on our software

performance. There is also some limitation on how far the camcorder can capture, especially at nights.

The surrounding environment also played a huge influence that can affect the level of complexity for our

project. Hence, regarding to the above concerns, we set up a simple situation and ended up buying a

standard-definition camcorder.

At the beginning of the project, I worked on hardware development research. The research was a bit

difficult since I had no knowledge or any experience about cars. After I talked to one of the professors

about our project and he told me about automobile relay and relay driver, everything started making

more sense and getting the hardware development into a proper shape. It was my first time to

understand what relay is and learn how relay works in a vehicle. When the hardware team had some

basic idea on how the circuit diagram for the headlight would be like, I switched to software

development team and worked on the FPGA development board with Alex and Victor. We had several

difficulties while working on the FPGA board because there are some limitations that the board can

offer. It took us several days to learn more about this FPGA board and to understand how the video


16

system works on the FPGA. The waiting time for lab access and software program licensing was really

intolerant as it took two weeks, which delayed the whole progress by one week. I was looking forward

to assist Victor to implement MATLAB code into C code until we realized there was not too much time

left to finish completely. It was a disappointment to a person with great passion in C programming.

I sincerely appreciate everyone in Lumos Technology, and am really glad that I had this chance to work

with them. I also appreciate everyone, including professors and teaching assistants, who helped us along

the road. It was a tough journey but we have tried and succeed in what we can provide.


17

8. Conclusion

Over the last 4 months, our engineers at Lumos Technologies have worked on developing a proof-of-

concept model of the Automated High Beam System. The biggest issue we had with this project was

with the DE2-70 FPGA development board. We had some technical difficulty with special lab access and

licensing that greatly delayed our work on the development board. We also underestimated the

difficulty of working with our FPGA and had spent a great deal of time just learning how to use it. In

order to produce a fully functioning prototype using our current setup, we would have to spend a great

deal of time implementing our hardware entirely in hardware.

An alternative for our design, which would further lead to a marketable product, would be to replace

the FPGA with a fast microcontroller designed specifically for DSP (or for the prototype, simply using a

PC would suffice). This would reduce the size of the final product and would allow us to use our current

software algorithm provided that it is further optimized. With regards to the installation inside the car,

only the camera secured to the windshield or dashboard, the automatic switch, and the system status

LED should be visible to the user. Subsequently, we would also have to learn more about the inner

workings of the headlight system in an array of car models to develop a circuit that can be installed into

any car.

In the end, the Automated High Beam System was built under the original budget and Lumos

Technologies was able to complete a great deal of research and development in this area within the

given time frame.

re: ensc 440 post mortem for an automated high beam...

Documents