Team Status Report for 4/27/24

We have officially completed all parts of our system so the only risk right now is if we cannot configure the system effectively to meet our pickup accuracy. We have been working hard to tune our system to detect items correctly and position itself to pickup; however, we are yet to find the sweet spot in our configuration that gets us the 80% threshold we want to achieve. The current contingency plan is to keep tuning it until it can detect the item correctly; we are experimenting with a few different item detection models still.

This week we reverted our design back to having the logic level shifters as well as a PMOS switch so we could reach the 7.4V input to the pumps. Through experimentation we proved that 7.4V was necessary to achieve our pickup weight of 700 grams. We will also be adding some extra weight to the rear of our design to make sure it does not tip over. Nathan is also working on developing a web page we can host with the camera feed; we found that this was the most effective way to be able to relay the camera feed back to the user side.

Here is the camera feed working.

Unit Tests Performed:
User Side Latency –> 10 ms Passed (5 trials timed/slomo camera)
Transmission Latency –> 15 ms Passed (5 trials timed/slomo camera)
Rover Side Latency –> 10 ms Passed (5 trials timed/slomo camera)
Lifting Capabilities –> 500 grams Failed –> 850 Grams Passed with 7.4V
Driving Speed –> 0.24 m/s Passed (5 trials measuring drive time across 1 meter)
Lifting time –> 8.4 seconds (calculated by timing lift across 70 trials)
Detection Accuracy –> 64% ish (calculated by 45 successful trials across 70)
Battery Life –> 1.25 hours of capacity (measured how much time we were able to perform tasks like driving/pickup)
Item Detection Range –> 33 cm (placed objects varying distances and found the maximum bound)

Hayden’s Status Report for 4/27/24

This week my workload was divided into three different categories: the first was finishing the final presentation and making sure our metrics for testing were presentable. I spent most of Sunday working on touching up the presentation and helping Varun prepare for presenting. The rest of the week I spent assembling the new pcb as well as the monitor setup for the user side. I also spent time working with Nathan researching how to pipeline the camera feedback effectively; we have made significant progress and I have no doubt it will be done by Wednesday. The latter part of the week has been spent drafting up our poster design and planning for the deliverables for this next week. A lot of the work we have been doing is to make sure our project is presentable this coming week.

Image of the user side setup.

In order to meet our Tuesday deadline we have to finish our poster design; in order to meet our Wednesday deadline we need to get the camera feed working. I will be spending the next three days working closely with Nathan to make sure we get the camera feed transmitted as well as helping Varun wherever debugging and verification is necessary for the kinematics. No schedule changes need to be made and quite frankly we do not have the opportunity to make any.

Hayden’s Status Report for 4/20/24

These past two weeks I have focused on improving the user experience. I found a monitor and have connected it to the Raspberry Pi. Nathan and I are still trying to find a way to transmit the camera feed back to the monitor but we could just directly SSH into the rover RPi if it comes down to it. I also spent this week redoing the PCB to make it have better keys and I made it more like a controller. I also designed a user terminal that will hold the battery and the Rpi/monitor and allow the user to adjust the angle. On top of this I have spent countless hours with Varun rebuilding the rover and testing it to make sure it still works every time we redo the electronics. I also have crafted some beautiful slides for our final presentation on Monday.
Here are some photos of the new PCB design, the current setup and the CAD for the new terminal I have designed.

We are very much on track to finish things; I do not need to modify the timeline at all, I just need to focus and get the deliverables done.
In the next week I will keep helping Varun calibrate the rover as I have been doing and figure out how to get the video feedback.

As I’ve been designing my side of the project I have had to improve my physical CAD skills with Fusion 360 to be able to create a fully integrated design. I also found it necessary to learn about new libraries in Python and learn about serial and socket communication methods. I have spent a lot of time reading data sheets and library documentation to be able to get a thorough understanding of what is happening in our design and figuring out how to debug it. The learning strategy that has proved to be the most effective has been reading these documents and then trying to implement the concepts into our design and then use previous knowledge to debug.

Team Status Report for 4/6/24

This week we accomplished a lot; we completely finished the driving subsystem with the controller and we were able to start verification of this system. We had to revamp the driving because the motors were under powered and we also revamped the robotic arm to position the camera in a central location to simplify the task of alignment. These decisions to change the arm and the drive train was to mitigate the risk of time. The largest risk we have right now is that we are unsure if we will have enough time to properly verify and validate our design once we complete it. We also broke one of the servos and luckily we have a spare but frying another one would be a major setback when we have to wait for delivery. We updated the Gantt chart last week and we are feeling much more confident about our timeline; as we have been working some things have become complex and others simpler than we expected.

