Understanding Mission Planner for Configuring Drone for Flight

            Now we come to the most important part of the configuration. We assume that all hardware connections have been made as per information provided in previous chapters. Each individual part has been tested and validated for hardware and software configuration. Now we install the Mission Planner Ground Control Application on our Laptop or PC. We connect internet to the laptop and follow the steps below in the order to avoid running errors.

Step 1    Install Mission Planner GCS Application on laptop or PC.

Step 2.    Connect laptop to internet and download OpenVPN windows client. Use the .ovpn file that we created in chapter IV. We had created .ovpn files for each component from FCU, Companion computer to GCS and placed them in a folder VPN_Folder on the laptop. We can drag and drop on OVPN client our gcs.ovpn file and connect to VPN like below:-

Step 3    Scroll down and note VPN IP Address. This IP Address is the IP Address of our ground control station (GCS). In my case its 100.96.1.34 (Kindly refer the VPN diagram in Chapter IV). All configuration of MAVlink in chapters above has assumed this IP Address. 
Please note that the IP Addresses will depend on your VPN service provider and your account created.

            Now, power up the drone, ensure all components works (no visible hardware error) and 4G LTE Modem is connected to service provider. Make sure there are no propellers on the drone. One can take remote ssh of Beagle Bone Blue and Companion Computer to check whether all working ok. If all OK lets connect Mission Planner GCS to the Drone. Here, it is important to note that it does not matter whether you are connecting MAVlink to Beagle Bone Blue directly incase of small drones or Companion computer incase of medium or large drones. The procedure remains the same.  Because even when we establish MAVlink via companion computer using MAVPROXY, the link is indirectly between Ardupilot running on Flight Controller Unit which is Beagle Bone Blue and GCS i.e Mission Planner.

Configuring the Drone (FCU) as per frame design, calibration of sensors and validating outputs

            Connecting MAVlink between drone (FCU) to Ground Control Station (GCS) i.e Mission Planner MAVPROXY via companion computer or directly to Ardupilot (FCU).

When we run Mission Planner with Admin rights it ensures access through windows firewall or Anti-virus Firewall.  As we have defined the IP Address of this laptop while configuring FCU and companion computer, the MAVlink traffic will be directed to it over local LAN or VPN depending upon the scheme adopted. Here, we simply need to select UDP as protocol, 921600 as baudrate and connect. UDP is the internet protocol to connect to FCU directly or indirectly via companion computer at 921600 baudrate. (Refer Chapter 4). Hence, from now we will refer to link with Ardupilot running on FCU directly or via companion computer as MAVLink assuming we refer both unless there is a need to specify the exact arrangement.

            Mission Planner (GCS) is used to configure Ardupilot autopilot application running on FCU. We configure the FCU (Ardupilot application) as per our drone design, calibrate the sensors onboard, validate the outputs and be ready to fly by choosing the flight options. All this will be covered in the thesis from hereon.

            Frame configuration 

After successfully establishing connection for the first time, between Drone FCU (Beagle Bone Blue) and GCS (Mission Planner) (irrespective or direct or indirect MAVlink), we need to select the frame type as per design of drone. This is not a repetitive step but done for the first time or after any major reset.

Mission Planner > Setup > Mandatory Hardware > Frame Selection

            After doing the frame selection, we need to do motor numbering and select the correct orientation. Incase of quadcopter, the number of motors are 4 where motor A/motor 1 and motor C/motor 2 are clockwise while motor B/motor 4 and motor D/motor 3 are anticlockwise. The pairwise ordering has to be same, however we can reverse the clockwise to anticlockwise as per our choice. The main point is A-C or 1-2 will rotate in same direction while B-D or 3-4 will rotate in other direction opposite to the other combination.

            Incase of Hexacopter, the number of motors are 6 where motor A/motor 2, motor C/motor 4 and motor E/motor 7 are clockwise while motor B/motor 1, motor D/motor 3 and motor F/motor 8 are anticlockwise. The pairwise ordering has to be same, however we can reverse the clockwise to anticlockwise as per our choice. The main point is A-C-E or 2-4-7 will rotate in same direction while B-D-F or 1-3-8 will rotate in other direction opposite to the other combination.

            The frame can be of X type or plus type depends upon the direction of forward move of the drone. It has been observed that X type frames are much more stable than the Plus type frame as the front move is handled by two motors instead of a single motor incase of plus. The detailed analysis on the frames, its types and other considerations have been discussed in the thesis of my project partner. The pictorial view of the frame motor numbering is given below to allow physical connection and propeller type to be put as per schematic given below:-

Mission Planner > Setup > Mandatory Hardware > Servo Output

            Radio Calibration      We need to calibrate the Radio Controller (RC) transmitter here to check for throttle, pitch, yaw, roll and flight modes are selected. We need to validate that the response to full range of controls for throttle, pitch, yaw and roll while toggle switches are programmed for flight mode selection and any other control we wish to have. This is important for all manual missions. Even for autonomous missions we need to test the drone locally before takeoff. Hence, it’s an important step. I will be using Taranis as Radio Controller (RC) transmitter and the X8R as the Radio controller (RC) receiver which we connected to FCU in chapter 3.

