Acta Polytechnica CTU Proceedings doi:10.14311/APP.2015.1.0015 Acta Polytechnica CTU Proceedings 2:15–21, 2015 © Czech Technical University in Prague, 2015 available online at http://ojs.cvut.cz/ojs/index.php/app RECONNAISSANCE MICRO UAV SYSTEM Petr Gabrlika,∗, Vlastimil Kriza, Ludek Zaludb a CEITEC - Central European Institute of Technology, Brno University of Technology, Technicka 3082/12, 616 00 Brno, Czech Republic b Faculty of Electrical Engineering and Communication, Brno University of Technology, Technicka 3082/12, 616 00 Brno, Czech Republic ∗ corresponding author: petr.gabrlik@ceitec.vutbr.cz Abstract. This paper describes the design and implementation of the Uranus UAV. This quad-rotor flying robot was created to extend the abilities of the hitherto developed with airborne missions. The first part deals with the mathematical model of the robot. Next, the control system is designed, and the proposed hardware as well as the implemented software solution are presented. For integration into the robotic system, a new communication protocol was created and is described here too. Keywords: UAV, multirotor, robotics, mathematical model, state-space controller. 1. Introduction In the research laboratories of CEITEC and BUT, the Cassandra robotic system has been developed [1]. This is a heterogeneous group of robots controlled mainly by telepresence from the operator base station. Within the described concept, each robot is assigned a specific task, such as reconnaissance, terrain mapping or contamination measurement. The intended pur- pose of the entire group is to perform these tasks in locations which are dangerous or inaccessible for hu- mans. Until recently, this group included only ground robots. In order to enable the group to pursue the assigned tasks from the air or to reach locations unap- proachable for ground robots, it was decided to extend the group with a flying robot. To facilitate operation in a closed environment where airplanes can manoeuvre only with difficulty, an aircraft with the ability to hover was required. Because airships provide a poor payload/dimensions ratio, helicopters were taken into consideration; the first attempts were carried out with classical machines. However, such helicopters were not robust enough for the intended use in a difficult environment, mainly due to the fact that they contain lot of small moving parts which get easily damaged. Quadrotors (and multi-rotor copters in general) have proved to be the best platform for our purposes. The only moving parts on these devices are their rotors rigidly connected to the engines. Everything is controlled just by changing their rotor speeds. Yet this solution also exhibits a disadvantage, namely internal instability; thus, a con- trol system needs to be implemented to provide the necessary operational ability [2]. Currently, quadrotors are being developed within a large number of projects, from hobby to professional ones. After investigating some of these projects, we considered the given status and decided to create our own solution. This approach offers a significant advan- tage: as the applied software is not license-restricted, Figure 1. Uranus UAV during a flight. we will have full control over the solution and will be able to modify our device if necessary. In this context, a specific airframe and control system were created. To design the control system, the behavior of the designed airframe with rotors was described and mathematical model assembled. 2. Quadrotor Model The mathematical model of the Uranus UAV com- prises two parts. The first part handles the relation between the speed of the rotors and the forces and torques affecting the quadrotor rigid body. The sec- ond portion defines the dynamics of the rigid body, including transformation between frames and effect of gravity force. This separation allows us to design a controller with better dynamics, because the first part of the model can be easily linearized in the controller. The forces and torques caused by propellers of the rotors and affecting the quadrotor rigid body are de- noted as u1 to u4. The meaning is as follows: u1 - torque around the x axis caused by different thrust of rotors 2 and 4; u2 - torque around the y axis caused by 15 http://dx.doi.org/10.14311/APP.2015.1.0015 http://ojs.cvut.cz/ojs/index.php/app P. Gabrlik, V. Kriz, L. Zalud Acta Polytechnica CTU Proceedings different thrust of rotors 1 and 3; u3 - torque around the z axis caused by different reaction torques from rotors rotating in opposite directions; u4 - force in the z axis caused by common thrust of all the rotors. The relation between the thrust and propeller speed of a rotor is FT = kT · n2, (1) and the relation between the reaction torque and propeller speed of a rotor is MR = kM · n2. (2) Here, kT and kM are constants determined by the measurement. The first part of the model then could be described as u1 = (−n2 2 + n2 4)kT l u2 = (n2 1 − n2 3)kT l u3 = (−n2 1 + n2 2 − n2 3 + n2 4)kM u4 = (n2 1 + n2 2 + n2 3 + n2 4)kT (3) l denotes the distance between the rotors and the center of gravity of a quadrotor. The second part of the model can be further divided into four parts: Equations that describe rotational movement; equations of linear movement; equations describing transformation between frames; and equa- tions expressing the effect of gravity force. All variables are defined in 2 frames: robot frame and ground frame. The robot frame is bound to the UAV while the x axis faces forward, y faces right, and z faces down. The ground frame is bound with the ground and oriented north-east-down. Rotational movement (robot frame): ω̇x = (Iyy − Izz)ωyωz + u1 Ixx ω̇y = (Izz − Ixx)ωxωz + u2 Iyy ω̇z = (Ixx − Iyy)ωzωy + u3 Izz (4) Ixx, Iyy and Izz represent moments of inertia around a given axis. Translation movement (robot frame): v̇x = mωyvz +mωzvy +Gx m v̇y = mωxvz +mωzvx +Gy m v̇z = mωxvy +mωyvx +Gz − u4 m (5) Gx, Gy and Gz are the gravity forces component in a given axis: Gx = −mg sin θ Gy = mg cos θ sinφ Gz = mg cos θ cosφ (6) Transformation between the robot frame and ground frame [3]: φ̇ = ωx + ωy sinφ tan θ + ωz cos θ tan θ θ̇ = ωy cos θ − ωz sinφ ψ̇ = ωy sinφ cos θ + ωz cosφ cos θ ẋ = vz(sinφ sinψ + cosφ cosψ sin θ) − −vy(cosφ sinψ − cosψ sinφ sin θ) + +vx cos θ cosψ ẏ = vy(cosφ cosψ + sinφ sin θ sinψ) − −vz(cosψ sinφ− cosφ sin θ sinψ) + +vx cos θ cosψ ż = vz cosφ cos θ − vx sin θ + vy cos θ sinφ (7) The parameters m, l, kT , kM of the models was mea- sured and Ixx, Iyy, Izz were computed. The values are as follows: m = 1.05 kg l = 0.35 m kT = 0.14 · 10−6 N ·RPM−2 kM = 4.6 · 10−9 Nm ·RPM−2 Ixx = 8.6 · 10−3 kg ·m2 Iyy = 8.6 · 10−3 kg ·m2 Izz = 12.0 · 10−3 kg ·m2 (8) 3. Controller Design To stabilize the Uranus UAV, a controller based on state space representation of the quadrotor was de- signed. As shown in Sect. 2, the model of the quadrotor com- prised 2 parts. The first part handles the non-linear relation between the rotation speed of the propellers and the introduced variables u1 - u4 denoting the forces and torques affecting the rigid body. Because this part of the model does not contain any dynamics, this relation can be expressed by purely static equa- tions (3). To handle this, a mathematical block with 16 vol. 2/2015 Reconnaissance Micro UAV System inverse function (9) is implemented in the controller. n1 = √ 2kMu2 − kT lu3 + kM lu4 4kMkT l n2 = √ −2kMu1 + kT lu3 + kM lu4 4kMkT l n3 = √ −2kMu2 − kT lu3 + kM lu4 4kMkT l n4 = √ 2kMu1 + kT lu3 + kM lu4 4kMkT l (9) This block, together with the first part of the model, will act as a linear section with unitary transfer func- tion (while operating in the working range of the rotor drivers). This allows direct use of the variables u1 - u4 as inputs to the system and enables us to treat these parts of the system as linear. The schema of the system with the controller is shown in Fig. 2; here, a classical state space controller is extended by few enhancements. The first one is a bias (u4−0) added to the input u4, whose function is to ensure the thrust needed to keep the quadrotor in hover flight. The next one consists in adding a new state IZ , which is an integral of the altitude error, z. The purpose of this is to achieve zero steady-state error while hovering, because it is almost impossible to set up a thrust that exactly compensates the gravity force. The design of the state space controller is based on a linearized model of the rigid part of the quadro- tor. Equations (6) and (7) are linearized around the working point, which is hovering. For the equilibrium point, we have φ = θ = ωx = ωy = 0. (10) To reach this state, the thrust of the rotors must compensate the gravity force acting in z axis at hori- zontal flight. Thus u4−0 = mg. (11) The system matrices A and B required for the controller design are derived from linearized Equa- tions (4), (5), (6) and (7). The matrix C is an identity matrix, and the matrix D is a zero matrix. The matrix K, which determines the control law, was obtained experimentally by the pole placement method. Matrix K: ωx ωy ωz vx vy vz φ θ ψ x y z Iz u1 1.05 0 0 0 0.29 0 2.66 0 0 0 0.12 0 0 u2 0 1.05 0 −0.29 0 0 0 2.66 0 −0.12 0 0 0 u3 0 0 0.66 0 0 0 0 0 0.44 0 0 0 0 u4 0 0 0 0 0 −4.08 0 0 0 0 0 −6.32−3.06 It can be observed from this matrix that the lin- earized state space description decoupled the system into independent subsystems for each axis.; the con- troller therefore handles it in this manner. In fact, from the perspective of attitude control, the state space controller can be understood as a set of sepa- rated PI or PD controllers. The results then prove that the approach involving a space controller and the approach employing PID controllers provide compa- rable results in this mode of flight. First, the real behavior of the designed controller was tested in a laboratory. Figs. 3 and 4 show the step responses for the angular rotations pitch and yaw, which were both measured independently on a special tool. 4. Implementation 4.1. Construction The Uranus UAV has a well-known, four-rotor struc- ture often referred to as quadrotor or quadrocopter. The construction consists of two orthogonal aluminum beams, which form a symmetric cross. All the elec- tronic devices and printed circuit boards (PCB) are situated in the middle of the cross to ensure that the center of gravity is also in the middle. At the end of each beam there is one brushless DC (BLDC) AXI 2212/34 electromotor equipped with a Graupner 11"x 5" carbon propeller. To suppress the mechani- cal vibrations, the motors are mounted on the rigid quadrotor frame through rubber pads. The UAV overall dimensions are 701x701x188 mm, and the weight is 1.05 kg. The maximal combined motor thrust is about 24 N, so it is possible to carry a 150 g payload without reducing the maneuverabil- ity. The construction is mechanically simple and also allows additional modifications. 4.2. Hardware The UAV is equipped with several PCBs. The central one is the control board, which contains a control microcontroller (MCU), a power supply, and various sensors. The other boards are the communication module, BLDC controllers, and ultrasound sensor. The sensor unit and GPS receiver are encased in their own packages, and they are connected to the control board. The block scheme of the Uranus UAV system is shown in Fig. 5. All the electronic devices on the UAV are powered by a Li-Pol accumulator. In this construction, a 3-cell accumulator with the nominal voltage of 11.1 V, and the capacity of 2200 mAh is used. This voltage is fed to all the engines, while the remaining electronics are supplied with 3.3 V and 5 V. The voltage level reduction is performed by switching and LDO (Low- dropout Regulator) stabilizers. The control board was designed specifically for this application. The main part of the board consists in an MCU LM3S8962, which is based on the 32-bit ARM Cortex M3 architecture and is able to operate at frequencies up to 50 MHz. It provides sufficient 17 P. Gabrlik, V. Kriz, L. Zalud Acta Polytechnica CTU Proceedings Figure 2. Designed controller. 0 5 10 15 −5 0 5 10 15 time [sec] θ [° ] Figure 3. Pitch angle step response. 0 5 10 15 0 20 40 60 80 100 time [sec] ψ [° ] Figure 4. Yaw angle step response. computing power [4], all the required communication buses (SPI, UART, I2C), and internal A/D converters. An Xsens MTi-G is applied as the main sensor unit; this component is an inertial measurement unit (IMU) and an attitude and heading reference system (AHRS). Firstly, instead of this IMU, a VectorNav VN-100 was used. With this IMU, however, we obtained worse results in stabilization, since the linear movement also cause a change in the measured angles. Thus, it was replaced with the Xsens MTi-G, a component widely used in other UAV projects, e.g. [5], [6]. The unit con- tains triaxial digital devices, namely an accelerometer, a gyroscope, and a magnetometer; further, the unit also comprises a GPS receiver in one package with an external GPS antenna. An internal Kalman filter pro- vides precise orientation estimation with 1 deg RMS roll/pitch and 2 deg RMS heading dynamic accuracy and the accuracy of 2.5 meters CEP in position. The control board is also equipped with a BMP085 barometric sensor for the purpose of altitude measure- ment. An ultrasound sensor, which is used at low altitudes (during take-off and landing), is situated on the special PCB. The battery level is determined on the basis of the voltage and current measurement. Regularly available BLDC controllers BL-Ctrl V2.0 provide the continuous current of 35 A for each motor and a very compact design. The controllers commu- nicate with the control board via an I2C bus. It is also possible to mount an IP wireless camera on the construction and broadcast the image to the base station. 4.3. Microcontroller Software The software for the MCU was written in the em- bedded C language due to high requirements for the real-time behavior and reliability. The software does not use a commercial RTOS but a simple and non- preemptive OS written specifically for this application. To achieve the real-time behavior, a system timer with the period of 100 ns was used; this is the shortest possible period to handle any application task. The application also uses MCU hardware interrupts to handle various asynchronous events. The interval for the computing of the main quadro- tor stabilization (angular rotations stabilization) is 10 ms. At the same period, the data from the IMU/AHRS are read and the actuator speeds up- dated. The sample period in altitude measurement depends on the used sensor; for example, we thus have the period of 25 ms for the ultrasonic sensor. The im- plemented control structures for the stabilization are constant, but their parameters can be tuned according to the current UAV configuration. The application operates in several modes: the configuration/stop mode, applied when the UAV is switched on but the actuators are disabled; the flight remote mode, used for standard remotely controlled operation; the signal lost mode, activated in the flight mode when the signal is lost and the UAV is landing automatically; and the flight auto mode, which is ready for future autonomous flying using GPS. 18 vol. 2/2015 Reconnaissance Micro UAV System MCU ARM Cortex M3 Ultrasound board 3-axis accelerometer Xsens Mti-G 3-axis gyroscope 3-axis magnetometer GPS receiver 4x BLDC electromotor 4x BLDC controller ZigBee wireless module ZigBee wireless module Notebook + Cassandra HID / Gamepad Uranus UAV Base station UART1 UART2 I C 2 USB UART - USB Pressure sensor I C 2 Figure 5. The block scheme of Uranus UAV system. Figure 6. UAV control board and the other electronics. 4.4. Communication The communication between the robot and the base station is wireless. It is provided by two paired X- Bee PRO S2B RF modules transmitting within the band of 2.4 GHz; the modules use the ZigBee protocol and operate in a transparent mode. In this mode, the 2 devices work as a virtual UART wire. Thus, every UART frame send to the input of one module appears on the output of the other (if the RF channel is established). The Baud rate of this line is 57.6 kbps. Above this layer of communication, the UranusLink protocol was created. It was designed as a packet- oriented, non-reliable protocol. This protocol defines the packet structure as well as the transmitted data representation. As shown in Table 1, every packet in UranusLink consists of 6 fields: the preamble (PRE); the sequence number (SQN); the message identifica- tion (MID); the data length (LEN); the data as such; and the checksum (CS). All the data are in the big endian format. The preamble has the constant value of 0xFD. It is used to determine the beginning of the packet. The SQN is intended for the numbering of the packets; while every sent packet increases this number by 2, the SQN can only take even values. This property is utilized in one of the packet validation mechanisms. Another important application of the SQN is in packet loss detecting. The MID determines the interpreta- tion of bytes in the DATA part of the message, while the LEN specifies the length of this part. There are 24 different packet types distinguished by the MID. The most important ones are: Compounded joystick command, Robot mode, and Acknowledge in the direc- tion towards the robot; and All data stream, Battery voltage, and Acknowledge in the direction towards the base station. The Computed joystick command holds the required roll, pitch, yaw, and thrust. The Robot mode is used to switch between the robot modes, as described in Sect. 4.3. This packet is specific, because it must be confirmed by the Acknowledge packet from the robot. The Acknowledge packet carries, in its data section, the SQN number of the packet which is confirmed by it. Towards the base station, the All data stream carries important telemetric data such as the robot attitude and altitude, GPS position, and status (e.g., if the GPS data are valid or the iner- tial measurement unit was initialized successfully). While these data are sent every 10 ms, the Battery voltage, for example, is sent once per second. In the direction towards the robot, the Compounded joystick command is sent approximately every 100 ms and the Robot mode only when it is required to switch the mode. As stated above, this packet must be con- firmed by the Acknowledge packet. If it is not, the station begins retransmitting it and continues until confirmation is obtained. This is carried out to ensure that the robot mode will be switched even when the packet is lost. The other packets remain unconfirmed, because the system overheads will be more significant than the advantage of ensuring that all flight data will be transmitted OK. If there is a packet outage lasting longer than 0.5 s, the robot will handle this as signal loss and take an action. It will set the required roll, pitch and yaw to zero; also, the system performs slow descent and can proceed to eventual landing. 4.5. Base station One of the requirements for the Uranus was its inte- gration in the Cassandra system. This system has been developed at CEITEC and the BUT for several 19 P. Gabrlik, V. Kriz, L. Zalud Acta Polytechnica CTU Proceedings PRE SQN MID LEN DATA ... CS 1B 2B 1B 1B 1-252 B 1B Table 1. UranusLink packet format. years. This system comprises a heterogeneous group of robots and a base station. The core of the base station consists of software written in C#, communica- tion HW, and human-device interface. This interface includes a joypad and a virtual reality helmet, or, in the simpler version, a monitor screen and an optional keyboard. The base station software can be run on a classical PC, a laptop, or an embedded PC; thus, the base station can be a mobile or even wearable system. A new communication HW was built to operate the Uranus UAV. This portable device consists of X-Bee modules (as described in section 4.4), a high-gain an- tenna, and an UART-over-USB converter, all placed in box attached to a foldable tripod stand to ensure a higher position of the communication system above the ground (and, thus, better coverage). From the base station, the operator can control all the powered robots by switching among them. The display provides the operator with a first person view from the robot. The robot movements are controlled via the joypad. If the camera on a given robot is capable of rotating, its motion can by controlled via movement of the operator’s head (in case that the virtual reality helmet is used) or by means of the joypad. The Cassandra base station display provides, be- sides a view from the onboard camera, important telemetric and other mission-related data, as shown in Fig. 8. The bottom part of the display presents attitude information, namely the actual roll and pitch angle in the artificial horizon in the left circular indi- cator, and the yaw angle in the compass in the right one. The upper left corner includes the robot status indicator. This contains the name of the active robot, its battery voltage, signal outage indicator, actuator state, robot mode, and other information if required. The lower part of this indicator can show important text information and warnings. All the indicators can be hidden, plus there are a couple of indicators not opened by default. Such indicators display, for example, the status of the other robots, the actual position of the robot on the map, or the actual camera orientation. 5. Operation For flying with the Uranus UAV, we use the following configuration: a laptop with the Cassandra system installed; a joypad; and a designed communication device. The Uranus is controlled by a joypad with 2 joysticks, of which the left one regulates the pitch and roll and the right one modifies the thrust and yaw. Before the flight, the following steps need to be carried out: after switching the power on, the Uranus Figure 7. Base station and Uranus UAV. Figure 8. The user interface of the Cassandra system. UAV is in the configuration/stop mode. This mode has to be switched to the run mode from the joypad. Subsequently, all the rotors start and operate at a very low speed. After that, the right joystick, which con- trols the thrust, needs to be pushed all the way down. Then the rotors will gradually achieve the speed corre- sponding to the actual joystick position. This solution was implemented to prevent the rotors from starting at very high RPMs if the mode is switched with the joystick in default position. From this moment on, the Uranus UAV is ready to flight. If the thrust joystick is released, the robot will take off and hover at about 1 meter above ground. To precisely suppress the gravity force by the thrust, the output levels sent to the motors from the controller are modified according to the battery voltage. This occurs because the thrust of the motors varies in accordance with the battery voltage. The battery voltage level is also reported to the base station to warn the pilot if the voltage drops too low. A warning is also produced by signal loss. If this happens, the Uranus UAV will automatically land. During the test flights, it was proven that Uranus is stable, and while the control joysticks are released, the quadrotor hovers in position. But because no position stabilization has been implemented to date, the Uranus could slowly drift from the given position. This feedback will be integrated only in the next versions. Controlling the Uranus with the joypad was easy, and the operator was able to operate the UAV 20 vol. 2/2015 Reconnaissance Micro UAV System effectively after a short while. 6. Conclusion Regarding the successful test flights, it can be con- cluded that the assembled mathematical model clearly expresses the quadrotor behavior; thus, the designed control system was able to stabilize the robot suitably. Although the controller was designed as a state-space device, it was proven that the resulting controller can be interpreted as a set of separate PI or PD controllers in each axis. This is due to the model linearization around the working point, namely hovering. For in- tended use, the described approach provides good results: the quadrotor was able to hover and to ma- neuver. To facilitate integration in the Cassandra system, a new communication protocol was designed, and the Cassandra system was modified to be capa- ble of handling the flying robots. As the purpose of the developed Uranus UAV was to enable the Cas- sandra robotic system to perform air missions, it can be stated that the given goal was achieved. For the future, we plan to navigate the Uranus UAV by the GPS, to design our own IMU, and to create a bigger airframe with a higher payload capacity. List of symbols θ Angle of rotation around the lateral axis [◦] φ Angle of rotation around the longitudinal axis [◦] ψ Angle of rotation around the vertical axis [◦] ω Angular speed [◦ s−1] FT Thrust [N] g Gravitational acceleration [m s−2] G Gravity force [N] I Mass of inertia [kg m2] kM Rotational speed to reaction torque ratio constant [Nm RPM−2] kT Rotational speed to thrust ratio constant [N RPM−2] l Length [m] m Weight [kg] MR Reaction torque [Nm] n Rotations per minute [RPM] u1 Torque in the longitudinal axis caused by motors [Nm] u2 Torque in the lateral axis caused by motors [Nm] u3 Torque in the vertical axis caused by motors [Nm] u4 Force in the vertical axis caused by motors [N] u4−0 Force in the vertical axis required to compensate gravity force [N] v Linear speed [m s−1] x Longitudinal axis; Position in this axis [–; m] y Lateral axis; Position in this axis [–; m] z Vertical axis; Position in this axis [–; m] Acknowledgements This work was supported by the project CEITEC - Central European Institute of Technology (CZ.1.05/1.1.00/02.0068) financed from European Re- gional Development Fund and by the project FEKT-S-14- 2429 “The research of new control methods, measurement procedures and intelligent instruments in automation” financed from internal grant system BUT. References [1] L. Zalud, L. Kopecny, F. Burian, T. Florian. Cassandra - heterogeneous reconnaissance robotic system for dangerous environments. In 2011 IEEE/SICE International Symposium on System Integration (SII), pp. 1275–1280. 2011. doi:10.1109/SII.2011.6147632. [2] S. Bouabdallah. Design and control of quadrotors with application to autonomous flying. Ph.D. thesis, ÃĽcole Polytechnique FÃľdÃľrale de Lausanne, 2007. doi:10.5075/epfl-thesis-3727. [3] F. Solc. Modelling and Control of a Quadrocopter. Advances in Military Technology 5(2):29–38, 2010. [4] H. Lim, J. Park, D. Lee, H. Kim. Build Your Own Quadrotor: Open-Source Projects on Unmanned Aerial Vehicles. IEEE Robotics Automation Magazine 19(3):33–45, 2012. doi:10.1109/MRA.2012.2205629. [5] S. Grzonka, G. Grisetti, W. Burgard. A Fully Autonomous Indoor Quadrotor. IEEE Transactions on Robotics 28(1):90–100, 2012. doi:10.1109/TRO.2011.2162999. [6] K. Alexis, C. Papachristos, G. Nikolakopoulos, A. Tzes. Model predictive quadrotor indoor position control. In 2011 19th Mediterranean Conference on Control Automation (MED), pp. 1247–1252. 2011. doi:10.1109/MED.2011.5983144. 21 http://dx.doi.org/10.1109/SII.2011.6147632 http://dx.doi.org/10.5075/epfl-thesis-3727 http://dx.doi.org/10.1109/MRA.2012.2205629 http://dx.doi.org/10.1109/TRO.2011.2162999 http://dx.doi.org/10.1109/MED.2011.5983144 Acta Polytechnica CTU Proceedings 2:15–21, 2015 1 Introduction 2 Quadrotor Model 3 Controller Design 4 Implementation 4.1 Construction 4.2 Hardware 4.3 Microcontroller Software 4.4 Communication 4.5 Base station 5 Operation 6 Conclusion List of symbols Acknowledgements References