Hardware-In-the-Loop Simulation of Time-Delayed Anti-Swing Controller for Quadrotor with Suspended Load

Abstract

Quadrotor flying vehicles with suspended loads have a lot of applications, such as mine detection and transferring loads for delivery, or through places where ground vehicles cannot reach. In these applications, the payload will be suspended underneath the vehicle and it is subjected to large oscillations due to external disturbances or the acceleration of the vehicle itself. These oscillations add additional forces and moments to the quadrotor, and this deteriorates its performance and stability. In this paper, we developed a hardware-in-the-loop (HIL) simulation platform for a quadrotor with a suspended load system using Gazebo. The developed platform can be used to understand the dynamics of the system and design control systems to suppress the oscillation of the suspended load. An anti-swing controller that is based on time-delayed feedback of the load swing angles is implemented in the designed HIL environment to show the usefulness of the newly developed system and the effectiveness of the anti-swing controller.

1. Introduction

In recent years, the demanding nature of civilian and military applications has brought significant attention to autonomous vehicles. Moreover, to provide a solution to distinct applications which cannot be handled using land or water, flying vehicles are the only choice. Furthermore, applications that require hovering and vertical take-off further limit solutions for autonomous vehicles and rotary flying vehicles, such as helicopters and quadrotors [1].

The quadrotor vehicle has more advantages compared with the helicopter, such that the presence of four rotors allows for load distribution and enables the quadrotor to have smaller rotor diameters, and hence smaller vehicle size, as compared with the single rotor helicopter. Furthermore, the smaller rotors store less kinetic energy per rotor and thus reduce the extent of damage in the event that the vehicle is involved in a crash. In addition, rotors can be protected by enclosing them within a frame.

Unmanned quadrotors, with the capability of handling suspended payloads with a cable, can be used in situations where normal land vehicles either cannot reach or are not recommended to be used. Applications such as tracking moving targets, photographing for surveillance, rescue operations for natural disaster areas, discovering mines, or inspecting gas and oil pipelines that exist in remote or hazardous areas are better operated with aerial vehicles [2].

A vehicle with a suspended load system can be treated as a multi-body dynamical system. The pendulous motion of a suspended payload with a cable can limit the applicability by either slowing down the flying vehicle or can damage the load itself. Moreover, the pendulum oscillation may prevent an accurate alignment during the pickup and/or placement of the load. In reality, a violent suspended payload swing due to a wind gust or pilot input can cause an accident [3]. It is thus critical to limit the payload swing to improve safety and performance [4].

In recent years, the delivery of packages has become an attractive application for multi-rotor vehicles, especially quadrotors. Many companies started offering this service, such as Amazon [5]. The payload can be attached to the quadrotor with a rigid connection or it can be suspended underneath the quadrotor by a cable. The rigid connection is the most common because of its practicality and simplicity. However, it is not suitable for heavy and large size packages, and in some situations, it may not be possible to land the vehicle. Moreover, with this configuration, the inertia of the quadrotor will increase significantly, which will reduce its maneuverability [6]. With a suspended load, large packages can be carried with one or more quadrotors. This configuration allows delivering the package without the necessity to land the vehicle, which improves the mission efficiency. However, it will complicate the dynamics and the performance of the quadrotor, especially when controlling the position of the payload in windy scenarios. Therefore, many researchers have recently started to develop control systems for the quadrotor with suspended load to stabilize the vehicle and suppress the oscillations of the load, alongside attaining accurate pickup and positioning of the load.

It is expensive and time-consuming to develop and test algorithms for autonomous vehicles in the actual world. Quadrotor simulations must be conducted prior to the UAV’s actual flight to limit the danger of property damage caused by aircraft crashes, system failure, or controller malfunction. Different simulations, such as numerical simulations, software-in-the-loop simulation (SIL), hardware-in-the-loop (HIL) simulation, and actual tests on testbeds, can be used to avoid these problems from arising; moreover, these methods make it possible to test and build multirotor vehicles safely and cost-effectively.

SIL simulation relies mainly on a separate computer where the flight code is completely simulated, along with a sensor model and vehicle dynamics to provide similar results to those of a real-life experiment; SIL is mainly used during the development stage of the simulation model. The SIL platform relies on UDP and TCP communication among its various parts, this communication is mainly governed by what is known as Lockstep, which is a technique developed to synchronize all the simulator parts together to avoid any packet loss or desynchronization between them. Lockstep issues a command for each cycle, performed by the controller to mimic the operation in real life [7,8].

HIL is a good tool for evaluating the performance of deployed models and algorithms on real-world hardware. The HIL simulations run the flight code and algorithms on the real-time computer, models the vehicle dynamics on the host computer, feeds data through a serial connection, and then visualizes the received responses [8,9,10].

