🚁 Omnicopter Control Research

Optimal Control · Robust Control · Fault Diagnosis · Fault-Tolerant Control
A hardware-based research project for fully-actuated 6-DoF aerial vehicles.

Start Here · What is an Omnicopter? · Motivation · Implementation · Research Focus · Media · References

🧭 Start Here

This repository documents our exploration of Omnicopter design, modeling, optimal control, robust control, and fault-tolerant control.

An Omnicopter is not just “a drone with more propellers”. It is a fully-actuated aerial vehicle that can command force and torque in all three spatial dimensions. In practice, this means it can:

• 🔼 move upward, downward, sideways, forward, and backward without needing to tilt first;
• 🔄 rotate around roll, pitch, and yaw while maintaining position;
• 🧲 hover at unusual or even inverted attitudes when actuator limits allow;
• 🛡️ use actuator redundancy for safer control allocation and fault recovery.

Project statement: build and test an Omnicopter hardware platform, then use it as a research testbed for optimal control, robust control, and fault diagnosis / fault-tolerant control.

✨ Project at a Glance

🎬 Media Gallery

PX4-based Omnicopter with dynamic control allocation Useful reference for PX4 control allocation and practical 6-DoF flight.	ArduCopter 6-DoF OmniCopter outside demo Useful reference for Lynchpin-style outdoor demonstrations.
ETH Zurich Omnicopter Original omni-directional six-degree-of-freedom flying machine.	Trajectory generation for fully-actuated multirotors Useful reference for trajectory-level optimal control ideas.

📸 Our hardware evidence slots

We have built such a system in last summer SEP, this project was awarded as FIRST price in 2025 UG student research showcase

Hardware prototype photo

Bench / tethered test video

🚁 What is an Omnicopter?

A conventional multirotor is usually under-actuated. It can generate thrust mainly along the body vertical axis, so horizontal motion requires the vehicle to tilt. This couples translation and rotation:

Want to move sideways?
    → tilt the drone
    → thrust vector gains horizontal component
    → attitude and position are coupled

An Omnicopter breaks this limitation by arranging rotor positions and thrust axes in 3D. The goal is to generate a full 6D wrench:

where:

• $\mathbf{F}$ is the 3D body force;
• $\boldsymbol{\tau}$ is the 3D body torque;
• $\mathbf{f}_{prop}$ is the vector of propeller thrusts;
• $M$ is the geometry-dependent allocation matrix.

For rotor $i$, a simplified force/torque contribution is:

where $\mathbf{p}_i$ is the rotor position relative to the center of mass and $\mathbf{x}_i$ is the rotor thrust-axis direction.

🧩 Conventional multirotor vs. Omnicopter

💡 Why Build One?

The design motivation is simple: many aerial robotics tasks require force control, not just position control.

Traditional multirotors are excellent for photography, mapping, inspection, and general flight. However, their under-actuation becomes a bottleneck when the vehicle needs to:

• 🧱 interact physically with walls, ceilings, tools, or objects;
• 🪛 apply force while maintaining a chosen attitude;
• 🧭 fly through constrained spaces without pointing the whole body in the direction of motion;
• 🧪 test advanced control allocation and fault-tolerant control algorithms;
• 🛟 survive partial actuator degradation by redistributing control effort.

For our project, the Omnicopter is valuable not because it is easy to fly, but because it is a rich control problem:

Geometry design
    ↓
6D force/torque map
    ↓
Optimal control allocation
    ↓
Robust tracking under uncertainty
    ↓
Fault diagnosis and recovery

🧱 Implementation Path

An Omnicopter can be implemented in several ways. Our project focuses on two useful reference families:

1. ETH-style cubic Omnicopter — an eight-rotor, fixed-pitch, reversible-propeller configuration.
2. Lynchpin-style tangential Omnicopter — a modular 6-DoF concept based on a geometric frame and tangential thrust logic.

🔷 ETH-style Cubic Configuration

The ETH-style Omnicopter is one of the most important reference designs for this project. It uses eight fixed-pitch rotors mounted around a symmetric cube-like frame. The rotors are not all pointing in the same direction. Instead, their thrust axes are arranged so that the combined actuator set can generate force and torque in all three dimensions.

🧠 ETH design logic

The ETH configuration follows several key ideas:

✅ Advantages

