Select Git revision
flightcontroller_imp.tex 6.27 KiB
\subsection{Flight Controller}
\subsectionauthor{Author: Lars Jonsson \\Reviewer: Max Unander}
To be able to start up the flight controller for the first time you will need to flash the flight controller with some sort of software.
There are many flight controller softwares on the market, a couple of them are open source.
After some reading around on the web we decided to flash a software called \href{http://cleanflight.com/}{Cleanflight} to the flight controller.
We chose Cleanflight because it has a well documented source code, gets regularly firmware updates and has a broad hardware support.
The main GUI looks nice and is easy to start out with, it's straight forward how to change parameter values, and how to setup the board before your first flight.
The firmware that we flashed our flight controller with is the \href{https://github.com/cleanflight/cleanflight/releases}{cleanflight\_SPRACINGF3.hex v$1.13.0$}.
Which was the newest stable version of Cleanflight at the start of this project.
Normally a quad copter or any other RC vehicle is controlled by a radio transmitter.
For a quad copter the radio transmitter must have at least 4 channels.
The four channels that is necessary to have is the three rotation axis yaw, pitch and roll plus the absolute throttle to all the motors.
In this project we are going to use another approach to control the copter.
Instead of having full control of the copter using the radio transmitter, you will only have to ability to send high level commands.
To be able to do this we need to interact with the flight controller from our MCU somehow.
The flight controller do have support for four different communication protocols.
It can take PWM inputs, where one PWM controls one channel.
%It has
It have PPM support, which is quite the same as a PWM but it has support for 8 PWM signals on one line.
%does?
It do support sBUS, which is some sort of secure serial protocol with inverted signals.
The last protocol it supports is called MSP (MultiWii Serial Protocol), which also is a serial protocol.
Our first thought was that we wanted to implement both the MSP and PPM protocols to control the copter.
We wanted PPM to be able to maneuver the copter with the RC transmitter, and MSP to control the copter with our MCU.
We also hoped that we will be able to have a 2-way communication with the flight controller using MSP.
This so we could be able to not only send commands to the flight controller, but also retrieve information from the flight controller as well, this protocol can be seen in Figure~\ref{fig:fc_communication_1}.
\begin{figure}[H]
\centering
\includegraphics[width=0.6\textwidth]{Pictures/fc_communication_1}
\caption{This shows how the intended communication between the radio-transmitter, MCU and flight controller was going to be implemented.}
\label{fig:fc_communication_1}
\end{figure}
The hard part with this approach was how to be able to switch between these two protocols mid air.
We did have some thought how we could do this, but we did not manage to get this working without rewriting some code in the flight controller.
As this could be a hassle, we thought out another way to solve this.
The easiest way was to decode the PPM signal from the transmitter into the MCU, and do the conversion between raw transmitter data and controlled data in the MCU and send all data through MSP instead.
With this approach the communication will look like the one in Figure~\ref{fig:fc_communication_2}.
\begin{figure}[H]
\centering
\includegraphics[width=0.6\textwidth]{Pictures/fc_communication_2}
\caption{This shows how the communication between the radio-transmitter, MCU and flight controller works.}
\label{fig:fc_communication_2}
\end{figure}
The disadvantage with this approach is that if anything goes wrong with the MCU, we won't have the ability to control the copter at all.
But there are also some advantages with this approach.
We now have the freedom to map the control stick in any way we want it and we can use all the available channels on the RC transmitter to start certain functions on the MCU, which will be shown later on.
In Cleanflight you have the ability to choose between three different flight modes.
The three modes are Rate mode (default), Horizon mode and Angle mode.
The default flight mode does not stabilize the copter around the roll and pitch axes.
Which means that the copter wont stabilize on its own if you center roll and pitch control sticks on the transmitter.
Instead the copter will respond with an angular velocity around these axes related to the stick.
In Angle mode the roll and pitch channels control the angle between the relevant axis and the vertical, achieving leveled flight just by leaving the sticks centered.
Horizon mode is some hybrid between the auto-level Angle mode, and the manual Rate mode, so for our application it´s best to go with Angle mode.
In Cleanflight you will also need to choose between three different PID controllers, MultiWii, MultiWii (2.3) and LuxFloat.
We started out with MultiWii, and did get the copter to fly, but it didn´t fly as good as we had hoped.
After weeks of tweeking with this PID, we saw that in newer versions of Cleanflight only LuxFloat will be available.
When changing to this PID controller instead and with some minor changes, the flight performance was improved drastically.
There are some things that was needed to be setup in Cleanflight to be able to fly the copter for the first time.
\begin{itemize}
\item First we did set the flight orientation of the copter, at default it is set to "X-config", but we wanted the "+-config" becuase of the placement of the sonars.
\item Second thing was to set the orientation of the flight controller, so the copter wont respond in the wrong direction.
\item When all the orientations was set right, we did calibrate the accelerometer.
\item Next thing to do was to setup the MSP communication port. Which we programmed to UART3 running at 115200 baudrate.
\item After that we did setup command bindings on certain channels, like arming the copter and choosing flight mode.
\item Last thing to do is to choose an PID controllers and assigning values for the P, I and D.
\end{itemize}
All our configurations that was set in Cleanflight can be shown in the Appendix \ref{label}.
TODO: Add the configs from Cleanflight into an Appendix, will be done after Christmas.