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 ProductsJuly 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 ii

List of Figures ix

List of Tables xiii

Executive Summary 1

1 Project Description 5

1.1 Project Motivation and Goals . . . . . . . . . . . . . . . . . . . . . 5

1.2 Project Requirements and Specifications . . . . . . . . . . . . . . . 6

1.2.1 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.2 Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.3 Operational Use . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2.4 Relevant Software or Hardware Specifications . . . . . . . . 7

1.2.5 Interface and/or Compatibility . . . . . . . . . . . . . . . . 7

2 Research 9

2.1 Existing Panoramic Solutions . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Smartphones . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.2 Film Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.3 Fisheye Panoramic . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.4 Digital Rotating Panorama . . . . . . . . . . . . . . . . . . 12

2.1.5 Comparison of Panoramic Solutions . . . . . . . . . . . . . . 13

2.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 Infrared Detector . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1.1 FLIR A35 . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1.2 DRS Tamarisk 320 . . . . . . . . . . . . . . . . . . 16

2.2.1.3 Sofradir PicoTM 384 . . . . . . . . . . . . . . . . . 17

2.2.1.4 Comparison of Cameras . . . . . . . . . . . . . . . 18

2.2.2 FPGA Hardware . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.2.1 Xilinx Spartan-6 . . . . . . . . . . . . . . . . . . . 20

2.2.2.2 Xilinx Artix-7 . . . . . . . . . . . . . . . . . . . . . 20

2.2.2.3 Xilinx Kintex-7 . . . . . . . . . . . . . . . . . . . . 20

2.2.2.4 Xilinx Zynq-7000 . . . . . . . . . . . . . . . . . . . 21iii

Contents iv

2.2.2.5 Arria V Family . . . . . . . . . . . . . . . . . . . . 22

2.2.2.6 Comparison of FPGAs . . . . . . . . . . . . . . . . 22

2.2.3 RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.3.1 Pin Grid Array . . . . . . . . . . . . . . . . . . . . 23

2.2.3.2 Ball Grid Array . . . . . . . . . . . . . . . . . . . . 23

2.2.3.3 DDR2 . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.3.4 DDR3 . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.4 Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.4.1 Servo Motors . . . . . . . . . . . . . . . . . . . . . 26

2.2.4.2 Stepper Motors . . . . . . . . . . . . . . . . . . . . 27

2.2.4.3 Stepper Motor Vs. Servo Motor . . . . . . . . . . . 28

2.2.4.4 Encoders . . . . . . . . . . . . . . . . . . . . . . . 29

2.2.4.5 Motor Driver . . . . . . . . . . . . . . . . . . . . . 29

2.2.4.6 Pricing Comparisons . . . . . . . . . . . . . . . . . 30

2.2.5 Wi-Fi Hardware . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2.5.1 Embedded Wi-Fi Module . . . . . . . . . . . . . . 31

2.2.5.2 USB Wi-Fi Dongle . . . . . . . . . . . . . . . . . . 31

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

2.3 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3.1 Network Communication . . . . . . . . . . . . . . . . . . . . 32

2.3.1.1 Wired . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.1.2 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.1.3 Radio . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.3.1.4 Cellular Network . . . . . . . . . . . . . . . . . . . 33

2.3.1.5 Network Communication Comparison . . . . . . . . 34

2.3.2 Motor Communication . . . . . . . . . . . . . . . . . . . . . 34

2.3.2.1 Inverted Motor Communication . . . . . . . . . . . 34

2.3.2.2 Optical Interface . . . . . . . . . . . . . . . . . . . 35

2.3.2.3 Slip-Ring . . . . . . . . . . . . . . . . . . . . . . . 36

2.3.2.4 Radio/Microwave Frequency . . . . . . . . . . . . . 36

2.3.2.5 Autonomous . . . . . . . . . . . . . . . . . . . . . 37

2.3.2.6 Comparison of Motor Communication . . . . . . . 37

2.4 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.4.1 Power Supply Unit . . . . . . . . . . . . . . . . . . . . . . . 39

2.4.2 Induction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.4.3 Solar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.4.4 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.4.5 Regulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.4.6 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.5 Mechanical System and Packaging . . . . . . . . . . . . . . . . . . . 43

2.5.1 Housing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.5.1.1 Water-Proofing . . . . . . . . . . . . . . . . . . . . 44

2.5.1.2 Temperature-Proofing . . . . . . . . . . . . . . . . 45

2.5.1.3 Wind-Proofing . . . . . . . . . . . . . . . . . . . . 45

Contents v

2.5.1.4 Surge-Protection . . . . . . . . . . . . . . . . . . . 45

2.5.2 Camera Mount . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.5.3 Motor Mount . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.5.4 Control Mount . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.6 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.6.1 FPGA Software . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.6.1.1 Xillinux . . . . . . . . . . . . . . . . . . . . . . . . 48

2.6.1.2 Arch Linux ARM . . . . . . . . . . . . . . . . . . . 48

2.6.1.3 Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . 49

Operating System Comparison . . . . . . . . . . . . . 49

2.6.2 Data Representation . . . . . . . . . . . . . . . . . . . . . . 49

2.6.3 Development Environment . . . . . . . . . . . . . . . . . . . 50

2.6.3.1 Xilinx IDEs . . . . . . . . . . . . . . . . . . . . . . 50

ISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Vivado . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.6.3.2 Altera IDE . . . . . . . . . . . . . . . . . . . . . . 50

SoC Embedded Design Suite . . . . . . . . . . . . . . 51

Final IDE Comparison . . . . . . . . . . . . . . . . . 51

3 Design 53

3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.1.1 Rotational Platform . . . . . . . . . . . . . . . . . . . . . . 54

3.1.1.1 Tamarisk . . . . . . . . . . . . . . . . . . . . . . . 55

Pin Layout . . . . . . . . . . . . . . . . . . . . . . . . 55

Data Out . . . . . . . . . . . . . . . . . . . . . . . . 55

Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Camera Control . . . . . . . . . . . . . . . . . . . . . 56

Power . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Timing . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.1.1.2 Zynq . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Pin Configuration . . . . . . . . . . . . . . . . . . . . 57

MicroZed . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.1.1.3 Wireless Communication . . . . . . . . . . . . . . . 60

3.1.1.4 Inductive Coil Interface . . . . . . . . . . . . . . . 60

3.1.1.5 Platform . . . . . . . . . . . . . . . . . . . . . . . . 61

3.1.2 Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.1.2.1 Light Emitting Diodes . . . . . . . . . . . . . . . . 63

3.1.3 Base Unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.1.3.1 Power Supply Unit . . . . . . . . . . . . . . . . . . 67

3.1.3.2 Battery . . . . . . . . . . . . . . . . . . . . . . . . 68

3.1.3.3 Voltage Regulators . . . . . . . . . . . . . . . . . . 69

3.1.3.4 Stepper Motor . . . . . . . . . . . . . . . . . . . . 70

3.1.3.5 Motor Driver . . . . . . . . . . . . . . . . . . . . . 72

3.1.3.6 Motor Controller . . . . . . . . . . . . . . . . . . . 74

Contents vi

3.1.3.7 Light Sensor . . . . . . . . . . . . . . . . . . . . . 76

3.1.3.8 Inductive Coils . . . . . . . . . . . . . . . . . . . . 77

3.1.4 Viewing Interface . . . . . . . . . . . . . . . . . . . . . . . . 78

3.1.4.1 Web Site . . . . . . . . . . . . . . . . . . . . . . . 78

3.1.4.2 Display . . . . . . . . . . . . . . . . . . . . . . . . 79

3.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.2.1 Camera Communication . . . . . . . . . . . . . . . . . . . . 79

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

3.2.1.2 Programming the UART . . . . . . . . . . . . . . . 82

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

Set rate of camera calibrations . . . . . . . . . . . . . 85

Gets rate between camera calibrations . . . . . . . . . 85

Set strength of ICE filter . . . . . . . . . . . . . . . 85

Set ICE min and max values . . . . . . . . . . . . . 86

Enable ICE mode . . . . . . . . . . . . . . . . . . . . 86

Automatic calibration activity query . . . . . . . . . 86

Enable automatic calibration . . . . . . . . . . . . . . 86

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

Enable black-hot scheme . . . . . . . . . . . . . . . . 87

Enable white-hot scheme . . . . . . . . . . . . . . . . 87

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

Set AGC gain manually . . . . . . . . . . . . . . . . . 87

Set AGC level manually . . . . . . . . . . . . . . . . 87

Set AGC gain bias manually . . . . . . . . . . . . . . 88

Set AGC level bias manually . . . . . . . . . . . . . . 88

Set AGC region of interest . . . . . . . . . . . . . . . 88

Toggle auto-calibration . . . . . . . . . . . . . . . . . 88

Select video orientation . . . . . . . . . . . . . . . . . 89

Set non-volatile parameters . . . . . . . . . . . . . . . 89

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

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

Select digital video source . . . . . . . . . . . . . . . 89

Set baud rate . . . . . . . . . . . . . . . . . . . . . . 90

Get system status . . . . . . . . . . . . . . . . . . . . 90

Select test pattern . . . . . . . . . . . . . . . . . . . . 90

3.2.2 Motor Communication . . . . . . . . . . . . . . . . . . . . . 90

3.2.3 Motor Control . . . . . . . . . . . . . . . . . . . . . . . . . . 90

3.2.4 FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

3.2.5 Embedded Linux . . . . . . . . . . . . . . . . . . . . . . . . 93

3.2.5.1 Web Server . . . . . . . . . . . . . . . . . . . . . . 93

3.2.5.2 RTSP . . . . . . . . . . . . . . . . . . . . . . . . . 93

3.2.5.3 Serial Com . . . . . . . . . . . . . . . . . . . . . . 93

3.2.5.4 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . 94

3.2.6 Platform Communication . . . . . . . . . . . . . . . . . . . . 94

Contents vii

3.2.7 End-User Interface . . . . . . . . . . . . . . . . . . . . . . . 95

3.2.8 Network Access . . . . . . . . . . . . . . . . . . . . . . . . . 95

3.2.9 Output Protocol . . . . . . . . . . . . . . . . . . . . . . . . 96

3.2.10 Video Output . . . . . . . . . . . . . . . . . . . . . . . . . . 96

3.2.11 Image Processing . . . . . . . . . . . . . . . . . . . . . . . . 96

3.3 Housing and Mounting . . . . . . . . . . . . . . . . . . . . . . . . . 97

3.3.1 Camera Mount . . . . . . . . . . . . . . . . . . . . . . . . . 98

3.3.2 Motor Mount . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.3.3 Control Mount . . . . . . . . . . . . . . . . . . . . . . . . . 102

3.3.4 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

4 Construction Testing and Evaluation 105

4.1 Tamarisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

4.1.1 Testing the Clocks . . . . . . . . . . . . . . . . . . . . . . . 105

4.1.2 Testing the Data Out . . . . . . . . . . . . . . . . . . . . . . 106

4.2 Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

4.3 Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.3.1 Making sure the motor works . . . . . . . . . . . . . . . . . 107

4.3.2 Testing the Arduino as a controller . . . . . . . . . . . . . . 107

4.3.3 Testing the LED trigger . . . . . . . . . . . . . . . . . . . . 108

4.4 FPGA/Control Unit . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.4.1 I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.4.2 Software Unit Testing . . . . . . . . . . . . . . . . . . . . . 109

4.4.3 End-User Interface . . . . . . . . . . . . . . . . . . . . . . . 113

4.5 Power and Regulation . . . . . . . . . . . . . . . . . . . . . . . . . 113

4.6 System Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 114

4.6.1 Indoor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

4.6.2 Outdoor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

5 Administrative Content 117

5.1 Milestone Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 117

5.1.1 August . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

5.1.1.1 Procurement . . . . . . . . . . . . . . . . . . . . . 117

5.1.1.2 Motor Interface . . . . . . . . . . . . . . . . . . . . 118

5.1.2 September . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

5.1.2.1 Camera Data Extraction . . . . . . . . . . . . . . . 118

5.1.2.2 Mechanical System . . . . . . . . . . . . . . . . . . 119

5.1.2.3 Host Server . . . . . . . . . . . . . . . . . . . . . . 120

5.1.2.4 Software Image . . . . . . . . . . . . . . . . . . . . 120

5.1.2.5 Calibrate Focal Point . . . . . . . . . . . . . . . . . 120

5.1.3 October . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

5.1.3.1 PCB Design . . . . . . . . . . . . . . . . . . . . . . 121

5.1.3.2 Optical Communication . . . . . . . . . . . . . . . 121

5.1.3.3 Image Stitching . . . . . . . . . . . . . . . . . . . . 122

Contents viii

5.1.3.4 Implement Custom PCB . . . . . . . . . . . . . . . 122

5.1.3.5 Inductive Power . . . . . . . . . . . . . . . . . . . 122

5.1.4 November . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

5.1.4.1 Housing . . . . . . . . . . . . . . . . . . . . . . . . 123

5.1.4.2 Durability . . . . . . . . . . . . . . . . . . . . . . . 124

5.1.4.3 Software Features . . . . . . . . . . . . . . . . . . . 124

5.1.4.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . 124

5.1.4.5 Aesthetics . . . . . . . . . . . . . . . . . . . . . . . 124

5.1.4.6 Presentation . . . . . . . . . . . . . . . . . . . . . 124

5.2 Budget Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

5.2.1 Power Supply . . . . . . . . . . . . . . . . . . . . . . . . . . 125

5.2.2 Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

5.2.3 Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

5.2.4 Development Board . . . . . . . . . . . . . . . . . . . . . . . 126

5.2.5 Zynq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

5.2.6 RAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

5.2.7 PCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

5.2.8 Misc. Supplies . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6 Conclusions 129

6.1 Project Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

6.2 Personal Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 130

6.2.1 Laith Charles Conclusions/Reflections . . . . . . . . . . . . 130

6.2.2 Alejandro Drausal Conclusions/Reflections . . . . . . . . . . 130

6.2.3 Nicholas Gaor Conclusions/Reflections . . . . . . . . . . . . 130

6.2.4 Tyler Johnson Conclusions/Reflections . . . . . . . . . . . . 131

A Appendix 133

Bibliography 147

List of Figures

2.1 Spinner 360 Camera . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Spinner 360 Film . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Fisheye Lens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Fisheye Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 ScanCam Device Overview . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 ScanCam Labeled Diagram . . . . . . . . . . . . . . . . . . . . . . 14

2.7 ScanCam Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.8 FLIR A35 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.9 DRS Tamarisk 320 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.10 DRS Tamarisk Image Enhancement . . . . . . . . . . . . . . . . . . 18