Mission Planner > Setup > Mandatory Hardware > Radio Calibration

            Before doing Accelerometer and compass calibration, we need to see the orientation of FCU with respect to the drone. In my case the FCU is in the line of aircrafts forward movement, hence the default AHRS orientation works for me. But incase the design of aircraft is such that FCU is facing in any other direction other than the direction of forward move of the drone then AHRS orientation needs to be done at

Mission Planner > Config > Full Parameter List > AHRS_ORIENTATION

Incase of any other orientation, refer to the link for its value https://ardupilot.org/copter/docs/parameters.html#ahrs-orientation e.g AHRS_ORIENTATION value is 1 for yaw45 degrees and so on. Default value is 0.

 The Beagle Bone Blue has onboard 9-Axis Inertial Measurement Unit (IMU) which combines a 3-axis gyroscope, 3-axis accelerometer and 3-axis compass. This IMU works by detecting linear acceleration using accelerometers, rotational rate using gyroscopes and heading reference using magnetometer. It contains one accelerometer, gyro, and magnetometer per axis. This is for each of the three principal axes i.e pitch, roll and yaw. The raw IMU measurements is utilized to calculate altitude, angular rates, linear velocity and position relative to a global reference frame. Hence, we need to calibrate accelerometer and compass to provide the same. The Ardupilot autopilot application utilizes Extended Kalman Filter (EKF) algorithm to estimate vehicle position, velocity and angular orientation based on rate gyroscopes, accelerometer, compass, GPS, airspeed and barometric pressure measurements.  The EKF is superior to the conventional complementary filter algorithms such as Inertial Navigation. It fuses all available measurements and is better able to reject measurements with considerable errors. This reduces the vulnerability of the drone to faults of a single sensor. This EKF algorithm also provides the option of integration of advanced optional sensors such as lasers and optical flow for more accurate navigation. [3]

            Accelerometer Calibration   In accelerometer calibration, we need to orient the flight controller by calibrating accelerometer for positional awareness of the drone. The drone has to be moved in all directions namely level, left, right nose up, node down and back as is prompted by voice guide.

Mission Planner > Setup > Mandatory Hardware > Accelerometer Calibration

            Compass and Magnetometer calibration     Next, we need to calibrate compass and magnetometer. We need to remove any missing compass and reboot the vehicle/FCU. Then we can see the compass identified by the ArduPilot application. We then calibrate magnetometer and rotate the vehicle in all directions until success message is received. We now need to reboot the FCU for changes to get saved. We must also ensure that the propellers are never on during this entire process.  

Mission Planner > Setup > Mandatory Hardware > Compass and Magnetometer calibration

            Flight Modes. We can select upto six flight modes programmable on the Radio Controller (RC) Transmitter subject to the number of channels it supports. The communication between RC transmitter happens with FCU via RC receiver we saw in Chapter 3 above. The details on flight modes are available later in this Chapter.

Mission Planner > Setup > Mandatory Hardware > Flight Modes

            Electronic Speed Control (ESC) calibration and motor test          Next, we are required to calibrate ESCs so that we can define the minimum and maximum PWM signal for running motors. When we click calibrate ESC, we need to reboot the drone/vehicle (FCU). We hear a sweet sound of ESC calibration on reboot. We must reboot again for getting drone ready for motor test. Thus, we carry out reboot twice to get ESCs and motor ready for dry run. Note all this is done without propellers.

Mission Planner > Setup > Mandatory Hardware > ESC Calibration

            Servo output. Next, we go to servo output to check if all ESCs have been detected. If it’s a quadcopter then we will see the servos green from 1 to 4 and incase of Hexacopter it will be from 1 to 6. After validating, we now carry out ESC calibration and motor test.

Mission Planner > Setup > Mandatory Hardware > Servo Output

Mission Planner > Setup > Optional Hardware > Motor Test

Click test all in sequence. Check the direction of move and order as per example above. The motors will start rotating for 2 secs with 5% throttle in sequence. The duration and throttle can be changed. Be sure to be without propellers. Check the picture to ascertain the expected direction of motor rotation and sequence. The clockwise and anti-clockwise motors have to be in their respective locations following the correct sequence as per the type of frame design.  

            Power module calibration     We are using the APM Power module which is between the battery and power distribution board to monitor the current and voltage drawn by the drone (all components). This power module gives battery state to ground operator as well as situational awareness to FCU. The smart battery with Battery Management System (BMS) has been explained in Chapter 7 above but is restricted to bigger drones. Most drones use LIPO batteries with no intelligence, hence this is an important step as battery is the most crucial part of drone working and single point of failure. Even when using smart batteries, having this power module is a good idea as overlay.  

Mission Planner > Setup > Optional Hardware > Battery Monitor

Setting depends on hardware used. I have used generic APM power monitoring module. Make the below mentioned changes:_

• Battery Capacity as per actuals
• Monitor– Select Analog current and voltage or Analog voltage only depending upon what you want to measure
• Sensor– Select Others
• HW Ver – APM2- 2.5 non 3DR
• Reboot vehicle/drone after making changes