Verification has occurred for driving and controlling and we will begin verification for the arm this week. As far as full system validation we plan on driving the rover this week and trying to pickup items when we align the rover properly using our own vision. We will not be incorporating the camera just yet but we will be driving blindly to work on fine tuning the object detection. For validation of our proposed latency, as Hayden mentioned, we’ll be using a high frame rate camera to check how long signals take to go from button press to robot movement. So far, the movement has been pretty close to instantaneous, so we haven’t needed to worry about it too much. In terms of drive validation, we have validated our drive- the Rover moves in the fashion that we intended it to, and can connect from quite a distance and remain relatively seamless in operation. As Varun mentioned in his report, we’ll be verifying consistency of the arm subsystem by power cycling the rover and determining with a vertical marker if the Rover got to the correct Y and Z positions. After that, we’ll begin working to bring the separate systems together. Considering the simplification that the new arm brings, we should be pretty solid in terms of progress.

Biggest risk right now is the Servos breaking in testing, causing a large lead time to get new ones. The contingency plans are to switch to a smaller, more common, high-torque servo for the second stage in case this servo breaks. Quite a lot of changes were made to the overall system to better facilitate testing- however, the overall block diagram has not changed this week.

(HomeRover’s overarching redesign!)

Hayden’s Status Report 4/6/24

This week I spent four hours on Sunday debugging our communication protocol and establishing connection between the controller and the rover to allow driving to be demonstrated. After we achieved driving functionality and demonstrated I worked on rewiring and cleaning up the rover to make sure we will be able to fit everything on it. This week was heavily based on verification for me because I have completed the subsystem that I was in charge of. As far as verification I checked the latency of transmission between the two computers and found the latency was consistently less than 100ms which meets our design requirements (averaged about 15 ms, not sure if I measured properly but I count this as verified). I ended up putting a set delay/latency of 10 ms in the Python code just to make sure everything between the two systems was consistent; without this delay we had some interesting bugs.

As far as the latency of the direct wiring on the rover and in the controller I used the slowmo function of my iPhone 14 pro which has a frame rate of 240fps which allows us to detect latency to approximately 4ms. From this test I was able to confirm that the latency was below 20ms in both cases with the key press reaction being approximately 10ms (limited by the frame rate) and the rover motor reaction, which I ballparked by looking at the approximate time it started driving, to approximately 15ms. While I am not entirely convinced the measurements are the most accurate they are good enough for the design requirements we have outlined. I also scaled down the board size of the PCB and I am trying to source a Raspberry Pi 4 with greater RAM because that seems to be the bottleneck for the speed of the controller (I tried using different power sources, different WiFi connections and downloading different operating systems and the python code still was running too slow).

Given that the subsystem I was put in charge of ended up being much less involved than we initially expected I will be spending the rest of the time working on the arm kinematics with Varun and verifying the suction mechanism works as intended. We plan on verifying this system by lifting actual objects with the suction and making sure the servos and 3D printed components are strong enough to hold up to the weight of an iPad. I do not foresee any necessary schedule changes since we updated our Gantt chart and have cut time on certain tasks. I found a Raspberry Pi monitor I think will be perfect for our controller and is in our price range; I will place the order this week.

In the next week I will work with Varun to finalize arm movement and suction and begin system validation tests such as driving to a location and pressing the pickup button.

Hayden’s Status Report 3/30/24

This week I accomplished a lot; I was able to interpret the serial USB data on my laptop and convert it into inputs for python code. This is going to make the project a lot easier from here on out now that we have access to the useful data we want to transmit. Unfortunately, the Raspberry Pi we requested is too slow because it only has 1 GB of RAM so we had to demonstrate the communication laptop to laptop. On Friday, Varun and I were able to get the motors moving and we worked on the electronics for the drive train; we also 3D printed a few more parts that are necessary for our rover. I am confident that we will be able to display full driving capabilities for the interim demo on Monday which was our goal. Overall, I am in a significantly better place than I was at this time last week; I do not think I need to make any further changes to my required tasks and timeline.

In the next week I will be completing the full communication of the driving with the proper Raspberry Pis and have a prototype on the user side for entirely controlling the system. After I complete this I will be able look into monitors and hopefully assess the Raspberry Pi to make sure it has enough processing power to relay video information while keeping the latency low.

Below is a video of two laptops communicating using the test PCB.
VIDEO LINK

Here are some screenshots of the current state of the basic code.
Changes to the Arduino Code

Transmitter Side/User Side Code

Receiver/Server Side Code

Team Status Report 3/23/24

