THE RASPBERRY PI EMBEDDED COMPUTER AS AN ALTERNATIVE

CONTROLLER FOR REMOTE ACCESS LABORATORIES

A thesis submitted to the

Kent State University Honors College
in partial fulfillment of the requirements
for University Honors

by

Michael Marvin

May, 2014

i
 Thesis written by

Michael Marvin

Approved by

________________________________________________________________, Advisor

______________________________________________, Chair, Department of Physics

Accepted by

___________________________________________________, Dean, Honors College

ii
 TABLE OF CONTENTS

LIST OF FIGURES............................................................................................................iv

ACKNOWLEDGMENTS...................................................................................................v

CHAPTER

I. INTRODUCTION.......................................................................................1

II. THE CURRENT METHOD OF CONTROL..............................................2

Advantages of this method...........................................................................4

Disadvantages of this method......................................................................5

III. THE RASPBERRY PI METHOD.............................................................10

Hardware overview....................................................................................10

Software overview.....................................................................................13

Advantages of the Raspberry Pi method...................................................15

Disadvantages of the Raspberry Pi method...............................................18

IV. VERIFCATION THROUGH CREATION OF A LASER

RANGEFINDING LAB...........................................................................22

Sending......................................................................................................23

Receiving...................................................................................................27

V. CONCLUSIONS......................................................................................34

REFERENCES..................................................................................................................36

APPENDIX

1. DETAILED RASPBERRY PI SOFTWARE SETUP.....................................37

iii
 LIST OF FIGURES

Figure 1. A diagram of the Raspberry Pi...........................................................................11

Figure 2. A screenshot of the example index.html webpage.............................................24

Figure 3. The schematic diagram for the control board.....................................................26

Figure 4. The first version of the control board.................................................................26

Figure 5. A diagram of the setup with the first prototyped amplifier................................30

Figure 6. The first amplifier circuit moved onto a piece of perfboard..............................31

Figure 7. The schematic diagram for the amplifier circuit using the LT1058CN.............32

Figure 8. The pinout for the LM324N and LT1058CN.....................................................33

Figure 9. The circuit for the LT1058CN on a piece of perfboard......................................33

iv
 ACKNOWLEDGMENTS

I would like to thank my thesis advisor, Dr. Jon Secaur, for his guidance and

assistance with this thesis. Without his help none of this would have been possible.

Additionally, I would like to thank Wade Aldhizer for his assistance with the aluminum

box used with the detector.

Finally, I would like to thank those in the defense committee for all of their time and

assistance.

v
 1

1. Introduction

Distance learning utilizes the internet to allow students to attend classes or

perform other typically classroom oriented activities from afar, often from their homes.

This allows students who lack the transportation or travel time required to attend courses

at a traditional institution to improve their education. Kent State University has been

progressing toward offering more courses and degree programs online, with 17 degree

programs and 10 certificate programs available completely online along with several

hundred individual courses from a wide range of departments.

One of the innovative ways that the Department of Physics is getting involved is

by offering remote access laboratories, which are entirely online lab experience courses.

These lab courses go along with corresponding online physics courses, such as PHY

21040 “Physics in Entertainment and the Arts” and the corresponding lab course PHY

21041 “Physics in Entertainment and the Arts Laboratory”. The lab courses are made up

of several lab modules which may require students to perform experiments at their

homes, such as measuring the speed of light using a microwave oven. In other activities

students use their computers to control an experiment that is hosted on campus. The

second style of laboratory is the focus of this thesis. I propose using a Raspberry Pi

embedded computer as the server computer connected to the laboratory equipment with a

webpage for control, and compare this to the current method which uses a standard

Windows desktop and the Virtual Network Computing (VNC) protocol for control.
 2

2. The Current Method of Control

To understand and compare the two methods, a detailed overview of the current

method of controlling the remote access laboratories is required. The current method

requires students, who will be synonymously referred to as “users”, to log into a

computer that is hosted on campus from their own computers using either a VNC client

or the LogMeIn web service to take control of the lab equipment. The general idea of this

is fairly simple, as users directly control the computer that they are connected to as if it

were their own computer, with inputs and display information being sent to or from the

laboratory computer. Users see the same display as the monitor attached to the laboratory

computer on their own display and interact with it using the mouse and keyboard attached

to their own computer, just as if they were using the laboratory computer directly. This

can be done from anywhere the user has access to a computer and the internet, with

several restrictions which will be expanded upon later in this chapter.

LabVIEW, a program created by National Instruments, is used to control the

webcams and other equipment connected to the laboratory computers. LabVIEW utilizes

a graphical programming language called G where programs are created by dragging

wires between blocks which represent different functions. For instance, to take a picture

with a webcam a program may be written which starts with an initialization block to

initialize the camera, followed by a block defining the properties of the image to be taken
 3

(such as resolution, exposure time, etc.), followed by a block that commands the camera

to take an image, and finally ending in a block that shuts down the camera. By chaining

blocks together like this, programs can be written to control each piece of equipment and

act on data received. A graphical interface, known as the front panel, contains the

controls, meters, graphs, text, and webcam images that the users interact with, each of

which has its own corresponding block in the program. To make a meter display a certain

value, for example, it is first added to the front panel, and then a wire is drawn from the

value to the input on the meter block in the block diagram. Similarly, a button on the

front panel has a block with an output which can be fed into the input of another block

with a wire. When a user clicks the button, the state of the output will change and affect

the input of the wired block accordingly.

When the users log into the computer using the VNC client or LogMeIn service

through their web browsers they are given full control of the computer. In a typical

scenario the LabVIEW program which was written for the lab that the computer is

connected to will be running and will occupy the entire screen. The users then interact

with the controls of the program to change aspects of the experiment (such as activating

an LED light or altering the frequency of an oscillating rope) and record the output given

on screen, either from meters on the front panel or from the webcam image displayed.

Interaction with external circuits is performed using a USB data acquisition

device (DAQ) produced by National Instruments and designed to interface directly with

the LabVIEW software. This allows programs to be written which can control and read
 4

digital signals to control external machines and circuits or to read sensors such as

temperature or light sensors. With this, physical devices can be constructed that are

controlled by the programs to perform laboratory tasks. One simple example would be

turning a desk lamp on or off to illuminate the experiment for night time viewing.

2.1 Advantages of this Method

This method of control has several key advantages over the Raspberry Pi method.

The primary advantage is the use of National Instruments LabVIEW, which is a powerful

set of software that, due to the graphical nature of its programming, is easier for those

without programming experience to use than traditional programming languages.

LabVIEW allows the designer of the lab to easily interface with external devices and

create a functional and attractive graphical interface. The use of VNC for display and

input gives the users a familiar form of interaction with the lab computer by using their

own keyboard, mouse, and monitor. Additionally, should a lab require a powerful

computer to process data before presenting it to the user, any sufficiently powerful

Windows computer can be used. Alternatively, should a lab require only a small amount

of processing power, a smaller or older computer may be used to save on initial costs.

Older computers can be recycled into controller computers instead of being thrown away

