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.

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!!!

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.

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.

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.

Pixhawk

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 mavproxy.py 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:

MultiWii

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:

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)
time.sleep(0.1)
[/code]

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:

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

Abstract:

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.

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
  //Altitudes
  #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  
else{  
servo[2] = CLOSE_HATCH;
if(alt.EstAlt > CLOSE_AT_ALT) Descendlock=true;
}
#endif
[/code]

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 mavproxy.py 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…

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.