Hayden’s Status Report 2/24/24

This week was way less productive than I wanted it to be. Sunday was dedicated to finishing up the CAD for the rover and finalizing our design review presentation. While I did not accomplish much in terms of completing design tasks for the rover beyond the CAD, I spent a lot of time learning how to calculate kinematics for the motion of the rover. I should be able to start working on the software system for the drive train. Since the drive train and the design are now finalized I was able to calculate the RPM we need the motor to spin to meet our target max speed of 0.5m/s. Given the fact the wheels are 2.5 inches in diameter we need to have an RPM of 150 to be at the maximum of our driving speed. I have began to relearn and mess around with Arduino code from the following sources that are inspiring the PCB design:
Source 1
Source 2
Source 3

Unfortunately I fell ill towards the end of the week and I have not been able to fabricate parts with Varun; nor have I been super productive. However, I am finally back on schedule and the time I’ve taken to learn kinematics and review Arduino programming will definitely streamline things in the future. In the next week I will finalize the PCB design and test my Arduino code with a basic breadboarded circuit. I will also help out as much as I can with fabricating the physical rover. Once again we are very proud of our CAD so here is another angle:

Team Status Report 2/24/24

As of this past week the biggest risk we have identified is our development of a power distribution board. The biggest risk is that no one on our team has experience with this type of design. Hayden and Varun are working on this design and have been reading data sheets for the components we settled on for our electronic scheme. The current contingency plan is to start early and get help from people we know that have experience in the development of power distribution boards for systems. One change we’ve made this week which was not reflected in the block diagram in our Design Review presentation was that we decided that using an Arduino Uno would simplify the pcb design for the user side because we can use it to convert to USB protocols. This change does not incur any costs because we already have three Arduinos from previous classes. We spent a lot of time this week discussing what libraries and types of software we want to use with the camera. We had a slight hiccup where the software for the camera was not running for a little bit but we have resolved this issue. While we have not made an official change to the schedule just yet, we might have to add an additional week after Spring Break to finish up fabricating the rover. The CAD design is finished! See below.

Team Status Report for 2/17/24

Currently, the most significant risks that could indeed jeopardize the success of the project are the actual suction mechanism reaching the desired target, and the vision of the objects. As we have successfully obtained the requisite depth camera, we will be able to begin actual work in experimenting with the hardware itself. In this way, we should actually be able to finish with the identification and location of the objects. Our concern, then, currently lays within the kinematics to reach the desired object. None of us are experienced in the kinematics side of robotics, mostly with fabrication, so we have deliberately stuck to a very simple, DOF-limited robot arm on the front of our robot that indeed should be easy to calculate with. There are many YouTube tutorials, and with the scheme that we have chosen, we already found an easy way to implement the kinematics. The devil, however, is in the details. We’re concerned at the moment about the physical implementation of these kinematics. Of course, we imagine that we’ll be able to tweak parameters and effect a change, but we’ll need to ensure that we have time to sit and tweak to ensure that things go smoothly. The block diagram of the system remains the same, but the suction design that Varun envisioned last week is a bit different from what he imagined; now we will use a DC air pump instead of a syringe to create suction. It will be a bit more expensive, but this way, we can ensure that the amount of pressure will be sufficient. Here’s a much more complete view of the draft version of HomeRover:

Part A: Varun
HomeRover, within the concept itself, is designed to meet the psychological and physical needs of those who are afflicted by a lack of mobility. Therefore, the consideration that we target is that of public health. As enumerated before, the purpose of the project is to exist such that someone who is essentially stuck in a chair can use it to grab objects around them with relative ease. As we mentioned during our proposal presentation, this idea came about due to a struggle that Hayden’s grandfather was facing. As he had recently broken his hip, he found himself stuck in a chair, with a small meter-long grabber that could not aid him to grab objects that were farther away from him that what his arm could reach. (that’s where our slogan, Reach Beyond Your Limits, comes from!) We saw an opportunity to consider his psychological and physical health, and we knew that we needed to take it.

