Single sentence summary
A programmable laser light show that allows the user to specify the
pattern displayed via three motor speeds and the length of time that this
pattern is held.
For this project, we designed a system to guide a laser beam through
an array of three rotating mirrors and then project it onto a screen where
it is able to “draw” a range of different patterns. Allowing
the mirrors to rotate at variable speeds creates the different patterns.
These variable speeds of the motors are produced via pulse width modulation
(PWM) control from the MCU. Each motor has its own dedicated pulse width
modulator, allowing each motor to rotate at a different speed.
Our project can be broken down into a few major constituent components.
These components include the laser tube and high voltage power supply,
the mirror assembly (three circular mirrors and motors), the Atmega32(L)
(and STK-500), and finally a custom made board which contains the PWM
support circuitry. All of these components are mounted on a piece of pegboard
making the unit easily portable. Additionally, a user interface for the
motors has been implemented that uses HyperTerminal. Each one of these
components is discussed in detail below.
We decided on this project after discussing the types of potential projects we could complete and jointly decided that since we never dealt with any type of motor control in lab that the final project was a good opportunity to do so. Additionally, after a trip last summer to Darien Lake amusement park where we watched a professional laser light show, we both had wondered how exactly this type of presentation was done. After a bit of research, we concluded that for the time allotted for this project, this tri-mirror setup was the most feasible.
Rationale and sources of your project idea
To develop the idea of this project, we first built the system using hardware only. The system was the same as in the final design with the exception that all motor control was done with potentiometers instead of PWM control. This allowed us to experiments with different numbers of mirrors, different ranges of speeds and different arrangements of the mirrors themselves. From this experimentation, we were able to make many decisions regarding the way the final project should be constructed. Firstly, we decided on three motors/mirrors for a number of different reasons, the main reason being that we could maximize the number of patterns available for display by maximizing the number of mirrors. The Atmega32(L) contains four pulse width modulators from three timer sources. One of these timers must be dedicated to program control, this leaves a maximum of three PWM channels from a single chip. Hence, we decided that three mirrors and motors was the proper choice.
We visualized this project in three parts. First, we had to successfully implement control of an individual light pattern. In our user interface, we added an option to make a light pattern. The user can enter a speed for each of the three motors to specify a light pattern. This pattern will be held until the user decided to quit the program. This was the first logical component of our project.
Lastly, we took these four arrays and enabled the user to store them in EEPROM. In this manner, a light show can be restored, even if the system is powered down. In the user interface, there are options that allow a user to save and restore a light show.
One of the tradeoffs that we needed to weigh during the design of this project was the choice of using all hardware PWMs or needing to code a single PWM in software while the other two were done in hardware, as our original proposal suggested. For instance, a slightly less expensive chip could have been used, such as the mega163, but then only two hardware PWMs would have been available since timer0 would have still needed to be used as the task timer. While writing a software PWM itself is not complicated (it only requires the manual toggling of a single output port bit), calibrating the modulation frequency to coincide with the frequency of the other two hardware PWMs may have proven to be a tricky procedure. Another tradeoff that we needed to consider was how much EEPROM would be available for on-chip laser show storage. The mega163 had 512 bytes while the mega32 has 1024 bytes which for the storage of our four arrays (three speed arrays and one timing array) which makes a significant difference. With these two metrics in mind, we felt that the Atmega32(L) was the proper choice of MCU.
As mentioned earlier, the hardware dimension of our project is composed of three main parts: a laser tube and high voltage power supply, a spinning motor/mirror assembly, and the support circuitry for the PWM motor control. Each one of these parts is discussed in detail below.
I) Laser Tube and High Voltage Power Supply
II) Mirror Assembly
Figure 1: Motor Assembly
The motors are 6V, continuous DC motors that run from an external 6V battery pack comprised of 4 series connect C-cell batteries. The mirrors are flat and circular in shape measuring 1 1/4” in diameter and 1/8” in thickness. Mounting the mirrors to the motor shafts was done with a specialized epoxy that allows for high-speed rotation of the mirrors. The motors are attached to the pegboard with small bolts to prevent any rotation of the motor body itself. The combined laser and spinning mirror assembly is pictured below in figure 2:
Figure 2: Laser and Spinning Mirror Hardware Assembly
Also pictured in the diagram above is the project is the projection screen. This screen was made from two custom made L-brackets, a length of threaded steel rod, and some spare window shade vinyl. The screen can be removed if the user wants to display the show on a bare wall.
III) Pulse Width Modulation
General Discussion of Concept
Motor control via PWM signals is one of variety of standard ways in
which a motor’s speed can be precisely controlled. The idea of PWM
control of a motor is analogous in a way to a light switch/light bulb
system. If over the course of a unit of time the light switch is off for
the entire time, then the bulb will be dark. Conversely, if the light
switch is on for the entire time, then the bulb will be as bright as possible.
However, if one was to rapidly flip the switch (on, off, on, off, etc.),
depending on what percentage of the cycle the switch was on (the duty
cycle) the light could be made to shine at a range of intensities between
100% dark and 100% bright.
The top most signal represents a slow speed because 90% of the cycle
the motor is off. The middle signal represents half speed because the
on and off times are balanced (50% duty cycle). Finally the bottom signal
represents a high speed because 90% of the cycle the motor is on. Although
the signals are fluctuating rapidly, the behavior seen from the motor
is very smooth because the inertia of the rotating shaft provides a natural
smoothing effect (like the flywheel in a car). However, additional smoothing
of the signal can be added in the support circuitry, discussed later.
Figure 4: PWM Support Circuitry
The rapidly varying PWM lines allow for smoothly varying motor speeds, which in turn allow for crisp laser images. Note that the protection diodes are needed because the changing magnetic fields in the inductive load will cause sharp spikes that would blow out the motors without these diodes. The VCC rail is powered by a 6V battery pack (4 C-cells). This is the final hardware component of our design project. A picture of the complete hardware system is shown below.
Using HyperTerminal, we constructed a user interface that supports two modes. Mode 1 will allow the user to set the duty cycles of each motor individually. Once these duty cycles are set, they will be held until the user changes them. Mode 2 is a light show programmer. This mode allows the user to specify a series of motor speeds (that determine a light pattern) that is held for a user-determined amount of time. A more detailed description of each mode follows.
Mode 1: Independent Duty Cycle Control
In this mode the user is prompted to select one of the three motors and set its speed. The user sets the speed by entering a number between 0 (off) and 255 (100% duty cycle). This range of numbers is a result of us choosing to use 8-bit PWM. Note that due to loads on the motor shafts (mostly weight of the mirror) we are unable to utilize the full range of speeds. This is discussed later on. The user must set one speed at a time, but can specify different speeds for each motor. The speeds are held until the user quits out to the main menu. The picture below shows what the user-interface menu looks like.
Mode 2: Laser Show Programmer
This mode allows the user to setup a laser show. The user has several options in this mode. The first option is to program a new laser show using the “program show” option. The user will be prompted for a set of three duty cycles, one for each motor. This will specify a particular laser pattern. The user will also be asked for a length of time (in seconds) that this pattern will be held. Each of the four values will be stored in separate arrays. Once this input set is complete, the user will be asked whether they are done entering data. If not, then they will be prompted to enter in four new values for the next pattern. If data entry is complete, they return to the programming menu. The user now has the options of either running the show or saving to EEPROM to be used at a later session. If the user selects “save show”, the arrays will be stored in EEPROM, so that at power down, the show will be saved. When the system is turned back on, the user is able to select the “load show” command and restore the saved show. Once a show is entered or loaded back from memory, the user may select the “start show” command. This option immediately spins up the motors to the speeds specified in the first data set. Each successive pattern is displayed and held for the specified amount time until the final data set, after which the motors are shut off. Below, menu 2 is shown, along with the information the user is prompted for while programming a show.
The purpose of this section is to explain, in some detail, the workings of our code. Very low-level detail will not be discussed here, but can be examined in our commented code in Appendix A. This section will provide the reader with enough detail to be able to follow the commented code.
The other component that is run from main is our control flow function.
This function is really the heart of the user interface. From here, user
input is received and decoded. Based upon several state variables and
the user input, the appropriate actions are determined.
A function called get_input is used to assign commands. USCRA bit 7 is
examined first. If it is high, then there is a character waiting to be
processed. The function then checks if the character is a carriage return.
If it isn’t, then it is added to a character input array. If the
entered command is a carriage return, then the character array is concatenated
and type cast into a character. This character is stored in the ‘command’
variable. In addition, a variable ‘process’ is set high. This
will be used as an indicator that there is a valid command ready to be
processed by the control flow function.
Based upon which menu is currently displayed, the current command, and
some other state variables, an appropriate action is taken. For example,
process is frequently used to ensure that menus are only displayed once,
and not endlessly repeated onscreen. ‘enter_motsp’ is used
during the individual PWM control mode, and ensures that the user is prompted
for the appropriate information. ‘Programshow’ is used to
determine when the user is entering data to be stored in the laser show
arrays. It also helps ensure that the user is prompted for the appropriate
Hardware/Software Implementation Problems
As with all major design projects, we encountered several difficult
and unexpected problems. First, after we successfully got the PWM working,
we noticed that we could not get the full range of speeds (0-255) with
the motor. When the motors are first started up, they need a speed of
at least 65 to get the motor shaft to continually turn. Once the motor
is started, speeds can be dropped lower than 65, but usually not much
below 35. Although we were initially concerned with this performance aspect,
after testing we determined that this was not actually a problem. At such
low speeds, the motors are not even able to move the beam fast enough
so that the persistence of vision takes effect. At these low speeds, the
laser just appears as a moving dot, rather than a coherent pattern. We
are still able to get a full range of patterns even without the full range
We also encountered some problems with ground. As we tested our design, we noticed that sometimes the motors would not fully shut off at zero duty cycle and power down, or that tapping the shaft could restart them. After some investigation, we determined that there was about a 2-volt peak-to-peak sine wave present at ground. We ensured that both the evaluation board’s ground was common with the battery-pack’s ground. This did not have any effect. After further experimentation, we found that the only way to rid ground of this unwanted signal is to make both grounds common, and connect them to earth ground (through the scope or wall socket).
Speed of execution
Our biggest concern was ensuring that any command entered by the user was processed correctly. We made sure that we used non-blocking code for this input. When the user enters a command in HyperTerminal and hits carriage return, a flag called “process” is set high. The software uses this flag to indicate that there is a command ready to be processed. A long series of if-else and case statements determines and executes the appropriate action. We were somewhat concerned that this conditional chain may be so long that some user input would be missed. However, after some extensive testing we found that our software always accurately processes user input. Our other concern was that the PWM techniques that we used would provide a suitable level of sensitivity to the motors. We wanted to ensure that a full range of speeds was possible, thus allowing for the greatest variety of laser light patterns. We accomplished this mainly empirically, using 8-bit modulation and then checking the motor operation to ensure that a wide variety of speeds were possible.
Accuracy, although important, was not a major consideration in our design. We wanted to make sure that the patterns in the show mode could be displayed in some length of seconds. We used a counter to keep track of the number of seconds that has elapsed. Once this counter equals the desired display length for the pattern, the second counter is reset and the next pattern is displayed. If we are off by some small number of milliseconds, the error will not really be noticeable to the user, nor will it affect the overall appearance of the light show. The only other accuracy consideration was to ensure that all commands entered in HyperTerminal were properly received. The methods we used to ensure this have been discussed previously in the speed section.
There are several safety concerns involved in this project. The first
is that project involves a laser so basic laser safety concerns need to
be addressed. While the beam is certainly not high power, it is still
dangerous if pointed directly into one’s eye. Most of the time the
beam is simply directed through the mirror array and onto the screen and
posses no real threat. However, during alignment of the mirrors the laser
must be on and the beam could accidentally strike someone in the eye.
Care must be taken, especially during alignment, to make sure that the
beam does not become a hazard.
Interference with Other People's Designs
We didn’t believe that our project caused any noticeable interference, since we ran it for a couple days without causing any problems for our surrounding neighbors. However on one of the last days, we did encounter one problem. One group was doing a guitar tuner of some kind, and noticed that our project created some noise that was detectable on his system. Apparently, the PWM signals that came off the MCU caused this problem. We were a little surprised by this, as we thought that our laser power supply would be the likely culprit. However, the interference was not generated when the laser supply was on. We guess that the wires that connect the output pins on the evaluation board to our circuitry are causing this noise. Fortunately, the interference was not so severe as to create a serious problem for our classmate.
Usability by You and Other People
A major component of our project was to create a user interface that would be robust and easily understood. We believe that practically anyone could use our design. The most difficult aspect of our design would be the setup, which anyone who has taken 476 could do. Setup merely involves setting up HyperTerminal. Once the project is set up, anyone could use the interface. The hardware is ready to use, so the only thing the user must do is turn on the power supply. From there, it is a simple matter of selecting the desired option, and inputting a motor speed. We thought about making the project ore portable by using an LCD to display the interface, however we decided against it because we thought it would be significantly less user-friendly.
We were able to meet all of our major design goals, as set forth in
our project proposal. The secondary goal, sound, was not implemented due
to lack of time. However, we are extremely pleased with the way that our
project turned out. Our resultant product is a great demonstration of
the Atmel32’s capabilities with motor control and serial communication.
Our project utilized most of the chip’s resources including all
three timers, the UART, and EEPROM storage. Further, we are very pleased
that the project is fun to operate. It is very entertaining to explore
the different patterns possible, and then program in a show that demonstrates
some very interesting light patterns. If we had to implement this project
again, we would do several things differently. First, we would try and
make our code somewhat more organized. Although entirely functional, and
generally readable, we feel that had we done a little more work on paper,
the code could be more easily understood. There are not too many intellectual
property considerations with our project. We used readily available hardware,
including an argon laser, power supply, transistors, motors, and mirrors.
We did not have to sign any non-disclosure agreements to get any of this
hardware. Our code is of our own design, and not part of the public domain.
Our project is an interesting demonstration of how a simple laser light
show may be programmed. We do not feel that there are very many patent
possibilities because most commercial systems are far more advanced and
capable of many more designs. Smaller systems are marketed that are similar
to ours except for the fact that they use glavometers in place of motors
and are often able to accept RCA inputs so that the pattern changes with
the music. However, none of these systems to our knowledge allow the user
to preprogram the unit to display a certain series of patterns. This idea
might be worked in to allow some sort of patent potential.
to accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment
As stated before in this report, all major safety hazards have been assessed and avoided as much as was possible given the time span of this project. The high voltage supply was sealed up and labeled with a “high voltage” sticker so that observers would understand the threat. The entire unit was mounted securely to a board, minimizing the risk that someone could pick up the laser tube and cause injury to themselves or others with the beam. Also, despite the speed of the motors, the edges of the mirrors have been smoothed so that no sharp edges could cut a user who was trying to align the unit during operation. Point five of the code states:
to improve the understanding of technology, its appropriate application, and potential consequences
We have already mentioned how happy we were that this project placed a slightly different “spin” on the idea of the laser show in an application that is a bit different than standard laser shows. Large-scale laser shows tend to utilize devices that can accurately and quickly move the beam in both the x- and y- planes, hence being able to make any 2-D figure. Ours, while more simplistic, is also much cheaper and in some ways more elegant in its operation. The sensitivity of the patterns to the changing motor speeds is quite interesting and allows for a wide range of available patterns if the user is willing to experiment enough. We feel that this is certainly an appropriate application of the popular laser technology. Point three of the code states:
to be honest and realistic in stating claims or estimates based on available data
From the onset of this project we were honest as to our own goals and the ability of the system that we were creating. We were realistic with the budget that this project would run us and we made it so that the project worked as specified given the $25 limit. We referenced all parts of the design that we did not explicitly develop and were honest about the portions of the project that could not be completed due to lack of time. Finally, we were honest when discussing the limited potential of patenting this device because of it similarity (though not exactly) to some existing laser projection devices. Point seven of the code states:
to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others
Our project without question complies with this portion of the code. As stated before, the high voltage supply was constructed from a design that was not ours and that design was certainly referenced in this report. Also, during the completion of this project we certainly stumbled upon many errors, of which some of the larger ones were discussed previously. For example, the problem with our circuit concerning the method of grounding was eventually identified (after hours of searching for it) and corrected. Also, Professor Land pointed out a few places on our power supply that were potentially dangerous and asked us to cover them with electrical tape, which we did immediately. Finally, throughout the design of this project we asked the TAs, Professor Land, as well as some of the other students for their input on the project and certainly took their input to heart. For instance our TA, Derek, certainly assisted us in choosing the proper switching transistors for the PWM control circuitry. Finally, point ten of the code states:
to assist colleagues and co-workers in their professional development and to support them in following this code of ethics
We feel that this point has a bit of dual meaning in the context of
ECE 476. The “colleagues and co-workers” applies both to the
partners working on the project together as well as the other groups working
around us in the lab. As a group, we tried our best to help out any groups
that asked us for advice or input because we expected to receive the same
sort of treatment when we asked them. Additionally, by working closely
together we were able to keep each other’s work at high standards
and make sure limited mistakes were made that could possibly violate the
code of ethics. For instance, this close working unit was the reason the
no limited safety issues remained when the project was complete. Also,
by helping each other out we were able to expedite the development process
and actually complete most of the goals that we set for ourselves.
char current_char; //most recently entered character
//Variables used for power-down storage of data
//timer 0 overflow ISR
//Decrement time if not zero
void display_menu0(void) //display menu 0
void display_menu1(void) //display menu 1
void display_menu2(void) //display menu 2
void control_flow(void) //master control function
if((menu_page==0) & process) //display menu
0 on reset
if((menu_page==0) & (command==1)) //enter
individual motor speed setting mode
//initilize motor speeds to zero
//make PWM ports outputs for motor control
//setup timer2: single PWM
//initialize state variables and flags
//setup for LEDs
void start_show(void) //run current show
Appendix II: Schematics
Schematic A: High Voltage Power Supply for Laser Tube
Schematic B: Motor Wiring Diagram with PWM Control
Appendix III: Cost details
**We spoke to a hobby electronics store
in Rochester called Allied-Action Limited, whom we have dealt with in
the past. We explained the type of laser tube we had and that we needed
to construct a supply to power it. We also explained that this project
was for a final engineering project at Cornell and that we were under
a strict budget. He agreed to sell us the flyback transformer as well
as the some of the other components not easily found in a common lab for
a set price of $12.50.
Appendix IV: Project Tasks Carried out by each Team Member
For the grand majority of this project we worked side-by-side, completing each portion of the project together. This was our goal from the beginning of our work session as we felt that it would maximize both our understanding of the project and the relevant concepts as well as the final result as each part of the project would be evaluated and thought through by both of us. Specifically, there were only two occasions where the two of us were not working together. Matt spent some extended time working on the main control flow loop while Josh was out for the Passover holiday. Josh made up for this extra time by spending an extended session putting together a large portion of the hardware system.
Appendix V: Acknowledgements
We would like to thank Professor Bruce Land for his help throughout this semester and especially on this final project. We would also like to thank our TA Derek for helping work a couple bugs out of our circuitry. Finally, our thanks to Andy Ruina and his Human Power and Bicycle lab for letting us use a few of their spare parts that were sitting around.
High Voltage Laser Power Supply
Barnett, R. et al. (2003). Embedded C Programming and the Atmel AVR. New York.
Horowitz, P. et al. (1989). The Art of Electronics 2nd Edition. Cambridge.
Datasheet for the Atmega32