or placed in storage, giving these otherwise expired computers a new life with a practical

usage.
 5

2.2 Disadvantages of this Method

This method also has many disadvantages, some of them serious enough to

consider the method a liability to continue using for future experiments. The most serious

disadvantage with this method is security. The users are in full control of the computer

they are connected to, exactly as if they were sitting in front of it and using it with the

attached keyboard and mouse, but likely without anyone noticing they are there. They are

able to stop the program from running using onscreen buttons or key combinations which

then frees the program to have its source code modified. A user, if he or she were feeling

malicious or simply interested in how the program works, could easily stop execution of

the program and alter the functioning to change any parameter of the program. This could

prove to be dangerous, for instance if an attached device had certain physical limitations

which are accounted for in the code, such as the amount of time a device can remain

activated before being damaged, but are later changed by a user. The program then could

exceed these limitations and damage or destroy the device, which could even pose an

electrical or fire hazard. National Instruments includes several features to prevent this

sort of unauthorized access to the LabVIEW code. The first of these features is the ability

to remove the stop buttons from a running program, restricting the stop functionality to

keyboard shortcuts that the user is unlikely to know. By removing the button, there is

little to no chance that the program will accidentally be stopped and users are less likely

to stop the program on purpose. The second feature, which has been available since

LabVIEW version 5.0, is password protection of the program so that the source code

cannot be modified without entering the correct password. This reduces the chance even
 6

further that a user will be able to maliciously alter the functioning of the program and

helps secure the viability of this method. However, this is not enough to circumvent the

next major security flaw.

While the program itself may be able to be protected from malicious user intent,

the operating system itself is not. When a user assumes control of the computer through

the VNC protocol or LogMeIn service, they are given full access as if they were using the

computer directly. This means that the user can run programs, close out of programs, start

or stop services, install updates to programs or entirely new programs, access the internet

from within the university network, and potentially install any sort of malicious software.

This security hole is a major issue and could prove to be a liability to the university as a

user could install malware that could infect the rest of the university network or could

attack outside networks from within the university’s own network. A user could

accidentally remove or modify a program that is needed on the computer to run the lab,

or at the very least do something as simple as shutting down the computer or logging off

of the user account that is running the program. This can be mitigated somewhat by

having the program be run by a user account with limited permissions so that users

cannot modify the programs on the computer, but they will still be able to log off or

shutdown the computer, modify local files, and shut down LabVIEW.

Another issue with the LogMeIn service is that it is not intended for use by 50 or

more students in one class all attempting to access a single computer. It is likely that two

users will attempt to control the computer at the same time. This may kick the first user
 7

out of the system when the second user connects or may allow both users to control the

computer at the same time. If the two users are controlling the same computer, their

inputs will both be applied and both will be unable to properly control the equipment.

LogMeIn also has a subscription cost that must be paid by the university, which currently

costs $299 per year for the entire set of lab computers. Users attempting to connect to the

computers must install a web browser extension, which they will likely not use after the

course is complete, which would ideally be avoided in a final control solution.

An alternative to using LogMeIn is offered by National Instruments in the form of

their own web interface. LabVIEW supports streaming a copy of the front panel to the

web as a website that can be accessed by a standard web browser. It can be configured so

that only one user can assume control at any time and further users must wait until the

current user is complete. Unfortunately the remote front panel, as it is called, requires

users to download and install a large runtime engine that is compatible with the version

of LabVIEW used, their choice of operating system, and the web browser in use. The

runtime engine does not always download and install automatically and must be found on

the National Instruments website by the users themselves. If a webcam is used in a lab

then users will need a second runtime engine for the National Instruments Vision module.

The Vision runtime engine is currently only available for the Windows operating system

and so users of Mac OS or Linux will be unable to access remote front panels this way.

As many of the current labs use webcams, this makes the remote front panel option not

sufficient as a universal solution for remote control.

 8

In addition to these serious issues with the current method of control, several less

severe but nonetheless disadvantageous issues also exist. One of these is the cost with

developing and maintaining a remote access laboratory. The computers used for running

the labs are generally older computers that are being replaced. These computers would

otherwise cost the university if free computers were not available when a new lab is

being developed. Additionally, webcams must be purchased for these computers should

the lab require one, which they often do. Most importantly in terms of initial hardware

cost, USB DAQ equipment must be purchased from National Instruments which costs

$150 to $1000 or more, even if just a single input or output is needed. The software must

additionally be purchased, such as the Windows operating system, LabVIEW, and the

Vision module if a webcam is needed. There is a continual cost also associated with

running these labs as the computers are left running 24 hours a day, 7 days a week.

Assuming an electricity cost of 10 cents per kilowatt-hour and an average usage of 100

watts per computer, the yearly cost for running one lab is

(1)
If I assume there are up to 10 labs running at any one time, then this cost becomes over

$875 annually even when the labs are not actively being used by students.

It is clear that an alternative method of control is needed, in terms of the

computers interfacing with the labs and also with how the user interacts with those
 9

computers. I propose an alternative control scheme utilizing a Raspberry Pi embedded

computer, which will be explained in detail in the next chapter.

 10

3. The Raspberry Pi Method

This chapter will focus on the general setup, advantages, and disadvantages of the

Raspberry Pi control method. A detailed specific example of this usage will be covered in

chapter 4. Prior to discussing the major changes of this method relative to the current

method, an overview of the Raspberry Pi embedded computer itself is needed.

The Raspberry Pi, which I will occasionally refer to as the Pi, is a credit card

sized embedded Linux computer developed by the nonprofit Raspberry Pi Foundation

based in the UK to provide a low cost computer that schools can use to teach

programming to students. Its low cost and high customizability has made it attractive to

hobbyists and is a primary reason I will be using it.

3.1 Hardware Overview

The Raspberry Pi computer has physical dimensions of 85.60mm long by 56mm

wide by 21mm tall. For comparison, typical credit card dimensions are 85.60mm long by

53.98mm wide. For the Raspberry Pi Model B, the onboard system on a chip (SoC)

which contains the central processing unit (CPU), graphics processing unit (GPU), and

random access memory (RAM), is the Broadcom BCM2835 which contains a CPU

running at 700 megahertz, a GPU capable of BluRay video playback using H.264

encoding at 40 megabits per second, and 512 megabytes of RAM. This is comparable in
 11

processing power to the Droid 2 smartphone released in the year 2010, but is more than

powerful enough to run a standard lab. The Pi Model A uses a similar SoC but only has

256 megabytes of RAM available. A diagram of the Raspberry Pi Model B with

sicomparison can be seen in Figure 1.

Figure 1. A diagram of the Raspberry Pi. A size comparison to a standard credit card is given. The large square chip in
the center is the Broadcom SoC.

The operating system and other files are stored on an SD card that is placed in the

onboard SD card slot. As long as an SD card has enough space for the operating system it

can be used, which generally requires an SD card of at least 2 gigabytes in size. The

Raspberry Pi Foundation suggests an 8 gigabyte SD card or larger for the recommended

operating system installation procedure. Additional peripherals, such as a monitor or

