The LowLevelMotionController node contains all of the controllers that run on the main computer (as opposed to the flight controller). For more information on what a controller is, the beginning of the wikipedia article for a PID controller is a good place to start.

Philosophy

Low level motion has four major goals:

• Accept requests for motion in a linear format such as velocities and accelerations
• Robustly attempt to execute requests while assuming availability of certain sensor data will be unreliable
• Support different controllers for different physical states and availability of sensor data
• Sanity check control outputs to the flight controller to avoid loss of control

IARC 2016-2017 Low Level Motion Design

Overview

IARC 2016-2017's Low Level Motion supported two controllers, a takeoff controller and a general purpose velocity controller. The general purpose velocity controller supported two planners, the general purpose acceleration planner and the land planner.

The initial design of IARC 2016-2017's LLM was to be a simple acceleration planner and general purpose velocity planner. However, during development it was realized that different types of controllers were needed for different situations. Thus, the concepts of supporting multiple controllers was born. However, the result was a very hacked together LLM that will need significant refactoring and redesign.

General Purpose Velocity Controller

During normal flight, the setpoints for the controllers were velocities sent by the motion planner. The AccelerationPlanner handles interpolating these velocity requests. The QuadVelocityController then runs PID controllers on the errors in our x, y, and z velocities to hit these setpoints. Because PID controllers perform best when they are controlling a linear system, the controller uses a model of the drone's dynamics to linearize as much as possible. The output of all of this is a set of numbers for pitch, roll, yaw rate, and throttle which are published on the /uav_direction_command topic to be sent to the flight controller.

Takeoff

Because it is impossible to linearize the takeoff behavior of the system, we have a different controller that runs in that case, the TakeoffController. This controller ramps the throttle until the drone is barely touching the ground. It then takes measurements of the current throttle, battery, and the distance from the props to the ground, and uses them to calibrate the drone model. The controller then hands of to the in-flight controller, the QuadVelocityController.

Landing

Landing is a special operation that could require accounting of ground effect. It was decided to make this into its own system.

Landing uses the LandPlanner to send velocity requests to the QuadVelocity controller. Once a certain height is reached a different velocity request is sent to avoid crashing into the ground. The LandPlanner uses the ground contact sensors to detect when the ground is reached.

Safety Response

When a safety response is received LLM will attempt to land using the LandPlanner.

Sanity Checking

All requests to the FC are sent through the QuadTwistRequestLimiter which is supposed to be an easy to read and understand way of limiting the max and min values sent to the flight controller as well as the max rate of change of any of the control inputs. This allows us to detect when are controllers are oscillating wildly. Max and min control limits are also checked by FC_comms however rate of change limiting is not performed.