Tag Archives: quad

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…





Multirotor diagram

The new GS node editor is progressing nicely and everything seems to fit. I have data visualization for most types of streams with scopes and FFTs and yesterday I added a map widget to visualize the GPS ECEF location.

On the silkopter brain side I kept having a weird feeling that something is not right, that I cannot model everything with nodes and streams. Since I tend to obsess about finding the correct paradigm to modeling a certain process, I started drawing multirotor diagrams to see if/where I hit a road block. After 6 tries I got this:

(excuse the quality, I got tired of drawing on my galaxy note 4 after the 3rd diagram and went back to paper)


I’ll start from the end – the PIGPIO sink. This takes a PWM stream from the Throttle To PWM node which does exactly what the name says – converts a throttle stream into a PWM stream.

The Throttle stream comes from the motor mixer which uses data from the Multirotor Model Data node (top cloud) to convert a Torque stream and a Force stream into throttle values for each motor. This conversion can be done easily for a certain combination of motors + propellers. It doesn’t have to be very accurate as there are some PIDs before this to compensate.

The Torque stream is calculated by the AV Model node (renamed now to Rate Model) that basically combines a rate PID + a feed forward model using again the top cloudy model data. It takes as inputs an angular velocity stream from the gyro and another angular velocity target stream from the Stability Model and tries to match them. The corrections represent the Torque stream.

The Stability Model node is responsible for matching a given Reference Frame (from the AHRS node) with a target ref frame from the Pilot or Assisted Model Node. The output of the Stability Model Node goes into the Rate Model Node.

The Assisted Model Node is responsible for matching a stream of velocities from the GPS with a target velocity from the Pilot. The velocities include both horizontal and vertical (altitude) components. It’s used to model a very intuitive control scheme – move left at 1m/s, or climb at 2m/s. Its outputs are a ref frame stream for the Stability Model (which will try to match it) and an up force stream fed into the Motor Mixer Node.

The Pilot Node interprets RC inputs (not shown in the diagram) and outputs either a ref frame + up force stream when using rate/stab controls, or a velocity stream when using an assisted control scheme.

So going top-down now :

– The Pilot tells reads RC commands and outputs either low-level rotation+vertical force data or high-level velocity data

– The Assisted Model reads velocity data and tries to match those inputs by changing the orientation and altitude of the quad

– The Stability Model reads orientation data and tries to match it by rotating the quad. It uses a stab PID to do this (until I have a good FF model).

– The Rate Model reads rotation speed and tries to match it by outputting torques. It uses the quad geometry and weight + rotational inertia of the motors + props to figure out how much torque to apply to rotate with a certain speed. Small corrections are done with a rate PID

– The Motor Mixer reads torques and figures out what throttle each motor should have based on the geometry of the quad and power train.

So far this looks like it should work.