keyboard, can be connected to the included HDMI, coaxial composite video, coaxial

3.5mm stereo output, 100 megabit Ethernet, or two USB 2.0 ports. Additional
 12

connections exist for a specialized camera module, currently available, and a display

module which is to be developed by the Raspberry Pi Foundation. The Raspberry Pi

Model A forgoes the Ethernet port and one USB port to reduce cost and power

consumption. Because the Model B includes an onboard Ethernet connection, it will be

used for this method.

A major feature of the Raspberry Pi is the inclusion of general purpose

input/output (GPIO) headers. These are male pins arranged in two rows of 13 on the

board which can be controlled from software running on the Pi. They are comparable to

the input and output channels on the USB DAQ used in the current method of control in

that they can send and receive digital signals. Some of these pins are dedicated 5 volt, 3.3

volt, or ground pins which cannot be changed, but the others can function as input or

output pins capable of sending or receiving a high signal of 3.3 volts or a low signal of 0

volts. A select few pins are capable of other functions, such as Serial Peripheral Interface

(SPI) communication, Inter-Integrated Circuit (I2C) communication, or Pulse-Width

Modulation (PWM). These will be used to integrate external devices into the labs in the

same way that the USB DAQ device is currently used.

There are currently two variants of the camera module available. The first is

comparable to a standard high definition color webcam and is the one that I use. It is

capable of taking up to 5 megapixel photos at a resolution of 2592x1944 pixels or

recording video at 1920 by 1080 pixel resolution at 30 frames per second. The second

version, known as the NoIR does not contain an infrared blocking filter and is suitable for
 13

nighttime use. Because this version lacks an infrared filter, infrared lights can be used to

illuminate the target of the camera. Infrared light is invisible to human vision and is

convenient to use when normal visible light would be considered a nuisance.

3.2 Software Overview

None of the software used in the traditional method is kept in this method. One of

the primary reasons for this is due to incompatibility with the Raspberry Pi hardware and

the operating systems available for use on it. The Raspberry Pi has a large set of

supported operating systems, including a derivative of Debian Linux titled Raspbian, a

port of the Arch Linux operating system, and Pidora which is a port of the Fedora Linux

operating system. Raspbian is the operating system recommended by the Raspberry Pi

Foundation for new users due to the included software packages and user friendly

interface. I decided on Arch Linux, however, due to its barebones nature. This does mean

that the initial setup will be more complicated but has the advantage of only installing the

programs needed. This reduces the total file usage of the operating system, reduces RAM

usage, and possibly increases security as potentially insecure programs will likely not be

installed. The choice of operating system will otherwise have no effect on the students

connecting to the remote access laboratory as the other programs used are agnostic to

which Linux operating system is running on the Pi, and as such Raspbian could be used if

one so desired.

Control of the laboratory will be managed by the software package WebIOPi,

which adds a simple way to control the GPIO pins from a web interface and Python
 14

script. Users will point their web browsers to a given URL, enter a username and

password which will be provided to them, and then will be able to interact with the

webpage. On the webpage there can be buttons, sliders, and other control interfaces,

similar to the front panel in LabVIEW, which will control various aspects of the lab. The

website can use traditional HTML and JavaScript functions to define the appearance and

interaction, while WebIOPi offers additional functions for controlling and reading from

the GPIO pins through the web interface. WebIOPi does not require any runtime engines

or browser extensions to run and can be viewed from most web browsers, including

mobile web browsers on smartphones and tablets. The appearance of the website is

defined using standard HTML and so can be created by hand using a text editor or any

standard webpage design software.

WebIOPi includes its own web server but it is possible to use an existing Apache

web server installation for serving the webpage. I did not test using Apache and instead

used the included web server during testing.

To stream webcam footage on the webpage from the Raspberry Pi camera module

I used a modification of the MJPG-Streamer program. MJPG-Streamer is a program

which takes images from a webcam or a folder and streams them to the web. The version

I used contains a plugin designed for use with the Raspberry Pi camera module which

gives higher frame rates than other plugins tested. The webcam stream is able to be

accessed using the standard HTML <img> tag and so no extra plugins or programs are

needed by the user viewing the stream. It can be embedded into the lab webpage using
 15

the <img> tag and the IP address of the Raspberry Pi, along with the port that the stream

is being shared on. No control of the stream is offered to the user and so a constantly

updating image is presented with no way of pausing or stopping the webcam image.

3.3 Advantages of the Raspberry Pi Method

Now that a general overview of the proposed method has been given, detailed

advantages over the current method can be given. Starting with the counter of the current

method’s most serious disadvantage, I present the advantages in terms of security that

this new method offers, beginning with the chosen operating system.

Arch Linux is an operating system based upon the Linux kernel. Linux operating

systems are not as popular as Windows operating systems, with Linux occupying 1.48%

of the desktop market share and Windows occupying 90.84% according to

netmarketshare.com in February of 2014. Linux is thus a smaller target for virus threats

as viruses written for Windows will have a greater chance of infecting more computers.

Coupled with the fact that Arch receives frequent updates to all of its programs and that

viruses written for one Linux distribution are not guaranteed to work with another Linux

distribution, the chance that the Pi will be infected with a virus is low. Additionally,

should a user somehow gain access to the actual operating system on the Pi, the

command line only interface and completely different set of commands from a Windows

computer would possibly deter them from attempting to make changes to the system.

Should a user manage to damage the file system in some way, all that is needed is to flash

a backed up image of the filesystem onto the SD card again and everything will return to
 16

normal working order. As such, after a lab is completed and verified to be working the

filesystem should be imaged and stored securely in case of future damage.

Accessing a prompt which would allow the user to run commands is much more

difficult with this method. Instead of giving users complete access to the full desktop,

they are limited to only being able to control what is exposed to them through the web

interface. The user cannot make changes to any files on the system unless there is a

corresponding action that can be performed from the web interface, nor can they remotely

shut down the computer or even the lab program. The website can additionally be

password protected with a simple encryption method so unauthorized users cannot access

the web interface. This password can be changed easily from the command line by the

administrator and so can be changed each semester or year to prevent students who have

taken the course earlier from accessing the lab when they shouldn’t be able to. The

encryption used is not designed to be safe from a serious hacking attempt, however, and

so a more secure authentication scheme may be needed to protect against this kind of

attack. With that said, the danger posed by a hacker gaining access to a lab web page can

be minimized through well designed labs that do not allow the user to damage the lab

equipment through the web page.

Moving away from the added security benefits, the next largest advantage is that

of cost. The hardware alone represents a non-trivial reduction in cost, especially if a new

computer would be needed to run the lab. A brand new Raspberry Pi Model B costs $35

before shipping and sales tax. This covers the functionality of the desktop computer and
 17

USB DAQ device in the current method, where the DAQ alone costs $150 or more. The

Pi also requires the purchase of an SD card and a power supply, with an 8 gigabyte SD

card costing less than $10 online and a 5 volt DC power supply providing at least 1 amp

of current costing less than $20. The standard camera module can be purchased from the

same retailers as the Raspberry Pi and costs an additional $25. Dedicated keyboards,