2.11 Sofradir PicoTM 384 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

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

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

2.14 Typical BGA Layout . . . . . . . . . . . . . . . . . . . . . . . . . . 24

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

2.16 LED Platform Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.17 Slip Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.18 Motor Power Delivery Block Diagram . . . . . . . . . . . . . . . . . 43

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

3.1 Hardware Design Flowchart . . . . . . . . . . . . . . . . . . . . . . 54

3.2 Rotational Platform Dimensions . . . . . . . . . . . . . . . . . . . . 55

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

3.4 Tamarisk Pin Connection . . . . . . . . . . . . . . . . . . . . . . . 56

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

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

3.7 Solidworks Platform Dimensions . . . . . . . . . . . . . . . . . . . . 62

3.8 Tamarisk FOV illustration . . . . . . . . . . . . . . . . . . . . . . . 63

3.9 LED Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.10 LED Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

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

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

3.13 RPS graph data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.14 OMPS300A48 Schematic . . . . . . . . . . . . . . . . . . . . . . . . 68

3.15 Voltage Regulator Circuit . . . . . . . . . . . . . . . . . . . . . . . 70ix

List of Figures x

3.16 OMHT17 Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.17 STR 2 stepper Driver Dimensions . . . . . . . . . . . . . . . . . . . 73

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

3.19 STR 2 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 74

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

3.21 STR 2 Example Wiring . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.22 STR 2 Motor Configuration . . . . . . . . . . . . . . . . . . . . . . 76

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

3.24 Web page View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.25 Data Flow in Software . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.26 Xilinx Software Block Design . . . . . . . . . . . . . . . . . . . . . 81

3.27 Xilinx MIO Configuration . . . . . . . . . . . . . . . . . . . . . . . 82

3.28 Xilinx MIO UART Configuration . . . . . . . . . . . . . . . . . . . 82

3.29 Serial Write to Tamarisk . . . . . . . . . . . . . . . . . . . . . . . . 83

3.30 Serial Read to Tamarisk . . . . . . . . . . . . . . . . . . . . . . . . 84

3.31 Simple Stepper Motor . . . . . . . . . . . . . . . . . . . . . . . . . 91

3.32 Complex Stepper Motor . . . . . . . . . . . . . . . . . . . . . . . . 92

3.33 End-User Communication . . . . . . . . . . . . . . . . . . . . . . . 95

3.34 Tamarisk Camera Mount . . . . . . . . . . . . . . . . . . . . . . . . 99

3.35 Riser Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

3.36 Combining All of the Mount Sub-Systems . . . . . . . . . . . . . . 104

4.1 Functionality of Input Buffer . . . . . . . . . . . . . . . . . . . . . . 109

5.1 August Timeline 8/18-8/31 . . . . . . . . . . . . . . . . . . . . . . 118

5.2 September Timeline 9/1-9/14 . . . . . . . . . . . . . . . . . . . . . 119

5.3 September Timeline 9/15-9/30 . . . . . . . . . . . . . . . . . . . . . 119

5.4 October Timeline 10/1-10/14 . . . . . . . . . . . . . . . . . . . . . 121

5.5 October Timeline 10/15-10/31 . . . . . . . . . . . . . . . . . . . . . 121

5.6 November Timeline 11/1-11/14 . . . . . . . . . . . . . . . . . . . . 123

5.7 November Timeline 11/15-11/28 . . . . . . . . . . . . . . . . . . . . 123

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

A.2 Applied Motions Approval . . . . . . . . . . . . . . . . . . . . . . . 135

A.3 Omega Engineering Approval . . . . . . . . . . . . . . . . . . . . . 136

A.4 UCF Logo Approval . . . . . . . . . . . . . . . . . . . . . . . . . . 137

A.5 FLIR Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

A.6 Lomography Approval . . . . . . . . . . . . . . . . . . . . . . . . . 139

A.7 ScanCam Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

A.8 Sofradir Approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

A.9 Pending OSRAM Approval . . . . . . . . . . . . . . . . . . . . . . . 142

A.10 Pending LiteOnIt Approval . . . . . . . . . . . . . . . . . . . . . . 143

A.11 Pending Xilinx Approval . . . . . . . . . . . . . . . . . . . . . . . . 144

A.12 Pending NEOS Approval . . . . . . . . . . . . . . . . . . . . . . . . 145

List of Figures xi

A.13 Pending DRS Approval . . . . . . . . . . . . . . . . . . . . . . . . . 146

List of Tables

2.1 Servo Motor Comparison pt. 1 . . . . . . . . . . . . . . . . . . . . . 26

2.2 Servo Motor Comparison pt. 2 . . . . . . . . . . . . . . . . . . . . . 26

2.3 Stepper Motor Comparison pt. 1 . . . . . . . . . . . . . . . . . . . 27

2.4 Stepper Motor Comparison pt. 2 . . . . . . . . . . . . . . . . . . . 27

2.5 Stepper Vs. Servo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.6 Stepper Motor Vs. Servo Motor Price . . . . . . . . . . . . . . . . . 31

2.7 Network Communication Comparison . . . . . . . . . . . . . . . . . 34

2.8 Comparison of Motor Communication . . . . . . . . . . . . . . . . . 37

2.9 Battery vs. Source vs. Hybrid Comparison . . . . . . . . . . . . . . 39

3.1 Needed LDO Voltage Regulators . . . . . . . . . . . . . . . . . . . . 70

3.2 OMHT17 Specifications . . . . . . . . . . . . . . . . . . . . . . . . 71

3.3 Tamarisk UART commands of interest . . . . . . . . . . . . . . . . 85

4.1 Tamarisk Commands of Interest . . . . . . . . . . . . . . . . . . . . 110

4.2 Response to Commands of Interest . . . . . . . . . . . . . . . . . . 111

5.1 Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

xiii

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 3

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 is 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. Collaboratively ourgroup will pool together our knowledge which has been attained throughout thecourse of our education. Each member has a particular speciality which will needto be utilized in order to accomplish the completion of a full design and man-ufacture. Electrical engineers will gather their hardware expertise using analogand digital circuit expertise to create an interface which the computer engineeringcounterparts will be able to implement using their software knowledge. Program-ming controllers and creating interfaces alike which will compliment the hardwareare necessary to fulfill the requirements 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 would introduce our group to the concept andpotentially help with employment in this field. Also, as more and more data istransmitted using optical frequencies rather than lower bandwidth frequencies,becoming familiar with detecting light and processing the signal into useful infor-mation will have many benefits in the future.

During this project we plan to fabricate a printed circuit board (PCB) by becomingfamiliar with a circuit board design program and laying out the physical compo-nents necessary to accomplish the task necessary. Another goal of the group isto interface processors with one another to establish communication between twodifferent systems. Also we would like to gain an understanding of and the abilityto implement data transmission formats like serial peripheral interface (SPI) andinteger-integrated circuit (I2C). The group will learn to implement noise filter-ing and ensure correct circuit protection is in place to protect vital componentsfrom surges. We will fabricate 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. Thiswill also ensure the device will work continuously for hours without heating uppast tolerable temperature ranges.

5

Section 1. Project Description 6

On the software side our goals are 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 is a priority. As an optional goal, we’dlike to establish two way communication with the camera which will allow theuser to point the camera in any desired direction. We will need to apply flatfield correction (FFC) or non-uniformity correction (NUC) from the program tothe camera intuitively. One of our goals is 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 is to make a functional product with failsafes built in so thatour prototype could actually be used as a persistent surveillance device whichwould aid in providing a complete security solution in a variety of situations. Wewant the product to be fairly robust, with the ablility to withstand various weatherconditions. We also want to utilize intuitive software and standard protocols whichcould be implemented into a variety of security systems.

1.2 Project Requirements and Specifications

1.2.1 Performance

The panoramic system will use non-intrusive long wavelength infrared (LWIR)thermal imaging to create a panoramic representation of the surrounding environ-ment. The project will require several components. In order to rotate the Tamarisk320, a stepper motor with at least 10 Oz-in holding torque will be needed to sup-port the camera and some light peripherals and matching dimensions dependingon which FOV Tamarisk model is chosen for the project. The Tamarisk 320 ther-mal camera will be used since it is the smallest of its class and offers a 320x240resolution with an integrated shutter for flat-field correction. Different models ofthe camera are offered with different field of view (FOV) angles including: 40, 27,15, and 9 degree differences. Current panoramic solutions are all above $5,000.We plan on outputting a high resolution thermal imaging device.

1.2.2 Capability

The system will be capable of rotating 360 degrees along the horizon, capturingimages and stitching all of the frames together into a panoramic. A control modulewill be required for the stepper motor to assure it can be moved to any locationat a fast rate. An analog to digital converter will also be used which will feed indigital data to the control unit of the project. An FPGA that can take 320 x 240x 16 bits of data and stitch a mosaic using the image information will be requiredas well as spatial location from the motor controller. To stitch together the image


a directional component to the camera needs to be implemented to the design.This will ping a directional timestamp alongside the frame. This will allow foran accurate de-warping program. Doing this de-warping in real time at a cheapcost is essential. Simulation of the ray traces in Zemax will assist in creatingan optimized algorithm for the system. This will help in reducing the requiredcalculations. The key specification for our design process is cost.

1.2.3 Operational Use

The purpose of this panoramic device is to provide surveillance capabilities tohigh value targets in situations with poor lighting situations. Creating a systemat a lower price point than current systems offered will make this a desirableand successful project in the marketplace. A 360 degree panoramic with a highresolution and fast refresh rate will help in a variety of solutions. Most notably,this kind of product would be of high value in persistent surveillance situations.The system will be functional in both daytime and night time. The technologyboasts superior surveillance capabilities at night over non-LWIR solutions.

1.2.4 Relevant Software or Hardware Specifications

Initial discussions with the sponsor of the project have illuminated the most im-portant aspects to emphasize when designing this project. In order from most toleast important, these aspects are

• Price

• Speed

• Quality of image

• Ease of use for the end user

The proof of concept will show a fast and cheap way of producing high qualityinfrared panoramas. Additionally, this system will show exactly how much com-putational power is required to produce an equivalent solution. This will allow foran optimized budget FPGA to be manufactured and packaged with the existingsoftware suite. Providing a solution at a price point fit for the market is one ofthe goals of producing 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 signal


out over serial audio visual (A/V), high definition multimedia interface (HDMI),or digital video interface (DVI) for a direct plug and play experience for end usersis an important convenience factor to the success of the project. Additionally,output over Ethernet for IP access or direct line into a computer is an importantdesign consideration to integrate this imaging capability with existing securitysystems.

Research

Before rushing to build the project, we must 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 will explore all of the elements that will go intocreating a cost effective panoramic infrared camera. The major research elementsfor the project include the following and their expanding subsections:

• Existing Panoramic Solutions (2.1)

• Hardware (2.2)