After reboot, go again and feed the measured values of voltage and current to calibrate the module. We can then see the output on the console as above. Note: This power module gives signal output of 5V and is connected to ADC of Beagle Bone Blue which can take only 1.8V max. Thus, we use resistors to divide voltage as shown in Chapter 3 connectivity diagram.

            Configuration of parameter list for UARTs            We need to configure the UARTs we had logically mapped in Chapter 2 while configuring the Beagle Bone Blue as the FCU. Just a recap that on Beagle Bone Blue, Serial 0 was MAVlink over micro-USB cable, Serial 1 was MAVlink with serial interface of Companion computer and Serial 2 is MAVlink directly with Beagle Bone Blue incase connecting directly to GCS (small drones). Now on the Mission Planner end, we need to define serial0, serial1 and serial2 protocols as MAVlink2 and baudrate as 921600. (Serial0 is configured by default so micro USB will work by default to connect for MAVlink). This configuration will enable the ports to act as MAVlink interfaces for Ardupilot application which is running on FCU. Make sure to write parameters after making changes.

Mission Planner > Config > Full Parameter List > Serial0 or Serial1 or Serial2

Selection and configuration of proximity sensor (LIDAR or mmWave radar)

LIDAR Configuration             If we wish to use LIDAR as our proximity sensor, then we need to configure the serial 5 in full parameter list as given below. Refer Chapter 2 where we had logically mapped UART 5 of Beagle Bone Blue with UART 5 of ArduPilot (Switch F). The physical connection of LIDAR is also at UART 5 of Beagle Bone Blue FCU (Refer Chapter 3 for physical connectivity diagram). Change Serial5_PROTOCOL to any other make of LIDAR incase you wish to use some other make or model from the list of supported LIDARs.

• Mission Planner > Config > Full Parameter List > Serial 5
• SERIAL5_PROTOCOL = “11” (“Lidar360”)
• SERIAL5_BAUD = “115” if using Serial1
• PRX_TYPE = “5”
• PRX_ORIENT = “0” if mounted on the top of the vehicle, “1” if mounted upside-down on the bottom of the vehicle.

            In our configuration above in the previous chapters, one can note that mmWave radar if connected to the drone (companion computer) will be sending data as master python script runs automatically on startup. But the choice to select and read proximity data from LIDAR or mmWave radar rests with Ardupilot running on FCU.  It is the PRX_TYPE which determines the selection.

For LIDAR

Mission Planner > Config > Full Parameter List > PRX_TYPE=5

For mmWave radar, its 2 means data will come on MAVlink via Companion Computer

Mission Planner > Config > Full Parameter List > PRX_TYPE=2

The proximity sensor data can be seen on Mission Planner irrespective of the choice of sensor as seen below:-

Mission Planner > Setup > Advanced Hardware > Proximity

(Ctrl+F is the shortcut)

Pre-Arm safety checks and failsafe configuration

         The ArduPilot autopilot application includes a set of Pre-arm safety checks. These ensure that the drone/vehicle will not arm i.e the motors will not fire up until all the set of conditions satisfied. It acts as a critical safety check to prevent  any risk to drone or the operator. The points on the pre-arm safety checklist can be enabled or disabled as per user requirement. The pre-arm safety checks are performed by Ardupilot autopilot application, each time we power on the drone/vehicle. Thus we can select the arming checklist to ensure that the necessary actions are pre-requisite to arming of motors for safety of both the pilot and the drone. The settings can be done as per path given below

Mission Planner > Config > Full Parameter List > ARMING_CHECK

After making requisite changes, the parameters need to be written by clicking write parameters to save it permanently. The FCU needs to be rebooted after any change. The option to write parameters is given on right side as seen in the picture below:

Whenever the drone is connected to the Mission Planner and the pilot tries to arm the aircraft using Radio Controller (RC) transmitter, the pre-arm check failure messages will be displayed to inform the pilot to take corrective action. Some of these messages are:-

            GPS related failure messages and their reasons:

GPS Glitch : This message appears when the drone is in a flight mode such as Auto or Position hold which requires GPS. Hence, the user is advised to change mode to stabilize which is completely manual mode not requiring GPS and troubleshoot the issue of GPS glitch which could be temporary in nature or require hardware change (GPS) change. 

Need 3D Fix : This message informs the pilot that again GPS hasn’t got 3D fix. The GPS uses 3D trilateration to determine its on the earth’s surface with a minimum of four satellites. The pilot must wait, take the drone to an open area and ensure 3D fix before using it in flight modes requiring GPS else operate the drone in stabilize mode where the controls are manual and does not require GPS.  

Bad Velocity : This message informs the Pilot that the drones’s velocity as per its inertial navigation system is above 50cm/s. Possible reasons for this error message are bad accelerometer calibration, GPS updating below 5Hzs or drone moving/dropping.

High GPS HDOP : The GPS’s high dilution of precision (HDOP) message above 2.0 value is undesirable for safety of drone operation. The pilot needs to wait for this error to auto resolve on its own as the GPS finds more and more satellites or change position. Normally a count of 12 satellites is good enough to get the requisite HDOP. This error could also be due to GPS interferences which needs to be resolved by moving any such source of interference away.