Most HIL systems are developed for simulating the quadrotor only [11,12,13,14]. Recently, SIL simulations with Gazebo and PX4 were conducted by Graham [6] for a quadrotor with a suspended load. The intentions were to test his design for a landing system. However, no HIL simulations for the quadrotor have been demonstrated; therefore, there is a gap which must be filled by researchers.

Pixhawk hardware has been widely used for UAV applications in recent years [15]. It offers high-quality autopilot hardware at a low cost and with a high level of availability. Furthermore, the open-source code PX4, which is autopilot firmware for driving unmanned aerial and ground vehicles, can be installed on this device. Pixhawk can be used in conjunction with simulation software, such as Gazebo, to create a HIL system. [16,17,18].

The Gazebo software is popular in the robotics community and is completely open-source so that the user can easily define 3D virtual worlds, sensor models, and communication protocols. In particular, this software contains the open dynamics engine (ODE), which can present a system model robot with high accuracy in real-time conditions. ODE can provide real-time dynamical simulations and the corresponding sensor readings for the UAVs [18,19].

The present paper is organized as follows: The quadrotor model of the quadrotor and the suspended load is given in Section 2; the suggested controller is given briefly in Section 3, followed by the procedure to develop the HIL environment in Section 4. The simulation results are discussed in Section 5. The conclusion is given in Section 6.

2. Quadrotor–Load Model

The quadcopter used has a cross structure, as shown in Figure 1. It consists of a frame with four motors that provide the forces that lift and move the vehicle. The suspended load is attached to the center of the frame.

The quadcopter with a suspended load system can be considered as a multi-body dynamical system [20]. Two frames are typically used to describe the movements of a quadrotor vehicle. The earth frame, also known as the inertial frame, is the first frame. The second frame is a body-fixed frame, in which the origin OB represents the quadrotor’s center of mass.

The position of the quadrotor body frame with respect to the earth frame is given by x, y, and z, which represent the longitudinal, lateral, and vertical motions, respectively. The orientation of the body frame with respect to the earth frame is given by the angles ϕ, θ, and ψ, which represent the roll, pitch, and yaw, respectively [21].

The suspended load can be described as a point mass that behaves as a spherical pendulum. Therefore, its motion can be described by two angles, θ_L and ϕ_L, where ϕ_L is the load oscillation angle in the xz plane, and θ_L is the load oscillation angle out of the xz plane.

3. Quadrotor Controller

The configuration of the proposed controller which will be implemented in the developed HIL environment is shown in Figure 2. It consists of two control systems: an anti-swing controller and a tracking controller [22].

3.1. Tracking Controller

The objective of the tracking controller is to follow the original trajectory of the quadcopter and the additional trajectory that is generated from the anti-swing controller. So, to follow the quadcopter trajectory, the six outputs of the quadrotor $(x,y,z,\varphi ,\theta ,\psi )$ must be controlled. However, selecting all these six outputs will induce an under-actuated system, as there are only four inputs. To overcome this problem, a double-loop architecture method is adopted as shown in Figure 3 [23,24]. The function of the inner loop is to control the attitude angles and the altitude $(\varphi ,\theta ,\psi ,z)$, while the function of the outer loop is to follow the desired trajectory in the x and y directions by providing the inner loop with the desired angle values. As a result, the quadrotor is stabilized at a desired height and yaw angle by the inner loop controller, while the outer loop stabilizes it in the x and y directions. To achieve stability, the inner loop must be substantially quicker than the outer loop.

The controller used in the open-source flight controller (PX4) is the PID controller. More details about the structure and design of the tracking controller implemented in the open-source PX4 autopilot can be found in [25]. In this controller, it is assumed that the motion is just a perturbation from the hovering condition. The PX4 firmware used in this work is the V1.12.3 release [26].

3.2. Anti-Swing Controller (ASC)

The objective of the ASC is to suppress the oscillations of the suspended. The time-delayed feedback gives a correction trajectory, which adds to the reference trajectory [27,28]. This correction trajectory is given by the following equations:

$$x_s=-K_{sx}L\hspace{0.17em}{\varphi }_L(t-t_{sx})$$

(1)

$$y_s=-K_{sy}L\hspace{0.17em}{\theta }_L(t-t_{sy})$$

(2)

where K_sx and K_sy are the feedback gain and t_sx and t_sy are the time delay of the swing angles in the x and y directions, respectively. By proper selection of these values, the load swing angles will stabilize and vanish. This feedback scheme is easy to implement. Moreover, only minimal knowledge of the system is required. The only quantity of the system that needs to be known is the oscillation period TL of the load which is given by the following:

$$T_L=\frac{2\pi }{\sqrt{g/L}}$$

(3)

The parameters of the ASC can be tuned to give the best damping for the suspended load. To measure the level of damping, the integration of the swing time history (ISH) is calculated according to the following equation:

$$ISH={\displaystyle \int \left({\varphi }_L^2+{\theta }_L^2\right)}\hspace{0.17em}dt$$

(4)

According to Equation (4), the level of damping will increase with a decrease in the ISH index.

3.3. Swing Angle Sensor

The ASC is suggested to be implemented in Pixhawk autopilot board. The implementation needs the measurement of the load swing angles which can be performed by two methods. In the first method, the swing sensor can be connected directed to the pixhawk analog to a digital (ADC) port, while the other is a non-contact one, where an inclination sensor is placed on the load and emits its signal either through wired connection or Bluetooth. In both cases, the sensor data is routed through the Pixhawk board to ensure the readings are synchronized to the main flight controller readings and then processed after relay on the companion computer. In this work, the non-contact measurement method will be used, which is based on an inclinometer that takes its measurements through an inertial measurement unit (IMU).

4. HIL Simulation

The HIL simulation is carried out to test the validity and performance of the controller and its impact on the autopilot performance in operation. The simulation system is separated into three main parts:

• The quadrotor and load dynamics simulation;
• The autopilot sensors simulation;
• The communication and synchronization between the different parts.

The quadrotor dynamics and sensor simulation is handled by Gazebo, which is an open-source robotics simulation framework that provides flexible and extensible environments for modeling and simulating various types of vehicles and environments, including our platform, a quadrotor, and its onboard sensors [29].

The communication is based on the Mavlink protocol, which is the standard communication protocol for micro aerial vehicles, and is handled by an open-source robotics framework for communication and data transfer between multiple components and systems, that relays stamped messages, states, commands, and other data through a serial connection, such as USB, UART, UDP, or TCP remote connection through WIFI [30]. Figure 4 shows the communication diagram during the HIL simulation [31].

4.1. Load Model

The suspended load is connected to the quadrotor on a ball and socket joint which allows rotation in the three axes with no translation. For simplicity, the rotation around the central axis “z” is disabled since it is not the focus of the control point of view. The connecting rod is then fixed to the load and the sensor is attached to it.

The joint structure in Gazebo is built up from a chain of simple joints, mostly fixed joints and one DOF joint. These simple joints are hierarchically connected by what are called virtual or dummy joints. These dummy joints serve the purpose of defining the allowed degrees of freedom individually. Therefore, the ball joint can be described in the Gazebo as two virtual one-DOF joints in the in the-plane swing direction (ϕ) and the out-of-plane swing direction (θ) with a fixed joint at the end that attaches to the load, as shown in Figure 5 and Figure 6.

The joint configuration and drone joint model is displayed in Rviz, which is an open-source visualizer tool for robotics applications [32], as shown in Figure 7. This helps in checking for joint interaction and limits in a clear visual manner.

4.2. Gazebo Implementation

The Gazebo platform relies on an XML-based file format named SDF, which stands for Simulation Description Format—this is either written directly or generated from a scripted format under the name URDF (Universal Robot Description Format), or from macro format under the name XACRO. These formats ease the building of complex robots as they rely on defining the main components of the robots and connecting them through joints and links. Complex robotics rely mainly on templates generated from the XACRO format to produce URDF for defining the robot and then automatically converting it to SDF using ROS. This benefits in the ability to define joint controllers and ROS controllers, which allow the control of the robot and manipulation of its parts using ROS API that manipulates the Gazebo simulation.

The hinge is composed of two single DOF joints as stated before that rotate in the $\varphi -\theta$ planes. Empty links are attached to these joints then fixed to the main link. This link represents the rod that is fixed to the suspended load using a fixed joint to avoid any unnecessary movements or rotations. Figure 8 shows a simple hierarchy tree for the drone and load model that is displayed in its ground state in Figure 9, and in its flying state in Figure 10.

4.3. Sensor Details

To simulate the inclination sensor, a gazebo sensor plugin for an inertial measurement unit (IMU) is used and placed, using a fixed joint, on the load part. This sensor allows the measurement of the inclination angles of the load, relative to their fixation point on the quadrotor and their rates. This data is published on both a Gazebo link state and a separate sensor ROS topic, so it can be later processed. Below is the code snippet for the sensor and defined parameters that are appended to the SDF. The sensor adds a Gaussian noise to simulate real-life performance and has a switch to turn on or off, in case it is needed to simulate a failsafe. The update and publish rate is also variable and can be easily adjusted to different rates to suit the performance needs.