• Communication (2.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 is important to con-sider alternatives which may already have solved the problem we are going after.If a product already on the market meets the need we are trying to meet, it maybe possible to take design elements from this products and improve upon them.Examining similar systems can show us where these products fell short, or whatconsiderations we aren’t currently aware of.

The following systems will be explored for potential design aspects and under-standing that may be applied to the project:

• Smartphones (2.1.1)9

Section 2. Research 10

• 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 methodswill be 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. Stitchingthe image together takes time also. The processor is not capable of real-timestitching. Typically, this solution only does a single frame instead of a persistentsurveillance solution. Most cell phones on the market are not weather resistant,which poses a problem in the environments our project is being built for. If thephone was outdoors and subjected to too much water exposure the device wouldbreak. Almost all cell phones on the market utilize visual cameras. This differsfundamentally from the proposed 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 asolution which is cost effective the solution cannot 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 will be to optimize the rotational refresh rate of the camera. The fisheye


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


lens solution will not be considered any longer due to the higher capital cost as-sociated with the technology. Our product will be tailored to implement a similarfunctionality to 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 are done for power supply solutions. All of the aspectsare considered of each element and various other components will be taken intoaccount to create a viable solution. Comparisons of each of the various solutionswill be at the end of their respective sections.

2.2.1 Infrared Detector

The focus of this product revolves 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 is 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 a 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. Therelenses 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 thedepth. The additional functionality provided by the feature board adds somedifferent protocols to work with. On top of the interface formats provided by thebase board USB 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 theinternals. The third configuration does not differ from the second configurationin any other way. The Tamarisk can apply different image enhancements to theoutput video, figure 2.10. There is an AGC which adjust the lowest temperatureseen to the lowest greyscale color and the highest temperature seen the the highestgreyscale color to increase contrast. The are two other image enhancement modes.ICE low 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 it iscompetitively priced. This solution is only a focal plane though, figure 2.11. Thebenefit of working with the raw focal plane is being 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. TheDRS Tamarisk is a modular solution. The lens on the Tamarisk is interchangeablewith a variety of other solutions. All of the lenses have been calibrated. TheTamarisk has an optional feature board. The data can be taken out of the moduledigitally from the base configuration or a video signal can be extracted from theoptional feature board. However, the connection type used is not common andtherefore engineering a connector to interface with the camera is required. TheFLIR A35 offers its own benefits. The camera has a simple connection type,an Ethernet port. This can supply power and communicate with the device. Thecamera can output data in a variety of formats which will be useful in supplying anoptimal data format for our design process. However, the fixed lens configurationis problematic for our specific solution. The selected FOV needs to line up nicelywith the rotation of the motor, most stepper motors rotate in 1.8 incrementswhile servo motors typically cannot rotate in continuous 360 loops. The FOVshould ideally fit into a single revolution.

Our selection of camera based on research is the DRS Tamarisk. The Tamariskis a packaged and functional detector. This device is ideal because the solution ismodular. Many calibrated FOVs can be selected and configured as desired. Theability to with or without the feature board is important. This way the device canbe configured as desired. DRS loan out Tamarisk cameras free of charge for collegestudents working on their senior design project. This would completely eliminatethe need to purchase an expensive IR camera. For these reasons the Tamarisk byDRS is the most optimal solution.

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 will have to be capable of stitching together 40photos of resolution 320x240 at a FOV of 9 degrees in a matter of a second or two,for a total 360 degree picture. Assuming 2 bytes are used to store information foreach pixel, this comes out to 6,144,000 B or 6.144 MB of data to be processed per2 seconds.

This calculation is what the processing requirement for the FPGA is based around.The RAM needed to handle the entire panoramic picture is larger than whatmost low end FPGAs offer in block RAM, so external RAM must be added toaccommodate for the system[4]. In recent years, FPGAs have become widely usedin image processing and are capable of handling data streams at a much higherrate than the one needed by the Tamarisk camera. Therefore even an FPGA witha modest amount of logic cells and processing power will be sufficient to completethe task of stitching together the infrared images.


The two main manufacturers considered, Xilinx and Altera, both offer a rangeof FPGAs which could suit the needs of the project. Xilinx boards support theXilinx SDK, the tool for developing for the board. The goal is to pick the onewhich has the minimum cost but still manage easily the stitching and readyingof the panoramic images. Familiarity was considered to be low on the list ofpriorities, as the lead for the programming of the FPGA in the group has a baseknowledge of Verilog and FPGAs in general but not of one specific company orproduct. Several of 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 is not needed for our purposes, so theseFPGAs were not considered. Because of the priority on minimizing cost, the LXplatform is of interest to the project. The technology is 45 nm, not the greatestavailable. A part on the upper end of this family, the XC6SLX100 has 4,824 Kbof block RAM and about 100,000 logic cells. The amount of block RAM in thisinstance does not appear to be high enough to store even one frame of the imagesbeing fed in. This would be a logistical issue, solvable through the addition ofRAM to the FPGA. Even though these FPGAs have the lowest speed out of thosebeing considered, the amount of data that needs to be processed is not high enoughto 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 reduce the logistical problem of feeding photo data in from several differentsources. There are 215,000 logic cells on this FPGA, which is much higher than thepreviously considered Spartan-6 FPGA. This FPGA would be much more powerfulthan necessary for the task at hand, but might be necessary when considering theamount 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 thatcomes with this FPGA is much higher than the amount that comes with the Artix


board. There are more DSP slices and logic cells as well. Most likely this will endup 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 are 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 range 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 cells andRAM capabilities would be adequate. See Figure 2.12 on page 21 for a detailedlayout of the board.

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


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 will be added no matter which FPGA is used, the amount of block RAMis not the most important feature of the board we choose. As long as the FPGAhas 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.

2.2.2.6 Comparison of FPGAs

The analysis of computational requirements for the assembly of a total panoramicpicture has led the group to conclude that the lowest-end FPGA will be adequateto complete the tasks we need it to. Cost is one of the top priorities in developmentof this project, so we want to buy the most cost-effective FPGA possible. Theresolution being handled is relatively low for a device designed for use in HD imageapplications. Therefore high cost FPGAs with more DSP slices, logic cells, andRAM can be disregarded. The minimum amount of RAM needed in the FPGAshould be enough to hold one frame. This is a conservative amount of memorywhich is met by most of the FPGAs in the Altera V GZ family and the XilinxArtix-7 family. This narrows down the choice of FPGA to a handful.

Both Xilinx and Altera offer SoCs. An SoC seems to be the most time andcost effective way to bring all of the components we need in 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 will have to be done intwo different programming languages, as the ARM processor will run C and theFPGA will run Verilog. This should not present any logistical challenge, as groupmembers have experience in both languages, and Verilog can call routines fromC fairly easily. Given the previous experience we have with Xilinx products, aXilinx board seems to be the logical choice for development and the final product.Xilinx products also offer development tools and support which will make thedevelopment of 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-7seems 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 is 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. It might also become needed for several full pictures to be stored at once.

The first decision which must be made regarding the memory devices we wantto use is whether to look for a device which utilizes a ball grid array (BGA)or one which utilizes a pin grid array (PGA). There are some advantages anddisadvantages to each which must be explored.

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 doesnot 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 the


pins 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 whichis printing our PCB. Since we already planned to export the printing of the boardto a company with more capability than the UCF lab, this should not prove to bemuch 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 have selected is able to utilize either of these, so we researched whateach has 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 havechosen 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 can be minimal. We want tomake sure we have enough to work with, but not pay for an amount that we won’tuse. The minimum amount we found widely available is 1 GB, which will bemore than enough to accomplish the tasks we need it to. The other considerationwhich needs to be given is to the amount of input pins the component accepts.The Tamarisk camera outputs 14 data bits at time, so we will need the ability toaccept 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 are 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 offers a solid solution forour purposes. It is immediately available from several different vendors. Digikey,the vendor we are using for several other components of our system sells it fromtheir website. It can take 16 bits of input. The one design hurdle created by usingDDR3 is the limited options we have in the way of package. This package is 13x9,for a total of 96 pins. While this does present more complexity during design, 96pins seem to be the most common amount for DDR3 RAM, and the benefits ofDDR3 outweigh the added time we must take to assign

2.2.4 Motor

The panoramic aspect of this project would not be possible without a rotatingapparatus for the camera. With this in mind, there are several viable solutionsthat can 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 which


required gratuitous amounts of power. More than a normal controller could outputon a pin. The main components of a motor which will be considered are:

• Mechanical Motor

• Motor Driver

• Driver Controller

With these essential components in mind, we will explore the different meritsbetween Servo Motors, Stepper Motors, Encoders, and Motor Drivers. Inaddition to exploring the different motor and driver solutions, comparisons oftraits and pricing are also included in this section.

2.2.4.1 Servo Motors

Servo motors are considered a trickier approach to this project. Since the servomotor utilizes continuous motion instead of “ticking” for each movement, it canprove a sizable problem for the rotation mechanics of the project. Although themotor can be programmed to rotate in “ticks” just like a stepper motor, there is arepeatable tolerance between each programmed “tick” that can slightly offset thepictures being taken. The most common tolerance seen is approximately 0.03.This is the degree tolerance of most of the servo motors. Since the standardachievable resolution for the servo is 0.45, there will be possible 0.03 x 4 =0.12

offset just for a 1.8 rotation. Since the camera has a 9 FOV, there is a range of0.03-1 variance with each “tick” of the servo motor. This can create a problemsince the number isn’t consistent compared to the stepper motor. An upside tothe use of servo motors is that the controller is built in so no extra peripheralsneed to be used in order to control it.

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


Table 2.1 and Table 2.2 depicts how similar each product is to each other minus theprice. Each come from the same line of product but there are notable differencesin price and functionality between them.

The first two models are more viable due to their specs vs the last one which ismore expensive and can be considered overkill for what is needed for 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 motor wasnot a problem. Depending on the material we pick for the casing, and how muchof the product needs to be housed, we didn’t want to struggle with putting sizableweight so a safe margin of 60 oz-in was chosen. Another factor that needed to beconsidered was that since the stepper motor rotates in “ticks” from the impulses,we needed to make sure that each “tick” would easily fit with our rotation pattern.The industry standard for stepper motors seems to be 1.8. With our camera beinga 9 FOV, this will allow for an even number of 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 is to each other minus the price. TheOMHT17-075 doubles the amount of leads compared to the other which we canbe reflected in its price. As we can see Table 2.4, not much changes between thetwo different models minus the number of leads.


2.2.4.3 Stepper Motor Vs. Servo Motor

In regards to the panoramic thermal camera, a lot of debate has gone into whetheror not it a step or servo motor was needed. The pros and cons of the stepper andservo motor merit a carefully measured decision between both, factoring in speed,power, strength, and precision. The camera would be rotating and speed was abig factor in the design of the project. With this in mind, the servo motor wouldbe the 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 requires a constant current to be flowingin order to perform which can be a drain on the power supply[7]. In addition tothe constant flow of current, this will generate a lot of heat in the system whichmay need to be compensated with a heat sink or design change in order to reduceheat buildup. Consequently, this will lead to added cost to the project, whichcontradicts 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 is also an important factor between the different motors. The step motorhas a high pole count in its design which allows it to have a higher torque outputat RPM’s lower than 2000. Conversely the servo motor has a better torque outputwith RPM’s greater than 2000. With these specifications in mind, the Tamariskcamera is extremely small and lightweight, alleviating much of the torque outputto just the casing and holding mechanism. Precision holds a huge precedent withthe design of this project. Step motors have a large number of poles so thatthey may move with precision vs the servo motor which has only a few poles andrequires an encoder to be accurate. With a constant flow of current in the stepmotor, impulses to the step motor can be controlled such that it will “tick” insmall increments so that data can be gathered. Given that the Tamarisk cameramay only take data once every 10 ms, an impulse can be programmed for each“tick” that will allow the camera to take its picture with enough time to resetbefore the next “tick”. Servo motors have a much more difficult time doing sosince they cannot “tick” as precisely compared to the step motor. If the camerais rotating in a constant motion, this will inexplicably cause pixels to be lost sincethere will 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, held


against a variety of characteristics. This table makes it easy to see that the steppermotor is 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 will have to be made in the form of a stronger power supply or aheat sink which will add to the cost. However, with careful browsing of product,we can mitigate the added cost significantly.

2.2.4.4 Encoders

A core design aspect of this project is that there needs to be communicationbetween the rotating camera and the software using it. Not referring necessarilyto the pictures being stitched together, but it’s essential for the software to knowthe position of the camera and how fast it’s moving so that it may coincide with theFOV and picture rate of the camera. For the case of this project, an incrementalrotary encoder will probably work best although there are many different waysit can be accomplished as well. For the incremental rotary encoder, utilizing itsequally spaced pulses when it rotates will allow us to easily coordinate it with therest of the components of the project.

A design flaw we must consider while choosing encoders is that incremental rotaryencoders have accuracy problems which can be a huge detriment for our project.Since the camera is so precise with its “tick” movement provided by the steppermotor, accuracy in movement must be extremely high, with little to no variancebetween any impulse movements. Due to the incremental encoders design, theencoder loses its position information when there is a loss in power or any kindof interference. However, this can be mitigated as certain models of incrementalencoders contain index channels that will keep the position of the encoder loggedin case any kind of power loss or interference occurs. A specific product we wereinterested in was just a general rotary encoder that was small enough to fit insideour overall product. A product we came across was the E6A2-C which is a costeffective encoder that we would be able to use since its external diameter is only 25mm. It also requires very little power from an energy source, only 5 volts comparedother encoders that we have looked at. Based on the average dimensions of theencoder, it will easily fit into our project with its compact design. Coupled witha cost effective design, it will be a good fit for the overall theme of our project inthat we are building a cost effective 360 panoramic camera.

2.2.4.5 Motor Driver

Having a motor is essential to the product but another component is needed toregulate the motor[8]. Having all the power and torque in the world doesn’t meananything if we can’t regulate the motor to do what we want. So in this case, wemust regulate the motor movement with impulses since it will most likely be astepper motor. This can be done conventionally by building a circuit that willsend impulses but it is much simpler to just have a driver for the motor since


most of the design aspects will come from interfacing the camera to the hardwareand software implementation. By utilizing this driver, we can be assured that themotor will step at the rate we need it to and worry about just the camera designwith its software counterparts.

For this project, we have selected the driver STR-2 to handle the necessary im-pulse and regulation needs. It has the capability to customize step and directioninputs as well as clockwise pulse and counterclockwise pulse. With this kind ofcustomization, we can even add more features since the rotation will be moreversatile and we can transform the project from just a simple panoramic picturebeing able to focus different areas and setting patterns. The driver is also rela-tively cheap, barring a price tag of $99.00 for one unit which can definitely be ajustifiable purchase since this is one of the major components that will be usedfor the project and adds a lot of potential functionality to the project. Since thisproject is going to be entered in the DRS competition as well, its price can almostbe negligible because of its versatility to the project.

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

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

Figures 2.15a and 2.15b illustrate the product picture and schematic. Its designand dimensions of the driver make it ideal for this project. The only problembecomes regulating the start of the impulses from the driver in conjunction withthe software/camera implementation. However, if we add timers or triggers itshouldn’t 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 is overall muchcheaper than the average servo with attached controller and encoder.


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 can stream Wi-Fion an integrated circuit[9].

2.2.5.1 Embedded Wi-Fi Module

The most obvious solution is to implement an embedded module that can transmitWi-Fi. The module is soldered onto a PCB and can be wired to transmit fromthe Linux server we are installing on the chip. From looking at pricing, embeddedmodules tend to cost more than USB solutions.

2.2.5.2 USB Wi-Fi Dongle

Wi-Fi dongles offer us some simplification to the development of the project. Thereare several USB wi-fi dongles on the market which completely take care of all ofthe interfacing necessary to transmit through Wi-Fi. The only setup we will needto do if we use this solution is to make sure the USB device can run on Linuxand has the necessary drivers set up. Given the complexity of some of the othersystems being used, we decided this would be the solution for our purposes.

D-Link DWA-121 Wireless N 150 Pico USB Adapter The D-Link Adaptersuits our purposes perfectly. We would like to have the smallest package possibleto make the system lightweight and easy to balance. It is capable of speeds upto 150 MB/s, far more than is needed for our purposes. Also important is thecost. At $15.00 it is very affordable. If it needs to be replaced for any reason itwill not be at a huge cost. This adapter is also compatible with Linux which isan important consideration. It boasts connectivity over a farther distance as well,which is important for the end-user.


2.3 Communication

Establishing reliable communication with all of the various elements of the pro-posed product is challenging. There are a few obstacles which need to be overcome.Typically, connecting all of the peripherals to the core computational unit wouldbe simple. Connecting them with wires would be sufficient with a few resistors andmaybe some op-amps to control the power delivered to the components. However,the nature of the rotational platform causes issues when feeding wires from otheritems out of the rotational plane. Research on how to realistically interface allof the various components must be conducted to ensure reliability. The easiestapproach is to break down communication into 2 different categories and thencoordinate them together:

• Network Communication (2.3.1)

• Motor Communication (2.3.2)

While looking at these different approaches, we must take into consideration fac-tors such as:

• Speed

• Cost

• Accessibility

• Housing considerations

• Ease of implementation

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

2.3.1 Network Communication

The method by which the system transmits the output to whatever system theend-user is viewing it on needs to be considered. With the factors mentioned inSection 2.3 in mind, considerable exploration will go into the following networkcommunication methods that will 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 will be comparedand contrasted 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 is to use a slip ring, a device which will allowa system to rotate freely of wires feeding input or output. This solution would begreat for a project where budget is not one of the main considerations, because theyare quite expensive to procure. Using our given project specifications, a modestamount of speed can be sacrificed in order to provide a cost effective solution.

2.3.1.2 Wi-Fi

Wi-Fi will allow data off the rotating platform using the IP protocol. If the datais streamed to a set website, any device which is connected to the internet will becapable of looking at the streaming panoramic pictures in real time. If this optionis selected, a server will need to be embedded in the PCB so that the data canbe hosted directly from the system. This will also mean data transmission willhave to be structured so that it can be transmitted using the IP protocol. Thiswill add some computation to the back end, requiring more resources in orderto live stream. The best part of this implementation is that Wi-Fi will offer themaximum accessibility to the end-user.

2.3.1.3 Radio

Similar transmission can 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 will take some extra componentsto modulate the signal in such a way that it is viewable. It would also not be asaccessible, because setting up a receiver just for the system takes extra work, whencompared to using already implemented personal computers or mobile 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 is 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 simplifies the decision of which option toimplement. Referring to Table 2.7, it is clear that a wired Ethernet connectionwould not be affordable and justifiable to our sponsor. This narrows our decisiondown to the wireless solutions. Using a cellular network would be ideal in veryspecific circumstances, but given the wide availability of internet connectivity ina modern environment, it is 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 will be ableto view output from the camera. It can be implemented easily using an embeddedserver. This seems to be the best way to transmit output.

2.3.2 Motor Communication

Establishing communication with the motor is another consideration. Power needsto be supplied to the motor and the motor needs to be connected to a pro-grammable unit which is synced with the camera data. Timing the steps of themotor to capture frames during the pauses then issuing step commands to moveagain so the next frame can be captured. With the factors mentioned in Section 2.3in mind, the varied approaches of Inverted Motor Communication, Optical Inter-face, Slip-Ring, Radio/Microwave Frequency, and Autonomous solutions needto be explored and analyzed.

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

2.3.2.1 Inverted Motor Communication

The first consideration is to have the motor inverted. The side of the unit whichrequires power is 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 solve


communication. The speed of delivering signals to the motor will 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 is easy to implement but will have worse reliability and controllabilityfrom the additional mass.

2.3.2.2 Optical Interface

This solution for communicating with the motor involves 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 will be oriented so theshaft rotates the platform and the base stays stationary. Commands from theFPGA will be issued to the LEDs, the LEDs will send a signal to a light sensor onthe motor side. The received instructions will be decoded on another processingunit and then commands will be issued to the driver and relayed to the motor.The benefit of this system is speed. Light is fast and with the right LED anddriver the response will be very good. The cost of this solution is reasonable. Acheap microcontroller can be used to power the secondary system for the motor.The LEDs which will be on the underside of the rotating platform are reasonablycheap. The solution if implemented correctly should be reliable. This solutioncomparatively speaking is difficult to implement. There are more componentsto implement than the other solutions leaving more room for troubleshooting.A similar solution regarding having LEDs hooked up to an Arduino could beimplemented on any microcontroller. Figure 2.16 illustrates what the base of theplatform 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 is another possibility. Themotor only has a few wires which need to be fed through to the FPGA. The driverin this solution would be located on the motor side of the system. This solutionis fast. Based on the number of wires required it would not be too expensiveto feed them through with a slip ring. Slip rings have a low fail rate. Wiredsolutions are more reliable than a wireless one in most cases. Therefore, thissystem would be reliable and easy to control. However, implementing the slip ringabout the mechanical rotation and the overall cost will be difficult to keep thissolution under consideration. Unfortunately, nobody in our group has advancedknowledge in mechanical systems which puts us at a disadvantage. This will makethe solution complex for this group. For clarification on the type of slip ring thatis 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 is another option. We could use the existing Wi-Fi moduleto communicate with the base. This would require a complicated base circuitcapable of handling a Wi-Fi stack. Another option would entail using a rawradio/microwave frequency to control the system. No Wi-Fi stack or two waycommunication would be needed if we were to use this, just a system which re-acts to a specific frequency. There are a lot of existing signals propagating inthe atmosphere. Finding an unused frequency is area specific and therefore lim-iting. A very high frequency line of sight microwave signal could be used withinsulation. The insulation would ensure no interference would occur. However,higher frequencies mean more power consumption from switching. This solutionwould be fast and have a mid-range cost solution. The system would be reliableas long as interference was appropriately filtered out. The communication wouldbe able to supply controllability. There are plenty of hobbyist modules available


which could perform this task. Using some prepackaged solution as a referencedesign the system shouldn’t be too difficult to implement but there will be a lotof components to this solution.

2.3.2.5 Autonomous

Another option which has not be discussed is 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 microcontroller.This solution would mean there is no communication between the FPGA and mo-tor. The motor will operate by itself and could only be turned on or off in practicalusage. This is a fast, cheap, reliable solution, however there is no controllabilityfrom the users end to communicate with the device. This solution would not bedifficult to implement, however, the solution is 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 have 3 or less merits factored into the traits that we arelooking for in regards to motor communication. All 3 of them offer speed whichis a must since the timings we will be dealing with are quite strict. Since costis one of the most important aspects to this project, the inverted motor andautonomous methods are very cost effective and are fairly easy to implement,but the accessibility and housing for them are quite costly and complex. Theradio/microwave method seems to be the worst of the bunch, being costly anddifficult to implement. Ruling out the other 3 at this point, we can see that theoptical interface and slip-ring solutions are the most viable. The optical interfaceoffers speed, cost effectiveness, accessibility, housing construction, but lacks inthe ease of implementation. The ease of implementation will definitely be anoffset factor for picking this solution. The slip-ring solution displays an easy wayto solve the motor communication problem. It offers speed, accessibility, housingconstruction, and can be easy to implement. However, it contradicts a main designaspect for the project in that it is expensive to implement. All in all, it boils downbetween the optical interface and slip-ring solutions. The smart way to go about


this is to take on the challenge of implementing the optical interface solution. Ifwe cannot properly implement it, then we might have to take a hit to the budgetand go with the slip-ring route. The motor communication is one of the mostimportant components of the system, and having it properly working and takinga hit to the budget is better than having a sub-par motor communication systemand saving a few bucks.

2.4 Power

Power is one of the most important systems for this project. Without the propercontrol and maintenance of the system’s energy resource, the system will not beable to run consistently and efficiently. In order to remedy this, different consider-ations must be taken in regards to how the power supply will be treated while theproject is running. This section will cover the different options pertaining to theprojects power storage, regulation, and delivery to the system. The componentswhich require power delivered to them are:

• FPGA

• Motor Driver

• Motor Controller

• Camera Module

• LED Ring

These are the main subsystems which require power delivered to them. The otherperipherals can be powered from the embedded controllers. There are major designaspects that need to be considered in regards to power that are dealt with in thissection 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 must consider is the kind of power supply that the projectwill use. With such a large variety of ways to power up the project, carefulconsiderations must be made so that the optimal power supply is used[10]. Inthe case for this project, we will be powering the driver instead of the motor itselfbecause the driver will take over powering the motor instead of it being user based.

In regards to a battery power source, standard 9V batteries won’t have enoughpower to fuel any kind of motor/driver. This means that a big lead acid of NiMHbattery pack must be used so that the project has enough power to consistently runfor long periods of time without being changed or maintained. With this in mind,we will need a split power supply source where different supplies are used for eachcomponent. The control unit will most likely be an FPGA board that will be usinga lot of computations so it will probably be powered by USB or a powerful batterylike the motor/driver. The reason for the split power supply is that when you runtwo high powered devices like a motor/driver and FPGA, problems can happensimply because each device isn’t getting enough power to do their respective jobs.The pros of having a battery powered device is that the project can be set upanywhere, eliminating the need for outlets or power sources. If the project setupis to be static/stationary, this would be the ideal setup since nothing needs to bemaintained or moved. The cons of having a battery powered device is that thebatteries need to be changed out periodically, depending on how often the deviceis being used. Based on the environment, the hassle of changing the batteries inthe device can range from a 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 projectin that it’s extremely beneficial to use an outlet source when the project isn’tbeing moved all the time and that no batteries need to be changed or maintained.Additionally, the cost of having an outlet source to power the project may bemuch cheaper since batteries do not need to be changed. However, a case can bemade for having rechargeable batteries that give the project hybrid pros and consin that it contains the mobility of having battery sources to power it but is costeffective in keeping 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 equal withits pros and cons in that it can power the device and has mobility. If you look at


the outlet approach, the pros actually outweigh the cons three to one in the power,maintenance, and cost department. Looking at the hybrid approach, it has thesame statistical value of having a three to one pro to con ratio but exchanges themaintenance trait for a mobility trait. Analyzing the three different approacheswe can rationalize that the outlet or hybrid approach will be best for the projectand can be differentiated by the fact if the project will be mobile or not.

Due to the nature of the project, constraints are in place that will limit a batterypowering the motor and driver at the same time. It is most efficient to use a powersupply unit that is connected to an outlet simply because the voltage output ofmost batteries degrades with use which can create a lot of problems if a freshbattery isn’t in the project or it has been in use for too long. This cannot bethe case for the Tamarisk camera or Zynq board. Since the rotational platformposition will always be dynamic with respect to position, it cannot be plugged intoan outlet source without utilizing a costly solution like a slip-ring. Therefore, wemust use a battery solution that will provide enough steady power to all of thedifferent components on the rotational platform. Since there are multiple powerrequirements to the different parts of the rotational platform, voltage regulatorswill need to be utilized in order to avoid having multiple batteries with differentpower values for the purpose of powering everything.

Another aspect we must consider is that putting a battery on the rotational plat-form can affect performance of the motor. Since the platform will be spinning,weight discrepancies can cause instability in the movement of the Tamarisk cam-era. In order to remedy this, counterweights will have to be carefully placed inorder to keep the system stable. While the balance issue has been addressed, wemust ensure that the overall weight of the platform can still be supported by thestepper motor.

2.4.2 Induction

Induction is a somewhat complicated aspect of the project. We must incorporatethe coils and circuit necessary to charge both the camera and FPGA. However,depending on how much power the FPGA will really be consuming since it isperforming a lot of computation, will determine how much power we really needto charge both components. As of now, it is speculated that 10 watts of powershould be enough to charge both components. However, designing an efficientinductive charging system is difficult to do. Ideally a coupling factor of 99% can beachieved[11]. Transformers are able to accomplish this high efficiency. However,our system will not have one inductor fully encased in another. Because therewill be distance between the two systems, naturally there will be some loss. Thehighest efficiency we can hope for in this systems is around 90%. More conservativeestimates would bring power transfer around 70-80%. On the market right nowthere are many solutions to provide inductive power. However, most of thesesolutions are for teaching the concept, which includes basic tasks such as lightingup LEDs or charging a cell phone. For our project a higher power solution would


need to be designed. Most of the current solutions on the market only todaydeliver a maximum 5V 500mA. On top of the low power transfer the system isusually inefficient. With this in mind, sizable modification to their system mustbe made to meet the power requirements for our system. A proposed method ofpowering the system would be to put 2 inductive charging systems for the cameraand FPGA. This way, we take a current system and modify it to what we needwhile avoiding the messy and potentially problem ridden alternative of trying tomodify a current DIY project to meet our needs.

From research there are many considerations which need 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 need to be performed. Induction is a strong candidate for transferringpower to the rotational platform, however, the concerns about interference fromthe magnetic field generated by the induction and shielding the electronics toprevent undesired behavior is another design concern.

Should the inductive power transfer be done using AC then the material chosenfor the inductive coil will be a hollow copper pipe. Current under AC conditionstravels mostly around the outside of the wire. Making the cross section of the wiresolid would be heavier and not cost effective. For a DC application of inductivepower transfer the coils would utilize a solid wire. The key to making an efficientpower transfer between the two coils is to make a high coupling factor between thetwo respective coils. Another key factor is the Q value of the actual coils. Wrappingan inductive coils uniformly utilizing properties of solenoids to maximize the fluxgenerated by the coil is another important factor of induction which will affect theperformance of this system.

2.4.3 Solar

Due to the fact that we can expect this system to be used in an outdoor envi-ronment, it is worth noting the risks and benefits involved with harnessing solarpower. Potentially all of the subsystems could be run on solar power from twodifferent arrays of solar panels. The first array would be mounted on top of the ro-tational platform and would power the PCB, camera, and LED array. The secondarray would be below so that it could feed power to the motor.

Without using solar panels to power the subsystems, a power outlet will have tobe nearby in order to give power to everything. This would be unfortunate, as itwould limit the flexibility of the system. However, when using solar power we have


to consider if any given location could provide enough sunshine to be adequate.Also, the system could be used indoors, in which case this method of generatingpower could not be used at all. Keeping these two factors in mind, this benefitof solar power does not seem to be all-encompassing. If we cannot rely solely onsolar power in all situations, we will have to design and implement two differentways of supplying power.

Yet another consideration which gives us hesitation about using solar power is thecost of solar cells. Although the cost of this technology has decreased in recentyears, it is still quite costly when compared to inductive or battery power. As arough 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 have forthe amount of voltage and current needed for each component. When lookingat solar panel vendors online, we quickly found that solar panels are 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 costs $437.65. This is the cost of just one of the panels we need.

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

2.4.4 Storage

The project will employ 2 different methods of power storage that will maximizeits efficiency. The motor will be powered by the STR 2 Stepper Driver which isthen powered by the specialized power supply unit, OMPS300A48. This powersupply unit supplies enough voltage and amps to the OMHT17-075 Stepper Motorthat will optimize its revolutions per second.

With the motor having a specialized power supply unit, the Tamarisk and Zynqboard need to have power as well. With this strategy in mind, a rechargeablebattery will be powering up the Tamarisk and Zynq board so that no wires or slip-rings will be needed to connect the 2 components to the specialized power supplyunit. This battery can be charged continually using inductive power generatedbetween the base and rotational units, so that batteries will not have to be switchedout at any point until the battery cannot recharge itself anymore. This adds anadditional benefit in that no power is being sapped from the OMPS300A48 so thatit won’t lose efficiency when it comes to revolutions per second and overall torquepower.

2.4.5 Regulation

Having a specialized power supply unit means that power will 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, specialattention must be made to how quickly the power will be drawn out of the batteries.In order to remedy this, inductive charging will be employed so that we can have awireless charging apparatus in the project. This is to avoid using costly solutionslike a slip-ring apparatus. For more information on inductive charging, please referto Section 2.4.2. Testing must be conducted in order to determine the rate ofcharging coming in from the inductive process vs what is being used.

2.4.6 Delivery

In terms of delivery, the OMPS300A48 will supply power to the STR 2 Step-per Driver and OMHT17-075 Stepper Motor. The OMPS300A48 takes its powerfrom an AC input so the amount that it has is virtually unlimited for its scope.Power delivery to the Tamarisk camera and Zynq Board will come at a much morecomplicated method. The overall combined voltage for both of the componentsis equated to be approximately 5 volts and 2 amps which compiles to approxi-mately 10 watts of power total. Since batteries cannot output specifically 5 volts2 amps for our needs, voltage regulators will need to be added to the system sothat the right amount of power goes to each component. Specifically referring tothe Zynq board, it has many components that require smaller amounts of powerso voltage regulators will need to be carefully administered to the different partsof the board in order to ensure that it operates properly. Looking at Figure 2.18,we can see that the OMPS300A48 power supply unit draws power from an outletand transfers it to the STR 2 Driver and OMHT17-075 Stepper Motor. As forthe rotational platform, Figure 2.19 clarifies how power will be delivered to thetop platform. The power starts from the battery and passes through a number ofvoltage regulators which will allocate the appropriate power requirements to eachof the rotational platform components.

Figure 2.18: Motor Power Delivery Block Diagram

2.5 Mechanical System and Packaging

Having the components of the project means nothing if they aren’t placed properlyor protected. Since one of the biggest aspirations of the project was to place it


Figure 2.19: Rotational Platform Power Delivery Block Diagram

outdoors or in a public area, how each of the systems will be mounted and protectedmust be taken under heavy consideration. Outside factors such as weather andexternal interference will be 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 is to flesh out the logistics of wiring,placement, and protection for the overall project.

2.5.1 Housing

The intended environment in which the camera system will operate in is not strictlydefined. It could be used in a surveillance capacity in hot, dry climates or humid,cold climates, or anywhere in between. In order to make the system as stable aspossible in these situations, we must give consideration to weather-proofing thesystem’s housing. This includes 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 should be fast, easy, and


cost-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 will need to have a tight seal on the dome whichwill rest on the rotating platform. The dome will need to have a transparentlens in front of the camera so that water cannot get into the system at all. Thiswill require some calibration and mechanical fixing so that nothing can shift andinterfere with the camera’s view.

These two solutions working in conjunction should ensure that the system is en-tirely waterproof.

2.5.1.2 Temperature-Proofing

The system should be able to function both in hot or cold climates. Since we areencasing all of the moving parts, we do not need to worry about water condensingon the rotational joint and freezing. No water should be able to freeze in areaswhich would prohibit movement. This means that heat will be the main concernwith the system.

Because of budget and time constraints, cooling the system will not be emphasizedto as great of an extent. Cooling solutions involve the installation of either a fan,a heat sink, or a liquid cooling apparatus. These solutions range from expensiveto logistically complex. Instead, we will reflect as much heat off of the system aspossible using white paint on the housing. This will be much cheaper and easierto accomplish.

2.5.1.3 Wind-Proofing

The structure of the housing needs to be such that gusts of wind will not causethe system to topple over. In order to prevent this from happening, we simplyhave to construct the base of the rotating platform to be wide enough that it cannot 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 lead to complete destructionof all the electrical components. We will prevent this from happening two differentways. To keep lightning from striking the system, we will place an antenna next


to the camera which will be fixed to ground. This will prevent any electricaldisturbance. To prevent surges out of the power outlet, we will use a consumer-grade surge protector. These solutions are cheap and easy, and could preventmajor destruction of the system.

2.5.2 Camera Mount

Mounting the camera correctly is imperative to creating a controlled environmentfor the camera to operate. Without a good mounting solution, the focal pointwill not be calibrated correctly for adequate imagery to be constructed from thesystem.

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 willbe designed to grip the camera utilizing the area which existing camera mountingsystems utilize for the camera. A key consideration for the camera mount is tolimit the axial mobility of the camera to ensure the camera cannot shift off thereference rotational plane. The proposed system has 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 is important to retrieve good imagery from the system.

Configuring the focal point of the system is another important consideration of thecamera mount. The panoramic solution is utilizing the 35mm lens. Calculatingthe focal point of this system and configuring the camera to reside and rotateabout the focus to ensure detailed imagery from the device is an important designconsideration. To allow for a configurable camera mount a sliding mount is beingchosen. This will allow for minor adjustments to where the focal plane sits inregards to the rotational axis. This flexible design will also allow for the systemto be configured for different fields of view.

2.5.3 Motor Mount

Considerations for the motor mount is that the motor is to remain fixed aboutthe base. The base is to be static in regards to the reference plane. The referenceplane in this case will be a roof of some kind. Considerations for mounting theproject to a surface like a roof to get accurate imagery. The mount will 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 is taken from existing security surveillancesystems. Many panoramic systems exist in security systems today. Most panoramicsystems are based on a wide FOV lens capable of seeing a wide area. The realityof IR cameras is that they are much lower resolution than today’s visible cameras.


Getting decent panoramic imagery from a Fish eye type lens is difficult to achievedue to the enormous cost of high resolution infrared focal planes.

The motor, like some of the rotational systems which exist in the market today,will reside in a water-proof weather resistant enclosure along with the motor driverand various other power supply related elements. The motor chosen has mountingscrews on the front to be fastened in place. Other machining related applicationsutilize these screw brackets to fasten the motor to an enclosure. Preliminaryfindings indicate the easiest mounting option will be to fasten the motor to aplate which will then be mounted on the top of a box-like structure. The box-likestructure will house the rest of the electrical components assigned to the base.

2.5.4 Control Mount

The control mount will be how the FPGA PCB is mounted to the rotationalplatform. A camera mount system is already in place. The camera will be mountedabove the PCB. In order to compensate for the presence of the camera, somethrough holes will be put into place to allow for the camera to be mounted withoutinterference from the PCB. Using the existing through holes to act as support forthe camera platform they can also be utilized as anchors for the PCB. Fromexperience of taking various other electronics apart utilizing necessary supportinfrastructure for a convenient anchor point is a common practice in the consumerindustry. This optimized solution will reduce the parts involved in constructingthe product and therefore reduce the cost and labor associated with manufacturingthe solution.

On top of securing the controller, shielding the controller from interference isanother factor associated with the control mount. The magnetic field generatedfrom various other components could potentially interfere with the performance ofthe device. Therefore, appropriate shielding must be built into the control mount.A cost effective, light and functional solution to this design consideration is acopper plate. This copper plate will be fastened on the underside of the platform.This should supply adequate shielding from the potential EM interference at areasonable cost. Copper is frequently used to protect against EM interference aswell as other alternatives such as silver and gold. Keeping budget in mind, copperwould be the most economical solution when compared to gold or silver shieldingsolutions.

2.6 Software

There are a couple decisions which need to be made about the code and back-endwhich will support the system. Although much of the tasks which need to behandled by the processing unit are fairly straight forward such as the control of


the camera and motor, some key decisions are important to explore. There are 3main aspects that need 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 are printing will utilize an operating system in order to streamdata to the end-user device. This means we need to decide on the best optionfor an embedded media streaming server. Linux distributions offer a wide varietyof solutions 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 need to look atwhen examining these distributions are:

• 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 systemsare 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 will definitely be of use duringthe development of our project. It is based on Ubuntu and has GUI support. Thiswould come in handy for coding, but unfortunately the MicroZed board does notoffer GUI support. This solution does not seem right for the final product, as itis 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 is listed as one of the distributions of Linux directly sup-ported by the Xilinx Zynq-7000. This will offer a lightweight solution, and willnot 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 has to offer is irrelevant.Our goal is to pare down the functionality of the operating system we use tothe bare essentials. Because of this consideration, Ubuntu does not seem to offeranything of use that Arch Linux doesn’t.

Operating System Comparison From looking at the considerations above,the choice of operating system for this project seems clear. The MicroZed devel-opment board we are using will come with Xillinux, and will be the easiest wayto develop code for the project. This will be utilized throughout the developmentprocess. For the final product, we will run the server on Arch Linux ARM. Thiswill offer 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, it will be assumed that greyscale output isdesired. This will result in the added bonus of lower bandwidth needed to streamthe output, since less bits will be needed to represent each pixel of the picture. Theother added bonus of using grayscale output is that their will be less computationon the back end. If an RGB picture was desired the picture would have to mapeach greyscale value of each pixel to an RGB value before the panoramic picturecould be sent to the output. Without this mapping, output is able to be sent fromthe control unit faster.

It is our intent to stream in real time the pictures coming out from the SoC chip onthe camera mount. They will be streamed over wireless communication to a front-end device which will then display the completed picture on the screen. The picturewill then update as fast as the camera will allow. This time should be less than twoseconds. Also, the display should be capable of pushing any error messages whichneed human intervention to fix. Things like motor or camera malfunction shouldproduce output to the user letting them know which subsystem has encounteredan issue. This output will be in the form of a simple text string printed over thelast image successfully sent with details about what went wrong. Other systeminterruptions like necessary periodic camera calibration will not be sent to theend-user, because no intervention is required 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 want to make due with the most stripped down IDE possible, without givingup things that we need. Xilinx seems to be the best option for developing onthe Zynq board, because the Zynq board is produced by Xilinx. This leads 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 write for the Zynq board can be tested before it is implemented.This is integral to the development process. Like the ISE, there are some featuresof Vivado which the free version does not provide. These are features such aslogic and serial I/O analyzer, which would be nice to have and might expeditethe development process, but should not be integral to finishing the code for ourpurposes.

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 emerges 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.

Design

Now that enough research has been conducted in order to make educated decisionson the design aspects of the project, designing the entire project was broken downinto the following segments:

• Hardware (3.1)

• Software (3.2)

• Housing and Mounting (3.3)

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 overall hard-ware design. The Rotational Platform portion is color coded orange, Base Unitcorresponds to blue, the Rotational Platform matches with the green, and theMotion design aspect is found all throughout all 3 sections.

53

Section 3. Design 54

Figure 3.1: Hardware Design Flowchart

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 is thefoundation of the following components:

• 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)

