Control
Control documentation in PDF form:Datei:Control Module.pdf
Contents
Synopsis
The Control Module is responsible for all signal processing and data transfer throughout the lidar system. It consists of two parts: an internal and an external controller. The Internal Controller will act to transmit data and commands throughout the system as well as to process data coming into the system. It will most likely consist of an FPGA, a DSP, or a combination of the two. The External Controller will act to interface with the Communication module in order to process commands from the user, where they will be sent to the internal controller to be sent throughout the system. It is also responsible for transferring data to the user, receiving updates from the user, and programming the internal controller.
Glossary of Terms
1. DSP: Digital Signal Processor
2. FFT: Fast Fourier Transform
3. FPGA: Field Programmable Gate Array
4. MCU: Microcontroller
5. GUI: Graphical User Interface
6. PC: Personal Computer (a system with a processor, operating system, inputs and outputs, as well as a programmable GUI)
Design Requirements
This section includes the objectives and constraints of the Control module.
1. Data can be collected at an appropriate rate
a. This depends on the FFT speed used. Research shows that a 50MHz bandwidth is usually provided in lidar systems, so a clock speed of at least 100MHz is necessary to shift in the large sample rates (1).
2. Data can be processed and shifted into a storage block which can be read by a PC at a fast enough rate
a. The FFT must be performed fast enough for real time measurements to be read by a PC (e.g. velocities read once per second)
3. The device can be readily reprogrammed remotely and code can be developed for it by open source individuals
a. Documentation and support on the device should be readily available b. A standard of code practice should be formulated (if not already formulated) for uniformity in open source code c. Existing solutions to given problems should be well known for the given device (i.e. FFT code can easily be found online for an FPGA, it does not reinvented)
4. Commands can be precisely sent
a. Precision both in time and resolution (for example in turning motors)
5. Existing solutions (i.e. off the shelf solutions) should be available for the device and its tasks
6. The device can be reprogrammed to allow for unique applications of the lidar system as well as to accommodate additional modules if need be
a. A standard interface should be developed so that new modules can simply be inserted into the system
Safety
This section describes the safety concerns of the Control module, and suggestions for mitigating any possible risks.
The Control module is the brain of the entire system and, as such, it should have a method of knowing that all modules in the system are connected in the appropriate locations, are working properly, and can be receiving power. In order to do so, it is suggested that a safety interlock signal be designed into the device. This signal should come from each module independently and provide an “OK” to the Control module, which will inform the Control module that the Power module can be turned on and all other peripherals may begin operation. In addition to this, all electrical interfaces within the control module should be shielded and insulated from external access. This is to prevent any accidental contact of potentially high voltages as well as crosstalk and unnecessary noise in data.
High Level Overview
This section will discuss the main functions of the Control module and its constituent components.
Figure 1: System diagram of the Control Module
The Control Module is responsible for controlling all data flow and electrical signals throughout the system. As can be seen in Figure 1, the Control Module is separated into two main branches: an Internal Controller and an External Controller. The Internal Controller is responsible for all internal signal processing, data collection, and sending commands throughout the system. The External Controller, however, is responsible for connecting the lidar to the user through the Communication module. It will interface with the Internal Controller in order to share data from the interior of the system to the outside world, as well as to pass on user commands to the rest of the system. The External Controller will also be responsible for reprogramming the Internal Controller with updates or new software for new applications.
Low Level Information
This section will discuss the details of the Control Module, including the functions it needs to accomplish and suggestions on how to accomplish said functions. It is separated into the two main branches of the Control Module: Internal and External Controllers.
Internal Controller
Figure 2: Overview of the Internal Controller
Figure 2 Provides an overview of the roles of the Internal Controller. The Signal Processing branch involves two main functions: Interfacing with PC (the External Controller) and Data Processing. Interfacing with PC includes the ability to be reprogrammed and the ability to receive commands, which it can then send off to various modules. These tasks can be accomplished with either a DSP, MCU, or an FPGA, based on the decisions of the designer (2, 3, 4). This aspect of the Control Module is what connects it to the rest of the lidar system, and a protocol must be set up for all peripheral modules to be able to receive and understand the signals sent to them by the Internal Controller.
Data processing involves the ability to collect and manipulate data sent by the Detector Module into useful information which can be used to determine various parameters such as wind speed and direction. In order to accomplish this, an FPGA or DSP can be used, but an FPGA would be favoured, both for its ability to be reprogrammed and its strong parallel computing capabilities. Whichever device is used must, at the very least, be able to handle an FFT with a 50 MHz bandwidth, meaning the clock speed must be at least 100 MHz.
The Mechanical branch involves the communication between modules which have moving parts or whose physical state can be manipulated by user submitted commands (for example, the scanner module being told to move the optics 30 degrees, or the pulse rate of the laser increasing). This branch can be accomplished with a dedicated chip or an FPGA, although an FPGA is favoured for its ability to handle various other tasks for this module simultaneously, and its ability to be reprogrammed. In order to accomplish this task, a protocol must be set up for the peripheral modules to read and understand the information being sent to them.
External Controller
Figure 3: Overview of the External Controller
Figure 3 provides an overview of the External Controller. It has one main task: allowing the user to remotely access and manipulate the system. This involves communicating to the various modules, receiving information about their various states (power consumption, temperature, humidity, etc.), receiving data about wind parameters, and reprogramming the Internal Controller. This can be accomplished by using a PC and a light version of Windows, as it allows for a lot of support, documentation, and individuals with the skills to program on such a platform. On top of this, it handles interfacing through PCI, USB, and other common means with little extra work on the part of the user (5).
Interfaces
Figure 4: Dependency Map of Control Module
Figure 4 shows the dependencies of the Control Module with the rest of the lidar system. The inputs and outputs are described in detail below. The descriptions are colour coded for ease of reading and transferring from diagram to text.
Progress
This module is in the abstract definition phase, and information regarding power as well as specific design (weight, dimensions, components, etc.) needs to be accomplished before prototyping can begin.
Testing
Type description of testing on module here.
Comments
UML and One line diagrams need to be made for this module.
Control module colour (Hex code): #e69238
Reference formatting needs to be changed
Revision History
| Description of Work | Date | Author |
| Created document and filled in information on Synopsis, Glossary of Terms, Design Requirements, High Level Overview, Low Level Overview, Interfaces, Progress, and Comments | 18.07.2015 | Joshua Calafato |
| Changed diagrams to standardized gliffy format, added Safety section, updated interfaces section (input/output table) | 29.07.2015 | Joshua Calafato |
| Added References | 30.07.2015 | Joshua Calafato |
| General edits to grammar and style | 31.07.15 | Joshua Calafato, Katherine Maul, Frank Modruson IV, Alan Yeh |
References
1. Zephir Ltd. (2015). ZephIR Lidar (Brochure). England: Zephir Ltd. Retrieved from http://www.zephirlidar.com/wp-content/uploads/2015/03/ZephIR-Lidar-2015-brochure.pdf
2. Texas Instruments. (Nov. 2002). Choosing the Right Architectures for Real Time Signal Processing Designs. Retrieved from http://www.ti.com/lit/wp/spra879/spra879.pdf
3. Altera. (May 2013). Radar Processing: FPGAs or GPUs?. Retrieved from https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/wp/wp-01197-radar-fpga-or-gpu.pdf
4. Choosing FPGA or DSP for your Application. (Oct. 2012). Retrieved August 2, 2015. Retrieved from http://www.hunteng.co.uk/info/fpga-or-dsp.htm
5. Berkely Design Technology. (2002). Comparing FPGAs and DSPs for Embedded Signal Processing [pdf]. Retrieved from http://www.bdti.com/MyBDTI/pubs/info_stanford02_fpgas.pdf
6. Scott S. Cornelsen. Electronics Design of the AGLITE-Lidar Instrument. A report submitted in partial fulfillment of the requirements for the degree of a Masters of Science in Electrical Engineering. 2005