The pilot has the option to disable the fence and take-off in a flight mode which does not require GPS such as stabilize or a AltHold and then switch to Loiter after arming. However, this is not recommended and GPS issues  be resolved before takeoff.

            Inertial Navigation System (INS) related error messages:

INS not calibrated:  This error message comes when  one or all of the accelerometer’s offsets are zero which requires the pilot to recalibrate the accelerometer as shown earlier in the chapter.

Accels or Gyros not healthy:  This error message usually means a hardware issue or a recent firmware update related issue. The pilot needs to get this issue resolved by exploring both options before flying. Hardware issues are mostly resolved by replacing the faulty hardware but firmware update issues require either reverting back to the old firmware, or carrying out update again. Incase the firmware update issue is identified; it must be reported to Ardupilot developers on the forum to find possible solutions or issue fixes for resolving the same.

Accels inconsistent:  This error message is again an indication to recalibrate accelerometer as shown earlier in the chapter or carry out hardware change incase recalibration does not help.

Gyro cal failed:   This error message indicate that the gyro calibration has failed to capture the offsets. This in most cases is caused as a result of drone being moved during the calibration process. It can likely be resolved by unplugging and plugging the battery again without jostling the drone. If the issue remains, then it could also be due to sensors hardware failure such as  spikes).

Gyros inconsistent: The error message is displayed when two gyroscopes are reporting drone rotation rates differing by more than 20deg/sec. This could be due to a hardware failure or caused due to bad gyro calibration.

            Battery/Power Monitor message:

The power module calibration that we did earlier ensures that both voltage and current utilizations are tracked for the drone. The pilot or drone operator has the option of providing minimum voltage level as the failsafe value below which the drone will alert the drone pilot/operator and carry out emergency action i.e land or return to launch (RTL) as per user settings incase the drone is airborne. In pre-arm check it simply alerts the pilot/operator to check battery or replace faulty power module. We have the option of configuring minimum arming voltage and remaining capacity parameters for the battery/power monitor by adding values to the BATT_ARM_VOLT and BATT_ARM_MAH parameters in complete parameters list.

Mission Planner > Config > Full Parameter List > BATT_ARM_VOLT

Mission Planner > Config > Full Parameter List > BATT_ARM_MAH

This ensure and checks for the battery above failsafe levels and has enough capacity for flight operations.

            Radio failsafe error message:

This message is displayed when the radio link between the drone and Radio Controller (RC) receiver is broken. During pre-arm it could be due to hardware failure such broken antenna or improper settings of RC transmitter. During flight this message could be due to drone being out of range. The drone has a setting to return to launch (RTL) incase of this error message. We will disable this message for auto or guided mission as our MAVlink will be on 4G LTE modem based internet and the range of drone operation much more that radio link range of RC transmitter and receiver. The disabling of the setting for auto flight mode will be covered in next sub chapter.

            No proximity sensor:

This error message is displayed when proximity sensor settings are enabled but sensor signal is unavailable. We need to check for physical connectivity issues or hardware error to resolve this.

Understanding Flight modes

            After understanding the MAVlink protocol, we also require to understand the flight modes to be able to proceed with system configuration and piloting of unmanned system running Ardupilot and MAVLink protocol. Ardupilot defines multiple flight modes, some important ones are listed below:

            The STABILIZE mode enables complete control to user. The drone will respond to every input provided by user using RC transmitter. Its like a manual override option available for user to take control from autopilot (autonomous mission) incase of issues with the drone. It requires careful handling of the drone and practice to operate the drone in this mode. We can analyze the quality of piloting of drone by analyzing logs which has been explained in detail in subsequent chapter on post-mission analysis.     

            ALTITUDE HOLD (ALT_HOLD) modeautomatically controls the altitude of the unmanned system by the autopilot. However, it does not control the heading  and position of the drone and is controlled by user instead. It’s a relatively easier mode to operate the drone as the user does not have to bother to maintain altitude. This mode is more recommended for beginners and does not require a GPS as it estimates the altitude with the barometer. It is possible to tune the setting of the proportional–integral–derivative (PID) controller of the ALT_HOLD mode in GCS (Mission Planner). The altitude is maintained with proportional controller. It estimates the error between the desired altitude and the actual altitude and in turn tunes the vertical acceleration proportionally to the error. The proportional gain can be set through a GCS (Mission Planner) and will be discussed later in this chapter. The Proportional gain has to be selected keeping in mind the fact that a very high gain makes the control more aggressive and less stable, on the contrary a very low gain will make the control sluggish and nonresponsive.

            LOITER mode is even more convenient than the previous ALT_HOLD mode as the drone in this mode maintains the altitude, its position and heading once the user stops giving control signals through RC Transmitter. It kind of freezes in the place last left by user. In this mode the drone maintains the current location, orientation and altitude last operated by the user. So it’s a combination mode with STABLIZE mode till the time user is operating and then goes in auto mode when user stops providing it any input though RC transmitter. The LOITER mode requires a GPS 3D fix and HDOP (Horizontal dilution of precision) is smaller than 2.0) for it to work or an optical flow. We cannot arm the vehicle in LOITER mode unless we meet the requirement. To achieve better performance, the drone must be in low magnetic interference of the compass and low vibrations. The PID controller gains can be tuned from the GCS (Mission Planner). The LOITER SPEED represents maximum horizontal speed in cm/s which is typically 5m/s. The default configuration is that the maximum acceleration is half of LOITER SPEED which is 2.5m/s2. The parameters of the LOITER mode can be configured through a GCS (Mission Planner) by setting PID control gains of the altitude, position and orientation (Yaw, Pitch and Roll) and is discussed later in the chapter.

            The LAND mode forces the drone to land to the ground mostly incase of emergency.

            The RTL (Return to Launch) mode forces the drone to return to start position from where it took-off. Both LAND and RTL mode are used in case of violation of navigation safety and geofence. An example of RTL is on loss of communication for a particular duration specified before take-off. The configuration of drone to LAND immediately or RTL automatically incase of battery going below threshold, is called GEOFENCE.

            The GUIDED mode is one of the most important mode which operates only with GPS. The GPS of drone performs 3D fix and is activated, then the drone navigates autonomously to a particular GPS coordinate as provided by GCS. As the name suggests, the drone in the GUIDED mode is guided by the user to navigate autonomously to a specific waypoint as provided by the user. The GUIDED mode which works in conjunction with GPS, allows the user to send the drone to specified waypoint as defined by their GPS coordinates. The drone is not armed in the GUIDED mode until it achieves the GPS 3D fix. A GCS is used to send a navigation waypoint to the drone over MAVlink to navigate to it thereby requiring complete reliability over the link. We can click on map to provide next waypoint to the drone.

            The AUTO mode refers to the autonomous mode, where the drone follows a predefined mission where a set of waypoints is fed and stored in ardupilot autopilot application. The drone follows the aerial path through waypoints in the same order as defined by the user before the start of mission. Utilizing the 4G LTE communication for Beyond Visual Line of Sight (BVLOS) communication, we intend to use the AUTO and guided modes without the need for RC transmitter. Hence, we need to make changes to  the drone configuration to allow its operation in AUTO or GUIDED mode. When we are sure about our way points we use AUTO mode, but when we need to guide the drone with waypoints changing on the fly we prefer GUIDED mode.

