Data Logger using Raspberry Pi Scott Cairns 1817523
Download 200.65 Kb.
|
- Navigate this page:
- 3.1.1Installer
- 3.1.2Data logger
- Modules
- Functions
- Exception handling
- Main section
- Output
3Development3.1DesignTwo programs were created during this project, one to aid in the installation of software and another to run the main program to allow data logging. Both of these run in the terminal and have no Graphical User Interface designed, the installation program only requires the user to input Y/N for saving required modules. The data logging program only allows externally connected computers to input ‘1’, ‘2’, ‘3’, and ‘Q’. No other interaction is required between the user and program other than these or through use of the GPIO buttons. 3.1.1InstallerThe installation program (‘installation.py’) makes use of two modules, ‘os’ and ‘time’, the os module is used to allow Python to interact with the operating system to create ‘system’ calls which allow Python to make use of the terminal, the time module is used for the sleep command. The program then uses system calls to run various commands allowing it to download the necessary software packages and Python modules, as well as creating a directory for the logger on the desktop. The installer was produced to allow an efficient method of downloading the software packages and Python modules that are required by the data logger. It creates a specific folder for the logger in which all the data will be saved in. This saves the user from having to sit at their computer downloading each required package and module which could take hours depending on their network connection. 3.1.2Data loggerThe data logging program makes use of several modules and functions. These modules allow the ability to extend the Python library which allows extension of the functionality. The Python program makes use of several different functions, this allows the program to create different processes for each of the function calls this would ensure that if an error occurred with one of these processes it would not terminate the overall program and continue to run the other processes (for example if the process for recording the optical sensor failed, both webcam recording and temperature sensor recording are done through two other processes both of these would continue to work successfully, if one function was used in the same case data logging would end as one section of the function had failed). The program makes use of command line interface rather than using a graphical user interface, as the Raspberry Pi has very limited resources available this ensures no extra resources are used simply to run the GUI. With the use of GPIO buttons to allow control of the program there was simply no need for an extra GUI to be implemented, which would also require more space on the SD card allowing less recordings to be saved. Accessing the data logger remotely allows overwriting of the GPIO buttons, allowing ‘1’, ‘2’ and ‘3’ to act as buttons (B1, B2 and B3) if the user is unable to physically press the buttons then it’s still possible to run the data logger. COSMCOSM (previously Pachube) is a service which allows users to connect to and upload sensor readings. This project makes use of EEML (Extended Environments Markup Language) which allows a connection to COSM to upload sensor reading in real-time, COSM then records the data and automatically graph the data. This allows sharing of sensor data with anyone in the world with an internet connection as well as the ability to monitor the device from anywhere in the world. COSM allows users to read and graph data stored up to three months old. COSM allows users to see webpages for individual feeds (one sensor) or view a person’s profile which includes any sensors they may upload. EEML connects to COSM using an API key, an API feed number and an API URL, using this it then sends a single reading from the sensor then COSM does the rest (updating the graphs and updating the website reading). An alternative to COSM is open.sen.se; however this appears to be an invite only service for now. Open.sen.se appears to offer better graphing (use of colours, multiple figures plotted on one graph instead of a different feed for each). This project made use of COSM to create two feeds, one for the temperature sensor data and one for the optical sensor data. Using EEML this connects to COSM using the API url, key and feed number to update with real time sensor readings and graph the data. ModulesThe data logging program (‘logger.py’) makes use of eleven modules which includes ‘os’, ‘time’, ‘datetime’, ‘RPi.GPIO’, ‘spidev’, ‘multiprocessing’, ‘eeml’, ‘evdev’, ‘signal’, ‘termios’ and ‘thread’. The ‘os’ module is used by Python to allow interaction with the operating system, throughout this file it is used for various commands such as; allowing system calls similarly to the installation program (these are used to run external software packages such as ffmpeg as well as resetting the terminal on close), get an environment variable from the operating system to determine if the user is connected remotely or not, the ability to send a kill signal for a process, and reading a key press from the terminal. The ‘time’ module allows Python access to various time related functions, in this program the module has various uses which include the ability to get the current time which is then formatted and used for a timestamp on newly created files and sensor recording. It is also used to allow sleep calls which are used to allow sufficient time for reading messages, prevent buttons from being detected several times due to holding it down, and spacing out the time between processes starting. The ‘datetime’ module allows manipulation of dates which includes the format, in this program it is used to allow a string to be produced from the time integer received from the time module. The ‘RPi.GPIO’ module allows the Python program to communicate with the GPIO pins on the Raspberry Pi, this module is used to allow gpio pins to be set up as an input or output and then attempt to detect changes such as a button press (this would change the input from 1 to 0), it is also be used to make changes such as enabling and disabling an LED, when closing the program it is also used to perform a clean-up which resets the gpio ports to defaults before the program was run. The ‘spidev’ module is used to allow the Python program to communicate with the SPI port. This is used to send and receive bits from the sensors; this allows it to read the raw values from the sensors. The ‘multiprocessing’ module is used to allow various different functions to be run concurrently; this also allows Python to terminate the processes which threading does not offer in Python. It is used to run each of the sensors individual functions when data logging begins. The ‘eeml’ module is the extended environments mark-up language which allows connection to COSM to be able to send real time sensor information. The ‘evdev’ module is used to import UInput and ecodes. This is used to allow Python to create an input device and inject key presses, allowing a key press to end the webcam stream when connected locally. The module ‘signal’ is used with the os module to allow Python to send a kill signal for the ffmpeg process if it is running when the user wishes to begin data logging. The ‘termios’ module is used to modify the terminal that the program is running in, this gets the current terminal, modifies it to allow detection of key presses. When exiting the program the reset allows the terminal to return to its unmodified state. The ‘thread’ module is used for threading within Python. This is used for the key listener function as it does not need to be terminated during the running of the program and will run in the back waiting for a key press, threading is used rather than multiprocessing as it allows use of shared memory, this allows it to alter global variables. FunctionsThe data logging program makes use of several different functions, each of these functions provide a purpose to the main section of the program. The functions in this program are ‘get_adc’, ‘recordTemp’, ‘recordLight’, ‘startRecord’, ‘stopRecord’,’ singleImg’ and ‘keyPress’. The ‘get_adc’ function receives a channel parameter, this function opens a spidev wrapper to communicate with the SPI port and send bits to and receive bits from the SPI channel, and this gets the output from the sensors, it then uses this raw data to return them to the function which called it. The ‘recordTemp’ function sets up a variable using time and datetime modules to get the current timestamp, it then calls the get_adc function to receive the reading for channel 1 (temperature sensor), converts this reading to a Celsius reading and Fahrenheit then opens a file to write it to as well as sending it to COSM. The function then gets put to sleep for 30 seconds then repeats, it will repeat until the logging is cancelled or the program is closed. The ‘recordLight’ function is similar to recordTemp but calls get_adc function using the parameter 0 indicating the light sensor is on channel 0. This function just simply writes the reading value to the file and COSM without any calculations. This function again waits 30 seconds then repeats, and will repeat until logging is cancelled or the program is closed. The ‘startRecord’ function receives a ‘method’ parameter indicating the method of logging for the webcam (store or stream); the function sets up a list of parameters which allow changing of frame rates, frame size, and other important parameters. The function then gets a list of the open processes attempting to check if ffmpeg is running, if so end the process. The method variable is used to determine which code is run to store to SD card or to stream over the network, and then the appropriate variables are used within the system call. The ‘stopRecord’ function checks if data logging is currently in process, if it is it then terminates the three processes if they are alive (a process may have terminated prior to this if it failed, for example no webcam plugged in). If locally connected it then uses evdev to create an input device and inject ‘q’ to end the webcam stream. The ‘singleImg’ function is similar to the startRecord; it sets up variables to hold information such as the frame size, input name, and other important parameters. It then checks if the ffmpeg process is running, if it is attempts to kill it then run the system call to take the image. The ‘keyPress’ function is used to modify the terminal which allows reading of inputs. It then checks these and passes them back out of the program to be used for overwriting the buttons. This function originally posed as a problem as to start with the function was called using multiprocessing, doing this caused issues with detecting buttons and the ability to pass the key back out of the function as multiprocess functions do not share the same memory, so is unable to access global variables or return any variable from the function. This problem was overcome by using threading, threading allowed access to global variables allowing the detected key to be passed back out of the thread. Exception handlingThe functions in this program all include exception handling, each function will include a ‘try’ and ‘except KeyboardInterrupt’ which is the exception if the user presses Ctrl + C the program will end, at the same time the program will perform a system call to reset the terminal (removing the previous edits it made to allow key detection) as well as a clean-up of the gpio ports ensuring no random LEDs are left on. If the user does not cause a KeyboardInterrupt then it will be skipped. Main sectionThe main section of the data logging program is an infinite loop which will wait for detection of a key or button, once either of these are detected the appropriate section of code will be executed resulting in a change to the LEDs, variables and a function call. Various sleep calls are used here to prevent several detections from one button press, again this section of code includes a ‘try’ and ‘except KeyboardInterrupt’ clause which performs the gpio clean-up and terminal reset ensuring the terminal is back to how it was before the program was run. There are various prints used throughout the program to assist the user and give the user feedback to their interaction, such as recording has started and recording method has changed. OutputThe end user will see a terminal in which any appropriate messages will appear. When the program begins the user may get a message if they are connected remotely allowing the ability to overwrite the GPIO buttons, a message will also appear stating the program has fully loaded. Enabling data logging will show another suitable warning message for users then begin data logging, during data logging every 30 seconds the temperature and optical sensors reading will be displayed. The user will receive a message when changing the streaming method between store to the SD card or stream over the network. The user will also receive a message detailing the process of an image capture. Figure 4 shows typical output the user will see when beginning the program and beginning data logging, when remotely connected. 
Typical output the user will see when Data Logging Directory: ~aka Download 200.65 Kb. Share with your friends:
|