mice, and monitors are not needed as the Pi can be run “headless” where all configuration

is performed through an SSH connection from another computer. Any other hardware

needed for the lab would be needed even if the current method was used. This brings the

total cost of creating a new lab with brand new hardware up to a total of about $100.

Factoring in the cost of the Windows operating system, National Instruments LabVIEW

and Vision software, the LogMeIn service, and a webcam in the current method

compared to the 100% free cost of the software and the comparable cost of hardware

used with the Raspberry Pi method, the new method has a clear advantage.

Perhaps even more drastic than the difference in initial hardware costs is the

difference in long term operational cost. The Raspberry Pi consumes a peak power of 5

watts, which when run for an entire year costs

(2)
which is a total of $83.22 savings per lab per year. For a total of 10 labs running at one

time, the combined savings in electricity would be $832.20 per year, with a total cost of
 18

$43.80 per year. The electrical savings alone could pay for the introduction of 8 new labs

with brand new hardware for each.

All of the software mentioned is open source software that is free to use. Being

open source means that should a feature be required in one of the programs that does not

currently exist, the feature can be added, either by the developer of the lab or by a

member of the community that exists for the program. For instance, WebIOPi currently

supports several analog to digital converters and new drivers could be written for a new

device, should it be needed for a lab.

In addition to the advantages that the University would see in reduced cost and

increased security, the students themselves would see an improvement as well. WebIOPi

supports nearly every modern browser available, including mobile browsers for tablets

and smart phones, all without needing browser plugins or runtime engines. This means

that students can simply click a link to the lab from within the course syllabus or website

without needing to install anything first or using an unfamiliar program. They are not

restricted to a certain operating system or web browser and, most importantly, can access

the labs from public computers that do not allow the installation of other programs, such

as computers in a public library or university computer lab.

3.4 Disadvantages of the Raspberry Pi Method

This method does come with its own flaws which must be taken into

consideration when deciding which method should be used when designing a lab. One of

the advantages of the current system is that computers which are no longer being used for
 19

their original purpose can be reused to run a lab. This method does not support this, as

new hardware must be purchased each time a lab is implemented. Additionally, all of the

programs used in the current method are unsupported by the Raspberry Pi hardware and

software. For instance, there are Linux versions of LabVIEW available, but they are

designed with Intel and AMD processors in mind. LabVIEW for Linux would not run on

a Raspberry Pi because the processor uses the ARM architecture. Additionally, the

LabVIEW development environment requires one gigabyte of RAM while the Pi only has

512 megabytes of RAM. This hardware limitation on software exists for programs other

than LabVIEW as well, as programs not specifically designed to run on the ARM CPU

architecture are not guaranteed to run on the Raspberry Pi. This issue is mitigated

somewhat by the choice of programs covered previously in this chapter, which are all

designed to run on the Raspberry Pi.

An additional disadvantage regarding the use of the Linux operating system on

the Raspberry Pi is that it is generally used exclusively through a text only terminal and

not with a graphical user interface (GUI). It is possible to install a desktop environment

onto the Pi, and Raspbian comes with one installed by default, but Arch Linux does not

come with one preinstalled. This was a deliberate choice as I have experience with using

Linux through a terminal interface and not including a desktop environment leaves more

space for other files, but others who are working on designing labs may not have the

same experience and would have to learn an entirely new operating system without using

a graphical interface.
 20

The programming of the labs is also performed without a GUI as the Python code

used with WebIOPi is created using a standard text editor, as opposed to the graphical

programming that LabVIEW uses. This may prove to be an additional challenge for those

who are not familiar with programming. Design of the website used to control the lab

also requires some use of editing HTML files with a text editor to include the javascript

and WebIOPi functions required to attain the desired effects.

The hardware of the Raspberry Pi itself may be considered a disadvantage as the

limited processing power and memory may not be enough to handle the processing of

data a lab may require. As a result, more powerful computers may be required for labs

with large data processing elements and these labs would be unable to use the same

software set as the Raspberry Pi. This would result in two contiguous systems being used

for control within one laboratory course which could be confusing for students.

Additionally, to prevent the use of two different control systems in one laboratory

course the current system would have to be replaced entirely by the new Raspberry Pi

control method. This would have a nontrivial monetary and time cost as new hardware

would need to be purchased for each lab and new websites would have to be developed to

control the labs. However, once an initial basic setup with Arch Linux, WebIOPi, and

MJPG-Streamer all installed and configured is made and an image of the SD card is

created, using the SD card image as a base for future labs would cut down on the time

required to program new labs.

 21

One disadvantage that the Raspberry Pi method has along with the current method

is that two users can connect to and control the lab at the same time. This may be possible

to avoid using Apache instead of the web server included with WebIOPi, but I did not

test this. This means that two or more users may connect to the lab at the same time but,

unlike in the current method, their keyboard and mouse presses will not interfere with

each other as the webpage is displayed on their local machine. A lab may be able to be

designed to minimize interference caused by two or more users, such as the lab designed

in the next chapter. That lab has one button which resets a timer. If a user presses the

button while other users are viewing the webpage, the other users are still able to press

the button without harm.

 22

4. Verification through Creation of a Laser Rangefinding Lab

It is not enough to describe the Raspberry Pi method of control without also

providing a tested example laboratory. As a result, I attempted to construct a laser

rangefinding lab where students are able to fire a diode laser from the WebIOPi web

interface which is reflected off of a target and the light received by a detector at the

source. By determining the amount of time the light takes to arrive at the detector from

the laser source and knowing the speed of light, the students can measure the distance

between the source and the reflector.

For this laboratory a revision 2 Raspberry Pi Model B is used along with a 4

gigabyte class 4 SanDisk SDHC card to store the operating system and other files. The

standard camera module is used to provide a live stream of the oscilloscope that will be

used to display the sent and received signals. Power is provided by a 5 volt, one amp

micro-USB power supply that connects to a standard 120 volt AC power outlet.

Development of this lab is split into two parts; the first is “sending”, which

comprises the hardware and software necessary to control the laser source. The second

part is “receiving”, comprising the hardware necessary to view the returned light signal. I

will begin with a description of setting up the software on the Raspberry Pi from

installation of the operating system to final configuration of the website used for control.
 23

4.1 Sending

A condensed version of the software setup is presented here. For a detailed

procedure complete with Linux commands that can be used to produce this lab from

scratch, please see Appendix A.

The latest image of Arch Linux was downloaded from the Raspberry Pi

Foundation website and flashed onto the SD card using a computer running Windows 7.

The default password for the root account was changed along with the time zone

information. The hostname, or the name that other computers on the network see the Pi as

having, was changed to “physics-pi-00” and the camera module was enabled. I then

installed the programs needed to build WebIOPi and MJPG-Streamer, then built them

from their source code and installed them. Following this, I configured WebIOPi to use

the files I wanted instead of the default ones and installed a program that would allow me

to send an email when the Pi booted. I finally created a script which would start

WebIOPi, MJPG-Streamer, and send the email on system startup.

In the event that the system were damaged in the future and to speed the process

