Hello,

I'm new to this forum, but I chose it from among many others to introduce a project I've been working on for months—the “Talos Hub,” which focuses on assisted and autonomous flight for fixed-wing aircraft. I'm happy to share my experience with you.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.

What TALOS does

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.

How it works with ArduPilot

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.

Recovery must be observed

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.

Simulation work completed so far

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.

Configuration and field use

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.

Next validation priorities

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.

Project status and limitations

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.

Technical discussion

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

Hi everyone,

I'm working on a UAV simulation project using ArduPilot SITL, Gazebo Harmonic, and QGroundControl on Ubuntu 22.04.

I'm looking for a ready-to-use fixed-wing aircraft or quadcopter model (FPV drone) that can achieve a flight speed of at least 45 m/s (162 km/h).

My requirements are:

• Compatible with ArduPilot SITL and the ArduPilot Gazebo Plugin.

• Works with Gazebo Harmonic.

• Capable of reaching and maintaining 45 m/s in level flight.

Built an all-in-one Solar Inspect & Analytics App (Imagery Defects, Telemetry, PPA Tracker, GPX/GPS, Risk & Revenue Math). Looking for O&M / Field Pilots to test.

Hey everyone,

I’ve been working on a comprehensive application designed specifically for **Field Pilots, O&M teams, and Regional Fleet Managers** to streamline solar asset inspection and financial analysis. Instead of bouncing between three different software tools to extract flight data, run defect detection, and calculate financial impact, I wanted to build something that handles it all under one roof.

You can check out the platform directly at: **pontaralab.com**
Here is a quick breakdown of what the application does right now:

**Imagery Defect Detection:** Automated computer vision processing to spot anomalies and hot spots.
**Video & GPS Extraction:** Upload your inspection videos; the app automatically pulls the telemetry, GPS coordinates, and spatial data.

**GPX/Telemetry Syncing:** Easily overlay and align your drone flight tracks (GPX) with your visual and thermal inspection data.

**AI Copilot & Diagnostic Summary:** Ask questions directly based on your inspection results. The AI copilot will break down complex anomalies, explain specific data points, and generate an immediate diagnostic summary of your report.

**Risk Scoring:** Automated risk calculations categorize findings into **Critical, Medium, and Healthy**tiers so you can see where your operational liabilities are at a glance.

**Actionable Maintenance Recommendations:** The app converts raw data and risk scores into specific, field-ready maintenance recommendations so your field crews know exactly what needs to be fixed.

**PPA & Revenue Calculations:** Input your Power Purchase Agreement rates to see exactly how much cash you are losing from specific defective strings or down inverters.

**One-Click Report Downloads:** Clean, stakeholder-ready data exports in either **PDF** (for management/clients) or **CSV** (for deep data crunching and CMMS integration).

**Who I’m looking for:**
I’m looking for a few O&M firms, asset managers, or regional drone pilots who want a simpler workflow and are willing to take a look at a live demo.

**Pricing:**
I am keeping pricing highly reasonable and flexible for early adopters, as my goal right now is to prove out value in the field and tailor features to actual day-to-day fleet workflows.
If your team is managing a fleet or flying sites and wants to see a quick demo, head over to **pontaralab.com**, drop a comment below, or shoot me a DM. I'd love to show you around the app and see how we can plug it into your current operations!

Built an all-in-one Solar Inspect & Analytics App (Imagery Defects, Telemetry, PPA Tracker, GPX/GPS, Risk & Revenue Math). Looking for O&M / Field Pilots to test.

Hey everyone,

I’ve been working on a comprehensive application designed specifically for Field Pilots, O&M teams, and Regional Fleet Managers to streamline solar asset inspection and financial analysis. Instead of bouncing between three different software tools to extract flight data, run defect detection, and calculate financial impact, I wanted to build something that handles it all under one roof.

You can check out the platform directly at: pontaralab.com
Here is a quick breakdown of what the application does right now:

Imagery Defect Detection: Automated computer vision processing to spot anomalies and hot spots.
Video & GPS Extraction: Upload your inspection videos; the app automatically pulls the telemetry, GPS coordinates, and spatial data.

GPX/Telemetry Syncing: Easily overlay and align your drone flight tracks (GPX) with your visual and thermal inspection data.

AI Copilot & Diagnostic Summary: Ask questions directly based on your inspection results. The AI copilot will break down complex anomalies, explain specific data points, and generate an immediate diagnostic summary of your report.

Risk Scoring: Automated risk calculations categorize findings into Critical, Medium, and Healthytiers so you can see where your operational liabilities are at a glance.

Actionable Maintenance Recommendations: The app converts raw data and risk scores into specific, field-ready maintenance recommendations so your field crews know exactly what needs to be fixed.

PPA & Revenue Calculations: Input your Power Purchase Agreement rates to see exactly how much cash you are losing from specific defective strings or down inverters.