• Strong theoretical foundation for 6-DoF force/torque authority.
• Compatible with optimization-based allocation and null-space methods.
• Suitable for studying arbitrary-attitude hover and decoupled translation/rotation.
• Closely connected to PX4 Omnicopter documentation and open-source implementation references.

⚠️ Practical issues

• Bidirectional propellers and ESC 3D mode need careful setup.
• Motor reversal is slower than same-direction thrust changes.
• Aerodynamic interference between nearby rotors can produce model mismatch.
• A pseudo-inverse allocator can command infeasible thrusts unless constraints are handled.

📌 Why it is useful for us

The ETH configuration is a strong baseline for our research because it gives a clear mathematical structure:

Desired position + attitude
        ↓
Desired 3D force + 3D torque
        ↓
Allocation matrix M
        ↓
8 reversible rotor thrust commands

This is ideal for studying optimal allocation, actuator saturation, null-space optimization, and fault-tolerant reconfiguration.

🟣 Lynchpin-style Tangential Configuration

The Lynchpin-style configuration is another useful reference because it approaches 6-DoF flight from a different geometric intuition. Instead of emphasizing a cube-like 8-rotor layout, it uses a collapsed-dodecahedron-inspired modular frame and places motors/propellers around the frame in a way that supports tangential omnidirectional flight.

The Lynchpin contest requirement can be summarized as:

The drone should rotate into any orientation while maintaining position, and it should move in any direction regardless of its orientation.

🧠 Lynchpin design logic

✅ Advantages (compared to ETH-style)

• Attractive geometry for modular aerial robotics.
• Potentially fewer propulsion units than an 8-rotor cubic configuration.
• Good conceptual reference for arbitrary-attitude motion.
• Useful for comparing how geometry affects allocation conditioning and fault tolerance.

⚠️ Practical issues (compared to ETH-style)

• Less standardized than the ETH/PX4-style reference design.
• Geometry and actuator directions must be modelled very carefully.
• Fewer actuators may reduce redundancy for fault-tolerant allocation.
• The controller must still handle bidirectional thrust, actuator limits, and motor dynamics.

📌 Why the Lynchpin-style config is useful for us

The Lynchpin-style configuration is useful as a comparison case:

ETH-style:      symmetry + 8 rotors + allocation redundancy
Lynchpin-style: modular geometry + tangential logic + compact 6-DoF concept

By comparing both, we can ask research questions such as:

• Which geometry gives better force/torque isotropy?
• Which configuration gives a better-conditioned allocation matrix?
• How much actuator redundancy is needed for safe fault recovery?
• Which design is more efficient for arbitrary-attitude hovering?

🛠️ Our Hardware Progress

We have already constructed a complete Omnicopter hardware platform and performed initial tests. This platform is intended to serve as the physical testbed for the control research in this repository.

✅ Current progress

• Reviewed ETH Omnicopter and Lynchpin-style design references.
• Selected a feasible Omnicopter hardware configuration for research use.
• Built a complete Omnicopter hardware platform.
• Performed initial hardware-level tests.
• Prepared the platform for control-oriented experiments.
• Identify or refine the thrust/torque allocation matrix.
• Build a simulation model for controller validation.
• Implement constrained optimal allocation.
• Add robust tracking controller.
• Add fault diagnosis and fault-tolerant reallocation.
• Validate with repeatable flight experiments.

🧪 Hardware test evidence to add

🧮 Modeling Foundation

The Omnicopter can be modelled as a rigid body with six controllable degrees of freedom. The key object is the allocation matrix $M$:

where $\mathbf{u}$ represents individual actuator thrust commands.

🔍 What we need to identify

🧪 Suggested identification workflow

1. Measure geometry
   p_i, x_i, center of mass, frame axes

2. Static actuator calibration
   command -> thrust, command -> current, command -> RPM

3. Dynamic actuator calibration
   thrust step response, reversal delay, rate limit

4. Build initial allocation matrix
   y = M u

5. Validate against IMU / motion capture / log data
   predicted acceleration vs measured acceleration

6. Update model
   add bias, scaling, saturation, coupling, disturbance terms

🧠 Research Focus

This project lands on three major control directions:

1. Optimal Control — make the 6D motion and motor allocation efficient and constraint-aware.
2. Robust Control — maintain stable tracking under modeling errors, disturbances, and aerodynamic coupling.
3. Fault Diagnosis / Fault-Tolerant Control — detect degraded actuators or sensors and reconfigure the controller.

🎯 1. Optimal Control

