SARA Drone

SARA, the Super Awesome Research Aircraft project, was my primary focus for about 1 year (Summer 2015-2016)

The initial goal was to create a relay aircraft for unmanned aerial vehicles. One aircraft takes off, then SARA takes off, creating a link to the other aircraft and ground control. Video up/downlink, control up/downlink, and telemetry up/downlink was the goal.

Just developing a flight system was the first goal. Instead of making a conventional quadcopter design, I decided to push the envelope a bit and try an experimental design.

With two tilt servos, on top and bottom, with motors mounted on them, the craft would vector thrust in the pitch and roll axes, and use variable speeds on the propellers to control yaw.

A whole lot of drawings were made, components chosen, weights added, avionics systems designed, all while learning exactly how to do each of these things.

An initial CAD model for integration was made:

Screenshot 2016-11-21 11.21.27.png

Then, a workbench was fabricated, tooling was set up, all while waiting for parts from all the online suppliers.

Once the parts arrived, I built an “iron bird”, without knowing any C/C++ programming, and only initial understanding of DC electricity.

Using many of the wonderful resources for Arduino programming, I quickly built a codebase for motor control within 3 days.img_7302

To test that the directions of the motors were indeed opposite, and to write the motor control algorithm, I mounted the motors on a free-spinning bearing to see it rotate back and forth with variations in motor torque (accelerations in motor angular speed).

img_7315

Control was done by an Arduino Uno ATMEGA 328.img_7375

The CAD model was translated into drawings for help in building the vehicle.img_7507

Motors were mounted to the tilt mechanisms, and those to the frame. The Frame was supplied by FliteTest.com, an awesome resource to the RC/Drone community.

img_7522

I built a special jig out of aluminum bar and birch wood so that I had a level working surface upon which to build the drone.

img_7527

Learning lessons of wiring and avionics harnesses was next! I took inspiration from Google searches of “wiring harness”. One big inspiration was Masten Space System’s avionics system:avionics-tri3

With that as inspiration, I did the best I could with the tools I had (male-male jumper wires)img_7608

With soldered joints to the power distribution board complete:img_7669

Final assembly took time, but came out very beautifully. I’m still quite proud of the initial aesthetics of the design.

img_7684_1

An initial CG test confirmed a good forward/aft center of gravity. Some corrections had to be made, particularly with a GoPro on the forward bar.

img_7699

Electrical integration of a second microcontroller was made. The reasoning for this second MCU, was that the Arduino in the middle was too task saturated to do attitude, heading, and altitude (AHRS) calculations while also providing control systems. The AHRS unit is the purple lit box in the bottom left. This unit also provided live telemetry to a ground station. This unit is the ReadyToFlyQuads FLIP 1.5. It uses an MPU6050, BMP180, and ATMEGA 328 for its duties.

img_7752

While electrical integration was easy, getting the main Arduino Uno to communicate at a high rate with the FLIP1.5 was a programming challenge (to say the least!!). 😀 I spent about 1 week working on selecting or writing a serial communication protocol to interface the boards. Lots of coffee. Lots of confusion. LOTS and I mean LOTS of LEARNING!

img_7841

I still look back on this time, and realize how much I learned about C & C++! From direct pin register manipulation in microcontrollers, to classes, structs, and programming concepts, this time cast everything electronic permanently into my brain!

I finally got the system working, using multiple bit-banging, interrupt-driven Serial protocol libraries. The celebratory picture:img_7875

Next step? FLIGHT TEST.


I decided to go with a tethered approach to avoid unintentional fly-away and crashing into the neighbor’s house.

The initial flight test goal was simply to tune the PID algorithms tied to the pitch and roll tilt mechanisms. Simple enough, right? Testing began in early August 2015.

img_7755

img_7760

img_7802

Unfortunately, the first attempt did not work. The propeller hit the paracord tether, aborting the test about 0.5 seconds after initiation.

The story of the next few weeks was: Think, Make, Test, Think Again

I wrote detailed flight test briefs to help prepare for the flights, and to test more scientifically / methodically.

img_8017

After months of testing, it became apparent that only an accurate kinematics & dynamics simulation would be able to diagnose the issue accurately, and solve it – if possible.

I began programming in multiple languages, trying their tools out.

I settled on MATLAB/Simulink to build a block-based kinematics & dynamics simulation of the vehicle.