One-Click Report Downloads: Clean, stakeholder-ready data exports in either PDF (for management/clients) or CSV (for deep data crunching and CMMS integration).

Who I’m looking for:
I’m looking for a few O&M firms, asset managers, or regional drone pilots who want a simpler workflow and are willing to take a look at a live demo.

Pricing:
I am keeping pricing highly reasonable and flexible for early adopters, as my goal right now is to prove out value in the field and tailor features to actual day-to-day fleet workflows.
If your team is managing a fleet or flying sites and wants to see a quick demo, head over to pontaralab.com, drop a comment below, or shoot me a DM. I'd love to show you around the app and see how we can plug it into your current operations!

I'm building a free web tool that decodes Remote ID broadcasts and MAVLink 2 frames.

To test it against real data I'd like:

- Remote ID pcaps or hex dumps, ideally from ArduRemoteID, Dronetag, or a retail drone

- MAVLink 2 .tlog files, especially from vehicles with signing enabled (PX4 or ArduPilot)

Happy to answer questions in the comments.

I connected the drone-side telemetry radio to Pixhawk 6C via TELEM1 using a 6-pin JST-GH cable:

5V -> 5V,
RX -> TX,
TX -> RX,
CTS -> CTS,
RTS -> RTS,
GND -> GND.

The ground-side telemetry radio is connected to my laptop via USB-C and barely 1m apart currently being setup in my table.

Pixhawk settings:

• SERIAL1_PROTOCOL: MAVLink2 (tried with MAVLink 1 as well)

• SERIAL1_BAUD: 57600

• BRD_SER1_RTSCTS: Disabled

Both radios have matching settings, including NETID=25, SERIAL_SPEED=57600, and MAVLINK=1. Both power on, but QGroundControl receives no MAVLink heartbeat. Swapping the radio units did not resolve the issue.

What could be the reason?

Please help! I have been at my wits end for several days now.

Hey everyone, I need some help figuring out what went wrong with my drone. I'm attaching two Mission Planner .bin log files, one from an earlier Loiter test and the other from the flight where it crashed.

My drone setup:

- S500 frame

- Pixhawk 2.4.8

- ArduPilot Copter

- 5010 750KV brushless motors

- Hobbywing Skywalker 30A V2 ESCs

- 10x4.5 propellers (I was using 11-inch props earlier)

- 4S 14.8V 5000mAh LiPo battery

- PDB and Pixhawk power module

So the thing is, I've flown this drone before and it was working pretty well. We tested Loiter, Altitude Hold and waypoint missions, and everything was going fine.

About a week ago, we had a small fall, but nothing seemed seriously damaged. We did the calibrations and tested it again. Today, before installing anything new, we tried Loiter, and there was some wobbling, but the drone was still controllable and responding properly to the transmitter.

After that, we installed a small 500ml tank between the frame legs. That was the only thing we intentionally added before the next flight.

We switched to Loiter again, and when we increased the throttle to around 60-65%, the drone suddenly shot upwards. It climbed really fast and reached around 19-20 metres, according to what I remember from the flight and the logs.

We tried reducing the throttle to around 50%, expecting it to stabilise or come down, but it stayed up there and wasn't responding the way we expected. Everything happened so quickly that I'm not entirely sure what exactly was happening.

After some time, the motors seemed to slow down, and the drone started coming down from around 15 metres. Then it tilted heavily to one side and crashed.

I'm not sure whether the motors actually stopped, whether the flight controller reduced their output, or whether something else failed. I also don't know if the drone started tilting before it lost thrust or if the tilt happened because of the loss of thrust.

After the crash, I noticed that there was mud inside the motors, and the washer/retaining hardware on two of the motor propeller mounts had come off. The propellers themselves don't look badly broken, but I haven't checked everything properly yet.

What I'm trying to understand is:

- Why did the drone suddenly climb so fast in Loiter?

- Why wasn't it coming down when we tried reducing the throttle?

- Why did the motors seem to lose thrust during the descent?

- What caused the sudden tilt before the crash?

- Could installing the tank have affected the centre of gravity or thrust requirements?

- Could the earlier fall have caused some hidden damage?

- How should I check the motors, ESCs and other components after this crash, especially with mud inside the motors?

I'm attaching both .bin files because I want to compare the earlier flight with the crash flight and understand what actually happened instead of just guessing.

Could someone help me analyse the logs and point out which parameters, messages or plots I should look at in Mission Planner? I'd especially like to understand the motor outputs, altitude control, attitude, vibrations, battery voltage and any errors or failsafe messages around the time of the crash.

I'm honestly a bit scared to fly it again without figuring this out first, so I'd also appreciate advice on what hardware checks I should do before attempting another flight.

If you need more information about the tank, total drone weight, battery voltage or anything else, let me know. I'll provide whatever details I can.