As of right now the biggest risk that could jeopardize our project is the integration of the control system on the rover. We officially have a rover built but we need to integrate the electronics onto the rover which is going to require a significant amount of work. Our current contingency plan is to put our heads down and write code for the next week so we will have a working system prior to the interim demo. We don’t need to make any changes at the moment because we have 3 weeks of slack time built into our project timeline and with this we have two more weeks to get a semi-working integration of the rover then 3 weeks to improve the accuracy of our model. We see the claw kinematics and the object detection as the one thing that we are going to need to tune the most and we believe that three weeks is adequate time to achieve this to a reasonable degree.

There were no changes made to the overall design of the model, just some changes while fabricating that were planned. We added a slot that allows for the adjustment of the deadshaft wheel in the front, so our belts remain tightened.

The Rover in its non-electronic-burdened form!

Hayden’s Status Report 3/23/24

This week I received the PCB and debugged it and everything seems like it will work in our context. We do not like the buttons we chose so our final design will use a different footprint for buttons. I also figured out we need to use an Arduino Nano ESP32 rather than an Arduino Nano Every; this is because of the USB protocol and wanting to use this for the python code I will be writing on the user side. I also made the decision to write the code in Python on the user side because it will be relatively basic and has a keyboard interrupt library.

We need to simplify some of our stuff because we are about a week and a half behind as of right now and I decided that simplifying the code for sending signals to the rover is going to help us make up some time. We have also finished fabricating all the necessary parts for the drivetrain and we are currently assembling the rover and should have it complete as soon as we receive the wheels.

Below is a video of the PCB working with the serial monitor as well as a photo of the PCB. Sorry about the focus on the camera I don’t have a tripod to hold it. To see photos of the rover assembly see Varun’s post; however I also attached some of the print files.

Video of the PCB


Photo showing the USB setup of the PCB


Photo showing the print for the dead shaft mounting bracket and the live shaft gears.

This week I will be cutting out the washers, finalizing the rover construction and writing python code for the user side that will transmit from one Raspberry Pi to another. I also need to make a decision what language I will be writing the driving code in that will meet our design requirements for response time. I will order the second Raspberry Pi as well as a monitor so I can finalize the controller before the interim demo.

Hayden’s Status Report 3/16/24

This week I made a lot of progress. I spent Friday helping Varun fabricate parts for the robot arm. We should be able to complete the drive train parts in the next few days. I also finished the PCB design and will be able to order it ASAP once I confirm the parts are available on the website. I got a breadboard and tested my code from last week and it works; now that the code works the PCB was designed to work with this code. After we finish fabricating the rover in the next week we will be able to work on the kinematics; I have finished my research for the driving kinematics and I am currently looking into Wi-Fi communication between RPis so I can get that up and running after the rover is built.

Attached are some screenshots of the PCB and the code working for the controller:

This is the breadboard I used to confirm the design.

We are still behind on fabricating the rover, but once we have it created I believe it will be much easier for us to write meaningful code for the kinematics and debug it. We are on track to have a moving rover by the interim demo.

In order for things to be on track I need to purchase the drive train components by Wednesday and have all the other components 3D printed by then as well. I will also order the PCB ASAP because it might take a while to ship. I also need to confirm with other members of the group that we have purchased/acquired the RPis and the monitor to make sure we can get the controller side complete in the next two weeks.

Hayden’s Status Report 3/09/24

These past two weeks I’ve spent the majority of my time verifying the design and touching up the CAD so we will be able to hit the ground running after Spring Break with fabrication of our rover. I spent probably about 8 hours alone confirming our design and finding sources for our design proposal report. As far as progress, I have not been able to work on the physical fabrication our experimentation parts because I was ill the week prior to Spring Break and then I have been out of town. However, while working on our design report submission I confirmed the ability of our design to drive, lift items properly, and receive data from the encoder on the servos at a high enough rate to have the amount of control we would like.

Additionally, I finally had the time to write some Arduino code and I was able to get the analog button presses to translate to outputs from the Arduino. Here is the basic code I was able to write with the help of one of our design sources.

Looking at the schedule I am pretty much on task as far as design; nevertheless, I am very far behind as far as fabrication. This week Varun and I plan on using the water jet to create our bottom plate and we will be able to keep 3D printing components. Once, we order the final components of the drive train we will be able to assemble the entire rover and the only part we will have left is integration. We were very optimistic in believing that we could fabricate the entire rover before break but now that our design is set in stone I believe we will be able to get caught up in the next two weeks. Kinematics is still in the works and I need to put a lot more effort into the coding aspect of the project now that the CAD is finalized. This next week I will finish the entirety of the 3D printed drive train modules and I will finalize a PCB so I can order one and begin debugging ASAP.