of creating a new lab with the same programs, I created an image of the SD card that can

be flashed onto a new SD card and used in a different Raspberry Pi. The only

configuration that would need to be performed to use it in a new lab would be to change

the hostname and the files used by WebIOPi. Additional configuration changes could

also be needed, such as the email address used to send and receive the startup email.
 24

An image of what the webpage looks like when loaded is included in Figure 2 for

reference.

Figure 2. A screenshot of the example index.html webpage. The image in the center of the webpage is the webcam
stream from the Raspberry Pi camera module and would typically display an oscilloscope output. This is a basic,
barebones example of a webpage that can be created for a remote access laboratory.

This covers the required software needed to control the laser, but additional

hardware was needed as well. The most important of these is the laser module itself. The

laser chosen for this lab was the 5mW 655nm Premier PWM laser by Global Laser Ltd.

This laser module was chosen due to its small beam divergence of less than 0.5

milliradians and ability to accept a TTL signal with a frequency of up to 1 MHz. The

distance I planned to have the laser travel was up to 5 km, as the distance between the

buildings I was planning on placing the lab equipment and the reflector at are around 2.5

km apart. The total time for the light to travel 5 km is about 17μs and I wanted to make

sure that there was a few microseconds between when the source pulse ended and the

first photons were received by the detector. I decided on having the laser be on for 10μs

and off for 27μs, for a total period of 37μs and a frequency of 26 kHz. If I had decided to
 25

reduce the distance travelled for the final version of the lab, having the option to go up to

1 MHz frequency would allow me to reduce the distance to 300 meters.

The TTL signal was generated by a 555 timer circuit that was built on a piece of

perfboard and designed to be plugged directly into pins 2, 4, 6, and 8 on the Raspberry Pi.

Pin 2 supplies the 5 volt power required by the laser, pin 6 supplies the ground

connection, and pin 8 corresponds to GPIO pin 14 in the Broadcom numbering. Pin 4 was

not used, but also supplies a constant 5 volts. The board was designed so that setting

GPIO 14 to a high signal of 3.3 volts would enable the laser and setting it to low would

disable the laser. This is done by connecting the output of the pin directly to the blue wire

on the laser diode. The TTL signal generated by the 555 timer circuit is connected to the

yellow wire on the laser, while the red wire and black wire are connected to the 5 volt

and ground planes on the board, respectively. A coaxial RCA connector is soldered to the

board with the outside connected to ground and the inside connected to the TTL signal.

This is then fed into one of the channels of the oscilloscope. A schematic diagram of the

circuit is given in Figure 3, with a picture of the first version of the board given in Figure

4.

To make the rise and fall times of the TTL signal as short as possible, the signal is

sent through two inverting Schmitt triggers. These are provided by the DM7414N

integrated circuit on the board.

 26

Figure 3. The schematic diagram for the control board. The 555 timer is an LM555CN and the Schmitt Trigger is a
DM7414N.

Figure 4. The first version of the control board. Several changes were made for the final version: the resistor in the
bottom of the image was moved to the correct location, headers for 5v and ground were added, and an RCA connector
was added. The female headers on the left connect directly onto pins 2,4,6, and 8 on the Raspberry Pi.
 27

4.2 Receiving

There is no software required for receiving the light emitted by the laser diode and

so only the hardware that I used will be discussed. There are three major parts of the

receiving hardware: the detector, optical amplification, and electronic amplification. The

detector chosen was the High Frequency Hawkeye detector by Global Laser Ltd. It was

chosen because it can handle input frequencies of up to 750 kHz, which would allow me

to reduce the total distance the laser travelled if necessary, and also because of its low

cost of less than $200.

To increase the amount of light reaching the detector, I used an inexpensive

refractor telescope as an optical amplifier. I mounted the detector inside an aluminum

project enclosure and used several pieces of ¼ inch and ½ inch PVC pipe to fix the

enclosure to the end of the telescope. To precisely aim the telescope at the reflector I used

two pieces of piping that were larger than the telescope diameter, one placed on each end

of the telescope tube, which were fixed to a piece of wood for support. Three holes were

drilled into each piece of piping spaced evenly around the perimeter of the pipe. Three

thumb screws were then threaded into the holes and the telescope was placed inside the

piping. By adjusting the screws I could precisely move the front or back of the telescope

to aim it directly at the target. A similar, smaller setup was done for the laser so that it too

could be aimed, with the back of the laser diode fixed in place and the front adjustable

with three thumb screws. This was fixed with more PVC pipe to the telescope and the
 28

wires from the laser were guided through the piping to the Raspberry Pi and the control

board.

The maximum distance that the light could travel and still be detected by the

detector under ideal conditions can be determined by the laser power, the beam

divergence, and the sensitivity of the detector. One millivolt of signal should be enough

to amplify and still be distinguishable from noise and as the detector has a sensitivity of

one volt per milliwatt, then one microwatt of power going into the detector should be

enough. The total length of the beam can be calculated as follows,

( ) (3)

where l is the length of the beam, D is the diameter of the beam at the detector, and θ is

the beam divergence. The maximum diameter of the beam that will provide one

microwatt of power on the detector can be determined from the area of the detector’s

sensor and the total power of the laser,

√( )
(4)

where D is the diameter of the beam, Pl is the total power of the laser, Pd is the power per

area required. Pd is calculated from needing one microwatt of power on the area of the

sensor,

(5)
 29

with A being the sensor area. For this detector, the sensor diameter is 0.50cm with an area

of 2.0x10-5 m2, resulting in a Pd of 5.1x10-2 W/m2 and thus a D of 0.35 meters. From this

and equation 3, using the beam divergence of 0.5 milliradians, a total length l of 700

meters is attained. This is less than a kilometer, and so will not suffice for the purposes of

the experiment. Using the telescope, however, increases the usable area to 2.0x10-3 m2,

resulting in a Pd of 5.1x10-4 W/m2, a D of 3.5 meters, and a total length l=7.0 km, further

than the 5 km expected for the final lab, meaning under ideal conditions the equipment

will work for the lab.

The electrical amplification was more difficult as neither I nor my advisor had

any previous experience with amplifiers. I operated by finding potentially useful

amplifier circuits on the internet or in the datasheets of operational amplifiers and then

tested them to see if they would meet my needs. Operational amplifiers, often abbreviated

as “op amps”, work by amplifying the difference in voltage between the two inputs.

Ideally in an open loop configuration the gain produced by the amplifier is infinite,

meaning the slightest difference in voltage between the inputs results in the amplifier

outputting at the maximum voltage when the non-inverting terminal is at a higher voltage

than the inverting terminal, or at the lowest voltage when the non-inverting terminal is at

a lower voltage than the inverting terminal. To control the magnitude of the gain, a

feedback resistor is used from the output terminal to the inverting terminal. The output

voltage then reaches equilibrium when the inverting input is at the same voltage as the

non-inverting input.
 30

I used an LM324N for the first part of my tests, trying a simple operational

amplifier circuit first. This did not work, partly due to the fact that the detector outputs an

