drone in the sky

Not just another drone project

Weight management and how everything affects everything

The most important thing when it comes to multicopters is to do a lot of systems engineering. Every component affects multiple other components. There are just so many parameters that it is nearly impossible to design the optimal system without having custom parts (which I don’t). The only way is to find the best possible compromise.

Weight directly affects the most important attributes of a UAV. These are flight time, size, hazard/insurance and maximum possible payload. While a lot of things define the weight, weight in return also defines a lot of the components. You need to make sure that the motor-propeller & battery combination reaches its highest efficiency at the given load. A bigger battery will not always result in more flight time. Bigger batteries result in higher weight and thus cause more load on the motors. If the motor/propeller is not operating in the sweet spot it will draw much higher currents which dramatically reduces flight time.

To get an idea of how much the different components add to the total weight I made a chart showing weights of my first calculations. This must be the first step in development! Note: Some of the weights are estimated (plastics, screws).

To get the weight approximation you need to have an idea about what components you want to use and how the frame should look like. So in the early stage, it is more like a “do it all at once” approach. Once you got that you start refining. This can take a lot of iterations till you get to a good result.

The above chart gives you some idea of what to expect when you want to build an action cam based drone. The weight will be around 1150 g if you try to keep it low. If you decide to use a retail frame the weight might be 200-500 g higher since those are a lot heavier.
The estimated 1200 g of overall weight will be the starting point for the following powertrain calculations.

6 thoughts on “Not just another drone project”

  1. Laurent says:

    I follow you for several months in your project DroneBridge having also long wanted to build a drone dedicated to the photo / video.
    To follow you on this project I ordered the following elements to build my drone.
    – Turnigy i6S radio with smartphone / tablet support.
    – Omnibus F4 Pro flight controller with barometric sensor
    – Ublox N8M GPS with Compass
    – Four 2312 980 Kv engines with 9450 propellers
    – Four controllers 30 A
    – Chassis S500 from Hobbyking
    – GoPro STORM32 gimbal
    – Two Raspberry Pi 3 B
    – Two ALFA AWUS036NHA (AR9271)

    What will you advise me as batteries? 3S? 4S? 5000 mAh / h?

    I did ground tests on flat ground of the DroneBridge link and the resiltat is of the order of 610 meters for the moment with the antennas Omni 3 db.
    When the drone will be in flight condition I could do the test ground / Air which should logically be much better. It should be tested with a circular polarization antenna side drone and a directional antenna ground. (and why not an antenna with motorized tracking in the future …)

    I keep you informed of my tests.


    1. cyber says:

      Cool project! Sadly I never really tested the range. Always kept on developing and trusting the guys from wifibroadcast that they are right with their numbers. But in air should def. improve range a lot! New tests from WifiBroadcast (low transmission bit rates I guess) show up to 7km of range!

      Do you have any data about power consumption of the motor-propeller combination? Google might find some user tests. Like how much amperes one motor draws runing on 3S/4S while providing 300g of lift etc.
      With that data and your overall weight of the drone you can sort of estimate what battery would perform best in your case.
      – Lets say your drone is 1300g -> 325g/motor to keep it in hover
      – Look up the amps or watts drawn at that load on 3S and see how long a 5200mAh 3S would last etc.

      From my experience I would say you are right to go for 5000+mAh. 3S batteries are lighter and give a bit more flight time in my case (at least on paper – did no tests with 4S). So maybe 3S is for you also.

  2. Laurent says:

    In fact I took the same technical specifications as the DJI Phantom 4 for engines and propellers. The Phantom 4 is also powered by a battery in 4S it seems to me.
    For the DroneBridge side, does lowering the Wifibroadcast transfer rate to increase the range affect the DroneBridge protocol such as latency at the RC level or telemetry?

    Best regards


    1. cyber says:

      If it is the same motors that DJI uses then 4S is the go to (as you said DJI uses 4S as well).
      The problem is that every motor type is different. KV and stuff does not allow to compare motors on matters of efficiency. Size, quality and number of magnets, diameters, spaces in between the parts, prop diameter, prop angle etc. determine the efficiency. But I’d say that you can’t be wrong by choosing any of the battery types (3S, 4S).

      DroneBridge RC, telemetry and status messages take up very little bandwidth compared to the video feed. So lowering the transmission rate should not affect any latency etc. It might become critical on the lowest bit rate settings. But I have not tested that.

  3. Marcus says:

    Great project, thanks for keeping us up to date!
    I actually wanted to post this on DroneBridge but the comments there seem to be closed.
    Looking at the hardware diagram I had a question: Wouldn’t the Raspberry Pi easily be capable of providing at least the same funcionality as the ESP32? In other words, allow for direct connection of an Android phone without an additional ground station? I am of course talking about a Raspberry Pi with Wifi.

    1. cyber says:

      Hi! thanks 🙂 I closed comments because of a vast amount of spammers.

      Yes, that would be possible. The advantage over the ESP would be that we can also send the video stream. I guess we could also have a higher range in case we hook up a high power WiFi card to the AirPi.
      In fact, that was the first working setup I had. Just a pure WiFi connection. I ditched it because of the advantages that come with WiFi adapters operating in monitor mode.
      The current implementation still contains some code from that time. All modules have a command line argument called “-m (mode)” that can be set to “w” for WiFi, however, it is not implemented at this point.
      At the moment I have no time to add it, but I think it would be a nice thing to have in the future.

Leave a Reply

Your email address will not be published. Required fields are marked *