Optimal control is used when we want the vehicle to satisfy motion goals while minimizing a cost and respecting constraints.

For an Omnicopter, the most immediate optimal-control problem is control allocation:

Given a desired 6D wrench, choose motor thrusts that generate it safely and efficiently.

🧩 Baseline allocation

A simple baseline is the pseudo-inverse allocator:

This is easy to implement, but it may fail when:

• one or more motors saturate;
• thrust commands require impossible reversal timing;
• the desired wrench is outside the attainable wrench set;
• a motor is degraded or failed;
• we want to minimize energy, noise, heat, or current.

⚖️ Better allocation: constrained QP

A more practical allocator can be written as a quadratic program:

where:

• $\|M\mathbf{u} - \mathbf{y}_{des}\|_Q^2$ tracks the desired wrench;
• $\|\mathbf{u} - \mathbf{u}_{prev}\|^2$ discourages aggressive thrust changes;
• $J_{rev}$ penalizes motor reversal;
• $J_{energy}$ penalizes current / power consumption;
• constraints enforce actuator limits.

🧭 Optimal-control research questions

• How can we allocate thrust while avoiding unnecessary motor reversal?
• Can we use the null space of $M$ to minimize energy without changing the produced wrench?
• How should force and torque tracking be weighted when full tracking is infeasible?
• Can MPC improve arbitrary-attitude trajectory tracking compared with cascaded PID control?
• How do ETH-style and Lynchpin-style geometries differ in attainable wrench space?

🧪 Planned experiments

🤖 2. Robust Control

Robust control addresses the gap between the clean mathematical model and the real flying machine.

In the real platform, we must expect:

• 🌬️ aerodynamic interference between rotors;
• 📦 payload and center-of-mass changes;
• 🧱 frame vibration and flexibility;
• 🔁 motor reversal delay;
• 📉 inaccurate thrust coefficients;
• 🧲 sensor noise, bias, and magnetic disturbance;
• 💨 external disturbances such as wind or contact forces.

🧠 Candidate robust-control structure

flowchart LR
    Ref[Reference trajectory] --> Nominal[Nominal 6-DoF controller]
    Nominal --> Alloc[Constrained allocator]
    Alloc --> Vehicle[Omnicopter hardware]
    Vehicle --> Est[State estimator]
    Est --> DOB[Disturbance observer]
    DOB --> Nominal
    Est --> Nominal

🔧 Methods we can investigate

🧪 Robust-control experiments

📈 3. Fault Diagnosis and Fault-Tolerant Control

Fault control is the final landing point of this project. Because an Omnicopter is over-actuated or geometrically redundant, it provides an excellent platform for studying fault diagnosis and fault-tolerant control allocation.

⚠️ Faults we care about

🔍 Fault diagnosis idea

Use the model to predict what should happen, then compare it with what actually happens:

motor commands
    ↓
predicted force / torque
    ↓
predicted acceleration / angular acceleration
    ↓
compare with IMU + estimator
    ↓
residual
    ↓
fault detection + isolation

A simple residual can be defined as:

or at the wrench level:

The goal is not only to detect that something is wrong, but also to identify which actuator or sensor is responsible.

🧩 Fault-tolerant reallocation

Once a fault is identified, the allocator can be reconfigured:

normal allocation matrix M
        ↓ fault detected
modified allocation matrix M_fault
        ↓
new actuator constraints
        ↓
redistributed motor commands
        ↓
degraded but stable flight

For example, if motor 3 loses effectiveness, we can model it as:

Then the allocator should avoid relying too much on motor 3 and redistribute the remaining wrench among healthy motors.

🧪 Fault-control experiments

🧪 Experiment Plan

Phase 1 — Safe hardware validation

• Verify motor order and thrust directions.
• Confirm ESC 3D / bidirectional mode behavior.
• Check vibration, current draw, and thermal behavior.
• Record motor command, RPM/current if available, IMU data, and battery voltage.

Phase 2 — Model identification

• Measure geometry and build $M$.
• Estimate thrust coefficients.
• Identify actuator delay and reversal timing.
• Validate predicted acceleration against logs.

Phase 3 — Control allocation

• Implement pseudo-inverse allocation as baseline.
• Implement constrained QP allocation.
• Add saturation and rate-limit handling.
• Add reversal penalty and energy penalty.

Phase 4 — Robust control

