niagroup / 2020_arduino_pi_iot_project Goto Github PK

forms/Web UI -> python/Flask back end

back end should pair with discovered devices, issue test suite in "flask_webapp/tests/", return pass/fail status back up to UI

• Decide database choice of usage (i.e. sqlite, mysql, firebase, etc.)
• Setup structure based on front-end and arduino communications & results needs:
  • Control/Command send format (should we track this?)
  • Format for Response/Results from Arduino (how should it be stored?)
  • Algorithm based results, Algorithm version based results (i.e. algo1_v0 results vs algo1_v1 results)

  NOTE:: results will be based on total time needed to be balanced

  • Test comparison storage (i.e. start position 1 results vs start position 2 results)
• Consider what database to use works best with the front-end framework (if not already included)

• This can serve as the main html to be inherited by all other front end developers.
• As new functional features get added, they can simply be added to new files.
• Will need basic color and layout ideas.
• Consider code standard.

General Idea/Purpose

• Understand pairing process requirements
• Create pairing process script
• This will be used for the backend developers

Bluetooth Pairing Scripts Requirements:

• The script method should accept two arguments: bluetooth address & pairing pin
• Pairing pin will be a default value
• Return a failure status or a pass status
• This is only for bluetooth classic/smart devices that require a pairing pin (ble devices do not require pairing)

Test & Pass Expectation:

• Verify successful pairing - Be sure that pairing works consistently

Considerations:

1. This will be executed from the webapp UI.
2. The status should change based on the results of this process.

• Decide which development framework to use for the front-end & back-end development (i.e. django, flask, etc).
• The decision should be complimentary to the features needed:
  • db management
  • potential user credentials management
  • back-end scripts
  • neutral programming language for the team to easily contribute
  • ease of adjustments to accommodate a collaborative effort

General Idea/Purpose

• To standardize expected communication based on bytes for the arduino to process and the pi to send
• Will be extensive enough to cover all microcontroller functionality and results reporting

Bluetooth Standard Requirements

• The messages should have a start and stop byte for the arduino and the pi to know when to start listening and stop listening
• A finite length for the byte array will be required, OR a set of finite array lengths depending on the desired functionality i.e. 3 byte array length for sanity check tests, and 15 byte array length for real commands and responses.
• This standard should include error messages as well.
• The maximum byte value is 255 (whole numbers), or FF in hexadecimal representation, so for floating values consideration for post receiving simple calculations will be needed. i.e. if the distance measure is a floating point value of 12.5cm, maybe it is multiplied by 10 before sending (125, or 7D in hex), sent, and then divided by 10 on the receiving end to be displayed on the front end as 12.5cm as expected.
• specific byte positions in the byte array should be associated with the expected result byte array.
  i.e. 8 byte length array [xx,xx,xx,xx,xx,xx,xx,xx]

python/Flask -> Web UI/ display Table

Recommendations

Last analysis: Aug 18 | Next scheduled analysis: Aug 25

Open

✅ Nice work, you're all caught up!

Available

✅ Nothing yet, but I'm continuing to monitor your PRs.

Metrics

What would you like to see here? Let us know!

Resources

📚 Quick links
Pixee Docs | Codemodder by Pixee

🧰 Tools I work with
SonarCloud | SonarQube | CodeQL | Semgrep

🚀 Pixee CLI
The power of my codemods in your local development environment. Learn more

💬 Reach out
Feedback | Support

❤️ Follow, share, and engage with Pixee: GitHub | LinkedIn | Slack

• This will make it possible for other users on the same network to type the IP address of the pi in their browser
  and view the front-end directly
• This does not include the latency/lag that one would normally be experienced when using VNC

General Idea/Purpose

• Learn about PWM (Pulse Width Modulation) using the digital I/O pins and how to set them up.
• Learn about controlling servo with the digital I/O pins (using Servo.h library)
• Create a function to control the servo position

Servo Function requirements:

• The function should exist outside the main loop so it is contained
• The function should require a position argument to be passed in, to set the servo position

  NOTE : The servo position should be sent as a angle in degrees (i.e. 0, 30, 90, etc )

• This function should include options to do full sweeps (0-180 degrees) or going to designated positions
• Eventually this function will be triggered by a received bluetooth command byte

Test & Pass Expectation:

• The function should be able to handle invalid values (i.e. values outside of the desired angle range.)
• The function should be able to set the servo to the correct angle per the desired angle per the passed in argument.

Considerations:
1. The servo is made up of 3 wires:

• Orange - Signal wire; this should be connected to a PWM pin (currently pin 6)
• Red - Power wire; this should be connected to the 5V pin
• Brown - Ground wire; this should be connected to the Ground pin
  2. Be sure to verify wiring to avoid damaging the servo.

3. Avoid manually turning the servo while connected to the Arduino to avoid any incidental feedback current from the servo motor.

The Technology

• The Ultrasonic Sensor [model: HC-SR04] has a transmitter and a receiver
• Ultrasonic sensors work like radar: they emit an ultrasonic pulse and wait for it to "bounce" off of a surface and back to the receiving end of the sensor. The delta in time from emitting to receiving provides a voltage reading to the Arduino to be calculated and converted into a distance reading.

Scenario:

• The ultrasonic sensor is being used for detecting the distance of the ball.
• The reading appear to be accurate from 3-15cm, but beyond that the measurements appear to be drastically inaccurate.

  Considering switching sensor technologies from ultrasonic sensor -> Infrared Range finder.

Current workaround:

• Limiting the balance range from 2-15cm. This is not sufficient.

Upon clicking the connect button I did observe connection established successfully, however an alert message was displayed by the browser explaining that there was a failure that occurred during connection.

• user entries

• time, date, balance time

General Idea/Purpose

• Learn about Serial Communication and how to set them up.

  NOTE : We will be using the SoftwareSerial library, as it will make testing/development easier.

• Learn about sending serial communication messages via bluetooth.
• Create a function to send/receive serial messages via bluetooth.

Bluetooth Function Requirements:

• The function should exist outside the main loop so it is contained
• The function should be capable of reading incoming command bytes received via bluetooth
• The function should be capable of sending bluetooth result bytes via bluetooth
• The function should be able to run different functions based on the ability to process incoming command bytes

  NOTE : This will require the creation of a defined command list, that the pi side of the team will need when integration begins.

Test & Pass Expectation:

• RX confirm - When a message is received the arduino should light an LED to visually confirm a received bluetooth message
• Echo validate - When a message is received the arduino should a response with the same byte that was received to confirm the correct data was sent from the pi
• Error Handling - When a received message (from the pi) is incorrectly formatted, the arduino should respond with an error message
• Test & Result - When a correctly formatted message is provided from the pi, the appropriate test function should run on the arduino and respond with the expected result (i.e. sensor measurement value)

Considerations:

1. The arduino reads serial commands in byte arrays, so a defined list of byte will be needed. (i.e. [FF, A3, 12, 78, etc])
2. Because the arduino will read as an array of bytes, this will potentially require a start byte and a stop byte to trigger when to stop listening for commands.
3. The HC-05 Bluetooth module has an operating voltage of 3.3 volts. The VCC pin should ONLY be connected to the arduino's 3.3V pin. While different revision of the board have circuit protection, we should side with caution and just stick with 3.3V.
_4. Serial Communication has two general methods : half duplex or full duplex _

• half-duplex - the devices can only receive or send data one at a time.
• full-duplex - the devices can both receive or send data one at the same time.

NOTE : For serial communication device 1 RX pin connects to device 2's TX pin, and device 1's TX pin connects to device 2's RX pin. So if communication isn't working, this may be a good thing to double check first.

Model a simple design to be easily assembled for the balance beam. The balance beam is used to hold the sensor & the ping pong ball. The pivot mechanism will depend on how you portion gets designed.