Be sure to select Mission Planner > Setup > FailSafe > Radio > Enabled continue with mission in Auto Mode

Understanding error messages during flight and Post mission flight log analysis

            After  doing are complete configuration and calibration of the drone, the drone is good enough to fly. However, we must carry out a limited duration flight test to evaluate the logs. The logs help us to understand the complete behavior of the drone for any possible error to prevent loss of aircraft or injury during its operation. Also the logs help us fine tune the various settings esp PID (Proportional – Integral – Derivative) tuning for optimum performance. The analysis of the logs must be done after each flight to improving the performance of drone iteratively and also prevent/avoid future failures by picking on the tell-tale signs as part of best practice.  

            The logs are stored in two ways during a flight as Telemetry Logs or Data Flash logs.

The desired data rate at which the data is sent from the autopilot to the ground station can be controlled through the mission planner though Mission Planner > Config > Planner As all the logging data is sent over the telemetry link (MAVlink).

            Telemetry logs (also known as “tlogs”): These logs are recorded by the Mission Planner which is the GCS on the local laptop/PC running the application as and when drone is connected on telemetry link over radio or 4G LTE Modem. The log files are made in the format YYYY-MM-DD hh-mm-ss.tlog and can be accessed from Document > Mission Planner > log > frametype. 

Mission Planner > Telemetry logs >Tuning displays the parameters of the log we want to see. Incase we want to change the parameters of logs which we wish to see, double click on the tuning top bar and the select window opens.

We can also convert .tlog to KML+GPX to view 3D flight plan in google earth. The converted file with .tlog.kml is in the same log sub folder.  The graph log option can be used to view static graphs from .tlog file using the interactive window as shown below

            Dataflash logs    These logs are recorded on the Flight Controller i.e part of the ardupilot autopilot stack. They are downloaded using Mission Planner or going into the directory /var/lib/ardupilot incase of Beagle Bone Blue and can be downloaded directly. The log files are made in the format YYYY-MM-DD hh-mm-ss.bin and can be accessed from Document > Mission Planner > log > frametype just like tlogs as seen above.

The data flash logs have two options namely auto analysis and review a log. The auto analysis is a quick log summary view and does not contain much details.

Review a log is a more detailed analysis for in-depth understanding of functioning of components as logged by Ardupilot autopilot application. For the purpose of my thesis I will use review a  log as it provides me with a log browser where I can review each parameter of the log file as static graphs to better understand the working of drone software and hardware during flight operations. Unlike tlogs which are moving logs like a live review, the data flash logs are static graphs. 

            Understanding data flash logs using review a log option

In order to better understand the flight logs we need to be clear on the end aim of the analysis. Irrespective of the fact whether we use tlogs or data flash logs (review a log) option, the aim is to analyses the working of drone from key failure or error perspective to minimize failure of flight operations. Also, the nomenclature of log parameters more or less remain the same which means the same knowledge of data flash logs can help us analyze tlogs too. Its entirely on the drone operator or pilots choice to adopt which method for log analysis. The subsequent analysis of logs in the thesis is relevant for tlogs too.

