F16: Micro Watch Monitoring System - Revision history

146 user11: /* Tasks */

2017-04-02T23:43:26Z

‎Tasks

146 user11: /* Python Serial Read and JSON Parse Issues */

2016-12-21T22:13:23Z

‎Python Serial Read and JSON Parse Issues

146 user11: /* Implementation */

2016-12-21T20:49:46Z

‎Implementation

146 user11: /* Software Design */

2016-12-21T20:49:27Z

‎Software Design

146 user11: /* Hardware Interface */

2016-12-21T20:48:30Z

‎Hardware Interface

146 user11: /* Alexa Skill Development Issues */

2016-12-21T20:41:33Z

‎Alexa Skill Development Issues

146 user11: /* Alexa Skill Development Issues */

2016-12-21T20:40:10Z

‎Alexa Skill Development Issues

146 user11: /* Alexa Skill Development Issues */

2016-12-21T20:39:51Z

‎Alexa Skill Development Issues

146 user11: /* Python Serial Read and JSON Parse Issues */

2016-12-21T20:37:53Z

‎Python Serial Read and JSON Parse Issues

146 user11: /* Python Serial Read and JSON Parse Issues */

2016-12-21T20:35:43Z

‎Python Serial Read and JSON Parse Issues

@@ Line 8: / Line 8: @@
 === Tasks ===
-* Create FreeRTOS tasks to monitor sensor data, pin dat, and OS statistics on the SJ-One Board
+* Create FreeRTOS tasks to monitor sensor data, pin data, and OS statistics on the SJ-One Board
 * Create a task that parses sensor data into Javascript Object Notation (json) and utilizes the Xbee Wire Antenna to wirelessly transmit it via the UART protocol
 * Create a python script for the Raspberry Pi 3 that parses data received by the Xbee Wire Antenna and relays it to Firebase

@@ Line 293: / Line 293: @@
 === Python Serial Read and JSON Parse Issues ===
-When initially designing the python script that would read serial data and parse it into the desired HTTP PUT request for Firebase, we had a single loop that ran on a timeout and sent whenever serial data it had when it woke from sleep. To improve data latency and reduce timing conflicts, we decided to abandon that system and instead have the python script parse and send monitoring data as soon as it was read from the Xbee. To do this, we created an additional loop to read a line of data from the serial connection. Several issues came into play when implementing this as there was no way to know if the data received was not mangled during transfer. We found out that two issues could occur: the serial connection between the Explorer USB dongle and the Raspberry Pi 3 could temporarily freeze for a few millisecond, and the data that passes between the Xbees could sometimes be corrupt. Both of these cases caused a crash in the python script and needed to be carefully recovered from using 'try-except' statements. This process took some trial and error, but ultimately lead to huge improvements in running stability.
+When initially designing the python script to read serial data and parse it into the desired HTTP PUT request, we created single loop to with a sleep timeout. In this implementation the loop would pull serial data from the boad's queue, send it, then go to sleep. This implementation had issue with timing as the rPi wake time now needed to be in sync with the SJ-one board to prevent a backlog of old data being retrieved from the rPi's serial queue. To improve data latency and reduce timing conflicts, we decided to abandon that system and instead have the python script parse and send monitoring data as soon as it was read from the Xbee. To do this, we created an additional loop to read a line of data from the serial connection and removed the sleep timer. Now that we had speedier and more stable script, other issues came into play as there was no way to know if the data received was fully intact. We found out that two issues could occur: the serial connection between the Explorer USB dongle and the Raspberry Pi 3 could temporarily freeze for a few millisecond, and the data that passes between the Xbees could sometimes be corrupt. Both of these cases caused a crash in the python script and needed to be carefully recovered from using 'try-except' statements. This process took some trial and error, but ultimately lead to huge improvements in running stability.
 === Alexa Skill Development Issues ===

@@ Line 275: / Line 275: @@
 # Initialize UART driver with a baud rate of 9600
 # Send null terminated character array over UART3
 ''' Transfer Data Object from the Raspberry Pi to Firebase's Real-time Database'''

@@ Line 179: / Line 179: @@
 [[File:CMPE146 F16 MW MicroWatch Task Data flow Diagram.png | frame | center | <center> '''Figure 6. Task Data Flow Diagram''' </center>]]
 '''Raspberry Pi JSON Parsing and Firebase Upload'''