<gazebo>

<plugin name=“imu_plugin” filename=“libgazebo_ROS_imu.so”>

<alwaysOn>true</alwaysOn>

<bodyName>base_footprint</bodyName>

<topicName>imu</topicName>

<serviceName>imu_service</serviceName>

<gaussianNoise>0.0</gaussianNoise>

<updateRate>20.0</updateRate>

</plugin>

</gazebo>

This plugin publishes its reading to a ROS topic defined by the parameter “<topicName>”, this data is then synchronized with the PX4 using a Mavlink message through MAVROS then sent to the control algorithm.

The plugin approach can be replicated by reading the link state directly from gazebo, but it is better to use external plugins to measure drone behavior on the readings.

4.4. MAVROS Plugin

MAVROS is a communication node between ROS and the Mavlink protocol to facilitate algorithm and application development. The Mavlink system sends data in a structured format called “messages”, where the message is instantiated as an object and its contents are parameters to that object. The code below shows the structure of the “swing_angles” message that was created specifically for this work.

uint64 timestamp # time since system start (microSeconds)

float32 phi # Phi swing angle

float32 theta # Theta swing angle

float32 phid # Phi swing angle rate of change

float32 thetad # Theta swing angle rate of change

The message contains a timestamp header to ensure synchronization with the main IMU in the Pixhawk. The plugin performs two main functions: during simulation, it is used as a relay for the simulated sensor from the Gazebo to the controller and the PX4 module through Mavlink; meanwhile, in real testing, the plugin receives the sensor message from the PX4 and relays it back to the companion computer and then publishes it through ROS for the controller. The first function is useful in determining the suitable update rates that can function correctly with the PX4 firmware and various Pixhawk boards, without overloading the processor with a large data stream.

4.5. Mavlink Message Definition

The Mavlink message sent by Mavros should be defined in the Mavlink headers of both the sender and receiver; thus, the Mavlink headers in both Mavros and PX4 are regenerated with the newly enumerated message so it can be transmitted. This enumeration follows the Mavlink message template definition so it can be implemented to any Mavlink-supported flight stack. The message definition snippet is shown below.

<message id=“228” name=“SWING_ANGLES”>

<description> Transmit swing angles from suspended payload sensor to Pixhawk</description>

<field type=“uint64_t” name=“time_usec” units=“us”>Timestamp (synced to UNIX time or since system boot).</field>

<field type=“float” name=“phi”>Swing angle Phi</field>

<field type=“float” name=“theta”>Swing angle theta </field>

<field type=“float” name=“phid”>Swing angle rate Phi</field>

<field type=“float” name=“thetad”>Swing angle rate theta </field>

</message>

4.6. PX4 Application for Real-Time Data Viewing

PX4 is developed upon the NuttX, a Linux real-time operating system (RTOS), and it contains a console for control and debugging. Using this console, several apps can be developed to be used directly on the PX4 without the need for external computers. An app has been developed to read and view the “swing_angles” topic, that is published on the PX4, so the data can be quickly debugged and monitored on the fly. The app can also be set up to infinitely display data upon request. Below in Figure 11 is the output of the NuttX console when the application is running in real-time on a Pixhawk 1 board using the HIL simulation.

The application can later be extended to include the ASC controller as a part of the PX4 software stack to eliminate the need for a companion computer. This eliminates the external delay that can occur due to the transmission and external processing delay.

4.7. Data Logging Interface

An interface was designed using Python and Qt, a dynamic robust framework for developing graphical user interfaces (GUI) applications, to facilitate the process of simulation and data logging, as shown in Figure 12. The interface provides a real-time representation of the quadrotor states and the load states directly from the sensors. It also provides the ability to quickly modify controller gains and drone parameters. The interface is also connected to RQT [33], an open-source data logging system and visualizer for ROS-based applications, to provide more control and visualization tools for the simulation. The main features are developed based on ROS, and the drone model modification capabilities rely on parsing the SDF files and launch files. The interface provides the ability to run any configuration through a launch file and the ability to add or customize any feature, such as running a simulation multiple times or launching pre-configured instances of other software, such as RQT or RViz, for more features [32]. Another addition is the ability to log and save a synchronized version of the states that are used later in for post-processing, debugging and/or analysis of the data. This is a handy feature that really saves the trouble of frame matching the data readings and multiple simulation clocks between nodes and topics.

The interface also has the capability of modifying the internal parameters of PX4 on the fly through its use of Mavros as shown in Figure 13. Further, the choice of Qt for GUI development provides the freedom for customization and ease of simulation and testing and extension to include embedded visualization tools as shown in Figure 14.