AC signal centered on 2.5 volts but the amplifier needed a signal centered on ground.

Because of this I decided to try a differential amplifier, specifically an instrumentation

amplifier, where the input signal is compared to a reference voltage and any differences

in voltage are amplified. In the initial testing with the amplifier circuit on a breadboard, I

was able to get a substantial return signal from all the way down the hallway of the

physics building, Figure 5, which is over a hundred meters in total length. After

transferring the circuit to a perfboard, Figure 6, I encountered problems with the circuit

and was not able to get any signal at all from any distance.

Figure 5. A diagram of the setup with the first prototyped amplifier. The circuit uses the LM324N as an
instrumentation amplifier. The signal visible on the oscilloscope is the output from the detector after the laser light had
travelled down the entire hallway and back.
 31

Figure 6. The first amplifier circuit moved onto a piece of perfboard. The female headers on the left connect to the
detector, with 5V available on the top header, the signal from the detector on the center header, and ground on the
bottom header. The single female header located next to pin 7 on the LM324N is the output from the amplifier. The
potentiometer on the right allows the reference voltage to be fine-tuned around 2.5 volts. The potentiometer on the left
allows for a configurable gain.

I tested the circuit using a function generator producing a sinusoidal wave

centered on 2.5 volts with a variable frequency and amplitude. I determined that the

LM324N chip had somehow been damaged, perhaps by a static discharge, and tested the

circuit with a new chip. With the new chip, the circuit appeared to be working but the

gain potentiometer was not performing as expected. I was only able to get a gain of 40 at

100 kHz frequency and an input peak to peak voltage of 5mV. Adjusting the

potentiometer had no effect on the overall gain like I was expecting. After reducing the

frequency to 1kHz I was able to adjust the gain by changing the resistance of the

potentiometer and could reach a maximum gain of 833 using a 3mV input signal. Testing

at 10 kHz revealed maximum gains of 250 times using a 10mV signal. Seeing as I was

expecting a frequency in the tens of thousands of Hertz, I decided to search for an

amplifier integrated circuit with a high slew rate, as the slew rate is related to how

quickly the amplifier can operate on the input signal.

 32

I decided on the LT1058CN because of its high slew rate of 13 V/μs compared to

the LM324N’s slew rate of 0.5 V/μs. I initially tried replacing the LM324N in the circuit

with the new LT1058CN but was not able to get any appreciable gain. I then found the

circuit diagram for an amplifier that would give a constant gain of 1000, Figure 7, but

requires a split supply of +12V and -12V, as opposed to the single supply of +5V that I

was using. The pinout for the LT1058CN and LM324N are the same and is given in

Figure 8. This new circuit required a signal centered on 0 volts, so I placed a small

capacitor in series with the input signal. I tested the circuit on a breadboard and found it

to work well with the test signal, so I moved it to perfboard like I did for the previous

circuit, seen in Figure 9. Unfortunately I have not been able to get the circuit working

properly on the perfboard. For some reason after the first stage the signal becomes

centered on a negative voltage, which is amplified further in later stages, causing the

output signal to be fixed or nearly fixed on -12 volts. I have not yet been able to identify

the cause of this and so have not yet determined a fix.

Figure 7. The schematic diagram for the amplifier circuit using the LT1058CN.
 33

Figure 8. The pinout for the LM324N and LT1058CN. The chips are 14 pin dual inline packages.

Figure 9. The circuit for the LT1058CN on a piece of perfboard. The headers, from top left and going counter-
clockwise, are: ground for the oscilloscope, ground for the detector, signal from the detector, +5V for the detector, +5V
from the power supply, ground from the power supply, -12V from the power supply, and +12V from the power supply.
The single male header is the output from the amplifier.
 34

5. Conclusions

Unfortunately, due to time constraints, I was unable to finish creating a fully

functional laser rangefinding laboratory. The only unfinished part of the laboratory was

getting the receiving side of things working sufficiently; the hardware and software for

controlling the laser diode functions as expected. In retrospect, it may have been a better

test of the feasibility of the Raspberry Pi method of control by rebuilding one of the

currently existing laboratories using the Raspberry Pi. This would have allowed me to

compare the two methods exactly without also needing to deal with the logistics of

creating an entirely new lab. However, the lab I was trying to build was one that was

going to be implemented in the future and by making progress on it now, I have saved

time and effort for its later implementation. Despite its unfinished state, the laser

rangefinding laboratory still demonstrates the feasibility of the Raspberry Pi control

method for use in future labs.

Given the numerous disadvantages of the current method of control presented in

Chapter 2 and the Raspberry Pi method’s solutions to many of those problems presented

in Chapter 3 along with the demonstration of a remote access laboratory designed to be

controlled by the Raspberry Pi, the Raspberry Pi method of control should be

implemented for control of future remote access laboratories. As explained in Chapter 3,

the Raspberry Pi offers a low cost and power efficient control platform that is simpler for
 35

students to use. Students would not be required to download and install additional

software onto their computers, allowing them to use public computers to perform the

labs. The security enhancements offered by the Raspberry Pi method decrease the

likelihood of damage to the laboratory equipment and decrease the possibility of the

controlling computer being infected with potentially dangerous malware. These concerns

suggest that the current method of control is insufficient and should be replaced and that

the Raspberry Pi method may be the solution to these problems.

 36

References

"Distance & Online Learning." Distance Learning Online, Distance Learning. Kent State

University Office of Continuing and Distance Education, n.d. Web. 01 Apr. 2014.

<http://www.kent.edu/dl/index.cfm>.

Jackson, Liam. "MJPG-Streamer." GitHub. GitHub, 11 Dec. 2013. Web. 01 Apr. 2014.

<https://github.com/jacksonliam/mjpg-streamer>.

"Locking and Password Protecting a LabVIEW VI." National Instruments

KnowledgeBase. National Instruments, 29 Mar. 2013. Web. 01 Apr. 2014.

<http://digital.ni.com/public.nsf/allkb/B0CB267369078B3F8625751900662D89>

"Motorola DROID 2." Phone Arena. Phone Arena, n.d. Web. 01 Apr. 2014.

<http://www.phonearena.com/phones/Motorola-DROID-2_id4681>.

Ptak, Eric. "Internet of Things Framework." Webiopi. Google Project Hosting, n.d. Web.

01 Apr. 2014. <https://code.google.com/p/webiopi/>.

"Raspberry Pi FAQs." RaspberryPi.org. Raspberry Pi Foundation, n.d. Web. 01 Apr.

2014. <http://www.raspberrypi.org/faqs>.
 37

Appendix 1. Detailed Raspberry Pi Software Setup

A computer running Windows 7 was used to setup the SD card with the initial

Arch Linux image. It was later used to configure the Raspberry Pi through an SSH

connection. The latest Arch Linux image was downloaded from the Raspberry Pi

Foundation website and the SD card was inserted into an SD card reader on the Windows

computer. The program Win32 Disk Imager was used to prepare the SD card with the

Arch Linux image by selecting the Arch Linux image file, the corresponding drive letter

for the SD card, and pressing the “Write” button.

