Skip to main content

Pre-flight Testing - Weight and Balance

So I've finally arrived at a time all aircraft engineers hope to get... Maiden flight. But I've had too many experiences where the maiden flight is all but over in a matter of seconds becauseI was too eager to "free the bird". The end result... A disgruntled soul wishing it had been more patient.

I've learnt my lesson (with my wife's mentoring) to be more methodical and pragmatic about my approach to the maiden flight. Since I don't have the luxury of wind tunnel testing of the wing and the airframe, the only reliable weapon in my arsenal was... Calculations. To be more specific, weight and balance calculations and measurements.

After using AutoCAD, a weight balance spreadsheet to calculate the estimated (emphasis on "estimated") center of gravity in relation to the wing mac (mean aerodynamic chord), measuring the actual cg will all electronics included was the next (and hopefully) final step.

It must be said that prior to this step I realised that packaging tape on the wing will not be enough for a 2.4m - 800g foam glider. Reinforcing with carbon tube over 85% of wing span should increase the rigidity of the wing. I had also reinforced the nose as the glide speed could reach 9m/s (36 km/h). Landing nose first at that would surely break the fuselage in half. I had made provision for a "tweeking" the c.g. by having a long enough battery bay (the battery weights about 1/4 of the total mass) to shift the c.g. quite drastically.

Based on some research including this intuitive document on weigh balance, it was quite clear that doing a hand toss launch for this size of glider was not a good idea. It was recommended that if the glider was powered,  rather use that option so you have more control while you try and find the optimum weight balance point for the plane for smooth flying at all air speeds.

So currently the c.g. sits at 30% (57mm) from the leading edge of the main wing. This should be a good starting point for the maiden flight (I so hope).

Comments

Popular posts from this blog

Setting up the Tarot T4-3D gimbal on the Pixhawk 2.4.8 with Specktrum dx6 Gen2 toggle switch

So i took the challenge of setting up the Tarot gimbal not just for inherent stable video footage but also the flexibility of controlling it from the radio control. However, I encountered quite a few challenges which made me aware that I'm not the one only in this battle . It's quite clear that the setup of the Tarot gimbal using its own software is completely different from how it's been described in the Ardupilot/Arducopter webpage and in mission Planner. In Mission Planner and it's associated site makes one believe that it should be done through software, only to realize that in actual fact the setup is more complex than that.  After two evenings of trying various combinations, I realized the getting the pixhawk Aux channels to communicate with the T4 gimbal requires the following steps: - The Pixhawk Pin9 (Aux1) needed to be activated to pass through user-chosen channel from the transmitter. For the Dx6 Gen2 it was the channel 6, which can assigned the

Matlab to C/C++ code development - Some learning points

Over the last few years, the engineers at the company have invested both their time and sleepless nights in formulating a process for the development of Machine learning algorithms that will satisfy real-time constraints with minimal RAM usage. This is quite a tall task as per default, that would force one to do their development directly in C language. Although that seems like the right choice, the downside is the direct correlation of the debugging time with algorithm complexity.  Such a time could have been rather used in optimizing the algorithm within the MATLAB environment which has excellent tools for the analysis, plotting and debugging. So it was decided to rather learn the Code generation process with the hope that future algorithm could be designed in a similar fashion without the hassle of the compiler-specific run-time issues. The development of this machine learning algorithm would eventually be implemented in a 32bit, 160Mhz speed, 260KB RAM microcontroller.

The hard climb of innovation

For the last couple of months, our design team has been hard at work at detail development of our drone concept which we hope to make public early 2021. These have been unprecedented times with so many changes within our company: people moving countries, stuck at airports, universities closing and transitioning to online classes and exams; all in the space of one year! Nevertheless, one of the fundamental challenges facing the drone industry in developing countries next year, is how to operate within an environment where shipping of critical parts (amongst other things) has been disrupted due to the covid-19 pandemic. If the most critical items (propellers, batteries, sensors, etc. ) of the system are also associated with the longest lead time, this has a significant impact on the operating cost and service coverage that can be achieved. Unfortunately, there's no easy way of solving this issue except if it was envisioned as part of the development process. But this is seldom the ca