Finding Nessie

Finding Nessie

A few months ago I travelled around the highlands with my trusty hexacopter and like any normal person excited about Scotland, I tried to find the most famous cryptid in the world. Nessie.

A cryptid is an animal or plant whose existence has been suggested but has not been discovered or documented by the scientific community.

The Loch Ness Monster

Loch Ness is the second largest lake in Scotland, it’s also very deep, reaching 230 meters on its deepest point. I would definitely like to dive there, maybe in another trip…

Anyhow, I used my hexacopter to try to find Nessie, needless to say, I was unsuccessful… or maybe not??? watch the video and you might be surprised.

I flew with my 10,000 mah battery, which gave me about 20 minutes of flight time,  I performed automatic missions, but mainly it was manual flying, it was a bit risky, because I was flying over water, any failure and I’ll had to swim to recover it… But not as risky as this one. The vehicle performed flawlessly.




Check the video!!!



Racer Hexacopter v1


This is a vehicle designed to race!

Glass fibre frame, extremely light yet very hard to endure the common crashes when doing FPV racing, Multistar Baby Beast motors, 6 of them! and 3 props 5×3 in props! Very very responsive package!!



Frame: HK Thorax Mini FPV Hex
Motors: Multistar 2206-2150kv “Baby Beast”
ESC: Afro 12amps, SimonK
Props: 3 blade 5 x 3
FC: naze32 (afro)
Battery: 2.2A


Some photos of the building process:

I’m using a neopixel strip (because its fashion now to use it… and its cool). The next photos are of the vehicle flying:



Flying from computer

Flying from computer

As a by-product of a research I’m working on right now, I’m showing this videos of me controlling a multirotor from a computer. It’s done in different platforms -two flight controllers- Pixhawk and MultiWii.

The companion computer used in this tests is a credit card-size computer, the popular Raspberry Pi 2, which has four cores clocks at 900mhz and 1 gb of RAM.

Connection diagram
Connection diagram

So, the basic idea is to send data to the companion computer and this will use it to several purposes. The purpose shown in this post is to send roll, pitch, throttle and yaw data to the flight controller. In other words, it is to fly the multicopter from another computer. Eliminating the need of a standard RC radio, you might ask, why would I want to this?? there is three ways to answer this, one is because I can… the second is to ensure that the communication with the vehicle is working great and is robust, and the third one is to further develop advanced outer-loop position controllers.

This is by no means new or cutting edge, it’s just clever use of the libraries I have written (in the case of my multiwii library…) and the one that has been developed by people from 3DR (dronekit).

The companion computer is running linux and some python scripts (I’ll explain more later…), the ground station is running Matlab/Simulink in order to read the joystick and motion capture tracking system (not used in this examples…) and then just sent via UDP to the raspberry pi.

Test vehicles
Test vehicles

We are currently testing on 3 vehicles, all of them quadrotors, one is a bit bigger than the others… 650mm from rotor to rotor in comparison to 330mm for the smaller ones.



Firstly, I would like to make a recommendation related to this flight controller, don’t buy the hobby king clone version. We wanted to “save” money by buying this clone version and we ended up with 2 controllers that are not working… we might just had bad luck with a bad batch but who knows… Buy the original one.

The pixhawk is connected to the raspberry pi using serial communication, a tx/rx/gnd cable, we are using serial port 2 on the pixhawk.

The baudrate on the rpi is limited to 115,200… But for our requirements it’s still working ok. Whenever we need more speed, we will need to modify the kernel or change from debian to ubuntu…

The rest of the multirotor remains the same. GPS is connected, but being inside a building, there is no way to get GPS lock. But no worries, we have a very precise indoors GPS system… a motion capture system. In the pictures shown above you can see a GPS stand being used for the optitrack markers, the overall tidiness of the vehicle is truly amazing.

The firmware remains untouched, we are using 3.2 and 3DR flight stack, we might change to PX4 flight stack, but so far this one is working ok. The only thing that we have changed on the pixhawk is the set of parameters of the SR2 rates. Apparently the maximum value we can assign is 10hz… we might need more.

In this one we use and droneapi (renamed DroneKit) in order to send the channel override and fly the vehicle, the code looks something like this:


Droneapi makes doing apps/scripts and particularly talking to the pixhawk a very easy task. I want to thank Andrew Tridgell and all the developers involved here.

The resulting product is shown in this video:



I have done this one in the past, in several forms and with different boards, but in this test I’m using a naze32 board, which is great because it’s 32bit, which means it’s faster and the stabilisation is smoother, and, of course, the communication is way way faster than with my old 8bit versions.

I have actually achieved 300hz of communication using a oDroid U3… Check this video.

This library performs great, is lightweight and extremely easy to use.