• Develop code to start the pi camera and stream it to the browser when ready
• Potentially include opencv to enabled computer vision based analysis (setup for future implementation)
• Potentially look into tracking objects quickly (the ping pong ball may move abruptly and it may be a challenge to track)
• If tracking is possible, consider a way to translate the illustrate the performance visually in a graph/plot

General Idea/Purpose

• Storage for different system states
• We will also need bluetooth messaging history w/ timestamps
• PID test results will possibly need to be stored as well for reference

Data storage code:

• The function should exist as a callable function for easy integration w/ other developers' code
• The function should store the following system states:
  1. Current Bluetooth connection state - what devices are we actively connected to
  2. Previously connected/paired Bluetooth devices
  3. [*stretch goal*] Storing of previously sent & received Bluetooth messages w/ the target device name (Arduino)

Test & Pass Expectation:

• The front end should load the previously paired/connected devices on the initial loading of the page

Considerations:

• The user will eventually be able to see the previously sent/received messages on the front end (in the browser window)

Description: This issue will track the effort of creating a python back-end data structure with calls for issuing a generic and BLE Bluetooth scan and identify available devices.

Pass Criteria:

• Issue a Flask command and gather unique ID for each arduino device connected.
• Store each device info in a data structure. Class, Dict, etc...

Reach Goals:

• Trigger command from "Connect"/"Scan" button from the front-end.
• Return device ID back to the front-end.

#Please document all headaches, learning, tips & tricks.

This script will simply mirror the current BLE solution, but offer similar functionality for the non_BLE communication.

General Idea/Purpose

• Function to understand bluetooth request messages from the pi
• Learn about bit manipulation (i.e. bit masking, reading, and shifting)
• Call correct functionality based on received byte arrays

NOTE : Request & Response messages will be compromised of 8 bytes in an array

Communication Standard Implementation

• The function should exist outside the main loop so it is contained

• The function should be called each time a BT message is received

• The function should be able to read all 8 bytes and parse them accordingly

  • each byte has a designated purpose:

  byte0	byte 1	byte 2	byte 3	byte 4	byte 5	byte 6	byte 7
  command	detail 1	detail 2	Kp	Ki	Kd	reserve	status

NOTE : the first bit (MSB, farthest left bit) of the command byte will indicate what type of command this message will be. i.e. sanity check vs PID control run.

• This function will call other specific action functions based on the command received (i.e. servo control, sensor read, etc.)
• This function should provide a return byte array, or "Response" via the BT module
• [If memory permits] A series of constants can be created to help map what each byte will mean

Test/Pass Expectation:

• The function should be able to return a response byte array this will be continuously developed as the command list grows.
• The first stage of this function will cause some physical action to occur in the test setup.

Considerations:

1. The function is being created based on the expectation of the request btyte array being formatted correctly.
2. The status byte will only be used by the arduino (response).

BT Communication Standard for the project

General Idea/Purpose:

• Research how to scan for bluetooth devices via python code using the pi
• Develop so it can be easily called from the front-end UI (via flask-backend)

Bluetooth Scan function Requirements:

• The function should have a test file that will be placed in the flask directory "tests" folder
• The function should be capable of scanning for both bluetooth classic (non-ble) & bluetooth low energy (ble) devices
• The function should return a readable format that is easily parsed using python code
• The function returned format should include clear distinctions between ble and non-ble devices
  • This should include the device name & its bluetooth address

Test/Pass Expectation:

• The function should return a json object that can be parsed by the respective back-end developer(s)
• If there are no devices discovered there should still be a json object returned, but it will just be empty

Considerations

• The python library installed is pybluez, but the setup differs based on the operating system

  NOTE : It has only been tested on the Raspberry Pi

• Controlling bluetooth via python requires super user access, so the pip install should be lead with a "sudo"
• Because the bluetooth control requires super user access, there will be added system level installs (this will be included in the docs folder)