There are six major types of errors to look for while analyzing logs. The analysis also helps us to optimize the design, improve configuration and do advanced tuning for improved flight operations. I will review actual logs in my thesis to explain the analysis and possible solutions during the course of my thesis.

            Mechanical Failures   The most common error that can occur to any drone is due to mechanical fault such as motor or ESC failure, propeller damage etc resulting in sudden divergence in the desired roll/pitch/yaw to the actual roll/pitch/yaw which we will analyze through the log browser of data flash logs. This deviation from desired values can be seen in the Altitude information seen as ATT in log analysis. The details of this log settings are as below:

The log review of altitude information,  ATT from log file of V type drone. The x axis depicts the time of flight while the y axis is degrees for roll and pitch while degree heading for yaw. We see in the logs that bothfrom the table or the pictorial graph we see roll and pitch leading desired values but Yaw is lagging desired value. It requires PID tuning to fine tune the value such that desired and actual are as close as possible. The PID tuning is discussed in the subsequent part of this chapter.

            Vibrations    High vibrations results in drone’s accelerometer based altitude and horizontal position estimates to drift far off from reality which leads to problems with altitude hold. This can result in the drone quickly shooting up in the sky in flight modes such as Loiter, PosHold, Auto, etc. Vibration levels below 30m/s/s are acceptable levels while above 30m/s/s may result in problems. The values  above 60m/s/s will surely cause problems with flight modes position or altitude hold. Hence, this analysis is key to ensure safe flight. The real time vibrations can also be seen during flight while post flight vibrations graphs can be seen in VIBE in log analysis. The details of this log settings are VibeX , VibeY and VibeZ which denotemeasured standard deviation of the primary accelerometer’s output in x, y and z axis respectively in m/s/s. Clip0, Clip1 and Clip2 are the values which increase each time one of the accelerometers reaches its maximum limit (16G)

The Realtime vibration measurements can be see from Mission Planner > Vibe Option

The log review of vibration information, VIBE from log file of V type. The vibration measurement along x, y and z axis of drone is below 30 m/s/s which is the desired output. Both from the table or the pictorial graph we see that vibration values as measured along all three axis is very low thereby validating the frame design and drone assembly. The x axis in graph is the time of flight and y axis is vibration measured in m/s/s for each of the axis of drone frame (x,y and z)

            Compass interference    Interferences to compass can be caused on drone by power distribution board, motors, battery, ESCs and other electrical devices. These can disrupt compass heading resulting in circling or drone flying in completely wrong direction. It is a very important parameter to look for to ensure optimum design considerations often requiring to tune the frame design. Post flight this data can help understand the behavior of the drone.  

The mag_field fluctuations are acceptable between 10-20% range when throttle is raised upto a max of 30%. Fluctuations above 60% is dangerous with increase in throttle. MagX, MagY and MagZ are raw magnetic field values for x, y and z axis respectively. OfsX, OfsY and OfsZ are raw magnetic offsets. They will only change if COMPASS_LEARN parameter is 1. MOfsX, MOfsY and MOfsZ are Compassmot compensation for throttle or current.

The log review of compass readings depicted by MAG and MAG2. We have two compasses on board. One inbuilt compass as part of BeagleBone Blue package while the other external compass as part of GPS package. The compass log information MAG and MAG2 from log file of V type drone. The Magnetic field measurements along all three axis is consistent thereby validating no interference from any other drone component.  The pictorial graph is showing measurements for both compass but table displays only one compass readings at any point of time. The x axis in graph is the time of flight and y axis is measured magnetic field in Gauss for each of the axis of drone frame (x,y and z) for both compasses onboard the drone.

            GPS glitches     The GPS glitch is an important parameter to evaluate during logs  analysis especially when flying in flight modes requiring GPS input to make decision suchas Loiter, RTL, Auto, etc. Position errors as a result of erroneous GPS readings can lead to unreliable or aggressive behavior of the drone. Two key fields to look for in GPS logs are Horizontal dilution of precision (HDop) and Number of satellites locked on to (NSats) values. Hdop < 1.5 is very good are very good while above 2.0 indicates a problem. The number of satellites < 12 is undesirable. The pilot must wait for these values to fall in range before taking off. A considerable change in these two values results in GPS position change. The GPS values during flight can be seen as GPS in log analysis. The details of this log settings are as below:

The log review of GPS readings depicted by GPS in log browser. The number of satellites during flight have been consistent as 14 which is > 12 (threshold value as discussed earlier). The HDOP is <1 which is well within the threshold of <2 for reliable flight. The altitude measurement has been consistent thereby confirming reliability of GPS as a sensor. The readings validate that there is no interference to GPS or GPS glitch thereby validating both the hardware status and the location of GPS on the drone has no interference from motors. The pictorial graph is showing measurements of important GPS parameters such as number of satellites, HDOP value, altitude value and latitude and longitude values. for both compass but table displays only one compass readings at any point of time. The x axis in graph is the time of flight and y axis is number for satellite count, decimal number for HDOP value, and latitude and longitude in degrees.

            Altitude variations EKF errors     The power to the all drone components is routed from the battery through the power module which also measures the voltage and current consumption if configured and calibrated. We need to see graphs of GPS, barometer altitude (BAlt) or altitude above home (CTUN Alt). The CTUN log gives us lot many details including throttle percentages ThH and ThO. It also gives us barometer altitude, desired altitude, terrain altitude and the climbed rates abbreviations are as below

