WATCH WING

Get oriented — understand the BIR program structure and meet the team.

What we did

• Sat in a circle for an introductory briefing on the project and program expectations
• Talk by Sidharth on open source projects - what they are, why they matter, and how to contribute to/use them responsibly
• Discussed overall direction for the Watchwing UAV project at a high level

Problems and blockers

• None yet — orientation week

Decisions

• Project name settled: Watchwing
• General scope confirmed: autonomous waypoint-guided fixed-wing UAV using ArduPilot

Next week

• Prepare and deliver formal project presentation
• Start narrowing down system architecture (flight controller, sensors, firmware choice)

Goal this week: Formally present the Watchwing project to the group and finalize the technical direction.

What we did

This week, we formally presented the Watchwing project to the group. We explained the main goals of the project, its scope, and the overall architecture that we were planning to use. We also presented the concept of the autonomous UAV, which is a fixed-wing drone designed to fly through a predefined route using a set of GPS waypoints.

We explained how the main change-detection system would work. The UAV will first fly through a fixed route containing a number of GPS waypoints, for example, five points. At each waypoint, the camera will be triggered using GPS to capture an image. We called this first set of images Round A. After some time, the UAV will fly the same route again and capture images at the same five waypoints, which we called Round B. The images from both flights will then be compared with each other, such as Point 1 from Round A with Point 1 from Round B, Point 2 with Point 2, and so on. If a significant difference is found between two corresponding images, that area can be flagged as a possible change.

We also discussed the different components that would be required to make the system work. The planned system would use a Pixhawk flight controller running ArduPilot's ArduPlane firmware, along with GPS and IMU sensors for navigation and orientation. We planned to use Mission Planner as the ground-control software, with MAVLink being used for communication between the ground station and the UAV.

During the discussion, we also decided to record a continuous video throughout the entire flight. This video would be saved onto an onboard SD card so that the complete flight could be manually inspected later if required. This would give us an additional source of information apart from the individual images captured at the waypoints.

However, while discussing the system in more detail, we came across a few problems that needed to be solved. We were still unsure about which specific flight controller hardware would be the most suitable for our UAV. Another important problem was figuring out how accurately the UAV could return to the exact same position and orientation at each waypoint during different flights. Since our change-detection method depends on comparing images taken from the same locations, even a small difference in the position or orientation of the UAV could affect the accuracy of the image comparison.

After discussing these issues, we finalized the basic approach for the change-detection system. We decided to use GPS-triggered images captured at fixed waypoints and compare the corresponding images from different flight rounds. Along with this, we would maintain a continuous video recording of the flight on the onboard SD card for manual inspection. With the basic technical direction decided, we were ready to move on to the physical construction of the UAV.

Problems and blockers

One of the main problems we faced this week was deciding between the different flight controller hardware options. We also needed to understand how accurately the UAV could return to the same position and maintain the same orientation at each waypoint during repeated flights. This is important because the images captured during different rounds need to be sufficiently similar in terms of viewpoint for the change-detection system to work reliably.

Decisions

We decided to use a GPS-triggered image capture system, where the UAV captures images at predefined waypoints during each flight. The images from different rounds will then be compared point-to-point to identify possible changes in the monitored area. We also decided to record a continuous video of the entire flight and store it on the onboard SD card so that the flight can be manually reviewed whenever necessary.

Next week

Start with the body of UAV

Next week, we will start working on the body of the UAV. We will begin developing the physical airframe of the fixed-wing aircraft and work on the initial design and construction.

Goal this week: Build the airframe of the UAV, including the wings, fuselage, and tail, using foam board.

What we did

This week, we started building the physical airframe of the Watchwing UAV. We began with the wings and spent around three days cutting and assembling the wing panels. Once the wings were completed, we weighed them and found that the complete wing set weighed around 300 g, while the total wing area was approximately 1250 cm².

We then compared these values with the design targets we had calculated earlier. When we checked the expected component weight and the approximately 900 g of motor thrust available from our selected motor, we realized that both the wing area and the wing weight were significantly different from what we needed. This made us go back and check our calculations as well as the material that we had used to build the wings.

