Category: Lahari’s Status Reports

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.

This week in class we tweaked the computer vision and worked through our propulsion issues. The later part of the week we finalized the design for the robot and did some fabrication. On Monday, we went out to test the propulsion with the fully charged battery added thrust. These changes seemed to make all the difference and our device was able to move a sizeable distance based on the photos attached. There was a some mid-air rotation so this will be the focus going into next week.

We also did a test to compare the Raspberry Pi (fisheye) camera and the Logitech webcam to see which was better for detection at different lateral distances. With the large circle (2-meter diameter) I printed this week, there was 0% detection with the Pi camera and about 60% detection on the Webcam on average. We will be moving forward with the webcam. We also tested detection rates and frame rate against resolution and found 480p to be optimal.

From Thursday onwards we made CAD models and fabricated the final design in TechSpark. Vikram made the designs for the walls and base of the device, while I designed the lid and added some hardware cutouts using SolidWorks. We decided to use Acrylic, which I laser cut on Saturday.

 

This week we focused on our propulsion system as a team. We added weights to the inside of the device, to combat the swinging problems we faced before. The weights were successful in removing swing, but the insufficient lateral movement from our propellers was still a problem. Vikram suggested that the problem was that the connectors between the ESC and the motors were too thin to handle the current. While he made new connectors, Daniel and I created a new thrust testing apparatus at TechSpark. We went for a new design that we saw online, consisting of a pillar, with the propeller at the top. This would allow airflow which is important, so the propulsion is not impeded. We were able to generate 70 grams more with the thicker wires.

Since the camera to motion pipeline seemed to work in the demo setup, it was important that we also tested the CV in the actual testing setting. So we headed to the Pausch bridge to see the camera feed and detection. We tried to change the thresholds and parameters around, but found that the 1m target we have was miniscule because of the fisheye lens. The fisheye lens does not seem optimal for our use case namely, it distorts shapes the further they are from the center of the frame and downsizes shapes that closer to the center. It likely that a equirectangular camera will work just fine for our project, because the field of view from 43′ height can easily cover a 3 meter radius. Keeping with the fisheye lens, we could try a software algorithm to correct fisheye to equirectangular. Or more simply, we could enlarge the center of the frame, discarding data on the edges of the frame, because this is the only data we are concerned with. A backup plan is to use a USB webcam.

This week I improved my CV  target detection code and helped the group with more drop tests and some integration tasks. For integration we finally combined the propulsion system inside the housing with the PWM generation code that Daniel prepared and the CV code that I worked on. Daniel and I built an apparatus, pictured in the team report, to hang the device from for our demo. I uploaded my code to the Raspberry Pi, and adjusted it to the new camera. The fish eye lens was different from that of my laptop camera so I had to reduce the perfectness parameter and increase the maximum radius from 30 to 50 pixels to make it visible at the distance fit for our use case.

The earlier part of the week I spent making my CV more robust. I did a number of things to address problems like false circles and misattribution of the target. These changes have made the algorithm more robust, and affected the latency minimally. We measured about 6fps before and 5fps after.

1. I performed HoughCircles on a thresholded image instead of the original grayscale image. This means the image was changed to binary, with pixel values above a certain value turned to 255, and the rest to 0. Our target is black against white, so circles where the gradient is less will not be present in the thresholded image.
2. When the circle is lost, most likely due to motion blur, the last known location of the target is stored.
3. When there are multiple circles, we choose the one whose center is the least Euclidean distance from where the target was last found.

This week we had several tests to carry out. The first was a drop test, which we did again at the Pausch Bridge. This test would tell us whether we had eliminated spin by adjusting the parachutes, and the amount of thrust in our propellers. Last week, I made a few design changes to avoid the spinning that was happening during the drop. I shortened the straps of the parachute and attached them to the body with carabiners. In testing this proved successful by eliminating spin during the fall.  A picture of the parachute attachment now:

Initially, I tested the circle detection CV using a small image of a circle. Adjusting the parameters of the script, I found a range and line thickness of a circle that would make it visible. I scaled this up linearly to estimate we need a target diameter of at least 1 meter with 10cm thickness. I then printed the 1 meter circle piecewise on several letter size papers and stuck them to a board (pictured in team status report). We tested the large circle and found it was detected at a range fit to our use case, i.e. it was detectable close up and from 43 feet away (the height of the Pausch Bridge).

