Cost Effective Panoramic Infrared...

University of Central Florida

Senior Design Design Report

Cost Effective Panoramic InfraredCamera

Authors:Laith Charles

Alejandro Drausal

Nicholas Gaor

Tyler Johnson

Supervisors:Dr. Samuel Richie

Dr. Orges Furxhi

Group Number 2College of Engineering and Computer Science

Sponsored by: St. Johns Optical Systems&

Applied Motion ProductsDecember 2014

http://www.ucf.edu/

http://eecs.ucf.edu/






Research Group Web Site URL Here (include http://)

Department or School Web Site URL Here (include http://)

Contents

Contents i

List of Figures viii

List of Tables xi

Executive Summary 1

1 Project Description 3

1.1 Project Motivation and Goals . . . . . . . . . . . . . . . . . . . . . 3

1.2 Project Requirements and Specifications . . . . . . . . . . . . . . . 4

1.2.1 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.2 Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.3 Operational Use . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.4 Relevant Software or Hardware Specifications . . . . . . . . 5

1.2.5 Interface and/or Compatibility . . . . . . . . . . . . . . . . 5

1.3 Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Initial Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4.1 September . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.1.1 Procurement . . . . . . . . . . . . . . . . . . . . . 8

1.4.1.2 Motor Interface . . . . . . . . . . . . . . . . . . . . 8

1.4.1.3 Camera Data Extraction . . . . . . . . . . . . . . . 8

1.4.1.4 Mechanical System . . . . . . . . . . . . . . . . . . 9

1.4.1.5 Host Server . . . . . . . . . . . . . . . . . . . . . . 9

1.4.1.6 Software Image . . . . . . . . . . . . . . . . . . . . 9

1.4.1.7 Calibrate focal point . . . . . . . . . . . . . . . . . 9

1.4.2 October . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4.2.1 PCB Design . . . . . . . . . . . . . . . . . . . . . . 11

1.4.2.2 Optical Communication . . . . . . . . . . . . . . . 11

1.4.2.3 Image Stitching . . . . . . . . . . . . . . . . . . . . 11

1.4.2.4 Implement Custom PCB . . . . . . . . . . . . . . . 11

1.4.2.5 Inductive Power . . . . . . . . . . . . . . . . . . . 11

1.4.3 November . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4.3.1 Housing . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4.3.2 Durability . . . . . . . . . . . . . . . . . . . . . . . 13i

Contents ii

1.4.3.3 Software Features . . . . . . . . . . . . . . . . . . . 13

1.4.3.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4.3.5 Aesthetics . . . . . . . . . . . . . . . . . . . . . . . 14

1.4.3.6 Presentation . . . . . . . . . . . . . . . . . . . . . 14

2 Research 15

2.1 Existing Panoramic Solutions . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Smartphones . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1.2 Film Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.1.3 Fisheye Panoramic . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.4 Digital Rotating Panorama . . . . . . . . . . . . . . . . . . 18

2.1.5 Comparison of Panoramic Solutions . . . . . . . . . . . . . . 19

2.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.1 Infrared Detector . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.1.1 FLIR A35 . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.1.2 DRS Tamarisk 320 . . . . . . . . . . . . . . . . . . 22

2.2.1.3 Sofradir PicoTM 384 . . . . . . . . . . . . . . . . . 23

2.2.1.4 Comparison of Cameras . . . . . . . . . . . . . . . 24

2.2.2 FPGA Hardware . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.2.1 Xilinx Spartan-6 . . . . . . . . . . . . . . . . . . . 26

2.2.2.2 Xilinx Artix-7 . . . . . . . . . . . . . . . . . . . . . 26

2.2.2.3 Xilinx Kintex-7 . . . . . . . . . . . . . . . . . . . . 27

2.2.2.4 Xilinx Zynq-7000 . . . . . . . . . . . . . . . . . . . 27

2.2.2.5 Arria V Family . . . . . . . . . . . . . . . . . . . . 27

2.2.2.6 Comparison of FPGAs . . . . . . . . . . . . . . . . 28

2.2.3 RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.2.3.1 Pin Grid Array . . . . . . . . . . . . . . . . . . . . 29

2.2.3.2 Ball Grid Array . . . . . . . . . . . . . . . . . . . . 30

2.2.3.3 DDR2 . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2.3.4 DDR3 . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2.4 Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.2.4.1 Servo Motors . . . . . . . . . . . . . . . . . . . . . 32

2.2.4.2 Stepper Motors . . . . . . . . . . . . . . . . . . . . 33

2.2.4.3 Stepper Motor Vs. Servo Motor . . . . . . . . . . . 34

2.2.4.4 Encoders . . . . . . . . . . . . . . . . . . . . . . . 35

2.2.4.5 Motor Driver . . . . . . . . . . . . . . . . . . . . . 36

2.2.4.6 Pricing Comparisons . . . . . . . . . . . . . . . . . 36

2.2.5 Wi-Fi Hardware . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.2.5.1 Embedded Wi-Fi Module . . . . . . . . . . . . . . 37

2.2.5.2 USB Wi-Fi Dongle . . . . . . . . . . . . . . . . . . 37

D-Link DWA-121 Wireless N 150 Pico USB Adapter . 38

2.3 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.3.1 Network Communication . . . . . . . . . . . . . . . . . . . . 39

2.3.1.1 Wired . . . . . . . . . . . . . . . . . . . . . . . . . 39

Contents iii

2.3.1.2 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.3.1.3 Radio . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.3.1.4 Cellular Network . . . . . . . . . . . . . . . . . . . 40

2.3.1.5 Network Communication Comparison . . . . . . . . 40

2.3.2 Motor Communication . . . . . . . . . . . . . . . . . . . . . 40

2.3.2.1 Inverted Motor Communication . . . . . . . . . . . 41

2.3.2.2 Optical Interface . . . . . . . . . . . . . . . . . . . 41

2.3.2.3 Slip-Ring . . . . . . . . . . . . . . . . . . . . . . . 42

2.3.2.4 Radio/Microwave Frequency . . . . . . . . . . . . . 43

2.3.2.5 Autonomous . . . . . . . . . . . . . . . . . . . . . 43

2.3.2.6 Comparison of Motor Communication . . . . . . . 43

2.4 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.4.1 Power Supply Unit . . . . . . . . . . . . . . . . . . . . . . . 45

2.4.2 Induction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.4.3 Solar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.4.4 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.4.5 Regulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.4.6 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.5 Mechanical System and Packaging . . . . . . . . . . . . . . . . . . . 50

2.5.1 Housing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.5.1.1 Water-Proofing . . . . . . . . . . . . . . . . . . . . 51

2.5.1.2 Temperature-Proofing . . . . . . . . . . . . . . . . 51

2.5.1.3 Wind-Proofing . . . . . . . . . . . . . . . . . . . . 52

2.5.1.4 Surge-Protection . . . . . . . . . . . . . . . . . . . 52

2.5.2 Camera Mount . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.5.3 Motor Mount . . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.5.4 Control Mount . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.6 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.6.1 FPGA Software . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.6.1.1 Xillinux . . . . . . . . . . . . . . . . . . . . . . . . 55

2.6.1.2 Arch Linux ARM . . . . . . . . . . . . . . . . . . . 55

2.6.1.3 Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . 55

Operating System Comparison . . . . . . . . . . . . . 55

2.6.2 Data Representation . . . . . . . . . . . . . . . . . . . . . . 55

2.6.3 Development Environment . . . . . . . . . . . . . . . . . . . 56

2.6.3.1 Xilinx IDEs . . . . . . . . . . . . . . . . . . . . . . 56

ISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Vivado . . . . . . . . . . . . . . . . . . . . . . . . . . 57

2.6.3.2 Altera IDE . . . . . . . . . . . . . . . . . . . . . . 57

SoC Embedded Design Suite . . . . . . . . . . . . . . 57

Final IDE Comparison . . . . . . . . . . . . . . . . . 57

3 Initial Design 58

3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Contents iv

3.1.1 Rotational Platform . . . . . . . . . . . . . . . . . . . . . . 58

3.1.1.1 Tamarisk . . . . . . . . . . . . . . . . . . . . . . . 59

Pin Layout . . . . . . . . . . . . . . . . . . . . . . . . 60

Data Out . . . . . . . . . . . . . . . . . . . . . . . . 61

Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Camera Control . . . . . . . . . . . . . . . . . . . . . 61

Power . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.1.1.2 Zynq . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Pin Configuration . . . . . . . . . . . . . . . . . . . . 62

MicroZed . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.1.1.3 Wireless Communication . . . . . . . . . . . . . . . 64

3.1.1.4 Inductive Coil Interface . . . . . . . . . . . . . . . 65

3.1.1.5 Platform . . . . . . . . . . . . . . . . . . . . . . . . 66

3.1.2 Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.1.2.1 Light Emitting Diodes . . . . . . . . . . . . . . . . 68

3.1.3 Base Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.1.3.1 Power Supply Unit . . . . . . . . . . . . . . . . . . 72

3.1.3.2 Battery . . . . . . . . . . . . . . . . . . . . . . . . 73

3.1.3.3 Voltage Regulators . . . . . . . . . . . . . . . . . . 74

3.1.3.4 Stepper Motor . . . . . . . . . . . . . . . . . . . . 75

3.1.3.5 Motor Driver . . . . . . . . . . . . . . . . . . . . . 77

3.1.3.6 Motor Controller . . . . . . . . . . . . . . . . . . . 79

3.1.3.7 Light Sensor . . . . . . . . . . . . . . . . . . . . . 81

3.1.3.8 Inductive Coils . . . . . . . . . . . . . . . . . . . . 82

3.1.4 Viewing Interface . . . . . . . . . . . . . . . . . . . . . . . . 83

3.1.4.1 Web Site . . . . . . . . . . . . . . . . . . . . . . . 83

3.1.4.2 Display . . . . . . . . . . . . . . . . . . . . . . . . 84

3.1.5 Hardware Flaws . . . . . . . . . . . . . . . . . . . . . . . . . 84

3.1.5.1 Computing PCB Flaws . . . . . . . . . . . . . . . . 84

3.1.5.2 Tamarisk Flaws . . . . . . . . . . . . . . . . . . . . 85

3.1.5.3 LED/Light Sensor Flaws . . . . . . . . . . . . . . . 85

3.1.5.4 Wi-Fi Communication Flaws . . . . . . . . . . . . 85

3.1.5.5 Inductive Power System Flaws . . . . . . . . . . . 86

3.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

3.2.1 Camera Communication . . . . . . . . . . . . . . . . . . . . 86

3.2.1.1 Setting Up UART on the Zynq . . . . . . . . . . . 88

3.2.1.2 Programming the UART . . . . . . . . . . . . . . . 88

3.2.1.3 List of Commands that will be sent to the camera . 89

Set rate of camera calibrations . . . . . . . . . . . . . 89

Gets rate between camera calibrations . . . . . . . . . 92

Set strength of ICE filter . . . . . . . . . . . . . . . 92

Set ICE min and max values . . . . . . . . . . . . . 93

Enable ICE mode . . . . . . . . . . . . . . . . . . . . 93

Contents v

Automatic calibration activity query . . . . . . . . . 93

Enable automatic calibration . . . . . . . . . . . . . . 93

Force in non-uniformity correction (NUC) . . . . . . . 93

Enable black-hot scheme . . . . . . . . . . . . . . . . 93

Enable white-hot scheme . . . . . . . . . . . . . . . . 94

Set Auto Gain Correction (AGC) mode . . . . . . . 94

Set AGC gain manually . . . . . . . . . . . . . . . . . 94

Set AGC level manually . . . . . . . . . . . . . . . . 94

Set AGC gain bias manually . . . . . . . . . . . . . . 94

Set AGC level bias manually . . . . . . . . . . . . . . 95

Set AGC region of interest . . . . . . . . . . . . . . . 95

Toggle auto-calibration . . . . . . . . . . . . . . . . . 95

Select video orientation . . . . . . . . . . . . . . . . . 95

Set non-volatile parameters . . . . . . . . . . . . . . . 96

Set non-volatile parameters to default . . . . . . . . . 96

Get values of non-volatile parameters . . . . . . . . . 96

Select digital video source . . . . . . . . . . . . . . . 96

Set baud rate . . . . . . . . . . . . . . . . . . . . . . 96

Get system status . . . . . . . . . . . . . . . . . . . . 96

Select test pattern . . . . . . . . . . . . . . . . . . . . 96


3.2.3 Motor Control . . . . . . . . . . . . . . . . . . . . . . . . . . 97

3.2.4 FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

3.2.5 Embedded Linux . . . . . . . . . . . . . . . . . . . . . . . . 100

3.2.5.1 Web Server . . . . . . . . . . . . . . . . . . . . . . 100

3.2.5.2 RTSP . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.2.5.3 Serial Com . . . . . . . . . . . . . . . . . . . . . . 100

3.2.5.4 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.2.6 Platform Communication . . . . . . . . . . . . . . . . . . . . 101

3.2.7 End-User Interface . . . . . . . . . . . . . . . . . . . . . . . 101

3.2.8 Network Access . . . . . . . . . . . . . . . . . . . . . . . . . 102

3.2.9 Output Protocol . . . . . . . . . . . . . . . . . . . . . . . . 103

3.2.10 Video Output . . . . . . . . . . . . . . . . . . . . . . . . . . 103

3.2.11 Image Processing . . . . . . . . . . . . . . . . . . . . . . . . 103

3.2.12 Software Flaws . . . . . . . . . . . . . . . . . . . . . . . . . 104

3.2.12.1 Camera Communication Flaws . . . . . . . . . . . 104

3.2.12.2 Motor Communication Flaws . . . . . . . . . . . . 104

3.2.12.3 Motor Control Flaws . . . . . . . . . . . . . . . . . 104

3.2.12.4 Embedded Linux Flaws . . . . . . . . . . . . . . . 104

3.2.12.5 End-User Interface Flaws . . . . . . . . . . . . . . 105

4 Final Design 106

4.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.1.1 Atom 1024 Camera . . . . . . . . . . . . . . . . . . . . . . . 107

Contents vi

4.1.2 Tiva 123GXL + CC3100 Wi-Fi Module . . . . . . . . . . . . 107

4.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109



4.2.3 Image Processing . . . . . . . . . . . . . . . . . . . . . . . . 111

4.3 Housing and Mounting . . . . . . . . . . . . . . . . . . . . . . . . . 111

4.3.1 Camera Mount . . . . . . . . . . . . . . . . . . . . . . . . . 111

4.3.2 Motor Mount . . . . . . . . . . . . . . . . . . . . . . . . . . 115

4.3.3 Control Mount . . . . . . . . . . . . . . . . . . . . . . . . . 116

4.3.4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

5 Construction Testing and Evaluation 119

5.1 Atom 1024 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

5.1.1 Testing the Camera Power . . . . . . . . . . . . . . . . . . . 119

5.1.2 Testing the Ethernet Connection . . . . . . . . . . . . . . . 119

5.1.3 Testing the Data Out . . . . . . . . . . . . . . . . . . . . . . 120

5.1.4 Testing the Sofradir Commands . . . . . . . . . . . . . . . . 120

5.2 Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

5.2.1 Making sure the physical motor works . . . . . . . . . . . . 120

5.2.2 Tiva C 123GXL + CC3100 Wi-Fi Module . . . . . . . . . . 120

5.3 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

5.3.1 I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

5.3.2 Software Unit Testing . . . . . . . . . . . . . . . . . . . . . 122


5.4 Power and Regulation . . . . . . . . . . . . . . . . . . . . . . . . . 126

5.5 System Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 127

5.5.1 Indoor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

5.5.2 Outdoor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

6 Administrative Content 129

6.1 Initial Milestone Discussion . . . . . . . . . . . . . . . . . . . . . . 129

6.1.1 August . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.1.1.1 Procurement . . . . . . . . . . . . . . . . . . . . . 129

6.1.1.2 Motor Interface . . . . . . . . . . . . . . . . . . . . 130

6.1.2 September . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

6.1.2.1 Camera Data Extraction . . . . . . . . . . . . . . . 130

6.1.2.2 Mechanical System . . . . . . . . . . . . . . . . . . 130

6.1.2.3 Host Server . . . . . . . . . . . . . . . . . . . . . . 131

6.1.2.4 Software Image . . . . . . . . . . . . . . . . . . . . 131

6.1.2.5 Calibrate Focal Point . . . . . . . . . . . . . . . . . 131

6.1.3 October . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

6.1.3.1 PCB Design . . . . . . . . . . . . . . . . . . . . . . 132

6.1.3.2 Optical Communication . . . . . . . . . . . . . . . 132

6.1.3.3 Image Stitching . . . . . . . . . . . . . . . . . . . . 132

Contents vii

6.1.3.4 Implement Custom PCB . . . . . . . . . . . . . . . 132

6.1.3.5 Inductive Power . . . . . . . . . . . . . . . . . . . 132

6.1.4 November . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

6.1.4.1 Housing . . . . . . . . . . . . . . . . . . . . . . . . 133

6.1.4.2 Durability . . . . . . . . . . . . . . . . . . . . . . . 133

6.1.4.3 Software Features . . . . . . . . . . . . . . . . . . . 133

6.1.4.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . 134

6.1.4.5 Aesthetics . . . . . . . . . . . . . . . . . . . . . . . 134

6.1.4.6 Presentation . . . . . . . . . . . . . . . . . . . . . 134

6.2 Budget Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

6.2.1 Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . 135

6.2.2 Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

6.2.3 Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

6.2.4 Misc. Supplies . . . . . . . . . . . . . . . . . . . . . . . . . . 135

7 Conclusions 137

7.1 Project Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

7.2 Personal Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 138

7.2.1 Laith Charles Conclusions/Reflections . . . . . . . . . . . . 138

7.2.2 Alejandro Drausal Conclusions/Reflections . . . . . . . . . . 138

7.2.3 Nicholas Gaor Conclusions/Reflections . . . . . . . . . . . . 138

7.2.4 Tyler Johnson Conclusions/Reflections . . . . . . . . . . . . 139

A Appendix 140

Bibliography 154

List of Figures

1.1 August Timeline 8/18-8/31 . . . . . . . . . . . . . . . . . . . . . . 7

1.2 September Timeline 9/1-9/14 . . . . . . . . . . . . . . . . . . . . . 7

1.3 September Timeline 9/15-9/30 . . . . . . . . . . . . . . . . . . . . . 8

1.4 October Timeline 10/1-10/14 . . . . . . . . . . . . . . . . . . . . . 10

1.5 October Timeline 10/15-10/31 . . . . . . . . . . . . . . . . . . . . . 10

1.6 November Timeline 11/1-11/14 . . . . . . . . . . . . . . . . . . . . 12

1.7 November Timeline 11/15-11/28 . . . . . . . . . . . . . . . . . . . . 12

2.1 Spinner 360 Camera . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Spinner 360 Film . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Fisheye Lens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Fisheye Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5 ScanCam Device Overview . . . . . . . . . . . . . . . . . . . . . . . 19

2.6 ScanCam Labeled Diagram . . . . . . . . . . . . . . . . . . . . . . 20

2.7 ScanCam Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.8 FLIR A35 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.9 DRS Tamarisk 320 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.10 DRS Tamarisk Image Enhancement . . . . . . . . . . . . . . . . . . 24

2.11 Sofradir PicoTM 384 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.12 Layout of the Zynq-7000 . . . . . . . . . . . . . . . . . . . . . . . . 28

2.13 Available FPGA options for the Zynq-7000 . . . . . . . . . . . . . . 29

2.14 Typical BGA Layout . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.15 Reprinted with Applied Motions Approval Chapter A.2 . . . . . . 37

2.16 LED Platform Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.17 Slip Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.18 Motor Power Delivery Block Diagram . . . . . . . . . . . . . . . . . 50

2.19 Rotational Platform Power Delivery Block Diagram . . . . . . . . . 50

3.1 Hardware Design Flowchart . . . . . . . . . . . . . . . . . . . . . . 59

3.2 Rotational Platform Dimensions . . . . . . . . . . . . . . . . . . . . 60

3.3 ST4 Tamarisk Pin Connection - Pending approval . . . . . . . . . . 60

3.4 Tamarisk Pin Connection . . . . . . . . . . . . . . . . . . . . . . . 61

3.5 DDR3 Configuration as seen by the Zynq Z7010-CLG225 . . . . . 63

3.6 DDR3 Configuration as seen by the RAM . . . . . . . . . . . . . . 63

3.7 Solidworks Platform Dimensions . . . . . . . . . . . . . . . . . . . . 67

viii

List of Figures ix

3.8 Tamarisk FOV illustration . . . . . . . . . . . . . . . . . . . . . . . 68

3.9 LED Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.10 LED Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.11 LED for PCB - Pending OSRAM Approval Chapter A.9 . . . . . 70

3.12 Base Unit Solidworks drawing With Dimensions . . . . . . . . . . . 71

3.13 RPS graph data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.14 OMPS300A48 Schematic . . . . . . . . . . . . . . . . . . . . . . . . 73

3.15 Voltage Regulator Circuit . . . . . . . . . . . . . . . . . . . . . . . 75

3.16 OMHT17 Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.17 STR 2 stepper Driver Dimensions . . . . . . . . . . . . . . . . . . . 78

3.18 STR 2 stepper Driver and OMHT17-075 Housing Placement . . . . 78

3.19 STR 2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.20 STR 2 Input/Output Pins . . . . . . . . . . . . . . . . . . . . . . . 80

3.21 STR 2 Example Wiring . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.22 STR 2 Motor Configuration . . . . . . . . . . . . . . . . . . . . . . 81

3.23 Phototransistor for base unit Pending LiteOnIt Approval Chap-ter A.10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.24 Web page View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.25 Data Flow in Software . . . . . . . . . . . . . . . . . . . . . . . . . 87

3.26 Xilinx Software Block Design . . . . . . . . . . . . . . . . . . . . . 88

3.27 Xilinx MIO Configuration . . . . . . . . . . . . . . . . . . . . . . . 89

3.28 Xilinx MIO UART Configuration . . . . . . . . . . . . . . . . . . . 89

3.29 Serial Write to Tamarisk . . . . . . . . . . . . . . . . . . . . . . . . 90

3.30 Serial Read to Tamarisk . . . . . . . . . . . . . . . . . . . . . . . . 91

3.31 Simple Stepper Motor . . . . . . . . . . . . . . . . . . . . . . . . . 98

3.32 Complex Stepper Motor . . . . . . . . . . . . . . . . . . . . . . . . 99

3.33 End-User Communication . . . . . . . . . . . . . . . . . . . . . . . 102

4.1 Final Design Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . 106

4.2 Sofradir Atom 1024 . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.3 Atom 1024 GigE Port . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.4 Tiva 123GXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.5 Tiva Pin Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

4.6 CC3100 Wi-Fi Module . . . . . . . . . . . . . . . . . . . . . . . . . 109

4.7 Software Class Diagram UI . . . . . . . . . . . . . . . . . . . . . . . 110

4.8 Software Class Diagram Camera . . . . . . . . . . . . . . . . . . . . 112

4.9 Tamarisk Camera Mount . . . . . . . . . . . . . . . . . . . . . . . . 114

4.10 Riser Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

4.11 Combining All of the Mount Sub-Systems . . . . . . . . . . . . . . 118

5.1 Functionality of Input Buffer . . . . . . . . . . . . . . . . . . . . . . 121

A.1 St Johns Optical Systems Approval . . . . . . . . . . . . . . . . . . 141

A.2 Applied Motions Approval . . . . . . . . . . . . . . . . . . . . . . . 142

A.3 Omega Engineering Approval . . . . . . . . . . . . . . . . . . . . . 143

List of Figures x

A.4 UCF Logo Approval . . . . . . . . . . . . . . . . . . . . . . . . . . 144

A.5 FLIR Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

A.6 Lomography Approval . . . . . . . . . . . . . . . . . . . . . . . . . 146

A.7 ScanCam Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

A.8 Sofradir Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

A.9 Pending OSRAM Approval . . . . . . . . . . . . . . . . . . . . . . . 149

A.10 Pending LiteOnIt Approval . . . . . . . . . . . . . . . . . . . . . . 150

A.11 Pending Xilinx Approval . . . . . . . . . . . . . . . . . . . . . . . . 151

A.12 Pending NEOS Approval . . . . . . . . . . . . . . . . . . . . . . . . 152

A.13 Pending DRS Approval . . . . . . . . . . . . . . . . . . . . . . . . . 153

List of Tables

1.1 Budget Spending . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Servo Motor Comparison pt. 1 . . . . . . . . . . . . . . . . . . . . . 33

2.2 Servo Motor Comparison pt. 2 . . . . . . . . . . . . . . . . . . . . . 33

2.3 Stepper Motor Comparison pt. 1 . . . . . . . . . . . . . . . . . . . 33

2.4 Stepper Motor Comparison pt. 2 . . . . . . . . . . . . . . . . . . . 34

2.5 Stepper Vs. Servo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.6 Stepper Motor Vs. Servo Motor Price . . . . . . . . . . . . . . . . . 37

2.7 Network Communication Comparison . . . . . . . . . . . . . . . . . 40

2.8 Comparison of Motor Communication . . . . . . . . . . . . . . . . . 43

2.9 Battery vs. Source vs. Hybrid Comparison . . . . . . . . . . . . . . 46

3.1 Needed LDO Voltage Regulators . . . . . . . . . . . . . . . . . . . . 75

3.2 OMHT17 Specifications . . . . . . . . . . . . . . . . . . . . . . . . 76

3.3 Tamarisk UART commands of interest . . . . . . . . . . . . . . . . 92

5.1 Tamarisk Commands of Interest . . . . . . . . . . . . . . . . . . . . 123

5.2 Response to Commands of Interest . . . . . . . . . . . . . . . . . . 124

6.1 Budget Spending . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

xi

UNIVERSITY OF CENTRAL FLORIDA

Executive SummaryCollege of Engineering and Computer Science

Infrared Panoramic

by Laith CharlesAlejandro Drausal

Nicholas GaorTyler Johnson

University Web Site URL Here (include http://)

Department or School Web Site URL Here (include http://)

Executive Summary 2

A cost effective infrared panoramic is a platform which can supplement currentsecurity solutions. Infrared detectors provide a unique advantage over normalcharged coupled device (CCD) and complementary metal-oxide-semiconductor(CMOS) detectors. Infrared detectors can see outside the human vision spec-trum which allows them to detect warm blooded animals and other hot itemswithout the need of supplementing illumination. This technology has been widelyused in military applications to provide situational awareness to troops in the fieldand help protect bases from incoming threats. Taking this previously expensivemilitary technology and implementing a budget 360 degree panoramic solution tobe used in commercial and residential application could be extremely beneficialat increasing safety while protecting high value targets, increase the efficiency ofsurveillance solutions, and reducing the frequency of false alarms.

As infrared technology decreases in price the amount of applications for this detec-tion hardware increases. The solutions currently available for residential and com-mercial applications are limited. It is expected this technology will become moreappealing for public. There is a need for the capabilities the infrared detectorsoffer. A product packaged correctly, marketed efficiently, and sold at reasonableprice could have great success in the surveillance market. There is a potential togenerate a large amount of revenue with the correct infrared detector solution.

Our proposed solution is a panoramic long-wave infrared (LWIR) device. Infrareddetectors are dropping in price, however, they are still expensive for the commer-cial, residential, and non-military government applications. Therefore, maximizingthe potential of a single medium resolution to create a product which provides themost imagery for the least amount of money is desirable in making a successfulproduct. By rotating an infrared detector about an axis parallel to the detectorplane a panoramic visual of the surrounding environment can be stitched togetheron a computational unit and output a visual which can assist surveillance appli-cations.

This product will be mounted on a motor driven rotating platform powered bya driver which can be controlled by a computational unit. The video will bestitched together and streamed to a computer where it can be viewed. A heavydesign consideration is expandability. This will allow the device to be integratedinto a variety of existing security systems. The product should also be able toserve as its own surveillance solution. A versatile device which can be mountedboth indoors and outdoors and provide good image clarity under a variety ofenvironments which can be easily controlled by an operator. The device should beable to alert when a suspicious target is detected and recording capabilities shouldalso be implemented.

The most demanding design consideration for this product is the cost of the finaldevice. This is key to making a prosperous product in a established security in-dustry which currently doesn’t widely utilize the capabilities of infrared detectors.Making add on modules which can expand the functionality of this detector tomake a solution which can satisfy any number of security needs.

Project Description

1.1 Project Motivation and Goals

The motivation behind doing this project was to apply all of the electronics knowl-edge which we have attained throughout the course of our respective educationand to further our skillset in our individual areas of expertise. Collaborativelyour group pooled together our knowledge which has been attained throughout thecourse of our education. Each member has a particular speciality which has beenutilized in order to accomplish the completion of a full design and manufacture.Electrical engineers gathered their hardware expertise using analog and digital cir-cuit expertise to create an interface which the computer engineering counterpartsimplemented using their software knowledge. Programming controllers and creat-ing interfaces alike which complimented the hardware were necessary to fulfill therequirements of our project.

The reason infrared detectors are the center of the project is because it is a nichefield which is likely to grow greatly in the next decade. Having some experiencedealing with infrared detectors introduced our group to the concept and potentiallyhelp with employment in this field. Also, as more and more data is transmittedusing optical frequencies rather than lower bandwidth frequencies, becoming fa-miliar with detecting light and processing the signal into useful information willhave many benefits in the future.

During this project we planned to fabricate a printed circuit board (PCB) bybecoming familiar with a circuit board design program and laying out the phys-ical components necessary to accomplish the task necessary. Another goal of thegroup was to interface processors with one another to establish communicationbetween two different systems. Also we planned to gain an understanding of andthe ability to implement data transmission formats like serial peripheral interface(SPI) and integer-integrated circuit (I2C). The group learned to implement noisefiltering and ensure correct circuit protection is in place to protect vital compo-nents from surges. We fabricated a custom power supply which can power all ofthe various components aptly and allow the device to operate appropriately undervarious temperatures allowing for a wide range of environmental operation. Thisalso ensures the device will work continuously for hours without heating up pasttolerable temperature ranges.

3

Section 1. Project Description 4

On the software side our goals were to learn and implement video data formatsand image stitching. This entails syncing motor control with the data coming infrom the camera. On the front-end, building a user interface (UI) to make theuse of the software easy and intuitive was a priority. As an optional goal, wewanted to establish two way communication with the camera which would allowthe user to point the camera in any desired direction. We needed to apply flatfield correction (FFC) or non-uniformity correction (NUC) from the program tothe camera intuitively. One of our goals was to implement industry standard codewhich is easily expandable and is structured so that the program could be workedon collaboratively with other programmers for mass expandability.

Mainly our goal was to make a functional product with fail-safes built in so that ourprototype could actually be used as a persistent surveillance device which wouldaid in providing a complete security solution in a variety of situations. We wantedthe product to be fairly robust, with the ability to withstand various weatherconditions. We also wanted to utilize intuitive software and standard protocolswhich could be implemented into a variety of security systems.

1.2 Project Requirements and Specifications

1.2.1 Performance

The panoramic system uses non-intrusive long wavelength infrared (LWIR) ther-mal imaging to create a panoramic representation of the surrounding environment.The project required several components. In order to rotate the Tamarisk 320, astepper motor with at least 10 Oz-in holding torque was needed to support thecamera and some light peripherals and matching dimensions depending on whichFOV Tamarisk model was chosen for the project. The Tamarisk 320 thermal cam-era was used since it is the smallest of its class and offers a 320x240 resolutionwith an integrated shutter for flat-field correction. Different models of the cameraare offered with different field of view (FOV) angles including: 40, 27, 15, and 9degree differences. Current panoramic solutions are all above $5,000. We plan onoutputting a high resolution thermal imaging device.

1.2.2 Capability

The system is be capable of rotating 315 degrees along the horizon, capturingimages and stitching some of the frames together into a portion of a panoramic.A control module was required for the stepper motor to assure it can be moved toany location at a fast rate. An analog to digital converter was also planned to beused which would feed in digital data to the control unit of the project. An FPGAthat can take 320 x 240 x 16 bits of data and stitch a mosaic using the imageinformation was originally required as well as spatial location from the motor


controller. To stitch together the image a directional component to the cameraneeded to be implemented to the design. This pings a directional timestampalongside the frame. This allows for an accurate de-warping program. Doing thisde-warping in real time at a cheap cost is essential. The key specification for ourdesign process is cost.

1.2.3 Operational Use

The purpose of this panoramic device is to provide surveillance capabilities to highvalue targets in situations with poor lighting situations. Creating a system at alower price point than current systems offered makes this a desirable and successfulproject in the marketplace. An image with a wide field of view and fast refreshrate will help in a variety of solutions. Most notably, this kind of product would beof high value in persistent surveillance situations. The system is functional in bothdaytime and night time. The technology boasts superior surveillance capabilitiesat night over non-LWIR solutions.

1.2.4 Relevant Software or Hardware Specifications

Initial discussions with the sponsor of the project illuminated the most importantaspects to emphasize in the process of designing this project. In order from mostto least important, these aspects were:

• Price• Speed• Quality of image• Ease of use for the end user

The proof of concept shows a fast and cheap way of producing high quality infraredpanoramas. Additionally, this system shows exactly how much computationalpower is required to produce an equivalent solution. This allows for an optimizedbudget FPGA to be manufactured and packaged with the existing software suite.Providing a solution at a price point fit for the market was one of the goals ofproducing the camera system.

1.2.5 Interface and/or Compatibility

The imagery must be output in a standardized format which can plug into anymodern monitor or interface with computational platforms. Sending a video signalout over serial audio visual (A/V), high definition multimedia interface (HDMI), ordigital video interface (DVI) for a direct plug and play experience for end users wasan important convenience factor to the success of the project. Additionally, output


over Ethernet for IP access or direct line into a computer was an important designconsideration to integrate this imaging capability with existing security systems.

1.3 Budget

Vendor Date Cost Req#Digikey 11/14/2014 $30.36 SDAdafruit Industries 11/14/2024 $54.11 SDRadioShack 11/13/2014 $18.59 PickupLowes 11/12/2014 $12.36 PickupApplied Magnets 11/11/2014 $46.61 9118Lowe’s 11/8/2014 $64.22 PickupDigikey 11/6/2014 $50.34 9097Mouser 11/6/2014 $140.85 9097Advanced Circuits 10/30/2014 $215.92 SDAvnet 10/28/2014 $66.85 9016OSH Park 9/23/2014 $27.35 8715Digikey 9/23/2014 $183.00 8451Avnet 8/25/2014 $71.60 8451SparkFun 8/25/2014 $27.12 8451Omega Engineering 8/20/2014 $358.00 8253Applied Engineering Products 8/11/2014 $106.51 8253Avnet 8/8/2014 $281.48 8252

Total: $1,755.27

Table 1.1: Budget Spending

1.4 Initial Timeline

The following timelines were constructed to initially outline the actual constructionof the prototype. These initial timelines are not inclusive of the research conductedand the preliminary design process which is considered in the semester prior. Allresearch should be completed prior to the production semester. A tentative designshould be complete. The viability of several components needs to be tested toensure proper functionality during the production semester. Testing componentsand researching backup options has been already considered. The timeline hasbeen built around the consideration of potentially troubleshooting componentswhich are not functioning as desired. Figure ?? depcits the initial August timelinefor completing the project.


Figure 1.1: August Timeline 8/18-8/31

1.4.1 September

The goal of September is to build a ”functional” prototype. This month willbe learning how to interface our development board with everything else. Thiswill involve knowing the data pathways, issuing instructions, and receiving datato perform image manipulation at some point. During this time we will also bebuilding a mechanical system for physical prototyping and developing tailoredhardware for the software being implemented. A timeline illustrating the orderand due date of the proposed milestones in September is featured in Figures 1.2and 1.3.

Figure 1.2: September Timeline 9/1-9/14


Figure 1.3: September Timeline 9/15-9/30

1.4.1.1 Procurement

This milestone indicates that all of the essential parts to begin prototyping willhave been ordered. Bare minimum parts which should have been procured forinitial experimentation are as follows. The IR camera needs to be bought tointerface with the FPGA. The FPGA prototyping board needs to also be ordered.The rotational motor and driver for said motor needs to be acquired. Appropriatepower supplies to power each device will be required. Finally, we will need to haveordered all other parts involving connecting various peripherals. These parts willbe used to begin initial development.

1.4.1.2 Motor Interface

The motor interface milestone suggests communication from a controller to thedriver which makes the motor spin accordingly should be reached at this juncture.This involves providing all of the correct voltages to all of the parts involved inthe process. It is important that we familiarize ourselves with the performance ofthe motor and all of the necessary components involved in instructing the motorto perform rotational operation. This also implies checking the physical size ofthe motor and begin construction on housing and mechanical practicality of thesystem.

1.4.1.3 Camera Data Extraction

Extracting data from the camera entails initializing a data stream from the cameraand receiving the data on the FPGA for data manipulation. This milestone re-quires understanding of the FPGA and of the IR camera. Knowing how to programthe FPGA and establish a master/slave communication with a peripheral will benecessary. We will need extensive knowledge of the pin layout and understanding


of the existing data exchange protocols offered by the camera. Implementation ofthis will be done on the development FPGA.

1.4.1.4 Mechanical System

Before image manipulation can begin, a controlled environment to simulate thefield functionality and offer a repeatable process is essential. Constructing a skele-ton platform for testing is important. The milestone indicates that the motorshould be secured in a base which will prevent the platform from moving. A toptesting platform should be made to mount the appropriate components neces-sary to test a bare minimum system. The necessary components will need to bemodeled and printed for experimentation.

1.4.1.5 Host Server

In order to establish communication from the FPGA to a viewing platform, likea computer, a server will be required to host the processed video. This milestoneentails installing an embedded version of Linux onto the FPGA and setting up theserver. This server should host the video feed which is then accessible and easilyviewable in the browser of a computer connected wirelessly to the network.

1.4.1.6 Software Image

Here the data from the camera should be able to be manipulated and displayed.This milestone only requires basic image generation and being to build the founda-tions for the rest of the programming involved. Much of the consideration in thissoftware will be identifying the essential components of the FPGA developmentboard which will be required to make an operational system.

1.4.1.7 Calibrate focal point

Using the stitched panorama the center of the camera should be adjusted to per-fection. A platform with the camera mounted in the appropriate location fixedthe the rotational plane will allow for the camera to be isolated and fixed so thatfurther experimentation will not compromise the integrity of the panorama. Thiswill allow repeatable experimentation which paves the way for perfecting the soft-ware side of the product. The overall goal if this step is to improve the quality ofthe final imaging of the product.


1.4.2 October

September was dedicated to understanding the functionality of all of the compo-nents involved in the product. October is focused on bringing those componentstogether and making them work harmoniously together. Much of this month willbe dedicated to refine the functionality of the rotation controls. The stability ofthe platform will be a primary focus of this month. Generating a full panorama ininfrared and streaming the image over WiFi is the main milestone to be reached.Optimizing the hardware to be scaled down and implementing the previously de-veloped software onto to a custom PCB with an ideal form factor to complimentthe design of the product. For a visualization of milestones, please refer to Fig-ures 1.4 and 1.5.

Figure 1.4: October Timeline 10/1-10/14

Figure 1.5: October Timeline 10/15-10/31


1.4.2.1 PCB Design

This step is dependent on the required elements identified in the software. Onceessential components have been identified and utilized then cutting out the super-filous components of the development board to reduce size and potentially reduceoverall cost assuming a large volume of PCBs are being manufactured.

1.4.2.2 Optical Communication

The final implementation will communicate to the engine wirelessly by sendingpulses of light to a sensor which will relay the instruction and make the motormove. Establishing how to physically implement it is an important design step.This milestone marks the point in time where a proof of concept has been imple-mented. This will help establish the physical arrangement of the LEDs which isan important consideration for the PCB board design.

1.4.2.3 Image Stitching

Using our functional mechanical platform and the existing communication estab-lished with the various peripherals. The camera and motor will need to opperatein sync, data will need to be captured and the information is to be stitched intoa panoramic image. The image does not yet have to be completely refined. Rawconsecutive images should be stitched together at this point. This should be ableto tell us how precise the positioning of the camera on the platform is relative tothe true center by slight distortions of the panorama.

1.4.2.4 Implement Custom PCB

This landmark indicates the custom designed PCB has been implemented into theprototype. The software which was origionally opperating for testing purposes onthe development board should also be loaded onto the custom PCB. The appopri-ate peripherals should be connected to the PCB and be functional. This step willhelp in configuring the final form factor of the device. Until the custom PCB is inplace the final housing cannot be put in place.

1.4.2.5 Inductive Power

The proposed solution relies on inductive coils to transmit power up to the spinningcamera. An important part on making this a reality is to create a power solutionwhich can plug to the wall and supply power everywhere it needs to go. Thewireless power transmission to charge the battery which will be housed on theplatform is important to get functioning. The inductive system will have to be


laid down on the plaform first, before a camera can be mounted on top. Thiswill increase power transfer effeciency and allow for shielding of other electricalcomponents above the coil which could be EM sensitive. This milestone involveshaving power coming from the a standard 120V 60Hz wall outlet and modified tosupply power from one coil to another which will charge a battery.

1.4.3 November

The purpose of the month of November is a refining month. This month will bereserved for any loose ends which were failed to be executed in a timely manner.This factors in time for any shipping delays and extra troubleshooting required onother unfinished buisiness. The device should be functional going into this month.However, viable products for market are not just functional. In a competativemarket the product needs to be reliable, durable, and easy to use. This month willbe focused on packaging a product which is read for the market. For a visualizationof milestones, please refer to Figures 1.6 and 1.7.

Figure 1.6: November Timeline 11/1-11/14

Figure 1.7: November Timeline 11/15-11/28


1.4.3.1 Housing

Now that the final electrical board is in place packaging the device so that theelectrical and mechanical components can function protected from outside inter-ference is important. The housing should be put on at this point to protect andfurther promote correct opperation. A sleek weather-proof rotationally aerody-namic housing should be added to the device to provide protection without im-pacting performance. The housing cannot block infrared light from reaching thedetector.

1.4.3.2 Durability

Any device will need to withstand a fair ammount of wear and tear. The dura-bility landmark indicates that repetative testing of the device has been done.Power cycling the product to ensure the product boots successfully without fail-ure. Subjecting the product to realistic shock and vibrations which the devicecould experience to test the stability of the mechanical platform. This device is aproduct which should be packaged for outside opperation as well as inside opper-ation. Testing how well the product stands up to various weather conditions suchas rain.

1.4.3.3 Software Features

The software has been working for a while. However, packaging the program intosomething deployable with the product and making the software able to work ona variety of systems. Perfecting our user interface making it clean and intuative.Providing all of the necessary functionality which will be required by the users likerecording, playback, manual control of the camera rotation are functions whichshould be packaged and be readily accessible for a user to access.

1.4.3.4 Testing

Moving the system around and testing the performance under many conditions.The product should work under ideal conditions up to this point. Testing indi-cates putting the device in slightly undesirable conditions and seeing the response.Attempting the access the video feed from multiple platforms. Stressing the de-vice and seeing performance. After this milestone is done then the software andhardware should be resiliant to nonidealities. While testing, a consideration ongathering video of the product in action this will be useful to include in the pre-sentation portion of the project.


1.4.3.5 Aesthetics

Now that the device has been engineered to be functional any additional time inthe design process will be dedicated to perfecting the aesthetics of the device. Itis hard to forsee exactly what will be required for this step so early on in thedesign process. This milestone will be to iron out any of the visuals which didn’ttranslate from the design process into the final product as desired.

1.4.3.6 Presentation

The final project will be presented to a council of selected UCF advisors. Thispresentation should be assembled for presentation by this date. The presentationshould introduce the purpose of the project, go over the design process, show theactual construction phases, show testing data and supply imagery. Included in thepresentation should be a thought out live demonstration.

Research

Before rushing to build the project, we needed to have enough knowledge in orderto make educated decisions on what is best for the project and how each of thedifferent components work together in order to create a synergistic effect that isthe overall project. Here, we explored all of the elements that went into creatinga cost effective panoramic infrared camera. The major research elements for theproject included the following and their expanding subsections:

• Existing Panoramic Solutions (2.1)

• Hardware (2.2)

• Communication (5.3)

• Power (2.4)

• Mechanical System and Packaging (2.5)

• Software (2.6)

Each section and its subsections will go into detail about potential solutions andapproaches to the overall project.

2.1 Existing Panoramic Solutions

Before beginning development on the panoramic camera, it was important to con-sider alternatives which may already have solved the problem we were going after.If a product already on the market met the needs we were trying to meet, it wouldhave been possible to take design elements from this products and improve uponthem. Examining similar systems showed us where these products fell short, orwhat considerations we weren’t currently aware of.

The following systems were explored for potential design aspects and understand-ing that may have been applied to the project:

• Smartphones (2.1.1)15

Section 2. Research 16

• Film Solution (2.1.2)

• Fisheye Panoramic (2.1.3)

• Digital Rotating Panorama (2.1.4)

To create a holistic look at all of the panoramic solutions, the different methodswere explored for potentially useful design aspects relevant to the project andcompared with each other in order to rank overall usability.

2.1.1 Smartphones

Currently, the most widely used panoramic solutions globally are smartphones.These solutions typically involve the user holding a smartphone and activatingthe panoramic mode on the cellphones camera feature. The user begins on oneside of the desired panoramic capture and slowly pans the environment until thedesired area has been captured. This is a convenient solution as it takes hardwarealready included in today’s phones and re-purposes them to create a panoramicimage which can be used to capture a wide horizontal FOV. The smartphonetakes advantage of the accelerometers, gyroscope, and the data from the camerato determine the direction of the device and then using a large amount of imageprocessing the information is stitched together into a single image. The greatestappeal of this technology is convenience. The smartphone market has been steadilyincreasing. More and more people are carrying this technology at their fingertipsevery day . Cell phones are usually heavily subsidized with a contract from acarrier. However, cell phones are expensive considering which components areutilized for panoramic imagery. If all a user wants to do is capture panoramicimagery then a cell phone includes a lot of unnecessary functionality. Despitebulk production driving down the cost of cell phones, a minimized solution whichincludes the basic components utilized could be built at a much lower cost. Thissolution utilizes a user physically holding the cell phone and spinning. Stitching theimage together takes time also. The processor is not capable of real-time stitching.Typically, this solution only does a single frame instead of a persistent surveillancesolution. Most cell phones on the market are not weather resistant, which poseda problem in the environments our project is built for. If the phone was outdoorsand subjected to too much water exposure the device would break. Almost all cellphones on the market utilize visual cameras. This differed fundamentally from theproposed infrared solution.

2.1.2 Film Solution

In contrast to the smartphone solution, the spinner 360 in figure 2.1 is a completelyanalog system which utilizes a mechanical pull string system to rotate a camera andthen the image is captured on film, Figure 2.2, instead of being digitally stitched


together. The advantage to this solution is the lack of computation needed. Nopower is required to make this system run. The resolution of the film is extremelyhigh which is great for zooming in and seeing detail at a distance. However, thissystem is not digital which make accessing the information for live surveillancedifficult. The film would have to be automatically fed into a scanning devicewhere it could be digitized and transmitted or the operator would have to be rightnext to the camera which would defeat the existence of the camera. This camerais not intended as a surveillance solution.

Figure 2.1: Physical Representation of Camera - Reprinted with LomographyApproval Chapter A.6

Figure 2.2: Panoramic Capture on Film - Reprinted with Lomography Ap-proval Chapter A.6

2.1.3 Fisheye Panoramic

The fish-eye panoramic, in figure 2.3, is another solution to infrared panoramicimaging which offers a unique solution. This is a lens which you can put on astandard FLIR camera. Instead of utilizing a rotational interface to provide apanoramic solution for surveillance this lens extends the FOV of a regular infrareddetector. Imagery from the FLIR camera is shown in figure 2.4. The lens bendslight to offer a complete panoramic solution for an uninterrupted complete 360degree view. The benefit of a solution like this is live video feed from an infraredarray. Unfortunately, this solution would be rather expensive to implement. A


high resolution detector would be required to provide useful imagery at range.Specialized lenses for infrared light are expensive. Germanium crystals, the mostcommon material used in infrared lenses, are quite expensive. A newer alternativematerial for infrared lenses is chalcogenide could be a viable more cost effectivesolution. However, for a panoramic view of the horizon of an environment thissolution would have many pixels staring at either the ground or the sky dependingupon the orientation of the camera.

Figure 2.3: Panoramic Lens - Pending NEOS Approval Chapter A.12

Figure 2.4: Imagery from a FLIR with a fisheye lens - Pending NEOS Ap-proval Chapter A.12

2.1.4 Digital Rotating Panorama

This solution utilizes a controllable motor which can rotate the focal plane of thecamera. The physical appearance of this solution is shown in figure 2.5. The


camera has a single strip of pixels, a one dimensional array which as the motorscans the environment, the focal plane and other components can more easily beseen in figure 2.6. This reduces the cost associated with the focal plane of thedevice. The cameras orientation can be changed and configured to rotate aroundany number of axis. The stepper motor, featured in figure 2.7 shifts the cameraslightly the strip of CCD pixels capture light data which the device is pointedtowards at that moment. Then the camera shifts slightly to capture the next stripof data. By doing this process repeatedly the camera is able to create a panoramicrepresentation of the environment at a fairly minimal cost respectively. A tailoredsolution could be created to replicate the functionality of this visual sensor inthe infrared. This device is currently utilized for predominantly large wide FOVphotography. The sensor can create a high resolution image with a minimal sizedetector. The disadvantage of such a process is the time it takes for a single scanof the environment to occur.

Figure 2.5: ScanCam Device Overview - Reprinted with ScanCam ApprovalChapter A.7

2.1.5 Comparison of Panoramic Solutions

Considering our primary design concern is cost efficiency and taking into accountthe various existing solutions which have been researched. In order to make a so-lution which is cost effective the solution could not include expensive optics. Thefocal plane used needs to be utilized well. Infrared detectors are still very expen-sive. Creating a solution which can maximize the imagery from a single mediumresolution focal plane to provide a panoramic solution would involve rotating thefocal plane and sampling the environment multiple times. The downside to this isthe slow refresh rate. Therefore, using this method, an important design consid-eration is to optimize the rotational refresh rate of the camera. The fisheye lens


Figure 2.6: ScanCam Labeled Diagram - Reprinted with ScanCam ApprovalChapter A.7

Figure 2.7: ScanCam Motor label - Reprinted with ScanCam Approval Chap-ter A.7


solution were not considered any longer due to the higher capital cost associatedwith the technology. Our product was tailored to implement a similar functionalityto the ScanCam, however, in infrared.

2.2 Hardware

The hardware research section is reserved for research done on the main hardwarecomponents identified as:

• Infrared Detector (2.2.1)

• FPGA Hardware (2.2.2)

• RAM (2.2.3)

• Motor (2.2.4)

Separate considerations were done for power supply solutions. All of the aspectswere considered of each element and various other components were taken intoaccount to create a viable solution. Comparisons of each of the various solutionscan be found at the end of their respective sections.

2.2.1 Infrared Detector

The focus of this product revolved around the capabilities of LWIR imaging. Thebenefits of night time surveillance is extremely beneficial in security situations.Most thefts occur at night time. It is for this reason the detector of choice was aninfrared detector. For a good balance of good resolution and reasonable cost wehave selected detectors which have approximately 320x240 resolution. Thermaldevices have much larger pixels than today’s CMOS detectors. A larger pixelmeans more light will hit each individual pixel. This means more data can beabsorbed by a single pixel which makes for a more accurate reading by the pixelas opposed to a smaller CMOS pixel. This means that comparably speakingon today’s market given current normal pixel size a 320x240 resolution CMOSdetector isn’t comparable to the 320x240 LWIR detector. More accurate imagerycan be attained by a comparable array size by the LWIR. Therefore the imageryprovided by the sensor is comparable to a higher resolution CMOS.

2.2.1.1 FLIR A35

FLIR are a well renowned manufacturer of infrared detectors. The A35, picturedin figure 2.8, is a 320x256 resolution thermal camera[1]. This camera comes withtwo standard available lenses one with a focal length of 9mm and another with


a 19mm focal length. The respective FOV offered by each of these lenses is 48

(H) x 39 (V) and 25 (H) x 19 (V). These lenses are not interchangeable, thedesired configuration must be selected upon order. The thermal sensitivity of thecamera is 50mK. Minimum focal distance of an object for it to be in focus is20x the chosen focal length. This camera outputs a video signal over standardCAT5 cable. The camera can put out a 8-bit monochrome at 9/30/60Hz with anautomatic gain control (AGC) applied. The camera can also output a 14-bit rawdata feed at 9/30/60Hz. The camera can be powered over the Ethernet cable. Theprotocols which this particular device support over the Ethernet are TCP, UDP,ICMP, IGMP, DHCP, and Gig-E Vision. One of the best and simplest features ofthis solution is the Ethernet port with a PoE solution available. This means onlya single standard form factor connection is necessary to interface with the device.

Figure 2.8: FLIR A35 camera module - Reprinted with FLIR Approval Chap-ter A.5

2.2.1.2 DRS Tamarisk 320

The Tamarisk 320, pictured in figure 2.9, is a 320x240 vanadium oxide thermalimaging detector[2]. DRS package this product in a fairly modular manner. Theirlenses are interchangeable and the lenses offered are extraordinarily diverse. Thereare 10 different lenses ranging from a 90 (H) to a 6.2 (H) FOV. The camera isavailable in multiple hardware configurations. The camera can be acquired withjust the base. The base is inclusive of the detector, bias board, and a processorboard. The base puts out a signal over LVCMOS UART or over Camera Link.The signal can be output similar to the FLIR A35 in either 14-bit raw videoor 8-bit with an AGC or other image enhancement applied. The module canalso be acquired with the base configuration, mentioned before, and with theirfeature board. The feature board adds some functionality to the Tamarisk. Thefeature board clips onto the back of the existing baseboard without adding anyadditional size to the width and height of the camera but it does extend the depth.The additional functionality provided by the feature board adds some differentprotocols to work with. On top of the interface formats provided by the base boardUSB 2.0, RS-232, and A/V are also included. The third configuration includes


the base configuration, feature board and a back cover to protect the internals.The third configuration does not differ from the second configuration in any otherway. The Tamarisk can apply different image enhancements to the output video,figure 2.10. There is an AGC which adjust the lowest temperature seen to thelowest greyscale color and the highest temperature seen the the highest greyscalecolor to increase contrast. There are two other image enhancement modes, ICElow and ICE high. These filters apply levels of edge enhancements. ICE lowprovides a moderate level of contrast enhancement to detected edges. ICE highbrings out a maximum level of edge enhancement to the image. The disadvantageto this configuration is the connection type used. This is not a commonly usedconnection type. Preliminary research indicated that design of a cable to interfacewith the camera is allocated to the scope of the project. DRS do not offer thecable accessory indicated in their documentation any longer. There are also a

Figure 2.9: DRS Tamarisk 320 Camera Module with Feature Board - PendingDRS Approval Chapter A.13

variety of accessories which are available for assistance in development. There is ahardware/software developer’s kit, breakout box which can provide standard videooutput pins from the camera module equipped with the feature board. Wires tointerface with the 30-pin connection on the back of the Tamarisk. There are variousmounting solutions provided by DRS to connect the Tamarisk to a standard 1/4-20tripod mount.

2.2.1.3 Sofradir PicoTM 384

Sofradir package a good focal plane. This particular focal plane is 384x288[3].This focal plane gives a slightly better resolution than the other detectors and itis competitively priced. This solution is only a focal plane though, figure 2.11.The benefit of working with the raw focal plane is to talk directly to the sensorwithout having to go through any existing system. This would mean the housing


Figure 2.10: DRS Figure of Image Filters - Pending DRS Approval Chap-ter A.13

for the focal plane would be ours to configure. This solutions benefit is completecustomization. Interacting with the focal plane, doing image correction, and usinga custom housing and lens. This would add a significant amount of work to thedesign process. There would be much DSP to be done interpreting the signal outof the focal plane. Once a custom lens is mounted to the system calibrating thelens would also be another design consideration which would increase the difficultyof the project. However, this offers flexibility to tailor the design process to exactlywhat is required and would reduce the overall amount of electrical components inthe system.

Figure 2.11: Sofradir PicoTM 384 Focal Plane - Reprinted with Sofradir Ap-proval Chapter A.8

2.2.1.4 Comparison of Cameras

All of the cameras compared have similar resolution focal planes. Each companyand their respective product have their various pros and cons. There are manyfactors which influenced our decision making process on which detector to use.


The Sofradir PicoTM 384 is not a complete camera module. This requires moredesign considerations than the other detector solutions being considered. The DRSTamarisk is a modular solution. The lens on the Tamarisk is interchangeable witha variety of other solutions. All of the lenses have been calibrated. The Tamariskhas an optional feature board. The data can be taken out of the module digitallyfrom the base configuration or a video signal can be extracted from the optionalfeature board. However, the connection type used is not common and thereforeengineering a connector to interface with the camera is required.

The FLIR A35 offers its own benefits. The camera has a simple connection type,an Ethernet port. This can supply power and communicate with the device.The camera can output data in a variety of formats which would be useful insupplying an optimal data format for our design process. However, the fixed lensconfiguration is problematic for our specific solution. The selected FOV needs toline up nicely with the rotation of the motor, most stepper motors rotate in 1.8

increments while servo motors typically cannot rotate in continuous 360 loops.The FOV should ideally fit into a single revolution.

Our selection of camera based on research was the DRS Tamarisk. The Tamariskis a packaged and functional detector. This device was ideal because the solutionis modular. Many calibrated FOVs could have been selected and configured asdesired. The ability to do this with or without the feature board is important.This way the device could be configured as desired. DRS loan out Tamariskcameras free of charge for college students working on their senior design project.This would completely eliminate the need to purchase an expensive IR camera.For these reasons the Tamarisk by DRS was found to be the most optimal solution.

Unfortunately, due to unforseen complications in interfacing with the camerathrough hardware, the project was unable to utilize this camera. Instead, aSofradir Atom 1024 was chosen as a replacement. This camera was easy to inter-face with over the Gig-E protocol, and was capable of being powered over PoE.This simplified a lot of design changes which had to happen at the last moment.The FOV of this camera was much larger than what was originally intended, at19.8. It also has a larger resolution per frame, at 1024x768.

2.2.2 FPGA Hardware

An FPGA was decided to be the best choice for processing of images comingfrom the Tamarisk camera. In recent years FPGAs have become much faster thanmicrocontrollers for the processing of images. Speed is one of the top prioritiesin this project, so it stands to reason this would give the kind of performance thesponsor expects. The FPGA unit was designed to be capable of stitching together40 photos of resolution 320x240 at a FOV of 9 degrees in a matter of a second ortwo, for a total 360 degree picture. Assuming 2 bytes are used to store informationfor each pixel, this comes out to 6,144,000 B or 6.144 MB of data to be processedper 2 seconds.


This calculation was what the processing requirement for the FPGA is basedaround. The RAM needed to handle the entire panoramic picture is larger thanwhat most low end FPGAs offer in block RAM, so external RAM had to be addedto accommodate for the system[4]. In recent years, FPGAs have become widelyused in image processing and are capable of handling data streams at a muchhigher rate than the one needed by the Tamarisk camera. Therefore even anFPGA with a modest amount of logic cells and processing power would have beensufficient to complete the task of stitching together the infrared images.

The two main manufacturers considered, Xilinx and Altera, both offer a range ofFPGAs which could suit the needs of the project. Xilinx boards support the XilinxSDK, the tool for developing for the board. The goal was to pick the one whichhas the minimum cost but still managed easily the stitching and readying of thepanoramic images. Familiarity was considered to be low on the list of priorities, asthe lead for the programming of the FPGA in the group has a base knowledge ofVerilog and FPGAs in general but not of one specific company or product. Severalof the options considered were:

2.2.2.1 Xilinx Spartan-6

The Spartan-6 family of FPGAs are the lowest end FPGAs that Xilinx offers.Spartan-6 FPGAs are intended for use in situations in which minimizing costand power is important. The two platforms which fall under this family are LXand LXT. The LXT platform is distinct from LX because of the inclusion of anintegrated transceiver. This functionality was not needed for our purposes, sothese FPGAs were not considered. Because of the priority on minimizing cost,the LX platform is of interest to the project. The technology is 45 nm, not thegreatest available. A part on the upper end of this family, the XC6SLX100 has4,824 Kb of block RAM and about 100,000 logic cells. The amount of block RAMin this instance does not appear to be high enough to store even one frame of theimages being fed in. This would be a logistical issue, solvable through the additionof RAM to the FPGA. Even though these FPGAs have the lowest speed out ofthose being considered, the amount of data that needed to be processed was nothigh enough to be of any concern.

2.2.2.2 Xilinx Artix-7

Xilinx lists this option as being the best compromise between performance, cost,and power usage. The technology used on all 7-series FPGAs from Xilinx are 28nm. The total block RAM of an Artix-7 XC7A200T is 13 Mb (1.625 MB), abovewhat would be needed to process the panoramic picture one frame at a time. Thiscould have reduced the logistical problem of feeding photo data in from severaldifferent sources. There are 215,000 logic cells on this FPGA, which is muchhigher than the previously considered Spartan-6 FPGA. This FPGA would be


much more powerful than necessary for the task at hand, but might be necessarywhen considering the amount of RAM we would prefer.

2.2.2.3 Xilinx Kintex-7

The Xilinx Kintex-7 is intended primarily for use in signal processing applications.This family offers higher performance than the Artix family. The block RAM thatcame with this FPGA was much higher than the amount that comes with theArtix board. There are more DSP slices and logic cells as well. This solutionended up being a more powerful FPGA than the project needs.

2.2.2.4 Xilinx Zynq-7000

The Zynq series from Xilinx is a SoC (System on a chip) which utilizes eitherthe Artix or Kintex board and includes many components needed for a varietyof applications[5]. This SoC was developed specifically for use in surveillance orcamera applications. The package supports an architecture which combines theFPGA with an ARM Cortex Processor, as well as interfaces for memory. Thesupported I/O peripherals are USB, UART, and ethernet, all of the peripheralswhich were of the most interest to the group. There are 54 pins on the board, whichshould be more than enough to communicate betweens the various subsystemswhich need to be controlled. Options for the FPGA ranged from low to high end.Because of the notes already considered about the Artix and Kintex FPGAs, andthe fact that an ARM processor is on this board, an FPGA with less logic cellsand RAM capabilities was found to be adequate. See Figure 2.12 on page 28 fora detailed layout of the board.

2.2.2.5 Arria V Family

Altera offers a wide range of FPGAs spanning the same area that Xilinx covers.The Arria V family is the most cost-effective group of FPGAs that Altera offers[6].The FPGA on the lower end of the spectrum is the Arria V GZ. This board offers156k logic units, which is the term for what Xilinx calls logic cells. The block RAMavailable for this FPGA ranges from 10 Mb to 24 Mb. Again, since additionalmemory was added no matter which FPGA is used, the amount of block RAMwas not the most important feature of the board we chose. As long as the FPGAhad enough block RAM to handle one frame of the picture, the amount of memoryis adequate. When looked at as a whole, this family of FPGAs is very similar towhat the Xilinx Artix-7 family has to offer regarding computational power andRAM.


Figure 2.12: Zynq Board Layout - Pending Xilinx Approval Chapter A.11

2.2.2.6 Comparison of FPGAs

The analysis of computational requirements for the assembly of a total panoramicpicture led the group to conclude that the lowest-end FPGA would be adequate tocomplete the tasks we need it to. Cost was one of the top priorities in developmentof this project, so we wanted to buy the most cost-effective FPGA possible. Theresolution being handled was relatively low for a device designed for use in HDimage applications. Therefore high cost FPGAs with more DSP slices, logic cells,and RAM could be disregarded. The minimum amount of RAM needed in theFPGA should be enough to hold one frame. This was a conservative amount ofmemory which is met by most of the FPGAs in the Altera V GZ family and theXilinx Artix-7 family. This narrowed down the choice of FPGA to a handful.

Both Xilinx and Altera offer SoCs. An SoC seemed to be the most time and costeffective way to bring all of the components we needed on the board together.The SoC considered in the sections above support the addition of DDR2 or DDR3memory, which will allow the entirety of one panoramic picture to be stored beforebeing sent to the output device. Programming for the SoC had to be done intwo different programming languages, as the ARM processor could run C andthe FPGA runs Verilog. This did not present any logistical challenge, as group


members have experience in both languages, and Verilog can call routines from Cfairly easily. Given the previous experience we had with Xilinx products, a Xilinxboard seems to be the logical choice for development and the final product. Xilinxproducts also offered development tools and support which made the developmentof the project a simpler task.

The Xilinx Zynq-7000 SoC can be purchased with either a Kintex or Artix FPGAon it. Because of earlier considerations of cost and resources needed, the Artix-7seemed to be the best option for use on the board.

Figure 2.13: Available FPGA options for the Zynq-7000 - Pending XilinxApproval Chapter A.11

2.2.3 RAM

No matter which FPGA was selected for the control unit, the amount of RAMprovided will not be enough to store all of the data for the in and output buffers.As computed in section 2.2.2, one full panoramic picture is approximately 6.144MB. We also designed around the possibility of having several full pictures to bestored at once.

The first decision which had to be made regarding the memory devices we wantedto use was whether to look for a device which utilized a ball grid array (BGA)or one which utilized a pin grid array (PGA). There are some advantages anddisadvantages to each which we needed to explore.

2.2.3.1 Pin Grid Array

A pin grid array is the method for pin layout widely used in PCB layout. Itinvolves arranging pins in a rectangular fashion at a distance of 2.54 mm apart.This has been found to be the optimal way to layout pins so that interference does


not become an issue but area is maximized. This option is easier for hobbyists asit doesn’t require special machining equipment to implement. Unfortunately, theprotrusion of the pins from the board means that during development the pinscould get damaged or snap more easily. If a pins snaps it must be completelyreplaced, which could pose logistical issues.

2.2.3.2 Ball Grid Array

The development of the ball grid array is fairly recent compared to the pin gridarray. Its design is launched from the idea of the pin grid array. Instead of con-necting to protruding pins however, the ball grid array uses pads attached to thepins inside the board. This gives a more flush design which offers quicker commu-nication times. This design removes the risk of accidental damage to protrudingpins. Another advantage is that BGA layouts can be more dense, as there is muchlower risk of bridging pins when soldering. More precise methods are needed tosolder BGA pins. This would mean exporting the soldering to the company whichwas printing our PCB. Since we already planned to export the printing of theboard to a company with more capability than the UCF lab, this did not prove tobe much of a hurdle. Figure 2.14 shows what a typical BGA layout looks like.

Figure 2.14: A typical BGA layout (Licensed under Creative Commons -attributed to Konstantin Lanzet)


Two ubiquitous technologies for addable RAM available are DDR2 and DDR3.The board we selected was able to utilize either of these, so we researched whateach had to offer.

2.2.3.3 DDR2

DDR2 is a slightly older technology, developed and released in 2004[4]. DDRwas originally developed to improve transfer speed from the memory by allowingan action on both the rising and falling edge of the clock. DDR2 was designedto improve on DDR by having an internal clock with half the speed of the databus clock. It is capable of transmitting at twice the rate of its first generationcounterpart.

When researching the advantages of using DDR2 or DDR3, we found that the onlyreason DDR2 is necessary or wanted is if the system it will be used on only hasthe connection configuration for DDR2. DDR3 is not backwards compatible, sothis is the only option with some systems. Fortunately for us, the board we hadchosen supports either DDR2 or DDR3, so there would be no reason to purchaseDDR2 over DDR3.

2.2.3.4 DDR3

DDR3 improved upon DDR2 memory in much the same way that DDR2 improvedupon DDR[4]. Developers once again succeeded in achieving clock rates half thoseof DDR2, effectively doubling the transfer speed. Not only is DDR3 faster thanDDR or DDR2, it has also become more ubiquitous in the memory market, andis much more cost effective. Because of these factors it was easy to see that thiswould be the best technology to take advantage of.

Given our memory requirements, the memory size could be minimal. We wantedto make sure we have enough to work with, but not pay for an amount that wewouldn’t use. The minimum amount we found widely available is 1 GB, whichwould be more than enough to accomplish the tasks we needed it to. The otherconsideration which needed to be given was the amount of input pins the compo-nent accepts. The Tamarisk camera outputs 14 data bits at time, so we neededthe ability to accept 2 bytes of data a time.

DDR3L is another technological advancement in memory technology which de-creases the voltage needed for the RAM to function. These were comparable inprice to regular DDR3, so we narrowed our search down to just looking for these.This added specification brought the list of RAM candidates down to a handful.

The AS4C64M16D3L manufactured by Alliance Memory offered a solid solutionfor our purposes. It was immediately available from several different vendors.Digikey, the vendor we were using for several other components of our system soldit from their website. It can take 16 bits of input. The one design hurdle created by


using DDR3 was the limited options we had in the way of package. This packagewas 13x9, for a total of 96 pins. While this did present more complexity duringdesign, 96 pins seemed to be the most common amount for DDR3 RAM, and thebenefits of DDR3 outweigh the added time we must take to assign the pins.

2.2.4 Motor

The mosaic aspect of this project would not be possible without a rotating appa-ratus for the camera. With this in mind, there were several viable solutions thatcould be taken in order to achieve the rotating component for the project.

Motors have many considerations[7]. Most circuits in recent years utilize digitallogic and work on small amounts of power. Motors are mechanical systems whichrequired gratuitous amounts of power, more than a normal controller could outputon a pin. The main components of a motor which were considered were:

• Mechanical Motor• Motor Driver• Driver Controller

With these essential components in mind, we explored the different merits betweenServo Motors, Stepper Motors, Encoders, and Motor Drivers. In addition toexploring the different motor and driver solutions, comparisons of traits and pricingare also included in this section.

2.2.4.1 Servo Motors

Servo motors were considered a trickier approach to this project. Since the servomotor utilizes continuous motion instead of “ticking” for each movement, it couldhave proven a sizable problem for the rotation mechanics of the project. Althoughthe motor could be programmed to rotate in “ticks” just like a stepper motor,there is a repeatable tolerance between each programmed “tick” that can slightlyoffset the pictures being taken. The most common tolerance seen is approximately0.03. This is the degree tolerance of most of the servo motors. Since the standardachievable resolution for the servo is 0.45, there would be a possible 0.03 x 4=0.12 offset just for a 1.8 rotation. Since the camera being designed for had a9 FOV, there was a range of 0.03-1 variance with each “tick” of the servo motor.This could have created a problem since the number isn’t consistent compared tothe stepper motor. An upside to the use of servo motors is that the controller isbuilt in so no extra peripherals need to be used in order to control it.

Table 2.1 and Table 2.2 depicts how similar each product was to each other mi-nus the price. Each came from the same line of product but there were notabledifferences in price and functionality between them.


Servo Motor Model NEMA Hld Trq Step Length(CPM-SDSK-*) Size (Oz-in) Angle () (In.)2310P-RLN 23 112 0.45 2.332311P-RLN 23 145 0.45 2.333411D-RLN 34 192 0.45 3.42

Table 2.1: Servo Motor Comparison pt. 1

Servo Motor Model Rotor Weight Price(CPM-SDSK-*) Inertia (lb) ($)2310P-RLN 0.077 1.38 2572311P-RLN 0.077 1.38 2793411D-RLN 0.0704 3.1 328

Table 2.2: Servo Motor Comparison pt. 2

The first two models were considered more viable due to their specs vs the lastone which was more expensive and could be considered overkill for what is neededfor the project.

2.2.4.2 Stepper Motors

With such a large competitive following in the market, choosing a stepper motorfor the project was tough simply because most companies are bidding for consumerattention by offering cheap/affordable stepper motors that are easily customizableto customer needs. Upon careful inspection of the stepper motors, a couple offactors needed to be taken into account before narrowing down the product listinginto what we could use. The weight of the Tamarisk 320 camera had to be factoredin since the motor would need to be strong enough to rotate it plus any kind ofcasing we decide to add in order to protect the camera from outside factors. TheTamarisk 320 weighs approximately 1 ounce so finding a strong enough motorwas not a problem. Depending on the material we pick for the casing, and howmuch of the product needs to be housed, we didn’t want to struggle with puttingsizable weight so a safe margin of 60 oz-in was chosen. Another factor thatneeded to be considered was that since the stepper motor rotates in “ticks” fromthe impulses, we needed to make sure that each “tick” would easily fit with ourrotation pattern. The industry standard for stepper motors seems to be 1.8. Withthe camera being designed for having a 9 FOV, this allowed for an even numberof ticks i.e 9/1.8 = 5.

Step MotorModel

Length(In.)

RotorInertia

Weight(lb)

Price($)

OMHT17-075 1.85 0.00544118 0.73 7417Y301S-LW4 1.89 .00096 0.77 52

Table 2.3: Stepper Motor Comparison pt. 1


Step MotorModel

NEMASize

Hld Trq(Oz-in)

LeadsStepAngle ()

OMHT17-075 17 62.8 8 1.817Y301S-LW4 17 61 4 1.8

Table 2.4: Stepper Motor Comparison pt. 2

Table 2.3 depicts how similar each product was to each other minus the price.The OMHT17-075 doubled the amount of leads compared to the other which wecould be reflected in its price. As seen in Table 2.4, not much changed betweenthe two different models minus the number of leads.

2.2.4.3 Stepper Motor Vs. Servo Motor

In regards to the mosaic thermal camera, a lot of debate had gone into whether ornot a step or servo motor was needed. The pros and cons of the stepper and servomotor merited a carefully measured decision between both, factoring in speed,power, strength, and precision. The camera rotational speed was a big factor inthe design of the project. With this in mind, the servo motor would have beenthe obvious choice. However, in looking at the general specifications of a servomotor, it can be seen that the servo motor is only effective with RPM’s greaterthan 2000.

In regards to power, the stepper motor required a constant current to be flowingin order to perform which could have been a drain on the power supply[7]. Inaddition to the constant flow of current, this generated a lot of heat in the systemwhich needed to be compensated with a heat sink or design change in order toreduce heat buildup. Consequently, this lead to added cost to the project, whichcontradicted one of the main design choices of building this project. In comparisonto the servo motor, current is only supplied to the motor when it needs to moveor hold the load.

Strength was also an important factor between the different motors. The stepmotor had a high pole count in its design which allowed it to have a higher torqueoutput at RPM’s lower than 2000. Conversely the servo motor had a bettertorque output with RPM’s greater than 2000. With these specifications in mind,the Tamarisk camera was extremely small and lightweight, alleviating much of thetorque output to just the casing and holding mechanism. Precision held a hugeprecedent with the design of this project. Step motors have a large number ofpoles so that they may move with precision vs the servo motor which has only afew poles and requires an encoder to be accurate. With a constant flow of currentin the step motor, impulses to the step motor could be controlled such that it will“tick” in small increments so that data can be gathered. Given that the Tamariskcamera could only take data once every 10 ms, an impulse could be programmedfor each “tick” that will allow the camera to take its picture with enough timeto reset before the next “tick”. Servo motors had a much more difficult time


doing so since they cannot “tick” as precisely compared to the step motor. If thecamera was rotating in a constant motion, this would cause pixels to be lost sincethere would be spots where data is missing because the camera may not have hadenough time to reset before the camera moved to a different location. Table 2.5

Stepper ServoSpeed xPower xStrength xPrecision x

Table 2.5: Stepper Vs. Servo

gives a visual representation comparing the stepper motor to the servo motor, heldagainst a variety of characteristics. This table made it easy to see that the steppermotor was a better design choice for this project. The specialized speed, strength,and precision of a stepper motor outweigh its only design flaw of power and heat.Compensation had to be made in the form of a stronger power supply and a heatsink which added to the cost. However, with careful browsing of products, wemitigated the added cost significantly.

2.2.4.4 Encoders

A core design aspect of this project was that there needed to be communicationbetween the rotating camera and the software using it. Not referring necessarily tothe pictures being stitched together, but it was essential for the software to knowthe position of the camera and how fast it was moving so that it could coincidewith the FOV and picture rate of the camera. For the case of this project, anincremental rotary encoder was found to be most likely to work best althoughthere were many different ways it could have been accomplished as well. Forthe incremental rotary encoder, utilizing its equally spaced pulses when it rotateswould allow us to easily coordinate it with the rest of the components of theproject.

A design flaw we needed to consider while choosing encoders was that incrementalrotary encoders have accuracy problems which could have been a huge detrimentfor our project. Since the camera is so precise with its “tick” movement providedby the stepper motor, accuracy in movement needed to be extremely high, withlittle to no variance between any impulse movements. Due to the incrementalencoders design, the encoder lost its position information when there was a lossin power or any kind of interference. However, this could be mitigated as certainmodels of incremental encoders contain index channels that could keep the positionof the encoder logged in case any kind of power loss or interference occured. Aspecific product we were interested in was just a general rotary encoder that wassmall enough to fit inside our overall product. A product we came across was theE6A2-C which is a cost effective encoder that we would be able to use since its


external diameter is only 25 mm. It also required very little power from an energysource, only 5 volts compared other encoders that we had looked at. Based onthe average dimensions of the encoder, it would easily fit into our project withits compact design. Coupled with a cost effective design, it would be a good fitfor the overall theme of our project in that we were building a cost effective 360

panoramic camera.

2.2.4.5 Motor Driver

Having a motor was essential to the product, but another component was neededto regulate the motor[8]. Having all the power and torque in the world wouldn’tmean anything if we couldn’t regulate the motor to do what we want. So inthis case, we needed to regulate the motor movement with impulses since it wasmost likely be a stepper motor. This could be done conventionally by building acircuit that would send impulses but it was much simpler to just have a driver forthe motor since most of the design aspects came from interfacing the camera tothe hardware and software implementation. By utilizing this driver, we could beassured that the motor will step at the rate we need it to and worry about justthe camera design with its software counterparts.

For this project, we selected the driver STR-2 to handle the necessary impulse andregulation needs. It had the capability to customize step and direction inputs aswell as clockwise pulse and counterclockwise pulse. With this kind of customiza-tion, we could even add more features since the rotation had the ability to be moreversatile and we could transform the project from just a simple panoramic pictureto being able to focus different areas and setting patterns. The driver was alsorelatively cheap, barring a price tag of $99.00 for one unit which could definitelybe a justifiable purchase since this was one of the major components that wouldbe used for the project and added a lot of potential functionality to the project.Since this project is entered in the DRS competition as well, its price could almostbe negligible because of its versatility to the project.

Figures 2.15a and 2.15b illustrate the product picture and schematic. Its designand dimensions of the driver made it ideal for this project. The only problembecame regulating the start of the impulses from the driver in conjunction withthe software/camera implementation. However, once we added timers or triggersit didn’t prove to be a large design problem overall.

2.2.4.6 Pricing Comparisons

With cost being a major factor in this project and taking the previous comparisonsbetween stepper and servo motors, Table 2.6 illustrates the price difference betweenthe stepper and the servo, we can see that the stepper motor was overall muchcheaper than the average servo with attached controller and encoder.


(a) STR-2 ICD (b) STR-2

Figure 2.15: Reprinted with Applied Motions Approval Chapter A.2

Stepper Motor Vs. Servo MotorStepper Price Servo PriceProduct ProductOMHT17-075 $74.00 ClearPath SD $257.00Driver STR-2 $99.00Total: $173.00 $257.00

Table 2.6: Stepper Motor Vs. Servo Motor Price

2.2.5 Wi-Fi Hardware

In researching ways to communicate the data from the system in Section 2.3.1,we came to the decision that streaming through a Wi-Fi server would be the bestoption. There are a couple different options through which we could stream Wi-Fion an integrated circuit[9].

2.2.5.1 Embedded Wi-Fi Module

The most obvious solution was to implement an embedded module that couldtransmit Wi-Fi. The module could be soldered onto a PCB and could be wiredto transmit from the Linux server we were installing on the chip. From looking atpricing, embedded modules tend to cost more than USB solutions.

2.2.5.2 USB Wi-Fi Dongle

Wi-Fi dongles offered us some simplification to the development of the project.There were several USB wi-fi dongles on the market which completely take careof all of the interfacing necessary to transmit through Wi-Fi. The only setup we


needed to do if we used this solution was to make sure the USB device could runon Linux and had the necessary drivers set up. Given the complexity of someof the other systems being used, we decided this would be the solution for ourpurposes.

D-Link DWA-121 Wireless N 150 Pico USB Adapter The D-Link Adaptersuited our purposes perfectly. We wanted to have the smallest package possible tomake the system lightweight and easy to balance. It was capable of speeds up to150 MB/s, far more than was needed for our purposes. Also important was thecost. At $15.00 it was very affordable. If it needed to be replaced for any reason itwould not be at a huge cost. This adapter was also compatible with Linux whichwas an important consideration. It boasts connectivity over a farther distance aswell, which was important for the end-user.

2.3 Communication

Establishing reliable communication with all of the various elements of the pro-posed product was challenging. There were a few obstacles which needed to beovercome. Typically, connecting all of the peripherals to the core computationalunit would be simple. Connecting them with wires would be sufficient with a fewresistors and maybe some op-amps to control the power delivered to the compo-nents. However, the nature of the rotational platform caused issues when feedingwires from other items out of the rotational plane. Research on how to realis-tically interface all of the various components needed to be conducted to ensurereliability. The easiest approach was to break down communication into 2 differentcategories and then coordinate them together:

• Network Communication (2.3.1)

• Motor Communication (2.3.2)

While looking at these different approaches, we needed to take into considerationfactors such as:

• Speed

• Cost

• Accessibility

• Housing considerations

• Ease of implementation

These factors helped us reach a viable option by weighing pros and cons of eachproposed solution.


2.3.1 Network Communication

The method by which the system transmitted the output to whatever system theend-user was viewing it on needed to be considered. With the factors mentionedin Section 5.3 in mind, considerable exploration went into the following networkcommunication methods that would be used for syncing up each of the differentcomponents of the project. Such viable solutions include a Wired approach, Wi-Fi, Radio, and 2.3.1.4 solutions. To create a holistic look at all of the differentnetwork communication methods, all of the different methods were compared andcontrasted with the factors first discussed at the beginning of the section.

2.3.1.1 Wired

Transmitting the output through an Ethernet connection would give us the bestcommunication speed. Unfortunately, using a wired solution would require us tosolve the problem of how to handle a rotating system with wires coming out of it.The best solution to this problem was to use a slip ring, a device which would allowa system to rotate freely of wires feeding input or output. This solution would begreat for a project where budget was not one of the main considerations, becausethey are quite expensive to procure. Using our given project specifications, amodest amount of speed could be sacrificed in order to provide a cost effectivesolution.

2.3.1.2 Wi-Fi

Wi-Fi would allow data off the rotating platform using the IP protocol. If the datawas streamed to a set website, any device which was connected to the internetwould be capable of looking at the streaming panoramic pictures in real time.If this option was selected, a server would need to be embedded in the PCB sothat the data can be hosted directly from the system. This would also mean datatransmission would have to be structured so that it could be transmitted using theIP protocol. This would add some computation to the back end, requiring moreresources in order to live stream. The best part of this implementation was thatWi-Fi would offer the maximum accessibility to the end-user.

2.3.1.3 Radio

Similar transmission could be done through the use of radio frequency waves. Uti-lizing radio waves, the output could be viewed from any receiver within range ofthe device. The signal would be transmitted so that the receiver can send the datadirectly to a display device and be viewable. This would take some extra compo-nents to modulate the signal in such a way that it would be viewable. It wouldalso not be as accessible, because setting up a receiver just for the system takes


extra work, when compared to using already implemented personal computers ormobile devices.

2.3.1.4 Cellular Network

Transmitting data through a cellular network would allow for the device to be usedin more remote locations. Instead of a server or wired connection which requiresa device connected to the internet to be within the operating area, this optionwould only require a cell tower to be within communication distance. This optionhas the same problems as wi-fi, in that the data would need to be formatted suchthat it could be sent through the cellular network. It would also offer a lowertransmission bandwidth, which was of concern when sending multimedia.

2.3.1.5 Network Communication Comparison

Speed Cost AccessibilityHousingConstruction

Ease ofImplementation

WiredEthernet

x x

Wi-Fi x x x xRF xCellular x

Table 2.7: Network Communication Comparison

The importance of cost and accessibility simplified the decision of which option toimplement. Referring to Table 2.7, it was clear that a wired Ethernet connectionwould not be affordable and justifiable to our sponsor. This narrowed our decisiondown to the wireless solutions. Using a cellular network would be ideal in veryspecific circumstances, but given the wide availability of internet connectivity in amodern environment, it was far from necessary. Using radio also has the issue ofbeing useful in specific circumstances, but not most. It should not be a requirementfor the user to be within radio range of the system in order to view the output.The use of Wi-Fi would mean that anybody with access to the internet would beable to view output from the camera. It could be implemented easily using anembedded server. This seemed to be the best way to transmit output.

2.3.2 Motor Communication

Establishing communication with the motor was another consideration. Powerneeded to be supplied to the motor and the motor needed to be connected to aprogrammable unit which was synced with the camera data. Timing the stepsof the motor to capture frames during the pauses then issuing step commands to


move again so the next frame can be captured. With the factors mentioned inSection 5.3 in mind, the varied approaches of Inverted Motor Communication,Optical Interface, Slip-Ring, Radio/Microwave Frequency, and Autonomoussolutions needed to be explored and analyzed.

After taking the following into consideration, a comparison between all of thesolutions was made in order to visualize the pros and cons of each approach.

2.3.2.1 Inverted Motor Communication

The first consideration was to have the motor inverted. The side of the unit whichrequired power was already on the rotational platform with the FPGA. This wouldmean controlling the motor could be done directly from the FPGA. Commandswould be issued from the FPGA to the motor driver then relayed to the motor.This would mean minimal cost, no additional components are required to solvecommunication. The speed of delivering signals to the motor would be extremelyfast. However, with much additional weight added to the rotational plane theresponse sensitivity of the motor would be reduced. With more mass starting andstopping the stability of the rotational plane would also be influenced drastically.The solution was easy to implement but was found to have worse reliability andcontrollability from the additional mass.

2.3.2.2 Optical Interface

This solution for communicating with the motor involved having an LED arraymaking a complete circle on the underside of the rotating platform with the originof the LED circle at the center of rotation. The motor would be oriented so theshaft rotated the platform and the base stayed stationary. Commands from theFPGA would be issued to the LEDs, the LEDs would send a signal to a lightsensor on the motor side. The received instructions would be decoded on anotherprocessing unit and then commands would be issued to the driver and relayedto the motor. The benefit of this system was speed. Light is fast and with theright LED and driver the response would be very good. The cost of this solutionwas reasonable. A cheap micro controller could be used to power the secondarysystem for the motor. The LEDs which would be on the underside of the rotatingplatform are reasonably cheap. The solution if implemented correctly, would proveto be reliable. This solution comparatively speaking was difficult to implement.There were more components to implement than the other solutions leaving moreroom for troubleshooting. A similar solution regarding having LEDs hooked up toan Arduino could be implemented on any micro controller. Figure 2.16 illustrateswhat the base of the platform would look like.


Figure 2.16: LED Platform Base

2.3.2.3 Slip-Ring

Connecting the motor to the FPGA via a slip ring was another possibility consid-ered. The motor only had a few wires which need to be fed through to the FPGA.The driver in this solution would be located on the motor side of the system. Thissolution was fast. Based on the number of wires required it would not be tooexpensive to feed them through with a slip ring. Slip rings have a low fail rate.Wired solutions are more reliable than a wireless one in most cases. Therefore,this system would be reliable and easy to control. However, implementing the slipring about the mechanical rotation and the overall cost proved to be too difficultto keep this solution under consideration. Unfortunately, nobody in our group hadadvanced knowledge in mechanical systems which puts us at a disadvantage. Thismade the solution complex for this group. For clarification on the type of slip ringthat was being considered, please refer to Figure 2.17.

Figure 2.17: Slip Ring - Reprinted under the creative commons license


2.3.2.4 Radio/Microwave Frequency

A wireless EM wave was another option considered. We could have used the exist-ing Wi-Fi module to communicate with the base. This would require a complicatedbase circuit capable of handling a Wi-Fi stack. Another option would entail usinga raw radio/microwave frequency to control the system. No Wi-Fi stack or twoway communication would be needed if we were to use this, just a system whichreacts to a specific frequency. There are a lot of existing signals propagating in theatmosphere. Finding an unused frequency is area specific and therefore limiting.A very high frequency line of sight microwave signal could be used with insula-tion. The insulation would ensure no interference would occur. However, higherfrequencies mean more power consumption from switching. This solution wouldbe fast and have a mid-range cost solution. The system would be reliable as longas interference was appropriately filtered out. The communication would be ableto supply controllability. There were plenty of hobbyist modules available whichcould perform this task. Using some prepackaged solution as a reference designthe system shouldn’t have been too difficult to implement but there would be alot of components to this solution.

2.3.2.5 Autonomous

Another option which has not be discussed was making the base autonomous. Inorder to do this we would need to program a cheap microprocessor to operate byitself and configure the timing correctly in the program on the micro controller.This solution would mean there is no communication between the FPGA andmotor. The motor would operate by itself and could only be turned on or off inpractical usage. This was found to be a fast, cheap, reliable solution, howeverthere was no controllability from the users end to communicate with the device.This solution would not have been difficult to implement, however, the solutionwas limited.

2.3.2.6 Comparison of Motor Communication

Speed Cost AccessibilityHousingConstruction

Ease ofImplementation

InvertedMotor

x x x

Optical Interface x x x xSlip-Ring x x xRadio/Microwave x xAutonomous x x x

Table 2.8: Comparison of Motor Communication


Referencing Table 2.8, the inverted motor communication, radio/microwave, andautonomous solutions had 3 or less merits factored into the traits that we werelooking for in regards to motor communication. All 3 of them offered speed whichwas a must since the timings we dealt with were quite strict. Since cost was oneof the most important aspects to this project, the inverted motor and autonomousmethods were very cost effective and were fairly easy to implement, but the acces-sibility and housing for them were quite costly and complex. The radio/microwavemethod seemed to be the worst of the bunch, being costly and difficult to imple-ment. Ruling out the other 3 at this point, we could see that the optical interfaceand slip-ring solutions were the most viable. The optical interface offered speed,cost effectiveness, accessibility, housing construction, but lacked in the ease of im-plementation. The ease of implementation definitely became an offset factor forpicking this solution. The slip-ring solution displayed an easy way to solve the mo-tor communication problem. It offered speed, accessibility, housing construction,and could be easy to implement. However, it contradicted a main design aspectfor the project in that it was expensive to implement. All in all, it boiled downbetween the optical interface and slip-ring solutions. The smart way to go aboutthis was to take on the challenge of implementing the optical interface solution. Ifwe could not properly implement it, then we might have had to take a hit to thebudget and go with the slip-ring route. The motor communication was one of themost important components of the system, and having it properly working andtaking a hit to the budget was better than having a sub-par motor communicationsystem and saving a few bucks.

2.4 Power

Power was one of the most important systems for this project. Without the propercontrol and maintenance of the system’s energy resource, the system would notbe able to run consistently and efficiently. In order to remedy this, differentconsiderations needed to be taken in regards to how the power supply would betreated while the project is running. This section will cover the different optionspertaining to the projects power storage, regulation, and delivery to the system.The components which required power delivered to them were:

• FPGA• Motor Driver• Motor Controller• Camera Module• LED Ring

These were the main subsystems which required power delivered to them. Theother peripherals could be powered from the embedded controllers. There aremajor design aspects that needed to be considered in regards to power that aredealt with in this section such as:


• Power Supply Unit (2.4.1)• Induction (2.4.2)• Solar (2.4.3)• Storage (2.4.4)• Regulation (2.4.5)• Delivery (2.4.6)

2.4.1 Power Supply Unit

A design factor we needed to consider was the kind of power supply that theproject will use. With such a large variety of ways to power up the project,careful considerations needed to be made so that the optimal power supply wasused[10]. In the case for this project, we decided to power the driver instead ofthe motor itself because the driver has the ability to take over powering the motorinstead of it being user based.

In regards to a battery power source, standard 9V batteries wouldn’t have enoughpower to fuel any kind of motor/driver. This meant that a big lead acid of NiMHbattery pack needed to be used so that the project had enough power to consis-tently run for long periods of time without being changed or maintained. Withthis in mind, we needed a split power supply source where different supplies wereused for each component. The control unit we were designing for would most likelybe an FPGA board that would be using a lot of computations so it would probablybe powered by USB or a powerful battery like the motor/driver. The reason forthe split power supply was that when you run two high powered devices like amotor/driver and FPGA, problems can happen simply because each device isn’tgetting enough power to do their respective jobs. The pros of having a batterypowered device were that the project can be set up anywhere, eliminating the needfor outlets or power sources. If the project setup was to be static/stationary, thiswould be the ideal setup since nothing needed to be maintained or moved. Thecons of having a battery powered device were that the batteries need to be changedout periodically, depending on how often the device was being used. Based on theenvironment, the hassle of changing the batteries in the device could range froma walk in the park to running a marathon in flip flops.

In regards to having an outlet source for the project, you would need an adapter toconvert the outlet output into a usable voltage and current for the motor/driver.The same pros and cons apply to having an outlet source to fuel the project in thatit’s extremely beneficial to use an outlet source when the project isn’t being movedall the time and that no batteries need to be changed or maintained. Additionally,the cost of having an outlet source to power the project are much cheaper sincebatteries do not need to be changed. However, a case could be made for havingrechargeable batteries that give the project hybrid pros and cons in that it wouldcontain the mobility of having battery sources to power it but is cost effective inkeeping the batteries a constant amount for their respective life spans.


Battery Outlet HybridPower x x xMaintenance xMobility x xCost x x

Table 2.9: Battery vs. Source vs. Hybrid Comparison

Referencing Table 2.9, we can see that the battery approach tends to be equalwith its pros and cons in that it can power the device and has mobility. If youlook at the outlet approach, the pros actually outweigh the cons three to one inthe power, maintenance, and cost department. Looking at the hybrid approach,it has the same statistical value of having a three to one pro to con ratio butexchanges the maintenance trait for a mobility trait. Analyzing the three differentapproaches we could rationalize that the outlet or hybrid approach would be bestfor the project and could be differentiated by the fact if the project will be mobileor not.

Due to the nature of the project, constraints were in place that limit a batterypowering the motor and driver at the same time. It was most efficient to use apower supply unit that was connected to an outlet simply because the voltageoutput of most batteries degrades with use which could create a lot of problemsif a fresh battery wasn’t in the project or it had been in use for too long. Thiscould not be the case for the Tamarisk camera or Zynq board. Since the rotationalplatform position would always be dynamic with respect to position, it could notbe plugged into an outlet source without utilizing a costly solution like a slip-ring.Therefore, we needed to use a battery solution that would provide enough steadypower to all of the different components on the rotational platform. Since therewere multiple power requirements to the different parts of the rotational platform,voltage regulators needed to be utilized in order to avoid having multiple batterieswith different power values for the purpose of powering everything.

Another aspect we needed to consider was that putting a battery on the rotationalplatform could affect performance of the motor. Since the platform would be spin-ning, weight discrepancies could cause instability in the movement of the Tamariskcamera. In order to remedy this, counterweights needed to be carefully placed inorder to keep the system stable. While the balance issue had been addressed, weneeded to ensure that the overall weight of the platform could still be supportedby the stepper motor.

2.4.2 Induction

Induction was a somewhat complicated aspect of the project. We needed to in-corporate the coils and circuitry necessary to charge both the camera and FPGA.However, depending on how much power the FPGA would really be consumingsince it is performing a lot of computation, wwould determine how much power


we really needed to charge both components. While designing this element ofthe project, it was speculated that 10 watts of power would be enough to chargeboth components. However, designing an efficient inductive charging system wasdifficult to do. Ideally a coupling factor of 99% could be achieved[11]. Transform-ers are able to accomplish this high efficiency. However, our system would nothave one inductor fully encased in another. Because there was distance betweenthe two systems, naturally there had to be some loss. The highest efficiency wecould hope for in this systems is around 90%. More conservative estimates wouldbring power transfer around 70-80%. On the market while researching there weremany solutions to provide inductive power. However, most of these solutions werefor teaching the concept, which included basic tasks such as lighting up LEDsor charging a cell phone. For our project a higher power solution would need tobe designed. Most of the current solutions on the market today only deliver amaximum 5V 500mA. On top of the low power transfer, the system is usuallyinefficient. With this in mind, sizable modification to their system needed to bemade to meet the power requirements for our system. A proposed method of pow-ering the system would be to put 2 inductive charging systems for the camera andFPGA. This way, we could take a current system and modify it to what we neededwhile avoiding the messy and potentially problem ridden alternative of trying tomodify a current DIY project to meet our needs.

From research there were many considerations which needed to be weighed. Forinstance, should the inductive power be transmitted via AC or DC? What gaugewire and what material should the inductive coils be made of? What shape shouldthe induction be wound into? Should hollow wire or solid wire be used? Also, theinductive solution functions by making magnetic fields to a ”listening” inductor.Would the electromagnetic discharge cause too much interference with the otherelectronics? Are there measures to shield components from being affected by themagnetic interference?

In order to address these concerns regarding inductive power transfer, calculationsof a design needed to be performed. Induction was a strong candidate for trans-ferring power to the rotational platform, however, the concerns about interferencefrom the magnetic field generated by the induction and shielding the electronicsto prevent undesired behavior was another design concern.

Should the inductive power transfer have been done using AC then the materialchosen for the inductive coil would be a hollow copper pipe. Current under ACconditions travels mostly around the outside of the wire. Making the cross sectionof the wire solid would be heavier and not cost effective. For a DC application ofinductive power transfer the coils would utilize a solid wire. The key to making anefficient power transfer between the two coils was to make a high coupling factorbetween the two respective coils. Another key factor was the Q value of the actualcoils. Wrapping an inductive coils uniformly utilizing properties of solenoids tomaximize the flux generated by the coil was another important factor of inductionwhich will affect the performance of this system.


2.4.3 Solar

Due to the fact that we expected this system to be used in an outdoor environment,it was worth noting the risks and benefits involved with harnessing solar power.Potentially all of the subsystems could have been run on solar power from twodifferent arrays of solar panels. The first array would be mounted on top of therotational platform and would power the PCB, camera, and LED array. Thesecond array would be below so that it could feed power to the motor.

Without using solar panels to power the subsystems, a power outlet needed tobe nearby in order to give power to everything. This would be unfortunate, asit would limit the flexibility of the system. However, when using solar powerwe needed to consider if any given location could provide enough sunshine to beadequate. Also, the system could be used indoors, in which case this method ofgenerating power could not be used at all. Keeping these two factors in mind, thisbenefit of solar power did not seem to be all-encompassing. If we could not relysolely on solar power in all situations, we would have to design and implement twodifferent ways of supplying power.

Yet another consideration which gave us hesitation about using solar power wasthe cost of solar cells. Although the cost of this technology has decreased in recentyears, it was still quite costly when compared to inductive or battery power. Asa rough estimate used for researching cost, we assumed we would need to supplyabout 10 watts for the components on the rotational platform and 290 watts forpowering the motor. These calculations were based on the estimates we had forthe amount of voltage and current needed for each component. When looking atsolar panel vendors online, we quickly found that solar panels were indeed tooexpensive to justify given our project specifications. The Canadian Solar CS6x-290M 290 Watt 36.1 Volt Solar Panel found on a consumer solar panel vendor’ssite cost $437.65 at the time of our research. This was the cost of just one of thepanels we need.

Given these logistical issues with utilizing solar power, it was decided that thiswas not a good option for our project.

2.4.4 Storage

The project employs 2 different methods of power storage that maximize its effi-ciency. The motor is powered by the STR 2 Stepper Driver which is then poweredby the specialized power supply unit, OMPS300A48. This power supply unit sup-plies enough voltage and amps to the OMHT17-075 Stepper Motor that optimizesits revolutions per second.

With the motor having a specialized power supply unit, the Tamarisk and Zynqboard needed to have power as well. With this strategy in mind, a rechargeablebattery could power up the Tamarisk and Zynq board so that no wires or slip-rings would be needed to connect the 2 components to the specialized power supply


unit. This battery could be charged continually using inductive power generatedbetween the base and rotational units, so that batteries would not have to beswitched out at any point until the battery could not recharge itself anymore.This added an additional benefit in that no power was being sapped from theOMPS300A48 so that it wouldn’t lose efficiency when it came to revolutions persecond and overall torque power.

2.4.5 Regulation

Having a specialized power supply unit meant that power would be automaticallyregulated between the STR 2 Stepper Driver and OMHT17-075 Stepper Motor.Since the Tamarisk camera and Zynq Board are being powered by batteries, spe-cial attention needed to be made to how quickly the power could and would bedrawn out of the batteries. In order to remedy this, inductive charging would beemployed so that we could have a wireless charging apparatus in the project. Thiswas intended to avoid using costly solutions like a slip-ring apparatus. For moreinformation on inductive charging, please refer to Section 2.4.2. Testing neededto be conducted in order to determine the rate of charging coming in from theinductive process vs what was being used.

2.4.6 Delivery

In terms of delivery, the OMPS300A48 supplies power to the STR 2 Stepper Driverand OMHT17-075 Stepper Motor. The OMPS300A48 takes its power from an ACinput so the amount that it has is virtually unlimited for its scope. Power deliveryto the Tamarisk camera and Zynq Board comes at a much more complicatedmethod. The overall combined voltage for both of the components is equated tobe approximately 5 volts and 2 amps which compiles to approximately 10 watts ofpower total. Since batteries cannot output specifically 5 volts 2 amps for our needs,voltage regulators needed to be added to the system so that the right amount ofpower goes to each component. Specifically referring to the Zynq board, it hasmany components that require smaller amounts of power so voltage regulatorsneeded to be carefully administered to the different parts of the board in orderto ensure that it operates properly. Looking at Figure 2.18, we can see that theOMPS300A48 power supply unit draws power from an outlet and transfers it to theSTR 2 Driver and OMHT17-075 Stepper Motor. As for the rotational platform,Figure 2.19 clarifies how power is delivered to the top platform. The power startsfrom the battery and passes through a number of voltage regulators which allocatesthe appropriate power requirements to each of the rotational platform components.


Figure 2.18: Motor Power Delivery Block Diagram

Figure 2.19: Rotational Platform Power Delivery Block Diagram

2.5 Mechanical System and Packaging

Having the components of the project meant nothing if they weren’t placed prop-erly or protected. Since one of the biggest aspirations of the project was to placeit outdoors or in a public area, how each of the systems would be mounted andprotected needed to be taken under heavy consideration. Outside factors such asweather and external interference are addressed in terms of the following:

• Housing (2.5.1)

• Camera Mount (2.5.2)

• Motor Mount (2.5.3)

• Control Mount (2.5.4)

The purpose of exploring these different areas was to flesh out the logistics ofwiring, placement, and protection for the overall project.


2.5.1 Housing

The intended environment in which the camera system would operate in was notstrictly defined during the research phase of our project. It could be used in asurveillance capacity in hot, dry climates or humid, cold climates, or anywhere inbetween. In order to make the system as stable as possible in these situations,we needed to give consideration to weather-proofing the system’s housing. Thisincludes Water-Proofing, Temperature-Proofing, Wind-Proofing, and Surge-Protection approaches to protecting the system.

2.5.1.1 Water-Proofing

Many companies now offer hydrophobic spray which can easily be applied to asurface for the purposes of water-proofing. This solution would be fast, easy, andcost-effective. One such product is NeverWet, made by Rust-Oleum. It is intendedfor use in indoor or outdoor environments and dries quickly. It is offered at manyconsumer stores, so it would not be difficult to procure.

The website warns not to apply hydrophobic coating to electrical componentsunfortunately. This means we would need to have a tight seal on the dome whichwould rest on the rotating platform. The dome would need to have a transparentlens in front of the camera so that water could not get into the system at all. Thiswould require some calibration and mechanical fixing so that nothing could shiftand interfere with the camera’s view.

These two solutions working in conjunction would ensure that the system is entirelywaterproof.

2.5.1.2 Temperature-Proofing

The system should be able to function both in hot or cold climates. Since weplanned on encasing all of the moving parts, we did not need to worry aboutwater condensing on the rotational joint and freezing. No water should be able tofreeze in areas which would prohibit movement. This means that heat would bethe main concern with the system.

Because of budget and time constraints, cooling the system could not be empha-sized to as great of an extent. Cooling solutions involve the installation of eithera fan, a heat sink, or a liquid cooling apparatus. These solutions range from ex-pensive to logistically complex. Instead, we chose to reflect as much heat off ofthe system as possible using white paint on the housing. This proved to be muchcheaper and easier to accomplish.


2.5.1.3 Wind-Proofing

The structure of the housing needed to be such that gusts of wind could not causethe system to topple over. In order to prevent this from happening, we simplyhad to construct the base of the rotating platform to be wide enough that it couldnot be flipped. The amount of mass on top of the base should not be significantenough to pose any threat of getting caught by wind.

2.5.1.4 Surge-Protection

The last, least likely way that weather could interfere with the system is electricalsurges from lightning, power lines, or other routes. While the event of somethinglike this is an anomaly, not protecting against it could have lead to completedestruction of all the electrical components. We planned to prevent this fromhappening in two different ways. To keep lightning from striking the system,we placed an antenna next to the camera which will be fixed to ground. Thisprevented any electrical disturbance. To prevent surges out of the power outlet,we used a consumer-grade surge protector. These solutions were cheap and easy,and could have prevented major destruction of the system.

2.5.2 Camera Mount

Mounting the camera correctly was imperative to creating a controlled environ-ment for the camera to operate. Without a good mounting solution, the focalpoint could not be calibrated correctly for adequate imagery to be constructedfrom the system.

The Tamarisk system already has a mounting area which is usually utilized formounting the camera. Right behind the lens of the camera there is a metal ringwhich existing mounting solutions utilize to grip the device. A similar system wasdesigned to grip the camera utilizing the area which existing camera mountingsystems utilize for the camera. A key consideration for the camera mount was tolimit the axial mobility of the camera to ensure the camera cannot shift off thereference rotational plane. The proposed system had no feedback option built in totell the controller when the camera has shifted from the desired area of operation.Designing a robust camera mount to ensure the camera cannot deviate from thereference location was important to retrieve good imagery from the system.

Configuring the focal point of the system was another important considerationof the camera mount. The mosaic solution considered was utilizing the 35mmlens. Calculating the focal point of this system and configuring the camera toreside and rotate about the focus to ensure detailed imagery from the device wasan important design consideration. To allow for a configurable camera mount asliding mount was chosen. This allows for minor adjustments to where the focal


plane sits in regards to the rotational axis. This flexible design also allows for thesystem to be configured for different fields of view.

2.5.3 Motor Mount

Considerations for the motor mount were that the motor was to remain fixed aboutthe base. The base was to be static in regards to the reference plane. The referenceplane in this case would be a roof of some kind. Considerations for mounting theproject to a surface like a roof to get accurate imagery. The mount would need tobe resistant to acclimate weather from shifting the device from its home location.The home location being the desire fixed plane for the system to operate around.

Inspiration for mounting this system was taken from existing security surveil-lance systems. Many panoramic systems exist in security systems today. Mostpanoramic systems are based on a wide FOV lens capable of seeing a wide area.The reality of IR cameras is that they are much lower resolution than today’svisible cameras. Getting decent panoramic imagery from a Fish eye type lensis difficult to achieve due to the enormous cost of high resolution infrared focalplanes.

The motor, like some of the rotational systems which exist in the market today,was planned to reside in a water-proof weather resistant enclosure along withthe motor driver and various other power supply related elements. The motorchosen had mounting screws on the front to be fastened in place. Other machiningrelated applications utilize these screw brackets to fasten the motor to an enclosure.Preliminary findings indicated the easiest mounting option would be to fasten themotor to a plate which would then be mounted on the top of a box-like structure.The box-like structure will house the rest of the electrical components assigned tothe base.

2.5.4 Control Mount

The control mount was planned to be how the FPGA PCB was mounted to therotational platform. A camera mount system was already in place. The camerawould be mounted above the PCB. In order to compensate for the presence of thecamera, some through holes would be put into place to allow for the camera to bemounted without interference from the PCB. Using the existing through holes toact as support for the camera platform they could also be utilized as anchors forthe PCB. From experience of taking various other electronics apart utilizing nec-essary support infrastructure for a convenient anchor point is a common practicein the consumer industry. This optimized solution reduced the parts involved inconstructing the product and therefore reduced the cost and labor associated withmanufacturing the solution.


On top of securing the controller, shielding the controller from interference wasanother factor associated with the control mount. The magnetic field generatedfrom various other components could have potentially interfered with the perfor-mance of the device. Therefore, appropriate shielding needed to be built into thecontrol mount. A cost effective, light and functional solution to this design consid-eration is a copper plate. This copper plate was fastened on the underside of theplatform. This supplied adequate shielding from the potential EM interference ata reasonable cost. Copper is frequently used to protect against EM interference aswell as other alternatives such as silver and gold. Keeping budget in mind, copperwas found to be the most economical solution when compared to gold or silvershielding solutions.

2.6 Software

There were a couple decisions which needed to be made about the code and back-end which support the system. Although much of the tasks which needed to behandled by the processing unit were fairly straight forward such as the control ofthe camera and motor, some key decisions were important to explore. There are3 main aspects that needed to be explored:

• FPGA Software (2.6.1)• Data Representation (2.6.2)• Development Environment (2.6.3)

2.6.1 FPGA Software

The board that we printed utilizes an operating system in order to stream datato the end-user device. This means we needed to decide on the best option foran embedded media streaming server. Linux distributions offer a wide variety ofsolutions for an embedded system. Linux is also supported by Xilinx. For theZynq board, Xilinx offers an SDK which comes with a compiler for C and C++.Using this will simplify the server set up. The considerations we needed to lookat when examining these distributions were:

• Minimized Complexity• Resource Requirement• Processor Compatibility

Here we consider different viable systems such as Xillinux, Arch Linux ARM,Ubuntu and explore their potential use for the project. In order to fully understandwhat each system is capable of, comparisons between each of the operating systemswere made as well.


2.6.1.1 Xillinux

Xillinux is a Linux distribution developed specifically for use on the MicroZedboard, which we are developing our code on. This would definitely be of use duringthe development of our project. It is based on Ubuntu and has GUI support. Thiswas thought to come in handy for coding, but unfortunately the MicroZed boarddoes not offer GUI support. This solution did not seem right for the final product,as it is intended for use just on development boards.

2.6.1.2 Arch Linux ARM

This is a distribution of Arch Linux intended specifically for use on ARM proces-sors. It was designed to be as simple as possible, with plenty of room for usercustomization. This was listed as one of the distributions of Linux directly sup-ported by the Xilinx Zynq-7000. This offered a lightweight solution, and wouldnot require any resources not available from the Zynq-7000 board.

2.6.1.3 Ubuntu

It is possible to install Ubuntu on any Zynq platform. Ubuntu can provide aton of functionality to users, and is a great option for a fully-fledged end-userenvironment. For our purposes, most of what Ubuntu had to offer was irrelevant.Our goal was to pare down the functionality of the operating system we use tothe bare essentials. Because of this consideration, Ubuntu did not seem to offeranything of use that Arch Linux didn’t.

Operating System Comparison From looking at the considerations above,the choice of operating system for this project seemed clear. The MicroZed de-velopment board we were using came with Xillinux, and would prove to be theeasiest way to develop code for the project. This would be utilized throughout thedevelopment process. For the final product, we had planned to run the server onArch Linux ARM. This would have offered us the most customizability.

2.6.2 Data Representation

The Tamarisk camera offers support for both greyscale and RGB output. Whengetting project specifications from the sponsor, their preference for either was notstated. For the purpose of development, we assumed that greyscale output wasdesired. This would result in the added bonus of lower bandwidth needed tostream the output, since less bits would be needed to represent each pixel of thepicture. The other added bonus of using grayscale output was that their wouldbe less computation on the back end. If an RGB picture was desired the picture


would have to map each greyscale value of each pixel to an RGB value before thepanoramic picture could be sent to the output. Without this mapping, outputwas able to be sent from the control unit faster.

It was our intent to stream in real time the pictures coming out from the SoC chipon the camera mount. They were intended to be streamed over wireless commu-nication to a front-end device which would then display the completed picture onthe screen. The picture would then update as fast as the camera would allow. Thistime needed to be less than two seconds. Also, the display needed to be capableof pushing any error messages which need human intervention to fix. Things likemotor or camera malfunction needed to produce output to the user letting themknow which subsystem had encountered an issue. This output would be in theform of a simple text string printed over the last image successfully sent with de-tails about what went wrong. Other system interruptions like necessary periodiccamera calibration would not be sent to the end-user, because no intervention isrequired to fix this issue.

2.6.3 Development Environment

Choice of development environment can play a huge role in how fast code canbe developed. FPGA development comes with certain requirements for an envi-ronment which other devices don’t, such as the ability to simulate and testbenchVerilog or VHDL code. As a result, we focused our search for an IDE on onesspecifically created for developing on an FPGA or an SoC. Several prominentchoices included the Xilinx IDEs and Altera IDE. To wrap up the section, acomparison between the different systems is enacted in order to weighs the prosand cons of each.

2.6.3.1 Xilinx IDEs

Xilinx offers several IDEs, with several different versions. To fit budget constraints,we wanted to make due with the most stripped down IDE possible, without givingup things that we needed. Xilinx seemed to be the best option for developing onthe Zynq board, because the Zynq board is produced by Xilinx. This lead to usfocusing mostly on looking at the products listed below.

ISE Xilinx’s ISE software is a complete design suite intended for use when devel-oping for any family of FPGAs that Xilinx offers. It allows for easy implementationof high level code (C or C++), and also supports other software that Xilinx offers,such as Vivado. A free version called the WebPack is offered for free, with limitedfeatures. Fortunately the features necessary to development are all present in theWebPack version, because a one use license is far above our price range at $2995.


Vivado Vivado is another ISE used for developing for Xilinx products, specifi-cally SoCs. It comes with several components packaged together in the free Web-Pack version. Most importantly for our purposes, it comes with a simulator, sothat the code we wrote for the Zynq board could be tested before it was imple-mented. This was integral to the development process. Like the ISE, there weresome features of Vivado which the free version does not provide. These are featuressuch as logic and serial I/O analyzer, which would be nice to have and might haveexpedited the development process, but were not integral to finishing the code forour purposes.

2.6.3.2 Altera IDE

Altera is the other big FPGA designer and producer. Like Xilinx, they focused onmaking an IDE for use with their products. Since an IDE is such an importantdesign element, we researched the IDE that Altera had to offer when trying todecide which company’s FPGA we wanted to use on our system.

SoC Embedded Design Suite This product from Altera offers features similarto what Xilinx paid version of ISE and Vivado offer. One of the nice features of thisIDE that Xilinx doesn’t have is it supplies a Linux environment with the softwareintended for use on an SoC. It also offers something called a software-to-hardwarehandoff, which allows software developers to ignore FPGA development and focuson the code. Unfortunately most of the functionality offered by this design suiteis only available for use in the paid version. When comparing the free version ofAltera’s design suite to what Xilinx offers in their WebPack, Xilinx emerged theclear winner.

Final IDE Comparison After considering what each company had to offer,both in features and in cost-effectiveness, Xilinx was decided to be the best option.While both companies offer a free solution which would probably be more thanadequate to complete the coding needed for our system, Xilinx offers more in theway of features. Also, from looking at our options for FPGA in the above sections,we also found that Xilinx met our needs in cost, familiarity, and support as well.Using the IDE provided by the relevant FPGA vendor will give us an avenue fortechnical support which might not be as easy to find otherwise.

Initial Design

Once enough research had been conducted in order to make educated decisionson the design aspects of the project, designing the preliminary project was brokendown into the following segments:

• Hardware (3.1)• Software (3.2)

This was done because each section has a radically different approach with differentparts and methodologies. Attempting to mix and match portions of each sectionwould only hinder its overall design due to a clutter in organization.

3.1 Hardware

The focus of this section will be mostly the moving and components of the project.Playing by this strategy, it was much simpler to break down the section into 4smaller pieces:

• Rotational Platform (3.1.1)• Motion (3.1.2)• Base Unit (3.1.3)• Viewing Interface (3.1.4)

If you refer to Figure 3.1, you will see the design flowchart for the initial overallhardware design. The Rotational Platform portion is color coded orange, BaseUnit corresponds to blue, the Rotational Platform matches with the green, andthe Motion design aspect is found all throughout all 3 sections.

3.1.1 Rotational Platform

Of the 3 main areas that house the entire project, the rotational platform acts asthe pivotal point for the camera. With that being established, the platform wasthe foundation of the following components:

58

Section 3. Initial Design 59

Figure 3.1: Hardware Design Flowchart

• Tamarisk (3.1.1.1)• Zynq (3.1.1.2)• Wireless Communication (3.1.1.3)• Inductive Coil Interface (3.1.1.4)• Platform (3.1.1.5)

The rotational platform was to be made of printed plastic and dimensioned at5.5” in diameter. A hole small enough would be drilled directly in the middle ofthe platform so that the OMHT17-075 Stepper Motor may be installed, giving theplatform its rotational ability. For clarification of the components we were goingto place on the rotational platform, please refer to Figure 3.2.

3.1.1.1 Tamarisk

The Tamarisk camera comes with two options when configuring the hardware ofthe device[2]. The first is called the base configuration. The advantage of thisconfiguration is that it allows for RAW frames to be transferred in 14-bit format.It also provides more control over the shutter of the camera, which will help withthe timing section. The other configuration includes a feature board which allowsfor USB serial control as well as analog video out.


Figure 3.2: Rotational Platform Dimensions

The second configuration of the camera was found to be unfavorable since it doesnot allow access to the RAW information coming from the camera. The BaseConfiguration was chosen.

Pin Layout If you refer to Figures 3.3 and 3.4, you can see that there are 60pins in the base configuration. However, only 28 of them are used. 14 pins areused for the pixel data, 8 pins are used to control the camera and to get the statusof the camera, and the rest correspond to power and ground[12].

Figure 3.3: ST4 Tamarisk Pin Connection - Pending DRS Approval Chap-ter A.13


Figure 3.4: Tamarisk Pin Connections

Data Out Odd pins 59 - 37 contain the first 12 bits (bits 0 - 11) of the ParallelDigital Data Output, even pins 48 - 46 contain bits 12 and 13 of the Digital DataOutput.

Clocks Even pins 44 - 40 are the clock pulses; 44: FSYNC – which is the framesynchronization clock pulse. 42: LSYNC – which is the horizontal clock pulse. 40:PCLK – which is the main clock pulse of the camera.

Camera Control Even pins 16 - 12, 26 - 24 and 38 were all used to control thecamera. Pins 16 and 14 were used for UART commands which can modify theway the camera outputs and controls camera features such as AGC and ICE. Pins26 and 24 were used to determine the state of the shutter. The state of the shutterwas important because it allowed for a precise idea of when not to grab an imagesince the camera was unavailable at that time. Pin 38 was used for GENLOCK –a feature which allows for a manual clock pulse to replace PCLK.

Power Odd pins 7 - 1 and even pins 60 - 56 were used for all grounds, even pins8 - 2 were for VIN – 3 -5.5 V – and even pins 54 - 50 were used for VCC IO –1.8V Power Supply.


Timing The timing on the Tamarisk camera was set by a fixed clock whichoperates at 10 MHz. This determines much of the timing for when data wasread to the control unit, and when the motor rotates. Once the camera captures aframe, the data would be available to be read from the time stamp range of .5 ns to10 ns after the capture. The time between rising edges is 100 ns. This means thatan entire frame can be transmitted from the camera to the ArtixTM-7 in the spaceof 320×240×100ns = 7.68 ms. This was convenient because the camera needsabout 5 ms for the capacitor to dissipate its energy before it can capture anotherframe, and 10 ms to capture the frame for a total of 15 ms minimum betweenframe captures. This meant that the limiting factor on how fast a full panoramicpicture could have been outputted was dependent on how fast the motor can move.

Most of the control of the system was based around when the SoC receives a fullframe. We planned to implement logic in such a way that once the input interfacerecognized that a full frame had been received, the control sent out a signal tothe motor control to rotate 9. The other possibility was that the camera has tocalibrate. This meant no data can be outputted to the System on a Chip(SoC),and all movement must be halted. The time for the calibration to take placewas 440 ms, but sometimes has to be performed several times in order to ensureproper calibration. The camera would send out a signal when this procedure wascompleted and the camera would be available for use again.

3.1.1.2 Zynq

Pin Configuration The Zynq Z7010-CLG225 has 169 Pins which all need tobe connected to various components[13]. The camera would require 14 pins fordata and 8 for control. The LED’s required a control line. The RAM required 47pins to be connected to the Zynq as shown in Figures 3.5 and 3.6.

Two buffers were going to be needed for the production of a finalized singlepanoramic photo. These buffers were to be DDR3 memory devices outside ofthe Zynq which would store images before and after processing[14]. The firstbuffer would hold incoming frames taken by the camera, taken as serial input bythe SoC. For the sake of safety, and not losing frames, this buffer was going to bebig enough to hold 3 frames. This is 153,600 bytes or 153.6 KB. To play it safe,we had made this buffer 200 KB in size. The other buffer would have been forholding the panoramic picture as it was being stitched together. This is the sizeof the final picture file, calculated earlier as being 6.144 MB. This was rounded upto be 6.5 MB of buffer for the panoramic picture to be stored in. The SoC wouldhave handled incoming pictures in real time and decide when to take a frame outof the incoming buffer.

The camera output needed 26 pins to establish a connection and receive an imagebetween the SoC. This meant the SoC needed to have this quantity of pins reservedand configured for communication with the camera. The pins utilized are outlinedhere:


Figure 3.5: DDR3 Configuration as seen by the Zynq Z7010-CLG225

Figure 3.6: DDR3 Configuration as seen by the RAM


• Fourteen pins represent gray-scale values ranging from 0 to 214

• Two pins for UART communication• One pin for the clock• Two pins for video synchronization• Two pins for ground• One pin for voltage (high)• One pin to give the camera power• One pin to select UART, USB, or RS-232 communication• Two pins to establish camera calibration

LEDs on the SoC were going to be programmed to indicate input and output fordebugging purposes. The Tamarisk camera and the motor both were to send errorsignals if something went wrong with either of the systems. These signals wereto be recognized by the board and sent to output in a legible form so that theycould be fixed if intervention was needed from the end-user. If no interventionwas required, the error code did not need to be seen by the end-user, and was notdisplayed.

MicroZed The MicroZed is a development board that was used to prototype-/debug/ software. This board was also used as our base model for the PCB thatwas designed[15].

The MicroZed’s main computing unit was the Zynq-7000 - 7Z010, which was theSoC that is used on our board. Some of its key features include:

• 1GB of DDR3 SDRAM• 128 Mb of QSPI Flash• Gigabit Ethernet• USB-UART• 100 User I/O• JTAG• 33.33 MHz oscillator

3.1.1.3 Wireless Communication

The output was to be transmitted through a USB Wi-Fi interface. In order todo this we were going to have a USB port on the PCB which interfaced with theLinux server on the ARM processor. The USB needed a transceiver as well asthe connection to connect to the wi-fi dongle[9]. Once the connection was madethe operating system would have taken care of all the handshakes necessary forwireless communication.


3.1.1.4 Inductive Coil Interface

The design chosen for the inductive coil on the rotational platform and the designon the stationary base is the same[11]. The solenoids have the same radius tomaximize efficiency. The coils have the same number of loops (n). The coils aremounted directly above one another. Any misalignment ensuring the coils aremounted with the origin of each solenoid about the rotational axis would end upwith inconsistent power transfer from base to platform. The coils are made out ofthe same material, copper. All of these factors ensure a good coupling between thecoils. Also, reducing the distance between the respective coils as much as possibleincreases the coupling of the coils.

Winding the actual coils was done manually. In order to ensure ideal quality (q) ofthe inductive winding there were several considerations. The coil had to be wounduniformly as the loops needed to be as parallel to the pairing loop. The spacingbetween each loop was uniform as well. Wrapping the inductive coil has been doneon a jig of some kind to ensure uniformity. Calculations on the inductive loop areas follows:

L =µ ∗N2 ∗ A

`

Q =ω ∗ LR

N = 12

A = π ∗ r2

r = 5cm

A = 78.5cm2

` = 5cm

µcopper = 0.999994H/m

L = 2.26mH

Presistivityofcopper = 1.796 ∗ 10−8Ω

R = ((2 ∗ π ∗ r ∗N) + `) ∗ P

R = 6.86 ∗ 10−6Ω

Q = 329.42

The quality factor of the designed induction is 329.42 which is considered a goodquality factor. The quality factor of the coil being good means the inductivepower transfer from one coil to the next is more efficient. Therefore, there is lessheat generation by the system and less interference from other components. It istheoretically possible to get infinite quality. However, attaining a Q factor of over


1000 is difficult. Given our space restraints a Q of 329 was more than sufficientfor the power transfer.

3.1.1.5 Platform

The platform holds many of the significant subsystems for this project. On it wouldhave been mounted the Tamarisk camera, which would feed its data lines down tothe PCB. The Zynq was also to be located on this platform, as well as the severalLEDs that were going to be used to communicate down to the motor. The Linuxserver is embedded on the Zynq and was going to interface with the ArtixTM-7 andthe USB Wi-Fi dongle. Apart from the motor, light sensor, and motor controller,all necessary components of the system are housed on the rotational platform.The specifics on each of these systems are covered in their respective sections.

As a whole, we constructed the platform so that it does not pose any issues whenit is being rotated. If the board is not balanced with approximately equal distribu-tions in all directions, the stability of the system is affected. Mass can optionallybe added to the rotational platform in the form of counterweights. This removedthe design concern for everything to be planned out before the PCB is printed. Asa base design, we constructed a SolidWorks drawing and rendering of the platformthat hosts all of the subsystems listed above. Figure 3.7 provides a visual detailingall of the dimensions and hole placements for the platform.


Figure 3.7: SolidWorks Platform Dimensions

3.1.2 Motion

The motion of the Tamarisk camera would have defined how it outputs the panoramicview. The Tamarisk 320 model we would’ve used contains a 9 Field of View(FOV)which defined how the camera moves in general. Simply put, the camera travelsa full 360 while taking pictures every 9 for a total of 40 pictures. This was tobe done at the maximum possible speed that the motor and Tamarisk can achievewhile working in sync with each other. For a better visualization regarding theTamarisk FOV and how it would create its panoramic effect, please refer to Fig-ure 3.8.


Figure 3.8: Tamarisk FOV illustration

3.1.2.1 Light Emitting Diodes

In order to establish communication with the motor, optical communication wouldhave been utilized. To ensure sufficient lighting would be supplied to the base,an array of LEDs were to be used to send the commands. The Zynq was to behardwired to the LED array and would instruct the LEDs to blink at a frequencyof 38kHz. An output pin from the Zynq would have handled the oscillation trigger.The LED ring would be supplied sufficient power from the Zynq to not need anyadditional power regulation. The LEDs in the circuit are IR LEDs with wavelengthof 940nm[16], a common wavelength used in IR remotes. This would send light toa sensor connected to the motor controller, 3.1.3.7. Each LED consumes typically20mA when powered on and takes 1.5V to turn on. The voltage output from thepins of the Zynq peak at 3.35V which would mean the LEDs should be put inseries with a resistor to ensure they do not burn out. The whole circuit wouldconsume less current than the Zynq is rated to output for each pin. The totalcurrent draw of the top part of the circuit is less than 53.7mA. The LEDs thatwould have been used have an extremely wide 120 viewing angle to ensure thelight emitting from the diode triggers the sensor. Figures 3.9 and 3.10 show thesimulated circuit and the output from the areas of interest.

V in = V diode+ IR

3.35V = 1.5V + (20mA)(R)

R = 92.5Ω


For clarification on the dimensions and layout of the LEDs that would have beenused, please refer to Figures 3.11a and 3.11b. Upon inspection of the figures, wecan see that the LEDs would have fit nice and snug between the base unit androtational platform.

Figure 3.9: LED Schematic

Figure 3.10: LED Simulation


(a) LED physical appearance (b) LED physical measurements

Figure 3.11: LED for PCB - Pending OSRAM Approval Chapter A.9

3.1.3 Base Unit

The base unit for the project acts as the central hub where the project is stored.Initial specifications of the base unit are that they are a 6”x6”x5” and made ofprinted plastic. There would have been 4 holes that are placed in conjunctionwith the dimensions of the FPGA board and ultimately the rotating platform andTamarisk camera. There would also be a hole directly in the middle of the base unitso that the OMHT17-075 Stepper Motor may be placed underneath but still havethe rotating shaft above the base unit so it can maneuver the rotational platform.For clarification on how these holes are be placed, please refer to Figure 3.12 whichcontains a SolidWorks drawing of the initial base unit design with the holes placedin it.


Figure 3.12: Base Unit Solidworks drawing With Dimensions

Since the base unit is ultimately hollow, this allows us to hide a lot of differentcomponents within the unit so that they are protected from outside factors. Withthat being said, the STR 2 Driver and and OMPS300A48 Power Supply Unit arenested inside the base unit as well as any other wires we can fit without affectingoverall performance. Though having the base unit to house the OMHT17-075Stepper Motor, STR 2 Driver, and OMPS300A48 Power Supply, the compilationof all components being included in the base unit are:

• Power Supply Unit (3.1.3.1)• Battery (3.1.3.2)• Voltage Regulators (3.1.3.3)• Stepper Motor (3.1.3.4)• Motor Driver (3.1.3.5)• Motor Controller (3.1.3.6)• Light Sensor (3.1.3.7)• Inductive Coils (3.1.3.8)


3.1.3.1 Power Supply Unit

Careful consideration went into the selection of the power supply unit of the motor.The power supply unit had to be able to support both the driver and motor ofthe project. Initially, we had considered opting for the OMPS300A24 model. TheOMHT17-075 Stepper Motor is actually powered by the STR 2 driver can useanywhere from 12-48 volts of power in order to operate[10]. We figured that inorder to be safe with the voltage usage of the motor, we could settle with theOMPS300A24 model since it gave us exactly what we needed and cost efficiencyis extremely important to the integrity of this project.

However, upon closer inspection of the revolutions per second(RPS) data providedfrom the product sheet, we saw that with our current load of the motor andcasing/housing of it, it was best to select the OMPS300A48 model since it provideda 48 volt output that would provide the additional RPS that we would need. Ifyou refer to Figure 3.14, the schematics and layout for the OMPS300A48 areprovided. Upon inspection of this schematic, we can see that the dimensions of itfit quite easily under the housing unit. As for the RPS aspect, in Figure 3.13, wecan see that the RPS for the OMHT17-075 Stepper Motor model has significantlyreduced RPS with higher loads. But with the OMPS300A48 allows for mitigationof the lost RPS compared to the 12 or 24 volt output versions.

Figure 3.13: RPS graph data - Reprinted with Omega Engineering ApprovalChapter A.3


Figure 3.14: OMPS300A48 Schematic - Reprinted with Omega EngineeringApproval Chapter A.3

3.1.3.2 Battery

A battery was to be fitted on top of the rotational platform in order to powerthe Zynq board and Tamarisk camera. The power requirements for the rotationalplatform components are:

• Zynq Board= 5 V @ 500mA• Tamarisk Camera= 3.3 V @ 600mA

With these power requirements known, we can calculate what kind of power wewould need from a battery:

Power = V oltage(V ) ∗ Current(I)


5V + 3.3V = 8.3V

500mA+ 600mA = 1100mA = 1.1A

Power = 8.3 ∗ 1.1 = 9.13Watts

This means that all of the rotational components would require approximately 9watts of power or 10 watts to be on the safe side. Since the Zynq Board required5 volts, we can go with a 5 volt or higher battery with at least 2 aH power ratingso that we could get the required power.

In terms of product, we would have chosen the Power-Sonic PS-628 battery. It israted at 6 volts and 2.9 aH making it more than qualified to power the rotationalplatform components. A little bit of lee-way is added in our specs for powersince batteries tend to degrade in voltage output when they are used for extendedperiods of time.

The main problem with this kind of setup is that the battery would be a littlebulky for our project. Measured dimensions put the battery at 2.6 inches(length),1.3 inches(width), and 4.06 inches(width). We would have to put the batteryon its side in order to even consider placing it on the rotational platform. ThePower-Sonic PS-628 battery also weighs approximately 1.3 lbs which translates toroughly 20.8 ounces, which is over 1/3 of the OMHT17-075’s weight threshold.

3.1.3.3 Voltage Regulators

Having the battery would not be enough to power the components on top of therotational platform. Yes, we have enough power to do so, but the power must beproperly allocated to the right areas in order for the project to work effectively.Regular voltage regulators may not cut it in this case, since most voltage regulatorswould require at least 8 volts and cut down from there[17]. Since our battery wouldhave been a 6 V, we can use a low drop out(LDO) regulator that would regulate anddrop output voltages even in your input voltage is less than 7 V. Based solely onthe Zynq schematic and data sheet, the board takes different voltages that rangefrom 1-5 volts for different operations on the board. This means that differentvoltage regulators would need to be designed for the various portions of the Zynqboard. For an example of how the voltage regulator would work in general, pleaserefer to Figure 3.15. Figure 3.15 is a prime example of how a voltage regulatorcircuit works using a 7805 Voltage Regulator model.

Table 3.1 lists the different LDO voltage regulators that are needed in order topower the Zynq board. Each model is placed in a similar circuit resembling Fig-ure 3.15 with adjusted values that reflect each particular model.


Figure 3.15: Voltage Regulator Circuit

Input Voltage(V) Output Voltage(V) LDO VR Model6 1 LP3879MR6 1.5 MIC5317-1.51MT6 1.8 LP5996SD6 3.3 LP5996SD6 5 LT1763

Table 3.1: Needed LDO Voltage Regulators

3.1.3.4 Stepper Motor

The selection of the motor in terms of design created a formidable choice betweena lot of the different stepper motors on the market. Ultimately, we have settledupon using the OMHT17-075 stepper motor as our motor of choice[18]. Thiswas due to the relatively cheap cost of the motor being $74.00 coupled with itssize, availability, and maximum achievable torque. The Tamarisk camera actuallyweighed approximately 2.25 ounces, leaving a lot of lee-way in terms of weightthat the motor can support for the housing and other peripherals. If you refer toTable 3.2, the other specifications can be seen in an organized table.

In regards to overall size, the motor measures approximately 1.85”, which is theperfect size for hosting the camera without taking up too much space. Couple thiswith the overall strength of the motor and it creates a great synergistic benefitbetween the different components that are on the project. The bottom half ofFigure 3.16 portrays the other dimensions of the motor and we can easily see howthe dimensions of the motor contribute to saving on space for the project. Forbetter clarification on the placement of the motor within the base housing for theproject, please refer to Figure 3.18.


Table 3.2: OMHT17 Specifications - Reprinted with Omega Engineering Ap-proval Chapter A.3

Figure 3.16: OMHT17 Schematic - Reprinted with Omega Engineering Ap-proval Chapter A.3

Heat is another important aspect that we must take into consideration when itcomes to running the OMHT17-075. Since step motors convert electrical powerinto mechanical power, there can be a lot of heat generation between the OMHT17-075 Stepper Motor that is dependent entirely on the motor speed and power supplyvoltage. Since there is heat generation, time must be allotted to allow the heatto dissipate. The OMHT17-075 Stepper Motor will be moving in incremental”ticks” with small breaks in between to allow the Tamarisk camera to take in databefore the next ”tick”. Based off the data sheets, it will take the Tamarisk cameraapproximately 8 ms to take in data. From here, we can calculate the approximatethe rate of total heat dissipation using a rate of heat transfer equation making afew reasonable assumptions for theoretical purposes:

Rate = K ∗ A ∗ (T1 − T2)/D


where:

• K= Thermal Conductivity Constant=plastic=.7• A=Surface Area(cube)=6 ∗ (L2)=6 ∗ ((1.65)2) = 16.335squareinches• T1= Maximum Safe Motor Temperature(c)=50 Celsius• T2= Average Room Temperature= 21 Celsius• D= Thickness=0.1”

Plugging these all into the equation:

(.7) ∗ (16.335) ∗ (50 − 21)/.1 = 3, 316.005 3, 300J/s

Since we are dealing with milliseconds, we can divide our number by 1000 in orderto convert it to J/mS: 3300/1000 = 3.3J/mS Since there are 8 mS of downtimebefore the Tamarisk would have to move again, there are 8 ∗ 3.3 = 26.4Joules lostor .0139 Celsius between each Tamarisk cycle.

3.1.3.5 Motor Driver

The motor driver we have chosen for the project is the STR 2 DC AdvancedMicrostep Drive. This driver allows us to program the OMHT17-075 StepperMotor to whatever incremental rates we need[8]. In this case, the motor hasan angle change of 1.8 with a 9 FOV from the Tamarisk camera. Doing basicdivision of 9/1.8 = 5 steps of impulse that the STR 2 has to send to the OMHT17-075 Stepper Motor in order to get a ”tick” for the motor to move in the exactplacement of the camera.

The STR 2 allows us to also setup micro stepping in case we need to do specificcases of camera movement. A speculated use of this project would be for surveil-lance and the STR 2 micro stepping allows us to set up different ”tick” incrementsthat are beyond just the 1.8 movements. The STR 2 is also able to send clockwiseand counter clockwise pulses to the OMHT17-075 stepper motor which allow forfurther potential customization to whatever the project needs.

Referring to Figure 3.17, we can see that the dimensions of the STR 2 easilyfit within the 6”x6”x5” housing for the project. For clarification on placementbetween the STR 2 and housing, please refer to Figure 3.18.


Figure 3.17: STR 2 stepper Driver Dimensions - - Reprinted with AppliedMotions Approval Chapter A.2

Figure 3.18: STR 2 stepper Driver and OMHT17-075 Housing Placement


3.1.3.6 Motor Controller

A closer look at the different components of the STR 2 Driver is portrayed inFigure 3.19. If you pay attention to the lower left side of Figure 3.19, you can seethat there are pins for the different inputs of the STR 2 Driver. This is importantto the overall design in that the Motor Controller consists of 2 different componentsworking in conjunction with each other. The STR 2 driver is able to send signalsto the OMHT17-075 Stepper Motor through a series of impulses. However, if youwant specific timing setups for the motor like needed for this project, you musthave logic inputs that come from a programmable logic circuit(PLC) or just asource of step signals.

Figure 3.19: STR 2 Block Diagram - Reprinted with Applied Motions Ap-proval Chapter A.2

Since cost effectiveness was an important aspect to the project, we have opted forusing a source of step signals in order to get the impulse pattern that we need.For our source of step signals, we originally opted to use programmable LEDs thatare wired to the input pins of the STR 2 Driver. The hypothetical input/outputpins are laid out as such in Figure 3.20. Simply put, whenever the LED turns on,


the same logic input is sent to the STR 2 Driver which consequently powers theOMHT17-075 Stepper Motor. For clarification on how the wiring occurs betweenthe STR 2 Driver and the LEDs, please refer to Figure 3.21.

Figure 3.20: STR 2 Input/Output Pins - Reprinted with Applied MotionsApproval Chapter A.2

Figure 3.21: STR 2 Example Wiring - Reprinted with Applied Motions Ap-proval Chapter A.2

Configuration of the STR 2 Driver must be performed as well since it is compatiblewith multiple motors that all use different settings. There are 8 switches on the


side which can configure the STR 2 Driver to perform different kinds of actions.However, permutations of buttons 1-3 are reserved for the different motor modelsoffered with the compatibility of the STR 2 Driver. This is because differentmodels have different current and voltage requirements in order to run efficiently.For our case of the OMHT17-075, switches 1 and 2 will be left up and switch 3will be pressed downward. Figure 3.22 illustrates how the switches are arrangedin order to create the optimal conditions for the OMHT17-075 Stepper Motor.

Figure 3.22: STR 2 Motor Configuration - Reprinted with Applied MotionsApproval Chapter A.2

3.1.3.7 Light Sensor

The receiving end of the optical interface would have been a phototransistor. Thephototransistor would have sat below stationary as the ring of IR LEDs rotates.The phototransistor requires 1mW/cm2 of light to trigger the transistor into theon position[19]. This is considered Vth or the threshold voltage of the transistor.Considering the initial LEDs chosen are running at 20mA at 1.5V the output lightfrom each assuming ideal operation is 30mW of light. However, LEDs are typicallyonly 80% effective at transforming power into light. This would mean a realisticoutput of 24mW of light are emitted from each LED. Assuming the light wasuniformly distributed about the 120 FOV of the LED and taking into account


the respective spacing of the LED to the light sensor as well as the dimensions ofthe phototransistor and the LED featured in Figures 3.11b and 3.23b the followinghypothetical calculations arise:

6.1mm− 1.7mm = 4.4mm

4.4mm ∗ tan(120/2) = 7.62mm

π ∗ (7.62mm)2 = 182.4mm2

π ∗ (5mm/2)2 = 19.6mm2

24mW/((182.4mm2/(19.6mm2) = 2.58mW

(2.58mW )/(.196cm2) = 13.16mW/cm2

13.16mW of light would hit the phototransistor given the current spacing theFOV of light emitting and the size of the phototransistor. This is plenty of lightto trigger the 1mW/cm threshold. The diodes, if oriented correctly would be ableto trigger a reaction from the sensor. The wiring of the light sensor to LED alongwith appropriate signal output is shown in Section 3.1.2.1 featured previously onpage 68. Figures 3.23a and 3.23b provide an in-depth visualization on the layoutand dimensions of the phototransistors initially considered to be used.

(a) Phototransistor physical ap-pearance (b) Phototransistor physical mea-

surements

Figure 3.23: Phototransistor for base unit Pending LiteOnIt Approval Chap-ter A.10

3.1.3.8 Inductive Coils

The base inductive coil is identical to the inductive coil on the top of the system.Although inductive coupling is more efficient at distance using AC, DC coupling


is efficient enough for the distance and power which our system is trying to ac-complish.

3.1.4 Viewing Interface

The panoramic output would be available for any device with a modern browserinstalled on it. Given the high resolution of the picture, optimally the outputwould have been viewed on a high resolution monitor. We split the outgoing videointo 4 sections, each 90 degrees field of view, so that it was easier to view theoutput on a wider variety of devices. Although the output from the camera wasformatted with 14 bit greyscale, most displays are not capable of displaying pixelswith 14 bit values. Because of this, we scaled down the value of each pixel to an8 bit representation, making the image more accessible to any type of display.

Figure 3.24: Web Page View

3.1.4.1 Web Site

The Website would have had the ability to allow the user to change various camerasettings as well as some of the gain and levels that the ArtixTM-7 uses to correctthe images. As seen in Figure 3.24 there would be a portion where the user can go


into the settings and change the way the camera functions. These controls are theones that DRS provides natively on the camera, which are an interface to thosecontrols. At the bottom there would be a message box that shows any errors thathave occurred with the communication to the camera. It was placed so that theuser can see the error codes without having to search for them. In the center thereare images coming from the camera explained in Section 3.1.4.2.

3.1.4.2 Display

As mentioned earlier, the image would split into four different sections. Given thatthe horizontal resolution of each frame is 320 pixels wide and we are taking 40frames to constitute an entire image, the final image is 12,800 pixels wide. Evenfor some of the best monitors available this is too wide to display on one screen.Dividing this into four, each section has a resolution of 3200 by 240. The sectionsare laid out with two above the other two. Each covers 90 of the total picture.Each section is labeled so that the end-user can easily identify where things in thepicture are located relative to the location of the system as shown in Figure 3.24.

3.1.5 Hardware Flaws

Unforseen circumstances in the design implementation process of the project inaddition to the rigorous time constrains forced some redesign. The redesign issueswhich will be addressed here are exclusively hardware related.

• Computing PCB 3.1.5.1• Tamarisk 3.1.5.2• LED/Light Sensor 3.1.5.3• Wi-Fi Communication 3.1.5.4• Inductive Power System 3.1.5.5

3.1.5.1 Computing PCB Flaws

The Zynq has a fine pitch BGA which is difficult to route pins for and challengingto mount. Instead of fabricating our own flavor of the Zynq with a smaller BGAand optimized hardware for our purposes a decision was made to redirect thefocus of the PCB development onto a carrier board for the existing MicroZedboard which had more than enough processing power to accomplish the tasksrequired. The carrier was fabricated with the CC3200 module to handle the Wi-Fi communication of the system, a SS4 connector to connect the carrier boardto the Tamarisk camera and berzerker 100 rails to attach to the MicroZed. Evenafter the carrier boards fabrication issues getting communication to work betweenthe hardware and the software became problematic.


3.1.5.2 Tamarisk Flaws

The Tamarisk in base configuration uses a very uncommon ST4 connector. Foraccessing the pins on the camera to power the device, initialize a data stream andactually get data out of the camera there was an unnecessary difficult step. Inan attempt to interface with the pins on the Tamarisk a small break out boardwas first fabricated. The board fabricated for this purpose had issues. Therewere unintentional shorts between some of the traces. These made configuringthe Tamarisk not possible in our prototype environment. This did not deter thegroups intent on sticking with the Tamarisk but time was spent and wasted onthis endeavor. Another board was fabricated connecting the Tamarisk to all theright voltages and pins to the MicroZed using a carrier board. The MicroZed andthe Tamarisk would both plug into the board and the appropriate connectionswere made so that initializing the Tamarisk using the MicroZed would be possi-ble. However the SS4 connector which connected to the ST4 on the Tamarisk wasmapped incorrectly the mirror image of the pins were mounted. By shifting overthe connector and soldering lead wires this mistake could be amended. This wasa difficult environment to debug though and should any issues with the commu-nication of the camera and the MircoZed it would be impossible to attach anytest equipment to the system. Switching cameras was important to get an easy todebug environment and a widely supported connection type.

3.1.5.3 LED/Light Sensor Flaws

An optical communication from the rotating platform is possible. During designwe did not consider the prospect of a two way communication between the topand bottom platform. The first solution proposed involved pulsing an LED on thetop platform and receiving the pulse on the base platform and moving the motor.The light sensor we were using was digital and it only sensed light every 100msand would occasionally miss pulses of light. Robust communication method wasneeded with minimal lag and two way communication between the base platformand the rotational platform so acknowledgments could be sent.

3.1.5.4 Wi-Fi Communication Flaws

The initial design called for pulling images from the camera, stitching them to-gether and hosting them on a web server which was accessible over the network.The MicroZed would need to be equipped with Wi-Fi which could stream an up-dating web page and sharing the information over the network to clients. A currentrealistic data rate transfer over Wi-Fi is around 500Mb/s considering lost packets,retransmission and overhead. This Wi-Fi limit was fine in the initial design whenthe camera had a lower resolution. The new camera has a higher resolution theimages take more data to stream. Wi-Fi is not sufficient to support rate of datastream out of my camera. Ethernet is more reliable and has a higher bandwidth.


Unfortunately, continuously rotating the top platform will not be possible with anethernet connection without additional design consideration.

3.1.5.5 Inductive Power System Flaws

The inductive power system was built to power the Tamarisk and the MicroZedand very low power additional sub-systems. The new thermal camera consumesfar more power than the system was designed for sending power wirelessly wouldrequire a complete redesign of the system. The inductive system worked for theload it was designed for but the energy consumption of the stand-in camera madethis not a viable substitute.

3.2 Software

The code for the project is split up into various distinct parts:

• Camera Communication (3.2.1) - How the system will communicate to thecamera.

• Motor Communication (3.2.2) - How the system will communicate with themotor.

• Motor Control (3.2.3) - How the system will control the motor.• FPGA (3.2.4) - The tasks that the FPGA will have in the System.• Embedded Linux (3.2.5) - The tasks the the operating system will have in

the system.• End-User Interface (3.2.7) - What the end users interface will look like.

3.2.1 Camera Communication

All of the information regarding the camera software communication was takenfrom Tamarisk software interface control document[20].The Tamarisk camera wascapable of outputting in serial through several routes. The most common linksused were the RS-232, USB or UART. The RS-232 offers a 57.6k Baud rate bydefault, enough for the purpose of communicating to the Zynq. However, in orderto get output in a digital form, the use of UART was required. Familiarity withUART led the group to determine this would have been the best way to receiveoutput from the camera. The baud rate could have been set to whatever value isneeded when using UART, so the default value of 57.6k was be used. This wasable to be adjusted if it was felt that adjustment was needed. For an in-depthexplanation and visualization, please refer to Figure 3.25.

The Tamarisk supported a set of hexadecimal instructions which make debuggingand adjusting settings easy. Communication back to the camera was done through


Figure 3.25: Data Flow in Software

the Zynq, as this was the only point of communication to the camera. The Zynqwas configured to signal certain LEDs when communication errors occur to aid indebugging.

There are 24 commands which were of interest to the end-user and us as thedevelopers of this project. These commands handle every setting on the camerafrom time between camera calibrations to the auto-gain correction level. Thesecommands were sent in the form of messages, which follow a set format, elucidatedhere.

• One byte, 0x01 - Signals the start of the message• One byte determines command to be performed• One byte to specify how many parameter bytes (N) follow• N bytes to pass whatever parameters are needed• One byte for the checksum


3.2.1.1 Setting Up UART on the Zynq

Since the Zynq was a completely programmable chip there are some configurationsthat need to be done in order to allow for this communication. Using the Xilinxsoftware. Xilinx initially made it easy to configure the pins in software as shown inFigure 3.26. Each component on there needs to be added before any programmingcan be done if not the Zynq becomes unaware of what hardware is attached to it.UART was apart of the MIO ports which the Zynq Z7010 had 31 usable MIO. Each

Figure 3.26: Xilinx Software Block Design

MIO port can only be taken up by one peripheral as demonstrated in Figure 3.27.

Since we were using the Zynq Z7010, we were limited on the amount of ports wecan use. Therefore, we chose the pins 52 and 53 as shown in Figure 3.28 for theUART so that we had USB available.

3.2.1.2 Programming the UART

This was considered a peripheral on the Zynq. Embedded Linux was able to detectwhen there was a serial port attached to the hardware. This was how we sent thecommands to the camera. We have the option to generate a piece of software thatinterfaces with the camera by sending it the controls that the user selects throughthe UI (WebSite).

The simplest way to do so would have been to write a Python script that interpretsthe users input on the website and then sends the commands to the camera.


Figure 3.27: Xilinx MIO Configuration

Figure 3.28: Xilinx MIO UART Configuration

PySerial was a package that allows for serial communication in the Python lan-guage. An example of how to write to the camera is demonstrated in Figure 3.29.Once the command was written to the camera the camera will reply. Figure 3.30shows how to read the information that would have been coming from the cam-era to make sure that it executed the command correctly. If the camera did notexecute the command correctly there was a certain amount of times that the com-mand would resend before a timeout occurs. At that point the user would bealerted that something went wrong with sending that command to the camera.From there it was up to the user to decide what to do with the information nowpresented.

3.2.1.3 List of Commands that will be sent to the camera

There are 24 commands that the camera was able to receive over UART. Table 3.3lists all the commands with their hex command value and a brief description[20].


Figure 3.29: Serial Write to Tamarisk


Figure 3.30: Serial Read to Tamarisk


Instruction Function0x12 Set rate of camera calibrations0x13 Gets rate between camera calibrations0x1E Set strength of ICE filter0x22 Set ICE min and max values0x23 Enable ICE mode0x25 Automatic calibration activity query0x26 Enable automatic calibration0x27 Force in non-uniformity correction (NUC)0x28 Enable black-hot scheme0x29 Enable white-hot scheme0x2A Set Auto Gain Correction (AGC) mode0x32 Set AGC gain manually0x33 Set AGC level manually0x82 Set AGC gain bias manually0x83 Set AGC level bias manually0x84 Set AGC region of interest0xAC Toggle auto-calibration0xCF Select video orientation0xB0 Set non-volatile parameters0xB3 Set non-volatile parameters to default0xB5 Get values of non-volatile parameters0xD7 Select digital video source0xF1 Set baud rate0xF2 Get system status0xF4 Select test pattern

Table 3.3: Tamarisk UART commands of interest

Set rate of camera calibrations This command allows the user to specify howlong the camera should wait between automatic calibrations. It takes an integerwhich equates to the total amount of minutes between calibrations. If this is setto 0 the only calibrations that are done are the mandatory ones. When receivedand processed correctly this command will respond with an acknowledgement.

Gets rate between camera calibrations Sending this command caused thecamera to send back a string specifying what the period between camera calibra-tions was currently in seconds. This command works in conjunction with the 0x12command to set the period.

Set strength of ICE filter Before using this command we must enable ICEmode, the 0x23 command. This command allows you to specify a value between0 and 7 which specifies the strength of the ICE. Low values of ICE strength are


used in settings where you would expect to have lower contrast. High values areused in settings where the environment is changing frequently.

Set ICE min and max values This command performs a similar function to0x1E. Instead of taking an integer between 0 and 7, this takes a 0 or a 1 value. A0 value sets ICE to a strength of 0, and a 1 value sets the ICE to a strength of 7.This could be valuable if the camera is changing locations drastically.

Enable ICE mode This command is fairly self explanatory. It takes in a valueof either 0x0000 or 0x0001. A 0 value turns ICE mode off, while a 1 value turnsICE mode on. We used mostly ICE mode during development, but want to leavethe choice of whether to use it up to the end-user.

Automatic calibration activity query Sending this command to the systemsuccessfully results in a returned integer value between 0 and 2. The meanings ofthese values are listed below.

• 0 - There is no calibration currently being done.• 1 - A periodic time-out is being done. This is the calibration whose period

is specified with the 0x12 command.• 2 - A change of temperature range has occurred, so the camera is recalibrat-

ing to be able to show a wider or smaller range.

Enable automatic calibration This command is not used frequently by theend-user. It is intended to completely turn off or on automatic camera calibrations.In development we want to use this command to stop calibrations if we want toperform a specific kind of calibration, either range change or regular. This wouldprevent a different calibration from being triggered while ours is going on. Mostof the time we want to leave automatic calibration enabled. This command takesa value of 0 or 1, with 0 being disable and 1 being enable.

Force in non-uniformity correction (NUC) Use of this command allowsus to make the camera calibrate any kind of pending calibrations from disablingautomatic calibrations. This could also include the range change calibration. Wecan also specify the value of 3 or 4 with the command. A value of 3 performs thecalibration as normal, and 4 performs them with the shutter disabled.

Enable black-hot scheme Sending this command changes the default camerasetting from a white-hot scheme. This causes the camera to represent warmerobjects as black, as the name implies. We left the choice of how to display thethermal image to the end-user, so this command is be needed.


Enable white-hot scheme If the end-user wishes to switch back to white-hot,they can send this command which switches the display back again. This is thedefault option, but must be implemented because of the option to change to black-hot.

Set Auto Gain Correction (AGC) mode AGC mode is an alternative toICE mode. The two cannot be in used in conjunction with one another, so inorder to use this command ICE must be disabled. This command takes in aninteger with a value from 0 to 2, whose meanings are shown here.

• 0 - Freezes the AGC conversion at the gain and level it is currently at.• 1 - Sets AGC in automatic mode, using log base 2 histogram equalization.• 2 - Allows the end-user to custom set the AGC gain and level.• Any other value entered here will not be recognized, as they are reserved by

the system.

Set AGC gain manually This command can only be used when the camera isset to manual AGC mode. The command takes in an integer value between 0 and4095, where 0 is the minimum gain and 4095 is the maximum. The system usesthe function gain = 256/(4096 −manual gain value). So a value of 0 would givethe minimum gain a value of 1/16. Unity gain would be achieved if the user wereto enter a value of 3840, which corresponds to a gain value of 1. Max gain usingthis formula comes out to be 256.

Set AGC level manually Similar to the command which sets the AGC gainmanually, this command can only be used when the camera is set to use manualAGC mode. Similar to AGC gain, this command takes in an integer value between0 and 4095. It does not use an equation to convert to a different value. Instead,0 is the minimum level and 4095 is the maximum level. This parameter decideswhat the minimum and maximum pixel values are centered around. The minimumvalue is computed as level + ceil(−(4095 − gain)/2) and the maximum value iscomputed as level + ceil((4095 − gain)/2) + 1.

Set AGC gain bias manually This command allows the user to set the valueof the gain bias. The gain bias is analogous to contrast control for the outgoingpicture. It takes in an integer value between 0 and 4095. The actual value of thegain factor can range between 0.25 and 4.0. If the value entered into this commandis less than or equal to 2047, gain factor = (0.75 ∗ gain bias/2047) + 0.25. If thevalue entered is greater than or equal to 2048, gain factor = (3 ∗ (gain bias −2048)/2047)+1. Given these equations, unity gain bias has a value of 2047, givinga gain factor of 1.0.


Set AGC level bias manually This command allows the user to set the valueof the level bias. This setting is analogous to brightness control. It accepts aninteger value between 0 and 4095. The actual level factor values range between-255 and 255. Similar to the gain bias, the level bias is manipulated using a simplemathematical formula to set the actual level factor. For values less than or equalto 2047, level factor = 255 ∗ level bias/2047 − 255, and for values greater thanor equal to 2048, level factor = 255 ∗ (level bias− 2047)/2048. This means unitylevel bias is at the user-entered value of 0, giving a level gain factor of 0.

Set AGC region of interest This command serves several purposes. It cantake integer values ranging from 0 to 3, whose purposes are listed below.

• 0 - Gets the AGC region of interest currently set.• 1 - Gets the AGC region of interest allowable limit.• 2 - Allows the user to set the region of interest, taking in 4 pixel coordinate

values.• 3 - Allows the user to put the region of interest values in non-volatile pa-

rameters so it can be retrieved at any time.

The region of interest specifies in what area of the picture you want AGC to beactive. We want this to be included to give the end-user the maximum customiz-ability possible.

Toggle auto-calibration This command allows the user to toggle betweenwhether they want calibrations to occur automatically or manually. The defaultmode is set to periodic automatic calibrations. This command differs from 0x26in that it does not stop range change calibrations from occurring. This is benefi-cial because range change calibrations are necessary if we want to be outputtingimages that are useful. Without them, changes in temperature would not changehow the picture is displayed, slowly becoming harder and harder to decipher tothe human eye. The command takes in a value of 0 or 1 to either enable or disableautocalibration.

Select video orientation This command can be used to configure the outputdisplay mode. It can take integer values ranging from 0 to 3, whose meanings areoutlined here.

• 0 - Normal video orientation.• 1 - Flips the video over the vertical axis.• 2 - Flips the video over the horizontal axis.• 3 - Flips the video over both the vertical and horizontal axes.

Once again, we want to include this functionality to give the most customizationto the end-user as possible.


Set non-volatile parameters This command allows us to write a value of anyparameter recognized by the camera to the camera’s flash memory. This can beuseful for a lot of different things. In the widest sense, this command allows us tostore settings permanently until we decide we want to change them again. Thereare a ton of parameters with spots in the flash memory which we don’t knowwhich to utilize yet and each has an associated ID. In order to write to one ofthese parameters, you supply the command with the ID of the parameter and thenew value you want to set.

Set non-volatile parameters to default This command allows the user toset the camera back to it’s original flash contents. All of the default values areoutlined in the technical documents for the camera, and there are too many tomention. This is extremely useful to us because we can set the camera settingsback to normal if we decide to change things back.

Get values of non-volatile parameters This command takes in an integerwhich specifies the ID of the parameter you wish to know the current value of. Itsends back in return a VALUE response with this value, as well as an acknowl-edgement. This command is good when used before setting any parameter values,so you know what you are changing it from.

Select digital video source Since the camera is capable of outputting in severaldifferent modes, this command can be used to set the digital video source but isnot used by the end-user. However, it is important to make note of it. The defaultoutput is through the Symbology Module. We have designed our system aroundthe 14 bit data output, which is a different output source.

Set baud rate This is another command which should not be accessible to theend-user. This command allows us to change the baud rate of the serial port,with either RS232 or UART is being utilized. We set this up at the beginning ofdevelopment to be a frequency compatible with the entire control unit and set itas a default.

Get system status This command does not take any user input. It returns along response which gives a variety of values being stored by the camera. Someof the fields included are the manual gain and level values, whether the shutter isopen or closed, and if autocalibration is enabled. This can be useful for giving anoverview of the system to the end-user.

Select test pattern This command was largely important during the testingof our system. It allows the user to display a variety of test patterns. We can usethe all black and all white test patters to ensure the output of each individual bit


is functioning correctly. Because this has nothing at all to do with image settings,it won’t be of use to the end-user.


The motor is configured on first implementation to follow a regular movementpattern. It rotates would 9, then stop. It does this 40 times, completing an entire360 rotation for the Tamarisk Camera. It followed this rotation every time asignal is received from the control unit saying that the camera is ready to capturethe next frame.

The control unit on the platform was the Zynq. The Zynq determined when itwas an appropriate time to trigger the command to start turning and then wait anappropriate amount of time until the motor was in position and capture an imagefrom the camera. It determined the timing based on the average time it took torotate 9. The signal which the Zynq transmitted was sent through the LEDs atthe bottom of the base platform. From there it was retrieved by a phototransistoron the base unit with an Arduino attached.

3.2.3 Motor Control

Once the information was sent from the platform to the phototransistor there wasan Arduino that read and decoded the information it received. As soon as itwas done decoding the information it sends it to the STR 2 Driver which sendsimpulses to the motor and rotates accordingly.

Arduino has a stepper motor library which we used. Using the library, the Arduinowas able to facilitate the process of getting our motor to move accordingly.

An example of the process that the Arduino will do in order to move the motor afixed amount of times is shown in Figure 3.31. This is used to move the motor 9.

There was an alternative process which the sponsor company suggested whichincorporates settable modes for the motor. This feature will be a ulterior goalwhich will be added in if there is enough time during development. These modescan be pre-configured and set using a control signal in the form of a specific patternof LED flashes. A signal will be sent from the operating system if a change inmovement pattern is requested, which the Zynq will send the instruction to theSTR 2 Driver and consequently the motor.

An example of the process that the Arduino will do in order to account for thisspecial mode is shown in Figure 3.32.


Figure 3.31: Simple Stepper Motor

3.2.4 FPGA

The power of the Zynq came from a combination of its dual core processor aswell as the ArtixTM-7 FPGA. The ArtixTM-7 provides a direct connection to thecamera’s output[13]. The information from the camera was in raw 14-bit formatand needed to be processed and composed into a frame. The ArtixTM-7 took careof all the timing of the bits, clocks of the camera, as well as moving the frames inand out of memory. Once the final panoramic was done, the ArtixTM-7 took careof any post processing of the image and placed it in a memory location where itwas easily accessible by the dual core processor so the user can see the final image.


Figure 3.32: Complex Stepper Motor


3.2.5 Embedded Linux

We utilized Arch Linux ARM on our Zynq. There is a complete guide for instal-lation of this operating system on the ZedBoard website. The ZedBoard devel-opment board we are using already comes with Arch Linux installed, which wasgreat for immediately being able to start developing code for our system. Theboot files for our Zynq SoC were loaded onto an SD card which will be read onthe Zynq board.

The presence of an operating system allowed a way to get this information outto the user in an easy and intuitive way. Since the operating system was Linux,a high level of customizability was available. The operating system hosted a webserver, provide serial communication, and serve as a platform for an RTSP server.

3.2.5.1 Web Server

Having a web server allowed for users to access an interface in which they can sendcommands to the camera and view the live video stream. We would have usedNginx, a lightweight web server which offers flexibility in hosting data. However,Nginx needed to be compiled and configured from source before being used on theEmbedded Linux operating system.

3.2.5.2 RTSP

RTSP will allow for users to connect to an IP address using VLC or a web pluginand view the video output from the camera. LIVE555 was a program available onLinux that will facilitate the RTSP server creation.

3.2.5.3 Serial Com

Serial communication was to be used to send commands to the camera, whichwere sent using a python script. This allowed the commands so that it can beeasily interfaced with the website. Python offers a serial communication library.The script looks at a location in the file system to see if any configurations havebeen set by the web server and if so it will automatically execute the commandreceived and place the results in a location where the web server can see it.

3.2.5.4 Wi-Fi

To make all this possible there needed to be a form of IP communication withthe Linux subsystem. Embedded Linux was able to handle various wi-fi adaptersautomatically[9]. There are two possible ways on how we were to set it up: The


1st being Ad-Hoc and the 2nd being infrastructure. Infrastructure allows forthe Embedded Linux to connect to an access point and from there, any deviceconnected is able to view and control the camera stream. It is important to notethat this project implementation has no added security measures in place.

Each of the systems above needed to be complied on the device and configured towork for the Zynq.

3.2.6 Platform Communication

The platform initially needed to feed the output of the completed image to adisplay device. Since the entirety of the system is on a spinning platform, anywires coming down from the device posed a problem. Also worth considering wasthe distance the camera was from the output display. To address these issues,wireless RF communication was to be used to stream the output from the controlunit to the display. There are two options for RF communication.

Wi-Fi can be used so that the outgoing data can be easily viewable in a widearray of devices. The hardware implementation of this would have been relativelysimple. The problem with this approach was that the IP stack would have to beutilized in order to send the data over wi-fi. This adds more computational load onthe back end of the system. The data would need to be formatted in a datagramproperly in order to be transmitted.

After deliberating on the pros and cons of the different transmission methods, itwas decided that utilizing the IP stack to send data over a Wi-Fi network wouldhave been optimal. It is our goal to provide the output through the most accessibleroute possible. Streaming the data through a Wi-Fi network would mean that thestreaming panoramic pictures would be viewable by any device which can connectto the network. This could be a cell phone or consumer PC. Having the maximumaccessibility was important for meeting our project specifications, since we don’tknow what environment the camera would have been used in, or what resourceswould have been available for viewing.

3.2.7 End-User Interface

Because we were utilizing wi-fi and the IP stack, the end-user viewing environmentwas available to any browser which supported HTML 5. The webpage has minimalcontent, but the center of the page hosted a video which used a VLC plug-in. Thisenabled us to give the plug-in the IP address of the streaming content from theLinux server. It displayed this automatically on opening the page. This plug-inalso supported the ability to stream full screen by double clicking on the element.On the bottom of the page we display any error code which required humanintervention to fix. This allowed for easy debugging on our end, and give theend-user feedback if something was to go wrong with the system. On the upper


right corner of the screen was an easy to use menu. This displays the commandswhich can be sent to the control unit. With this, the end-user can adjust the ICEor AGC to their liking. This setup would have provided all of the functionality weneeded on the front end of the system and be easily accessible to all. Figure 3.33provided a complementary diagram that illustrates the general process describedabove.

Figure 3.33: End-User Communication

3.2.8 Network Access

The data was streamed over an embedded Linux server on the PCB. The server ranon Arch Linux ARM, a distribution designed specifically to run on an embeddedARM processor, which our Zynq processor had. It was set up to use the minimumresources required.

The basic flow of the server was set up as follows:

1. Recognize when data is present in the output buffer.2. Make the data available in a format recognizable to the VLC browser plug-in

from a static IP.3. When the output buffer updates to the new panoramic, update the data at

the IP address.

The wi-fi dongle we were using was capable of transmitting at up to 150 MB/s,more than enough for the purposes of sending the 4 MB of data we need to sendevery 2 seconds. Optimally the user would have been within range to connectdirectly to the network being broadcast. This would’ve given the fastest speeds.Otherwise, the user could’ve connected to the website anywhere and view theoutput.


3.2.9 Output Protocol

Data transmission through the server used IPv4, the standard protocol for sendingdata over the Internet. The data had to be formatted with an IPv4 header to tellthe network how to transmit. Fortunately, the embedded Linux server and thewi-fi dongle took care of this formatting for us. The drivers that come with theUSB and Linux know exactly how to put packets together. In order to transmit,we needed to put the data to be transmitted in a block of RAM, and tell the Linuxserver when data was ready to be updated. This way it transmitted only whennecessary, when new data was in the RAM buffer.

3.2.10 Video Output

The final output being sent through wi-fi was an 8-bit greyscale image. Althoughthe original output from the camera was 14-bit greyscale, this was more than mostdisplays are capable of representing. Rescaling the values of each pixel to an 8-bitvalue also decreased the amount of bandwidth we needed the end-user to have,and the wi-fi to support. The total panoramic was segmented into four parts tomake it easier to view on many different platforms. The total resolution of eachsegment was 3200 x 240.

3.2.11 Image Processing

Two approaches were considered in the handling of creating a smooth lookingpicture which covered a 360 view. The first was to use a wide field of view, buttake pictures which overlap with each other to a point. When the pictures wereto be stitched together, the images can be smoothed algorithmically to createsomething that looks true to life. This is the way in which phones that takepanoramic pictures to create a final image.

The second way of going about composing a full panoramic picture was to use asmall field of view, and stitch the individual frames together end to end. Thisapproach requires less memory to be used by the ArtixTM-7, as smaller amountsof data were being processed at one time, allowing the use of a cheaper Zynq. Itdid require more precision from the movement mechanism being used, namely thestep motor. This was figured into the selection of the step motor, as accuracy wasone of the top priorities.

The images coming from the camera were in 14-bit greyscale. Since this is athermal camera, those values represent a specific temperature. One of the majorpost processing that needed to occur was gain control. Gain control took all thevalues from the each frame, calculate mean and standard deviation and rescaleall the pixels in the image to be between those values. This was implementedon the whole panoramic to make it look more uniform rather than each frameindividually. The FPGA facilitates these calculations.


Once the gain control was applied, the ArtixTM-7 placed the final image in alocation that was accessible to the Embedded Linux.

The ArtixTM-7 programming was done through the use of Verilog/VHDL pro-gramming language. The part of the group responsible for the programming ofthe ArtixTM-7 were familiar with both Verilog over VHDL, so this was seen to bethe better option for the project. The ARM processor was programmed in C/C++as well as some python scripts due to familiarity with the group members.

3.2.12 Software Flaws

Limitations of the solutions we had planned on implementing arose at differentstages of project development. The MicroZed board ended up playing a lesser rolein the final design, and several other modules were affected as well. Here we willexplain the flaws that led to changes in our software design, then later explainwhat these changes ended up being.

3.2.12.1 Camera Communication Flaws

3.2.12.2 Motor Communication Flaws

We conducted some preliminary testing on some of the basic components of ourproject early in the semester. When we tested the LED and light sensor com-ponent, we saw that the sensor refresh rate was very low. It did not allow forthe motor to react quickly when the control system signalled that it was readyfor a spin. Another issue that arose after more evaluation of the communicationmethod was that the motor could not communicate back to the control unit. Thiswas desired so that the current position was known at all times. For these reasons,an alternative plan was created for motor communication.

3.2.12.3 Motor Control Flaws

3.2.12.4 Embedded Linux Flaws

In trying to establish two-way communication between the memory and the op-erating system, several issues arose. The operating system did not allow the rootuser to have direct memory access without some workarounds which would havebeen time-costly. Direct memory access was needed in order for the logic to callscripts which could write to the buffer to the camera, and manage the imagebuffers coming from the FPGA. This ended up killing the idea of utilizing an op-erating system entirely. Instead we focused software development on the end-userapplication for image processing, and low level on the FPGA.


3.2.12.5 End-User Interface Flaws

As software development on the end-user interface progressed in its early stages,it was being written in a combination of HTML5, Javascript, and PHP. However,issues arose when this was hosted on the MicroZed server. The server did notsupport PHP, which was needed in order to call scripts in the operating system toaccess data pins.

During development we were unsuccesful in cross compiling any Linux packages forthe version of Linux the MicroZed ran on. This created several issues, includingbeing able to install drivers for the USB WiFi dongle, and using an embeddedserver on the MicroZed. The latter issue led to the decision to create an end-userapplication which did not interface with a browser. This will be described in theFinal Design section. Before we had decided not to use the embedded operatingsystem in it’s entirety, we started developing a C# application to communicate tothe MicroZed and run scripts.

Hardware issues with communicating with the camera arose after the applicationhad already been written, so it needed to be changed to suit the new camera wewere going to use. The specifics of these changes will be elaborated on later. Theswitch to a new camera also increased the resolution per frame drastically. Thiscreated an issue, as it had been planned to display the full panoramic picture ata time.

Final Design

With the initial design flaws stated in the previous chapter, various changes neededto be made for the final design to be viable and consistent. Certain parts/featureswere changed or removed in order to facilitate a working and consistent product.To illustrate the changes made to the overall design, please refer to Figure 4.1

Figure 4.1: Final Design Flowchart

106

Section 4. Final Design 107

4.1 Hardware

4.1.1 Atom 1024 Camera

With so many complications from the Tamarisk Camera, our group decided tochange the camera in order to facilitate a working product in time for presentation.We were given many different options but settled with the Atom 1024 Camerabecause of the convenience for getting data out. The Atom 1024 Camera is aninfrared camera produced by the company Sofradir which utilizes standard portswhich facilitate data coming out very easy. Figure 4.2 shows an illustration ofwhat the camera looks like and Figure 4.3 depicts the power input and GigE portthat it takes.

Figure 4.2: Sofradir Atom 1024

4.1.2 Tiva 123GXL + CC3100 Wi-Fi Module

With the LED communication idea having too many flaws, the group needed asolution that would prove to be faster and more efficient. Figure 4.4 depicts theproduct for illustration purposes. The Tiva 123GXL coupled with the CC3100provided a means to communicate to the computer/Atom 1024 without using toomany wires. The Tiva 123GXL provided a means to replace the Arduino we hadinitially used since the code was essentially the same. The Tiva 123GXL wasnow responsible for sending the impulse steps to the STR 2 Motor Driver. Forclarification on how the Tiva was connected to the STR 2 Motor Driver, pleaserefer to Figure 4.5. Important to note is that the CC3100 in Figure 4.6 is set toconnect to a private IP address being hosted by a router and communicates fromthe computer through there.


Figure 4.3: Atom 1024 GigE Port

Figure 4.4: Tiva 123GXL


Figure 4.5: Tiva Pin Layout

Figure 4.6: CC3100 Wi-Fi Module

4.2 Software


After abandoning the idea of a web browser interface, several other options wereconsidered. Due to the familiarity the group had with C# application developmentusing Windows Presentation Foundation, we decided to write the interface usingthese tools. This was actually easier to write, as we had much more familiaritywith C# than PHP and HTML. It also allowed more freedom, in that we couldhave the user set the IP of the camera and present the various commands to thecamera in an easier to understand way.


After encountering issues with the camera we had originally designed around, theinterface had to be changed again so it could interface with the new camera. Thisrequired rewriting the frame retrieval and user command logic to utilize the Gig-Eprotocol. Along with this change, the new camera had a much larger resolutionper frame. This led to the decision to only display two frames at a time, so thatthe user did not have to scroll to see a full picture.

Figure 4.7: Software Class Diagram UI


An alternative which proved to work perfectly well for interfacing between themotor driver and the image processing module was utilizing WiFi. A TI Tiva-Cwas used in conjunction with a CC3100 to accomplish this communication. The


libraries that the TI products support made developing the logic for this moduleeasier than anticipated. The module was programmed to receive a byte when thecurrent camera data had been received to spin the motor, then a second byte wassent back to say that the camera was ready to capture the next frame. WiFiproved to be fast enough for our uses, and allowed the two-way communicationwhich we required.

4.2.3 Image Processing

Unfortunately, the hardware issues encountered with interfacing the camera withour PCB ended up requiring us to switch all image processing logic to the end-userapplication. The change of camera also affected this, in a positive way. Throughusing the Gig-E protocol instead of UART to receive data from the camera, packetreassembly became much simpler. The Gig-E protocol utilizes UDP datagramswhich are handled quite easily on the sending and receiving end. The majority ofthe image processing was done on the camera itself. The end-user application wascoded to be able to send appropriate commands to the camera in the expectedformat.

4.3 Housing and Mounting

One of the things that needed to be considered when designing this system is howit will stand up to an outdoor environment. The intended use of the infraredpanoramic camera is for surveillance; mounted in a long-term fixed area, whichmeans it will need to withstand a variety of weather conditions. Another consid-eration when designing the housing is the stability of the system. It needs to beresistant to vibrations and the movement coming from the motor rotation. Withthese things managed, the camera system should be able to operate in any envi-ronment we need it to. The design elements regarding the housing and mountingof the project will be discussed and explored in the following sections:

• Camera Mount (4.3.1)• Motor Mount (4.3.2)• Control Mount (4.3.3)

4.3.1 Camera Mount

The mount on the rotational platform was primarily designed around the camerawe had planned on using, the Tamarisk 320. Here we will explain how we builtthe platform based on the specifications of the camera.


Figure 4.8: Software Class Diagram Camera


The Tamarisk 320 maximum dimensions are 34x30x30mm if the base, featureboard, and back cover configuration are selected, giving it a total weight of 29g.This does not include any additional size or weight given to the camera by a lens.With the largest lens option, the camera would be 37x32x49mm and would weigh64g. The camera needed to be connected to a rotating platform which could spinin a controllable manner without obstructing the line of sight of the detector.

The Tamarisk 320 comes with a variety of accessories. Two of them are bracketsfor the camera to be mounted on a standard 1/4-20 screw, a standard tripodmounting screw. By utilizing one of these brackets we can connect the cameramodule to anything with a 1/4-20 screw. This provides a versatile mechanicalinterfacing platform. The mount accessory is made of anodized aluminum andconnects to the camera at the base of the lens. The center of gravity relativeto the camera is located inside the lens due the the heavy weight of the 35mmlens being greater than the weight of the camera module. With this in mind, wecustomized a brace mount for the camera that stabilized its lens heavy design.

In order to better support the camera module, ensure good image stability, andprevent the device from becoming loose, we fashioned a mount of our own de-sign that will behoove the functionality of the camera mounted to the rotationalaxis. Using the mechanical ICD of the Tamarisk 320, a plastic form factor wasdesigned using a 3-D modeling program and then printed out using a 3-D printer.As a preliminary design, we had created a 1.25” x 0.29” x 1.0” (L x W x H)brace that would have been fastened to the camera lens in order to stabilize it.However, the thickness of the material was tested to ensure appropriate stability.Figure 4.9 provides a SolidWorks drawing of the dimensions and layout of thebrace for visualization purposes.

A primary design consideration was to make sure the camera is fixed within avery low tolerance to the rotation of the motor. The rotation of a single click ofthe motor is being used as a constant 1.8. While this contains a high degree ofaccuracy, the motor had no default way of reporting back its original location atthe time of design. Assuming this constant, and without the aid of any additionalpositional sensors, preventing camera drift from the reference axis was paramount.Providing additional support to the sides of the camera will help prevent thecamera from drifting from the assumed location. Gripping the camera by the lenswas also important, most of the weight of the camera is in the lens. Gripping boththe lens and camera body to minimize the strain on each respective componentwhich could be induced by a change in rotational inertia. A controller module wasanother part of the design. This system was imperative to interface with the datacoming out of the camera, supply power to all of the components, and control thestepper motor commands. The mount for the camera needed to take into accountthe positioning of this controller board. Sufficient access was needed in the backof the camera to allow connection to the existing pin outs on the camera module.

The camera mount needed to secure nicely to a platform which rotates as a resultof the stepper motor. Slots were fashioned into the casing to provide a stablemounting platform. Making the camera mount detachable from the platform was


Figure 4.9: Tamarisk Camera Mount

important in the prototype phase to keep the system as modular as possible pro-moting the freedom of design changes. In order to remedy this, a ”riser” platformwas added above the Zynq board. It is important to note that the riser platformfits over the Zynq board and onto the rotational platform. This allows it to providestabilization to the camera brace but still spin with the rotational platform. Abonus is that the riser platform was to provide additional protection to the Zynqboard from outside elements. In Figure 4.10, we have detailed the dimensions forthe riser board for visualization purposes.

The infrared camera is the highest value asset of this project. Protecting the devicefrom the environment is important. Surveillance systems are frequently utilized inoutdoor conditions, making the housing around the camera water tight to preventprecipitation leaks. The camera mount was optimized to prevent obstacles that


Figure 4.10: Riser Platform

could interfere with the rotation of the camera. By designing the cross sectionsof the mount to be perpendicular with respect to the focal plane, circular andcentered about the rotational axis, the aerodynamics were be optimized. Thisreduces the probability of external interference.

4.3.2 Motor Mount

The motor is the primary mechanical item in this panoramic solution. The rotationof this system needed to be unhindered. The system requires a high level ofsensitivity in order to function properly. The bulk of the motor is mounted on thebase side. The small bolt which comes out of the motor and spins relative to therest of the stepper motor is anchored into the rotational platform. The majorityof the electrical components are mounted on the rotational plane. The goal ofthis was to prevent the need of wires to be fed from the rotational platform to therelatively stationary base. This design is intended to optimize the disuse of sliprings for the project.

There were several considerations made in mounting the motor to avoid any po-tential issues. The pin extruding from the base needed to be anchored to therotational platform. The bulk of the motor needed to be fastened to a secure base.The base houses the power supply, the motor, and one of the inductive coils. Thepin coming out of the motor is fastened to the rotational platform and is securedto the rotating platform by utilizing the flat side of the pin. A coupling sleeve


fits over the pin securing itself by applying pressure to the flat edge. This allowsthe rotational platform to respond to the pins orientation. The sleeve attached tothe motor pin is made of a light weight metal, aluminum, which provides a securegrip to the pin without adding an excessive amount of weight. A hole is threadedinto the aluminum sleeve which allows a screw to be tapped in order to supplyadditional pressure onto the pin and keep the top structure from being lifted fromits base. The rest of the motor is attached to the base platform.

The base platform was to be printed out of a weather resistant plastic. The bulkof the base was to be printed as a single piece of plastic, to ensure the joints ofthe base are waterproof. Water entering the base could irreparably damage theelectronic components on the inside. 3D printing the entire base ended up beingtoo expensive, so we switched to a premade case which was weather proof andsturdily made The only other piece of the base which is exposed to the outsideis the top plate. The top plate is a square piece of plastic which attaches to thebulk of the motor and the rest of the stationary base. The base has the abilityto be fastened to a surface. This device is a demonstration unit which needs tobe portable. A final ready-for-market version of this product will utilize a basewith some anchor point to be fastened to a surface. The prototype does not needsuch a system. However, the prototype should have a secure base. The base isheavy and stable enough to not readily move. Should the prototype shift duringoperation this would adversely affect the system and the output imagery wouldnot be accurate. Some of the panorama could be missing or the same environmentcould be repeated. The premade box that we chose has a large width and breadth,giving it the stability and mass we needed to ensure stability.

This system is subject to much rotational stress. The platform starts and stopsfrequently. The bulk of this mechanical stress which the system experiences isexerted on the motor and any of the components on the rotational platform. Thefrequent change in rotational inertia was factored into the design of the motormount. Similar to the camera mount, considerations needed to be taken to ensurethe rotational axis of the motor with respect to the camera, was configured and didnot deviate from the calibration. The components surrounding this system werereinforced to compensate for the additional stress which the system experiences.The motor picked is capable of handling much higher payloads than what it isbeing subjected to from this design.

The rotation between the platform and pin needed to be controlled. None of theother systems should interfere with this interface. Design to prevent any electricalcomponents and environmental interference has been taken into account. Thespace between the two platforms needed to be protected. A tight space betweenthe base and rotational platform helped mitigate any potential interference.

4.3.3 Control Mount

The Tamarisk comes optionally equipped with a feature board, the configurationwhich we had selected was the one without the additional board. This solution is


lighter and provides a more useful digital interface capability. Items which wereto be connected to the camera were the electrical connections which provide noadditional structural support and the structural mechanical mount. The structuralmount consists of support for the camera to be fastened to the rotational platformand also a weather protection structural dome. DRS offers some existing mountingsolutions for the Tamarisk. Their solution consists of a metal ”U” shaped clampwhich grips the camera behind the lens.

The camera mount system is mounted above the controller. The controller wasplanned to be fastened to the rotational platform. A small platform acts as abridge, extending over the Zynq board. This platform supplies a mounting inter-face for the camera so it does not interfere with the Zynq board. The camera wasgoing to be connected to the board via a SS4 breakout wire. This ended up chang-ing to bypass the control unit entirely, instead directly connecting to the end-userdevice. The Zynq was to be fastened by a few screw holes in the board to the plat-form. Unfortunately, issues with the PCB we designed led to us not mounting itat all on the rotational platform. A wi-fi module was also to be mounted with thecontroller, but also had to be discarded. Considerations were taken into accountto ensure there was not any EM interference and a thin weather-proof plastic wasgoing to be used to cover the board. The Zynq, like any computational device,will generate heat. A small heat sink or other ventilation solution was going tobe required to adequately dissipate heat. This requirement disappeared when wedecided not to mount the PCB.

The inductive coil is part of the control mount system. A concern with the induc-tive platform was interference from the coupled inductors. In order to reduce thepotential interference of the inductive system, placing a copper plate underneaththe board helped shield the board from flux. The copper plate can be utilizedas a local ground of the system. The inductive coil resides beneath the copperplate. The coil is mounted directly above the other inductive coil attached onthe base unit. For maximum power transfer, the distance between these two wasminimized.

The protective dome covering the control unit will attach to the rotational plat-form. The dome will extend up and cover all of the important electrical com-ponents which need to be protected from acclimate weather. However, the IRcamera cannot see through normal plastic. To keep cost down the dome will stillbe printed using a 3-D printer. However, a hole will need to be present to allowthe thermal camera to see outside of the dome. The lens and the dome need tomake a tight seal about each other to protect the Zynq and other electronics onthe inside of the dome. A rubber O-ring will suffice at keeping water out of thesystem while still allowing the camera to see.

4.3.4 Overview

Looking at all of the individual mounts and housing units for each of the 3 systemsmentioned above, it can be difficult to envision what the overall product is expected


to look like. Combining the camera mount, motor mount, and control mount, wehave built what the entire system is supposed to look like and how it will all fittogether. Figure 4.11 depicts what all of the mount subsystems look like assembled.We can see that the base unit houses the OMHT17-075 Stepper Motor, STR 2Driver, and the OMPS300A48 Power Supply Unit. From here, the OMHT17-075Stepper Motor sticks out through a hole in the middle of the base unit and connectsto the rotational platform.

Figure 4.11: Combining All of the Mount Sub-Systems

Construction Testing and Evaluation

Now that design is complete and the project has been assembled, it’s extremelyimportant to make sure all of the components are working properly. Componentsmay work by themselves but since they are all connected, their performance mightbe affected by neighboring components. It is important to ensure that each of thefollowing components are tested thoroughly:

• Atom 1024 (5.1)• Motor (5.2)• Communication (5.3)• Power and Regulation (5.4)• System Performance (5.5)

In thoroughly testing each of these components, we minimize the risk of havingproblems synergistically between the different systems. We are also able to recorddown numbers that may be cross referenced for another component in the future.

5.1 Atom 1024

Being the focal point of the project, testing for the Atom 1024 is of the utmostimportance. We needed to make sure that the camera was able to communicateto the computer correctly.

5.1.1 Testing the Camera Power

We attached a multimeter to the DC IN of the camera to make sure that thecorrect voltage was going into the unit.

5.1.2 Testing the Ethernet Connection

The Ethernet test was meant to assure that the camera is able to be seen by thecomputer on the network. This was tested using eBUS player which is able to seeall GigE Vision devices on a network.

119

Section 5. Construction Testing and Evaluation 120

5.1.3 Testing the Data Out

In order to make sure that the camera responded correctly to the computer, weran eBUS player’s built in video player to ensure that the camera was sending thevideo transmission over the Ethernet cable.

5.1.4 Testing the Sofradir Commands

The simplest way for testing if the commands sent by the end user reaches thecamera was to send the command for a NUC now, this causes the camera toaudibly ’click’ which confirms to us that there has been a serial communicationset. Each of the commands sent there after are used for different video options,therefore they were tested by viewing the video output, since they change theactual image coming into the computer.

5.2 Motor

Testing the motor is one of the most important aspects of the project. Not onlydo we have to make sure that it powers on properly, but that it will rotate incoordination with the Sofradir camera. With this in mind, we have come up witha few testing procedures.

5.2.1 Making sure the physical motor works

We will first make sure that the motor and coincidently the driver are working bydoing the following:

1. Plug the STR2 into the power supply.2. Plug the motor into the STR2.3. Enable self test on the STR2.4. Make sure that it responds to the signals sent by the STR2.

Once we ensure that the motor is operating correctly we will need to move on thefollowing test. We will need to make sure that the controller is sending the rightsignals to the motor to rotate accordingly.

5.2.2 Tiva C 123GXL + CC3100 Wi-Fi Module

We nee to make sure that the Tiva C 123GXL with the CC3100 Wi-Fi moduleis able to send a pulse command to the motor driver, as well as receive and senddata packets to/from the computer.


To assure that the Tiva C can pulse the motor, a simple program was written asa hardcode pulse. To assure that the Tiva C can communicate wireless, we usedUART to print the contents of a received datagram. To assure that the computerwas receiving a response, we used WireShark to look at all the packets cominginto the computer.

At this point we will be confident that the whole Motor/Control subsystem isworking as intended.

5.3 Communication

5.3.1 I/O

To ensure that data was being stored correctly in the incoming and outgoingbuffers, we needed to perform capacity tests. The specific procedure for seeingif the buffers were set up correctly can be seen below and is demonstrated inFigure 5.1.

1. Test that input buffer can hold 3 frames of data (See Figure 6.1)

(a) Send 3 files, each of same size of one frame (Total size 460.8 kB)(b) Check that file data in buffer(c) Send one more file to buffer to ensure buffer not overwritten

2. Test that output buffer can hold file the size of total panoramic

(a) Send one large file the size of final panoramic (6.144 MB)(b) Check that correct file data in buffer(c) Send file to buffer while full to ensure buffer not overwritten

Figure 5.1: Input Buffer Functionality


Due to issues interfacing with the embedded memory, the shift to a direct stream ofimage data changed what needed to be tested to ensure reliable image transmission.To test that image data was not being lost, discernible objects were placed at eachangle the camera might be aimed at. We ensured that an image being shownat the time was indeed the most current one. Storing of image frames was donein a byte array which we set to null between each image reception. To ensurethe memory of the end-user application was being managed correctly, we ran thecamera stream for an extended amount of time. The stream ran for 20 minutesand did not present any issues or slowdowns.

We had also planned to test the USB Wi-Fi dongle to ensure full functionality.This would have involved checking the speed of the connection, and the reliabilityof the connection. The steps we would have had to walk through to test everythingwe need to are as follows.

1. Fully configure the server to stream camera data

• To make sure the final product will function correctly we have to sendthe same amount data at the same speed we expect to get out of theWi-Fi

2. Log onto the Wi-Fi through the ad-hoc network3. Measure how long it takes for the viewing page to update compared to how

often the data is changed on the system4. Try sending a command to make sure the Wi-Fi is able to both receive and

transmit

After changing to a wired ethernet connection to the end-user device, this testchanged. Instead we had to ensure that the end-user application was able to setthe IP address of the camera correctly, and that data was streaming consistentlyfrom the camera without packet loss. This test was passed on setup, as the Gig-Eprotocol is consistent and a direct ethernet connection is very reliable.

5.3.2 Software Unit Testing

Each of the commands which were going to be sent to the Tamarisk camera neededto be tested. Table 5.1 shows the hexadecimal commands of interest and thefunction of these commands, and Table 5.2 shows the type of message the expectedresponse will be.

The format of the ACK response is always the same format. It will have 6 bytes.

• Byte 1 is 0x01, signals start of message• Byte 2 is 0x02, the ACK response ID• Byte 3 is 0x02, gives 2 parameter bytes• Bytes 4 and 5 echoes the command ID


Instruction Function0x12 Set rate of camera calibrations0x13 Gets rate between camera calibrations0x1E Set strength of ICE filter0x22 Set ICE min and max values0x23 Enable ICE mode0x25 Automatic calibration activity query0x26 Enable automatic calibration0x27 Force in non-uniform correction (NUC)0x28 Enable black-hot scheme0x29 Enable white-hot scheme0x2A Set Auto Gain Correction (AGC) mode0x32 Set AGC gain manually0x33 Set AGC level manually0x82 Set AGC gain bias manually0x83 Set AGC level bias manually0x84 Set AGC region of interest0xAC Toggle auto-calibration0xCF Select video orientation0xB0 Set non-volatile parameters0xB3 Set non-volatile parameters to default0xB5 Get values of non-volatile parameters0xD7 Select digital video source0xF1 Set baud rate0xF2 Get system status0xF4 Select test pattern

Table 5.1: Tamarisk Commands of Interest

• Byte 6 is the checksum

The format of a VALUE response also follows a set format.

• Byte 1 is 0x01, signals start of message• Byte 2 is 0x45, the VALUE response ID• Byte 3 is 0x02, gives 2 parameter bytes• Bytes 4 and 5 are an unsigned integer• Byte 6 is the checksum

The format of a TEXT response also follows a set format. The text response willonly show up during development, as it is meant for debugging purposes.

• Byte 1 is 0x01, signals start of message• Byte 2 is 0x00, the TEXT response ID


Instruction Expected Result0x12 ACK0x13 ACK0x1E ACK0x22 ACK0x23 ACK0x25 ACK w/ VALUE0x26 ACK0x27 ACK0x28 ACK0x29 ACK0x2A ACK w/ VALUE0x32 ACK0x33 ACK0x82 ACK0x83 ACK0x84 ACK or message0xAC ACK0xCF ACK0xB0 ACK0xB3 ACK0xB5 ACK w/ VALUE0xD7 ACK0xF1 Check baud rate - match0xF2 ACK w/ 20 byte message0xF4 ACK

Table 5.2: Response to Commands of Interest

• Byte 3 gives the number (N) of bytes to follow• Bytes 4 through N+3 is an ASCII string containing the text message• Byte N+4 is the checksum

If a test failed, one of two responses were possible. A NAK response indicatesthat for some reason the command given could not be processed. An ERR re-sponse indicates that an unrecognized command was given, or the command wasinterrupted.

The format of the NAK response is always in the same format. It has 6 bytes.

• Byte 1 is 0x01, signals start of message• Byte 2 is 0x03, the NAK response ID• Byte 3 is 0x02, gives 2 parameter bytes• Bytes 4 and 5 echo the command ID• Byte 6 is the checksum


The format of the ERR response has two possible formats. It has a variableamount of bytes. The format of the first type of ERR response is below.

• Byte 1 is 0x01, signals start of message• Byte 2 is 0x04, the ERR response ID• Byte 3 is 0x02, gives 2 parameter bytes• Bytes 4 and 5 echoes the command ID• Byte 6 is the checksum

The second possible ERR response is of the following format.

• Byte 1 is 0x01, signals start of message• Byte 2 is 0x02, the ERR response ID• Byte 3 gives the number (N) of bytes to follow• Bytes 4 through N+3 is an ASCII string containing the error message• Byte N+4 is the checksum

In order to test all functional commands, we were going to need to receive each ofthese signals and make sure they were interpreted in the appropriate way. Perhapsmost importantly, we needed to test the NAK and ERR responses. These responsesare those which needed to be sent to the output for the user to handle. If theseresponses were not being received and interpreted correctly, troubleshooting anyissues with the subsystems would have been impossible.

When the camera we were using changed, these tests became slightly different.Although the format of the command bytes changed, much of the testing of thecommands remained the same. We sent each of the commands we needed toimplement to the camera to ensure that the proper response occurred.

We also planned to unit test the LED subsystem before the idea was abandoned.This would have involved fully programming the base platform light sensor andmotor controller as well as the rotational platform LEDs to work correctly. Wewanted the platform to be rotating as it should be to ensure that the rotation didnot affect the performance of the light sensor. We also wanted to check for severaldifferent consistencies during this test.

• That the LEDs are signaling within 2 ms of being told to by the SoC• That the LEDs flash in the correct pattern programmed into the SoC• That the light sensor is signaling to the motor control unit within 5 ms of

the LEDs being turned on in the specified pattern• That if the pattern being flashed by the LEDs is not recognized, no action

will be taken by the motor


After adjusting our motor control subsystem to be WiFi based, we needed toperform testing to ensure signals were being interpreted correctly between theend-user application and the CC3100 and Tiva-C module. We checked to makesure that the motor was only spinning one step per frame. We also checked thatin the event of a packet not reaching either system, a time-out would cause thesystems to resend. This worked correctly. Lastly, because of the change to a wiredrotational unit, we needed to ensure that the motor changed direction every 11steps, so the wires would not wrap around the system. This worked as intendedwithout fail, even with time outs.


A test was needed to check that all output was being displayed to the end-user inthe expected way. All of the steps below needed to be checked to ensure all of thefunctionality on the end-user webpage was working correctly.

1. Begin streaming data from the camera.2. View the stream at the IP address configured on the server.3. Send a command to the camera from the application to modify the camera.4. Ensure that the correct command has been interpreted.

Each of the commands and error messages needed to be cycled through and in-teracted with through the end-user interface to ensure each worked as expected.The tests on these followed the same procedure as the software unit test for eachof the command codes for the camera. Each error code should print correctly tothe user with a readable explanation of the issue encountered. The user shouldalso get feedback when a camera command is executed correctly.

Since the system is only intended for use by a single user at a time, a stress testis not needed. As long as the image loads in a reasonable amount of time (<5s)depending on connection speed, the requirements will be satisfied.

5.4 Power and Regulation

Testing the power supply and regulation will determine how long the project canrun without any kind of interruptions or problems. Without a constant and steadysupply of power, the motor will not be able to function properly or consistently.With this design constraint in mind, we have constructed a testing procedure thatwill enlighten us as to the full capabilities of the working conditions with regardsto the project functionality.

1. Power up the supply by plugging it into an outlet source.


2. Using a multi-meter, measure the voltage and current output of the sourcewithout anything plugged in.

3. Plug the driver and motor in and run them at full power. Measure how wellthe motor performs under prolonged running conditions.

4. With the same setup as the previous step, test different conditions relatingto temperature i.e indoor and outdoor conditions and their correlation withperformance and consistency.

5.5 System Performance

Once each of the different components have been tested, the project will be as-sembled and then run together as a single unit. We will then measure the overallperformance of the project based on how long it takes to perform its task and theefficiency in which it performs it. However, the performance of the system can begreatly affected by several factors such as temperature and longevity/consistency.With this in mind, we have decided to run 2 separate sets of tests based on indoorand outdoor conditions.

5.5.1 Indoor

One of the considerations we must consider is the conditions the project will beworking in. Factors such as light, temperature, and wind will all factor into theoverall performance of the project. Here we will test the indoor capabilities of theproject. We have defined indoor conditions to be 300 degrees Kelvin with little tono wind speed. With these conditions in mind, we will measure the latency andquality of the pictures come out with and compare them with other environmentalfactors. The minimum acceptable time it should take for the image to update onthe end-user’s system is 2 seconds. Of course this depends on network conditions,but in this ideal situation we expect the best possible performance.

The qualitative measurements we are shooting for out of the system are:

• Update of panoramic picture every 2 seconds from end-user view

– Step motor is able to rotate camera every 25 ms– Camera takes picture within 5 ms of motor being in position– FPGA processes each frame as they come in, allowing 25 ms for each

(the length of time between platform rotations)– LED correctly signals and is recognized by light sensor to signal motor

when to rotate– Server transmits at around 5 Mb/s stream to user

• Commands sent to camera system from end-user interface are processed andexecuted in less than 5 seconds


• Error messages from the camera appear to the end-user within 5 seconds ofbeing received by control

5.5.2 Outdoor

A big consideration of this project was its commercial use for outdoor events andutility. However, the outdoor environments contains an innumerable amount ofvariables that could affect the performance of the project. While not being ableto recreate specific conditions of the outdoor environment with consistency, wewill test the project in extreme conditions of high and low temperatures with heatlamps and cooling elements in order to set a performance precedent for the middleground of the temperature elements.

In order to test the waterproof aspect of the housing we will want to be careful,because if the waterproofing isn’t perfect we could severely damage the electricalcomponents. To test this part we will put the housing without the interior com-ponents in extremely humid conditions and inundate it with water. We will havehumidity indicators placed inside. If this are indicating wetness past a certainthreshold, the housing must be treated again with the waterproof spray. We willcontinue this process until the test gives the result we need.

The extraneous outdoor conditions such as wind and external physical interferencecan be simulated during testing with limited extent as well. The same basic testingwill occur as with the indoor testing, with the exception of the changed environ-ment and all performance marks including latency and quality will be accountedfor.

Administrative Content

6.1 Initial Milestone Discussion

The following timelines are constructed in regards to the actual construction ofthe prototype. This timeline is not inclusive of the research conducted and thepreliminary design process which is considered in the semester prior. All researchshould be completed prior to the production semester and a tentative design shouldbe complete. The viability of several components needs to be tested to ensureproper functionality during the production semester. Testing components andresearching backup options has been already considered. The timeline has beenbuilt around the consideration of potentially troubleshooting components whichare not functioning as desired.

6.1.1 August

The month of August will be structured to setting a foundation to success for thefollowing months. Referring to Figure 1.1, the start of the semester occurs on the18th, leaving approximately 13 days for ordering and shipping of most if not, allof the parts needed to build a prototype. Following the arrival of the parts, workwill take place in interfacing with the OMHT17-075 Stepper Motor using the Zynqboard.

6.1.1.1 Procurement

This milestone indicates that all of the essential parts to begin prototyping willhave been ordered. Bare minimum parts which should have been procured forinitial experimentation are as follows:

• Zynq board and Microzed board need to be interfaced.• Base unit components need to be tested and interfaced.• Wiring and connection peripherals checked.• Power units are ordered and tested.

129

Section 6. Administrative Content 130

6.1.1.2 Motor Interface

The motor interface milestone suggests communication from a controller to thedriver which makes the motor spin accordingly should be reached at this juncture.Providing all of the correct voltages to all of the parts involved in the process.Familiarizing the group on the performance of the motor and all of the necessarycomponents involved in instructing the motor to perform rotational operation.This also implies checking the physical size of the motor and begin constructionon housing and mechanical practicality of the system.

6.1.2 September

The goal of September is to build a ”functional” prototype. This month our goalwill be learning how to synchronize our development board with everything else.We must know the data pathways, be able to issue instructions, and receive datato perform image manipulation at some point. During this time we also need todevelop a mechanical system for physical prototyping and tailor the hardware forthe software being implemented. A timeline illustrating the order and due date ofthe proposed milestones in September is featured in Figures 1.2 and 1.3.

6.1.2.1 Camera Data Extraction

Extracting the data from the camera entails initializing a data stream from thecamera and receiving the data on the Zynq for data manipulation. This milestonerequires understanding of the Zynq and of the IR camera. We must also start toprogram the Zynq and establish a master/slave communication with a peripheral.Extensive knowledge of the pin layout and understanding of the existing data ex-change protocols offered by the camera is needed to complete this. Implementationof this will be done on the development Zynq.

6.1.2.2 Mechanical System

Before image manipulation can begin, a controlled environment that simulates fieldfunctionality and offers a repeatable process is essential. Constructing a skeletonplatform for testing will be needed early on in the development process. Themilestone indicates that the motor should be secured in a base which will preventthe platform from moving. A top testing platform should be made to mount theappropriate components necessary to test a bare minimum system. The necessarycomponents will need to be modeled and printed for experimentation.


6.1.2.3 Host Server

In order to establish communication from the Zynq to a viewing platform such asa computer, a server will be required to host the processed video. This milestoneentails installing an embedded version of Linux onto the Zynq and setting up theserver. This server should host the video feed which is then accessible and easilyviewable in the browser of a computer connected to the network.

6.1.2.4 Software Image

Here the data from the camera should be able to be manipulated and displayed.This milestone only requires basic image generation and being able to build thefoundations for the rest of the programming involved. Much of the considera-tion in this software will be identifying the essential components of the MicroZeddevelopment board which will be required to make an operational system.

6.1.2.5 Calibrate Focal Point

A necessary part of developing any camera system is precisely calibrating the cam-era to its focal point. A platform with the camera mounted in the appropriatefixed location in relation to the rotational plane will allow for the camera to beisolated and static so that further experimentation will not compromise the in-tegrity of the panorama. This will allow repeatable experimentation which pavesthe way for perfecting the software side of the product. The overall goal of thisstep is to improve the quality of the final imaging of the product.

6.1.3 October

September will be dedicated to understanding the functionality of all of the compo-nents involved in the product. Following that, October will be focused on bringingthose components together and making them work harmoniously together. Muchof this month will be dedicated to refining the functionality of the rotationalcontrols. The stability of the platform will be a primary focus of this month.Generating a full panorama in infrared and streaming the image over Wi-Fi is themain milestone to be reached. We would also like to optimize the hardware to bescaled down and implement the previously developed software onto to a customPCB with an ideal form factor to compliment the design of the product. For avisualization of milestones, please refer to Figures ?? and ??.


6.1.3.1 PCB Design

This step is dependent on the required elements identified in the software. Onceessential components have been identified and utilized, then cutting out the super-fluous components of the development board to reduce size and potentially reduceoverall cost will be our goal with the PCB. This is assuming a large volume ofPCBs will be desired to be manufactured.

6.1.3.2 Optical Communication

The final implementation will communicate to the motor wirelessly by sendingpulses of light to a sensor which will relay the instructions to make the motormove. Establishing how to physically implement it is an important design step.This milestone marks the point in time where a proof of concept has been imple-mented. This will help establish the physical arrangement of the LEDs which isan important consideration for the PCB board design.

6.1.3.3 Image Stitching

Using our functional mechanical platform and the existing communication estab-lished with the various peripherals, the camera and motor will need to operate insync, data will need to be captured, and the information will need to be stitchedinto a panoramic image. The image does not yet have to be completely refined.Raw consecutive images should be stitched together at this point. This should beable to tell us how precise the positioning of the camera on the platform is relativeto the true center by slight distortions of the panorama.

6.1.3.4 Implement Custom PCB

This landmark indicates the custom designed PCB has been implemented into theprototype. The software which was originally operating for testing purposes on thedevelopment board should also be loaded onto the custom PCB. The appropriateperipherals should be connected to the PCB and be functional. This step will helpin configuring the final form factor of the device. Until the custom PCB is in placethe final housing cannot be put in place.

6.1.3.5 Inductive Power

The proposed solution to powering the rotational platform relies on inductive coilsto transmit power up to the spinning camera. An important part on making thisa reality is to create a power solution which can plug into a wall and supplypower everywhere it needs to go. The wireless power transmission to charge the


battery which will be housed on the platform is important to get functioning. Theinductive system will have to be laid down on the platform first before a cameracan be mounted on top. This will increase power transfer efficiency and allowfor shielding of other electrical components above the coil which could be EMsensitive. This milestone involves having power coming from the a standard 120V60Hz wall outlet and modified to supply power from one coil to another which willcharge the system batteries.

6.1.4 November

The purpose of the month of November is a refining month. This month willbe reserved for any loose ends which failed to be executed in a timely manner.This factors in time for any shipping delays and extra troubleshooting required onother unfinished business. The device should be functional going into this month.However, viable products for market are not just functional. In a competitivemarket the product needs to be reliable, durable, and easy to use. This monthwill be focused on packaging a product which is ready for the market. For avisualization of milestones, please refer to Figures 1.6 and 1.7.

6.1.4.1 Housing

Now that the final electrical board is in place, we must package the device so thatthe electrical and mechanical components can function protected from outsideinterference. The housing should be put on at this point to protect and fur-ther promote correct operation. A sleek weather-proof rotationally-aerodynamichousing should be added to the device to provide protection without impactingperformance. The housing cannot block infrared light from reaching the detector.

6.1.4.2 Durability

Any device will need to withstand a fair amount of wear and tear. The durabilitylandmark indicates that repetitive testing of the device has been done. This in-volves power cycling the product to ensure the product boots successfully withoutfailure and subjecting the product to realistic shocks and vibrations which thedevice could experience to test the stability of the mechanical platform. This de-vice is a product which should be packaged for outside operation as well as insideoperation. As a result, we must do testing on how well the product stands up tovarious weather conditions such as rain.

6.1.4.3 Software Features

At this point in development, the software should have been working for a while.However, we must work at this point to package the program into something


deployable with the product and making the software able to work on a varietyof systems. This involves perfecting our user interface, making it clean, intuitiveand provide all of the necessary functionality intended for the project.

6.1.4.4 Testing

This phase of development entails moving the system around and testing the per-formance under many conditions. The product should work under ideal conditionsup to this point. During testing we will place the device in slightly undesirableconditions and see the response. We will attempt to the access the video feed frommultiple platforms, stress the device and see how it performs. After this milestoneis done the software and hardware should be resilient to non-ideal circumstances.While testing, we will want to take video of the product in action, as this will beuseful to include in the presentation portion of the project.

6.1.4.5 Aesthetics

Now that the device has been engineered to be functional, any additional time inthe design process will be dedicated to perfecting the aesthetics of the device. Itis hard to foresee exactly what will be required for this step so early on in thedesign process. This milestone will be to iron out any of the visuals which didn’ttranslate from the design process into the final product as desired.

6.1.4.6 Presentation

The final project will be presented to a council of selected UCF advisers. Thisproject should be assembled for presentation by this date. The presentation shouldintroduce the purpose of the project, go over the design process, show the actualconstruction phases, show testing data and supply imagery. Included in the pre-sentation should be a thought out live demonstration.

6.2 Budget Discussion

We based our decisions on the following factors:

1. Cost2. Functionality of the Parts3. Complexity of the Project4. Sponsor Constraints


There has to be a balance between the cost and the functionality that we want tobring in this system. Each part was carefully chosen for its merits regarding theabove factors. It is important to note that some sacrifices had to be made in termsof cost vs implementation complexity so that the difficulty would be challengingbut accessible for the group.

6.2.1 Power Supply

We went for the Omega OMPS300A48. It is a specialized power supply unit adeptat powering the HT stepper motor series and the STR driver series. This powersupply provides enough overall power to efficiently run the components in the baseunit.

6.2.2 Driver

We went for the STR-2. This driver is low cost, able to be controlled by anexternal device, and also able to control the motor with accuracy. We receiveda sponsorship from Applied Motion Products to use and promote one of theirpremium drivers. This created a savings of $99.00 which promotes the overalltheme of the project.

6.2.3 Motor

The OMHT17-075 Stepper Motor provides us with the utility and low cost thatis essential to the overall theme of the project. The motor is able to support allof the rotational platform components while maintaining a small form factor andis widely accessible in the market.

6.2.4 Misc. Supplies

St. Johns Optical Systems would like us to have enough parts for two units andtherefore the pricing in the budget reflects the cost for building 2 complete systems.The cost of a complete system is approximately $800.00 which does not includethe Tamarisk camera.


Vendor Date Cost Req#Digikey 11/14/2014 $30.36 SDAdafruit Industries 11/14/2024 $54.11 SDRadioShack 11/13/2014 $18.59 PickupLowes 11/12/2014 $12.36 PickupApplied Magnets 11/11/2014 $46.61 9118Lowe’s 11/8/2014 $64.22 PickupDigikey 11/6/2014 $50.34 9097Mouser 11/6/2014 $140.85 9097Advanced Circuits 10/30/2014 $215.92 SDAvnet 10/28/2014 $66.85 9016OSH Park 9/23/2014 $27.35 8715Digikey 9/23/2014 $183.00 8451Avnet 8/25/2014 $71.60 8451SparkFun 8/25/2014 $27.12 8451Omega Engineering 8/20/2014 $358.00 8253Applied Engineering Products 8/11/2014 $106.51 8253Avnet 8/8/2014 $281.48 8252

Total: $1,755.27

Table 6.1: Budget Spending

Conclusions

• Project Summary (7.1)• Personal Conclusions (7.2)

7.1 Project Summary

Holistically, the project encompassed a wide variety of knowledge that was coveredor at least touched upon in previous classes. As for material that wasn’t taught inclass, a lot of research went into exploring the ins and outs of specific sub-systemsthat were a part of the whole project. Categorically organizing the project, wehave broken it down into 3 main sections:

• Hardware (3.1)• Software (3.2)

As luck would have it, our group of 4 is comprised of 2 electrical engineers and 2computer engineers. This allowed us to focus on our respective majors in that theelectrical engineers focused on hardware while the computer engineers focused onthe software aspect with everyone equally working on the Housing and Mountingsystem.

The hardware portion focused mainly on the motor, power supply, camera, andcomputer that were going to be used for the project. On the other hand, thesoftware aspect was centered around setting up the Atom 1024 Camera and allof the logic that will go between each sub-system i.e. how all of the sub-systemscommunicate with each other. As development progressed this became mainlyinterfacing the camera with the end-user application for image processing. Lastly,the housing and mounting portion of the project focused on how each differentcomponent and subsystem will be placed and ultimately housed. Since the projectwas going to be used in different environments, a lot of consideration went into howeach of the components will be placed and logistically connected to each other.

137

Section 7. Conclusions 138

7.2 Personal Conclusions

7.2.1 Laith Charles Conclusions/Reflections

My college education has consisted mostly of learning through a textbook, listeningto lectures, and performing controlled lab experiments where existing solutionshave already been predetermined to work. This project has given me a glimpse ofwhat realistic product design is like. Applying knowledge learned in the classroomto an actual real world application is interesting and challenging. It was excitingto turn this long report into something tangible. Looking back on the semesterI did not realize the amount of design considerations which go into planning aproduct. Every detail needs to be considered, there are so many choices when itcomes to choosing something as simple as an LED. There are so many solutions totoday’s problems given the wealth of electrical components at our disposal today.Even considering the length of the report I am sure there are some design aspectswhich have been overlooked. Looking back at our initial design and reviewing thedesign changes we made throughout the semester and some compromises whichwe made to achieve a working project. We learned so much over the year whichwill help us in future projects in planning more appropriately.

7.2.2 Alejandro Drausal Conclusions/Reflections

I am finally looking forward to what is beyond Senior Design. The design phasehad a lot housekeeping that I was not too fond of. Implementing the design was aserious challenge as well, and I was not prepared for the drastic changes that had tobe done. I realized how many things that were thought of did not end up makingit to the implemented design. Fortunately with the internet and my backgroundwe were able to figure out solutions to the problems that we faced. It took someserious engineering to come up with solutions to implementation problems. Nowthat graduation is around the corner, I am excited to see where I will be next.

7.2.3 Nicholas Gaor Conclusions/Reflections

All throughout college and especially in the engineering department, you overhearpeople always talking about their Senior Design project as if it’s a fabled myth ofinsane difficulty and back breaking work. After completing Senior Design I and II,I realize that complications can arise from the smallest problems. Senior Designdoesn’t just test technical skills, but logistical and managerial as well. Being incharge of the motors and power supply, it felt accomplishing to be specializedin a specific aspect of the project and to contribute to something much greaterthan yourself. In taking Senior Design I and II, I feel that my technical and teambuilding skills have been challenged and strengthened.

Section 7. Conclusions 139

7.2.4 Tyler Johnson Conclusions/Reflections

Throughout my college career I have been building skills in teamwork and timemanagement, which take just as much effort to develop as the technical skills Ihave been accumulating. With this project I see the culmination of these efforts.Without a doubt the work we did throughout both semesters proved to be the mostvaluable and critically difficult work I have ever encountered. I think as a wholeour group learned the value in constant, clear communication. We also learnedthe importance in realizing when solutions to problems aren’t going to work, andmoving on swiftly to the next best option. After seeing the kind of issues thatcame up as the semester went on, I have come to appreciate how projects can shiftdrastically as development goes on.

Appendix

1. St Johns Optical Systems Approval 141

2. Applied Motions Approval ... 142

3. Omega Engineering Approval ... 143

4. UCF Logo Approval ... 144

5. FLIR Approval ... 145

6. Lomography Approval ... 146

7. ScanCam Approval ... 147

8. Sofradir Approval ... 148

9. Pending OSRAM Approval ... 149

10. Pending LiteOnIt Approval ... 150

11. Pending Xilinx Approval ... 151

12. Pending NEOS Approval ... 152

13. Pending DRS Approval ... 153

140

Appendix. Appendix 141

1

Alejandro Drausal

From: Orges Furxhi

Sent: Saturday, July 19, 2014 2:44 PM

To: Alejandro Drausal

Subject: Re: Use of a Panoramic IR Image on Senior Design Project

Categories: Red Category

Sure

Sent from my iPhone

On Jul 19, 2014, at 2:20 PM, "Alejandro Drausal" <[email protected]> wrote:

Orges,

Could I use one of the images from the boat on the project?

-Aj

<image001.png>

Alejandro Drausal (Aj)

Jr. Engineer, St. Johns Optical Systems

4100 St Johns Pkwy

Sanford, FL 32771

772.226.0826

[email protected]

Figure A.1: St Johns Optical Systems Approval


From: Morgan Spenla <[email protected]>Sent: Tuesday, July 29, 2014 12:53 AMTo: Ngaor; Don MacleodSubject: Re: Applied Motion Products Hi Nicholas, Can you tell us more about your project? We would love to feature you in an upcoming AMP newsletter if you’reinterested in sharing finished photos and a little about your work. The images you sent over look fine to me. Thanks,Morgan SpenlaDirector of Marketing

Applied Motion ProductsApplied-Motion.com [email protected] Learn more about who we are in 60 seconds in this short video.

From: Ngaor <[email protected]>Date: Monday, July 28, 2014 at 5:05 PMTo: 'Don Macleod' <[email protected]>Cc: Morgan Spenla <[email protected]>Subject: RE: Applied Motion Products Don and Morgan, I have attached the pictures that I will be using for our technical report regarding the STR 2 Driver. I have them fromthis site: http://www.applied-motion.com/sites/default/files/hardware-manuals/STR2%20Hardware%20Manual%20920-0059B.pdf . Each of the pictures corresponds with specific text from the paper talkingabout the different features of the STR 2 and how they apply to our project. Please let me know if this is ok. Here is alsothe link to the technical paper we are writing in case you want to see the text that corresponds to thepictures: https://www.writelatex.com/read/gfjyyhwbtcmj Thank you for your time, -Nicholas

Figure A.2: Applied Motions Approval


From: Adam, Donna <[email protected]>Sent: Tuesday, July 29, 2014 5:06 PMTo: NgaorSubject: RE: Reprint Request - Omega Part #OMHT17-075 (Stepper Motor)

Good Afternoon Mr. Gaor:I can grant you permission in a Reprint Agreement to use the information for the OMHT series but there is athird party who also has rights to the PS Series information and I am doubtful that I will hear back from him ona timely basis in order to get his permission for this reprint request especially since your deadline is in 2 days. Please let me know if you are agreeable to me issuing a permission letter just for the OMHT Seriesinformation.Best regards,Donna Adam

From: Ngaor [mailto:[email protected]] Sent: Tuesday, July 29, 2014 11:14 AMTo: Adam, DonnaSubject: Re: Reprint Request - Omega Part #OMHT17-075 (Stepper Motor) Hi Donna, I appreciate the quick reply on your end. Here is the information that you will need: 1. Cost Effective Panormic Infrared Camera 2. Due date: 3. The paper will be submitted to our professor and later uploaded onto a website designed by my group. 4. My personal address is 13242 summer rain drive orlando fl 32828. University of Central Florida's address is 4000 Central Florida Blvd, Orlando, FL 32816.

I request permission to use content from the following pages: http://www.omega.com/Auto/pdf/OMHT_Series.pdf http://www.omega.com/Auto/pdf/PS_Series.pdf http://www.omega.com/pptst/OMHT_Series.html http://www.omega.com/pptst/PS_Series.html Here is the link to our paper in the works as well in case you're curious or need to know where each of theseparts are being applied: https://www.writelatex.com/read/gfjyyhwbtcmj

Thank you for your time, -Nicholas Gaor

On Jul 29, 2014, at 10:53 AM, "Adam, Donna" <[email protected]> wrote:

Good Morning Mr. Gaor:Could you submit a copy or provide a link of the information that you would like to use in yourpaper?Thank you.Best regards,Donna Adam

7/31/14

Figure A.3: Omega Engineering Approval


1

Alejandro Drausal

From: Sue Gonzalez <[email protected]>

Sent: Wednesday, July 30, 2014 4:12 PM


Subject: RE: Licensing

Hi Alejandro,

This is approved. Best of luck on your project.

From: Alejandro Drausal [mailto:[email protected]]

Sent: Wednesday, July 30, 2014 4:09 PM To: Sue Gonzalez

Subject: RE: Licensing

Sue,

We plan on using this one.

Regards,

Alejandro Drausal

From: Sue Gonzalez [mailto:[email protected]]

Sent: Wednesday, July 30, 2014 9:09 AM

To: [email protected]

Subject: Licensing

Hi Alejandro,

When is a good time for me to reach out to you to discuss your inquiry?

Sue Gonzalez

Marketing Coordinator

UCF Business Services

Twitter: @ucfbusserv

[email protected]

407.823.3539

Figure A.4: UCF Logo Approval


1

Alejandro Drausal

From: Laith Charles <[email protected]>

Sent: Thursday, July 31, 2014 1:12 AM


Subject: Fwd: Your request to FLIR?

---------- Forwarded message ---------- From: Hirst, Barry <[email protected]> Date: Wed, Jul 16, 2014 at 1:21 PM Subject: Re: Your request to FLIR? To: Laith Charles <[email protected]>

Laith, Not a problem, good luck! Sent from my iPhone Regards, Barry Hirst Sales Director, South Region FLIR Systems, Inc 866 837 3235 281-536-5251 On Jul 16, 2014, at 12:04 PM, "Laith Charles" <[email protected]> wrote:

Barry, Thanks for getting back to me. I am a student at UCF working on a group senior design project. Our group is comparing a variety of mid-resolution LWIR detectors in the research portion of the report one of the options we are considering is the A35. With written consent, we would like to include some of the visuals in the "FLIR automation brochure" to provided a visual aid to enhance the report. Please let us know if that would be acceptable. If you have any questions feel free to ask. Regards, Laith

Figure A.5: FLIR Approval


From: Laith Charles <[email protected]> To: [email protected] Subject: 360 Date: Tue, Jul 8, 2014, 1:28PM To Whom it may concern, I am a student at the University of Central Florida. Myself and my group are designing a infrared panoramic system for our senior design report. During our research we found your solution interesting. With your consent, we would like to include some information and visuals from this website. http://shop.lomography.com/us/cameras/panoramic-cameras Please let us know if you have any question. Thank you for your time. Regards, Laith Charles From: Juan Hoyos <[email protected]> To: Laith Charles <[email protected]> Subject: Re: 360 Date: Wed, Jul 9, 2014, 8:33PM Hello Laith, Your report sounds really interesting, please feel free to use our images, once your report is ready please send it back to me so we can take a look at it. Thanks! From: Laith Charles <[email protected]> To: [email protected] Subject: Re: 360 Date: Sat, Jul 12, 2014, 3:59PM Juan, I would be happy to do that. Thank you for your consent. Regards, Laith

Figure A.6: Lomography Approval


1

Alejandro Drausal




Subject: Fwd: Copyright permission request

---------- Forwarded message ---------- From: Thomas Sharpless <[email protected]> Date: Tue, Jul 8, 2014 at 1:47 PM Subject: Re: Copyright permission request To: Laith Charles <[email protected]>

Of course, you are free to quote that paper, and use any of the images from tksharpless.com in your report. And please send me a link to the result. -- Tom Sharpless

On Tue, Jul 8, 2014 at 12:23 PM, Laith Charles <[email protected]> wrote: Dear T.K. Sharpless, I am a student at the University of Central Florida. Myself and my group are designing a infrared panoramic system for our senior design report. During our research we found your solution interesting. With your consent, we would like to include some information and visuals from this website. http://tksharpless.com/A%20Digital%20Rotating%20Panoramic%20Camera.htm Please let us know if you have any question. Thank you for your time. Regards, Laith Charles

Figure A.7: ScanCam Approval


1

Alejandro Drausal

Subject: FW: FW: Thank you for Your Interest - Sofradir EC Infrared Systems

---------- Forwarded message ---------- From: Joan Gargiulo <[email protected]> Date: Fri, Jul 25, 2014 at 8:46 AM Subject: FW: Thank you for Your Interest - Sofradir EC Infrared Systems To: [email protected]

Hi Laith,

Brooke Herbst reached out to me to let me know, we would be pleased for your team to utilize the information on our Pico 384. We do ask that you reference our website as your source.

Thank you again for your interest.

Best regards,

Joan

From: Laith Charles [mailto:[email protected]] Sent: Thursday, July 24, 2014 4:00 PM

To: Joan Gargiulo Subject: Re: Thank you for Your Interest - Sofradir EC Infrared Systems

To Joan,

I am a student at the University of Central Florida. Myself and my group are designing a infrared panoramic system for our senior design report. During our research for the project we looked into using the Sofradir Pico 384. With your permission, we would like to include some information about the Pico and a graphic of the focal plane in our report. All of the necessary information would be taken from the following link.

http://www.electrophysics.com/DbImages/SofEC-Pico384-v02.pdf

Please let us know if you have any question.

Thank you for your time. Regards, Laith Charles

Figure A.8: Sofradir Approval


1

Alejandro Drausal




Subject: Fwd: Copyright release request

---------- Forwarded message ---------- From: Laith Charles <[email protected]> Date: Wed, Jul 30, 2014 at 5:04 PM Subject: Copyright release request To: [email protected]

Stefan, I am a student at the University of Central Florida. Me and my group members are purchasing a few of your LEDs for our senior design project. We would like to include some images and information regarding the specific diode we used in our report. Would you be willing to release the copyright information regarding the specific product. We would only include an image of the product in its undoctored form and various other information included in the data sheet. The diode selected is the SFH 4243. Please let me know if you have any questions, Regards, Laith

Figure A.9: Pending OSRAM Approval


1

Alejandro Drausal




Subject: Fwd: Copyright release request

---------- Forwarded message ---------- From: Laith Charles <[email protected]> Date: Wed, Jul 30, 2014 at 5:11 PM Subject: Copyright release request To: [email protected]

To Who it may concern, I am a student at the University of Central Florida. Me and my group members are purchasing a few of your phototransistors for our senior design project. We would like to include some images and information regarding the specific diode we used in our report. Would you be willing to release the copyright information regarding the specific product. We would only include an image of the product in its undoctored form and various other information included in the data sheet. The transistor selected is the LTR-3208E. Please let me know if you have any questions, Regards, Laith

Figure A.10: Pending LiteOnIt Approval


Figure A.11: Pending Xilinx Approval


1

Alejandro Drausal




Subject: Fwd: copyright permission request

---------- Forwarded message ---------- From: Laith Charles <[email protected]> Date: Tue, Jul 8, 2014 at 12:11 PM Subject: copyright permission request To: [email protected]

To whom it may concern, I am a student at the University of Central Florida. Myself and my senior design group are developing a LWIR panoramic solution for our senior design project. With your consent, we would like to include your product in our research and with your consent we would like to include some of the images on your website indicated by the link below. http://www.neos-inc.com/ProductSpotlight.php Please let us know if you have any questions. Regards, Laith Charles

Figure A.12: Pending NEOS Approval


1

Alejandro Drausal

Subject: FW: Copyright Permission

From: Alejandro Drausal

Sent: Friday, July 18, 2014 7:03 PM

To: 'Skidmore, George'

Cc: '[email protected]'; '[email protected]'; '[email protected]'

Subject: Copyright Permission

Good evening George,

We are creating a document for our Senior Design and we would like to use some images from the Tamarisk Data

sheets.

Doc. 1012819 – Using the all tables for Software Specs

Doc. 1012820 – Using Figure 4; Figure 12; Figure 13; Figure 21

http://www.drsinfrared.com/Portals/0/docs/datasheets/TamariskFamily_Datasheet_MR-2013-01-654_Rev07.pdf --

Various Tamerisk Images, With and without lens

Doc. 1003727 – Mechanical Drawing of 1003728-L000

Regards,

Alejandro Drausal

Alejandro Drausal (Aj)

Jr. Engineer, St. Johns Optical Systems

4100 St Johns Pkwy

Sanford, FL 32771

772.226.0826

[email protected]

Figure A.13: Pending DRS Approval

Bibliography

[1] Thermal imaging cameras for Automation & Fire and Safety. FLIR, 3 2014.Rev. B.

[2] TAMARISK INFRARED SOLUTIONS THAT FIT. DRS, 1 2013. Rev. 7.

[3] Pico 384 384x288 (17um) Uncooled Microbolometer. Sofradir, 2013. Ver. 1.

[4] Matthew Murray. Ddr vs. ddr2 vs. ddr3: Types of ram explained. PC Maga-zine, 2 2012. URL http://www.pcmag.com/article2/0,2817,2400801,00.

asp.

[5] Zynq-7000 All Programmable SoC Overview. Xilinx, 12 2013. Ver. 1.6.

[6] Arria V Device Overview. Altera Corporation, 12 2013.

[7] Matthew Burris. Stepper motors vs servo motors - selecting amotor. URL http://components.about.com/od/Components/a/

Stepper-Motors-Vs-Servo-Motors-Selecting-A-Motor.htm.

[8] Hardware Manual STR2 Step Motor Drive. Omega, 1 2014. URL http:

//www.applied-motion.com/sites/default/files/hardware-manuals/

STR2%20Hardware%20Manual%20920-0059B.pdf.

[9] Community Sourced. Rpi usb wi-fi adapters, 6 2014. URL http://elinux.

org/RPi_USB_Wi-Fi_Adapters.

[10] Power Supplies for Open Frame Stepper Drives. Omega, 12 2013. URLhttp://www.omega.com/Auto/pdf/PS_Series.pdf.

[11] Dries van Wageningen. An introduction to wireless charging, 7 2013. URLhttp://www.wirelesspowerconsortium.com/.

[12] Tamarisk 320 Electrical Interface Control Document. Omega, 5 2014. Rev.D.

[13] Zynq-7000 All Programmable SoC DC and AC Switching Characteristics (Z-7010, Z-7015, and Z-7020). Xilinx, 7 2014. Ver. 1.12.

[14] 64M x 16 bit DDR3L Synchronous DRAM (SDRAM). Alliance Memory, 42014. Rev. 1.0.

154

http://www.pcmag.com/article2/0,2817,2400801,00.asp

http://www.pcmag.com/article2/0,2817,2400801,00.asp

http://components.about.com/od/Components/a/Stepper-Motors-Vs-Servo-Motors-Selecting-A-Motor.htm

http://components.about.com/od/Components/a/Stepper-Motors-Vs-Servo-Motors-Selecting-A-Motor.htm

http://www.applied-motion.com/sites/default/files/hardware-manuals/STR2%20Hardware%20Manual%20920-0059B.pdf



http://elinux.org/RPi_USB_Wi-Fi_Adapters

http://elinux.org/RPi_USB_Wi-Fi_Adapters

http://www.omega.com/Auto/pdf/PS_Series.pdf

http://www.wirelesspowerconsortium.com/

Bibliography 155

[15] MircoZed Production. Avnet Electronics Marketing, 1 2014. Rev. F.

[16] High Power Infrared Emitter (940 nm). OSRAM, 12 2013. Ver. 1.1.

[17] Circuits Today. Voltage regulators, November 2008. URL http://www.

circuitstoday.com/category/voltage-regulators.

[18] Stepper Motors Frame Sizes From NEMA 11 to 34. Omega, 12 2013. URLhttp://www.omega.com/Auto/pdf/OMHT_Series.pdf.

[19] IR Emitter and Detector Product Data Sheet LTR-3208E. Liteon Optoelec-tronics, 5 2000. Rev. A.

[20] Tamarisk 320 Software Interface Control Document. DRS, 11 2013. Rev. E.

http://www.circuitstoday.com/category/voltage-regulators

http://www.circuitstoday.com/category/voltage-regulators

http://www.omega.com/Auto/pdf/OMHT_Series.pdf

Cost Effective Panoramic Infrared...

Documents

Transcript of Cost Effective Panoramic Infrared...