While investigating the problem, we discovered that we had made a material mistake. The foam board we had purchased was actually PVC foam board, commonly called Sunboard, which is mainly used locally for making signs and hoardings. We had assumed that it was similar to the lightweight hobby foam used for RC aircraft, such as Depron or EPP, but it was much heavier. From the finished wing itself, we calculated an areal density of approximately 0.24 g/cm², which is around eight times heavier than true Depron of a similar thickness. This explained why our wing had become so heavy.

We also cross-checked our design with a published reference aircraft using a similar 2212 motor class. The reference aircraft was around 640 mm long, had an approximately 810 mm wingspan, a flight weight of around 495 g, and used a four-channel, four-servo control setup. This comparison helped us confirm that our selected motor and servo configuration were reasonable, and that the main problem was with our wing sizing and construction material rather than the basic component selection.

After identifying the problem, we went back to the calculations and redesigned the wing from the beginning. We decided on a 950 mm wingspan and targeted a wing loading of approximately 40 g/dm². We chose this value as a reasonable middle ground: it would keep the aircraft relatively light and simple to build while still providing a comfortable safety margin compared with higher wing loadings.

We then calculated the required wing area assuming a target total aircraft weight of around 600 g. At a wing loading of 40 g/dm², we would need approximately 1500 cm² of wing area. With a wingspan of 950 mm, this gives a chord of roughly 16 cm. At this weight range, our existing motor would provide a thrust-to-weight ratio of approximately 1.5, giving us a good amount of available thrust.

Problems and blockers

The biggest problem we encountered this week was that our first wing design turned out to be both too small and too heavy. The wing had an area of only around 1250 cm² while weighing approximately 300 g. The main reason for this was the incorrect material we had used.

With the original wing dimensions and material, the calculated wing loading was approximately 84.6 g/dm², which was much higher than our desired range. The estimated stall speed was also around 50 km/h, which was too high for the type of aircraft we were trying to build.

Another problem was that the term "foam board" turned out to be quite ambiguous when sourcing the material locally. PVC foam sheets used for signage and lightweight hobby foams such as Depron or EPP can be sold under similar descriptions, even though their densities are very different. Because of this, we ended up purchasing the wrong material for the aircraft.

Decisions

After going through the calculations and identifying the material problem, we decided to completely rebuild the wings rather than trying to extend or modify the existing ones. This time, we will source proper Depron or suitable EPP foam before starting the new build.

We finalized the main structural targets for the new wing. The wingspan will be 950 mm, with a chord of approximately 16 cm, giving us a total wing area of around 1500 cm². We are targeting a wing loading of approximately 40 g/dm² and using 600 g as the estimated all-up weight, giving us some additional safety margin over the bare component weight. At this loading, the estimated stall speed is approximately 34.5 km/h, which is considerably lower than our original design.

We also decided to rebuild the tail surfaces according to the new wing size. The horizontal stabilizer will be approximately 220–300 cm², while the vertical fin and rudder will be approximately 130–150 cm². The fuselage length can remain relatively close to the original design, around 640–680 mm, since our main sizing problem was with the wing rather than the fuselage.

Before purchasing the new foam, we also decided to verify the material properly. We will check the cross-section of the foam and weigh a sample piece to estimate its density before buying an entire sheet. This should prevent us from repeating the same material mistake.

Next week

Next week, we will source the correct Depron/EPP foam and begin rebuilding the wings, fuselage, and tail using the new dimensions. The new wings will be cut to a 950 mm span and approximately 16 cm chord, while the horizontal stabilizer and vertical fin/rudder will be resized according to the new wing area.

Once the new airframe is assembled, we will weigh the complete aircraft and check whether the actual weight is close to our 600 g target. We will then recalculate the actual wing loading and thrust-to-weight ratio using the measured weight before moving forward with the rest of the UAV build.

Links