During the week of Oct 10-16 we set about creating the MVP for our project, while working on the design report. This version of the device was made of Foam core, because the material is lightweight and easy to modify. I helped fabricate the housing by tracing, cutting and gluing various pieces. We decided early on that three propellers was the minimum necessary to achieve omnidirectional movement, so we chose a hexagonal shape for the body. This would achieve less air resistance and a symmetrical design. The design had three arms to extend the propellers outwards, so that airflow would not be obstructed by hitting the sides of the housing. The goal was to see how far our propulsion system could move the object during a drop test. The week culminated in another drop test which was unsuccessful, because the device spun during most of the fall. 

 

Meanwhile, we performed final tests which helped us rule out directional antennas as our perception method. The new WiFi board had arrived, so we tested it out with the directional antenna. Daniel and I went out to the grassy area outside Hamerschlag to find at what distances and angles a phone hotspot would produce higher RSSI. The signal was stronger in a usable horizontal angle of about 30 degrees, but only within 20 feet. The range of the vertical angle where the phone could be detected was very narrow. Lastly, the back of the antenna also had some range where the signal was as strong as in the front. This meant the antennas were not practical for perception for much of our use case, it would not be possible to detect relative direction based on these antenna data. At the end of the week we decided to switch to computer vision instead of antennas for perception. 

 

During the week of Oct 17-23 we continued working on our device. I am now in charge of computer vision instead of signal processing because we have switched to cameras. We decided to use circle detection, so that the use case would remain simple. The user would only have to place a circle marker on the ground. I implemented a circle detection script in Python with OpenCV. The script converts the frame from a camera feed to black and white, applies median blur, then HoughCircles (from cv2 library). The result was the coordinates and radii of the circles in the image. Daniel and I integrated this code with the Raspberry Pi camera, and found that the detection was robust. What remains to be done is to find out the latency associated with the code, we may consider using C++ to remove some of it. We also want to go outside and see whether it works at a distance of about 40 feet and with different lighting conditions. I may have to adjust the parameters, such as circle radius and blur kernel, based on these tests.

This week I spent time working on the pretests and the design document. For the design document, according to feedback I adjusted the block diagram, because I forgot the motor controllers in the presentation. We did a drop test and a test of propeller thrust to conclude our pretest phase.

The drop test gave us an idea of the amount of time available for onboard computations and movement. The propeller test would verify the 1kg thrust metric from the product listing. We put together the parachute and the weight and headed to the Pausch Bridge, where I released the items from the top, while Vikram waited below to retrieve and ensure no passers by. Daniel filmed from the street exit on the fifth floor of the Gates Center. 

The propeller test was somewhat successful, though we had some problems with the PWM generator while getting started. All in all, we completed the tasks on our schedule that require our combined attention. My individual task during this week and going into next week involves digital filtering of the RSSI data we collected last week.

This week I helped with the slides for next week’s presentation and the pretests we conducted over the weekend. I created a block diagram using a third-party software and redid our Ghant chart in response to the feedback we received during proposals. I set out to be as specific as possible at this stage of the project, given that we have developed our device design more according to the specs of some of our parts. Over the weekend we integrated the directional antenna with the ESP32 board. We then took several measurements in the grassy area outside Hamerschlag Hall, to check the RSSI measurements.

We were unsatisfied with the direction finding algorithm we proposed earlier. The previous idea was to move in the direction of greatest RSSI by maximum value. After I researched the RSSI quantity further it is actually feasible to get the exact angle of the direction then vectorize that quantity among the three propellers we will have. This will add more precision to the programming portion of this project, with very little added computational complexity. These and other more descriptive tasks were determined this week, like the need for a digital filter. We plan to do more pretests in the coming week when our parachutes arrive.

This past week, our proposal presentation occurred on Wednesday, so I spent the first half of the week practicing. Mainly I familiarized myself with the slides and focused on explaining our visuals and calculations in an organized manner. Our group received feedback regarding the slides yesterday via Slack. Overall, some helpful questions were brought up both in the comments and in the Q/A portion of the presentation. For example, whether we were considering other steering systems and the tradeoffs associated with them. In turn, I am researching other methods of steering like compressed air, and how they would affect the device’s weight and robustness (against weather and other confounding variables).

After the proposal presentation we ordered some parts to try out. Namely, we ordered one directional antenna and a chip to control the signal reception on the antenna. We expect to be able to compute RSSI and find out the range of our directional antenna. Hopefully, these items will meet the needs of our perception task.

This week we have been preparing the proposal presentation for the upcoming week. In order to quantify the requirements of our project,  we have been researching current technology related to our topic and modelling the kinematics of our device in action. Personally, I have been editing the proposal slides and typing up the equations we used in LaTeX for readability. I also looked around for potential drop sites around campus in person and on Google Maps.