Month: April 2023

This week I mainly focused on encasing and mounting options for our sensor module, specifically for our bike module. Prior to our final presentation, we were using a really crude method to prop up our module in order to avoid detecting the handle bar instead of the actual user.

 

So in order to improve our sensor positioning I developed a version of the case presented in last week’s report, adapted to the position in the pictures above. I utilized the center tray as the base for it and developed the following cases:

These cases were designed to be placed on top of the center tray from the bike and thus hinders our invasiveness goal sine it renders the tray useless for the user. However, this spot and method is the simplest way of mounting without redesigning the whole module or tampering with the dashboard. The case on the right is the first iteration which did not print smoothly on the corners on top evidenced by the curvature. In addition, this case is smaller and has a lower angle of elevation than the one on the right.

Nonetheless, after printing, I installed our module in both cases at the gym and adjusted the ADC reading based on threshold testing. This testing consisted of me standing upright at the very edge of the bike to see if I was detected or not, then riding the bike and tilting my body backwards in a way that would realistically mimic a user leaning back on the bike and observe how the module behaved. Clearly, we want the module to not detect a person standing behind the bike, but we want to be able to accurately detect a user on the bike even if he/she is leaning farther back than usual.

So after much trial and error I was able to determine a range of ADC values and test small variations in this value to ensure proper functioning of the system. I found that we had a lean-back vs out of range detection compromise. If we wanted to detect somebody leaning back we ran the risk of setting the threshold too low and detect a person standing at the very edge of the bike, while if we set the threshold too high we ran the risk of not detecting a user leaning back while guaranteeing a person standing at the edge was not. In light of this, I observed bike users in the gym and saw that most users leaned forward or stayed upright rather than lean back, So I decided to compromise a bit for the lean-back and focus on not detecting anybody at the edge.

With this in mind and as per the data tables and graphs we produced earlier on, I fixed the ADC reading threshold at a lower value from what was originally set for the treadmill in order to reduced the detection distance. In addition, I noticed that the larger case needed a lower threshold than the smaller one given the angle variations they had. Thus I also tested different heights of users in order to determine if the angle on the larger case was too high to accurately detect shorter users. Both cases, with different tuning, handled different heights satisfactorily (heights that are reasonable for users of the bike and heights that the manufacturer suggests, 4’9” to 6’5′).

With that out of the way I proceeded to perform the same tests and gym trials highlighted on the final presentation (document which highlights our unit testing – gym trials – and overall testing of the system – detection delay and accuracy). Our detection accuracy improved as expected, with pretty much only 1 trial failing under normal circumstances. Under extreme inclination (leaning back) the reading and detection was not stable and worked a little over half of the time, but this was to be expected as mentioned above. So we are betting that usage will not resemble this scenario and our detection threshold is appropriate.

Given that both cases performed similarly and better than the crude setup we had before the final presentation, it is now a matter of preference when it comes to choosing which model of the case to use. At the moment I am leaning towards using the larger angle one given that the smaller angle case is technically damaged. Thus if we choose to print the smaller one we would need 2 fresh prints whereas only 1 is needed for the larger angle one. This decision will save us time and costs. Nonetheless I believe our budget is still large enough to accommodate 2 fresh prints. so we will see.

So for next week we will perform more testing to see if either case has an edge, then fabricate them as part of our final system, and finally report our findings for the last set of deliverables we have for the upcoming week.

For these past two weeks I have been working mostly on the physical components of the senor module. Parting from the last status report, I was able to develop a mobile and compact version of our sensor module. Following the wiring diagram from my last report, I proceeded to solder and glue everything together forming the following module pictured below:

Afterwards, in collaboration with Nat, I uploaded the modified script for the NodeMcu with the web-app integration and successfully produced 4 fully functioning modules with web-app occupancy capabilities:

Next, I shifted my focus on creating a 3D printed enacisng prototype for the modules using Solidworks and the Ender printers at the Techspark facilities. I created one unsuccessful one and proceeded to refine it to create a second more acceptable prototype pictured below:

While I waited for the fabrication of the prototype case to be completed I tested out the modules in the UC Gym and ran a couple trials to determine what parameters needed to be adjusted. The treadmill trials were a success since I was capable of detecting proper occupancy readings with 10 one-minute stand-in trials, 10 separate pass by’s behind the treadmills mimicking people walking by, 10 separate stand-ins outside the detection range in terms length, and 10 other stand-ins to the side of the machine. All of them worked successfully in terms of the hardware, meaning that the built-in LED of the NodeMcu (our physical indicator) lit up successfully every time.

When it came to the bikes, things did not run as smoothly. First off I had a lot of trouble finding a good mounting position. I was able to improvise a rather crude setup and proceeded to run the same tests I did for the treadmill. The main set that failed was the passer-by trials since the detection range was configured to the treadmills and therefore too long, meaning that the ADC reading boundary needs to be adjusted to fit the length of the bikes. All other trials were successful.

Nonetheless, there are some some significant concerns related to the mounting position of our modules on the gym equipment. The testing took place with a sensor module in a non-fixed position. This is a concern in the case of the treadmill because if some user were to incline the treadmill to the max or use the max speeds of the treadmill causing lots of vibration, the sensor module might slip and fall. In addition, the location in which it was placed is directly in front of a hole were gym user’s belongings can be placed, objects that if placed there would effectively obstruct the sensor module. As a result other mounting positions were considered but have proved to be challenging due to the flush design of the dashboard. On top of this, the bikes dashboards have awkward angles that made the testing of our modules quite difficult.

During this testing I realized that my encasing is not ideal and that perhaps a possible implementation with the sensor connected through wires but separated from the battery pack and the NodeMcu might be ideal. The ideal solution would require tampering with the machine dashboards and potentially drilling holes to add and safely secure the mounts for the modules. Nonetheless this is obviously not allowed. Thus, this might prove to be a setback and a potential impediment in our implementation plan.

Following the gym trials, I tested the module for power consumption more formally than last time since now the Wi-Fi capabilities of the NodeMcu were active. I measured that the sensor draws roughly 21mA. Nonetheless the NodeMcu readings were a bit inconclusive. During setup, the NodeMcu draws roughly 80mA but then drops down to roughly 26mA. However it jumps frequently to 80mA and back to the 20s range. This does not affect our 16.5 hour requirement but it does make calculating the precise consumption a bit hard. Thus, I believe we will use worst case consumption estimates to provide the overall battery life

In addition, other occupancy testing was done in a more controlled environment to see the full integration. These worked successfully for the most part with certain hiccups pertaining the back-end software implementation.

So, further analysis and refinements need to be made in terms of powere consumption and the software/sensor back-end before the final report and demo. Thus for next week I plan on preforming more testing on the modules for power and integration as well as and solving the issue of mounting the module on the gym equipment as best I can. The mounting issue threw me a bit off schedule, yet when it comes to the system as a whole, I would say that portion went according to plan.