We have the rotational platform made of printed plastic and dimensioned at 5.5”in diameter. A hole small enough will be drilled directly in the middle of theplatform so that the OMHT17-075 Stepper Motor may be installed, giving theplatform its rotational ability. For clarification of the components being placed onthe rotational platform, please refer to Figure 3.2.


Figure 3.2: Rotational Platform Dimensions

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.

The second configuration of the camera is unfavorable since it does not allow accessto the RAW information coming from the camera. The Base Configuration waschosen.

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].

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.


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

Figure 3.4: Tamarisk Pin Connections

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 are all used to control thecamera. Pins 16 and 14 are used for UART commands which can modify the waythe camera outputs and controls camera features such as AGC and ICE. Pins 26and 24 are used to determine the state of the shutter. The state of the shutter is


important because it will allow for a precise idea of when not to grab an imagesince the camera will be unavailable at that time. Pin 38 is 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 are all grounds, even pins 8 - 2 areVIN – 3 -5.5 V – and even pins 54 - 50 are used for VCC IO – 1.8V Power Supply.

Timing The timing on the Tamarisk camera is set by a fixed clock which oper-ates at 10 MHz. This will determine much of the timing for when data can be readto the control unit, and when the motor will rotate. Once the camera captures aframe, the data will 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 is convenient because the camera needs about5 ms for the capacitor to dissipate its energy before it can capture another frame,and 10 ms to capture the frame for a total of 15 ms minimum between framecaptures. This means the limiting factor on how fast a full panoramic picture canbe outputted is dependent on how fast the motor can move.