After weeks of development, I came upon an important realization.

The vehicle was, unfortunately, inherently uncontrollable.

In the configuration of tilt mechanisms and motor rotation direction which was chosen, the combination of gyroscopic effects and thrust vector effects were exactly the most undesirable configuration.

To be more specific, we can take a hypothetical example case:

  • Pitch is -10 degrees.
  • Pitch tilt motor tilts +1 degrees to provide a thrust vector to rotate the vehicle back to 0 degrees.
    • While tilting to 1 degrees, the motor and propeller are spinning.
      • The (secondary) rotation of a (principally) rotating object about any axis other than its principal rotation axis causes gyroscopic precession about an axis perpendicular to its secondary rotational axis.
        • SO: This causes a gyroscopic precession effect, of, say : x Nm, about the rolling axis.
    • It turns out, the thrust vector effect scaled linearly with the gyroscopic effect. This meant a typical pitch tilt motor correction would actually create a torque about the 45 degree line between the pitch and roll axes.

In isolation, this is ok, meaning a torque at 45 degrees to the pitch and roll axes could still provide some pitch control, provided that the roll control torque was at -45 degrees to the pitch and roll axes. (ie. control axes are 90 degrees offset from each other)

The ultimate killer, was that this control isolation was not the case. The torques provided by either the top or bottom tilt motor rotating, effectively acted around an imaginary axis 45 degrees between the pitch and roll axes. There was no reasonable control.

Much later, I realized I could have rotated the bottom or top tilt fixtures by 90 degrees, as difficult (mechanically) as that would be. That would have solved the problem. I would have done this, but as you will see later, I realized that 2 motors was an inherently inefficiency design anyway!

Regardless, I tried to make a compromise, just to make my money spent worth it!

I implemented a system with 3 servos, each with a weight on the servo arm. This weight moved left/right and fore/aft, to shift the center of gravity and create a torque of the (now FIXED) motors about its new center of mass.

img_8365

This system worked very nicely, and would have worked perfectly, if issues with the latency inherent to the Arduino Uno to FLIP 1.5 did not uncover themselves. Essentially, AHRS data was coming in WAY too slowly, by a factor of about 100. Not having a direct link to the accelerometers and gyros turned out to be a curse, not a blessing.

I added another AHRS with a high data rate, but this system was not tuned well and responded very negatively to fast linear accelerations (interpreting them as angular accelerations). Additionally, calculations bogged down the Arduino UNO, increasing its loop time to unacceptably slow limits.

The added weight of all of these components lead to one final test flight, where motors were run at FULL THRUST, overloading the battery slightly, and still, takeoff was not possible.


At this time, I decided to take a big picture look at the project and its goals.

The primary goal for this project was for me to learn as much as possible about unmanned vehicle design, programming, control theory, and dynamics. I could always learn more about those topics, but I felt I had reached saturation in what this particular project could do for me.

I ran some rough calculations regarding multicopter configurations, to determine whether more motors was more efficient than less.

The answer?

datafigure1_sara_components_2kgstructural_1bat

As evidenced by the above graphs, the more motors the merrier! (above assumptions: 1 battery, 2kg structural weight)


Phase II

Learning my lesson to design & engineer every system in advance, I decided to go for a 30mins-60mins duration multicopter.

I designed a completely new design, an octocopter, costing about $2000 not including tooling:

3

Featuring a 10Ah battery, multiple flight computers, redundant sensors, optical flow sensors, ultrasonic sensors, fire sensors, a battery safety control system, and of course, 8 motors, this beast would be a completely autonomous vehicle.

The mission of the vehicle was the same as it had always been : airborne relay for consumer UAVs!

Looking at the cost, and its expected capabilities, I decided to take a look at airplanes (with wings) as well…

This analysis lead me very quickly to the realization that wings are great. The same amount of energy stored for a 1 hr flight of a multicopter can allow a well designed airplane to fly for 6 hours+. The wing makes the flying vehicle mind bogglingly more efficient! Sure, the physics of airplanes (aerodynamics) is a few orders of magnitude harder than the physics of multicopters (kinematics), but the benefits should be worth it!

Plus… Then I could learn to write my own flight simulator code, and predict the performance of an aircraft!

This lead me to kick off a new project, SARA V1.1, eventually called ICARUS, for the “Insanely Cool Airborne Relay Utilization System”.

For ICARUS details, check out that page!