• Add disturbance observer or robust feedback layer.
• Test against payload shift and external disturbance.
• Compare nominal controller vs. robust controller.

Phase 5 — Fault diagnosis and recovery

• Design residual generator.
• Inject software faults in simulation.
• Validate detection thresholds.
• Reconfigure allocation after detected faults.

🧰 Suggested Repository Structure

Inspired by robotics course/project repositories, this repository should separate documentation, hardware, control code, simulation, experiments, and references.

omnicopter-control-research/
├── README.md
├── assets/
│   ├── omnicopter_banner.svg
│   ├── eth_cube_geometry.svg
│   ├── lynchpin_geometry.svg
│   ├── control_stack.svg
│   ├── fault_control.svg
│   ├── research_roadmap.svg
│   ├── hardware_prototype.jpg
│   └── bench_test_thumbnail.jpg
├── docs/
│   ├── eth_configuration.md
│   ├── lynchpin_configuration.md
│   ├── modeling_notes.md
│   ├── control_allocation.md
│   ├── robust_control.md
│   ├── fault_diagnosis.md
│   ├── experiment_logbook.md
│   └── image_generation_prompts.md
├── hardware/
│   ├── bom.md
│   ├── wiring.md
│   ├── esc_configuration.md
│   ├── safety_checklist.md
│   └── cad/
├── firmware/
│   ├── px4_notes.md
│   ├── ardupilot_notes.md
│   └── parameters/
├── simulation/
│   ├── gazebo/
│   ├── matlab/
│   └── python/
├── control/
│   ├── allocation/
│   ├── mpc/
│   ├── robust_control/
│   └── fault_tolerant_control/
├── experiments/
│   ├── bench_tests/
│   ├── tethered_tests/
│   ├── flight_tests/
│   └── fault_injection/
└── references/
    ├── papers.md
    └── links.md

✅ Safety Rules

Omnicopters are experimental aerial vehicles with bidirectional thrust. Treat every test as high-risk.

• 🧤 Remove propellers during firmware, ESC, and motor-order tests.
• 🧯 Keep a fire-safe LiPo charging and storage setup.
• 🛑 Use a physical kill switch and a clear emergency stop procedure.
• 🧍 Keep all people outside the propeller disk danger zone.
• 🪢 Use tethered tests before free flight.
• 🔋 Monitor battery voltage, current, and motor temperature.
• 🧪 Test one change at a time and log everything.
• 📝 Write down the exact firmware version, parameter file, and hardware configuration for each test.

📊 Evaluation Metrics

🧾 Key Takeaways

• 🚁 An Omnicopter is a 6-DoF multirotor capable of generating force and torque in 3D.
• 🧊 The ETH-style cubic design is a strong baseline because it is symmetric, over-actuated, and well connected to PX4 references.
• 🟣 The Lynchpin-style design is a useful comparison because it emphasizes modular tangential geometry and independent position/orientation control.
• 🛠️ Our hardware platform has already been built and tested, making this project suitable for real control experiments.
• 🎯 The main research value is not only flying the vehicle, but building a pipeline for optimal, robust, and fault-aware control.

🔗 References

Papers and technical sources

1. D. Brescianini and R. D'Andrea, “Design, Modeling and Control of an Omni-Directional Aerial Vehicle,” IEEE International Conference on Robotics and Automation (ICRA), 2016.
2. PX4 Documentation — Omnicopter Build Guide https://docs.px4.io/main/en/frames_multicopter/omnicopter
3. PX4 Documentation — Control Allocation https://docs.px4.io/main/en/concept/control_allocation
4. Terry's Lynchpins — Lynchpin Drone Contest https://www.terryslynchpins.com/contest
5. Awesome Tech Designs — Omnicopter taxonomy and examples https://github.com/bpodchezertsev/awesome-tech-designs/blob/main/Omnicopter.md

Videos

1. PX4 Based Omnicopter Using the New Dynamic Control Allocation https://www.youtube.com/watch?v=nsPkQYugfzs
2. ArduCopter 6DoF — OmniCopter — outside (Lynchpin) https://www.youtube.com/watch?v=0p9jmrf1eFM
3. The Omnicopter — ETH Zurich https://www.youtube.com/watch?v=sIi80LMLJSY
4. Fetching Omnicopter https://www.youtube.com/watch?v=0gR1ekapOAE

Built with carbon rods, reversible thrust, logs, unstable prototypes, and too much control theory.
🚁🧠🛠️📈