Most of the control of the system will be based around when the SoC receives afull frame. Once the input interface recognizes that a full frame has been received,the control will send out a signal to the motor control to rotate 9. The otherpossibility is that the camera will have to do a calibration. This means no datacan be outputted to the System on a Chip(SoC), and all movement must behalted. The time for the calibration to take place is 440 ms, but might have to beperformed several times to ensure proper calibration. The camera will send out asignal when this procedure is complete and the camera is available for use again.

3.1.1.2 Zynq

Pin Configuration The Zynq Z7010-CLG225 has 169 Pins which all need to beconnected to various components[13]. The camera requires 14 pins for data and8 for control. The LED’s require a control line. The RAM requires 47 pins to beconnected to the Zynq as shown in Figures 3.5 and 3.6.

Two buffers are needed for the production of a finalized single panoramic photo.These buffers will be DDR3 memory devices outside of the Zynq which will storeimages before and after processing[14]. The first buffer will hold incoming framestaken by the camera, taken as serial input by the SoC. For the sake of safety,and not losing frames, this buffer should be big enough to hold 3 frames. This is153,600 bytes or 153.6 KB. To play it safe, we will make this buffer 200 KB insize. The other buffer should be for holding the panoramic picture as it is beingstitched together. This will have to be the size of the final picture file, calculatedearlier as being 6.144 MB. This will be rounded up to be 6.5 MB of buffer for the


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

Figure 3.6: DDR3 Configuration as seen by the RAM


panoramic picture to be stored in. The SoC will need to handle incoming picturesin real time and decide when to take a frame out of the incoming buffer.

The camera output needs 26 pins to establish a connection and receive an imagebetween the SoC. This means the SoC will need to have this number of pinsreserved and configured for communication with the camera. The pins we need toutilize are outlined here

• 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 will be programmed to indicate input and output for debuggingpurposes. These LEDs will not be intended for use by the end-user, as it is hopedthat the camera mount will not need to be interacted with on a regular basis. TheTamarisk camera and the motor should both send error signals if something goeswrong with either of the systems. These signals should be recognized by the boardand sent to output in a legible form so that they can be fixed if intervention isneeded from the end-user. If no intervention is required, the error code does notneed to be seen by the end-user, so it will not be displayed.

MicroZed The MicroZed is a development board which will be used to proto-type/debug/ software. This board will also be used as our base model for the PCBthat will be designed[15].

The MicroZed is powered by the Zynq-7000 - 7Z010, which is the SoC which willbe 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 will be transmitted through a USB Wi-Fi interface. In order to do thiswe will have a USB port on the PCB which will interface with the Linux server onthe ARM processor. The USB will need a transceiver as well as the connection toconnect to the wi-fi dongle[9]. Once the connection is made the operating systemshould take care of all the handshakes necessary for wireless 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 will be the same[11]. The solenoids will have the same radiusto maximize efficiency. The coils will have the same number of loops (n). Thecoils must be mounted directly above one another. Any misalignment ensuring thecoils are mounted with the origin of each solenoid about the rotational axis wouldend up with inconsistent power transfer from base to platform. The coils will bemade out of the same material, copper. All of these factors will ensure a goodcoupling between the coils. Also, reducing the distance between the respectivecoils as much as possible will increase the coupling of the coils.

Winding the actual coil will be done manually. In order to ensure ideal quality (q)of the inductive winding there are several considerations. The coil must be wounduniformly the loops should be as parallel to the pairing loop. The spacing betweeneach loop should be uniform also. Wrapping the inductive coil will need to be 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 inductive powertransfer from one coil to the next will be more efficient. Therefore, there will beless heat generation by the system and less interference from other components.It is theoretically possible to get infinite quality. However, attaining a Q factor ofover 1000 is difficult. Given our space restraints a Q of 329 will be sufficient forthe power transfer.