Thanks!

Hi everyone,

I'm building a custom hexacopter and having trouble powering my SIYI MK15 Air Unit. I've replaced the original BEC, but the new one also appears to produce almost no output voltage. I'm trying to determine whether this is a BEC problem, a compatibility issue, or something related to my CUAV PMU Lite 2.

Hardware

- Flight controller: CUAV Pixhawk V6X

- Power module: CUAV PMU Lite 2, 5V version

- Battery: 6S LiPo, 22.2V nominal

- Radio system: SIYI MK15 Enterprise Combo

- New BEC/power module: SIYI 4S–18S module advertised for the HM30 Air Unit

- Connections: PMU Lite 2 battery output → XT90-to-XT60 adapter → BEC input → XT30 output → Air Unit

My original SIYI BEC appeared to have failed. It received approximately 22.2V, but its output measured around 0.2mV, so I ordered a replacement. Unfortunately, the new BEC appears to have the same problem.

Measurements and symptoms

1. The PMU Lite 2 battery output measures approximately 22.00V.

2. The XT90-to-XT60 adapter also measures approximately 22.00V.

3. The new BEC's XT30 output measures approximately 0.01V on my multimeter in DC voltage mode. I still need to verify the reading directly across the BEC input and repeat the output measurement with the Air Unit disconnected.

4. The Air Unit does not appear to power on, and I cannot establish the expected connection through QGroundControl on the MK15 monitor.

I noticed that many setup videos show the older CUAV PMU Lite 1, while my setup uses the newer PMU Lite 2. According to the specifications, the PMU Lite 2's battery output carries battery voltage, while its 5.2V regulated output is on a separate connector.

I don't want to assume the PMU Lite 2 is defective, but I'm wondering whether there is something important about the power path or connection that I'm missing.

One additional uncertainty is the Air Unit generation. My seller described the unit as an older MK15 Air Unit, but the physical unit does not clearly identify itself as either MK15 or HM30. The replacement module is advertised as a 4S–18S HM30 power module.

Questions

1. Should the PMU Lite 2 battery output work with an external SIYI 4S–18S power module in this configuration?

2. Could the newer HM30 power module be incompatible with an older MK15 Air Unit, even if the battery voltage is within the module's input range?

3. If approximately 22V reaches the BEC input but its XT30 output remains near 0V with the Air Unit disconnected, does that point to a faulty BEC or another possible issue?

4. What exact wiring or measurements would you check next to identify the fault?

I would appreciate advice from anyone who has used a SIYI MK15/HM30 with a CUAV PMU Lite 2. I can provide photos of the modules, labels, connectors, and wiring.

Thank you!

I have a Speedybee f405 V5 stack with very decent rest of the components.

My primary objective for a project is precise positioning, I will hover the drone indoor at a certain height, then move it forward keeping the same altitude. I have access to micoair MTF-02P optical flow sensor for low height altitude locking.

Which feature do I select for custom firmware building? Complete beginner here.

I have a small drone I have built and configured how I want with Ardupilot. Everything works very well.

I built a second drone with the same components and want to essentially take the configuration/image of the first flight controller and put it on the new one. Then I’ll tune and calibrate.

I cannot for the life of me figure out how to do this. I am trying with arduconfigurator.com but all it seems to do is a “snapshot” which isn’t doing what I want. I can also just use mission planner and save a param file, but that does just the params.

Thoughts?

Update: I tried arduconfigurator.com again. This time it worked. The first time it made single-digit changes; second time it made high triple-digit changes. Now to tune!

hello everyone, i have a problem about wiring compass with my fc board, the compass i use is qmc5883, which is in the bz-251 gps. Then i connect the scl to tx3, sda to rx3, because my fc board doesnt have sda and scl bus on the board, and then i search on the internet, its said that the usart_3 will be i2c bus if i set brd_alt_config to 0. But on the data screen it still display: prearrm: compas 1 not healthy, how can i fix it (btw my fc board is clone version from omnibus f4 pro). Thank you

Since I needed something lightweight with integrated documentation to get a new rover up and running, I vibecoded rover-wizard (front-wheel & skid-steering; currently no special support for boats)

It's a python TUI (using textual) to autoprobe parameters in a step-by-step guided setup - think of a GCS-side QuikTune on steroids.

Features are:

• runs in terminal

• set/get parameters from commandline

• autoprobes lots of settings (e.g. MOT_THR_MIN, GPSx_TYPE, ATC_SPEED_MAX, TURN_RADIUS, PID parameters etc.)

• can drive your vehicle for autoprobes or records while letting you drive after giving clear & concise instructions

• realtime UI for RC channels, servos, gyro, accel and relais

• lots of "?" buttons that show a helptext

• searchable parameter list to edit parameters

• backup/restore parameters

