The current prototype is operating using a house-made 3D printed frame, with parts all designed and refined through a rapid prototyping process. The controller architecture leverages a cascaded control scheme, where the inner-loop controller is dedicated to handling fast attitude corrections and PWM signal generation (used to operate the brushless DC motors in tandem with a dedicated electronic speed controller – ESC), and the outer-loop control is charged with platform communication and guidance. Since the timing of the inner-loop is dictated by the PWM pulse-length (at minimum 2ms/loop) we chose to leverage an Arduino Nano’s (16 MHz) small profile to fill this roll. Since much of the computational load is handled by position control, trajectory generation, and communication, the outer-loop guidance controller was chosen to be a TEENSY 3.6 (180 MHz), which offers a significant performance boost, while still being able to interface easily with the Nano’s architecture. (Final construction shown below)
Communication Network Design
In addition to the baseline quadrotor development, the interfacing peripheral hardware to control and interact with the platform was developed. A popular intuitive method for interfacing with any robotic system is a graphical user interface (GUI), as it can be used to both send command information and display quadrotor telemetry in a meaningful manner. Since the quadrotor position control is sensitive to the GPS update rate, one factor considered was the partitioning of the GPS data-stream from the GUI. This partitioning also has the added advantage of having more graphically heavy display methods for rendering trajectories, network maps, and potential fields.
Virtual Reality (VR) Integration
Throughout the design of the hardware test-bed, a visual interface using Blender and Python is also developed to allow for the end-user to intuitively interface with and control a given agent. Features include standard joystick control, manual obstacle placement (virtual obstacles), live obstacle tracking (webcam-openCV interfaced), and live telemetry feedback, with recording and storage capabilities.
As this work on the quadrotor test-platform transitions from a design and troubleshooting, towards implementation of control algorithms and end-user interfacing, one key point of interest has been the adaption of modern VR technology into swarm control and network modifications. In particular, we want to design an interface that allows for the user to intuitively make active modifications a network of flying agents, and control the swam without having to instruct each agent explicitly (the basis of formation control). There are a number of incredible methods for interfacing with swarms using modern network dynamics, and the goal is to leverage those very methods to reduce the burden on the user through an intuitive interface, allowing them to better focus the task of interest.
Potential Map Visualization and Integration
One approach to trajectory planning for robotics is use of a potential field to provide a cost associated with certain regions of the map. The goal of such algorithms is to choose the path that minimizes the cost represented by the height of the map. To make this process more intuitive for the researcher working with the quadrotors, a visual representation of the potential map within the Blender GUI is developed. The resolution of this map is 1.5 m x 1.5 m, with 10 mm x 10 mm squares. The target of this project is to devise, display, and execute a trajectory along the minimal cost path of the displayed map. Since Blender supports a python interface, the computations can be either done within the GUI, or in Matlab and passed through a temporary file.
Matlab Simulation Development
An integral part of testing and qualifying candidate algorithms for use on the RAINDrop platform, is the development of an accurate simulation that both emulates the on board discretized cascade control scheme, as well as accurately estimates the continuous dynamics of the quadrotor itself. One key component of the simulation is the partitioning of data that the quadrotor realistically has access to, and the simulation parameters necessary to produce a viable estimation of the dynamics. Additionally, as RAIN is a networks lab, most of the algorithms that will be tested on the RAINDrops will be centered around multi-agent interactions. As such, the simulation has been set up such that it simultaneously simulates a user-defined number of agents at each time-step. The eventual goal of this simulation is to have a well-documented, user-friendly simulation, that users can add and remove custom algorithms (estimation, trajectory generation, control, etc) with relative ease.
Flight Space Design
The previous robotics platforms developed in the RAIN lab were primarily restricted to ground operations, which affords both better platform stability and control when translating, while additionally allowing for longer communication delays on the GPS data uplink (Vicon system). One major complication that arises when extending platform operations into 3D is that of safety. Since the bulk stopping power of aerial platforms (like multi-rotors) leverages air manipulation (rotor redirection, air brakes, etc), which is an actively enforced reaction of the on-board controller. Since stopping actions require an active, stable flight controller, mandates passive safety measures to ensure the safety of the lab personnel and equipment.
To address the needs of functionality, ease of setup, and small storage profile, a hanging net was design that can be deployed using a ceiling-mounted curtain rail (shown below).
Rendered mock-up (left), final installed netting (center), stored final installed netting (right)