3.1.1.5 Platform

The platform will hold many of the significant subsystems for this project. Onit will be mounted the Tamarisk camera, which feeds its data lines down to thePCB. The Zynq will also be located on this platform, as well as the several LEDsthat are being used to communicate down to the motor. The Linux server willbe embedded on the Zynq and interface with the ArtixTM-7 and the USB Wi-Fidongle. Apart from the motor, light sensor, and motor controller, all necessarycomponents of the system will be housed on the rotational platform. The specificson each of these systems are covered in their respective sections.

As a whole, we need to construct the platform so that it will not pose any issueswhen it is being rotated. If the board is not balanced with approximately equaldistributions in all directions, the stability of the system is affected. Mass will beadded to the rotational platform in the form of counterweights. This will removethe design concern for everything to be planned out before the PCB is printed. Asa preliminary design, we have constructed a SolidWorks drawing and rendering ofthe platform that will host all of the subsystems listed above. Figure 3.7 providesa visual detailing all 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 will define how it will output the panoramicview. The Tamarisk 320 model we are using contains a 9 Field of View(FOV)which will define how the camera will move in general. Simply put, the camera willtravel a full 360 while taking pictures every 9 for a total of 40 pictures. This willbe 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 creates its panoramic effect, please refer to Figure 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 willbe utilized. To ensure sufficient lighting is supplied to the base, an array of LEDswill be used to send the commands. The Zynq will be hardwired to the LEDarray and will instruct the LEDs to blink at a frequency of 38kHz. An outputpin from the Zynq shall handle the oscillation trigger. The LED ring is suppliedsufficient power from the Zynq to not need any additional power regulation.. TheLEDs in the circuit will be IR LEDs with wavelength of 940nm[16], a commonwavelength used in IR remotes. This will send light to a sensor connected to themotor controller, 3.1.3.7. Each LED consumes typically 20mA when powered onand takes 1.5V to turn on. The voltage output from the pins of the Zynq peak at3.35V which mean the LEDs should be put in series with a resistor to ensure theydo not burn out. The whole circuit consumes less current than the Zynq is ratedto output for each pin. The total current draw of the top part of the circuit is lessthan 53.7mA. The LEDs selected have an extremely wide 120 viewing angle toensure the light emitting from the diode triggers the sensor. Figures 3.9 and 3.10show the simulated 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, please refer to Fig-ures 3.11a and 3.11b. Upon inspection of the figures, we can see that the LEDwill fit nice and snug between the base unit and rotational 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 will act as the central hub where the project isstored. Specifications of the base unit is that it will be a 6”x6”x5” and madeof printed plastic. There will be 4 holes that are placed in conjunction with thedimensions of the FPGA board and ultimately the rotating platform and Tamariskcamera. There will also be a hole directly in the middle of the base unit so thatthe OMHT17-075 Stepper Motor may be placed underneath but still have therotating shaft above the base unit so it can maneuver the rotational platform. Forclarification on how these holes will be placed, please refer to Figure 3.12 whichcontains a SolidWorks drawing of the base unit with the holes placed in 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 can be protected from outside factors.With that being said, the STR 2 Driver and and OMPS300A48 Power SupplyUnit will be nested inside the base unit as well as any other wires we can fitwithout affecting overall performance. Though having the base unit to house theOMHT17-075 Stepper Motor, STR 2 Driver, and OMPS300A48 Power Supply,the compilation of 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. If yourefer to Figure 3.14, the schematics and layout for the OMPS300A48 are provided.Upon inspection of this schematic, we can see that the dimensions of it can alsofit 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 must be fitted on top of the rotational platform in order to power theZynq 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 require approximately 9 wattsof power or 10 watts to be on the safe side. Since the Zynq Board requires 5 volts,we can go with a 5 volt or higher battery with at least 2 aH power rating so thatwe get the required power.

In terms of product, we have chosen the Power-Sonic PS-628 battery. It is rated at6 volts and 2.9 aH making it more than qualified to power the rotational platformcomponents. A little bit of lee-way is added in our specs for power since batteriestend to degrade in voltage output when they are used for extended periods of time.

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

3.1.3.3 Voltage Regulators

Having the battery isn’t enough to power the components on top of the rotationalplatform. Yes, we have enough power to do so, but the power must be properlyallocated to the right areas in order for the project to work effectively. Regularvoltage regulators may not cut it in this case, since most voltage regulators requireat least 8 volts and cut down from there[17]. Since our battery is a 6 V, we canuse a low drop out(LDO) regulator that will regulate and drop output voltageseven in your input voltage is less than 7 V. Based solely on the Zynq schematicand data sheet, the board takes different voltages that range from 1-5 volts fordifferent operations on the board. This means that different voltage regulators willneed to be designed for the various portions of the Zynq board. For an example ofhow the voltage regulator works in general, please refer to Figure 3.15. Figure 3.15is a prime example of how a voltage regulator circuit works using a 7805 VoltageRegulator model.

Table 3.1 lists the different LDO voltage regulators that will be needed in order topower the Zynq board. Each model will be placed in a similar circuit resemblingFigure 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 actuallyweighs 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 will 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 has to move again, there are 8 ∗ 3.3 = 26.4Joules lost or.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 will allow us to program the OMHT17-075 StepperMotor to whatever incremental rates we need[8]. In this case, the motor has anangle 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 will have to send to theOMHT17-075 Stepper Motor in order to get a ”tick” for the motor to move in theexact placement of the Tamarisk 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 we will need for the project, youmust have logic inputs that will come from a programmable logic circuit(PLC) orjust a source of step signals.

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

Since cost effectiveness is 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. Forour source of step signals, we have opted to use programmable LEDs that will bewired to the input pins of the STR 2 Driver. The input/output pins are laid out assuch in Figure 3.20. Simply put, whenever the LED turns on, the same logic input


will be sent to the STR 2 Driver which will consequently power the OMHT17-075Stepper Motor. For clarification on how the wiring will occur between the STR 2Driver 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 3 willbe pressed downward. Figure 3.22 illustrates how the switches will be arranged inorder 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 is a phototransistor. The phototransistorwill sit below stationary as the ring of IR LEDs rotates. The phototransistorrequires 1mW/cm2 of light to trigger the transistor into the on position[19]. Thiswould be considered Vth or the threshold voltage of the transistor. Considering theLEDs chosen will be running at 20mA at 1.5V the output light from each assumingideal operation is 30mW of light. However, LEDs are typically only 80% effectiveat transforming power into light. This would mean a realistic output of 24mW oflight will be emitted from each LED. Assuming the light is uniformly distributedabout 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 of the phototransistor andthe LED featured in Figures 3.11b and 3.23b the following 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 will be hitting 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 will be able totrigger 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 63. Figures 3.23a and 3.23b provide an in-depth visualization on the layoutand dimensions of the phototransistors we will be using.