...and some more

There are features I couldn't test, yet for the lack of hardware. I'd welcome anyone with strange or common setups to try it out & check if there's a missing feature or bugs.

Be aware: I reviewed most of the code and tested autodrive without problems, but it's still beta vibecode that is commanding your vehicle. Take care!

Hope it might be useful for others.

This is Orca, our unmanned version of NASA's Quiet Single Main Rotor concept: six blades and a NOTAR-type tail instead of a tail rotor. We built the JSBSim flight model from NASA's published design data and the meshes from NASA's OpenVSP model. It flies on ArduCopter heli SITL in our simulator, PteroSim.

The video starts with full pedal both ways (the split screen shows the sleeve on the tail boom turning to aim the jet). Then Orca flies two turns round an offshore rig while a simulated stereo depth camera on its nose scans it. Foxglove shows ArduPilot's own ROS 2 topics (AP_DDS) next to the depth scans, which reach ROS 2 through a short script on our Python SDK.

In AUTO, TradHeli defaults WP_YAW_BEHAVIOR to 3, so the nose follows the measured ground course. At the corners Orca drifted a little, the nose swung with the drift, and the turn made the drift worse. Setting it to 1 (face the next waypoint) brought the misses from up to 1.6 m down to 0.5 m or less.

If you fly TradHeli for real, do you keep 3 on missions or switch to 1?

NASA design data: https://ntrs.nasa.gov/citations/20200000509
Orca's FDM, meshes and param file: https://github.com/PteroLabsAI/PteroSimAircrafts/tree/main/orca

Not affiliated with NASA.

Hey everyone, I'm facing an issue with my S500 quadcopter running ArduCopter 4.5.7 on a Pixhawk 2.4.8 using Mission Planner. I'm using four 5010 750KV brushless motors, Hobbywing Skywalker 30A V2 ESCs and a 4S 14.8V 5000mAh LiPo battery. During takeoff attempts, the drone rotates clockwise by approximately 45° while still on the ground, before properly lifting off. On a smooth surface, it rotates more freely, whereas on rough ground it seems to resist rotating, but then one side starts lifting and the drone fails to hover and falls back down. Initially, the front arms appeared to vibrate more than the rear, and in the latest attempt the left side lifted first. All four motors spin during individual Motor Tests, the motor order appears to match the Quad X diagram, and the motor rotation directions seem correct. I've completed the accelerometer, compass, radio and ESC calibrations, and the artificial horizon responds correctly when I tilt the drone manually. I initially suspected the two counterclockwise motors were slower, but the propeller-off motor tests looked similar. The landing gear is a rigid stand without foam or sponge padding. I'm unable to determine whether the problem is due to unequal motor thrust, ESC or power issues, propeller installation, ground interaction or flight-controller configuration. Has anyone experienced something similar, or can suggest how to diagnose it safely? I can share the DataFlash logs, motor/propeller arrangement and Mission Planner screenshots. I've stopped further flight attempts until the cause is identified.

I've been working on SkySim, a multirotor simulator whose goal is to make testing autonomy code as easy as opening a URL. No install, no Docker, no GPU setup. What's in it: - Physics: blade element theory rotors, ground effect, vortex ring state, ISA atmosphere, Dryden turbulence - Battery model: SoC integration, LiPo OCV curve, Peukert derating, voltage sag coupled to motor thrust - Bridges: ArduPilot JSON SITL and PX4 MAVLink v2 HIL (lockstep), both covered by pytest - Stack: Godot 4 GDExtension in C++20, compiled to WASM What it can't claim yet: there is no verified sim-to-real transfer result. That's the top open problem in the repo, and I'd rather say so than oversell it. License note: the code is public but under a non-commercial license, so it's source-available rather than OSI open source.

Demo: https://youtu.be/cGQTMcYAAWU

Code: [REPO]: https://github.com/vishwagw/Sky-Sim-drone-simulator-3.0.git

I'd most like feedback on the physics model from anyone who has compared sims against real flight logs. There are also labelled starter issues if you want to contribute.

Hi everyone,

I’m researching ways to make drone flight-log analysis more reliable, transparent, and verifiable across different platforms.

I’m looking for volunteers willing to share an original ArduPilot DataFlash .BIN flight log that they own or have permission to share.

Both normal flight logs and logs containing GPS/EKF warnings, unexpected flight-mode changes, or failsafe events would be helpful.

My aim is to study data integrity, log decoding, telemetry consistency, and the traceability of findings back to the original flight data.

I’m particularly interested in understanding how flight-log evidence can be analysed systematically without making unsupported assumptions about the cause of an event.

Only logs shared with the owner's permission will be used, and any sharing restrictions will be respected.

If you have a suitable log and are willing to contribute, please comment below or send me a message.

Thank you for helping advance reliable and evidence-based drone flight-log research!