The UDP reader thread was also written by me using twisted.

The code for this one (most important part) looks like this:

Which code do you think is easier??

The video is next:

Dunnet Head Drone

Dunnet Head Drone

This great Scottish summer, I did a small road-trip to the highlands with a few friends and my trusty hexacopter.

We did a stop in a place called Dunnet Head, which is a peninsula in Caithness, on the north coast of Scotland, that includes the most northerly point of the mainland of Great Britain. Its has an awesome cliff which is only possible to see if you’re in a boat or using a drone 😉

It was close to 11 am, I started to get my vehicle ready, the weather was almost perfect, sun, no rain and just 17 kph of wind speed (the highest wind speed I have tried is 22 kph…). But of course… I was about to fly above the Atlantic Ocean!!! any wind speed is undesirable.

17.1 kph wind speed

This mission is without doubt the most risky one I have ever done, the problem involved here is that if something failed, a prop, GPS, a ESC, whatever… my vehicle was not going to just crash, it was going to be lost FOREVER. There is no way to get down that cliff (with no equipment) and by the time I could reach it in a boat, maybe it was 20-30 meters underwater, so, if there is fail, is game over.

Then why do I do this? you must think… Is just because I like to test my vehicles to the maximum and I trust them. Oh, by the way, I build this one, is not just a 1000 usd DJI Phathom thing… Its a vehicle I have dedicated hours and hours of designing, building and testing, this was the vehicle’s ultimate test.

Hexacopter ready to fly (props folded)
Hexacopter ready to fly (props folded)

The vehicle is almost everything in carbon fibre, and you can see the specifications here. A interesting fact about this one is that is using foldable props of 12 in, the usual size for this type of propeller is 15in.

So, I had my crew (The gang) to help me doing crowd control and warn me of some danger that me as a pilot cannot see easily. Thanks Tania, Dalila and Rob you guys rock!

I did a, what I thought, it was going to be a small automatic mission, because is easier for the vehicle to do a nice flight that me being at 300 meters away with no FPV gear. The mission was approximate 900 meters in total length and it was going to be done in 5 min.

Mission analysis

After do pre-flight tests, and check connections and the vehicle overall, the take off was very sweet and controlled. Loiter was holding great against the wind. I switch to stabilise and started to fly myself outside of the safe area (away from the cliff’s land) this was in order to take care of the possible big wind gusts in the edge of the cliff. Everything went great. Started to do some loitering to take nice videos, 360s and tilted the gimbal to see the danger under the vehicle (don’t forget to check the video).

Going on automatic mode

The automatic mission started, I was checking how was performing with the telemetry link to my tablet, first WP’s went great, it started to turn towards Orkney and then… I heard my tablet saying “Mode Land”!!!

Of course that mode takes time and goes down very slow, and the pilot can override it by switching modes, at that moment I knew the mission was over and the next thing to do is get it back safely. I switched modes to stabilise and by checking the heading on my tablet to make it point towards me, I did full pitch forward… The vehicle was 363 meters away from me, I could barely see it, my tablet was super helpful. At the end I was able to bring it back safely and I actually continued flying until the battery was almost dry.

The logs showed that there was a EKF variance (Extended Kalman Filter) which is being used as the primary source for attitude and position estimates. This check will trigger when the EKF’s compass and velocity “variance” are higher than an specific value, and this is what happened. The vehicle was flying in a mode that requires GPS (Auto) so the vehicle will switch to “pilot controlled” LAND… not very cool in this kind of situations.

Actual GPS log from the entire flight
EKF variance
My friends after the successful flight

The vehicle performed excellently (except for that variance…) and I was able to get very nice footage to show it to you guys, my readers. So, please check the next video and enjoy:



MultiWii is a UAV autopilot system developed by RC hobbyists. This project uses an Arduino board as a main processor while the sensor system can vary. This project aims to make the fabrication of electronics easy. It uses gyroscopes and accelerometers of the commercial off-the-shelf Wii motion controller from Nintendo (at the early beginning), which needs less soldering. They define it as “MultiWii is a general purpose software to control a multirotor RC model.”

I have used it for several years now, and its great for entry level to this exciting world of vehicles that crash beautifully, I also use it inside my laboratory.

In my lab I develop the outer loop controller, like a hover controller for example, and the MultiWii acts as the inner loop controller… reads sensors, generate PWM signals among other things, and more importantly it tracks the attitude angle I command.

Of course to make the MW listens to my commands, I need to speak “its language”, and that one is the MultiWii serial protocol, also know as MSP.


I’m currently using a Raspberry Pi or similar as a companion computer onboard my vehicles, this computer is the one that will calculate and process the commands of the outer loop (hover controller eg,).