@@ Line 200: / Line 201: @@
        print 'fireBase Data update failed'
 </syntaxhighlight>
 '''Amazon Alexa Skill'''
 The Amazon Alexa skill development can be split up into two parts: the Alexa skill code hosted on Amazon Web Services (AWS) Lambda, and the Amazon Voice Services (AVS) Interaction model defined by text and json files. The Alexa skill was developed using the Alexa Skill Kit SDK for NodeJS and uses a series of intent handlers to process the incoming json files that hold  user requests. For this application, several intents for user query, app launch, help, and exit are supported, each with their own function code. Upon receiving a user request for a query intent, the Alexa Skill code will look for the intended request, pull the desired data from Firebase, format it into a response, then send that response to AVS. The AVS interaction model is defined by the types of applicable intents found in the intent schema, the custom intent items found in the items list, and the sample utterances of the defined intents found in the utterances text. For example, if the user said, "What is the board's temperature," the utterance would be "''QueryIntent'' What is the board's {item}." The list of items would have "temperature" in it, and the intent schema would link the items list to the ''QueryIntent''.
 '''Intent Schema'''
@@ Line 233: / Line 236: @@
+}
 </syntaxhighlight>
 '''List of Items'''
@@ Line 253: / Line 257: @@
 last update time
 </syntaxhighlight>
 '''Utterances'''

@@ Line 145: / Line 145: @@
 The Micro Watch system consists of the SJ-One Board, Raspberry Pi 3, Xbee Series 1 modules, and the Xbee Explorer Dongle.
 [[File:CMPE146_F16_MW_System.JPG | frame | center | <center> '''Figure 1. Micro Watch System Configuration''' </center>]]
@@ Line 150: / Line 151: @@
 [[File:CMPE146_F16_MW_MicroWatch_System_Diagram.jpg | frame | center | <center> '''Figure 2. Micro Watch System Configuration''' </center>]]
 '''Xbee 1mW Wire Antenna - Series 1 '''
 The Digi XCTU software is used to configure the Xbee Wire Antenna modules for wireless connection. A shared channel and Personal Area Network (PAN) are set for both of the modules as well as a destination and source address. Setting these variables is all that is needed to enable communication. The module that is placed on the SJ-One Board is setup as the coordinator while the module connected to the Raspberry Pi 3 via the Xbee Explorer Dongle is setup as an endpoint. Setting either modules would have the same effect in a Xbee network with two modules, but as this project is aimed at providing multiple SJ-One Boards with sensor reporting ability, this will be important later. The SJ-One Board sends data to the Raspberry Pi 3 via UART3 protocol, and the Raspberry Pi 3 parses this data upon receiving it.
 [[File:CMPE146_F16_MW_XbeeModule.jpg | frame | center | <center> '''Figure 3. Xbee Wire Antenna''' </center>]]
 '''Xbee Explorer Dongle'''
 The Xbee Explorer Dongle is used to connect the Xbees to the Digi XCTU software as well as connect the Xbee to the Raspberry Pi 3. The Explorer dongle provides an interface between the Xbee pins and USB, allowing UART communication and configuration.
 [[File:CMPE146_F16_MW_ExplorerUSB.JPG | frame | center | <center> '''Figure 4. Xbee Explorer Dongle USB Controller''' </center>]]

