Posted on

Sebastian’s Status Report 3/23/24

This week I modified the platform jack to allow a motor to rotate the screw. This is necessary because the motor must be stationary while it rotates the head of the screw. Before the modification, the screw head moved when you rotated it because the threaded hole it was inside of caused translation. To fix this, I sanded down part of the screw with a file so the threaded hole no causes linear motion of the screw. Below is an image of the sanded screw.

I also began setting up the neural network infrastructure for posture detection. I selected a google colab notebook that is great for general purpose neural nets and has handy graphing functions to check for overfitting.

In the next week I will begin data collection so by interim demo we will have a coarse posture detector.

Posted on

Mary Rose’s Status Report for 3/23

This week I worked on designing the connection between the screw and the motor, as well as the stand and the motor. I included a sketch of the design for the block that connects the motor to the screw. This block will then be attached to the motor, allowing it to turn. The other component will attach to the bar of the platform jack to stabilize the motor while it turns the screw. My sketch for the block, and my inspiration for the motor stabilizer are shown below. The second picture is from:  https://www.thingiverse.com/thing:6161381/comments

Because of the need to create these new components, I am running a little behind in testing the code for the motors. However, I let my teammates know, and they are prepared to help if they need to.

Next week, my goal is to have these designs ready to print, and finish testing the motor code.

Posted on

Team Status Report 3/23

  • Right now, our largest risk is rotating the screw of for the platform jack. Because the screw head does not remain completely still while the stand is being raised, we are worried about how we are going to keep the motor stable. However, we are managing this risk by creating new components to attach to the stand in order to keep the motor in place. We have multiple design ideas in case one fails.
  • The changes made to our design are the addition of new components to keep the screw in place, a block, as well as another attachment to keep stable and connected to the bar.
  • We are still using our current schedule. As we had some slack time built in, we should be able to recover from adding these new components.
Posted on

Mary Rose’s Status Report for 3/16

  • This week, I worked on finishing the Bluetooth implementation from the laptop’s end. I also tested it by connecting to each characteristic and checking that the outputs were correct via printing from the serial monitor. I also began working on a function that given the number of rotations the motor needs to make, the motor will run. I may need to re-write this function, as our team is working on selecting a new motor, however as we will still be using the same motor shield to interface with it, this code will be useful.
  • I was able to catch up to where I am supposed to be on the schedule.
  • Next week, I plan to have the code for both motors (the height motor and the linear actuators) fully finished and tested.
Posted on

Team Status Report for 3/16

The biggest current risk is still the mechanical design as it has many uncertainties and because the software components have been mostly fleshed out already. To mitigate this risk we have gone ahead and ordered the platform jack we plan on using. We will begin testing next Monday. Depending on the friction of the linkages in the jack, we will determine how much torque we need in our stepper motor.

In case the platform jack fails for whatever reason (too much torque required or its top platform is not level), we will purchase a more expensive jack that is manufactured better but is also heavier.

One minor change to the design is that we are now planning on using bluetooth communication between the computer and the arduino since this is simpler than we thought and will contribute to our use case requirement of our product having a smooth and simple user interface. There were no real costs associated with this change since getting the bluetooth code written was minimal work.

Posted on

Sebastian’s Status Report for 3/16/24

This week I finished the basic proof of concept for the posture detector. Using Google’s BlazeNet pose estimation model, I was able to implement some basic thresholding on a single shoulder landmark to determine when the user is slouching. The video below shows myself sitting up straight briefly so the program can take a “snapshot” of good posture, then whenever I slouch I receive a message at the terminal telling me to fix my posture. If I don’t fix it, I keep receiving messages every 2 seconds. Once I fix my posture, the messages stop.

The link to the video on google drive is here.

I simply calculated the distance between the shoulder landmark in each frame and the “reference” frame showing myself having good posture which was captured at the start of the video. Some problems with this is that it will produce many false positives. If I shift left to right then I will get notified even if my posture remains good. For this reason, next week I will begin training a neural network for posture detection. The ability of a neural network to learn a rich and complex decision boundary makes it suitable for this application. When classifying posture in a person, many types of movement of landmarks on the body do not correspond to bad posture. I hope that the neural network will be able to learn to distinguish between movement that hints at bad posture and movement that is ok. I will be using a google co-lab notebook to train a simple neural network.

Another benefit of the neural network implementation is that our team simply has to learn from posture research what good posture is, take many photos of ourselves with that good posture, and do the same for bad posture. The neural network will do the hard work of learning what the difference is.

I am on schedule.

Posted on

Sebastian’s Status Report for 3/9/24

Over the past week I personally finished my sections of the design report. This involved completing the system specifications and trade studies sections. This was a useful exercise because it forced me to finalize the design of the mechanical stand. After conducting research on many types of platform jacks, I concluded that we should use an off-the-shelf platform jack and build an attachment for the screw so that a motor can rotate it.

I chose this path because designing a platform jack is a complex task and not the focus of 18500. Additionally, the modification to the stand will not be trivial. Like mentioned before, we will have to attach a motor to the stand, and also create a compartment (3D printed) below the stand to house the battery, arduino, motor shield. We will also need a similar compartment above the stand to store the linear actuators so that we can pitch the computer.

Overall, through writing the system specs and trade studies sections of the report, I became much more confident that our design will be feasible as I have done as much research as reasonably possible to ensure that our design choices will result in a product that meets our quantitative use case requirements. The trade studies section was especially useful to narrow down choices that were still up in the air such as what type of platform jack to go with, whether to go with wired/wireless connection, whether to use platform jack or stepper motors with lead screws, and other such tossups.

We are on schedule as the mechanical design is 90% complete and proof of concepts have been demonstrated on the software side for all software features.

Posted on

Mary Rose’s Status Report 3/9

  • Over the past two weeks, I worked on getting the Bluetooth connected between the stand and the app. I finished the Bluetooth implementation on the Arduino side. I also wrote some basic code for the Bluetooth connection from the laptop app.
  • I was able to catch up to where I am supposed to be on the schedule, this is because I moved some tasks around to make them more efficient.
  • Next week I plan to finish the Bluetooth from the laptop end and test the connection using print statements.
Posted on

Mary Rose’s Status Report for 2/24

Earlier this week, I worked on finishing the design presentation, specifically on the diagrams, the FSM, and the testing slides.

I then worked on refining and coding the calibration FSM. I tested the code I wrote for correctness, by manually feeding it inputs, and testing how it responds via prints. I am still a little behind schedule, and this week I plan to have the motor control/linear actuator code completed so I can begin testing as soon as possible. I also plan to take measurements of the design to determine how motor rotation corresponds to height.

Posted on

Mary Rose’s Status Report 2/17

  • This week I worked mostly on design. I created a document to help our team finalize our metrics. In addition, I drew up a rough sketch of the FSM for the stand’s calibration stage in preparation for writing code next week. I also did some more research on connecting to the Arduino via Bluetooth from the laptop’s side.  I also finalized the block diagram, which now includes some more detailed calibration information, such as a button that the user can press to restart the stand. The rest of my time was spent working on the presentation, specifically fleshing out our testing plan (Bluetooth communication, and motor precision).
  • I am currently a little behind schedule, which I plan to make up during the slack period I have scheduled for a week and a half from now.
  • For now, I will continue to draw up a diagram for the hardware, and next week I intend to begin writing the code to control the motor and linear actuators.