My companion computers therefore need to talk MSP… and precisely that is the purpose of this library.

I developed this library after spending too much time trying to use someones else code, I did it to be easy to use and easy to change. My definition is as follows:

pyMultiWii handles the MultiWii Serial Protocol to send/receive data from boards.

Lets make a very easy example… Imagine that you need to get the vehicles attitude at 10 hz, this is how to do it:

[code lang=”python”]
serialPort = "/dev/tty.usbserial-A101CCVF"
board1 = MultiWii(serialPort)
while True:
print board1.getData(MultiWii.ATTITUDE)

Easy right??

You just need to create a MultiWii object with the proper serial port to address to, then just create a while loop (to cycle forever) and send a request of attitude to the board… and of course then “sleep” for 0.1 seconds in order to do it at 10 hertz.

Wait, its not limited to 10 hz!!! you can put the rate you want… The fastest I have tried with a naze32 board and an Odroid U3 companion computer has being something above 300 hertz!!!

I have successfully used my library for commanding vehicles in my lab, the multiwii boards tested have being:

  • MultiWii AIO v2
  • Naze32 (either baseflight or cleanflight)

This library has being used by several people around the world to create their own cool UAV projects (I’ve received multiple emails thanking me for this piece of code)…

I encourage people to use it, and let me know if they found mistakes or ways to make it better, its licensed as GPL and the only think I ask when using it, is that people cite me or the library.

Here are some nice videos of the library in action:


CH Foldable v2

CH Foldable v2

Carbon Hexacopter Foldable v2

Hexacopter built to carrying heavier than normal payloads (aprox 2.5kgs).


Frame Tarot FY690S folding
Motors Multistar 4822-690kv
ESC Afro 30 (BL Heli)
Props Foldable 12 x 4.5
FC Pixhawk
Landing gear Electric
Weight (no battery) 2096 grams




This vehicle was made thinking in vibration issues transmitted to the camera and flight controller unit. Several techniques to ensure the vibration is damped to ensure great flights and reduce jello effect on videos.




Trying to take advantage of the foldable frame, making this vehicle easier to transport/carry while not flying. Sacrifices were made to ensure the foldable capabilities, one of them is the not-so-efficient foldable propellers.

Fully folded



Flight performance:


The sound made by this rotor configuration is different from the common carbon props one (which I prefer), but it appears to be more silent. Wind resistance is normal-great, the propellers stiffness might be a crucial factor here. It handles pretty well, especially when the landing gear is retracted (more agile…). Videos will come later.


Hexa vibrations
Accelerometer measurement in hover

The vibrations measured with the flight controller accelerometer when hovering (test performed at the firsts flights of a vehicle, to ensure it will perform great) are between the accepted values which are -5 to 5, the vibration showed on the plots never exceed +-3 which proves the vibration dampening of the motors and the flight controller is performing well. This will ensure great autonomous mission capabilities.


Flight times:


There is no enough data to have a conclusive opinion. Only 3 flights have being performed. The two batteries tested so far are Multistar 4s 10C (max 20C) on different capacities.

Predicted with eCalc:

8000 mAh
8000 mAh
10000 mAh
10000 mAh

Real flights:

Battery (mAh) Flight 1 (min) Flight 2 (min) Flight 3 (min)
10,000 11:13 (hover) 15:16 (hover)  14:29 (hover)
8,000 n/a 14:19 (mixed)  13:45 (hover)
5,000 (65c) n/a n/a  ≈10 (mixed)


8,000 mAh fly time (not hovering) – it was raining… oh Scotland.





Aldux ensuring a safety loitering
Aldux ensuring a safe loitering
I sent stuff to space

I sent stuff to space

A few months ago I was approach by some very-nice co-PhDs doing one of those cool balloons that fly very very high for some purpose, then burst it and open an small parachute for trying to soft-land the payload.

I was interested of course because is not very common to be able to say “I have sent some stuff to space”, I definitely wanted to have the possibility of saying that.

The project was titled:


Investigating stratosphere micrometeorite contamination


Meteorites and micrometeorites are important “peek-holes” to the formation of our solar system and processes on other planetary bodies. The field of meteoritics have received a lot of attention due to controversies around signatures of “life” in Martian and other meteorites, and contamination is a big problem when studying meteorites. In this study, carried out as part of the global space balloon challenge (GSBC), a Kaymont 1200 weather balloon equipped with an experiment box was used to transport micrometeorite analogues up to 33000 m. The experiment box opened between 25000 to 30000 m exposing the samples to potential microbial contamination. It is hoped this work may help provide important insights on the significance of contamination of micrometeorites in this level of the stratosphere. The experiment box was successfully retrieved, and scanning electron microscope analysis has shown probable upper atmosphere contamination consisting of NaCl salt, calcium carbonate grains and sulphur-bearing dust grains, which are possibly volcanic aerosols. Culturing of samples in the laboratory is ongoing, to assess the degree of biological contamination and to see which type of sample, if any, that the potential microbes preferred to hatch on to.