After the image was finished being written to the SD card, the SD card was

removed from the Windows computer and inserted into the Raspberry Pi along with a

USB keyboard, an Ethernet cable, an HDMI cable connected to a monitor, and the power

connection. Once the monitor displayed the login prompt, the username “root” was

entered and the password “root” was entered, without quotes. For all commands entered

into a terminal window, the Courier New font is used and they are prefixed by the “#”

symbol in this thesis. To get the IP address of the Raspberry Pi so that I could perform

additional configuration using an SSH connection, the command

# ifconfig eth0

was entered. The inet address listed is the IP address I have to enter to connect to the Pi.

The program PuTTY was used to remotely control the Pi through the SSH protocol. After

a connection was made using the same username and password as before, all of the cables
 38

connected to the Raspberry Pi were removed except the power and Ethernet cables.

Alternatively, the following commands could have been entered using the USB keyboard

and monitor without the need to use an SSH connection. All of the further commands

were performed through the SSH connection for the creation of this lab.

The first thing I did was change the password of the root user from the default to

something more secure. This is done by entering the

# passwd

command and entering the desired password twice, following the onscreen prompts.

After changing the password I changed the time zone data to Eastern Time. This can be

done using the following two commands, the first removes the current time zone data and

the second sets the new time zone to Eastern Time.

# rm /etc/localtime

# ln -s /usr/share/zoneinfo/America/New_York /etc/localtime

Next was to change the hostname of the Raspberry Pi. The hostname is what other

computers on the network will see as the Pi’s name. Every computer on the network

should have a different hostname for easy identification. I used the command line text

editor nano when editing text files directly in the terminal window. Nano is used by

calling the command nano followed by the path to the file to be edited. First I edited the

hostname file using

# nano /etc/hostname

and changed all instances of the default hostname alarmpi to the desire hostname, for this

lab I used physics-pi-00. The file is saved by pressing and holding the CTRL key and

pressing the x key. When prompted to save the file, the y key is pressed to confirm that
 39

you want to save the file followed by the enter key to accept the default name for the file.

This is the standard procedure for saving any files edited with nano. To complete the

change of hostname I had to add the physics-pi-00 hostname to the end of two lines in the

hosts file.

# nano /etc/hosts

The hostname was added to the end of the lines starting with “127.0.0.1” and “::1”. I then

updated the list of packages so that I could begin installing the dependences required to

build WebIOPi and MJPG-Streamer. This was done by first generating a key for the

package manager and then running the update command.

# pacman-key --init

# pacman -Syu

These commands each took some time to complete. To use the camera module I needed

to make a few changes to the /boot/config.txt file using nano. The following lines were

added to the end of the file.

start_file=start_x.elf

fixup_file=fixup_x.elf

disable_camera_led=1

I then installed the packages required to build the programs I needed.

# pacman -S base-devel python python-py python-setuptools cmake

libjpeg git

The system was rebooted after installation to finalize some of the setting changes made.

# reboot
 40

Next was to install WebIOPi. The latest version was downloaded from the Google Code

website where it is hosted and transferred to the Raspberry Pi from the Windows

computer using the sftp protocol through the FileZilla application. The version of

WebIOPi used was version 0.7.0.

# tar xvzf WebIOPi-0.7.0.tar.gz

# cd WebIOPi-0.7.0/python

# nano setup.py

In the setup file I had to add an option for the GCC compiler to ignore an error that

occurred when building. This error shouldn’t damage the final compiled code but without

disabling it I could not successfully build the software. I had to change the line that read

ext_modules = [Extension('_webiopi.GPIO', ['native/bridge.c',

'native/gpio.c', 'native/cpuinfo.c'])],

to read