(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 will be identical to the inductive coil on the top of thesystem. Although inductive coupling is more efficient at distance using AC, DCcoupling is efficient enough for the distance and power which our system is tryingto accomplish.


3.1.4 Viewing Interface

The panoramic output will be available for any device with a modern browserinstalled on it. Given the high resolution of the picture, optimally the output willbe viewed on a high resolution monitor. We will split the outgoing video into 4sections, each 90 degrees field of view, so that it will be easier to view the outputon a wider variety of devices. Although the output from the camera is formattedwith 14 bit greyscale, most displays are not capable of displaying pixels with 14bit values. Because of this, we will scale down the value of each pixel to an 8 bitrepresentation, making the image more accessible to any type of display.

Figure 3.24: Web Page View

3.1.4.1 Web Site

The Website will have 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 will be a portion where the user can gointo 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 is a message box that shows any errors that haveoccurred with the communication to the camera. It is placed so that the user can


see the error codes without having to search for them. In the center there areimages coming from the camera explained in Section 3.1.4.2.

3.1.4.2 Display

As mentioned earlier, the image will be split into four different sections. Giventhat the horizontal resolution of each frame is 320 pixels wide and we are taking40 frames to constitute an entire image, the final image will be 12,800 pixels wide.Even for some of the best monitors available this is too wide to display on onescreen. Dividing this into four, each section will have resolution 3200 by 240.The sections will be laid out with two above the other two. Each will cover 90

of the total picture. We will label each of the sections so that the end-user caneasily identify where things in the picture are located relative to the location ofthe system as shown in Figure 3.24.

3.2 Software

The code for the project will be 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 inthe 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 is taken fromTamarisk software interface control document[20].The Tamarisk camera is capableof outputting in serial through several routes. The most common links used are theRS-232, USB or UART. The RS-232 offers a 57.6k Baud rate by default, enoughfor the purpose of communicating to they Zynq. However, in order to get output ina digital form, the use of UART is required. Familiarity with UART led the groupto determine this would be the best way to receive output from the camera. The


Figure 3.25: Data Flow in Software

baud rate can be set to whatever value is needed when using UART, so the defaultvalue of 57.6k will be used. This can be adjusted if it is felt that adjustment isneeded. For an in-depth explanation and visualization, please refer to Figure 3.25.

The Tamarisk supports a set of hexadecimal instructions which will make debug-ging and adjusting settings easy. Communication back to the camera will be donethrough the Zynq, as this is the only point of communication to the camera. TheZynq will be configured to signal certain LEDs when communication error occursto aid in debugging.

There are 24 commands which are of interest to the end-user and us as the de-velopers of this project. These commands handle every setting on the camerafrom time between camera calibrations to the auto-gain correction level. Thesecommands are 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 is a completely programmable chip there are some configurationsthat need to be done in order to allow for this communication. Using the Xilinxsoftware. Xilinx makes 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 is unaware of what hardware is attached to it. UART

Figure 3.26: Xilinx Software Block Design

is part of the MIO ports which the Zynq Z7010 has 31 usable MIO. Each MIOport can only be taken up by one peripheral as demonstrated in Figure 3.27.

Since we are using the Zynq Z7010, we are limited on the amount of ports we canuse. Therefore, we chose the pins 52 and 53 as shown in Figure 3.28 for the UARTso that we have USB available.


Figure 3.27: Xilinx MIO Configuration

Figure 3.28: Xilinx MIO UART Configuration

3.2.1.2 Programming the UART

This will be considered a peripheral on the Zynq. Embedded Linux will be ableto detect that there is a serial port attached to the hardware. This is how wewill send the commands to the camera. We will generate a piece of software thatwill just interface with the camera by sending it the controls that the user selectsthrough the UI (WebSite).

The simplest way to do so would be to write a Python script that interprets theusers input on the website and then sends the commands to the camera.

PySerial is a package that allows for serial communication in the Python language.An example of how to write to the camera is demonstrated in Figure 3.29. Oncethe command is written to the camera the camera will reply. Figure 3.30 showshow to read the information coming from the camera to make sure that it executedthe command correctly. If the camera did not execute the command correctly therewill be a certain amount of times that the command will be resent before a timeoutoccurs. At that point the user will be alerted that something went wrong with


sending that command to the camera. From there it will be up to the user todecide what to do with the information now presented.

Figure 3.29: Serial Write to Tamarisk

3.2.1.3 List of Commands that will be sent to the camera

There are 24 commands that the camera should be able to receive over UART.Table 3.3 lists all the commands with their hex command value and a brief


Figure 3.30: Serial Read to Tamarisk


description[20].

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 causes thecamera to send back a string specifying what the period between camera calibra-tions is currently in seconds. This command will most likely work in conjunctionwith the 0x12 command 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 between 0


and 7 which will specify the strength of the ICE. Low values of ICE strength areused 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 will set ICE to a strength of 0, and a 1 value will set the ICE to a strengthof 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 will turn ICE mode off, while a 1 value willturn ICE mode on. We will most likely always use ICE mode during development,but want to leave the choice of whether to use it up to the end-user.

Automatic calibration activity query Sending this command to the systemsuccessfully will result in a returned integer value between 0 and 2. The meaningsof these 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 periodis 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 will not be used frequently bythe end-user. It is intended to completely turn off or on automatic camera cali-brations. In development we will want to use this command to stop calibrations ifwe want to perform a specific kind of calibration, either range change or regular.This would prevent a different calibration from being triggered while ours is goingon. Most of the time we will want to leave automatic calibration enabled. Thiscommand takes a 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 will performthe calibration as normal, and 4 will perform 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 would like to leave the choice of how todisplay the thermal image to the end-user, so this command will 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 bythe 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 coordinatevalues.

• 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 will be useful to us in our development stage, as it will allow us tomake changes to camera settings and then bring the camera back to its originalsetup.

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.It will send back in return a VALUE response with this value, as well as anacknowledgement. This command is good when used before setting any parametervalues, 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 willnot be used by the end-user. However, it is important to make note of it. Thedefault output is through the Symbology Module. We have designed our systemaround the 14 bit data output, which is a different output source. We will needto set this when we first set up the camera.


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 will want to set this up at thebeginning of development to be a frequency compatible with the entire controlunit and set it as 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 will largely be of use to us 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 bitis functioning correctly. Because this has nothing at all to do with image settings,it won’t be of use to the end-user. Therefore, we will not include it on the viewinginterface.

3.2.2 Motor Communication

The motor will be configured on first implementation to follow a regular movementpattern. It will rotate 9, then stop. It will do this 40 times, completing an entire360 rotation. It will do this rotation every time a signal is received from thecontrol unit saying that the camera is ready to capture the next frame.

The control unit on the platform will be the Zynq. The Zynq will determine whenit is an appropriate time to trigger the command to start turning and then waitan appropriate amount of time until the motor is in position and capture an imagefrom the camera. It will determine the timing based on the average time it takesto rotate 9. This number is not definite at the moment but once it is determinedthrough some experimentation, it will be programmed into the Zynq. The signalwhich the Zynq transmits will be sent through the LEDs at the bottom of thebase platform. From there it will be retrieved by a phototransistor on the baseunit with an Arduino attached.

3.2.3 Motor Control

Once the information is sent from the platform to the phototransistor there willbe an Arduino that will read and decode the information it received. As soon asit is done decoding the information it will then send it to the STR 2 Driver whichwill send impulses to the motor and rotate accordingly.


Arduino has a stepper motor library which we will be using. We still have todecode the information from the phototransistor. Using the library, the Arduinowill 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 motora fixed amount of times is shown in Figure 3.31. This will be used to move themotor 9.

Figure 3.31: Simple Stepper Motor

There is an alternative process which the sponsor company suggested which incor-porates settable modes for the motor. This feature will be a ulterior goal whichwill be added in if there is enough time during development. These modes canbe 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.32: Complex Stepper Motor

3.2.4 FPGA

The power of the Zynq comes from a combination of its dual core processor aswell as the ArtixTM-7 FPGA. The ArtixTM-7 will provide a direct connection to


the camera’s output[13]. The information from the camera is in raw 14-bit formatand will need to be processed and composed into a frame. The ArtixTM-7 willtake care of all the timing of the bits, clocks of the camera, as well as moving theframes in and out of memory. Once the final panoramic is done, the ArtixTM-7 willtake care of any post processing of the image and place it in a memory locationwhere it is easily accessible by the dual core processor so the user can see the finalimage.

3.2.5 Embedded Linux

We will utilize Arch Linux ARM on our Zynq. There is a complete guide forinstallation of this operating system on the ZedBoard website. The ZedBoarddevelopment board we are using already comes with Arch Linux installed, whichis great for immediately being able to start developing code for our system. Theboot files for our Zynq SoC will be loaded onto an SD card which will be read onthe Zynq board.

The presence of an operating system will allow a way to get this information outto the user in an easy and intuitive way. Since the operating system is Linux, ahigh level of customizability will be available. The operating system will host aweb server, provide serial communication, and serve as a platform for an RTSPserver.

3.2.5.1 Web Server

Having a web server will allow for users to access an interface in which they cansend commands to the camera and view the live video stream. We will be usingNginx, a lightweight web server which offers flexibility in hosting data. However,Nginx will need to be compiled and configured from source before being used onthe Embedded 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 is a program available onLinux that will facilitate the RTSP server creation.

3.2.5.3 Serial Com

Serial communication will be used to send commands to the camera, which willbe sent using a python script. This allows the commands so that it can be easilyinterfaced with the website. Python offers a serial communication library. The


script will look 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 needs to be a form of IP communication with theLinux subsystem. Embedded Linux will be able to handle various wi-fi adaptersautomatically[9]. There are two possible ways on how we set it up: The 1st beingAd-Hoc and the 2nd being infrastructure. Infrastructure will allow for the Em-bedded Linux to connect to an access point and from there, any device connectedwill be able to view and control the camera stream. It is important to note thatthis project implementation will have no added security measures in place.

Each of the systems above will need to be complied on the device and configuredto work for the Zynq.

3.2.6 Platform Communication

The platform will need to feed the output of the completed image to a displaydevice. Since the entirety of the system is on a spinning platform, any wirescoming down from the device pose a problem. Also worth considering is thedistance the camera is from the output display. To address these issues, wirelessRF communication will be used to stream the output from the control unit to thedisplay. There are two options for RF communication.

Wi-Fi can be used so that the outgoing data can be easily viewable in a wide arrayof devices. The hardware implementation of this would be relatively simple. Theproblem with this approach is that the IP stack would have to be utilized in orderto send the data over wi-fi. This adds more computational load on the back endof the system. The data would need to be formatted in a datagram properly inorder 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 wouldbe 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 is important for meeting our project specifications, since we don’tknow what environment the camera will be used in, or what resources will beavailable for viewing.


3.2.7 End-User Interface

Because we are utilizing wi-fi and the IP stack, the end-user viewing environmentwill be any browser which supports HTML 5. The webpage will have minimalcontent, but the center of the page will host a video which uses a VLC plug-in.This enables us to give the plug-in the IP address of the streaming content fromthe Linux server. It will display this automatically on opening the page. Thisplug-in also supports the ability to stream full screen by double clicking on theelement. On the bottom of the page we will display any error code which requireshuman intervention to fix. This will both allow for easy debugging on our end,and give the end-user feedback if something was to go wrong with the system. Onthe upper right corner of the screen will be an easy to use menu. This will displaythe commands which can be sent to the control unit. With this, the end-usercan adjust the ICE or AGC to their liking. This setup should provide all of thefunctionality we need on the front end of the system and be easily accessible to all.Figure 3.33 provides a complementary diagram that illustrates the general processdescribed above.

Figure 3.33: End-User Communication

3.2.8 Network Access

The data will be streamed over an embedded Linux server on the PCB. The serverwill run on Arch Linux ARM, a distribution designed specifically to run on anembedded ARM processor, which our Zynq processor has. It will be set up to usethe minimum resources required.

The basic flow of the server will be 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-infrom a static IP.

3. When the output buffer updates to the new panoramic, update the data atthe IP address.

The wi-fi dongle we are using is capable of transmitting at up to 150 MB/s, morethan enough for the purposes of sending the 4 MB of data we need to send every2 seconds. Optimally the user will be within range to connect directly to thenetwork being broadcast. This would give the fastest speeds. Otherwise, the usercan connect to the website anywhere and view the output.

3.2.9 Output Protocol

Data transmission through the server will use IPv4, the standard protocol forsending data over the Internet. The data must be formatted with an IPv4 headerto tell the network how to transmit. Fortunately, the embedded Linux server andthe wi-fi dongle will take care of this formatting for us. The drivers that come withthe USB and Linux will know exactly how to put packets together. In order totransmit, we will need to put the data to be transmitted in a block of RAM, andtell the Linux server when data is ready to be updated. This way it will transmitonly when necessary, when new data is in the RAM buffer.

3.2.10 Video Output

The final output being sent through wi-fi will be an 8-bit greyscale image. Al-though the original output from the camera is 14-bit greyscale, this is more thanmost displays are capable of representing. Rescaling the values of each pixel to an8-bit value will also decrease the amount of bandwidth we need the end-user tohave, and the wi-fi to support. The total panoramic will be segmented into fourparts to make it easier to view on many different platforms. The total resolutionof each segment will be 3200 x 240.

3.2.11 Image Processing

Two approaches were considered in the handling of creating a smooth lookingpicture which covers a 360 view. The first was to use a wide field of view, but takepictures which overlap with each other to a point. When the pictures are stitchedtogether, the images can be smoothed algorithmically to create something thatlooks true to life. This is the way in which phones that take panoramic picturescreate a final image.


The second way of going about composing a full panoramic picture is 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 are being processed at one time, allowing the use of a cheaper Zynq. Itdoes require more precision from the movement mechanism being used, namelythe step motor. This has been figured into the selection of the step motor, asaccuracy was one of the top priorities.

The images coming from the camera are in 14-bit greyscale. Since this is a thermalcamera those values represent a specific temperature. One of the major postprocessing that needs to occur is gain control. Gain control will take all the valuesfrom the each frame, calculate mean and standard deviation and rescale all thepixels in the image to be between those values. This will be implemented on thewhole panoramic to make it look more uniform rather than each frame individually.The FPGA will facilitate these calculations.

Once the gain control is applied, the ArtixTM-7 will place the final image in alocation that is accessible to the Embedded Linux.

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

3.3 Housing and Mounting

One of the things that need 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 (3.3.1)

• Motor Mount (3.3.2)

• Control Mount (3.3.3)


3.3.1 Camera Mount

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 needs to be connected to a rotating platform which can spin ina 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 relative tothe camera is located inside the lens due the the heavy weight of the 35mm lensbeing greater than the weight of the camera module. With this in mind, we havecustomized a brace mount for the camera that will stabilize 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 designthat will behoove the functionality of the camera mounted to the rotational axis.Using the mechanical ICD of the Tamarisk 320, a plastic form factor can be de-signed using a 3-D modeling program and then printed out using a 3-D printer.As a preliminary design, we have created a 1.25” x 0.29” x 1.0” (L x W x H)brace that will be fastened to the camera lens in order to stabilize it. However,the thickness of the material will need to be tested to ensure appropriate stability.Figure 3.34 provides a SolidWorks drawing of the dimensions and layout of thebrace for visualization purposes.

A primary design consideration is to make sure the camera is fixed within a verylow tolerance to the rotation of the motor. The rotation of a single click of themotor is being used as a constant 1.8. While this contains a high degree ofaccuracy, the motor has no default way of reporting back its original location.Assuming this constant, and without the aid of any additional positional sensors,preventing camera drift from the reference axis is paramount. Providing additionalsupport to the sides of the camera will help prevent the camera from drifting fromthe assumed location. Gripping the camera by the lens is also important, most ofthe weight of the camera is in the lens. Gripping both the lens and camera bodyto minimize the strain on each respective component which could be induced by achange in rotational inertia. A controller module is another part of the design. Thissystem is imperative to interface with the data coming out of the camera, supplypower to all of the components, and control the stepper motor commands. Themount for the camera needs to take into account the positioning of this controllerboard. Sufficient access is needed in the back of the camera to allow connectionto the existing pin outs on the camera module.


Figure 3.34: Tamarisk Camera Mount

The camera mount needs to secure nicely to a platform which will rotate as aresult of the stepper motor. Slots should be fashioned into the casing to provide astable mounting platform. Making the camera mount detachable from the platformis important in the prototype phase to keep the system as modular as possiblepromoting the freedom of design changes. In order to remedy this, a ”riser”platform is added above the Zynq board. It is important to note that the riserplatform fits over the Zynq board and onto the rotational platform. This allowsit to provide stabilization to the camera brace but still spin with the rotationalplatform. A bonus is that the riser platform will provide additional protectionto the Zynq board from outside elements. In Figure 3.35, we have detailed thedimensions for the riser board for visualization purposes.

The infrared camera is the highest value asset of this project. Protecting the device


Figure 3.35: Riser Platform

from 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 should be optimized to prevent obstaclesthat 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 will be optimized. This willreduce the probability of external interference.

3.3.2 Motor Mount

The motor is the primary mechanical item in this panoramic solution. The ro-tation of this system needs to be unhindered. The system requires a high levelof sensitivity in order to function properly. The bulk of the motor is going to bemounted on the base side. The small bolt which comes out of the motor and spinsrelative to the rest of the stepper motor will be anchored into the rotational plat-form. The majority of the electrical components will be mounted on the rotationalplane. This will prevent the need of wires to be fed from the rotational platformto the relatively stationary base. This design is intended to optimize the disuse ofslip rings for the project.

There are several considerations in mounting the motor to avoid any potentialissues. The pin extruding from the base needs to be anchored to the rotationalplatform. The bulk of the motor needs to be fastened to a secure base. The base


will house the power supply, the motor, and one of the inductive coils. The pincoming out of the motor will be fastened to the rotational platform and will besecured to the rotating platform by utilizing the flat side of the pin. A couplingsleeve will go over the pin securing itself by applying pressure to the flat edge. Thiswill allow the rotational platform to respond to the pins orientation. The sleeveattached to the motor pin will be made of a light weight metal such as aluminum,which will provide a secure grip to the pin without adding an excessive amount ofweight. A hole will be threaded into the aluminum sleeve which will allow a screwto be tapped in order to supply additional pressure onto the pin and keep the topstructure from being lifted from its base. The rest of the motor will be attachedto the base platform.

The base platform will be printed out of a weather resistant plastic. The bulkof the base will be printed as a single piece of plastic. This ensures the joints ofthe base are waterproof. Water entering the base could irreparably damage theelectronic components on the inside. The only other piece of the base which willbe exposed to the outside will be the top plate. The top plate is a square pieceof plastic which attaches to the bulk of the motor and the rest of the stationarybase. The base should have the facility to be fastened to a surface. This deviceis a demonstration unit which will need to be portable. A final ready-for-marketversion of this product will utilize a base with some anchor point to be fastenedto a surface. The prototype will not need such a system. However, the prototypeshould have a secure base. The base will need to be heavy and stable enough to notreadily move. Should the prototype shift during operation this would adverselyaffect the system and the output imagery would not be accurate. Some of thepanorama could be missing or the same environment could be repeated. Weightingthe base to prevent undesirable movement of the system will result in more reliableimagery. A lead weight would serve as an ideal solution. Lead is very dense andinexpensive which means only a minimal amount of lead would be required tosecure the base and the cost associated with securing the base will be minimal.Designing an aesthetic base is important in designing a marketable product. Thebase will be designed to have a uniform sleek exterior. Branding the base of theproduct will establish recognition and a trademark to the work. The logo willserve as our stamp of approval, reassuring potential customers they are looking ata refined, polished, and reliable product.

This system will be subject to much rotational stress. The platform starts andstops frequently. The bulk of this mechanical stress which the system experienceswill be exerted on the motor and any of the components on the rotational platform.The frequent change in rotational inertia should be factored into the design of themotor mount. Similar to the camera mount, considerations need to be taken toensure the rotational axis of the motor with respect to the camera, is configuredand does not deviate from the calibration. The components surrounding this sys-tem should be reinforced to compensate for the additional stress which the systemwill experience. The motor picked is capable of handling much higher payloadsthan what it is being subjected to from this design. However, the rotational plat-form will require a dampening system which will reduce any vibrations from the


base starting and stopping, potentially affecting the imagery of the panoramic sys-tem. Implementing some rubberized dampeners about the motor and rotationalplatform will remedy this issue should vibrational interference occur.

The rotation between the platform and pin must be controlled. None of the othersystems should interfere with this interface. Design to prevent any electrical com-ponents and environmental interference has been taken into account. The spacebetween the two platforms needs to be protected. The optical communicationwhich resides inside the area between the rotational platform and the base moduleneeds to also be preserved. A tight space between the base and rotational plat-form will help mitigate any potential interference. Bristles between the rotationalplatform and the base will help stabilize the system, protect the optical interface,and prevent foreign objects from interfering with the rotation of the system.

3.3.3 Control Mount

The Tamarisk comes optionally equipped with a feature board, the configurationwhich we have selected is the one without the additional board. This solution islighter and provides a more useful digital interface capability. Items which willbe connected to the camera are the electrical connections which will provide noadditional structural support and the structural mechanical mount. The structuralmount will consist of support for the camera to be fastened to the rotationalplatform and also a weather protection structural dome. DRS offers some existingmounting solutions for the Tamarisk. Their solution consists of a metal ”U” shapedclamp which grips the camera behind the lens.

The camera mount system will be mounted above the controller. The controllerwill be fastened to the rotational platform. A small platform will act as a bridge,extending over the Zynq board. This platform will supply a mounting interfacefor the camera so it will not interfere with the Zynq board. The camera will beconnected to the board via a SS4 breakout wire. The Zynq will be fastened bya few screw holes in the board to the platform. A wi-fi module will be mountedwith the controller. Considerations will be taken into account to ensure there isnot any EM interference and a thin weather-proof plastic will be used to cover theboard. The Zynq, like any computational device, will generate heat. A small heatsink or other ventilation solution might be required to adequately dissipate heat.After testing of the device is done, heat dissipation factors can be considered.

The inductive coil is part of the control mount system. A concern with the induc-tive platform is interference from the coupled inductors. In order to reduce thepotential interference of the inductive system, placing a copper plate underneaththe board will help shield the board from flux. The rotational platform needsholes in the bottom of the system. These holes will allow light from the LEDswhich reside on the top platform to reach the bottom, or base module, to estab-lish optical communication. The LEDs will reside beneath the copper plate. Thecopper plate can be utilized as a local ground of the system. The inductive coil


will also reside beneath the copper plate. The coil will be mounted directly abovethe other inductive coil attached on the base unit. For maximum power transfer,the distance between these two will be minimized.

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.

3.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 expectedto look like. Combining the camera mount, motor mount, and control mount,we have simulated what the entire system is supposed to look like and how itwill all fit together. Figure 3.36 depicts what all of the mount subsystems looklike assembled. We can see that the base unit houses the OMHT17-075 StepperMotor, STR 2 Driver, and the OMPS300A48 Power Supply Unit. From here, theOMHT17-075 Stepper Motor sticks out through a hole in the middle of the baseunit and connects to the rotational platform. Between the base unit and rotationalplatform there is a approximately 0.24” where light sensors will be placed that actas the form of motor communication. From here, the Zynq board board sits atopthe platform with the riser and camera brace perched above it, providing a stablemount for the Tamarisk camera.


Figure 3.36: 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:

• Tamarisk (4.1)

• Power Supply (4.2)

• Motor (4.3)

• FPGA/Control Unit (4.4)

• Power and Regulation (4.5)

• System Performance (4.6)

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.

4.1 Tamarisk

Being the focal point of the project, testing for the Tamarisk is of the utmostimportance. We will need to make sure that the camera’s clocks are workingcorrectly. We need to make sure that the data output is working correctly. Weneed to make sure that UART commands are being sent to the camera correctly.

4.1.1 Testing the Clocks

We test the clocks by attaching the clock pins to an oscilloscope and look at thedifferent clocks.

105

Section 4. Construction Testing and Evaluation 106

PCLK(10 Mhz) The PCLK is the driving clock, we will have to make sure thatthe period between rising edges is 100 nanoseconds. This will be our baselineto measure the other two clocks.

LSYNC Is driven by the PCLK. It is 320 PCLK cycles, therefore the time thatthis clock remains HIGH is 32 microseconds. There is also a time where itremains low, however that is determined on a camera to camera bases, wewill measure the H Blacking, as it is called.

FSYNC Is driven by the PCLK. It is 76800 PCLK cycles, therefore the time thatthis clock remains HIGH is about 7.68milliseconds. This does not accountfor the H Blacking. Once the H Blacking is calculated we can then determinethe actual time that FSYNC remains HIGH.

Based on the timing diagrams for the Tamarisk, we are able to take a pictureroughly once every 15 ms, this can be done quicker we will have to test for theabsolute minimum time that it takes to retrieve. With these constraint in mind,we must coordinate the Tamarisk with the motor so that the motor rotates onceevery time that the camera is ready. With these design characteristics in mind,we have composed a testing procedure that goes as follows:

1. Connect pins 40(PCLK), 42(LSYNC), 44(FSYNC), to the oscilloscope.

2. Power up the Tamarisk.

3. Look at the oscilloscope and make sure that the clocks are responding ac-cordingly.

4. Measure the average period of the FSYNC and the LSYNC.

5. The FSYNC will be used to trigger the movement of the motor.

4.1.2 Testing the Data Out

We can test the Data out by attaching each of the 14 pins for data to an oscillo-scope. Since each of the pins represent a logic HIGH or LOW we can make surethat they are outputting that. All we need to do for this check to see that data iscoming out from the camera since later we will make sure that the data is in factan image.

4.2 Power Supply

We need to make sure that the power supply is outputting the correct voltage andwhen needed the correct currents. We can check the voltage as well as the currentwith a multimeter. We need to make sure that we measure these wile the motoris working to ensure that the motor is getting the power it needs.


4.3 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 Tamarisk camera. With this in mind, we have come upwith a few testing procedures.

4.3.1 Making sure the 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.

4.3.2 Testing the Arduino as a controller

We will at this point take the STR2 off of the self test mode and connect theArduino to it with the basic motor control program. The basic control programwill go through a mock simulation of stepping the motor 5 steps, holding theposition for a step again until it has done so 40 times completing a full rotation.

1. Plug in the Arduino to the STR2 control lines

2. Run the program that moves the motor 5 steps for a total of 40 times.

3. Make sure that the motor has indeed rotated the full circle.

At this point we will be confident that the Motor, Driver and the Controller are allresponding as expected. we still need to make sure that the events are triggeredonly when the camera is ready to rotate.


4.3.3 Testing the LED trigger

We now have to make sure that the Arduino program will work when the LEDsare enabled. We will generate a program that enables the LEDs and then theyshould trigger the phototransistor which will cause the Arduino to spin the motor.

1. Flash LEDs to the phototransistor

2. Wait until the motor stops spinning and then trigger the again for a total of40 times

At this point we will be confident that the whole Motor/Control subsystem isworking as intended.

4.4 FPGA/Control Unit

The FPGA/Control Unit is essentially the ”brains” of the entire project. Here, allof the logic will flow to the different components of the system and where all of theprocessing will occur. It is imperative that proper testing is conducted to makesure data is being stored correctly in the system, commands are being correctlysent to the Tamarisk camera, and the output of the Tamarisk camera/FPGA iscorrect.

4.4.1 I/O

To ensure that data is being stored correctly in the incoming and outgoing buffers,we need to perform capacity tests. The specific procedure for seeing if the bufferswere set up correctly can be seen below and is demonstrated in Figure 4.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 4.1: Input Buffer Functionality

We will also need to test the USB Wi-Fi dongle to ensure full functionality. Thisinvolves checking the speed of the connection, and the reliability of the connection.The steps we will have to walk through to test everything we 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 network

3. Measure how long it takes for the viewing page to update compared to howoften the data is changed on the system

4. Try sending a command to make sure the Wi-Fi is able to both receive andtransmit

4.4.2 Software Unit Testing

Each of the commands which can be sent to the camera need to be tested. Table 4.1shows the hexadecimal commands of interest and the function of these commands,and Table 4.2 shows the type of message the expected response 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 4.1: Tamarisk Commands of Interest

• Byte 6 is the checksum

The format of a VALUE response also follows a set format.


• Byte 2 is 0x45, the VALUE response ID


• Bytes 4 and 5 are an unsigned integer


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.


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 4.2: Response to Commands of Interest


• Byte 2 is 0x00, the TEXT response ID

• 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 fails, one of two responses are possible. A NAK response indicates thatfor some reason the command given could not be processed. An ERR responseindicates that an unrecognized command was given, or the command was inter-rupted.

The format of the NAK response is always in the same format. It will have 6bytes.



• Byte 2 is 0x03, the NAK response ID


• Bytes 4 and 5 echo the command ID


The format of the ERR response has two possible formats. It will have a variableamount of bytes. The format of the first type of ERR response is below.


• Byte 2 is 0x04, the ERR response ID


• Bytes 4 and 5 echoes the command ID


The second possible ERR response is of the following format.


• 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 need to receive each of these signalsand make sure they are interpreted in the appropriate way. Perhaps most impor-tantly, we need to test the NAK and ERR responses. These responses are thosewhich need to be sent to the output for the user to handle. If these responses arenot being received and interpreted correctly, troubleshooting any issues with thesubsystems will be impossible.

The LED subsystem will also need to be unit tested. This involves fully program-ming the base platform light sensor and motor controller as well as the rotationalplatform LEDs to work correctly. We will want the platform to be rotating as itshould be to ensure that the rotation does not affect the performance of the lightsensor. We will want to check for several different 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 ofthe LEDs being turned on in the specified pattern

• That if the pattern being flashed by the LEDs is not recognized, no actionwill be taken by the motor

4.4.3 End-User Interface

A test will need to be run to check that all output is being displayed to the end-user in the expected way. All of the steps below should be checked to ensure allof the functionality on the end-user webpage is working correctly.

1. Begin streaming data from the server.

2. View the stream at the IP address configured on the server.

3. Send a command to the control unit from the webpage to modify either thecamera or motor.

4. Cause the camera to send an error message, and view it on the webpage.

Each of the commands and error messages need to be cycled through and interactedwith through the end-user interface to ensure each work as expected. The testson these will follow the same procedure as the software unit test for each of thecommand codes found in Table 4.1. Each error code should print correctly to theuser with a readable explanation of the issue encountered. The user should alsoget 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 page loads in a reasonable amount of time (<5s)depending on connection speed, the requirements will be satisfied.

4.5 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.

4.6 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.

4.6.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 motorwhen 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

4.6.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

5.1 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.

5.1.1 August

The month of August will be structured to setting a foundation to success for thefollowing months. Referring to Figure 5.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.

5.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.117

Section 5. Administrative Content 118

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

5.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.

5.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 5.2 and 5.3.

5.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.


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

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

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.

5.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.


5.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.

5.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.

5.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.

5.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 5.4 and 5.5.


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

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

5.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.

5.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.

5.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.

5.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.

5.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 thebattery 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.

5.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 on


other 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 5.6 and 5.7.

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

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

5.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.


5.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.

5.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 somethingdeployable 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.

5.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.

5.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.

5.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 should


introduce 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.

5.2 Budget Discussion

We based our decisions on the following factors:

1. Cost

2. Functionality of the Parts

3. Complexity of the Project

4. 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.

5.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.

5.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.

5.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.


5.2.4 Development Board

The MicroZed provides the functionality of a Zynq Z7010. Having access to adevelopment environment that is easily transferable to our final implementationwas a focal point in our decision process. The design of this board providesa trustworthy foundation for expanding upon. The resemblance between the 2boards allows us to safely expand into our project goals while not being expertsin the subject.

5.2.5 Zynq

The final model we will be using is the Z7010CLG225. It has the least amount ofI/O in its series but enough for the overall project while keeping its cost efficiencyhigh. The Zynq simplifies designing a system that requires the functionality ofan FPGA in conjunction with an operating system by having a single chip setwithout giving up functionality.

5.2.6 RAM

We chose the AS4C64M16D3L-12BCN since the nature of its availability doesnot rely on a bulk purchase. This specific RAM model allowed us to keep ourexpenses within a manageable range but provides the memory needed to completethe computational work required by the project.

5.2.7 PCB

We are going to go with 4PCB.com because many professionals we know in the fieldhave recommended it. They provide cost effective pricing and quick turnaroundsregarding multi-layered circuit boards.

5.2.8 Misc. Supplies

All the components that are there to regulate power and voltages are also still inthe air.

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.


Description Part Qty. Price TotalPower Supply OMPS300A48 2 $182.00 $364.00Driver STR-2 2 $99.00 $99.00Motor OMHT17-075 2 $74.00 $148.00Development Board AES-Z7MB-7Z010-G 1 $199.00 $199.00Break Out AES-MBCC-BRK-G 1 $59.99 $59.99Zynq XC7Z010-1CLG225C 2 $54.86 $109.71RAM AS4C64M16D3L-12BCN 4 $4.58 $18.32PCB 4PCB 2 $300.00 $600.00Parts Misc. Supply 2 $80.00 $160.00Camera Tamarisk 320 1 $0.00 $0.00

$1758.03

Table 5.1: Budget

Conclusions

• Project Summary (6.1)

• Personal Conclusions (6.2)

6.1 Project Summary

Holistically, the project encompasses a wide variety of knowledge that was coveredor at least touched upon in previous classes. As for material that wasn’t taughtin class, a lot of research has gone into exploring the ins and outs of specific sub-systems that are apart of the whole project. Categorically organizing the project,we have broken it down into 3 main sections:

• Hardware (3.1)

• Software (3.2)

• Housing and Mounting (3.3)

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, andboard that were going to be used for the project. On the other hand, the softwareaspect is centered around setting up the Zynq board and all of the logic that willgo between each sub-system i.e. how all of the sub-systems communicate with eachother. Lastly, the housing and mounting portion of the project focuses on how eachdifferent component and subsystem will be placed and ultimately housed. Sincethe project is going to be used in different environments, a lot of considerationwent into how each of the components will be placed and logistically connected toeach other.

129

Section 6. Project Summary 130

6.2 Personal Conclusions

6.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. I am excited atthe prospect of turning this long report into something tangible. Looking backon the semester I did not realize the amount of design considerations which gointo planning a product. Every detail needs to be considered, there are so manychoices when it comes to choosing something as simple as an LED. There are somany solutions to today’s problems given the wealth of electrical components atour disposal today. Even considering the length of the report I am sure there aresome design aspects which have been overlooked. It will be interesting to lookback at the end of senior design II when the working product has been made andcompare it to this revision of the report to see how closely our design processcompares to the end result.

6.2.2 Alejandro Drausal Conclusions/Reflections

I am finally looking forward to building this project. The design phase had a lothousekeeping that I was not too fond of. Overall I am very happy with what wecame up with and hoping that we will be able to execute the design successfully.One thing that I realized while working on the design is how much information Iactually know, and equally how much I really didn’t. Fortunately with the internetand my background I was able to have a complete understanding of all the designdecisions that were made. My team seems like they are competent too. Nextsemester will consume much time, but I am ready for the next challenge.

6.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. As far as I’ve experienced it, I realizedthat it isn’t that bad if you manage your time properly. Senior Design doesn’tjust test technical skills, but logistical and managerial as well. Being in charge ofthe motors and power supply, it felt accomplishing to be specialized in a specificaspect of the project and to contribute to something much greater than yourself.In taking Senior Design 1, I feel that my technical and team building skills havebeen challenged and strengthened.

Section 6. Project Summary 131

6.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.When we got off track midway through the summer, previous experiences withprocrastination were there to remind me how dangerous putting a report of thismagnitude off is. I am proud to say that our last week of writing was not stressful.We did exactly what we needed to in the time we needed to. All in all the processof researching and designing our project was satisfying, and I am very excited tosee the challenges we encounter when building this system.

Appendix

1. St Johns Optical Systems Approval 134

2. Applied Motions Approval ... 135

3. Omega Engineering Approval ... 136

4. UCF Logo Approval ... 137

5. FLIR Approval ... 138

6. Lomography Approval ... 139

7. ScanCam Approval ... 140

8. Sofradir Approval ... 141

9. Pending OSRAM Approval ... 142

10. Pending LiteOnIt Approval ... 143

11. Pending Xilinx Approval ... 144

12. Pending NEOS Approval ... 145

13. Pending DRS Approval ... 146

133

Appendix. Appendix 134

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.

147

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 148

[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