Autonomous Quadrotor – Collision Avoidance Simulation using Twin Activate and MotionSolve

John_Dagg_0

Overview

INTRODUCTION

As drones become increasingly prevalent, collision avoidance is emerging as a critical feature of drone technology. Drones are used for many purposes, ranging from surveillance to delivery, increasing the risk of mid-air collisions. To mitigate this risk, simulation tools like Altair’s MotionSolve and Twin Activate are being used to create robust collision avoidance systems. Traditional methods of collision avoidance control systems like real-world trials are costly and time-consuming. Simulation allows for testing and refinement of collision avoidance control systems without risk of expensive collisions.

In this example, we build a simple model of a collision avoidance control system in Altair’s Twin Activate, an intuitive 1D physics-based modeling software. Meanwhile, Altair’s MotionSolve, a multibody dynamics software, handles drone dynamics and collisions between the 3D models. The 3D geometry is built using Altair’s Inspire.

MODEL CREATION

Initially, the drone control system was built and tested without collision avoidance. Geometry was built in Altair’s Inspire and imported into MotionView. Then the control system for the drone was created in Twin Activate. After verifying the co-simulation functioned and the drone was capable of following a trajectory, collision avoidance functionality was incorporated into the model.

Understanding the Model Definition in Twin Activate

Overall Activate Model

1. Twin Activate generates a reference trajectory for the drone to deliver a package to a rooftop.
2. The drone system accepts the reference trajectory and returns the drone position, attitude, and obstacle location at each timestep.
3. The collision avoidance trajectory correction calculates an updated trajectory to avoid any obstacles observed by the drone.

Drone Control System

4. The drone’s control system calculates the required torques and thrust the vehicle must experience to reach the reference position from the actual position. Then it calculates the required velocity for each propellor to achieve the necessary net thrust and torques. Finally, a PID controller calculates the output to the motors based on the required propellor and current velocity.
5. A simple model of an electric motor and propellor is used to calculate the thrust generated by each propellor.
6. The thrust for each propellor is provided to MotionSolve which handles the model multibody dynamics. MotionSolve returns the drone position, attitude, and obstacle position. The MotionSolve solver deck (.xml file) is provided to Twin Activate allowing the programs to communicate.
7. A battery pack model calculates the state of charge based on the motor current draws.

Understanding the Model Definition in MotionSolve

The MotionSolve model comprises two drones: one operated by Twin Activate and the other functioning as an obstacle. The Twin Activate-controlled drone relies on the thrusts computed by Twin Activate to propel its motion. Conversely, the obstacle drone adheres to a predetermined motion profile. Throughout each timestep, the obstacle drone's position, typically detected via a camera or photoelectric sensor, is relayed to Twin Activate. Additionally, the model features a building where the Twin Activate drone drops a package at the end of the simulation.

Pre-Requisite

SOFTWARE REQUIREMENTS

Altair MotionView (2024 or newer)

Altair MotionSolve (2024 or newer)

Altair Twin Activate (2024 or newer)

MODEL FILES

Quadrotor_Model.zip (See attachments)

Usage/Installation Instructions

MODEL SETUP & SIMULATION STEPS

1. Open Quadrotor_MBD_archive.mdl in MotionView.
2. Open Quadrotor_Collision_Avoidance.scm in Twin Activate.
3. Run the model in Twin Activate.
4. Results will populate in the Results folder.
5. Open a new page in MotionView and change the client to HyperView.
6. Open Quadrotor_Results.h3d in the HyperView client to view the results.

Post-Requisite

RESULTS

The baseline model was tested prior to adding collision avoidance. The Twin Activate controller caused the drone to accurately follow a position trajectory. Attitude and position were reasonable throughout the simulation. Once the model was verified, collision avoidance was added to the model.

Twin Activate Model Verification without Collision Avoidance

After beginning the simulation, Twin Activate automatically creates graphs of the drone’s state. The drone closely follows the reference trajectory in the X and Y directions. There is noticeable deviation for Z position at 20 seconds because the drone drops the package decreasing the weight of the vehicle. The yaw PID controller poorly adjusts the drones yaw throughout the simulation. The state of charge of SoC decreases linearly. Finally, the correction trajectory shows the change in the trajectory from the initial trajectory due to obstacles.

Position, Yaw, State of Charge, and Trajectory Correction

Autonomous Drone Collision Avoidance Maneuver

The controller can compensate for an increased package mass. The graphs below demonstrate the change to propellor speed for an increase in mass from 200 grams (blue) to 300 grams (red).

Front Right Propeller Speed for Different Package Masses

Blue – 200 grams | Red – 300 grams

Front Left Propeller Speed for Different Package Masses

Blue – 200 grams | Red – 300 grams

Back Left Propeller Speed for Different Package Masses

Blue – 200 grams | Red – 300 grams

Back Right Propeller Speed for Different Package Masses

Blue – 200 grams | Red – 300 grams

CONCLUSION

As drones become widely adopted, drone technology must adapt to a larger number of drones. To reduce costs and save time, control algorithms can be accurately tested and evaluated by using simulation under a wide array of conditions. Simulation allows drone algorithms to be tested under any number of conditions in a completely controlled environment. The model shown in this example serves as a simple demonstration. More complex models can be developed that account for wind, air density, and temperature.

AUTHORS

John Dagg, Systems Engineering Intern

Christopher Fadanelli, Solution Engineer - Systems Integration