Background

Goal

Easily create autonomy applications by combining modular state behaviors into domain-specific state machines. Use generic interfaces for quadcopter and manipulator hardware which allow users to adapt existing hardware drivers to the framework.

Project

The goal of the project is to create a generic state machine interface for the quadrotor and arm to do different tasks such as “pick and place”, “screwing a lightbulb”, “AR manipulation”, etc. This requires different types of controllers, estimators and state logic based on the task at hand. The framework consists of the following main components:

Robot System
1. Controllers
2. Hardware Plugins
3. Estimators
4. ControllerHardwareInterfaces
LogicStateMachineFrontEnd
StateMachineGUIConnector
GUIFrontEnd
OnboardSystemHandler

Setup

The setup and brief README for the project is presented here

Components

Robot System

The robot system owns privately the hardware, controllers, estimators and controller-hardware interfaces. For the public interface it provides methods to retrieve sensor/estimator data, and select and set controller goals for the robot.

Component	Description	Link
Hardware	Send commands to hardware and retrieve raw sensor data	UAVSystem
Controllers	Provide run function that returns the controls to send back to hardware based on sensor data	BuiltInController
Estimators	Compute the robot state/parameters based on raw sensor data	None
Controller-Hardware Interfaces	For a single controller, extracts sensor/estimator data from hardware, passes it to the controller run function, and sends the resulting control commands to hardware	ControllerHardwareConnector

Logic State Machine (LogicStateMachineFrontEnd)

The Logic State Machine (LSM) contains the behavior necessary to achieve a desired task. Each state in a logic state machine contains a run function that executes state-specific behaviors and triggers appropriate state transitions. The LSM behavior is executed at a user-defined frequency

The LSM also provides a sub state machine for checking the health of the hardware based on sensor data, and health reported by the hardware plugins. The state of this submachine is used to guard the transitions between different states. For example, if the quadrotor has a low battery warning, the quadrotor will not accept a goal command to fly to a goal far away. If the battery level is critical, the health sub machine may trigger a land event automatically.

StateMachineGUIConnector

The StateMachineGUIConnector connects the GUI interface to the state machine. It provides a message based interface for triggering manual state transitions through the GUI. These actions can be very generic - such as buttons for “start mission” and “start tracking” - and can be specific such as “land”.

GUIFrontEnd (aerial_autonomy.aerial_autonomy_gui.EventTransmissionGUI)

The GUI contains a text box that updates the status of all the hardware plugins and the state machine. The status of the hardware plugins include the health information of the hardware and the state of the hardware in the world. The state machine status includes information about the current state and any events that are not accepted by the state machine. In addition, the GUI should be able to send manual triggers to the state machine that are generated by the user. Here is an example GUI FrontEnd:

Todo:: Add picture of latest GUI with quad status etc

The Triggers should be connected to the StateMachine using StateMachineGUIConnector class. The triggers are events without any information. There can also be commands with information using Rviz goalpose callbacks to send the drone to a specific location.

Event Generation

The events that trigger state machine transitions are created using event files in the events folder. The event header files are generated using CMakeLists similar to ros messages. The syntax for the event files is as follows:

EventManager:  # Event manager name
   event1 # Event name
   event2 # Event name

The event files can also include other event file as shown in visual_servoing_events file. The event manager class provides a function to trigger events for the state machine by name. The GUI takes in an event file and automatically creates buttons corresponding to events. The user can then trigger the events by pressing buttons in GUI

Classes segregated into groups

The classes created in this project can be found here