Troubleshooting… troubleshooting… and more troubleshooting
7th July – 13th July
7th July:
The Manatees were over the moon when we found out that our linear actuators were finally delivered over the weekends! We started the week off in high spirits, spending most of the day putting everything together. Lots of screwing and soldering later, our prototype’s support pillars were upgraded to permanent fixtures, the actuators, which replaced the makeshift lego towers used previously.
After ensuring that each pair of actuators were able to move simultaneously (view video V6 here), we tested the homing programme that our coders created. This programme determines the lowest possible position (the “home”) of the support bars and it is used as the reference point from which the bars are adjusted in height. Thankfully, the programme worked well (view video V7 here) and we spent the rest of the day playing the role of test subjects and experimenting with different actuator and air bag heights.
Introducing our family of actuators and switches!
8th July:
Our main agenda for the day was experimentation, which was essential to help us identify patterns to determine a code that will achieve the automatic height adjustment function we intended. Before that, we reorganised and extended some wires to allow for more flexibility and movement (also to make sure that we did not go insane from the wire mess we created ˆ𐃷ˆ). With our prototype looking more pleasant to the eye, we began our day of experimentation.
First, we recorded the pressure readings when the three bars were levelled and varying their heights together. Unfortunately, the results from this test were rather inconclusive, which may be attributed to the fact that all of us have very different body types. We observed that those with longer necks tend to cause pressure readings on the topmost bar only, and vice versa for those with shorter necks. This made it extremely difficult to determine any trend in pressure readings.
As such, we proceeded to another round of testing. This time, we focussed on determining the curvature that was most comfortable to the user from the “home” position. After adjusting each bar individually to match the subject’s comfort level, we noticed that the pressure distribution was rather constant, ranging from 31-39% per bar. This was a good indication of a useful marker that we could use to automatically adjust to the user’s neck curvature. Unfortunately, our day came to an end before we could conduct the test on other subjects, so we will be back tomorrow to investigate further!
Putting our prototype to the test
9th July:
To achieve better accuracy while experimenting, we decided to fix the actuators onto the base board permanently. We spent the morning marking out and drilling holes into the board, then screwing the actuators and limit switch holders in place. We were satisfied by the stability of the design and were ready to start another day of experimentation.
Unfortunately, our experimentation did not last long because we were hit by a wave of issues regarding our actuators. Many of them were getting stuck randomly despite greasing and circuitry checks. After some troubleshooting, we determined that the problem may lie in the breadboard used. Currently, each pair of motors are connected to the same motor pin on the RAMPS 1.4 via the breadboard, which allows each pair to be controlled together with greater ease. Hence, we decided to reconnect the affected actuators to individual motor pins on the RAMPS 1.4 and found some slight improvements. However, more troubleshooting is required to ensure that the problem has been completely eradicated (subtle foreshadowing for tomorrow).
More drilling and screwing!
10th July:
Yesterday, the actuators seemed to work well after some troubleshooting. However, we faced yet another setback. When several of our users laid on the bars, some actuators sounded rather strained and stopped working once again. We realised that the problem might be due to the bars being unable to support the full head weight over time. Another possible reason for the actuators being stuck is due to the torsional strain on the threads. After some brainstorming, we considered adding compression springs to the bottom of the metal bars to support part of the user’s head weight and allow for more optimal actuator movement.
Our afternoon was dedicated to our second formal presentation where we shared our project updates since the first presentation. We received some good feedback regarding the issues we faced and we are looking forward to implementing them within the next few days.
To end the day, we decided to modify our circuitry one last time in hopes to figure out what may have been the cause of the motors becoming weaker. We realised that the stuck motors were the ones that were still connected in pairs to the same motor pin on the RAMPS 1.4 via the breadboard. Such a connection should draw twice the amount of current. However, it seemed that the current supplied by the power source was lower than expected, resulting in lower power to the motors (P=VI). The remedy to this problem would be to connect all motors to individual motor pins on the RAMPS 1.4 directly. Unfortunately, because the RAMPS 1.4 only has 5 motor pins, we would require an additional Arduino with RAMPS 1.4. More research will also be needed to determine how communication can be established between them.
11th July:
Continuing from yesterday’s discovery, we decided to test out the dual Arduino system which allows for the direct connection of all 6 motors to the motor pins. While our hardworking coders modified the code for this new set up, the rest of us took charge of rewiring the components. We decided to use the Master-Slave Inter-Integrated Circuit (I2C) protocol to establish communication between the 2 boards. A connection was made between the boards via the Ground, Serial Data (SDA) and Serial Clock (SCL) pins. Briefly, the Master Arduino board pulses through the SCL line at regular intervals. A single bit of information is then sent through the SDA line as the clock line changes from low to high. This process repeats till a sequence of 7 or 8 bits is sent, which forms a command that the Slave board will execute.
Thankfully, after some troubleshooting, we were able to move the actuators on command under this new set up. The actuators also appeared more powerful than before. However, the new homing sequence has yet to be tested and we will dedicate the following week for this task along with more experimentation.
Testing out the new I2C system for our prototype (spot our coders engaging in very serious conversation)