Tag: status report

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.

This week, I helped the team do more tests in order to see if we could replicate the results we found last week regarding our solution of the swinging problem. We also finalized our choice of cameras after some range tests off the bridge, and began designing our final housing.

For the drop tests, we first lowered the total added weight through rocks to exactly 1 pound (it was 600g before, whereas ~450g/1lb is the actual weight of our payload). We also charged the battery fully and ran additional thrust tests using the scale. We found that at 100% power using 16 AWG wure, we were getting almost 700g of thrust, a marked improvement over previous week’s results.

For the actual drops, as usual, I held up the device by the parachutes as Lahari initiated the device. We first ran with 50% power to the motors and noticed a very minute movement. We then decided to change this to 75% and dropped an additional two times, noticing noticeable levels of movement in the direction of the motors. I also took pictures from the bridge looking down to document where the device landed, so we could compare to the no motor drop.

To try alternative cameras, I ordered an 120 degree camera from the ECE parts inventory to see if the smaller FOV would make the circle easier to detect. I tried setting it up with the Pi only to find that the one we had was for the Nvidia Jetson, so the Firmware was not compatible. I then helped Lahari and Vikram modify existing scripts we had in order to support a USB webcam (as the exiting PiCamera module only supported the CSI Pi Camera module). This involved modifying the code to use the generic OpenCV camera access functions, rather than PiCamera specific methods. After this was done, we went out to test this new webcam against the old 160 degree FOV camera.

 

We came up with a quick testing strategy where I would hold the device over the bridge, say the testing parameters out loud (resolution + camera type + lateral distance from target), and Lahari would record the screen and mic feed using OBS. Using a tape measure, I measured up to 4 meters away from the location of the target, with increments of 1 meter such that we measure the performance of each camera at each resolution at each distance away from the target center. Lahari and I started with the 160 FOV fish eye camera and noticed that it was not even picking up the target on the ground, even after we doubled its diameter to 2 meters (the fish eye effect made everything in the center of the frame super small). We decided to call of the further tests with the fisheye, and moved onto the Webcam. With the Webcam, the target was large and clear in the frame, and we were able to proceed with the entire suite of tests. (640 x 480 vs 1280 x 720, at 1, 2, 3 and 4 meters away from the center of the target).

Lastly, we brainstormed ideas together for a final housing. As we ended up choosing acrylic, Lahari and I worked together to quickly create DXF files for the hexagonal base of the device, as well as the rectangular side walls using Solidworks. Our next phase is to fully construct this housing, and test the device with the full camera to propulsion piepline.

This week, I helped the team prepare for and present our demo to the two groups on Monday and Wednesday, as well as work on modifications to the device to solve swinging problems in the air.

On Sunday before the demo, we worked together to fine tune the demo setup by testing what thrust to use, and how high up to tie the device to appropriately show off our system. Additionally, we ran various tests to see if the system performed as expected, as Vikram and I moved the circle under the device, and Lahari modified the detection code accordingly to improve detection. For the demo itself , I gave a brief overview of the main components of our project, then explained specifically my part (the vectorization algorithm), and how it fits into the overall data pipeline (my algorithm receives data from the CV subsystem, and passes it onto the arduino via UART).

 

After the demos, due to the low thrust we measured for each of our motors using the smaller props (~220g), I researched various thrust tests to see what other people were getting. I noticed people were getting easily over 800g using our motor with a 4S LiPo and 5 inch props (like us), so I suggested to the team that we should construct a proper motor thrust setup (motor attached to a raised platform, with a flipped propeller to generate thrust downwards onto a scale. Lahari and I found a wooden rod, and with the help of a friend, cut it to an appropriate size. I then measured the middle of a rectangular platform and glued the rod to it to give it a solid base. We then attached the motor to the top, and ran several tests. We found 330g of thrust with the 3S LiPo (the 4S was low battery), and 400g using thicker wires for the ESCs.

In order to solve the swinging problem we noticed in the air (which we attributed to lightness), we thought it would be beneficial to add weight to the device. I suggested we could use fish aquarium rocks (which I knew Lahari may have) as a stand in for the payload. We measured three 200g  bags of rocks, and Lahari and I cut a hexagonal insert such that we could put the bags at the bottom of the device, and cover them with this platform. After this, we tested  the device off the bridge (I dropped it, Lahari initiated it and Vikram caught it) and noticed the swinging no longer occurred, but minimal to no movement was observed. We then found that the 4S LiPo was low battery, causing the motors to slow down mid flight, so we charged it. Our next tests will have a fully charged battery, and 2 instead of 3 rock bags; we will then change thrust and weight accordingly to what we observed.

 

I also helped the team run detection tests for the circle off the Pausch bridge. I held the device off the side as Lahari viewed the camera feed on the laptop and made on the fly edits to the detection code. We found that the circle was too small to be detected in the thresh-holded image, so we printed a circle two times the size (2 meter diameter), and will be testing with that as soon as we construct it.

 

Lastly, I researched and ordered larger propellers (7 inches) in order to increase thrust further, incase we still cannot move after lowering the weight and using a fully charged battery.