Any sudden loss of altitude or abrupt reading co-related with GPS altitude readings can point to sudden power failure. The realtime EKF readings can be seen here:

We also need to understand how Ardupilot takes altitude reading both from sensor and its own estimation readings. The altitude above (mean) Sea Level (ASL) is the altitude of the drone with respect to the mean sea level (MSL) of the world. Altitude above Ground Level (AGL) the altitude of the drone above its rest position. Relative altitude is the one measured above HOME/ORIGIN position and is what is displayed in the ground station. OSD as the vehicle’s altitude. Terrain altitude (ALT) is the height above sea level (asl) of a terrain position. This may or may not any natural or man-made additions to the terrain’s ground altitude. Estimated altitude (ALT) is the  autopilot’s EKF estimation of vehicle Relative altitude above ORIGIN. This measurement is used internally by the drone’s Altitude Controller to maintain or obtain the Target ALT in flight modes such as ALTHOLD, LOITER/GUIDED etc where altitude is controlled. Target altitude (ALT) is the desired altitude in the above mentioned flight modes where altitude is maintained.

The EKF takes the IMU, GPS, and BARO sensor inputs and integrates them to provide this Estimated altitude (ALT).  The EKF subsystem is also responsible for estimating attitude, position and velocity of the drone which is utilized for navigation and control systems. The estimated altitude is then fed to the vehicle’s altitude control system. It attempts to reach the Target ALT in flight modes where altitude is maintained as mentioned before. The altitude controller can be fed terrain altitude data or data from range finder to attempt to reach target altitude. The flow of data for altitude control as as below:

The log review of ALT readings depicted by CUTN, BARO and GPS in log browser. We can see consistent altitude offset between Barometer altitude and GPS altitude. The Extended Kalman Filtering which integrates the measured values with the IMU data to estimate correct altitude shown as measured Altitude of CUTN. Here we see that CUTN Estimated Altitude is close to Barometer altitude and maintains a consistent offset with GPS altitude thereby providing reliable altitude measurements. Hence, the altitude estimation for the drone is reliable as per log analysis of V Type drone. The x axis in graph is the time of flight and y axis is the altitude in meters.

            Batt monitor errors   Battery monitor logs are the most important to view during the flight as well as after flight. The battery statistics are captured through APM power module between the battery pack and the power distribution board or DC-DC convertor.  The battery consistency is a must for reliable drone operations. Also, the battery experiences the maximum wear and tear after each drone subject to multiple conditions. Hence, its important to monitor any abrupt variations in battery voltage , current or energy consumption to estimate the overall operating state of battery pack powering the drone. Failure of battery pack is a single point of failure for entire drone and hence the logs must be reviewed in detail each time drone is airborne. The details of battery monitor (BAT) log settings is as given below:

The log review of BAT readings in log browser shows there is no inconsistency observed in the discharge of battery current or energy as seen from the logs. The voltage reading is fairly consistent too. The battery pack is able to retain charge and is able to provide and keep up with the power requirements of the drone. Hence,  we conclude after analyzing the BAT logs in log browser that the battery pack utilization has been consistent. The battery pack in this case 4s (16.8 Volts max) and 5200 mAh LiPo Lithium Polymer battery seems to be performing satisfactorily during the flight operation of the drone. These logs have been analysed after the flight of V Type drone. The x axis in the graphs is the time of flight while y axis is in volts for voltage readings, amperes for current, Watt second for energy and ohm for resistance. 

            Unexpected ERRORS codes during log analysis including Failsafes      The unexpected behavior of drone will generate the error codes by ERR for each log type and can be filtered out and analyzed for resolving them. The list of codes as below:

            Event Codes   The logs viewer also has the option of viewing events given by EV in the graph browser. The Event viewer codes are as given below:-

            PWM signal to motors and its output logs       RCIN & RCOUT  (Pulse Width Modulation (PWM) input and output to individual RC outputs ine motor/ESC combine.   The RCIN and RCOUT logs give us a view in to performance of each ESC/motor combine during the flight. RC1, RC2, RC3, RC4 incase of quadcopter and so on for any frame type gives details of Pulse Width Modulation (PWM) command sent by Ardupilot autopilot application during the flight to the ESC/motor/RC input and output. The RCIN and RCOUT log graphs have to be read in conjunction with mechanical errors described before using ATT and RATE. RATE is similar to ATT logs as explained earlier but gives the rate of change of yaw, pich and roll. ATT gives degrees of deviation between desired and actual values while RATE gives degrees per second deviation between expected and actual values for change in yaw, pitch and roll. These logs analyzed together can give important analysis for finding out about mechanical failures as well as requirement of tuning to improve stability of drone. The PID tuning is done based on the output of these graphs and will be discussed subsequently.

Below are important warning messages which are displayed in Mission Planner during flight and the same can be seen during the log analysis of RCOUT, ATT and RATE. Understanding them is critical to reliable functioning of the drone.

            Thrust Loss and Yaw Imbalance Warnings This warning is received mostly incase of incorrect hardware selection, hardware failure in propulsion system or improper tuning of PID values with respect to the frame type. If these warnings are displayed just with the take-off of aircraft then its more to do with hardware failure or poorly tuned aircraft but when received mid-flight its more likely a sudden hardware failure.

            Potential Thrust Loss            This message is displayed on GCS i.e Mission Planner or during log analysis signifies saturation of motor at 100% throttle. This mostly happens when one motor fails and the other tries to compensate for thrust loss of faulty motor/ESC combine.

As a result of this saturation, the Ardupilot autopilot application is unable to achieve desired /required roll, pitch, yaw and throttle output. This can potentially result in drone crash. A message like `Potential Thrust Loss (3)` signifies potential thrust loss for Motor number 3. We need to evaluate the RCOUT to see which motor failed for which this motor tried to compensate. In the screenshot of drone crash on 11 June 2021 clearly depicts motor 1 failed resulting in Motor 3 trying to compensate and going into saturation with potential thrust loss. As a result the drone flipped on right and crashed. The reason for failure of motor will need further analysis to find the reason for it such as mechanical failure of motor or ESC or simply propeller damage. This can be done by physical examination and table top testing.

If such error messages are received during hover or an altitude mode then it could probably be due to increased weight to thrust ratio requiring to retune to frame design and its components to reduce overall weight or change in propulsion system (motor/propellers). We must not that change in propulsion system must be done with proper drone calculations as higher propulsion system will require a bigger battery increasing the weight. This trade-off of thrust vs weight must be done as shown in chapter 1 earlier.

Incase of aggressive climbing and maneuvers, there is a requirement to lower the requested speed and acceleration.

Yaw Imbalance      The yaw imbalance warning depicts how much effort the drone is working on yaw. Incase of saturation, the ability of drone to maintain yaw is lost. 100% means complete saturation.  The message reads something like this giving percentage of yaw imbalance. `Yaw Imbalance 87%`. The yaw imbalance mode in hover or fixed altitude flight mode, the issue is most probably with the hardware. We need to evaluate the logs for PWN input signal in RCIN log settings and compare the PWN between pars in opposing motors. If  large throttle level difference between the clockwise and anti/counter clockwise motors is seen in the logs, then it is again likely due to hardware error. Most probably its when motors are not vertically on circular arms. This error can be cleared by rotating the motors to compensate for it as the thrust angle will assists the yaw in its rotation direction. If this yaw imbalance warning is seen during aggressive yaw maneuvers, the warning threshold need to be increased by raising ATC_RAT_YAW_IMAX in full parameter list.

Thus, after understanding all about configuration, fail safe pre arm checklist, understanding about logs and its impact on drone operations,  all the logs messages we are now in a position to finally tune PID values for advanced configuration options.

Other log evaluation options

IMU (accelerometer and gyro information)
GyrX, GyrY, GyrZ     The raw gyro rotation rates in radians/second for each of x,y and z axis
AccX, AccY, AccZ     The raw accelerometer values in m/s/s for each of x,y and z axis

Advanced tuning option for optimized flight operations

            In PID (Proportional – Integral – Derivative) tuning is a control loop mechanism by which the drone firmware stabilizes the drone/vehicle. P stands for Proportional which refers to the immediate Correction. The more we are off this value, the bigger is the correction. I stands for Integral which refers to over time or steady state correction. The additional corrections are added if we don’t make progress. D stands for derivative which means like take it easy correction. It slows down or dampen if the corrections are too fast.

            Roll/Pitch tuning, the rate parameter is the most important. It convert the desired rate of rotation into motor output. The Rate Roll and Pitch P tuning page has most information about tuning them. The Stabilize Roll and Pitch P converts the required angle into a desired rotation rate. This rate is thereafter fed to the rate controller. A higher value makes the drone/copter more responsive the inputs while lower value will make it smoother. A very high value makes  drone/copter to oscillate on the roll and or the pitch axis. A very low value makes drone/copter sluggish.

            Yaw tuning, the Stabilize Yaw and Rate Yaw parameters are used to tune yaw which in most cases does not require tuning. It is similar to roll and pitch. If the value is too high the drone/copter will oscillate else will be unable to maintain heading if too low.

            Altitude Tuning, hold related tuning parameters. Altitude Hold P is used to convert the altitude error which is the difference between the desired altitude and the actual altitude in order to maintain desired climb or descent rate. It the value is high, the drone/copter will make aggressive attempt to gain altitude and very high will give jerky throttle response to pilot inputs.

            The Throttle Rate more than often does not require any change. It converts the desired climb or descent rate into a corresponding acceleration up or down. The Throttle Accel (Proportional – Integral – Derivative) PID gains convert the acceleration error. It is the difference between the desired acceleration and the actual acceleration into a motor output. The 1:2 ratio of P to I is recommended to be maintained.

            Loiter Tuning, does not require much tuning in the case Roll and Pitch are tuned correctly with GPS working well and vibrations below accepted levels.

Mission Planner > Config > Extended Tuning