Discussions

Hi, friends,
I joined this forum to share a project I’ve been working on for a few months now—a system for in-flight assistance and autonomous flight for fixed-wing aircraft that I’ve named “Talos,” after the giant bronze automaton in mythology that defended the city of Crete.TALOS Hub is an experimental software project that brings mission coordination, pilot assistance and autonomous-flight supervision into a single system. The project grew out of more than thirty years of interest in RC aircraft and flying. Its name comes from Talos, the bronze automaton of Greek mythology that guarded Crete. Development currently focuses on fixed-wing aircraft. Future work is intended to extend the supervisory logic to multirotors, adapting it to the operating characteristics of each platform.

Autonomous flight involves more than following a route. Commands can conflict, telemetry can become stale, an approach can become unstable, and an acknowledged recovery command may not produce a successful recovery.

TALOS is being developed to coordinate these situations through explicit mission states, authorisations and checks on observed aircraft behaviour.

Its main areas of work include:

• Managing mission phases and start authorisations.
• Coordinating pilot requests with autonomous operation.
• Monitoring telemetry availability and freshness.
• Identifying approach conditions that require a go-around.
• Checking recovery before permitting another landing attempt.
• Recording decisions, commands and observed responses for later analysis.

The project also addresses RC model aviation, with functions intended to support manual piloting, assistance and autonomous operation within the same system. Compatibility and transitions between these operating states remain subjects of testing.

The current simulation setup uses ArduPilot/ArduPlane SITL and Gazebo, with TALOS communicating through MAVLink.

Responsibilities are divided between two layers:

• TALOS: supervisory decisions, mission authorisations, monitoring and recovery coordination.
• ArduPlane: aircraft stabilisation, navigation and low-level flight control, including the native energy controller.

This separation is central to the project. Test evidence must distinguish a TALOS decision from the action performed by ArduPlane and from the resulting physical response in Gazebo.

Some experiments use isolated simulation-specific changes to the firmware and companion software. Their results apply to those configurations and should not be interpreted as capabilities available in an unchanged ArduPilot installation.

A successful command acknowledgement establishes that a command was accepted. It does not establish that the aircraft has recovered.

In the tested configuration, recovery confirmation checks observed conditions such as:

• Altitude gain from the recovery baseline.
• Positive climb rate.
• Minimum airspeed.
• Persistence of the required conditions for a confirmation period.
• Freshness of the telemetry needed to evaluate those conditions.

Missing or stale required telemetry prevents recovery confirmation.

One simulation exposed a recovery deadline that was too short: the aircraft was recovering, but reached the required conditions after the deadline. The timeout was adjusted in an isolated simulation profile and the scenario was repeated successfully.

That result remains specific to the tested aircraft model and configuration. It also illustrates the purpose of the tests: exposing assumptions in the supervisory logic and checking them against recorded aircraft behaviour.

The current test programme uses a fixed-wing Gazebo model and progressively more demanding scenarios.

Completed scenarios include:

• Mission start through the TALOS authorisation path.
• Rejection of a repeated start request during an active mission.
• Rejection of selected commands from unauthorised sources.
• Rejection of malformed supervisory requests.
• Go-arounds following physically induced low airspeed or attitude instability.
• Recovery confirmation followed by a second approach.
• Physical runway contact and a verified stop.
• A pilot mission-abort request during a go-around, followed by cancellation before confirmation, continued recovery and landing.

The pilot-request test verified the implemented request-and-cancellation sequence. It did not verify immediate manual takeover or the complete sequence following a confirmed mission abort.

A separate experimental landing configuration also demonstrated variable motor output through the flare until physical runway contact, followed by reduced motor output and a verified stop. TALOS supervised the authority sequence, while the native ArduPlane energy controller calculated the changing motor demand.

The project includes a dedicated application for system configuration, monitoring and updates over Wi-Fi.

The aim is to make these operations accessible at the flying field through a common interface. Application compatibility and operating workflows continue to be checked during development.

Further simulation work is needed on:

• Legitimate pilot interventions that conflict with an autonomous recovery decision.
• Delayed or contradictory telemetry during approach.
• Recovery attempts that fail to meet the required conditions.
• Communication loss between TALOS and the flight controller during critical phases.
• Repeated failed approaches and the conditions under which another attempt is permitted.

For each scenario, useful evidence includes the initial conditions, triggering event, authority state, decision latency, commanded action, observed aircraft response and measurable recovery criteria.

TALOS is currently an experimental project undergoing simulator testing.

Results are specific to the tested software, aircraft model and simulation configuration. They do not establish readiness for operation on a real aircraft, and they do not automatically transfer to a different aircraft or to multirotors.

Simulation logs and test scripts have been recorded. Source code, logs and reproducible test packages are not included in this repository at this stage. Sharing a reproducible scenario will require documentation of its dependencies, configuration and limitations.

Feedback from developers, researchers, pilots and aerial robotics enthusiasts is welcome.

Particularly useful questions include:

• What evidence should be required before declaring a recovery complete?
• How should missing or uncertain telemetry affect the next permitted action?
• Which pilot-authority conflicts deserve explicit tests?
• What should happen after several unsuccessful landing attempts?
• Which logs and measurements would make independent review most useful?

TALOS Hub Team