4.8. Controller Implementation

The controller was written in Python for ease in development; it receives the discretized analog signals from the Pixhawk and then converts them to the desired angles after applying noise filters if required or calibration biases. The data is then used to calculate the delay values. The controller node operation is delayed by the desired value that is calculated dynamically through operation and then the generated trajectory is calculated and then added to the main vehicle trajectory, to be then published as position setpoints that the quadrotor can track. Figure 15 shows the code flow of the controller implementation.

5. Simulation Results

The inertia and propulsion system properties of the quadrotor model used in the simulation are listed in

Table 1. Parameters of the quadcopter and the suspended load.

Symbol	Description	Value	Unit
m	Quadrotor mass	1.585	Kg
Ixx	Quadrotor moment of inertia in the x, y, and z directions	0.018636482	Kg·m2
Iyy		0.020027499
Izz		0.02788
d	Quadrotor arm length	0.252	m
Cm	Motor moment coefficient	1.39 × 10−7
Ct	Motor thrust coefficient	9.79 × 10−6
Cdf	Quadrotor fuselage drag coefficient	0.055
Cdm	Motor drag coefficient	0.003
mL	Suspended load mass	0.27	Kg
L	Suspended load cable length	1	m
(xh, yh, zh)	Hook suspension point	(0,0,–0.1)	m

.

5.1. Hover Flight

The suspended load is subjected to a disturbance of 30 degrees in both directions. This is carried out by directly changing the joint state in the Gazebo simulation or by enforcing force disturbances on the load, but the first yielded better and more accurate state changes. The time history of the load swing angles is shown in Figure 16, while the time history of the quadrotor position in the forward and lateral directions is shown in Figure 17, without including the ASC. It is observed that the quadrotor tracking controller can dampen the oscillations of the suspended load due to the moments generated on the quadrotor from the motion of the suspended load. The tracking controller implemented in PX4 was able to return the quadrotor to its initial position. This indicated that the system is stable with this controller. The ISH determined for this flight maneuver is 0.6752.

In the second maneuver, the ASC is implemented as described in the previous section with the following parameters $K_{sx}=K_{sy}=0.6L$ and n. After including the ASC in the control loop, it is observed that the oscillations history of the suspended load was improved in both directions, as shown in Figure 18. The deviation of the quadrotor from the hover is smaller compared with the uncontrolled case, as shown in Figure 19. The ISH determined for this maneuver is 0.4271. Therefore, the reduction is 36.7%.

5.2. Travel Flight

To measure the effectiveness of the ASC during travel flight, the quadrotor is subjected to a trajectory pattern that involves moving the quadrotor a step in the forward direction (x) by a distance of 3 m, then in the lateral direction (y) by a similar distance, and finally returning the vehicle to the hovering point. The ASC parameters are the same as the ones used for the hovering flight.

The time histories of the load swing angles are shown in Figure 20 and Figure 21 with and without the ASC. The quadrotor trajectories in the x and y directions with and without the ASC are shown in Figure 22 and Figure 23, respectively. It is observed that the oscillations were reduced when using the ASC. The ISH values are decreased from 3.7238 to 1.8930 when the ASC is implemented amounting to a reduction of about 49.2%. Moreover, the effects on the quadrotor trajectories are very small.

5.3. Numerical Simulation

To check the results obtained from the developed testing platform, the proposed ASC is simulated numerically with a tracking controller that is similar to that one implemented in PX4 firmware, Figure 24. The time histories of the load swing angles with and without the ASC, due to an initial disturbance in hover flight, are shown in Figure 25 and Figure 26, respectively. We can observe the same trend—the ASC can improve the damping of the suspended load oscillations. The differences in the initial swing angles are due to the method of generating these initials values. The same trend can be observed also in the forward flight.

6. Conclusions

A robust testing platform was developed for quadrotors with suspended loads that is based on the hardware-in-the-loop simulation concept. The new platform allows the researchers to develop new controllers and test them safely and inexpensively for various flight scenarios and maneuvers, with the capability to simulate the disturbances that occur in a real flight. The Gazebo simulator provides researchers with a good tool to build the physical model with all the necessary sensors of the flight vehicles, without the need to deal with the complexity of the mathematical modeling. The usage of ROS facilitates real-time monitoring and logging of the flight.

The developed platform was used successfully to implement and test an anti-swing controller for the quadrotor suspended load system. This controller is based on the time-delayed feedback of the load swing angles. It was observed that the controller was able to improve the damping of the load oscillations in different flight scenarios. The testing platform was verified by comparing its results with the numerical simulations using Simulink modeling.