Design and installation of a Sky-camera network and data … · 2017. 5. 23. · Design and...
110
Design and installation of a Sky-camera network and data acquisition system for intra-hour solar irradiance and photovoltaic system output forecasting by Joseph Claude Eric Roy A thesis submitted to the Murdoch University to fulfil the requirements for the degree of H1264 in the discipline of Engineering Perth Western Australia, Australia, 2016 © Joseph Claude Eric Roy, 2016
Transcript of Design and installation of a Sky-camera network and data … · 2017. 5. 23. · Design and...
Design and installation of a Sky-camera
network and data acquisition system for
intra-hour solar irradiance and photovoltaic
system output forecasting
by
Joseph Claude Eric Roy
A thesis submitted to the Murdoch University
to fulfil the requirements for the degree of
H1264
in the discipline of
Engineering
Perth Western Australia, Australia, 2016
© Joseph Claude Eric Roy, 2016
iii
Author’s Declaration
I declare that this thesis is my own account of my research and contains as its main content
work which has not previously been submitted for a degree at any tertiary education institution.
Joseph Claude Eric Roy
v
Abstract
Murdoch University is enabling research in the area of intra-hour solar irradiance and photovoltaic
(PV) system output forecasting by installing a stereo vision capable Sky-camera network and
system. This research is being led by Dr Martina Calais and is in collaboration with the University
of Oldenburg Solar Energy Meteorology Group.
This document describes the process of designing and installation of Sky-camera equipment, and
along with its network and data acquisition system. Two Sky-camera locations had already been
identified on campus as suitable, by having few occluding objects in the Sky-camera’s field-of-
view, a power and network connection, as well as being near a data acquisition system that can
obtain PV power output and meteorological data.
The first location, on the top rail of a PV array on the roof of the Engineering and Energy Building,
was found to be marginally suitable due to tall trees and an elevator shaft. However, a different
location on this roof was chosen even though it required a greater installation effort. The second
Sky-camera location in the Renewable Energy Outdoor Test Area, offered a much simpler
installation process but lacked of an Ethernet access point. This required a wireless bridge to be
installed and configured.
The design of all custom made hardware for this project was accomplished using the Autodesk
Inventor® software suite, and then fabricated with the help of Murdoch University technical staff
and using in-house facilities. Networking all the Sky-camera equipment, the recreation of Python
codes into LabVIEW codes and changing a Linux Server to a Windows Server caused the largest
deviation from the original project plan. However, this led to the development of a different data
acquisition (DAQ) system program architecture that is anticipated to provide a more favorable
data availability rate. Other additional works that were outside the immediate scope includes; the
creation of a custom made Sky-camera image editing software for creating binary mask images
and the assembly of a Solys2 solar taker.
The overall Sky-camera network installation was successful and is now in a state that allows
research to begin. It is envisaged that the knowledge obtained through this project and following
projects will lead to the implementation of short term solar forecasting systems in remote diesel
networks.
vii
Acknowledgements
I would like to express my sincere appreciation to senior lecturer Dr Martina Calais, my project
assistants William Stirling, Simon Glenister and Taskin Jamal, to the technical officer Iafeta ‘Jeff’
Laava and John Boulton and to our technical adviser Thomas Smith for all their support, guidance,
and advice. I feel very fortunate to have had the opportunity to work with such a knowledgeable
and capable team. The success of this thesis project is testament of this support and hope you all
continue supporting others in the same way that you’ve all supported me on this project. Thank
you
Dr Martina Calais - Project Supervisor Dipl.-Ing TU Darmstadt, PhD Curtin University of Technology
Mr Simon Glenister – Researcher Assistant Murdoch University
Mr William Stirling - Project Assistant Murdoch University Technological Assistant
Thomas Schmidt – Technical Advisor
Diploma in Meteorology
Mr John Boulton – Technical Officer Murdoch University Engineering Workshop Manager
Taskin Jamal - Project Assistant Murdoch University PhD Researcher, School of Engineering
& IT PH Engineering Student
viii
Dedication
This thesis project is dedicated to my beautiful wife and lovely mother.
ix
Table of Contents
Author’s Declaration ................................................................................................................... iii
Abstract v
Acknowledgements .................................................................................................................... vii
Dedication viii
List of Figures ............................................................................................................................ xii
List of Abbreviations .................................................................................................................. xv
Chapter 1 Introduction ........................................................................................................... 1
1.1 Thesis Structure ..................................................................................................... 1
1.2 Project Introduction ............................................................................................... 2
1.2.1 Project Scope......................................................................................................... 3
1.2.2 Project Methodology ............................................................................................. 4
Chapter 2 Background ........................................................................................................... 7
2.1 Project Background ............................................................................................... 7
2.1.1 Campus Map ......................................................................................................... 9
2.1.2 The University of Oldenburg (UoO) ................................................................... 10
2.2 Sky-camera Technology ..................................................................................... 11
2.2.1 Sky-camera based forecasting technology overview .......................................... 11
2.2.2 Cloud Based Height (CBH) ................................................................................ 13
2.2.3 Location 1 Engineering and Energy Building ..................................................... 15
2.2.4 Location 2 Renewable Energy Power System Demonstration and teaching
facility (REPS) .................................................................................................... 17
Chapter 3 Hardware ............................................................................................................. 21
3.1 Hardware Selection ............................................................................................. 21
3.2 Hardware Purchase ............................................................................................. 22
3.2.1 PoE Injector Purchase ......................................................................................... 22
3.2.2 Sun Tracker Purchase .......................................................................................... 23
3.2.3 Sky Camera Calibration ...................................................................................... 23
Chapter 4 Installation ........................................................................................................... 25
4.1 Sky-camera 1 Installation .................................................................................... 25
4.2 Sky-camera1 System Installation ........................................................................ 26
4.2.1 Sky-camera1 Site Investigation........................................................................... 26
4.2.2 Sky-camera 1 Mounting System Design ............................................................. 28
4.2.3 Sky-camera 1 Hardware Installation ................................................................... 30
4.2.4 Sky-camera1 SOLYS2 Installation ..................................................................... 30
4.3 Sky-camera 2 Installation .................................................................................... 32
4.3.1 Sky-Camera 2 Installation Overview .................................................................. 32
x
4.3.2 Sky-camera 2 Site Investigation .......................................................................... 33
4.3.3 Sky-camera 2 Mounting System Design ............................................................. 34
4.3.4 Sky-camera 2 Hardware Installation ................................................................... 37
Chapter 5 Network ............................................................................................................... 39
5.1 Overview ............................................................................................................. 39
5.2 Sky Server and network configuration ................................................................ 39
Chapter 6 Software .............................................................................................................. 43
6.1 Python Software for Linux .................................................................................. 43
6.2 Temporary set-up ................................................................................................ 45
6.3 Making the change to LabVIEW ........................................................................ 47
6.4 LabVIEW Functions ........................................................................................... 48
6.4.1 Converting Python Codes to LabVIEW .............................................................. 48
6.4.2 Custom made Sky-camera image editing software ............................................. 49
Chapter 7 Data Acquisition System ..................................................................................... 53
7.1 Data Acquisition System Introduction ................................................................ 53
7.2 Initial Design And Its Problems .......................................................................... 53
7.3 Different Program Architecture Trial .................................................................. 56
7.3.1 APP DAQ trial results ......................................................................................... 58
7.4 New App DAQ System Design and Implementation .......................................... 60
7.5 Additional Programs Created .............................................................................. 66
Chapter 8 Results ................................................................................................................. 69
8.1 Sky-Camera Research Results ............................................................................ 69
8.2 Sky-Camera Installation Results ......................................................................... 69
8.3 Sky-Camera Network Results ............................................................................. 71
8.4 Python to LabVIEW conversion results .............................................................. 73
8.5 Sky-Camera DAQ Results .................................................................................. 73
Chapter 9 Conclusions and Future Works ........................................................................... 77
9.1 Suggested Future Works ..................................................................................... 78
References 80
Appendix A - Email Correspondences .................................................................................... 83
Vivotek PoE Adaptor Purchase Suggestions ........................................................................... 83
UoO feedback for the Sky-camera calibration ........................................................................ 84
UoO Sky-camera Background ................................................................................................. 85
UoO Sky DAQ Data Availability Rate .................................................................................... 87
Appendix B - Sky-camera Calibration .................................................................................... 88
Sky Camera Calibration Guide ................................................................................................ 88
Calibration Reports .................................................................................................................. 90
xi
Appendix C - Forecast Results ................................................................................................ 92
xii
List of Figures
Figure 1 Document Structure and relationship to Chapters. ........................................................ 2
Figure 2 Work-breakdown-structure for this project ................................................................... 5
Figure 3 Murdoch South Street Campus Map .............................................................................. 9
Figure 4 Figure: Example of a Sky-camera base solar irradiance forecast ................................ 11
Figure 5 Cloud shadow propagation uncertainty error due to unknown cloud base height ....... 13
Figure 6 Machine vision stereographic cloud base height measuring technology ..................... 14
Figure 7 outside view of the Engineering & Energy Building ................................................... 15
Figure 8 EEB PV training facility inverter and DAQ system .................................................... 16
Figure 9 Planned Sky-camera location on the EEB roof ............................................................ 16
Figure 10 exterior view of the REPS facility ............................................................................. 17
Figure 11 Overview of the system display screen from the LabVIEW DAQ system ................ 18
Figure 12 proposed location of the Sky Camera in the ROTA .................................................. 19
Figure 13 Initial system layout design and equipment selection ................................................ 21
Figure 14 Images from the Calibration process ......................................................................... 24
Figure 15 Picture of the Automatic corner extraction and an undistortion function .................. 24
Figure 16 SkyCAM1 Field-of-view investigation using a solar pathfinder (Calais, 2015) ....... 26
Figure 17 field-of-view from the new location on the EE building ........................................... 27
Figure 18 Solar geometry ........................................................................................................... 28
Figure 19 3D model of the EEB Sky-camera mounting system ................................................ 29
Figure 20 EEB Sky-camera Installation picture ......................................................................... 30
Figure 21 SOLYS2 installation with Mr. Glennister ................................................................. 31
Figure 22 A Sky-camera test picture from the ROTA location.................................................. 33
Figure 23 Camera installation plan for the ROTA location ....................................................... 35
Figure 24 Virtual prototype of Sky-camera mounting system usign Autodesk Invertor
software ............................................................................................................... 36
Figure 25 custom Sky-camera mount design fabrication plan ................................................... 36
Figure 26 Pictures of the Sky-camera installation at the ROTA location .................................. 37
Figure 27 Anticipated Sky-camera network configuration ........................................................ 40
Figure 28 Final SkyCAM network configuration ...................................................................... 41
Figure 29 Picture of the temporary setup ................................................................................... 46
Figure 30 view of the LabVIEW front panel ............................................................................. 49
Figure 31 Picture of the custom made Sky-camera image editing software .............................. 50
Figure 32 Example of the EEB Sky-camera 1 Binary Bitmap Mask image files ...................... 51
Figure 33 Example of the ROTA Sky-camera 2 Binary Bitmap Mask image file ..................... 51
Figure 34 Illustration of the initially encapsulated program architecture used to create the
first version of the Sky-camera DAQ system...................................................... 53
Figure 35 Query results of REPS DAQ system showing data capture inconsistency ................ 54
xiii
Figure 36 Query results of EEPV DAQ system program showing data capture
inconsistency ....................................................................................................... 54
Figure 37 illustration of an Application based DAQ system (APP DAQ) architecture ............. 56
Figure 38 Initial DAQ system proof of concept trial for using un-compiled independent
little LabVIEW programs (Apps) ........................................................................ 58
Figure 39 Overview of the APP DAQ system User Interface .................................................... 60
Figure 40 picture of the DAQ APP container title bar and four DAQ APPs below. ................. 60
Figure 41 Distributed APP DAQ topology ................................................................................ 62
Figure 42 LabVIEW APP DAQ template example 1 ................................................................. 63
Figure 43 LabVIEW APP DAQ template example 2 ................................................................. 64
Figure 44 DAQ APP Setting's page ........................................................................................... 65
Figure 45 Example of the DAQ App's ERROR LOG PAGE .................................................... 65
Figure 46 Example of the two data logging VIs used for configuring and logging data into
an SQL database .................................................................................................. 67
Figure 47 orientating and levelling the cameras ........................................................................ 70
Figure 48 Calibration report feedback from the University of Oldenburg ................................. 70
Figure 49 Modifation of Python codes for replacing a string with the MU logo ....................... 73
Figure 50 CSV files of PV system and environmental parameters ............................................ 74
Figure 51 Sky Camera Data Capture Rate ................................................................................. 74
Figure 52 Picture of the video received from the 19th of April Sky-camera image set. ............. 75
Figure 53 Solar irradiance forecast using new the new MU Sky-camera syste ......................... 75
Figure 54 Calibration pictures of Camera 1 using OcamCalib .................................................. 88
Figure 55 OcamCalib navigation bar ......................................................................................... 88
Figure 56 OCamCalib Processed and calibrated picture ............................................................ 89
Figure 57 Calibration Result Graph ........................................................................................... 89
Figure 58 Extrinsic Graph Results ............................................................................................. 89
Figure 59 Errors Graph Results .................................................................................................. 89
Figure 60 Camera 1(MAC0002D1378D25) Calibration results ................................................ 90
Figure 61 Camera 1(MAC0002D1378D25) Errors ................................................................... 90
Figure 62 Camera 2 (MAC0002D1313914) Calibration results ................................................ 91
Figure 63 Camera 2 (MAC0002D1313914) Errors ................................................................... 91
xv
List of Abbreviations
AI Artificial Intelligence
CBH Cloud Base Height
CCM cross-correlation methods
CMD Command Prompt
DAQ Data Acquisition
DHCP Dynamic Host Configuration Protocol
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol (Public & Private)
IT Information Technology
MU Murdoch University
MVOF machine vision optical flow
NTP Network Time Protocol
OS Computer Operating Software
PoE Power Over Ethernet
RE Renewable Energy
REPS Renewable Energy Power System (facility)
SDK Software Development Kit
SEIT School of Engineering and Information Technology
UoO University of Oldenburg
VI Virtual Interface
WMO World Meteorological Organization
1
Chapter 1 Introduction
1.1 Thesis Structure
This document is structured in four part: the introduction, background, core and synthesis.
1. The introduction explains how this document is organized, and explains the aims, goals and
the management methodology used for completing the project. Lastly, a scope and a work-
breakdown structure of the project are provided.
2. The background section provides a brief history for how this unique project opportunity was
manisfested, an explanation and a map are provided for each location allocated for the project.
Lastly, it also includes a brief description of the Sky-camera technology itself and its use.
3. The core section presents all the finer details and specifics about the project, and itself it is
divided into five distinct sections. These are; the hardware, the Sky-camera installation, the
network installation and its configuration, the software, and lastly the new Sky DAQ system
architecture section.
4. The synthesis section draws together all the results of the project. This section also
summarises the work and evaluate the degree to which the newly created Sky-camera network
meets the intents of the scope.
2
Figure 1 shows how the structure relates to each chapters of this document
Figure 1 Document Structure and relationship to Chapters.
1.2 Project Introduction
This thesis project started in July of 2015 and finished in June of 2016. The primary objective
for this project was to provide Murdoch University with the necessary infrastructure to begin
research and validation work in the area of Sky-camera forecasting technologies with machine
vision stereography cloud base height measuring technologies. Research into these
technologies was a necessary part of the project, however a much greater emphasis was placed
on the design and installation of its hardware components. The technical design requirements
for the new Sky-camera network and data acquisition system were already provided. However,
the installation and configuration of the Sky-cameras alone, depended on liaising with the UoO
in Germany.
3
The UoO are published experts in this area of research, and their knowledge was valuable when
designing the new custom made parts and when overseeing the construction and installation of
the new Sky-camera network equipment. Furthermore, this project was a multidisciplinary
project. It involved working closely with several university departments such as the SEIT
Engineering workshop, the University’s Building Management and IT service. For example,
liaising with the IT department and Mr Stirling was crucial when configuring new static IP devices
with special requirements on the different MU DHCP networks and subnets, which inherently
had restricted user domain privileges. Finally, the project also required a new computer language
and operating system to be learnt, and then be applied when creating a new specialised Sky-
camera data acquisition system.
The outcome of this project is a new Sky-camera network infrastructure that is ready to be used
as a research tool in the area of machine vision stereography cloud base height measuring
technology: this infrastructure consist of another network and specialised data acquisition systems
that can be synchronised and coherently capture pictures from two cameras located several
hundreds of metres apart; this infrastructure spans across a multitude of other networks and
technologies.
1.2.1 Project Scope
1. To review methods for determining cloud base height using data from two geometrically
calibrated Sky-cameras at Murdoch University and their application to short-term solar
irradiance forecasting.
2. To assist with project management, equipment purchase, installation and commissioning of
the Sky-cameras at the two locations
3. To develop a data acquisition system that allows for high time resolution measurements of
solar irradiance and PV system performance data at the camera locations.
4
1.2.2 Project Methodology
A waterfall project development model was chosen to manage this project since it is a classical
project management methodology, and is known to reduce the risk of project failure1. This is
because when using this methodology, a high level of planning is carried out at the beginning of
the project, so that each phase is clearly defined as a series of tasks arranged in a sequential order.
The project progresses by completing each task individually.
Four distinct phases were identify when creating a work-break-down structure for this project as
shown in Figure 2. These phases are research and design, hardware installation, provision of a
DAQ, and testing and validation. The specific tasks listed below do not offer an orderly nor 100%
comprehensive list for all possible tasks, but instead offer examples of the sequential development
process taken for successfully completing this project.
1. Research, analyse and report on the methods used for obtaining single point forecasts
using one Sky camera (e.g. predicting a photovoltaic system output at the location of the
camera) and stereographic methods for determining cloud base heights using two Sky
cameras at locations several hundred meters apart.
2. Research and identify the best university network access points and connection methods
3. Designate suitable locations for the Sky cameras and the data logging system.
4. Familiarize with, test and calibrate the Sky camera system by temporary installing the
equipment on a desk in a designated laboratory space.
5. Seek advice from the Oldenburg group to obtain and format the information accordingly
in order to suit their solar irradiance short-term forecast algorithms.
6. Access whatever PV output data is available from the existing PV systems located in
proximity to the Sky cameras
7. Design mounting systems for the Sky camera system hardware
8. Assist purchasing the necessary equipment
9. Assist creating the computer programs required for successfully completing this project
1 Project failure occurs when a project fails to meet all intents in the scope in time and on budget.
5
10. Assist with the installation, calibration and commissioning of the camera(s)
11. Validate the images and integrity of the data
12. Provide appropriate documentations such as but not limited to progress reports,
presentation slides and an as-built and maintenance program report.
Figure 2 Work-breakdown-structure for this project
7
Chapter 2 Background
2.1 Project Background
Murdoch University (MU) has a commitment to renewable energy, mainly through teaching,
testing and research. As a result, MU has a broad range of Renewable Energy (RE) systems
available for research.
In 2014, Dr Martina Calais (Calais) with the support of Dr Thilo Kilper, joined a collaborative
research project in the area of photovoltaic systems integration for remote diesel networks. This
collaboration in parts, included NEXT ENERGY1, a research institute affiliated with the
University of Oldenburg (UoO) in Germany, and Craig Carter, a Murdoch University adjunct
Professor. The research enabled Calais to go to Germany where she was introduced to the UoO
Solar Energy Meteorology Group and to their research on Sky-camera based forecasting
technologies, and where she met Dr Elke Lorenz, Dr John Kalisch, and Thomas Schmidt.
Afterwards, Calais received interest from Horizon Power2 to research Sky-camera technology and
then, was awarded a SEIT Small Grant Scheme Project grant for Sky-camera network
infrastructure at the South Street University Campus. This infrastructure is intended to enable MU
to begin validating work for Sky-camera based solar irradiance forecasting technologies and will
be designed such that it enables Sky-camera research in the area of obtaining cloud base height
(CHB) measurements.
The design of this new Sky-camera system began in 2015. Its design is being led by Calais in
collaboration with the UoO because in its initial stages, MU heavily relies on the expertise of the
UoO Solar Energy Meteorology Group.
1 NEXT ENERGY is a Research Centre for Energy Technology in Germany 2 Horizon Power is a is a State Government-owned power utility company in Western Australia, Australia
8
By mid-year in 2015, Calais devised a plan for installing a Sky-camera system at two different
locations. These being the roof of the Engineering and Energy Building EEB, as shown as location
1 on the campus map in figure 3, and the other being located in the Renewable Energy Outdoor
Test Area (ROTA), shown as location 3 in figure 3.
These locations were chosen due their relatively clear views of the Sky, and are located at a
distance of approximately 590 meters away from each other. This is believed to be enough for
determining CBH using machine vision stereographic imaging techniques (Calais, 2015).
Additionally, both locations were easily accessible and in proximity of a PV system containing
to some extent, a data acquisition system that could be used during the course of this research.
Lastly, Calais also outlined a plan to purchase the same types of equipment used by the UoO and
a wireless access point device to bridge an Ethernet network gap between the location 3 and 4
shown in Figure 3 Murdoch South Street Campus Map
On the 4th of July the Sky-camera equipment was purchased. These included: 2 Vivotek FE8174V
omnidirectional network cameras, a Dell Precision T1700 MT Server, and an EKI 636122GN-
AE Wireless Access Point.
9
2.1.1 Campus Map
Figure 3 Murdoch South Street Campus Map3
1. Engineering and Energy Building (Sky-camera 1 location)
2. Building 190 (Commissioning area)
3. Sea Container (Sky-camera 2 location)
4. Renewable Energy Power System (REPS) facility
3 Custom made map using scribblemaps.com. http://www.scribblemaps.com/create/#id=ge0YyAHn8W
10
2.1.2 The University of Oldenburg (UoO)
The University of Oldenburg is one of the most important educational facilities found in
Northwest Germany. It is well known for its Renewable Energy research and currently has 150
scientists working in the area of Renewable Energy technology research (PerformancePlus,
2015).
The Solar Energy Meteorology Group has been investigating shortest-term solar irradiance
forecasting methods since 2013. The research began when a single networked VIVOTEK FE8174
Sky-camera was installed on the rooftop of their university building and connected to a database.
This Sky-camera system, along with high time solar irradiance and photovoltaic module
measurements, enabled them to create and validate novel solar irradiance forecasting models.
The Solar Energy Meteorology Group published numerous papers about their Sky-camera
forecasting technologies, and have also taken part in major European Union solar irradiance
forecasting research, such as the PerformancePlus project which led to the publication of a joint
handbook section called "Best practices for optimal PV performance” and to a EUPVSEC
conference presentation publication providing a more detailed analysis of their results. See
Appendix A - Email Correspondences for more information about the UoO.
In 2015, the UoO agreed to join the MU Sky-camera research project and provide access to their
expertise. The main contact from the UoO during the course of this thesis project was Thomas
Schmidt.
11
2.2 Sky-camera Technology
2.2.1 Sky-camera based forecasting technology
overview
A Sky-camera system is a novel short-term solar forecasting system which makes use of
inexpensive omnidirectional cameras pointed towards the heavens and made to detect cloud
motion using modern computing algorithms such as machine vision optical flow (MVOF), cross-
correlation methods (CCM) as well as knowledge based artificial intelligence algorithms (West,
2014). The purpose of this forecasting system is to predict the reduced power output from solar
power systems that are in general caused by moving cloud shadows. This is done using solar
irradiance to electrical energy conversion mathematical models (West, 2014). A Sky-camera
based forecast example is shown in Figure 4.
Figure 4 Example of a Sky-camera based solar irradiance forecast. This image was taken
using the newly installed Sky-camera located at the ROTA location
12
A typical forecast of 20 minutes is possible using a Sky-camera based forecasting system, but this
forecasting time varies significantly due to a number of factors such as the cameras field-of-view
of the Sky, wind speed, cloud types, computational time and data acquisition speeds. The clouds
themselves create the largest source of error in the forecasts, because they can be arranged in
multiple layers, change shapes, size and colour, as well as appear randomly and disappear
completely (West, 2014).
Sky-camera system forecasts aligns well with the ramp up/down rate and the 1-10 minutes start-
up time requirement of diesel and gas power plants. Therefore, for high solar power system
penetration into a power system, a Sky-camera offers a simpler and less expensive solution than
batteries or flywheel technologies. The newly constructed solar farm for the Karratha Airport in
Western Australia provides an example of this technology being applied in Australia (Bell, 2015).
A recent study performed at a 1MV PV power plant in Munich, Southern Germany, where an
autonomous Sky-camera system providing power output forecasts up to 15 minute ahead, was
validated using the data acquisition system of the PV power plant (Domitrios, 2015)
The installation of single Sky-camera limits its forecast to predicting a solar power system output
at the location of the camera. This is because the Sky-camera images are two dimensional images
that are taken from a single perspective. The cloud base height (CBH) cannot be effectively
determined using two dimensional images and leads to errors when propagating the cloud
shadows in the forecasting models. An example of cloud shadow propagation error because of
unknown CBH is shown in Figure 5.
13
Figure 5 Cloud shadow propagation uncertainty error due to unknown cloud base height.
The letter ‘a’ and ‘b’ shown in the figure above depicts solar arrays
2.2.2 Cloud Based Height (CBH)
There are many methods for measuring CBH. A specialized device called a ceilometer is
recognized by the World Meteorological Organization (WMO) as the most accurate, reliable and
efficient means of measuring CBH from the ground when compared with alternative equipment
(World Meteorological Organization, 2008).
A significant find was made during the research phase of this project. An automatic weather
station with a VAISALA CT25K S/N - U01508 ceilometer was found. It is located at located at
the Jandakot Aerodrome, which is approximately 5km from the Murdoch University’s South
Street Campus. The ceilometer logs CBH measurements every 30 minutes and its data is made
freely available via the Bureau of Meteorology website (Bureau of Meteorology, 2015). More
importantly for the Sky-camera research project, these measurements can be accessed at a higher
time resolution for a small subscription fee. The reason this is a significant find is because the
data obtained from this ceilometer can be used to enable MU to research and validate novel Sky-
camera machine vision stereographic CHB measurement methodologies.
14
Currently, the Solar Energy Meteorology Group is working on Sky-camera configurations and
algorithms capable of deriving CBH measurements. One of the main reasons this project is
installing two Sky-cameras several hundred meters apart was to gain the ability to also take part
in this area of research and then later validate its results.
The general approach taken to derive CBH measurements using a Sky-camera technology is to
place geometrically calibrated two Sky-cameras several hundred meters apart as shown in Figure
6. This system would capture images of two different perspectives of a cloud simultaneously, then
utilise machine vision stereographic algorithms to rectify the images and derive the CBH
measurements using the offsets found from the different perspectives.
Common machine vision software packages are OpenCV, Matlab Computer Vision System
Toolbox and NI Vision.
Figure 6 Machine vision stereographic cloud base height measuring technology
15
2.2.3 Location 1 Engineering and Energy Building
The Engineering and Energy Building (EEB) as shown in Figure 7, is located in the Northern end
of the MU South Street Campus. It is home to the PV Training Facility designed by engineering
students as part of their fourth year coursework project. Later Stuart Kempin refined and oversaw
the implementation of the design as his final year engineering thesis project. The installation was
carried out by Sun Brilliance and Phase Engineering.
The overall system consists of five PV arrays using four different PV technologies:
polycrystalline, monocrystalline, CIGS (Copper Indium Gallium Selenide) thin film and
amorphous silicon. It has six different inverter models from three different manufacturers: SMA,
Fronius and Samil Power. The general arrangement of the training facility is shown in Figure 8.
The accumulated output capacity from these five PV systems is 8kW.
These systems were later connected to a DAQ system (EEPV DAQ) and programed using the NI
LabVIEW software. This system allows the PV system power output parameters such frequency,
phase angle, voltage and current to be measured at one hertz intervals and then logged into a
database as 10 minute averages. These measurements are obtained via a Modbus using Integra
1540 transducers system as well as a RS-485 start topography network that can communicate
directly with the inverters.
Figure 7 Outside view of the Engineering & Energy Building
16
Lastly, the EEPV DAQ system was being extended by other engineering students to also capture
meteorological parameters with the use of Advantech's ADAM 4000 modules. These parameters
include wind speed and direction, ambient and PV cell (each arrays) temperature and solar
irradiance measurements (one mounted horizontally and the other mounted on the plane of the
PV array).
Figure 8 EEB PV training facility inverter and DAQ system
Calais proposed mounting one of the Sky-cameras directly in the middle of the top rail of the PV
array located on top of the EEB, as indicated in Figure 9. This location appears to have a good
view of the sky and is conveniently accessible via the roof deck and a metal-grated walkway that
runs parallel directly behind the PV arrays. However, this top rail is slightly higher than arms
reach, which may complicate the maintenance of the Sky-camera due to the high risk of injury
when using a ladder on the roof. The plan also included having a new Ethernet access point
installed, and incorporating some of the EEPV DAQ system data into the new Sky DAQ system.
Figure 9 Planned Sky-camera location on the EEB roof
17
2.2.4 Location 2 Renewable Energy Power System
Demonstration and teaching facility (REPS)
Figure 10 Exterior view of the REPS facility
The REPS (Renewable Energy Power System) training facility as shown in Figure 10, is
incorporated into the Remote Area Power Supply (RAPS) display located just off Discovery Drive
inside the Renewable Energy Outdoor Test Area (ROTA). The REPS facility was built in 2009
with funding from the Australian Power Institute. The purpose for building this training facility
was to provide a space for students to study real power systems based on several technologies
that are all networked together to form a mini electrical power grid.
In general, the REPS facility’s mini power grid is created using independent PV and wind power
systems connected to grid-tied inverters that are coupled to an off-grid battery/generator Sunny
Island bidirectional inverter system. The Sunny Island bidirectional inverter manages the
frequency of this mini power grid network and dynamically alters the real power flow by utilizing
droop control algorithms (Castelli, 2010).
The DAQ system found in the REPS system was developed over many years using high-quality
National Instruments (NI) hardware and was programmed using the NI LabVIEW software. The
LabVIEW front panel of the system is shown in Figure 11.
The REPS facility offers all the tools necessary to study and validate the Sky-camera based PV
power output forecasting techniques and performance.
18
Figure 11 Overview of the system display screen from the LabVIEW DAQ system
The systems found in the REPS facility are:
1. A PV array (16 Solarex PV 77Wp modules = 1.232 kWp);
2. A SMA ‘Sunny Boy’ SB1100 inverter for the PV component;
3. 2 wind turbines (a SOMA, 2 bladed, 1kW turbine, and a Fortis Passaat 3 bladed, 1.4kW
turbine).
4. An SMA ‘Windy Boy’ SB1700 inverter for the wind component. At any one time only one
wind turbine is connected (via individual protection boxes with rectifiers and dump load
controllers) to the SB1700 inverter.
5. The Sunny Island 5048 inverter.
6. 8 EXIDE Energystore 6RP1080 flooded lead acid batteries connected in series, which
produces a 48 VDC battery bank with a total rated capacity of 1080Ah at the C100 rate. The
battery bank has been designed for 3 days storage (based on the summer load of
9.6kWh/day) and a 60% maximum depth of discharge.
7. A diesel generator WTGS6800DE that is rated at 6.3kVA with a power factor of 0.8. The
generator is single phase and operates at 240V/50Hz with an electric start.
8. Various AC loads including a UPS system for the data acquisition system.
9. A data monitoring and logging system consisting of SMA Sunny Webbox and Sensorbox as
well as a custom designed data acquisition system using isolation amplifiers, NI data
acquisition cards, and LabVIEW software.
19
Calais proposed mounting one of the Sky-cameras on top of a large metal box situated on top of
an old sea container inside the ROTA, approximately 30m away from the REPS facility, as
indicated in Figure 112. This location was chosen partly because it has a more or less unobstructed
view of the Sky. But more importantly, the location is safely accessible via a simple steel ladder
leading to a steel platform with a parameter railing system and is in close enough proximity to the
REPS DAQ system.
Figure 12 proposed location of the Sky-camera in the ROTA
The main challenge identified for this site was the lack of a MU Ethernet network assess point.
However, Mr. Stirling found that it is within range of the university Eduroam wireless network
with an estimated bit transfer rate of up to 22 Mbits/s. It is believed this rate is fast enough for
transferring the 300kB images within 10 secs. Furthermore, Mr. Stirling also discovered a 240V
electrical power receptacle inside the metal box thus allowing a wireless bridge access point
receiver to be installed (Calais, 2015).
21
Chapter 3 Hardware
3.1 Hardware Selection
The hardware components were deliberately chosen to match the UoO’s Sky-camera system. The
equipment selected are; two Vivotek FE8174V omnidirectional cameras: a Dell Precision T1700
MT Server: and an EKI 6311GN-AE Wireless Access Point, which was selected to bridge an
Ethernet network gap for one of the Sky-cameras, as shown in Figure 13.
This equipment was purchased prior to the beginning of this thesis project. When the project
started, it was found that the two Vivotek FE8174 cameras did not include a power supply. This
is because they are networked cameras that can be powered by either using an external power
adaptor, or more commonly by the network itself using Power over the Ethernet (PoE) technology
(VIVOTEK, 2015).
Figure 13 Initial system layout design and equipment selection
22
3.2 Hardware Purchase
3.2.1 PoE Injector Purchase
Vivotek FE8174V cameras are a robust. They are designed to be used in an outdoors environment
and are relatively well sealed using a high-quality cast aluminium frame and rubber seals
(VIVOTEK, 2015). However, they are not intended to be used facing upwards towards the Sky
in an outdoors environment. It was found that utilizing the PoE Ethernet connection method
would reduce the risk of water intrusion. This is because using the PoE technology will reduce
the number of wires coming out of the camera casing as well as allowing all the wires to go
directly through a centre bolt, making all wires completely sealed from the outdoor environment.
A picture showing the wire passing through the bolt arrangement is shown in Figure 50.
PoE is technology that transmits power to a device using several methods, but more commonly
via one or both of the unused twisted pairs of wires found in the 10BASE-T and the 100BASE-
TX Ethernet cables. Two IEEE standards are created for PoE. These are the 802.3af and the
802.3at. Each standards lists several classes of devices that differentiate their power ratings. An
online research revealed that the common PoE devices used for powering of cameras are an inline
PoE power injector, or a PoE Network Router, or PoE Network Switch.
Finding a PoE power transmitting device suitable to power the Vivotek FE8174V camera was not
straight forward. Consideration needed to be given to the price, the environment, the power
transmission range, data transfer rate and the fact that the Sky-camera had a 48V, IEEE 802.3af
rated, Class2 PoE device requirement (VIVOTEK, 2015).
The Vivotek help centre was contacted for their advice on selecting the right powering device for
the sky-cameras. See Appendix A - Email Correspondences for more details.
A PoE injector device was selected for simplicity and cost reasons. The TP-Link model TL-
POE150S was found to meet all of the sky-camera requirements. Furthermore, it was a simple
plug-and-play PoE injector suitable for data transfer speeds up to1000Mbps with auto-negotiation
circuitry that is capable of powering a device up to 100m away (TP-LINK, 2016).
23
At first a single TL-POE150S was purchased. The result of this purchase was successful. It
powered the Sky-camera as expected and its installation was very simple. It did not require any
tools nor needed to be configured. Consequently, a second unit was ordered shortly afterwards.
3.2.2 Sun Tracker Purchase
Purchasing and installing a sun tracker was not part of the original scope. However, as described
in section 2.1.3, a DAQ system needed irradiance measurement sensors. Calais suggested
purchasing a SOLYS 2 because its ease of installation and mobility features made it a perfect tool
for many research applications, including the Sky-camera research project.
The SOLYS 2 is a highly precise belt driven solar tracker manufactured by Kipp & Zonen B.V.
It comes with an embedded computer system that has an integrated GPS and compass system
(Kipp & Zonen, 2011). The SOLYS 2’s key feature is that it can automatically track the sun
without requiring any other sensors or external links. In simpler terms, it is a plug-and-play solar
tracker. The purchase was made on the 16/09/2015
3.2.3 Sky Camera Calibration
A Sky-camera calibration is essentially a mathematical model of the omnidirectional camera lens.
Having this model allows rectification of the images using machine vision functions and
algorithms, which is a necessary step for obtaining CBH measurements.
The calibration of the Sky-camera was performed inside Building 190, which is shown in Figure
3 on page 9 as location 2 on the campus map. The method used to derive the mathematical model
for the camera lens was an automatic corner extraction function and image un-distortion function.
These functions were found in a freely available MATLAB toolbox called OmniCalib
(Scaramuzza, 1999).
24
In general the calibration process is as follows. The calibration process begins by printing a
pattern onto an A3 sheet and gluing it to a light weight rigid flat surface. For this project an
aluminium plate was used. Then at least ten images are taken by the camera of this plate at various
angles and distances away from the camera to provide different perspectives of the pattern, as
shown in Figure 14. Using the functions found inside the OmniCalib toolbox, the camera lens is
modeled from each corner found in the patterns in the images, as shown in Figure 15.
Figure 14 Images from the
Calibration process
Figure 15 Picture of the Automatic corner extraction
and an undistortion function
25
Chapter 4 Installation
4.1 Sky-camera 1 Installation
Calais initially planned mounting the Sky-camera on top of a PV array frame located on the
rooftop of the MU EEB. This location was chosen primarily due to it being conveniently
accessible by the building elevator, and because of its proximity to a few research PV systems
connected to a DAQ system (Calais, 2015).
When this project began, an initial site investigation and analysis was performed. It was found
that the EEB rooftop location was not a good as good as it was originally thought. An intensive
search to find a better location followed but failed to find a better place. Consequently, the EEB
roof top was again investigated, whereby a more suitable location was identified.
This new location required a new custom made folding Sky-camera mounting system. This
mounting system was designed, built, installed and commissioned in-house by Mr Bolton and
other MU staff members. The installation of the EEB Sky-camera was completed and since June
5th has been actively taking pictures. These pictures have been validated by the UoO. However,
temperature and solar irradiance data has not been obtained by the EEPV DAQ system due to a
lack of sensors.
By going outside the scope of this project in an attempt to provide the missing data, a SOLYS 2
solar tracker was purchased, installed, and commissioned. The installation of this system also
required the purchase, the installation and commissioning of a new Ethernet network switch, a
data logger, and connection module. Furthermore, pyrometers were obtained and connected with
the generosity of Dr. Pryor and the help of Mr. Glenister.
The learning outcomes from the Sky-camera 1 installation was a more in-depth understanding of
the parameters affecting a Sky-camera’s field-of-view as well as firsthand experience working
with a SOLYS2 solar tracker and its sensors.
26
4.2 Sky-camera1 System Installation
4.2.1 Sky-camera1 Site Investigation
The approach taken to study the EEB Sky-camera location was to firstly assess the field-of-view
requirements for a Sky-camera system. This was initially done using a solar pathfinder and later
by using a laptop and a mobile apparatus to take pictures using the Sky-camera itself.
The field-of-view shown by the solar pathfinder reveals some trees in the east and an elevator
shaft in the west encroaching in the solar path, as shown in Figure 16. These may not pose
significant problems for a PV system, but could dramatically reduce the forecasting time for the
Sky-camera system. This is because a Sky-camera system tracks cloud movements. Therefore, it
must have a line of sight of the clouds over the trees and around the elevator shaft.
Figure 16 SkyCAM1 Field-of-view investigation using a
solar pathfinder (Calais, 2015)
27
Another challenge created by this location was the positioning of the camera: it was on top of the
PV array frame, which was beyond arms reach, it was perhaps exposed to a lightning strike, it
created a maintenance challenge, and it must have electrical conduits installed for routing the
wires between it and the building.
Lastly, the EEPV DAQ system was not fully functional or commissioned. IN addition the EEPV
DAQ system lacked solar irradiation sensors, wind speed and direction sensors, and temperature
sensors. However, it is currently being modified by engineering students and great progress is
being observed. It is believed this system may become fully functional in the near future.
Under normal circumstances, this location would be deemed unsuitable for placing a Sky-camera.
However, an intensive investigation failed to find a more suitable location. This is because the
accessibility to the PV system parameters from 4 separate PV systems, and the accessibility of
the roof-top itself made it too great of a case to dismiss. Additionally, a new location on the EEB
roof top was found that significantly improved the field-of-view of the Sky-camera
Figure 17 Field-of-view from the new location on
the EE building
28
The new Sky-camera location was next to the PV arrays, on the top corner of a lean-to roof, still
on top of the EEB roof but nearly due North of the elevator shaft. This new location eliminated
the need for electrical conduits, reduced the risk of a lightning strike, and allowed for a folding
mounting system to be attached to a wall which could be safely lowered for maintaining the Sky-
camera. Additionally, a better view of the skies was achieved from this location because it was
slightly higher and farther away from the trees, as shown in Figure 17.
Another interesting benefit of choosing this new location for a Sky-camera was the fact that it is
nearly due North of the elevator shaft. It was found that from this location, the elevator shaft no
longer obstructed the Western view the skies. This is because geometric conditions allow the Sky-
camera to see on either side of the elevator shaft from the perspective of the Sky-camera, the
clouds traveling Northwards will have a longer travel time in the field-of-view of the camera
before they intercept the sun’s path. This effect is shown in Figure 18.
Figure 18 Solar geometry
4.2.2 Sky-camera 1 Mounting System Design
The requirements for the new Sky-camera mount were such that: it had to be fastened to a wall,
had to be foldable, had to be constructed using high-quality materials, has to provide shielding to
the Ethernet wires and, has to be sturdy enough to prevent the camera moving and yet allow the
camera to be rotated and levelled.
29
The use of Autodesk Inventor® software enabled a three-dimensional model of the system to be
created and virtually tested for design validations. The final design shows a long square aluminum
tubing inside a channel that is hinged at the bottom as shown in Figure 19. The Ethernet wire is
shielded because it is made to run inside the square tubing and through the walls at the bottom.
At the top of the square tubing there is a bolt with a hole in its centre axis to allow the camera to
be rotated 360 degrees and shield the wire between the square tubing and the camera. The camera
itself is mounted on a level table plate, which is leveled using three threaded bolts and nuts.
The construction of the Sky-camera mount was done in-house inside the EEB workshop by Mr.
Bolton. Slight modifications were made to improve the overall design, such as a support arm was
added to hold the mounting system level when it is placed in its the horizontal position.
Figure 19 3D model of the EEB Sky-camera mounting system
30
4.2.3 Sky-camera 1 Hardware Installation
The installation and commissioning of this new mount system occurred on the 14th of April. It
took approximately a day and also involved running wires through the wall and roof of the lean-
to structure. Pictures of the construction are shown in Figure 20.
Figure 20 EEB Sky-camera Installation picture
4.2.4 Sky-camera1 SOLYS2 Installation
It was decided to install the SOLYS 2 on the roof of the EE building under the direct supervision
and expertise of Mr. Glenister. The assembly of the Solys2 was surprisingly straightforward and
was completed on the 21st of April. A picture of the installation process is shown in Figure 21.
In general, the supporting frame must be aligned due East by its reference mark, then mounting
the main body on its supporting frame pointing in that direction. The whole unit is then leveled
using adjustment screws, and the remaining attachments are fastened. Once everything is in place,
the SOLYS2 is activated simply by plugging it into a 240V mains power supply.
31
When the SOLYS2 was initially powered it underwent a calibration phase. This phase lasted
approximately 5 minutes after which this device began tracking the sun. The commissioning of
this device was not completed due to time constraints. However, on a sunny day, the SOLYS2’s
orientation can be fine-tuned using the three mounting screws and the sun pilot hole located on
the Thermopile mounting bracket. Finally some shade balls can simply be assembled and adjusted
via the sets screws on the support frame (Kipp & Zonen, 2011).
Figure 21 SOLYS2 installation with Mr. Glenister
32
4.3 Sky-camera 2 Installation
4.3.1 Sky-Camera 2 Installation Overview
Calais initially proposed mounting one of the Sky-cameras on top of a large steel box located on
top of an old sea container at ROTA. However other considerations had to be made.
When the project began, considerations given to maintenance, vandalism, network connectivity,
power supply, accessibility of the PV system and meteorological measurement data risks were
assessed. The result of this analysis was in favor of this proposed location.
The complete installation also included PoE injectors and a Wi-Fi access point device. The plan
created for this Sky-camera was to place the majority of the equipment inside the big steel box
and mount the Sky-camera on top of it.
A new Sky-camera mounting system was virtually prototyped again using Autodesk Inventor®
and later constructed using in-house staff and facilities.
The simplicity of the final mounting system made its installation very simple and quick. The Sky-
camera has since been configured and has been taking pictures since.
33
4.3.2 Sky-camera 2 Site Investigation
The approach taken to study the Sky-camera location at the ROTA was again to firstly assess the
field-of-view requirements for a Sky-camera system. This was initially done using a solar
pathfinder but later with the use of a laptop and a mobile Sky-camera apparatus. Pictures were
taken using the Sky-camera itself and sent to the UoO for their review and comments. The
cameras field-of-view was found to be very good at this location, as shown in Figure 22. However
others factors such as the DAQ system and security remained to be investigated.
Figure 22 A Sky-camera test picture from the ROTA location
The ROTA area is fenced and usually locked during the weekends. Vandalism was considered
to be a risk because this area is often unattended, and has a history of equipment being vandalized
or stolen. Furthermore, the location of the Sky-camera itself is not restricted during the week and
can be easily accessed by any person. However, risk mitigation measures were possible, such as
locating the majority of the equipment inside the big metal box.
34
The REPS facility has a working data acquisition system for logging PV and wind power system
inputs and outputs, as well as environmental parameters. However, this system was unreliable
due to an unstable power supply and the data acquisition program being unfinished. The cause
for the blackouts was found to be due to the REPS facility’s power and data acquisition system
relying solely on an off-grid power system with an aging battery bank. As described in section
2.1.4. The UoO’s high data availability rate requirements makes this unreliable power source a
problem for the new Sky-camera system. For this reason, as well as security, other potential sites
such as the roof of the algae farms, on top of a sea container near the concentrated PV power
system farm, and others were investigated.
By the end of April, it was realized that the delay caused by this investigation had reached a point
that may jeopardize the outcome of this project. It was noticed that by this time, an extension lead
was placed between the REPS facility and the neighboring building providing it with a constant
power supply that enabled various groups of industrial computer system engineering students to
make significant improvements to the data acquisition system. Furthermore, it was also noticed
that the Sky-camera makes a shutter sound every ten seconds, every time it takes a picture. This
was believed to significantly mitigate the risk of vandalism.
During the March 31st weekly progress meeting, the decision was made to install the Sky-camera
at the originally planned location.
4.3.3 Sky-camera 2 Mounting System Design
The first task taken in the design process was to confirm the site was suitable for the UoO’s
computer algorithm. Once the UoO confirmed the site was suitable for a Sky-camera, the general
arrangement plan design phase started.
35
It was decided to install the Sky-camera in the upper right corner of the metal box. The EKI-
6311GN is an expensive piece of equipment and has flashing LED indicators on its housing.
Because the ROTA has had a history of occasional vandalism and these lights may attract
unwanted attention, it was decided to install the EKI-6311GN inside the large metal box and have
it’s antennae extended using an antenna extension kit. This arrangement is shown in Figure 23
Camera installation plan for the ROTA location.
Figure 23 Camera installation plan for the ROTA location
Once the general the design requirements were defined, the camera mount itself had to be
designed with the following requirements:
1. Have the least amount of penetrations through the metal box
2. Allow the camera to be easily rotated for alignment purposes
3. Allow the camera to be easily leveled
4. Be constructed using weather resistant materials
5. Protect the camera electronics and metal box from water intrusions
The new Sky-camera mounting system for this location was again created with the Autodesk
Inventor® software, as shown in Figure 24. This software enabled a three-dimensional model of
the system to be created and virtually tested for design validation.
36
Figure 24 Virtual prototype of Sky-camera mounting system using Autodesk Inventor
software
A two-dimensional plan for the fabrication of the mounting system was created using the virtual
prototype and Autodesk Inventor ® This plan is shown in Figure 25.
Figure 25 Custom Sky-camera mount design fabrication plan
37
4.3.4 Sky-camera 2 Hardware Installation
The custom made mounting system for the camera made the overall installation of the Sky-camera
very simple. It only required a single 18 mm hole to be drilled on the top of the metal box, then
twisted to the correct alignment and leveled using the three leveling screws. However, before the
new mounting system could be installed, the top surface of the box had to be repainted due a
heavy corrosion problem. The task of removing the rust, sanding the metal, then applying a new
coat of primer and acrylic paint was performed with the help of Mr Glennister. The camera was
installed on the 3rd of May 2016. The construction pictures are shown in Figure 26.
The installation of the wireless access point device was relatively straightforward. It only required
an antenna adaptor to be purchased and custom made angle iron brackets to be fabricated.
Similary to the Vivotek FE8174V, the Eki-6311GN is powered using a PoE injector. However,
this adaptor was supplied by the manufacturer and does not appear to follow the IEEE standard.
It is 15V and allows for a maximum distance of 20 meters (Advantech, 2015).
Figure 26 Pictures of the Sky-camera installation at the ROTA location
39
Chapter 5 Network
5.1 Overview
The MU Ethernet network infrastructure is a vital part of the MU Sky-camera project. This is
because it serves as the only communication link between the Sky Server, the Sky-cameras, and
the DAQ systems. It is also the connection link to the World Wide Web (WWW); which
ultimately links MU’s data with the UoO research algorithms and software. Furthermore, the data
transfer rate from the MU Ethernet with TCP/IP and NTP protocols makes it possible to reliability
synchronize to less than a second, the different Sky-cameras and the DAQ systems for performing
intra-hour PV output forecasting with Cloud Base Height measurement research.
This part of the project was the most complicated part of the project, and the source of the majority
of the problems found when progressing with this project. Consequently, the constraints from the
management side of this network changed the original design of a single coherent Sky network
to a more disjointed network type. None the less, a functioning network became available that
meets all the objectives set out in the original SOW.
5.2 Sky Server and network configuration
Calais had loosely proposed to have the server located inside Building 190 (B190). This appeared
to be a suitable location for the server because it was an out-of-the-way, dry and clean location
with an acceptable network connection access point (Calais, 2015). Furthermore, B190
conveniently has ongoing RE projects and was the place chosen for testing the Sky-camera
equipment.
40
When the server arrived, it was initially installed inside B190 in the testing area. There, Mr.
Glenister updated the Sky-server using the latest Linux Slackware1 OS system and installed the
necessary software for this project. Mr. Glenister was instrumental with this part of the project
due to his abilities in using this Linux OS as well as setting up DAQ systems. He created disk
partitions, added domains for added security, and began creating a cross-platform shared folder
directory for sharing the Sky-camera pictures across the network. The main challenge for this
location manifested only later when trying to configure an FTP service from the B190 connection
to the MU network.
It was assumed that as long as the server was installed on the University campus and was
connected to the MU network, then an FTP service to the World Wide Web (WWW) would be
easily obtainable. In order words, we believed the server could communicate directly with all the
devices such as the DAQ system and Sky-cameras connected on the network and then could also
connect directly to the WWW (See Figure 27).
Figure 27 Anticipated Sky-camera network configuration
1 Slackware Linux was originally developed by Linus Torvalds in 1991, known for ease of use and
stability (Hick, 2005).
41
The MU Ethernet network was not as allowing nor as flexible as it was expected. Without going
into too many details, the initial and anticipated network configuration was not possible due to
many network security reasons and device configurations. The solutions required to meet the
network restrictions were not trivial. The help of Mr. Stirling was instrumental and greatly
appreciated for finding ways to make everything work. These extra efforts included installing an
additional computer on the MU Staff network that allowed the Sky server to be accessed remotely
using the Windows remote access service.
Figure 28 Final Sky-camera network configuration
The solution was to place the Sky Server, the Sky-camera, the Solys2 and its logger on the MU
Staff network, as shown in Figure 28. Doing this enabled direct communication via subnet 88
and between the REPS DAQ system and the Sky Server. However, a communication challenge
remained since the EEPV DAQ was on the MU Student network. For obvious security reasons
the MU Student network is strongly isolated from the MU Staff Network. The final solution was
to establish a communication pathway between the EEPV DAQ system and the Sky Server
through an SQL database located on the student network. The security protocols used in this SQL
database provided read and write access to students and only a read access from the MU Staff
network.
42
For communication reliability reasons, all the Sky-camera devices connected to the MU networks
were assigned unique and logically static IP addressed configurations. Their MAC address was
also registered to the DHNS register in the event any of the devices are to be connected to another
location in the network. The last remaining connection challenge was achieved on the 27th of
May 2016, when Mr. Stirling finished configuring an exception for the public access firewall that
allows a UoO computer IP address to access a newly created FTP World Wide Web service.
43
Chapter 6 Software
6.1 Python Software for Linux
The software part of this project also experienced a significant amount of scope creep. Creating a
new computer program was only meant to be a minor part of this project. Instead of creating new
computer programs, Calais took a safer approach and organized for the UoO to supply an
equipment list and their computer codes.
The codes supplied by the UoO were written using the Python computer language and were
written for a Linux OS environment. Mirroring the computer environment to the UoO’s systems
was expected to minimize computer program development time and errors. This is because,
depending on the computer programmer’s skill levels, Python codes written in one OS
environment may not work properly in another OS environment. For example, the Python folder
directory paths written in a Linux environment uses the forward slash (/) as the separator symbol
between folder names whereas, a backslash (\) is used in a Windows environment (Sweigart,
2015). The Python codes supplied by UoO were written using Python 2.7 and required the Pillow1
and Numpy2 libraries to be installed.
The first problem occurred when trying to commission the Sky-cameras using the UoO’s Python
2.7 codes in a Windows OS environment that was expecting Python 3.4 codes. Python 3.4 was
installed because it was the latest release of Python. However, unknowingly, this version was just
the raw Python engine and was only accessible via the command prompt (CMD). It did not include
any of the required libraries or the expected software development kit (SDK) interface.
1 Pillow is a image processing library for Python 2 Numpy is a numerical processing library
44
When executing the Python codes from the CMD prompt window, nothing happened. Nothing at
all. No error messages or sounds. No matter how many times the codes were executed, nothing
happened. It quickly became apparent that without a proper SDK installed for testing the Python
codes, it was almost impossible to troubleshoot them.
It also became apparent there was a limited amount of support that the MU engineering faculty
could provide towards the use of Python codes for this project. This is due to the fact that the MU
School of Engineering does not teach Python and none of the faculty staff members are up-to-
date with Python codes.
The solution was to install PyCharm Edu. PyCharm Edu is a free open sourced educational SDK
for learning Python provided by JetBrains. The PyCharm Edu SDK integrates the Python CMD
console and, provides many advanced features such as: debuggers, code completion, code
inspection, code refactoring, version control integration, and includes interactive programming
tutorials (JetBrains, 2016).
In time, using the PyCharm Edu tools and its informative resources allowed for all the exceptions
and errors to be cleared and allowed he UoO codes to run successfully. Notable exceptions were
the urllib and urllib2 exceptions due to running Python 2.7 codes with a Python 3.4 engine and
the pip command not working in a Windows OS environment due to a missing Windows
environment shared variable. By the time the Python codes ran successfully on the Windows OS,
the Sky Server with the Linux OS was ready.
The Linux OS installed on the Sky Server was a Linux OS Slackware product. Slackware offers
a robust Linux server platform and inherently comes with Python 2.7 (Hick, 2005). It was believed
that once the server was ready, the codes could simply be executed. However, this was not the
case. It still required the pip function to be installed then be configured so it can automatically
download and install the Pillow and the Numpy libraries.
45
Navigating through the Slackware OS environment was found to be tough because it does not
provide a Windows-like graphical interface. To use it, one must learn to type Unix shell3
commands in a command window known as Bash (Lumens, 2012). Again, the MU School of
Engineering Faculty does not teach Linux and consequently the staff members seldom use Linux
shell commands. Learning to use the Slackware Linux OS to install and run the Python codes
was very time-consuming and posed an immediate danger towards the successful completion of
this project.
6.2 Temporary set-up
By 7th of April, some significant progress was made on the network and installation of the Sky-
cameras. Still nwithout being able to run Python codes on the Sky Server and wanting to perform
a test of the system, it was decided to create a temporary set-up on top of the EEB and write a
basic LabVIEW program that can acquire the images and some data.
3 A shell is a command-line user environment that provides a frame work for executing commands for
launching applications (Lumens, 2012).
46
Figure 29 Picture of the temporary setup. A waterproof box was used house the datataker
near the solar PV array where all the sensors were placed. An Ethernet connection
allowed the LabVIEW program to interface directly with the Datataker.
The space allocated for the temporary set-up on the EEB roof is shown in Figure 29. In a week’s
time the whole set-up was created. Then for two days, the basic LabVIEW program took pictures
from two Sky-cameras as well as logged data from a power inverter, from a thermopile
pyranometer and PV cell pyranometer, a PV cell temperature thermocouple and an ambient
temperature thermocouple. The LabVIEW program was also responsible for embedding the date
in the upper left corner, the timestamp in the top right corner, the Sky-camera name in the lower
left corner and finally the University’s name in the lower right corner, as shown in Figure 52.
The images and the data captured by the temporary set-up were sent to UoO for their review and
comments. A few days later, they replied indicating that the images were acceptable and provided
a short video of the image processing steps.
47
6.3 Making the change to LabVIEW
It was anticipated that using the Linux OS and Python codes would make it easier and quicker to
implement the Sky-camera system, but instead caused unintended delays. Deciding to make the
change to LabVIEW was not an easy decision because significant advances had already been
made on the Linux/Python system. Additionally, the University did not have a LabVIEW version
with an active license suited for a Linux OS. Therefore, a Windows Server OS license would be
required. However, when weighing all options, it was decided to convert everything to Windows
and LabVIEW.
The main factors which influenced the decision are as follows:
1. The MU Computer System Engineering Students are proficient using LabVIEW and
could provide valuable assistance for this project in the foreseeable future.
2. Similar to the first benefit, the LabVIEW program itself provides a state of the art
machine vision add-on (NI VISION). This module is seen as a valuable resource in the
area for applying stereographic triangulation and optical flow methodologies to the Sky-
camera research. The use of LabVIEW would allow the use of this module.
3. The majority of the MU computers are using a Windows OS. As a result, the MU IT
department, computer technicians, and other staff members are proficient with the
operations and maintenance required for this OS. This thought to increase the longevity
of the Sky Server.
On the 22nd of April, Mr. Stirling was given authorisation to begin making the necessary
conversions to the Sky Server. In general, Mr. Stirling, installed Windows Server 2012 OS,
LabVIEW, as well as performed all necessary file sharing and user domain configurations.
Conveniently, once the conversion was finished, a new prefered location was found for the Sky
Server on the 2nd floor of the EEB. There it was installed, re-commissioned and connected to the
MU staff Ethernet network on the 4th of May.
Having the Sky Server re-configured to a Windows OS Environment for a LabVIEW based
environment meant that work on the Sky-camera DAQ only began on the 7th of May with
realistically a little more than a month left to complete this thesis project.
48
6.4 LabVIEW Functions
6.4.1 Converting Python Codes to LabVIEW
The need for a new major LabVIEW program for capturing and processing the Sky Images was
a consequence of the difficulties encountered when implementing a Linux OS system using the
supplied Python codes. It was not an anticipated part of this project. However, it was a task in
need and assistance was possible.
The temporary set-up produced messy codes and that were not suitable for the Sky-camera DAQ
system. Wanting to do better, the new Sky-camera DAQ system project began by recreating in
LabVIEW all the essential functions found in the UoO’s Python codes. It is important to note
that a conscientious effort toward the design of the new LabVIEW codes was placed knowing
that they will be used by other students in the forseeable future.
All the new LabVIEW functions created work together to provide a working program. They are
designed to be used similar to the functions found in the LabVIEW block diagram Function’s
Pallet.
The first function rearranges the time the date and time into the desired format. Its input is a
timestamp variable and returns several formatted strings. These strings are used in the next
function to generate and return a formatted folder path format as requested by the UoO. The final
function uses an input HTTP Command as a string to get a picture from the Sky-camera on the
network and return a picture with an embedded timestamp and logo to the formatted folder path
derived by the previous function.
49
The coverted Python codes into LabVIEW results are shown Figure 30 below.
Time Management Function
Folder Path Management Function
Get picture Function
Figure 30 view of the LabVIEW front panel
6.4.2 Custom made Sky-camera image editing
software
An additional LabVIEW program was created to convert a Sky-camera image into a binary bit-
map-mask image. The main purpose of this binary map image is to reduce the image processing
time required by the UoO’s forecasting algorithms.
Creating a mask took a large amount of effort and may have errors. This is because all objects in
the Sky-camera’s field-of-view are required to have a pixel value of [0,0,0], whereas the rest of
the image have a pixel value of [255,255,255]. Creating this Mask using Photoshop or Gimp
requires expertise and care to make sure it created correctly. To make it easier for the next person
to make these Masks, a new photo editing program was created as shown in Figure 31.
The new program was created in LabVIEW using basic functions. However it became a very
complicated program because it required the use of multilayered event structure functions.
Furthermore, the buttons were customized to provide a more modern look to the program and
complicated codes were used for resizing the images to the drawing pad then translating the cursor
location to the image data.
50
The author found this little program to be a great tool for future researchers and therefore chose
to test, validate and develop this program till it was thought to be bug-free and compiled into a
.exe file so it can run by future users on any Windows computer or tablet even in the absence of
LabVIEW.
The Mask Maker program description
When launched, the user is prompted to select a jpeg file. Then once selected, the jpeg image is
resized according the window container size, the drawing pad and resolution of the monitor.
Several controls are provided and arranged according to the steps required to convert the image
into the correctly formatted binary map mask image. When the user moves the mouse cursor over
the drawing pad where the jpeg is shown, the mouse cursor changes to the shape of a pencil.
While the mouse cursor is in this shape, the user can simply left-click the mouse button and move
the mouse to draw the mask. To stop drawing, the mouse button is simply released.
The only colours available are black and white. Black is used to mask the objects, and white is
used for everything else. The Mask Maker program front panel display is shown in Figure 31.
Figure 31 Picture of the custom made Sky-camera image editing software
51
A special quick function called the ‘Add Frame’ function is created to shade all edges and corners
in one click; speeding the photo editing process significantly. Similarly, another quick function
called ‘Filter’ is created to apply the white colour to the rest of the image once the occluding
objects are drawn in black. The last special option provided is called ‘Erase all’ where it simply
erases all the changes made to the image.
Once the mask is created, the user simply clicks on the save button to save the mask image in the
correct file type. Examples of the Binary Bitmap Mask Image files created using this custom
made program are shown in Figure 32 and Figure 33.
Figure 32 Example of the EEB Sky-camera 1 Binary Bitmap Mask image files
Figure 33 Example of the ROTA Sky-camera 2 Binary Bitmap Mask image file. The circles
found in the binary mask image shown above are masking swept area of small wind
turbines.
53
Chapter 7 Data Acquisition System
7.1 Data Acquisition System Introduction
The MU School of Engineering has several large DAQ computer programs created and operating
using the NI LabVIEW software environment. The initial approach chosen for creating a new
DAQ system was to duplicate the existing DAQ program’s architecture, so that a single program
that encapsulates all the program functionalities of the DAQ system (Encapsulated Program
Architecture). However, while programming the new DAQ system program using this
architecture for the Sky-camera project, many problems were identified which led to the
abandonment of this program structure.
Instead, a different programming architecture was conceived,. Subsequent trial of this architecture
was susseful so it was ultimately chosen for creating the new Sky-camera DAQ system. For the
purpose of this thesis, the new program architecture has been named the Application based Data
Acquisition System (APP DAQ).
7.2 Initial Design And Its Problems
Figure 34 Illustration of the initially encapsulated program architecture used to create the
first version of the Sky-camera DAQ system
54
Figure 34 illustrates the Encapsulated Program Architecture on the left and the initial Sky-camera
DAQ system program created using this architecture on the right. The problems identified when
using this approach were related to the fact that the programs often go offline while programming
and were not flexible to changes. These problems were first noticed while programming the new
Sky-camera DAQ program itself but also later when questioning the reliability of the other more
developed programs using the Encapsulated Program Architecture such as the REPS DAQ system
and the EEPV DAQ system.
To investigate the reliability of the data capture rate from the REPS DAQ and EEPV DAQ system,
a simple SQL Query of the data availability rate from this system was executed on their SQL
databases. The result of the SQL Query is shown in Figure 35 and Figure 36.
Figure 35 Query results of REPS DAQ system showing data capture inconsistency
Figure 36 Query results of EEPV DAQ system program showing data capture
inconsistency
It is important to mention that many of the data points missing from the REPS DAQ system are
due to the aforementioned unstable power supply. However, the scattering of the points are
unlikely to be caused by the unreliable power supply but more due to students stopping and
starting the program when making improvements to the program.
55
Since the REPS DAQ, the EEPV DAQ and the new Sky DAQ will be using the Encapsulated
Program Architecture, it was decided to investigate further the cause and effects of missing data
points to the Sky-camera research project.
The result of this investigation revealed that the REPS DAQ and EEPV DAQ systems go offline
for many reasons. As mentioned before, the REPS DAQ system’s power supply is a contributing
factor, the complexity of the programs is another, but the main reason identified for both was the
fact that the DAQ programs were unfinished.
The most important revelation of this investigation was the fact that the programs were unlikely
to become finished. This is because they are being used for experiment and teaching purposes and
suffer from occasional change in equipment and functionality requests. By design, they were left
as open-ended projects running in the LabVIEW environment so they have the flexibility to be
modified as requested.
The potential for gaps in data from the REPS, EEPV, and the new Sky DAQ was presented to the
UoO for their comments. Their response was clear; they are used to work within a meteorological
observatory framework with a guaranteed data availability rate of 99.9%. They further explained
that their PVout forecasting algorithms relies on this guaranteed data availability rate, and gaps
in the data poses a danger to corrupt their results. Lastly, they mentioned that they do not like
filling gaps due to the extra efforts required and because filling gaps conceal the truth within the
data itself. See Appendix A - Email Correspondences for more information.
In light of the Encapsulated Program Architecture problems such as complexity, long
development time, and gaps in data, and wanting to meet the requirements set forth by the UoO,
an alternative DAQ system program architecture was investigated.
56
7.3 Different Program Architecture Trial
A new programming concept was realized on the 6th of June. The basic concept being that the
DAQ system program could be made from short independent programs communicating via a
shared variable dispensary such as the NI shared variable engine, a networked file, a database, or
similar. The Achitecture for this porgram architecture is shown in Figure 37
A hypothesis of this new DAQ system concept was formed such that a Computer program can
obtain a greater data availability rate when composed of many short programs (DAQ APPs).
Where these DAQ APPs are device or application specific short programs that communicate via
a network object1 remain independent2 in that they are not constrained to operate within a single
device or as a single instance of itself. It is also hypothesized that a computer program created
using the DAQ APPs will make programming the new Sky DAQ program simpler and quicker.
Figure 37 Illustration of an Application based DAQ system (APP DAQ) architecture
1 Networked objects are logical items such as a file within a shared folder, a networked databases table, a
shared variables engine variable, and etc… 2 Program Independence is one that can be started, stopped, installed, and removed at any time without
interfering the operations of another program.
57
The foreseen benefits for using the APP DAQ concept and approach are;
1. The Apps are quickly deployable using available (student) resource(s) and skillsets
2. Once deployed, the Apps run outside the LabVIEW program environment
3. A DAQ system created using Apps is easily and quickly scalable
4. The Apps provide unparalleled flexibility for future needs and requirements.
5. Apps can easily provide an uninterrupted DAQ system.
6. The Apps create a consistent program look for ease of navigation
7. Apps are simple. They reduce troubleshooting time and provide a higher degree of error
prevention
The methodology used for creating these DAQ APPs was to program each as separate LabVIEW
VIs in LabVIEW and use the NI Distributed System Manager (Shared Variable Engine) to serve
as the Network object and thus create program independence between each VI.
It was also decided to use an interactive programming development model as opposed to the
waterfall model. This model is particularly suited for developing the APP DAQ as it is still in an
experimental stage of development and a scope could not be exactly defined. Furthermore, this
model allows for greater flexibility, less planning, and quicker results when compared to the
waterfall development model.
To test the hypothesis, three DAQ APPs were created; a Sky-camera DAQ APP, a Sky Image
Photo Editor DAQ APP, and a Data Taker DAQ APP. Knowing that the finished Sky DAQ will
require more than 12 DAQ APPs in total, the front panels (DAQ APP Icons) were sized
accordingly (125pixel high and 300pixel wide) as shown in Figure 38.
The initial APP DAQ trial utilized a specially created LabVIEW VI that made use of the SubVI
container function to create a backplane and unified container for each DAQ APPs. Another
purpose for this backplane was to give the impression that all the DAQ APPs were part of a single
program. The user could then interact with the DAQ APPs individually via their individualized
front panel controls.
58
Figure 38 Initial DAQ system proof of concept trial for using un-compiled independent
short LabVIEW programs (Apps)
7.3.1 APP DAQ trial results
The first observation made from this new system architecture was that the appearance differed
from the other DAQ systems found on campus, arguably giving it a more modern look. The
original front panel can be seen in Figure 37
Technically, creating and running un-compiled DAQ APPs in LabVIEW would not work without
advanced programming skills. It was found they conflicted with one another as they shared
SubVIs. This problem could be mitigated by modifying the SubVI default property setting as
reentrant VIs, but doing this is troublesome, requiring consistency throughout the projects and a
high level of programming skills from future developers (students).
An additional problem presented itself when trying to modify a DAQ APP while it was running.
The program files were locked and prevented their modification. This problem also occurred
when attempting to duplicate the DAQ APP program files.
59
Results from Compiling the Apps
Compiling a DAQ APP was surprisingly simple. It was unlike prior experiences due to the fact
that a DAQ APP is a very simple short program. They are easily compiled in a matter of a few
seconds. However, a new problem was observed. Once launched, they disappear whenever a user
clicks on the backplane as it was also a separate and independent program. This problem was
found to be caused by the Windows operating system window container default hierarchy settings.
It was also found later that altering the window hierarchy settings of the DAQ APPs before they
were compiled did not completely eliminate the window hierarchy problem. Online research
about this problem revealed that to have the DAQ APPs displayed on the front panel as originally
intended; requires creating ActiveX controls and containers. This was also found to be too
troublesome; requiring consistency throughout the projects and a high level of programming skills
from future developers (students).
Although difficulties were found during the initial trial, an undeniable proof of concept was
observed. It was found that once a DAQ APP was compiled and executed, it simply ran by itself.
It was independent of LabVIEW and of the other DAQ APPs. The trial successfully proved that
it was, in fact, possible to develop a DAQ program in sections and run the sections while other
sections are being developed.
The trial also demonstrated that this new DAQ system is scalable. After creating the first DAQ
APP (SkyCam 1), it was cloned many times, and each instance of itself could be set to do another
task or, in this case, the same task in parallel with the original APP. This provided a very
compelling case for implementing this concept further.
The results from the proof-of-concept trial proved the concept to be viable. It confirmed that when
using a shared variable engine, each DAQ APPS could be started, stopped and restarted at any
times without interfering with the operations of other DAQ APP. Furthermore, it showed that the
concept was scalable, flexible and could foreseeably allow for the complete Sky DAQ system to
be created in this manner.
60
7.4 New App DAQ System Design and
Implementation
The APP DAQ computer program architecture was created with the following three basic
elements: the APP Variable Engine, the DAQ APP container and the DAQ APP icon and a DAQ
APP Settings Page, as shown in Figure 39.
Figure 39 Overview of the APP DAQ system User Interface
1. DAQ APP Variable Engine
2. DAQ APP Container
3. DAQ APP Icon
4. DAQ APP Setting’s page
The DAQ APP container
Figure 40 picture of the DAQ APP container title bar and four DAQ APPs below.
DAQ APPs (group of 4 Apps)
DAQ APP Container
Group
DAQ APP Container Title
Group
61
The APP Container’s only function is to provide a coherent structure to the Sky DAQ. The look
created by the APP Container is shown above in Figure 40. The APP Container contains special
codes to maintain the organization of the DAQ APPs and allows the user to move all the APPs at
once around the monitor screen by simply left clicking the mouse button anywhere on the APP
Container, and then dragging it to its new position.
The DAQ APP Container also provides a master stop control for stopping the execution of other
DAQ APPs on the network. This is being done by assigning the round button on the upper left
corner Boolean value to a Shared Variable.
A little checkbox on the right of the master stop button when clicked allows the DAQ APP
Container to be resized. Additionally, when it is resized downwards, the APP setting controls are
exposed, as shown in Figure 41. A color selection button is located next to the resizing check box.
It allows the user to change the color of the DAQ APP.
Figure 41 APP Container resized exposing the Variable Engine settings
The APP DAQ architecture is not bound to a single computer. It is scalable, flexible and modular.
It is then foreseen that multiple APP DAQ systems could coexist and operate on the same
computer, as shown in Figure 42. To provide a solution for this forseeable situation, a DAQ APP
container can be used to organize APP DAQs into subgroups by implementing separate Shared
variables for each DAQ APP containers, as shown in Figure 43. For example, all hardware DAQ
APPs could be arranged together forming a group, and all the User Interface DAQ APPs can be
arranged in another. Furthermore, since the DAQ APP variables can be networked across campus
via the Ethernet network, the groups are not limited to a single system.
Resizing the APP
container exposes the
Variable Engine Settings
62
Figure 42 Distributed APP DAQ topology
Figure 43 DAQ APP Container organizational solution for other DAQ APPs
Creating multiple DAQ
APP Container variables
allows groups of DAQ
APPs to follow different
DAQ APP Containers
63
DAQ APP
The programming approach taken is to design a device or application specific mini program to
include all controls into a single page forming a Settings page. Doing this allows a user to
configure the device dynamically as the program runs and may also allow a compiled APP
program to be reused for another device requiring similar functions.
The DAQ APP template uses a Test Executive-Style State Machine structure. The main benefits
of using a state machine programming methodology is that it adds an intelligent structure to the
program in order to reduce programing errors and the effort required for debugging them. The
structure created by the State Machine makes it easy to create program state monitoring functions
for error detection and then to create error handling states that the program can go in when errors
occur. In general, the codes in the active case structure will determine the next state to transition
to next (Bitter, 2007).
To make it easier for the next Sky DAQ system developers, an APP DAQ LabView was created.
Figure 44 LabVIEW APP DAQ template example 1shows the area where the next programmer
places the codes and Figure 45 LabVIEW APP DAQ template example 2 shows the area where
to place all the controls and indicators of the DAQ APPs.
Figure 44 LabVIEW APP DAQ template example 1
64
Figure 45 LabVIEW APP DAQ template example 2
The template creates three standard pages which are; the ICON PAGE, the SETTINGS PAGE
and the ERROR LOG PAGE. The State machine template controls the functionalities of the DAQ
APP and its different modes of operations.
ICON PAGE
The DAQ APP Icon Page is currently set to 125 pixels high by 300 pixels wide. Standardizing its
dimensions is not necessary but helps create a standardized structure and look to the overall
system. It is suggested that changes to these dimensions are to be made in multiples increments
of the above dimensions. Doing this will reduce the chance of disorder in the system layout. The
look of four DAQ APP ICON pages are shown in Figure 40.
SETTINGS PAGE
The SETTINGS PAGE is set as the default page when the DAQ APP initially launches. As its
name implies, the main function of this page is to configure the APP. There are three distinct
sections found on this page: the DAQ APP settings, the positioning of the DAQ APP within the
APP Container, and a dynamic APP documentation sheet, as shown in Figure 46 DAQ APP
Setting's page
This page comes in various sizes because it is sized according to the controls required by the
APP.
65
Figure 46 DAQ APP Setting's page
ERROR LOG PAGE
The ERROR LOG PAGE is a page where a user can get information in the event the APP is not
performing to expectation. As a DAQ APP develops, this page may also include trouble
shooting functions as well as error management control function. A basic ERROR LOG PAGE
is shown in Figure 47.Figure 47 Example of the DAQ App's ERROR LOG PAGE
Figure 47 Example of the DAQ App's ERROR LOG PAGE
66
7.5 Additional Programs Created
As discussed earlier, both the REPS and EEPV DAQ systems were created using the
Encapsulated Program Architecture. Before creating the new architecture, these programs were
modified to capture environmetal data for the Sky-camera project. Both the EEPV and REPS
DAQ system had a network DNS path configured for the ECL1 SQL database. Therefore, some
Sky-camera tables were created in the ECL1 database using a custom made LabVIEW database
utility program and Microsoft SQL Management Studio 2012, as shown in Figure 48 Sky-camera
database table.
Figure 48 Sky-camera database table
To capture and log the environmental data, a specialized LabVIEW VI program was created. The
VI capture the 1Hz data directly from the REPS DAQ and EEPV DAQ systems global variable
strings and process this data to the desired 10s format (AVERAGE, MIN/MAX and STD). The
VI then formats the data into a long SQL string that is sends it to the database. An example of
the code is shown in Figure 49.
67
Figure 49 Example of the two data logging VIs used for configuring and logging data into
an SQL database
69
Chapter 8 Results
This thesis project was a long and intensive project, but also achieved great results. Some minor
problems exist in the overall system and these are discussed in greater details below. However,
the Sky-camera network installation is now complete. Both cameras are installed, calibrated and
both are taking pictures in sync, which enables CBH measurement research as well as the
validation of Sky-camera forecasting research to begin.
8.1 Sky-Camera Research Results
Although researching the Sky-camera technology was only a minor part of the project Scope, it
helped understanding the specific installation requirements of this system. The level of success
obtained from this installation never would have been possible without an understanding of the
Sky-camera technology and without closely working with the affiliated University of Oldenburg.
The result from this liaison for technical advice, assistance, and validation of results fostered a
stronger and more open relationship with the University of Oldenburg.
Additionally, a significant finding was made during the research phase of this project. A
ceilometer located at the Jandakot aerodrome, approximately 5km away from the Murdoch
University South Street Campus was found and its owners were contacted. This ceilometer logs
a cloud base height measurement every 30 minutes, however for a small subscription fee, its
measurements can be accessed in near real time resolutions. This is a significant find because the
data logged by this automatic weather station are known to provide reliable CBH measurements
which will help validate the accuracy of future stereographic machine vision algorithms for
determining CBH measurements.
8.2 Sky-Camera Installation Results
The design, fabrication and installation of all camera hardware was a success. The folding camera
mounting system is very easy to use and stable enough for the camera. It was also very easy to
orient and level the cameras. The process of levelling the camera is shown in Figure 50.
70
Also note the Ethernet wire going through the centre of the 18mm bolt.
Figure 50 orientating and levelling the cameras
The Sky-camera calibration results were compiled into a report. The feedback from the UoO
about the calibration report was positive as shown in Figure 51. However, it is not known if they
have been used in the forecasting trials yet and it is likely that the calibration may need to be
performed again when deriving the CBH. Due to this potential, the MATLAB OmniCALIB tool
box is saved on the project folder and a guide was created to help the next person perform the
calibration.
Figure 51 Calibration report feedback from the University of Oldenburg
71
8.3 Sky-Camera Network Results
The Sky-camera network installation was successful, although not perfect. The FTP access
provided to the UoO also appears to be working well.
One of the main objectives for the network was for it to be able to capture images and data in a
synchronized manner. This objective was met using a NTP service and appears to be working
successfully. All the systems on the Sky-network appear to have a possible time error of less than
a second. The only exception being the Sky-camera project computer having a root dispersion of
over one second. This may be due to the NTP service not having had enough time to synchronise
to this computer, but this was not investigated further because the synchronisation requirement
for this computer is not needed.
The main problem experienced from the network installation comes from the wireless network
bridge. For unknown reasons, it fails to reconnect after a power failure. The effects of this are a
loss of images. Possible solutions are to install an uninterrupted power supply, use another power
source, and perhaps adding a simple time delay circuit to the system. Mr Stirling found that the
wireless bridge does not connect to the network and goes into sleep mode when it does not detect
the camera. The camera has a longer boot-up time after a power failure than the wireless bridge.
Therefore, it is possible that the wireless bridge goes into sleep mode before the camera can
respond.
72
The results of the NTP server query for all computers and servers on the Sky-camera network are
given below:
Sky Server
C:\Windows\system32>w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 5 (secondary reference - syncd by
(S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.1215973s
Root Dispersion: 0.1875436s
ReferenceId: 0x8673FD0B
Last Successful Sync Time: 1/06/2016 1:19:36
PM
Source: dc2.ad.murdoch.edu.au
Poll Interval: 15 (32768s)
ICL1 DataBase
C:\Windows\system32>w32tm /query
/computer:eng-icl1 /status
Leap Indicator: 0(no warning)
Stratum: 5 (secondary reference - syncd by
(S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.1214142s
Root Dispersion: 0.2012964s
ReferenceId: 0x8673FD0B
Last Successful Sync Time: 1/06/2016 7:27:18
AM
Source: dc2.ad.murdoch.edu.au
Poll Interval: 15 (32768s)
Sky Project Computer
C:\Windows\system32>w32tm /query
/computer:eeproj-15 /status
Leap Indicator: 0(no warning)
Stratum: 5 (secondary reference - syncd by
(S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.1215973s
Root Dispersion: 7.9406719s
ReferenceId: 0x8673FD0B
Last Successful Sync Time: 1/06/2016 4:00:58
PM
Source: dc2.ad.murdoch.edu.au
Poll Interval: 15 (32768s)
REPS DAQ System Computer
C:\Windows\system32>w32tm /query
/computer:repspc2 /status
Leap Indicator: 0(no warning)
Stratum: 5 (secondary reference - syncd by
(S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.1215973s
Root Dispersion: 0.2059503s
ReferenceId: 0x8673FD12
Last Successful Sync Time: 1/06/2016 4:03:34
PM
Source: DC6.ad.murdoch.edu.au
Poll Interval: 12 (4096s)
REPS DAQ System Computer
C:\Windows\system32>w32tm /query
/computer:repspc2 /status
Leap Indicator: 0(no warning)
Stratum: 5 (secondary reference - syncd by
(S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.1215973s
Root Dispersion: 0.2059503s
ReferenceId: 0x8673FD12
Last Successful Sync Time: 1/06/2016 4:03:34
PM
Source: DC6.ad.murdoch.edu.au
Poll Interval: 12 (4096s)
EEPV DAQ System Computer
C:\Windows\system32>w32tm /query
/computer:eeproj-27 /status
Leap Indicator: 0(no warning)
Stratum: 5 (secondary reference - syncd by
(S)NTP)
Precision: -6 (15.625ms per tick)
Root Delay: 0.1215363s
Root Dispersion: 0.2277092s
ReferenceId: 0x8673FD0A
Last Successful Sync Time: 1/06/2016 3:52:42
PM
Source: dc1.ad.murdoch.edu.au
Poll Interval: 14 (16384s)
73
8.4 Python to LabVIEW conversion results
Making the change from Python for Linux OS to LabVIEW for Windows Server OS has led to
improved results. For example; it allows improvements to the codes to be made such as replacing
a time stamp string on the image with the MU logo, as shown in Figure 52, as well as creating a
custom made Sky-camera Image Editor Program for making a Binary map image, as shown in
Figure 31.
Figure 52 Modifation of Python codes for replacing a string with the MU logo
8.5 Sky-Camera DAQ Results
The new DAQ program architecture approach for creating the new SKY DAQ has now
consistently logged Sky-camera images and CSV data files now for nearly three weeks.
Additionally, it was found that the new architecture gave the program much more flexibility,
simplicity, and stability. Furthermore, the Sky DAQ program architecture was presented to
Associate Prof. Coles and permission was granted to begin converting the EEPV DAQ system to
it.
The volume of data that is being captured by the system also appears to be as expected. The Sky
DAQ server hard-drive was sized to allow for two years of contineous data capture. It appears
that the initial mathematical design calculation for sizing the Sky DAQ hard drive performed by
Mr Stirling will be accurate as long as the current estimated data capture rate of 1GB of data per
folder per day is maintained, see Figure 53 and Figure 54.
74
Figure 53 CSV files of PV system and environmental parameters
Figure 54 Sky Camera Data Capture Rate
Lastly, the data was sent for verification to and was later accepted by the UoO. As a result, they
have begun processing some image data sets and have provided a short video using the 19th of
April Sky image set. The video shown in Figure 55 was created in response to an email asking
for information about each step taken to create a Sky-camera based PV output forecast.
75
Figure 55 Picture of the video received from the 19th of April Sky-camera image set.
a) raw Image
b) Orientation of camera ( sun position, image centre )
c) Red-Blue-Ratio RBR ( Red Channel / Blue Channel )
d) Cloud mask with cloud motion vectors
e) RBR histogram I use for selecting the threshold
On the 17th of June the UoO sent back some actual solar irradiance forecast results using the 25th
of May Sky-camera image dataset, and one of the Sky-image Binary Map Mask created using the
custom made program, as shown in Figure 56.
Figure 56 Solar irradiance forecast using new the new MU Sky-camera system
77
Chapter 9 Conclusions and Future Works
This project finished in late June of 2016. The primary objective for this project was to provide
Murdoch University with the means necessary to begin research and validation work in the area
of Sky-camera forecasting technologies. The outcome of this project showed that creating the
intended Sky-camera network and DAQ system was actually much more complicated than
originally anticipated, but none the less one that was achievable.
The project experienced large deviations from the original project plan set forth by Calais, but
continued to progress through each barrier till the results at least met or superseded the original
intents of the project plan.
The new Sky-camera network system and infrastructure are now at the point where research can
effectively begin and continue thereafter. Both, the Sky-camera locations and its hardware are
all built using quality materials fit for a permanent Sky-camera research installation. Furthermore,
the network and its access points and DAQ system are all designed and configured to be flexible,
dependable, and scalable enough to meet future research requirements and needs.
This project also involved working closely with several University Departments to find solutions
for many complicated and restrictive problems found when creating the network link between all
the devices. This close relationship fostered a higher level of trust and confidence which enabled
time sensitive decisions to be made. For example the swift replacement of the Linux OS to a
Windows Server OS and the installation of LabVIEW led to greater results and improvements for
the overall Sky-camera research project. This is because it laid the foundation for future MU
students to continue developing and/or research the Sky-camera technology.
Additionally, having demonstrated capability to successfully meet the UoO’s technical
requirements in the installation, the image quality and the overall performance of the new Sky-
camera system resulted in fostering a stronger relationship between the two Universities.
78
Finally, the Sky-camera project comes to an end. Handover documentation is provided as follows:
guide; a folder full of pictures and manufacturer’s datasheets; an organised folder of programming
files which include the custom made LabVIEW Sky-camera tools pallet; and the LabVIEW DAQ
APP template. Lastly, there are nearly 40 GB (and growing) of Sky-images and data that is being
captured at a rate of 2GB per day.
On a more personal note, I would like to thank you for reading the details of this project. It was a
wonderful thesis project to have worked on. I now feel satisfied that the Sky-camera network
installation is in the state which allows research to begin. I sincerely hope that MU will contribute
to the commercial implementation of this technology in the near future.
Thank you
9.1 Suggested Future Works
Continue developing the Sky DAQ system. This includes the design and installation of
the Solys2, a new Ethernet switch, and format the data capture CSV files using the
LabVIEW program.
Continue developing the EEPV DAQ system. This includes the following: purchase of a
new NI RS-485 modules, the installation of temperature sensors, a wind vane, a wind
anemometer, PV cell thermocouples, and solar irradiance sensors; and the continued
development of the EEPV APP DAQ system by creating more DAQ APPs for each
inverters and sensors.
Continue developing the REPS APP DAQ system. This includes mostly software
reconfigurations.
Fine-tune the Sky-camera colour and settings. Although the UoO’s feedback was
positive, they mentioned that Perth’s Sky to be of a darker shade of blue then their Sky
in Germany.
79
Determine the cause for the wireless access point for not reconnecting properly after
power outages.
Began testing the validity of the Sky-camera technology and publish papers of the
results
80
References
Advantech. (2015, 05 05). EKI-6311GN . User's manual .
author, N. (2008, 04 20). The cloud classification system. Retrieved from
http://www.australiasevereweather.com:
http://www.australiasevereweather.com/techniques/moreadv/class.htm
Bell, L. (2015, 09 02). Pilbara airport solar farm to trial 'cloud predictive technology'.
Retrieved from http://www.abc.net.au/: http://www.abc.net.au/news/2015-09-
02/karratha-solar-farm-to-trial-cloud-predictive-technology/6740860
Bitter, R. (2007). LabVIEW, Advance Programing Techniques. London: CRC Press.
Bureau of Meteorology. (2015, 11 23). Basic Climatological Station Metadata for JANDAKOT
AERO. Retrieved from http://www.bom.gov.au/:
http://www.bom.gov.au/clim_data/cdio/metadata/pdf/siteinfo/IDCJMD0040.009172.Sit
eInfo.pdf
Calais, M. (2015, 06 05). Sky Camera Installation at Murdoch University . SkyCamera
Installation at Murdoch University . Perth, WA, Australia : Internal Document.
Castelli, L. (2010). A Power Engineering and Renewable Energy Engineering training facility.
Perth : Murdoch University .
Domitrios, A. ,. (2015). PV energy yield nowcasting combining sky imaging with simulation
models. European Photovoltaic Solar Energy Conference (p. 5AO.7.2). Hamburg:
ELECTA.
Hick, e. a. (2005). Slackware Linux Essentials. Retrieved from slackbook.og:
http://www.slackbook.org/html/index.html
JetBrains. (2016). PyCharm Edu. Retrieved from jetbrains.com:
https://www.jetbrains.com/pycharm-edu/concepts/
Kipp & Zonen. (2011). Solar Instruments, Atmospheric Science Instruments and Wind Sensors.
Product Catalogue. Richmond, VIC, Australia: Kipp & Zonen B.V.
Lumens, C. e. (2012, 10 14). bash. Retrieved from http://docs.slackware.com/:
http://docs.slackware.com/slackbook:bash
Organization, W. M. (2008.). Guide to Meteorological Instruments. Geneva, Switzerland:
World Meteorological Organization.
PerformancePlus. (2015). Best practices for optimal PV performance. European Union:
PerformancePlus.
Scaramuzza, D. (1999). Omnidirectional Camera Calibration Toolbox for Matlab. Retrieved
from OCamCalib: https://sites.google.com/site/scarabotix/ocamcalib-toolbox
Sweigart, A. (2015). Automate the Boring Stuff with Python: Practical Programming for Total
Beginners. San Francisco: No Starch Press.
TP-LINK. (2016). tplink_tlpoe150s_poe_injector. Retrieved from http://www.tp-link.com.au/:
http://images10.newegg.com/UploadFilesForNewegg/itemintelligence/TP-
LINK/tplink_tlpoe150s_poe_injector_1452946137178.pdf
81
VIVOTEK. (2015, 08 12). FE8174V User's manual. Retrieved from www.vivotek.com:
http://download.vivotek.com/downloadfile/downloads/usersmanuals/fe8174vmanual_en
West, D. R. (2014, 09 30). Short-term irradiance forecasting using skycams: Motivationand
development. Science Direct. Mayfield West, NSW, Australia: ELSEVIER.
83
Appendix A - Email Correspondences
Vivotek PoE Adaptor Purchase Suggestions
84
UoO feedback for the Sky-camera calibration
85
UoO Sky-camera Background
86
87
UoO Sky DAQ Data Availability Rate
88
Appendix B - Sky-camera Calibration
Sky Camera Calibration Guide
Camera Calibration Instructions The calibration process is actually straight forward. This is because a very powerful
omnidirectional camera calibration MATLAB program is provided freely by the University
of Zurich. The calibration procedure is as follows:
1. Download the free Matlab tool box program crated by
Davide Scaramuzza from the link below:
https://sites.google.com/site/scarabotix/ocamcalib-
toolbox
2. Unzip the file
3. Locate and print onto an A3 sheet the grid pattern
located inside the folder
4. Glue the this sheet of paper onto a flat and rigid light-
weight surface
5. Take a minimum of 8 pictures from different angles
similarly to Figure 57
6. Give the pictures a simple name such as Pic1, Pic2
etc.. and paste these picture inside the same unzipped
OcamCalib folder
7. Open MatLab and change the folder directory so the
program can access the files and picture located
inside the same unzipped folder
8. Enter the command OcamCalib
At this point a navigation bar opens as shown in
Figure 58 below. This navigation bar is used similarly to reading a book, from left to right.
Once the calibration is completed individual steps can be redone or viewed again.
Figure 58 OcamCalib navigation bar
9. Click the “Read names” tab
10. Enter the name prefix “Pic” or your chosen name
Figure 57 Calibration pictures of Camera 1
using OcamCalib
89
11. Enter the file format “j” for jpg etc..
12. If you want the program to use all the pictures then simply press enter.
At this point the program will open the
pictures and process them. If everything
goes well and without any errors a new
figure as shown in Figure 57 will appears
that will show all of the pictures.
13. To continue, click on the “Extract Grid
Corners” tab from the navigation bar
14. Press Enter to process the corner
automatically
15. Enter the number of squares in the X
direction including the white squares
16. Enter the number of squares in the Y
direction including the white squares
Note: I found that it was better for the program if you told the program to look for one less square than the
actual number
17. Enter the dimension of the squares in the X direction
18. Enter the dimension of the squares in the Y direction
19. Then press enter several times for automatic operations.
20. Press on the “Calibration” tab to start the calibration At this point the program will
process all the pictures and display them as shown in Figure 59.
21. Lastly to view the results or make adjustments and refinements, simply press on the
other tab in the navigation bar.
Figure 60 Calibration
Result Graph
Figure 61 Extrinsic
Graph Results
Figure 62 Errors
Graph Results
Figure 59 OCamCalib Processed and calibrated picture
90
Calibration Reports
Calibration Report for Camera 1(MAC0002D1378D25) #polynomial coefficients for the DIRECT mapping function (ocam_model.ss in MATLAB). These are
used by cam2world
5 -6.729529e+02 0.000000e+00 7.861248e-04 -6.958132e-07 6.406799e-10
#polynomial coefficients for the inverse mapping function (ocam_model.invpol in MATLAB). These are
used by world2cam
13 970.600559 510.095710 -57.254997 88.220926 33.856589 -18.366293 52.722556 14.286719 -
62.581211 -16.589906 36.800844 24.933999 4.640822
#center: "row" and "column", starting from 0 (C
convention)
959.000000 959.000000
#affine parameters: "c" "d" "e"
1.000000 0.000000 0.000000
#image size: "height" and "width"
1920 1920
Centers average re-projection error computed for each
chessboard [pixels]:
0.93 ± 1.30
1.07 ± 1.54
1.34 ± 1.33
1.62 ± 1.75
1.33 ± 1.44
1.74 ± 1.47
1.54 ± 1.53
1.46 ± 1.43
1.50 ± 1.90
1.16 ± 1.45
Average error [pixels]
1.370059
Sum of squared errors
1764.733219
xc = 9.448216166400000e+02
yc = 9.632835993599999e+02
Figure 64 Camera 1(MAC0002D1378D25) Errors
Figure 63 Camera 1(MAC0002D1378D25) Calibration
results
91
Calibration Report for Camera 2 (MAC0002D1313914) #polynomial coefficients for the DIRECT mapping function (ocam_model.ss in MATLAB). These are
used by cam2world
5 -6.639601e+02 0.000000e+00 5.821525e-04 -2.275922e-07 3.465850e-10
#polynomial coefficients for the inverse mapping function (ocam_model.invpol in MATLAB). These are
used by world2cam
12 979.657569 547.661030 -13.824137 87.354972 37.811249 -0.053025 23.869848 10.526612 -9.525590
-1.291151 4.163354 1.325869
#center: "row" and "column", starting from 0 (C
convention)
961.488812 972.125796
#affine parameters: "c" "d" "e"
1.000000 0.000000 0.000000
#image size: "height" and "width"
1920 1920
Centers Average re-projection error computed for each
chessboard [pixels]:
0.35 ± 0.17
0.88 ± 0.48
0.32 ± 0.16
0.52 ± 0.31
0.39 ± 0.28
0.49 ± 0.23
0.53 ± 0.27
0.38 ± 0.21
0.42 ± 0.28
0.37 ± 0.17
0.68 ± 0.32
Average error [pixels]
0.484122
Sum of squared errors
154.517440
xc = 9.625475481600001e+02
yc = 9.730670591999999e+02
Figure 66 Camera 2 (MAC0002D1313914) Errors
Figure 65 Camera 2 (MAC0002D1313914) Calibration
results
92
Appendix C - Forecast Results
Below shows a one minute time series of images of the Sky-camera solar irradiance forecast.
93
94
