Posted on

Team Status Report for 12/4/21

Over the past week we have been working on the two pending tasks on the schedule: final testing and housing. We laser cut the remainder of the pieces and attached them to the 3d printed arms and brackets we made before the break. The body is pretty sturdy and awaiting drop testing, but as a form of risk mitigation we still have our prototype. The new housing unit is completed (video) so the only other task in our schedule is to finish up testing. In today’s round of testing we had four trials:

Min: 1.27 m

Max: 2.84 m

Mean: 2.40 m

Median: 2.74

We have been making adjustments to the code as we go with our trials, like adjusting binary threshold and thrust from trial to trial. We have also been able to reduce the latency by removing a delay in the function that sends data to the Arduino via serial. The movement is much smoother after we made this change. Our goal for the next week to finish drop tests by Tuesday so we can switch focus to shooting our video and working on the final report.

Posted on

Lahari’s Status Report for 12/4/21

Over the past two weeks we continued to work on the final housing unit and did more drop tests. I laser cut the remainder of the pieces including the lid, and a few more of the wall pieces. I fully assembled the housing over the last few days, then we glued everything into place. Vikram and I soldered some new connectors for the new housing and we mounted a new set of motors to the arms. We plan to showcase this product instead of the prototype at the demos and in our video. We have been working on final testing as well over the last few weeks.

Before the presentation  we did several tests pertaining to our design choices. Namely, we collected data for tradeoffs related to camera lens, camera resolution, battery cell count, and propeller size. I redid the test of camera resolution against detection rate and frame rate as the results we had from the week previous were done under varying light conditions, the new results showed a more clear tradeoff between frame rate and detection rate. Since the presentation we have been working on final drop tests as we were unable to get enough trials in before the presentation. We completed 4 trials of drop testing today. The closest landing distance was around 1.25 meters. We have found testing to be pretty feasible at night as well, with a lower threshold value since the light from the bridge illuminates the target.

Posted on

Vikram’s Status Report for 12/4/2021

This week, I first worked on preparing for our final presentation. I practiced for the first few days of the week memorizing and rehearsing the slide deck and what I would say to make sure that the presentation went smoothly.

We also worked further on assembling our new housing out of 3D printed arms and acrylic body panels. We also installed a hinge for the top for easier access to the inside. We glued the bottom inside the hexagon and fixed the side panels with custom 120 degree brackets to form an even hexagon. The arms are bolted on, and the walls are tacked together with glue at the top. I also made the wiring adapters that go from the 2mm bullet connectors from the motors to the 3.5mm connectors for the ESCs.

Lastly, we performed about 7 drops with our system to characterize performance. While doing this, we noticed an issue with the ability to SSH into the raspberry pi above the drop zone because of wifi, so we amended our script to wait until it receives signal over UART from the Arduino to start the detection script. This way we run the python script while indoors and then when we hit the button to start the Arduino, it triggers the python script to start without needing to SSH in and run it directly. This helps our efficiency with performing drops. Additionally, we tested in a few different lighting conditions, ranging from bright sunny to very dark and with tuning our threshold, we were able to detect the target circle in both scenarios. A future possibility is to have a dynamic tuner that changes threshold based on amount of light or another metric. After some more testing, we will be looking to create our video and write up our testing data in the report.

Posted on

Daniel’s Status Report for 12/4/2021

At the beginning of this week, I mainly helped the team work on the final presentation. In addition to working together on deciding slide content and layout, I personally worked on data analysis to extract latency values of various parts of our system. We had previously recorded various slow motion videos in an attempt to measure latencies of core parts of our system; for example, to find the time from the Arduino sending a PWM value to the motor to actually seeing motor movement, we recorded a video with the motor in the frame, and an LED that would turn on when the PWM value was sent. These videos all included a stop watch in the frame to keep track of time. In order to extract the latency values for this, I imported the videos to iMovie and went frame by frame, writing down the two time stamps of when the LED turned on, and when the motor actually spun. The difference between these was the latency for this part of the system. I recorded these values on a Google Sheets and found the average of all the runs we did.

I then created a slide in the presentation to show where these latency values fit into the overall system, showing a block diagram of the major steps of the system, and the latencies between them. After this, I also helped the team record a quick demo video demonstrating the camera to propulsion pipeline.

Later that week, we started working on finalizing the laser cut and 3D printed housing. Vikram and I glued the walls to the floor on the base of the housing using hot glue, and I also soldered 16 AWG gauge 2 mm to 3.5 mm adapters for the motors to be able to connect them to the ESCs.

Lastly, we spent the end of the week testing our full system. As usual, I would hold the device and drop it as Lahari initiated it and Vikram caught it down below. Since this testing would be used in the final report, I took a picture from above after every drop, and recorded the distance the device was away from the target that Vikram measured. During our drops, we encountered an issue where the unstable WiFi connection on the Pausch bridge meant that SSHing into the Pi and running the CV script could not be done consistently, thereby lengthening the time for each drop as we had to wait for the Pi to reconnect to the WiFi. To fix this issue, we went back to the lab and I edited the Python script on the Pi to run once the Arduino sends a particular message to it over UART. This meant that the Pi’s CV portion of the script would only start once the button connected to the Arduino was pressed, thereby allowing us to stop relying on a stable SSH connection as we could run script while we had a WiFi connection, and the Pi would simply wait for the button press to begin. I also tried to make the script run automatically after the Pi booted up, such that we would never even have to SSH into the Pi; however, some issues regarding the version of Python the .bashrc file was using meant that our script could not run properly.

We dropped 7 times, and while wind was an issue at certain times, we managed to get our first drop within the target foam-core rectangle, around 50 inches from the center of the target. Additionally, as it got darker, detection got weaker. Lahari and I changed the threshold of the CV algorithm, allowing us to keep dropping in darker conditions.

We will continue testing the system in the coming week,  as well as record our final video.