So, they asked me if I could open a hatch at certain altitude and then close it. This was to expose the samples to the atmosphere at that altitude, close it and thats it.

I started to work… My idea was to use one of my flight controllers (an multiwii one) that has a precision barometer and can certainly drive servos and just write a small snip of code to activate the servo and close it.

Scotland from above
Scotland from above

After reviewing the multiwii code and the mission specifications, I decided to use the CAMTRIG function in the multiwii code and just add an “if” that will monitor the altitude and if it was above 25,000 meters then open the hatch and “lift a flag”, if the altitude value was more than 30,000 meters then close the hatch. The flag or lock was just to prevent the hatch to open when the ballon was plummeting down to the center of the planet.

I had to make sure the barometer was going to work at that altitude and also if the multiwii was designed for such big integer… The altitude is an 32-bit integer and have a range of -2,147,483,648 to 2,147,483,647 cm, so, no problem there.

I did a test of this using smaller altitudes, from 50cm to 150cm and it worked flawlessly, I’m surprised of the precision of the barometer and how well all the multiwii code works!

So, I gave to the team my FC, a BEC to power it the controller and the servo and a small battery. Everyone else did their awesome job and the balloon was launched, everything worked great, the balloon landed and payload/cargo is safe. We have top men working on it right now. Who? (you might ask…) TOP…. MEN.


And now I can proudly say:


I have sent some stuff to space!

I have sent an MultiWii to space!

Part of me has being in space!

… haha someone stop me.

The code looked like this:

[code language=”cpp” title=”MultiWii code to open a hatch”]
#if defined(CAMTRIG)
  #define OPEN_HATCH  2000  // µs
  #define CLOSE_HATCH 1000
  #define OPEN_AT_ALT 250000 // cm
  #define CLOSE_AT_ALT 300000 // cm
  // If altitude is between the two values, open the hatch
  if(alt.EstAlt > OPEN_AT_ALT && alt.EstAlt < CLOSE_AT_ALT && !Descendlock){    
servo[2] = OPEN_HATCH;   }  
// Keep servo close in any other case  
servo[2] = CLOSE_HATCH;
if(alt.EstAlt > CLOSE_AT_ALT) Descendlock=true;

UAS Grand Challenge

UAS Grand Challenge

University of Glasgow MAST Lab entry to the iMechE Unmanned Aerial Systems Grand Challenge 2014/2015.

The Unmanned Aircraft Systems Challenge (UAS Challenge) bridges the gap between academia and industry in developing applied UAS-related activities.

We designed an H quadrotor that was capable to carry 1 kilogram of flour, do waypoint navigation and drop the payload in a designated area.

This particular vehicle was done using 3D printed parts, and carbon fibre rods, the video explains more about it.

We used Pixhawk as flight controller and a Raspberry Pi 2 as companion computer. Several scripts in python were done to send commands via serial port to the Pixhawk, Drone API was used on the RPI 2.

The vehicle flew perfectly in manual and in autonomous mode, several tests were performed. The rpi2 / Pixhawk combo is a great way to do UAS applications like this one, and this is a living proof of it.

We had 3 ways of communicating with the vehicle:

– Standard RC

– 3DR radios (900 mhz)

– 2.4 ghz Wifi high gain antennas using SSH to the RPI 2 and then to the Pixhawk

Important to notice that we also had an RTSP video server using the RPI camera with 0.5 seconds delay, HD and 30 fps… It worked great.

Our payload mechanism was extremely simple yet very practical and useful, 3D printed as well and fully tested, the video will show that 😉

Tools like the SITL simulator was really helpful to test our scripts before doing them on the actual vehicle, special thanks to the developers that are making this tools easily accesible to us.

You might be thinking about how well we did… The vehicle worked great, we passed scrutiny very easily and it was airworthy after just adding some padding for the LiPo’s. The problem was later, a manual test was needed before doing the automatic mission, and it must be flown by a certified pilot…

Moment of disaster

Currently in the MAST Lab we don’t have a certified pilot, so iMechE provided the certified pilot for our vehicle, and as many of you know, every vehicle is different… and being a prototype, even more. The problem is that he did not had chance to practice before doing the actual flight… the vehicle took off, and like at 40 centimeters it pitched super aggressively and the tip of the vehicle touched the ground and it flip, that was it.

That particular part was not in our spare list and our 3D printer was 500 miles away in Glasgow (ergo the last song in the video, duhhhh). Oh, by the way, we have a Makerbot Replicator 2.