• Decide on what front-end framework to use (i.e. materialize, bootstrap, angular, etc.) that works best for
  this application.

NOTE:: Be sure to update the other front-end developers so they know where to place their js, html, and css files.

General Idea/Purpose

• Learn about creating header files
• Create custom library for bt communication standard
• This should make development easier to follow/implement for new developers

Bluetooth Function Requirements:

• The library should include an extensive list of pi request messages
• The library will be a living document that will continue to be developed
• The library should include status message & command byte definitions
• The library should include methods to handle processing the pi requests upon receipt
• There should be logic to confirm whether the request is a sanity check test or not

NOTE : Sanity checks are higher priority as they require less processing time than a full test request

Test & Pass Expectation:

• Verify correct message parsing - The message should mirror the request sent from the pi
• Sanity Check State - The library should quickly set the correct response state based on the command byte
• Error Handling - When a pi request is incorrectly formatted, the arduino should respond with an error message placed in the status byte of the response byte array.

Considerations:

1. The library should be developed in parallel with the backend library to ensure consistency in definitions
2. The code should handle a lot of the heavy lifting in its own file to keep the main code concise
3. The bluetooth implementation will need to be implemented on the pi side to work the same for BT BLE devices as well as BT classic devices.

Terms

request - message from the pi to the arduino
response - message from the arduino to the pi

Scenario:

• When a request is sent with a null byte, 0x00, the Arduino is having an issue processing the message.
• The response is never sent and causes a failure message on the pi
• Any non-zero byte that's sent does not cause this issue

NOTE : This may be an arduino limitation, not sure as of yet. References search terms : "Arduino Serial Communication"

Current Workaround:

• Never send a zero byte.

Work

• Add the html button next to Connect
• Add js api to issue the POST and GET requests similar to Connect in menu_list.js
• Integrate with app.py end-point api "disconnect" (Flask side already done)
• Test that it's working on Pi.

General Idea/Purpose

• Learn about Analog I/O pins and how to read the input
• Learn about reading Sensor output and analyzing the data to the respective sensor (i.e. value equation to convert to distance)
• Create function to read sensor value and output the estimated distance

Sensor function requirements:

• The function should exist outside the main loop so it is contained
• The function should be called, and return a double/floating point position (centimeters should be the expected unit of measurement)
• The function should include a valid measurement range (i.e. when objects are too close or too far, the readings will be compromised, so these values should be ignored. Maybe this reports as 0 by default?)
• This function will eventually need a secondary function that considers how long the measurement has been within a certain range for a specific time period (i.e. If the balanced position of the ping pong ball is 12cm, +/- 1.5cm of error, for 3 seconds we trigger a "balanced state reached")
• The function should have a expected measurement duration. (i.e. measure for 5 seconds, or 10 seconds then return the last measure value)
• Eventually this function will be triggered by a received bluetooth command byte

Test/Pass Expectation:

• The function should be able to return reading values.
• The desired measurement time should match the value passed in value (in seconds) the function expected argument.

  NOTE : this may need to change to milliseconds in the future.

Considerations:

1. The sensor has 4 pins
*TRIG - Trigger pin should be connected to any digital I/O pin as an OUTPUT (Currently pin 4)
*ECHO - Echo pin should be connected to any digital I/O pin as an INPUT; to be read (Currently pin 5)
*VCC - Supply voltage pin should be connected to the arduino 5V pin
*GND - Ground should be connected to the arduino ground pin
2. The trigger pin has to be set to HIGH then LOW to start the ultrasonic pulse emission.

NOTE : This means it should start at LOW and end with LOW, never leave it at HIGH

3. DO NOT WRITE TO THE ECHO PIN, this pin is strictly for reading by the arduino

NOTE: The echo pin returns a series of pulses (HIGHS & LOWS, i.e. 101000100001). To read the series of pulses we use the pulseIn function. i.e. pulseIn(5,HIGH)

*Create Flask Project
*Add necessary folders for respective web-teams
*Push to main repo