Part B: Hayden
As far as social factors, our target audience is the elderly and our design has to be intuitive and fairly simple. We know that our design needs to be easy to use by people with minimal education on modern technology and computers, which is why our design includes a basic arrow key control system with a monitor. An additional social factor we need to consider is that older people are sometimes untrusting of new technology and might not want something like HomeRover in their home; while furthering our design we need to find a way to ensure our customers that we are not collecting data or violating privacy within their home. Lastly, when it comes to our target demographic we also know that people are more financially conservative when they are older; because of this, we have made our design as inexpensive as possible by 3D printing parts and designing our system on Raspberry Pi’s that can compute fast enough but are not super expensive.

Part C: Nathan

With regards to economic factors, the first of which we have considered is that of the system of production, specifically supply-chain availability. When deciding on Raspberry Pi’s for our main source of computing capability, one aspect we considered was whether or not there was a shortage in most major retailers. However, according to multiple websites and news sources, the shortage seems to be resolved, indicating that we would be able to produce units cheaper. As a result of this, we can reduce the overall cost of our product, appeasing our target demographic who are more financially conservative, as aforementioned. In addition, because we are 3D printing parts, there is less pressure on sourcing parts through distributors and jumping through the hoops of retailers; the agency in building and representing our design tangibly is in our control, not on the onus of third party manufacturers.

Hayden’s Status Report 2/17/24

This week I spent the majority of my time designing and finalizing the mechanical CAD for the drive train of the rover. I spent a lot of time working on creating the belt system to allow us to drive the rover with two motors. I had to do a lot of designing and redesigning to be able to fit everything on the rover and I have imported the footprints in for the electronic components we plan on putting on the rover. I am currently designing footprints for modules to hold the electronics as well as finding a premade belt that works with the pulley system our wheels have. Below is the design for the dead-shaft drive train module:

Below is the live-shaft drive train module:

I also worked on the PCB some more and found some sources that have made game controllers using an Arduino. I have started experimenting with an Arduino and analog components to bring our basic PCB design to life in a practical and fast manner. Now that the rover is almost entirely designed I need to begin looking at kinematic calculations and how to perform them internally on the Raspberry Pi.

I am slightly behind on schedule from where I should be; however, the next three weeks on the schedule are fabricating the rover. Given that the majority of our parts need to be 3D printed we will have a lot of time between prints and assembly that I can put towards getting caught up on the embedded software side involving kinematic calculations. The next 24 hours will be spent finalizing the design review presentation and making sure that our design is robust and in a good place to pitch to the class.

Hayden’s Status Report for 2/10/24

This week I spent most of Sunday fine tuning the presentation and practicing for the presentation. I spent Monday morning prior to presenting reviewing our design and preparing for the presentation questions. After the presentation, I spent the rest of the week researching drive trains and CADing different designs in Autodesk Fusion 360. After researching and discussing we settled on a tank-drive system rather than a Rocker-Bogie suspension drive system. I drew both of these up in CAD just incase we want to implement the Rocker-Bogie at a later date. I also designed the modular baseplate to be able to mount our different robotic modules to the base of the robot. We decided that a peg-board type system would be best for experimentation and development.

In addition to working on the physical CAD I also touched up my PCB skills and drew up the basic PCB layout for the user controller. I found a button that could perform in the manner we wanted and that was similar to a computer key. I am currently researching methods to convert an analog high signal into USB protocol to then communicate with the Raspberry Pi on the user side.

My progress is right on schedule but I need to complete the CAD for the robot body this week. I will need to wait for Varun’s robotic arm design to properly scale parts to make sure the robot is stable. I will have the PCB completed on the user side by the end of this next week and I will have the entirety of the drive train and body of the robot mapped out. I also need to continue researching electronic speed controllers (ESCs) and other electronic components that I want to incorporate into our design.