ext_modules = Extension('_webiopi.GPIO', ['native/bridge.c',

'native/gpio.c', 'native/cpuinfo.c'], extra_compile_args=["-Wno-

error=declaration-after-statement"])],

Finishing the setup required just two more commands, one to change the directory and

the other to perform the setup. When performing the setup, the skip-apt argument was

passed because Arch Linux does not use the apt package manager while Raspbian, which

WebIOPi is developed on, does.

# cd ..

# ./setup.sh skip-apt
 41

After this WebIOPi was successfully installed on the system but not yet configured.

MJPG-Streamer was the next program installed by cloning the latest version from the git

repository and running the make command. Some folder management was performed to

clean up the folder structure, those commands are given as well.

# git clone git://github.com/jacksonliam/mjpg-streamer

# cd mjpg-streamer/mjpg-streamer-experimental

# make clean all

# cd ..

# mv mjpg-streamer-experimental/ ../

# cd ..

# rm -r mjpg-streamer

# mv mjpg-streamer-experimental/ mjpg-streamer

The folders that contain the actual lab scripts were created next, one titled “python” and

the other titled “HTML”, both contained in the /root/lab_files/ folder. The python folder

contains the Python script that controls the laser and the HTML folder contains the file

that defines the appearance and function of the website that users interact with.

# cd

# mkdir lab_files

# mkdir lab_files/python lab_files/HTML

Next was to configure WebIOPi to search the folders I created for scripts to run. I

used nano to edit the /etc/webiopi/config file and uncommented the line in the

[SCRIPTS] section of the configuration file that starts with “myscript =” to read

“myscript = /root/lab_files/python/script.py”. In the [HTTP] section the line starting with

 42

“doc-root =” was changed to read “doc-root = /root/lab_files/HTML”. The first change

causes WebIOPi to start the script.py Python script automatically when WebIOPi is

started. The second change causes WebIOPi to search for a file called “index.html” in the

/root/lab_files/HTML folder and serve that as the webpage seen when connecting.

Additionally, the port of the web server can be changed in the configuration file, but I

kept the default port of 8000.

To receive an update when the Raspberry Pi boots up along with the IP address of

the Raspberry Pi automatically, I setup an email messaging program that will use a gmail

account to send an email containing the IP address information. Using pacman I installed

ssmtp

# pacman -S ssmtp

and replaced the contents of the configuration file /etc/ssmtp/ssmtp.conf with the

following:

# The user that gets all the mails (UID < 1000, usually the
admin)
root=username@gmail.com

# The mail server (where the mail is sent to), both port 465 or
587 should be acceptable
# See also
http://mail.google.com/support/bin/answer.py?answer=78799
mailhub=smtp.gmail.com:587

# The address where the mail appears to come from for user
authentication.
rewriteDomain=gmail.com

# The full hostname

hostname=localhost

# Use SSL/TLS before starting negotiation

UseTLS=Yes
UseSTARTTLS=Yes
 43

# Username/Password
AuthUser=username
AuthPass=password

# Email 'From header's can override the default domain?

FromLineOverride=yes

Where “username” and “password” were replaced with the username and password of the

gmail account I used. I then changed the permissions of the file so that it was not

publically readable, as the password is stored in plain text, and made sure to add the root

user to the mail group.

# chmod 640 /etc/ssmtp/ssmtp.conf

# chown root:mail /etc/ssmtp/ssmtp.conf

# gpasswd -a root mail

I then added the following line to the bottom of the /etc/ssmtp/revailiases file:

root:username@gmail.com:smtp.gmail.com:587

with the same username as before.

To send an email on startup, I needed to add a systemd service that would run a

bash script located in the /root directory. Using nano, I created the

/etc/systemd/system/custom_start.service file with the following contents:

[Unit]
Description=Runs a bash script at startup located in the root
folder
After=dhcpd@eth0.service

[Service]
Type=forking
ExecStart=/bin/bash /root/start.sh

[Install]
WantedBy=multi-user.target
 44

And then enabled the service to be started at boot:

# systemctl enable custom_start

Afterward, I created the start.sh script in the /root directory that contains the commands I

want to have executed on startup. I wanted to autostart WebIOPi and MJPG-Streamer so

that in case of a power failure they would automatically resume. Additionally, I wanted to

send an email containing the IP address information to the gmail account used previously

when setting up ssmtp to alert me of a successful reboot and let me know the IP address

for initiating an SSH connection for remote maintenance. Therefore, the start.sh script

was created with the following contents:

#!/bin/sh # This is the shebang and tells the Pi what program to

run the script with

webiopi -c /etc/webiopi/config & # Starts the WebIOPi program in

the background

cd ~/mjpg-streamer # Changes the active directory to the mjpg-

streamer directory

LD_LIBRARY_PATH=./ ./mjpg_streamer -o "output_http.so -p 8080 -w

./www" -i "input_raspicam.so -x 640 -y 480 -fps 2 -quality 50" &
# Starts mjpg-streamer in the background using the raspberry pi
camera plugin. The resolution is set to 640x480 at 2 frames per
second and a quality setting of 50 (to save bandwidth)

sleep 20 # This allows the Pi to continue booting before trying

to send the IP address

echo “IP information for $HOSTNAME” > /tmp/ifconfig.txt # Create

a temporary file which will contain the IP address information
for the Pi

/sbin/ifconfig >> /tmp/ifconfig.txt # Append the IP address

information to the file
 45

mail username@gmail.com < /tmp/ifconfig.txt # Send the temporary

file to username@gmail.com

After creating the script with nano, I made it executable

# chmod +x /root/start.sh

and added the script.py and index.html files to the corresponding folders on the

Raspberry Pi using FileZilla. After doing so, an image of the SD card was made using

Win32 Disk Imager to be used as an initial image for further labs or as a backup in case

of damage to this lab. All that is needed to use the SD card image for future labs is to use

Win32 Disk Imager to apply it to an SD card, then boot the Pi with the SD card and

change the hostname and the files in the lab_files folder. Other configuration changes

could be needed, such as the port of the WebIOPi or MJPG-Streamer web pages.

The contents of script.py are below and are commented to explain what each line

does:

# import the libraries that will be needed

import webiopi
import time

GPIO = webiopi.GPIO # set GPIO as a shortcut for webiopi.GPIO

LASER = 14 # GPIO pin using BCM numbering

LASER_ACTIVE = False # A holder for the desired state of the
laser
TIMEOUT = 30 # seconds for timeout
TIME_START = 0 # A holder for the time the laser is activated

# setup function is automatically called at WebIOPi startup

def setup():
GPIO.setFunction(LASER, GPIO.OUT) # Set the pin to be an
output
GPIO.digitalWrite(LASER, GPIO.LOW) # Set the pin to low,
disabling the laser

# loop function is repeatedly called by WebIOPi

def loop():
 46

global TIME_START, LASER_ACTIVE

if (LASER_ACTIVE): # If the laser is supposed to be active
if (GPIO.digitalRead(LASER) == GPIO.LOW): # If it is
currently disabled, enable it
GPIO.digitalWrite(LASER, GPIO.HIGH) # Activate the
pin that controls the laser
TIME_START = time.time() # And mark the current time
if (time.time()-TIME_START > TIMEOUT): # If the current
time minus the start time is greater than the timeout, disable
the laser
LASER_ACTIVE = False # Set the laser to inactive in
code
GPIO.digitalWrite(LASER, GPIO.LOW) # physically
disable the laser

# gives CPU some time before looping again

webiopi.sleep(1)

# destroy function is called at WebIOPi shutdown

def destroy():
GPIO.digitalWrite(LASER, GPIO.LOW) # Disable the laser, just
in case

# This macro is called by the web page and tells the script to
enable the laser (in the loop() function)
@webiopi.macro
def activateLaser():
global LASER_ACTIVE
LASER_ACTIVE = True # Set the laser to active in code, but
not yet in reality
return True # Let the webpage know I received the request

The contents of index.html follow:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"

"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<meta name="viewport" content = "height = device-height,
width = 420, user-scalable = no" />
<title>Laser Range Finding Experiment</title>
<script type="text/javascript" src="/webiopi.js"></script>
<script type="text/javascript">
 47

webiopi().ready(function() { //When WebIOPi has started

perform the following
var content, button;
content = $("#content");
button = webiopi().createButton("laserButton",
"Activate", fire_laser); //Create a button called laserButton
that displays "Activate" to the user. When pressed, it activates
the fire_laser function
content.append(button); //Append the button to the end
of the "content" div element
});
function fire_laser() {
webiopi().callMacro("activateLaser"); //When this
function is called, it calls a macro in the script.py file that
sets the LASER_ACTIVE variable to true and activates the laser.
}
</script>
<style type="text/css">
button { <!-- This defines the appearance of any buttons
on the webpage -->
display: block;
margin: 5px 5px 5px 5px;
width: 160px;
height: 45px;
font-size: 24pt;
font-weight: bold;
color: black;
}
.Description {
display: inline;
}
</style>
</head>
<body>

<div id="instructions" style="float:left;max-width:30%;"> <!--

This div element contains a numbered list of instructions of how
to perform the lab. -->
<h3>Instructions:</h3>
<ol>
<li> Instruction 1 </li>
<li> Instruction 2 </li>
</ol>
</div>

<div id="content" align="center" style="float:left;width:640px;">

<!-- This div element contains the webcam stream and will also
contain the Activate button -->
 48

<img src="http://[Pi IP]:[Webcam Port]/?action=stream" /> <!--

This img tag will display the webcam stream if the IP address of
the Pi and the Port number that the stream is on are properly
configured -->
<br> </br>
</div>

<div id="constants" style="float:left;max-width:30%;"> <!-- This

div element contains an unordered list of possibly useful hints,
reminders, and values of constants that may be useful to the
students -->
<h3>Some helpful facts:</h3>
<ul>
<li>The speed of light, c, equals 2.998x10^8 m/s. </li>
<li>One second is 10^6 microseconds. </li>
<li>If a car travels at 15 m/s for 10 seconds then it travels a
total distance of 150 m/s. </li>

</ul>
</div>

</body>
</html>

At this point the software setup is complete. Rebooting the system sent an email

containing the output of the ifconfig command along with the hostname of the Pi. The

webpage for the lab could be accessed by pointing a web browser at the IP address in the

email and using port 8000. The webcam image was visible on the screen as well and

updated twice per second.