[Week 2] A few tricky issues but still making progress

Figure 1: Schedule for this week.

Acceptable delay

Due to MRS students' own assignment, the DDL of Task-2 "Read multiple IMUs via multiplexer" is postponed to Thursday evening this week. Additionally, the modeling of 3D-printing parts is assigned to Yixiao temporarily. 

Progress in this week & related issues:

1. Read multiple IMUs via multiplexer (Aurora & Jiajun) 

We are now able to fetch data from up to 8 IMUs. Meanwhile, we also tried to find out current data rate. In the first attempt, we synchronized the real data rate with the rate transferred to the computer, which was only 5Hz under a 9600 Baud rate. 

Figure 2: Shows the previous test for calculating at the wrong data rate.

As Yixiao thought the sensor frequency calculated in the intial test was too low, we reworked the test speed by improving the baud rate. After changing the baud rate, the data rate was almost 100 Hz, which is close to the default speed set in the codes.

One issue in the IMUs' initialization process

After connecting the multiplexer at the beginning, no matter how we connected four or eight sensors, there were always several sensors that return 0, which was quite abnormal. We initially suspected that the problem was caused by the hardware. 

Therefore, we replaced and tested all the hardware one by one, but the problem persisted. Finally, we rechecked the code and found the problem with the code shown below (the code in the figure has been corrected). In the previous version, we initialized the multiplexer and then selected the port. In the corrected version, the multiplexer is initialized after each port selection, thus solving the problem.

Figure 3: An improper initialization of multiple IMUs via multiplexer.

Figure 4: A proper initialization of multiple IMUs via multiplexer.

2. HTTP-post request (Charlie)

Got stuck Thursday morning while sending message to the server through the router. This issue was fixed by Charlie on Thursday night. Requests from Arduino-Uno-WiFi-Rev2 can now be sent to a server on the same local area network.

3. Check the 3rd order (Yixiao)

Dave had signed the order off on Thursday.

4. Model the 3D-printing parts (Yixiao)

One part for holding IMU has been completed, but another part for Arduino has not been started. As per instruction from Dave, we may add a kind of shield to protect the IMU from being bare if time is available. 

Figure 5: A draft drawing of the model without shielding from Qi Zhou. The elongated holes on both sides of the device have been designed for connecting elastic bands, while the recessed areas in the middle have been conveniently designed to embed the IMU. Accurate screw holes have also been included in the design, which correspond to the dimensions provided in the IMU drawing.

Figure 6: Final model for holding an IMU on the femur (rendered by SolidWorks Software).

5. The displaying engine: 

        The software can now create a model based on an input text, which is flexible and able to handle various compositions of joints, such as birds or humans. 

Figure 7: An example of input text is provided for the displaying engine, which will construct and connect the joints based on the provided indexes of terminals. Although they are currently manually defined, the LCR algorithm in the field of distributed system could be explored and implemented in the future to improve automation.

Figure 8: Final output from the displaying engine. A part of modelling is instructed by the manual of a JS graphic library, "Three.js".

Unstable output issue: may related with the refresh rate of screen, Qi Zhou has been assigned to fix this.