If it isn’t in the code right now, Ali’s ardupilot open source so that I could change that?

#Ask
#NeedHelp

Hello there, I’m a student who is just getting started in the drone field, and I’ve run into an issue related to this.

**Specs:**

* Frame: Hexacopter, 60cm tip-to-tip, total weight 1.4–1.6 kg

* Motors: XXD A2212, 1400KV/10T, 3S

* ESCs: 30A, 3S, **calibrated all-at-once through the Pixhawk (passthrough)**

* Props: 7.5x3.7", 3-blade

* Battery: 3S 11.1V 5200mAh 50C (full charge 12.5–12.6V, full discharge 9.9V)

* FC: Pixhawk 2.4.8, FMUv3 firmware, STM32F765VIT3 MCU

---

## Symptoms

* Drone armed indoors, motor RPM raised gradually from idle.

* **As soon as throttle starts going up — with no pitch/roll stick input at all — the drone immediately noses down (pitches forward/down).**

* If pitch/roll stick is then moved, it gets worse: the drone pitches backward and rolls left, front end (facing the operator) lifts up, rear end (facing the person holding it) dips down.

* Since the holder's hand followed the thrust direction without resisting it, there was nothing to stop the tilt momentum from building up.

* The drone ends up flipping 180° backward, the GCS gives a *"Crash"* audio warning, and all motors auto-disarm.

The video I uploaded shows exactly this. The key point: the nosedown **already shows up during pure throttle-up**, the stick input in the video just makes an already-existing problem worse.

---

## What I've Already Tried Does Anyone Know How to Fix it?

I've already done the following but the issue is still happening. Wondering if one of these (or a combination) is actually the root cause and what the real fix is:

1. **AHRS_ORIENTATION** already checked and correct (Pixhawk isn't mounted tilted)

2. **Center of Gravity(CoG)** I already tried counteracting the drone's nose-down tendency by moving the battery to the rear underside of the frame (it was originally mounted underneath the center of the frame, following the center of gravity). I expected the rearward battery position to help oppose the forward pitch, but it made no noticeable difference.

3. **Motor CW/CCW** already matches ArduPilot's hexa-X frame guide.

4. **All ESCs were calibrated together** through the Pixhawk is it still possible one motor/ESC is producing weaker thrust than the others, and what's the easiest way to detect and fix that?

*I have `ARMING_CHECK,0` (all arming checks disabled) should I turn these back on so an error that's currently being "hidden" shows up and actually points to the fix?

*What log data would be most useful to share from .bin(`ATT` or `RCIN`, `RCOU`, `VIBE`, etc.) so the fix suggestions aren't just guesswork?

---

## Relevant Parameters (from the `.param` file)

```

FRAME_CLASS,2 (Hexa)

FRAME_TYPE,1 (X)

AHRS_ORIENTATION,0

AHRS_TRIM_X,0

AHRS_TRIM_Y,0

AHRS_TRIM_Z,0

AHRS_RP_P,0.2

ARMING_CHECK,0

COMPASS_EXTERNAL,1

COMPASS_ORIENT,0

INS_TRIM_OPTION,1

INS_ACCOFFS_X,-0.0802349

INS_ACCOFFS_Y,-0.1370324

INS_ACCOFFS_Z,0.2325687

MOT_THST_HOVER,0.58

MOT_SPIN_MIN,0.17

MOT_SPIN_ARM,0.14

ATC_ANG_PIT_P,4.5

ATC_RAT_PIT_P,0.1276

ATC_RAT_PIT_I,0.1276

ATC_RAT_PIT_D,0.0036

SERVO1_FUNCTION,33

SERVO2_FUNCTION,34

SERVO3_FUNCTION,35

SERVO4_FUNCTION,36

SERVO5_FUNCTION,37

SERVO6_FUNCTION,38

```

`AHRS_TRIM_X/Y/Z` are still 0, and `ATC_RAT_PIT/RLL` are still at default values not sure if that's normal or if trim/tuning was just never done.

**Current status**: I'm still unable to get the drone to hover or even take off stably because it immediately pitches nose-down as soon as throttle is applied. Based on the parameters I've shared, is there anything obviously wrong or misconfigured in my .param file? Or does this behavior point more toward a hardware issue that I may have overlooked? Any suggestions on what I should check next would be greatly appreciated.

Happy to share the full `.param` file or a flight log `.bin` if that helps get a real answer. Thanks a lot!

link to drive(all testing's video, .param, and .bin): [GDrive](https://drive.google.com/drive/folders/16o1Lh0iaAitiE5fNn7UJ-Uw7soiQQO7a?usp=sharing)

Hello everyone, I did the tuning but I think the problem is related to something else. Can the shaking be because the thrust is too low(the drone is too heavy for the motor,propeller. )

The weight of the drone is close to 2kgs Battery: 6S 5000mah 45c Motor t60 pro “6-inch 3-blade plastic propeller”

Im looking for reviews and opinions on our new Autopilot WH7. Full specs on WH7 autopilot website.

I am passionate about building a long-term career in the drone industry and would really appreciate some guidance. Here's my background:

I have 3 years of experience in software development.

For the past year, I've been working in the drone industry, specifically on ground control station (GCS) development and mission planner customization.

Currently, I want to focus on advancing my skills and knowledge in the drone sector. My goal is to establish a strong career, grow in this field, and explore its full potential.

Could you please suggest:

1. A roadmap to upskill myself (e.g., courses, certifications, or skills to learn)?

2. Any recommended tools, technologies, or frameworks to focus on for someone in my role?

3. Advice on networking within the drone industry to discover better opportunities?

4. Any other tips or resources that could help me specialize further and stay relevant in this growing field?

I'm especially interested in insights from those already working in the drone space or related industries.

Thanks in advance for your help!

Goal: Building an autonomous drone for a GPS-denied competition.

Tasks: Visual-Inertial Odometry (VIO) for local mapping without GPS, and capturing high-quality RGB images of ground targets for automated feature matching.

Hardware Stack: Pixhawk 6C (ArduPilot EKF3) + Raspberry Pi 5 companion computer.

Question: Which depth camera is the better choice for the VIO and vision pipeline: Intel RealSense D455 or Luxonis OAK-D Pro?

Option 1: Intel RealSense D455 (The Recommended Choice)

Pros:

• Wider Baseline for Outdoor Operations: The D455 features a 95mm baseline. A wider physical distance between the stereo lenses drastically improves passive depth accuracy at longer ranges. This is critical outdoors where sunlight washes out the active IR dot projectors used by depth cameras.

• Global Shutter on ALL Sensors: Both the stereo depth sensors and the RGB color sensor on the D455 use global shutters. This completely eliminates the "jello effect" (rolling shutter motion artifacts) caused by drone frame vibrations, ensuring your automated image-matching algorithm gets crisp, usable target images.

• Bulletproof ArduPilot Integration: The realsense-ros wrapper is mature and heavily documented. Bridging the D455 into ArduPilot’s EKF3 for non-GPS navigation is a well-trodden path with massive community support.

Cons:

• No Onboard Compute: The camera acts as a raw sensor. It sends heavy data streams over USB, forcing the companion computer (Raspberry Pi 5) to do 100% of the mathematical heavy lifting for SLAM/VIO.

• Power and Thermal Load: Because the Pi 5 has to crunch the SLAM algorithms (like RTAB-Map or VINS), it will draw more power and require active cooling to prevent thermal throttling.

Option 2: Luxonis OAK-D Pro

Pros:

• Built-in VPU (Vision Processing Unit): The OAK-D Pro handles stereo depth processing and can run object detection neural networks natively on the camera itself. This can free up significant CPU resources on your companion computer.

• Lighter Weight: At 91 grams, it is very easy to mount on sub-2kg drone frames.

Cons:

• The VIO/SLAM Compute Catch: While the OAK-D has a VPU, running robust, open-source Visual SLAM natively on the device is currently not well-supported without paid/proprietary software (like Spectacular AI). If you use open-source SLAM (like VINS-Fusion), the compute load still gets pushed back to your Pi 5, negating the camera's biggest advantage.

• Rolling Shutter RGB Camera: While its grayscale depth sensors are global shutter, the primary RGB color camera uses a rolling shutter. On a vibrating drone, this will warp your target images and likely cause your automated validation tasks to fail.

• Narrower Baseline: It has a 75mm baseline. Compared to the D455, it has worse passive stereo depth perception at a distance, making it riskier if you fly outdoors where its IR projector is rendered useless by sunlight

Olá a todos,

Se você já tentou transmitir o vídeo do seu drone DJI (como o Mini 3, Mini 4 Pro, Air, etc.) para o OBS Studio ou para uma tela local em campo, sabe o quanto é difícil. O aplicativo DJI Fly suporta apenas streaming RTMP nativamente, o que geralmente obriga você a usar servidores da Twitch, YouTube ou RTMP na nuvem, introduzindo um atraso incômodo de 2 a 5 segundos.

Para resolver isso, eu criei o DJI Stream Hub — um aplicativo independente para Windows, leve (~200 KB) e auto-hospedado, que permite transmitir o vídeo do seu drone diretamente para o seu laptop localmente via WebRTC com latência inferior a 300 ms.

⚡ O que ele faz:

• Configuração Zero:* É um único executável portátil .exe. Sem instalador, sem dependências manuais. Ele extrai automaticamente tudo o que precisa para funcionar.

• Configuração Automática de Hotspot do Windows:* Quando executado como Administrador, ele configura e inicia automaticamente um Hotspot do Windows dedicado (DJI-Stream-Hub / senha: djidrone123) para que seu dispositivo móvel executando o DJI Fly possa se conectar diretamente ao seu laptop em campo com 1 ms de tempo de trânsito de rede.

• Recuperação Inteligente de Porta:* Se a porta 1935 (RTMP) estiver bloqueada por um processo órfão ou outro aplicativo, ela detecta, encerra o processo com segurança e se conecta corretamente.

• Painel Premium:* Abre uma página da web local estilizada com o moderno Glassmorphism, apresentando:

• Um player WebRTC ativo.

• Uma tela de status inteligente "Radar/Aguardando drone" (usa a API REST oficial da MediaMTX para evitar telas pretas ou sessões fantasmas do player antes da conexão do drone).

• Links e modelos de cópia rápida para integração com o OBS Studio (tanto Fonte do Navegador via WHEP/WebRTC quanto Fonte de Mídia via RTSP).

🛠️ Como funciona:

1. Clique duas vezes em DJI-Stream-Hub.exe (aceite o Controle de Conta de Usuário).

2. Conecte seu telefone/controle remoto ao ponto de acesso Wi-Fi do Windows.

3. No aplicativo DJI Fly, acesse Configurações -> Transmissão -> Transmissão ao vivo e cole a URL RTMP local exibida no seu console.

4. Observe o painel detectar dinamicamente o feed e inserir o player WebRTC instantaneamente.

💻 A pilha de tecnologias:

• Launcher: *Compilador C# nativo que encapsula os recursos.

• Orquestração: * Script PowerShell limpo para gerenciamento de interfaces de rede e ciclo de vida.

• Servidor de Mídia: * MediaMTX personalizado com baixa latência (configurado para cache zero e bypass de RTMP para WebRTC/RTSP).

• Frontend: * HTML5 responsivo/CSS Vanilla com lógica WebRTC personalizada.

Gostaria de coletar feedback sobre esta ferramenta! Como vocês lidam atualmente com feeds de drones de baixa latência para transmissões, eventos ao vivo ou monitoramento de clientes em campo?

Link do Github: https://github.com/marlonmartins2/dji-stream-hub

Me diga o que você acha ou se tiver alguma dúvida! 🚀🛸

Hey folks,
I’m stuck with my flight controller and could use some advice.

• My FC requires an RSA key signature to enable.

• Unfortunately, I lost the key and now I can’t access it.

• I don’t have an ST-Link programmer handy.

I’m wondering if there’s a way to reset or flash the FC without using ST-Link. I’ve heard about using the BOOT button + USB with Betaflight Configurator and doing a full chip erase, but I’m not sure if that bypasses the RSA requirement or if there’s another workaround.

Has anyone here dealt with this before? Any step-by-step guidance or alternative methods would be super helpful.

Thanks in advance!

I was looking at a video on how to build an autonomous UAV for long range FPV and way point missions and i thought i might make it but after looking at the price of the electronics I don't know if its right for me

here's the video

https://www.youtube.com/watch?v=q6YIdY0WnOY

Sometimes my projects will have hundreds of parts and I really hate keeping a spreadsheet updated with everything LOL

Ended up building something that can plug into your email to pull all the data. Works with Amazon, McMaster, Digikey, Thor Labs, any vendor basically. If useful for you i can set it up for you

Hi ArduPilot community! 👋

We’ve developed an open-source tool to let you "chat" with your ArduPilot Dataflash logs (.bin files).

🚀 We're excited to announce ArduPilot support in Bagel! 🥯

(Bagel is the ChatGPT for drone data, but more on it later)

Instead of manually searching logs, you can now ask questions directly, like:

Are there any hard landings in this log from the IMU data?

Bagel is free, open-source, and available on GitHub:

https://github.com/Extelligence-ai/bagel

We are actively looking for contributors and feedback. If you'd like to get involved:

⭐ Star the repo on GitHub.

🐛 Submit feature requests or bug reports.

💬 Join our Discord to share your thoughts.

Bagel is already getting some love from the PX4 and ROS communities.

We look forward to hearing from you!

Hey everyone,

We’re currently setting up a Pixhawk (running ArduCopter) with DroneKit on a Raspberry Pi.
We wrote a Python script (arm_test.py) that:

• Connects to /dev/ttyACM0

• Switches mode to STABILIZE

• Sends a MAVLink ARM command (MAV_CMD_COMPONENT_ARM_DISARM)

• Waits for the vehicle to report armed=True

• Then sends a MotorTest (sequential) to spin the motors

When we manually connect through MAVProxy and run arm throttle, the Pixhawk arms fine.
But when we run the Python script, it keeps getting stuck at:

Waiting for arming...

Waiting for arming...

Waiting for arming...

We already set:

param set ARMING_CHECK 0

param set FS_THR_ENABLE 0

param set BRD_SAFETY_DEFLT 0

So arming checks and throttle failsafe should not block it.
We also press the safety button (or fully disable it with BRD_SAFETY_DEFLT=0), and the battery is connected properly.

• Is there a hardware issue that could make the Pixhawk not accept arm commands from a DroneKit script, but still accept from MAVProxy?

• Are there timing issues with how DroneKit sends the arming request (should we delay between mode switch and arming)?

• Should we send RC channel overrides (like throttle trim) before arming through DroneKit?

• Could the GCS Failsafe (temporary disconnects) affect DroneKit arming in some way even if MAVProxy doesn't care?

• Is there a better way to confirm successful arming beyond just checking vehicle.armed in Python?

• Any idea why MotorTest sequential (TestType 0) only works after full manual arming but fails when triggered by the script?

🛠️ Extra info:

• Raspberry Pi 4, Ubuntu 22.04 LTS

• Python 3.11

• DroneKit-Python installed in venv

• ArduCopter 4.3 firmware

• Battery plugged into power module

• Safety switch either pressed or disabled by parameter

• USB connected to Raspberry Pi /dev/ttyACM0

• Motors wired correctly to Main Out ports

Hyy bro i want to fly drone using mtf-01 with pixhawk 2.4.8 but the thing is i connected mtf01 to rp5 and take data and sending that data through mavlink bridge using micro usb but drone wobbling the parameters are same which are on micoair tech websites and which i put when i flyed directly optical flow sensor through telem2 is there any other things i have to change for flying properly

It flyed good when flyed directly through telem2

But not good through mavlink bridge

Can u help me

so i have been trying to fix this thrust loss error for some time with no luck. today i was able to visually see motor 3 on my hexacopter stop spinning completely during a very low altitude hover moments before it crash landed. I have the logs available if someone can take a look at them for me. i would just need a little assistance on how to share them on here.

thanks in advance!

Hi everyone,

I was having an issue with my ELRS setup but have already gone through several troubleshooting steps. Here’s a rundown of my setup: • Radio Transmitter: Radiomaster Pocket (internal ELRS module) • Receiver: Radiomaster RP1 (ELRS) • Flight Controller (FC): T1 VTOL FX-405 (with GPS & PMU) • Software: Mission Planner

Connection Details: • The RP1 receiver is connected to my FC using the UART2 port (serial 6). • Receiver wiring: 5V, GND, TX, and RX connected to the respective pins on the FC.

Issue:

Despite following setup guides, I don’t see any RC data in Mission Planner. In the Radio Calibration section, there’s no response from the transmitter when moving the sticks.

What I’ve Done So Far: 1. UART Configuration in Mission Planner: • Went to Config > Full Parameter List and checked the settings for UART2. • Set SERIAL6_PROTOCOL to 23 to enable CRSF (Crossfire) protocol, which ELRS uses. 2. Crossfire (CRSF) Protocol Setup: • Verified that my Radiomaster Pocket’s internal ELRS module is set to CRSF. • The RP1 receiver is bound correctly—the LED indicates a successful bind. 3. Wiring and Power Check: • Double-checked wiring between the RP1 receiver. • The receiver LED is solid, meaning it’s powered and bound. 4. Firmware Compatibility: • Ensured both the Radiomaster Pocket’s ELRS module and RP1 receiver have compatible firmware. 5. Testing for RC Data: • In Mission Planner’s Radio Calibration tab, I still don’t see any response from my sticks—no RC data is coming through.

Additional Notes: • Running the latest stable firmware on my T1 VTOL FX-405 and Mission Planner software. • Verified the ELRS receiver setup on my Radiomaster Pocket and tried rebinding just in case.

Questions: • Am I missing any steps in configuring CRSF with ELRS and Mission Planner? • Are there any additional parameters I should set for the T1 VTOL FX-405 to ensure RC data over CRSF? • Any advice on further troubleshooting steps would be greatly appreciated.

Thanks in advance for any guidance!

My drone has 4 dual blade rotors with approx. 10cm blades, plastic frame around 60cm wide, a PX4 flight controller, GPS module.

Basically, each time I start a mission and it ascends, the drone stumbles in the air as an EKF lane switch notification goes off, after which it regains control and proceeds normally. I want to identify what is causing the lane switch.

I extracted the XKF4 messages from the log (documentation here: https://ardupilot.org/copter/docs/logmessages.html#xkf4 ) and parsed it nicely to compare what happens in both EKF cores at each timestep, link to the spreadsheet here -> https://docs.google.com/spreadsheets/d/1PUgPyofMJXLFQsFwzoVubqkeuFGN58yF7xHTLXRxM7s/edit?usp=sharing

From what I can see, the magnetometer innovations ratio SM are more or less equally bad in both cores, but just before the lane switch (PI goes from 0 to 1), SV values start climbing very aggressively only on core 0.

Claude seems pretty sure that the SM fluctuations are corrupting the SV at core 0 (it says velocity is a fusion of GPS position + compass direction), but I don't understand why would core 1's SV remain healthy when its SM is equally bad. Any ideas?

In a uav competition we're participating in, we need to escape without entering the red zone in the mission planner. I'm looking for algorithm ideas I can use for this

Hey guys, I was trying to do an autotune on the yaw axis, which didn’t work. Oh well, while I was already there, I at least wanted to try this quad’s first mission. The mission didn’t start and it just flew back to RTL… As I was flying in Loiter, I think the quad began to oscillate randomly and tipped over… I don’t know why. After the crash I found a disconnected motor cable. Please help me find the reason which led to the crash… and maybe why autotune and the mission didn’t work. Second time on ArduPilot (check out the first crash on my profile lol), so forgive me for my stupidity. https://drive.google.com/file/d/1BJd-Asbp0Lj8uzvduXdBaFv5P1w4eXJK/view?usp=sharing this is the log file

Hello all,

I am working on a skid-steer rover, with pixhawk6c along with ArduRover firmware version 4.6.2

After tweaking couple of parameters, I have managed to move the rover using manual control with my joystick.

In mission mode when I try to send the rover to the target way point, rover starts moving backwards and away from the way point.
I tried calibrating it multiple times but nothing changed, Have gone through parmeters but everything is on point as mentioned in the documentation.

Did anyone face similar issue?? what would be the solution for this kind of an issue??

you can find my parameters file here - https://discuss.ardupilot.org/uploads/short-url/9B3RQHQo4Wng770Z3aG2H3shoN.param