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