Monthly Archives: April 2016

A new UAV design

Since my quad decided to run away from me I have to build a new one. I spent more than one year designing the previous one and it went through 4 major iterations which ended up with a light, strong and easy to build quad. But not a perfect one though.

There are 2 issues that bother me with my quad and all quads in general:

  1. They are hard to carry around. Their propellers are sticking out, their arms are large and they are sensitive.
  2. The propellers are exposed when flying which is dangerous for everyone (including for the the propellers themselves). I could build prop guards but they are heavy and make the quad even bigger

Lately I’ve been thinking how to improve on this for the new quad. The first issue can be improved by making a smaller or a foldable one quad. I tried in the past to make a foldable tricopter out of balsa (before I had a 3d printer) but it didn’t work out that well. It was either too flimsy or too heavy. A smaller quad is attractive but it reduces flight time significantly since not all components can be scaled linearly (such as the rpi).

While looking for alternative designs I came across this – a single ducted prop UAV. It’s an interesting idea to have all axes controlled with the servo elerons but I think it’s a bit too radical for me. I need something more practical – and I think I got it:

A ducted coaxial propeller UAV, with control surfaces for pitch/roll. Yaw is done using differential thrust. I’ll call it CUAV – Coaxial UAV

So, some specs:

  • 2x 10×4.5 inches CF propeller
  • 2x 2209 980kv motors. They max out at ~900 grams of thrust for a total of 1800.
  • 2x 20 amp ESC. Not decided which one, not important for now
  • 2x digital 9g servos with metal gears for the control surfaces
  • 6mm 3k CF tubes for the structure with ABS 3D printed parts
  • Raspberry PI 3 brain, wifi video link, RFM22B telemetry and control link

I made a schematic as well:


The motors are arranged with the props in the center, pointing towards one another to protect them. The ‘chassis’ is made from the motor mounts – 2 identical pieces (one for each motor) with 4 CF arms, connected on the outside.

The weight should be around 640 grams, with a diameter of ~30cm and a height of ~14cm.

The advantage of this design is that it’s pretty easy to carry – the sensitive parts are protected by the duct, and the props should not hit anything even in the case of a crash. Also I think it will be more efficient that the last quad due to having only 2 motors and way bigger props (10 vs 7 inches)

The challenges will be:

  1. To design the chassis to be stiff and light.
  2. To arrange the components – especially the RPI – so that it doesn’t block the airflow. I think the battery and GPS will be on top and the RPI + camera on one side of the duct.
  3. To write a new motor mixer that controls the servos depending on the desired torque. The trick here is that the torque depends on both the angle of the control surface but also the motor thrust (how much air flows on top of it)

Since I first have to make a new GS, this will have to wait a while. Hopefully by the time I start putting it together the RPI Foundation will have released a new camera module and a RPI 3 Model A…




Node Definition

As I mentioned in my previous post I’m designing a domain specific language to define the node properties. So far it looks like this:

import "UAV_Config.def"

namespace silk

struct Multirotor_Config : public UAV_Config
    struct Motor
        vec3f position = {0, 0, 0};
        bool clockwise = false;

    string name;
    float mass = 1.f : [ ui_name = "Mass (Kg)", min = 0.f ];
    float height = 0.5f : [ ui_name = "Height (m)", min = 0.f ];
    float radius = 0.5f : [ ui_name = "Radius (m)", min = 0.f ];
    float motor_thrust = 1.f : [ ui_name = "Motor Thrust (N)", min = 0.f ];
    float motor_z_thrust = 1.f : [ ui_name = "Motor Z Torque (Nm)", min = 0.f ];
    float motor_acceleration = 10.f : [ ui_name = "Motor Acceleration (N/s)", min = 0.f ];
    float motor_deceleration = 10.f : [ ui_name = "Motor Deceleration (N/s)", min = 0.f ];
    vector<Motor> motors : [ ui_name = "Motors" ];


It looks a lot like C++ but allows some extra attributes on types and members, like ui_name to have a nicer name displayed in the editor, a min/max value for numeric types, the number of decimals for floating points etc.

The grammar is done with flex/bison and it will actually be a full typesystem that I will use to generate serialization/deserialization code offline and to create UIs online in the GS.

The language will support:

  • namespaces, needed to be able to generate the code in the correct namespace in C++ and to separate the types properly
  • basic types, like ints, floats but also uint8_t and friends
  • structs and classes together with inheritance.
  • templated types like vectors.
  • math types like vec2/3/4, quat and matrices
  • initializer lists for vec3/4 etc
  • custom attributes
  • imports

The compiler will take a file and output a typesystem that contains all the types defined in the file. These types will have reflection so they can be traversed. From this typesystem I can generate the C++ code for the brain – the serialization/deserialization to binary and json – and I can generate UI widgets in the GS as well.

I’m still struggling with the grammar definition but over this weekend I will get it done.

I have to admit – doing a domain specific language and a typesystem is actually very satisfying and challenging. I wish C++ would help a bit more with common things like reflection and such. I even considered moving everything to rust or go but then I’ll have another problem – QT and other library bindings…