The user interface (UI) is a visual application that communicates with my range of motion device. As my first UI project, it was a proof-of-concept/exploratory project with a sub-optimal user experience (UX) and bugs. In the future, I plan to use a more portable application (i.e. not just windows) as well as test-driven development TDD.
Check out the Device Description to understand what the device is supposed to do; the user experience is the intuitiveness and efficiency of the device's features. These are the targets:
Select Rotation Type (i.e. flexion, extension, etc.)
Select Body Region (i.e. wrist, knee, etc.)
Record each repetition of motion (defined as the movement between resting point and maximum point of flexibility)
Easily add repetitions or rotation types for a given region
"New, Open, Save, Save As, Export..." features
Used at the start and end of a rotation session
"Settings" features
Allows the user to change default settings about the application
"Help" feature
Points user to resources on how to use application
Device Topology
Preface
My goal is to turn this device into an actual product and to form a business around it. Looking for an investor intimidated me, so I limited myself to a couple of thousand dollars I'd saved over the years. I also am a novice at hardware design. For this reason, professional manufacturing (i.e. working with a board house, assembler, and product manufacturer) seemed out of reach. This drove me to search for small development boards that could be placed into the final product via headers. Therefore the only manufacturing I would have done would be PCB production for the simple PCB that'd connect the various components.
I now (10/28/20) realize this is ridiculous. It drove me to make unnecessary compromises (see ESP-Now below). Low-production runs are a thing, even if the price per unit is higher. Professional manufacturing allows a higher level of quality assurance and smaller footprints.
Switch to D1-Mini (ESP8266 Dev. Board)
Driven by the search for a smaller development board and a low power communication method (was using std. Bluetooth), I changed microcontrollers to the D1-Mini, a board based on the ESP8266. This change also facilitated wireless sensor modules.
The ESP8266 is the younger brother of the ESP32; however, unlike the ESP32, there is no Bluetooth support--just wifi. Espressif, the creators of the ESP32 and ESP8266, created a protocol called ESP-Now, which according to their website, "...enables multiple devices to communicate with one another without using Wi-Fi. The protocol is similar to the low-power 2.4GHz wireless connectivity that is often deployed in wireless mouses. So, the pairing between devices is needed before their communication. After the pairing is done, the connection is safe and peer-to-peer, with no handshake being required."
By switching microcontrollers, the device topology and network topology changed.
The most notable change is the change in connection. Now, each sensor is independent and wireless. Also important is the addition of the Hub module. This module acts as the translator between UI commands and ESP-Now communication.
The plan was for the Hub to be a development board with perhaps some LEDs and buttons. The hub is powered through the USB cable connected to the UI-device. Communication is also through this cable.
Connection Process
There are two steps to the connection process: Frist, the one-time distribution of information to each party. Second, the ESP-Now wireless connection that occurs at the start of each time the system is used.
The one-time distribution of information is one-time because the information shared is stored permanently on each device (the sensors, hub, and UI). This information consists of the device types, the mac addresses, and the AES128 key. Each sensor needs to know the mac-address of the hub module, and the hub needs...
Check out the Device Description to understand what the device is supposed to do; the user experience is the intuitiveness and efficiency of the device's features. These are the targets:
Manage Bluetooth Connections
Report Raw Data (Quaternions)
Select Rotation Type (i.e. flexion, extension, etc.)
Select Body Region (i.e. wrist, knee, etc.)
Record each repetition of exercise (defined as the movement between resting point and maximum point of flexibility)
Easily add repetitions or rotation types for a given region
"New, Open, Save, Save As, Export..." features
Used at the start and end of a rotation session
"Settings" features
Allows the user to change default settings about the application
"Help" feature
Points user to resources on how to use application
Device Topology
Each of the EM7180_UltimateSensorFusionSolution IMUs were connected to the hub over a usb2.0 cable; although the communication was i2c, the USB cable was used because it is a common, replaceable 4 wire cable. In this configuration, the esp32 gathered data from each IMU (through an i2c mux) and transmitted it over standard Bluetooth to the windows machine running the UI.
Implementation
Bluetooth Connectivity
The user interface incorporated a .net library called 32Feet.net, which provided an API to the windows machine's Bluetooth capabilities. A wrapper was designed to allow scanning, pairing, etc. from within the application.
AES128 encryption was used to secure communication between devices.
Range of Motion Reporting and Categorization
The reporting and categorization were implemented using a table, a familiar concept. Cell (1, 1) is used to specify the body region. The rows are used for the rotation type, and the columns are used for the repetitions. This moves all the selectable data to the left of the window meaning that if the table were to grow larger than the available space (through the addition of repetitions or thinning of the window), all the selectable data would still be displayed. It also means that as the repetitions are completed they are filled in left to right--the same way English is read.
The "New, Open, Save, Save As" were implemented in the common "File, Edit, View, Help" header. Each is a dropdown to a list of further options.
The visual aspects of these features were completed, but the functionality (i.e. data processing and file modification) was never implemented.