@@ Line 288: / Line 288: @@
 * Become familiar with some basic Alexa Skill formats. There are really only a handful of Alexa Skill interaction models for useful skills. Take a look at the sample apps in the [https://github.com/alexa Official Amazon Alexa Github] for most of the basic types and try to adapt one to your needs.
-* Read and thoroughly understand how AVS interacts with the Lambda skill code. Some simple reading could have saved me from many hours of debugging
+* Read and thoroughly understand how AVS interacts with the Lambda skill code. Some simple reading could have saved time from many hours of debugging
-* Setup a test environment with your skill code running locally some of the best tutorials for this is here: [https://developer.amazon.com/blogs/post/Tx24Z2QZP5RRTG1/new-alexa-technical-tutorial-debugging-aws-lambda-code-locally Debugging AWS Lambda Code Locally]
+* Setup a test environment with your skill code running locally. Some of the best tutorials for this is here: [https://developer.amazon.com/blogs/post/Tx24Z2QZP5RRTG1/new-alexa-technical-tutorial-debugging-aws-lambda-code-locally Debugging AWS Lambda Code Locally]
-* Test, test, and test again! You never know what that user is going to say or how they'll perceive (or misperceive) your skill so be prepared for anything.
+* Test, test, and test again! You never know what the user is going to say, or how they will perceive (or misperceive) your skill, so be prepared for anything.
 == Conclusion ==

@@ Line 287: / Line 287: @@
 There are countless developer pitfalls and best practices when developing an Alexa skill, so here are some tips that might be most helpful to new developers.
-# Become familiar with some basic Alexa Skill formats. There are really only a handful of Alexa Skill interaction models for useful skills. Take a look at the sample apps in the [https://github.com/alexa Official Amazon Alexa Github] for most of the basic types and try to adapt one to your needs.
+* Become familiar with some basic Alexa Skill formats. There are really only a handful of Alexa Skill interaction models for useful skills. Take a look at the sample apps in the [https://github.com/alexa Official Amazon Alexa Github] for most of the basic types and try to adapt one to your needs.
-# Read and thoroughly understand how AVS interacts with the Lambda skill code. Some simple reading could have saved me from many hours of debugging
+* Read and thoroughly understand how AVS interacts with the Lambda skill code. Some simple reading could have saved me from many hours of debugging
-# Setup a test environment with your skill code running locally some of the best tutorials for this is here: [https://developer.amazon.com/blogs/post/Tx24Z2QZP5RRTG1/new-alexa-technical-tutorial-debugging-aws-lambda-code-locally Debugging AWS Lambda Code Locally]
+* Setup a test environment with your skill code running locally some of the best tutorials for this is here: [https://developer.amazon.com/blogs/post/Tx24Z2QZP5RRTG1/new-alexa-technical-tutorial-debugging-aws-lambda-code-locally Debugging AWS Lambda Code Locally]
-# Test, test, and test again! You never know what that user is going to say or how they'll perceive (or misperceive) your skill so be prepared for anything.
+* Test, test, and test again! You never know what that user is going to say or how they'll perceive (or misperceive) your skill so be prepared for anything.
 == Conclusion ==

@@ Line 282: / Line 282: @@
 === Python Serial Read and JSON Parse Issues ===
-When initially designing the python script that would read serial data and parse it into the desired HTTP PUT request for firebase we had just a single loop that ran on a timeout and sent whenever serial data it had when it woke from sleep. To improve data latency and reduce timing conflicts we decided to abandon that system and instead have the python script parse and send monitoring data as soon as it was read from the Xbee. To do this we created an additional loop to read a line of data from the serial connection. Several issues came into play when implementing this as there was no way to know if the data received was in not mangled during transfer. We found out that two issues could occur: firstly the serial connection between the Explorer usb dongle and the Raspberry pi could temporarily freeze for a few milliseconds. Secondly, the data that passes between the Xbees could sometimes be corrupt. Both of these cases caused a crash in the python script and, as then couldn't be subverted by clever design, the  needed to be carefully recovered from using 'try-except' statements. This process took some trial and error but ultimately lead to huge improvements in running stability.
+When initially designing the python script that would read serial data and parse it into the desired HTTP PUT request for Firebase, we had a single loop that ran on a timeout and sent whenever serial data it had when it woke from sleep. To improve data latency and reduce timing conflicts we decided to abandon that system and instead have the python script parse and send monitoring data as soon as it was read from the Xbee. To do this we created an additional loop to read a line of data from the serial connection. Several issues came into play when implementing this as there was no way to know if the data received was in not mangled during transfer. We found out that two issues could occur: firstly the serial connection between the Explorer usb dongle and the Raspberry pi could temporarily freeze for a few milliseconds. Secondly, the data that passes between the Xbees could sometimes be corrupt. Both of these cases caused a crash in the python script and, as then couldn't be subverted by clever design, the  needed to be carefully recovered from using 'try-except' statements. This process took some trial and error but ultimately lead to huge improvements in running stability.
 === Alexa Skill Development Issues ===