• Reference for build: (https://www.youtube.com/watch?v=LzZ4Oqk_J1Y)
• Photos:

Goal this week: Get a suitable body material and a reliable cutting method ready so that construction of the UAV airframe could finally proceed.

What we did

This week, we focused mainly on finding a suitable material for the UAV body and figuring out a practical way to cut the airfoil and body components. We first tested Sunboard (PVC foam), which we had previously used, but rejected it because it was too thick and dense for our aircraft and would add too much weight to the final airframe.

We then tried Styrofoam (EPS) as another possible material. Although it was lightweight, we found that it was not firm enough for our requirements. When we tried cutting it with a blade, the material crumbled easily and did not maintain enough rigidity, making it unsuitable for building the airframe.

After testing the different materials, we decided to use Thermocol (low-density EPS) instead. It was considerably lighter while still providing enough rigidity for the structure. However, we quickly realized that cutting it accurately with a normal blade would be difficult, so we decided to use a hot-wire cutter instead.

We finalized the CAD design for the Clark-Y airfoil and exported the required STL file to create the cutting template. Since a proper nichrome wire was not available locally, we decided to experiment with gear cable wire as a substitute. We then built our own DIY hot-wire foam cutter from scratch using the available materials.

Before trying to cut the actual foam, we connected the cutter to a variable DC power supply and tested it at around 16 V and 3.5 A. The wire heated up properly, confirming that the basic setup was working. However, the wire initially had problems with sagging and kinking. We solved these issues by re-tensioning the wire and manually straightening it instead of replacing it.

By the end of the week, the material and cutting setup were finally ready. We had not yet started cutting the actual Thermocol body panels, but the hot-wire cutter had been successfully bench-tested and was ready for the next stage of construction.

Problems and blockers

One of the biggest problems we faced was the unavailability of Depron, which was our originally intended body material. Due to the ongoing war affecting its supply, we were unable to source it locally and had to look for alternative materials.

We also could not find proper nichrome wire locally for the hot-wire cutter. Because of this, we decided to experiment with gear cable wire as a substitute. Although it worked during the initial test, we still need to determine whether it will be durable enough for repeated cutting.

Another issue we faced was that the cutter wire initially sagged and had some natural kinks, which could have affected the accuracy of the airfoil cuts. We managed to correct this by re-tensioning the wire and manually straightening it.

The actual Thermocol cutting had also not started yet, so the performance of the cutter on the real material was still something we needed to verify.

Decisions

After testing the available materials, we decided to use Thermocol (EPS) as the main body material for the UAV.

We also finalized the Clark-Y airfoil for the wing and completed the CAD/STL template that would be used with the hot-wire cutter.

Since proper nichrome wire was not available, we decided to continue using gear cable wire as a temporary substitute, unless we were able to find a reliable source of nichrome wire.

With the material, airfoil design, and cutting method decided, we were finally ready to start constructing the actual airframe.

Next week

Next week, we will complete the body of the UAV, including the wings, fuselage, and tail, using the Thermocol and the hot-wire cutting setup. Once the panels are completed, we will weigh the finished airframe and check the actual weight against our target AUW and wing loading.

After completing the main body, we will also start working on the electronics, including the flight controller, servos, motor, ESC, GPS, and other components required for the UAV.

Links

Goal this week: Get a suitable body material sorted out and make progress on the airframe while starting the electronics work in parallel.

What we did

This week, we finally found a source for Thermocol nearby. Interestingly, we found it at a medical store and were able to get medicine boxes made of thermocol to continue working on the airframe. However, when we brought it back and checked the dimensions, we realized that the sheet was much thicker than what we actually needed for the wings.

We decided to try reducing the thickness ourselves using the hot-wire cutter we had built earlier. To keep the cut level and consistent, we planned to use a balsa wood template clamped on either side of the Thermocol and guide the hot wire along the templates. This seemed like a simple solution, but when we actually tried it, we ran into another unexpected problem. The hot wire remained in contact with the balsa template for too long in some places, causing the wood to scorch and burn.

The cutting itself also did not turn out as expected. The wire we were using still had some jagged sections left over from the earlier problems with the cutter, and this caused the Thermocol to come out with an uneven and rough surface instead of the clean, flat surface we needed for the wing.

Things became even more difficult when the gear cable wire we had been using as a substitute for nichrome wire finally snapped during the process. Since we did not have a replacement wire available, we could not continue experimenting with the cutter. At this point, with the balsa template getting damaged, the Thermocol cuts coming out uneven, and the cutting wire broken, it became clear that we were spending too much time trying to make the material and cutting setup work.

After considering the options, we decided that continuing with Thermocol was no longer practical. We therefore decided to order genuine Depron sheet instead. Although it would take approximately a week to arrive, using the correct material would save us from repeatedly trying to modify an unsuitable material and would give us a much better starting point for the final airframe.

Rather than letting the week of waiting become completely unproductive, we decided to start working on the electronics in parallel. This would allow us to continue making progress on the project while waiting for the Depron.

We also made an important change to the camera system this week. Based on Shan chettan's advice, we decided to replace the ESP32-CAM with a Raspberry Pi Camera. Since the Watchwing project depends heavily on comparing images from different flights, image quality is particularly important. The Raspberry Pi Camera provides advantages in areas such as resolution, low-light performance, and autofocus, making it a more suitable option for the image-comparison part of the project. We decided that making this change now would be much easier than building more of the system around the ESP32-CAM and changing it later.

Problems and blockers

The main problem this week was that the Thermocol we sourced was too thick, and our attempt to reduce its thickness using the hot-wire cutter did not work as planned. The balsa templates began to burn when the hot wire remained against them for too long, while the uneven sections of the cutting wire resulted in rough and inconsistent cuts.

The situation became more difficult when the gear cable wire snapped during the process. Since we did not have a spare wire available, we were unable to continue testing the cutter.

After several attempts, it became clear that trying to fix the existing setup further would take more time without guaranteeing a usable wing. We therefore decided to move to genuine Depron instead.

The Depron would take around one week to arrive, which meant that airframe construction would have to pause temporarily. However, we decided to use this waiting period to begin the electronics work rather than leaving the project idle.

Decisions

After the failed Thermocol cutting attempts, we decided to abandon Thermocol as the body material and order genuine Depron sheet instead. Although this meant waiting approximately a week for the material to arrive, we felt that using the correct material would be more reliable than continuing to modify the Thermocol ourselves.

We also decided to begin electronics bring-up in parallel while waiting for the Depron. This would allow us to work on the electrical and control systems independently of the physical airframe.

Another important decision was to switch the camera system from the ESP32-CAM to a Raspberry Pi Camera, following Shan chettan's advice. Since image quality will directly affect the round-to-round change-detection process, we decided that the better image quality and camera capabilities were worth making the change at this stage.

Next week

Next week, we will begin the Raspberry Pi bring-up, starting with flashing the operating system, setting up headless SSH access, installing picamera2, and testing image capture.

At the same time, we will begin bench-testing the RC transmitter, receiver, ESC, motor, and servos as a standalone system, without connecting them to the flight controller initially. This will allow us to verify each part of the control and propulsion system before integrating everything into the UAV.

Links

https://github.com/user-attachments/assets/4cb5d6a5-31f4-4e36-bd63-a17d4b966aa3

What we did

nothing much, got busy with coursework and exams

Goal this week: Get the Depron sheet, finalize the airframe design, and complete the main body of the UAV.

What we did

This week, the Depron sheet finally arrived. It was pre-cut to 5 mm thickness, which was exactly the type of material we had been looking for during the previous weeks. After all the problems we had faced with Sunboard and Thermocol, getting the correct material was a major step forward for the project.

With the material finally available, we decided to simplify our approach to the airframe design. Instead of continuing to derive our own wing span and chord dimensions, we decided to build the Flite Test Simple Scout according to its official plan. Its published specifications were already quite close to what we needed for Watchwing. The design has a 952 mm wingspan and a wing area of approximately 20.9 dm², with a published dry weight of around 425.2 g and an all-up weight of approximately 535.8 g. Its wing loading is around 25.6 g/dm², which was comfortably within the range we were looking for.

We also compared the Simple Scout with another Flite Test design, the Simple Storch, to see if it would be a better option for carrying our electronics and camera system. However, the Simple Storch had a much larger wingspan of approximately 1460 mm and an all-up weight of around 1005 g. This put it into a significantly larger and heavier class than what we had originally sized our A2212 1400KV motor and the rest of our system for. The Simple Scout therefore fit our requirements much better.

We also checked the Scout's expected weight against our motor. Our A2212 1400KV motor can produce approximately 900 g of thrust, which gives a thrust-to-weight ratio of roughly 1.68:1 at the Scout's published all-up weight. This gives us a comfortable amount of available thrust while still leaving some capacity for the additional electronics we need to carry, including the Pixhawk, GPS, and Raspberry Pi Camera.

Once the design was finalized, we started constructing the actual airframe. We traced the different components directly from the printed Simple Scout plans and began cutting the Depron for the wings, fuselage, and tail. This was the first time we were able to properly proceed with the airframe using the material and design we had settled on.

The timing of the build coincided with Onam, which meant that a significant portion of the week was taken up by family time, travel, and festival activities. Because of this, we did not have the same amount of continuous hands-on working time that we normally would. Instead, the construction had to be done in shorter periods whenever we had the opportunity.

Even with the limited working hours, we were able to make good use of the time available and successfully complete the main body of the UAV during the Onam period. After the delays and failed material experiments from the previous weeks, finally having a completed airframe was a significant milestone for the project.

Problems and blockers

The main limitation this week was the Onam vacation, which reduced the amount of time we could spend working on the UAV. Instead of having several uninterrupted days for construction, the work had to be done in shorter sessions between travel, family commitments, and other festival activities.

Despite this, we were still able to complete the main airframe within the available time.

Decisions

After comparing the available options, we finalized the stock Flite Test Simple Scout as our airframe. We decided to build it according to the official plan without custom scaling, since its dimensions, weight, and wing loading were already well suited to our requirements.

We also ruled out the Simple Storch because its larger wingspan and significantly higher all-up weight would have placed it in a heavier aircraft class than what our existing motor and electronics payload were designed around.

Next week

Next week, we will continue working on the electronics bring-up in parallel with the completed airframe. We will begin bench-testing the RC transmitter, receiver, ESC, motor, and servos to make sure the individual components are functioning correctly.

We will also start planning the modifications required inside the fuselage and electronics bay to accommodate the Pixhawk, GPS, Raspberry Pi, and camera system, while keeping the components secure and maintaining a suitable centre of gravity for the aircraft.

-Get the Pixhawk actually talking to the servos and motor correctly, and work through ArduPilot's setup and calibration process cleanly enough to start real bench testing, before anything gets mounted into the body.

What we did

So initially, what we did was read through the ArduPilot documentation to get a basic understanding of how everything fit together. We then uploaded the ArduPlane firmware onto the Pixhawk using Mission Planner's ground control software. After that, we went through the basic configuration steps — accelerometer and compass calibration — though only the internal compass could actually be calibrated, not the external one that comes with the GPS module. What we've come to understand is that in order to calibrate the external compass, it needs to be moved around together with the Pixhawk, both mounted on a single fixed unit, so we decided to leave that calibration for after both were attached to the main body.

We then moved on to radio calibration, and from there to the servo output section. The Pixhawk was powered through a 3300mAh 3S LiPo battery connected to the ESC, which was then wired into MAIN OUT channel 3, and that in turn powers the board. The remaining four servos were attached across the rest of channels 1 to 5.

https://github.com/user-attachments/assets/d9e56841-344a-40bb-9b3b-cab85152925d

In the Servo Output screen, all the servos moved correctly in response to radio input, except for throttle on channel 3. We went through pretty much every component individually to try and find the cause. We checked the RCMAP parameters — RCMAP_ROLL, RCMAP_PITCH, RCMAP_THROTTLE, RCMAP_YAW — and they were all sitting at their correct default values. We checked the servo function assignment again and confirmed channel 3 really was set to Throttle. We checked the physical wiring, checked that the receiver's channel order matched what Pixhawk expected, and confirmed on the transmitter's own screen that the throttle stick's output value was genuinely changing when we moved it, so the signal was leaving the transmitter correctly. It also showed up correctly in the radio calibration screen. This told us the input signal was being sent correctly, it just wasn't translating to an actual output. We decided to set that issue aside for the moment and moved on to ESC calibration.

https://github.com/user-attachments/assets/6a6e90e5-7b14-45b2-b108-5be83ae9cdb1

We tried Mission Planner's one-click "Calibrate ESCs" button, and it failed outright with an error saying to make sure our version was "AC3.3+." After looking into it, it seems this automated calibration flow is really built around ArduCopter's parameter set rather than ArduPlane, which is probably why it didn't work cleanly for a fixed-wing setup like ours. We switched to the manual ESC calibration method instead — throttle stick held all the way up, connect the battery, wait for the ESC to beep confirming it caught the top of the range, then throttle down to get the bottom of the range confirmed the same way. That part worked fine.

The actual explanation for the frozen throttle turned out to be arming, not anything wrong with the wiring or configuration at all. ArduPilot simply will not let throttle output do anything while the board is disarmed, and our pre-arm checks were failing — as far as we can tell, this was tied to the compass not being fully calibrated yet. Once we forcefully armed it through the Actions tab on the Data page in Mission Planner, we were able to get an actual output signal from throttle on channel 3.

Next week

Attach the components to the main body

Mount all the electronics into the body, get everything wired and confirmed working, and take it up for a first flight

What we did

We started mounting the components inside the body of the plane. First, we mounted the servos for both ailerons, the elevator, and the rudder. The hardest part here was bending the rods correctly to connect each servo to its control surface — for this, we 3D-printed servo horns so the rods could actually connect properly at both ends.

We then placed the battery, working out the center of gravity of the plane first, and mounted it in position using double-sided tape. The Pixhawk was mounted onto the side wall, and the radio receiver was placed inside the body as well. The GPS was kept exposed, using a gap we'd already left for it during the design stage. We also designed a firewall for mounting the motor, 3D-printed it, and fixed it to the front of the body using a glue gun.

Once all of that was in place, we made all the connections and started checking everything. The servos and motor were working fine, but we ran into an orientation issue — since the Pixhawk was mounted on the side wall rather than flat, we worked out that the correct orientation needed to be set as Yaw 180 and Roll 90. There was no preset option for this exact combination, so we had to figure out how to set up a custom orientation instead, which sorted the issue out.

https://github.com/user-attachments/assets/c18ed667-0398-4f2e-9c53-f4187ca28d09

After that came the bigger task of closing up the underside of the plane. We closed it using tape and added zip ties for extra security. We (Shan chettan lol)then checked the motor's thrust by arming it, and it gave a good amount of thrust, which had us fairly excited.

https://github.com/user-attachments/assets/7c95ffb8-d15e-42a9-8387-aaaa71229296

Looking back, that excitement is exactly where we went wrong — we went straight into our first flight attempt without simulating beforehand or properly checking the plane's control response first. In particular, we hadn't verified the elevator's orientation — pushing the stick down should have raised the elevator, but the direction was actually reversed. As soon as we moved the stick down in flight, the plane reacted the wrong way and crashed. The damage from this included a broken propeller and small cracks in the body.

https://github.com/user-attachments/assets/8a103069-e0ae-4b2f-8837-02de886d7a3d

Decisions

Fix the body and make subsequent flights

Do more flight tests

What we did

After the first crash, the firewall had broken - which we think was actually a good thing, since if it hadn't, that force wouldn't have been absorbed, and the damage would likely have been much worse. We then spent more time on the PicaSim flight simulator to build up more experience flying before trying again. We corrected the elevator direction properly and made sure all the controls were mapped in the right order this time.

We then took it out to the ground and flew it. It did fly, until it seemed headed straight for a powerline, and in that moment I panicked and banked the plane sharply to the left, which sent it crashing straight down.

https://github.com/user-attachments/assets/e85e026e-feed-42d0-a233-7aa0a86a7abd

There was some heavy damage, but we taped it up and somehow got it holding together again - though it didn't look like it could survive one more crash.

So we decided to make use of the GPS functionality as well, particularly Loiter mode, which makes the plane circle around a fixed point. While configuring the GPS, we came across the different flight modes available and realized there was an FBWA option - fly-by-wire stabilization - something we'd missed entirely earlier, and that might have given us better control and possibly avoided the earlier crashes altogether. On the transmitter, we mapped channel 5's topmost switch position to Manual, the middle position to FBWA, and the lowest position to Loiter. We then found a bigger, more open ground to give ourselves a smoother flying experience.

We flew it in Manual mode first, and the plane was climbing higher than expected when I tried switching it to FBWA - but I think the switch accidentally went one position too far, into Loiter instead. Around the same time, I also pulled the throttle down, whether out of instinct or in reaction to how fast it was climbing, it's honestly hard to say in hindsight. Between the mode ending up on Loiter and the throttle being cut, the plane went down and crashed straight into a powerline, damaging the body beyond repair.

https://github.com/user-attachments/assets/d0688072-a5b2-436c-84c3-b29f3b602719

https://github.com/user-attachments/assets/42bfe03f-b019-4237-b2a9-4cf66adad5d7

We didn't get the clean finish we were hoping for. But we did learn a lot, so not completely feeling bad I suppose. But yeah, that was the end of it.