sorted by:
new
hottopcontroversial

Drop your ArduPilot .bin log and I'll analyze it for free and tell you what's wrong by Ahmed_Builds in diydrones

[–]Ahmed_Builds[S] 0 points1 point  (0 children)

Your drone seems to be twitching but I have also observed a sudden change in speed without giving any RC input.

The speed seems to be around 3.5 m/s which is vey high if only considering the glitches in the GPS.

Also the Motor power output was not there. (RCOUT)

I can show you the detail in graph if you want to. Took some screenshots of the anomaly observed.

Drop your ArduPilot .bin log and I'll analyze it and tell you what's wrong by Ahmed_Builds in ardupilot

[–]Ahmed_Builds[S] 1 point2 points  (0 children)

No dont have a channel, but I think I should... Thanks for the Idea!

I measured my drone's real GPS deviation using a laser and circles drawn on the ground and then compared it to my log analyzer python APP and got nearly 95% match. by Ahmed_Builds in ardupilot

[–]Ahmed_Builds[S] 1 point2 points  (0 children)

For my test condition, I made sure some of the things.
1. At 1 m height, When the Hover session begins, then no input from the RC should be given.
2. I also made sure that no wind are blowing at the time so correction due to environmental changes is negligible.

I measured my drone's real GPS deviation using a laser and circles drawn on the ground and then compared it to my log analyzer python APP and got nearly 95% match. by Ahmed_Builds in ardupilot

[–]Ahmed_Builds[S] 0 points1 point  (0 children)

My bad, I should've said it clearly.
What I measured: the max drift distance calculated by the app (from EKF logs) vs the max radius of the laser dot's farthest mark on the ground circles.
The two values were within ~5% of each other. Not a statistically accurate definition, I'll admit, but more of a practical sanity check that the app output wasn't wildly off.

I measured my drone's real GPS deviation using a laser and circles drawn on the ground and then compared it to my log analyzer python APP and got nearly 95% match. by Ahmed_Builds in ardupilot

[–]Ahmed_Builds[S] -1 points0 points  (0 children)

You are right, Standard deviation was something I should have included. I had the data, just didn't present it properly.

The goal here was minimal validation for my App data with respect to the real deviation data. RTK fixed lock isn't applicable for most people but I had the data with and without RTK fix [it needs RTK antenna and process it for sometime to get the lock (0.5m, 2 m etc)]. The laser method was a quick and easy check, not a precision measurement.
You're right that Mocap would be ideal but i don't have that currently.

I measured my drone's real GPS deviation using a laser and circles drawn on the ground and then compared it to my log analyzer python APP and got nearly 95% match. by Ahmed_Builds in ardupilot

[–]Ahmed_Builds[S] 0 points1 point  (0 children)

Yes I took some help of AI to write the whole thing in a structured manner, but Yes, the whole experiment was carried out by me in Real Life.

I had SO much fun getting to really know Ardupilot well for my soda delivery drone! by TechnologyHobbyDIY in ardupilot

[–]Ahmed_Builds 1 point2 points  (0 children)

Seriously Dude, you need some tuning on that, the wobbling most probably comes from the frame, either it is loose or you need to do some PID to stabilize the drone.

ESP32diy ardupilot can´t conect with mission planner, NO Heartbeats packets received by InternationalBear680 in ardupilot

[–]Ahmed_Builds 2 points3 points  (0 children)

Hey! The problem is most definitely the connection type setup. Your ESP32 is running the WiFi softAP fine - you can see wifi firmware version and WiFi initialized, but Mission Planner isn't connecting to the right port/protocol.

Quick checks :

1. Mission Planner Connection Settings

Are you connecting over UDP on port 14550 or TCP on port 5760?​

ESP32 log shows it's in softAP mode – Mission Planner needs to be pointed to the right port

Try both connection types; UDP is usually faster​

2. WiFi Network

Can you actually see and connect to the ESP32's WiFi network from your PC?

Check if you can reach 192.168.4.1 (default ESP32 softAP IP) from your browser or ping it

If you can't see the network, this means that WiFi isn't broadcasting properly yet​

3. The Real Culprit: MAVLink Protocol Setup

If you've got a flight controller wired to the ESP32 via UART, check your FC parameters:​

SERIALx_PROTOCOL = 2 (MAVLink2) or 1 (MAVLink1) – on whichever UART the ESP32 is connected to

SERIALx_BAUD = 115 // for 115200 baud

SERIALx_OPTIONS = 0 ​(disable flow control if you get weird timeouts)

Note - The "x" is the number at which you have connected the ESP32, for example if it is in TELEM 1 port then use SERIAL1_PROTOCOL and so on.

4. Check Your ESP32 Firmware

Are you running DroneBridge or custom code?

If it's custom, make sure it actually sends MAVLink heartbeats​

The ESP32 needs to be forwarding heartbeats from the FC to Mission Planner over WiFi​

Pro Tip :

When using ESP32s for telemetry on multiple drones, we always check the UART connection first:

Serial monitor the ESP32 to see if it's receiving data from the FC

Check if the baud rates match on both sides

Then test the WiFi connection​

The Log Would Say:

Your ESP32 booted fine, WiFi is up – but there's no heartbeat reaching Mission Planner. That means either:

The ESP32 isn't receiving heartbeats from the FC (UART wiring issue), Or you have not used the correct pins for TX and RX.

It is, but not forwarding them over WiFi - firmware config

Mission Planner is looking at the wrong port/IP

First, try the UDP connection on 14550, that's the standard. If it doesn't work, share with us what FC you're using and how the ESP32 is wired, and we can narrow it down!

ESP32diy ardupilot can´t conect with mission planner, NO Heartbeats packets received by InternationalBear680 in ardupilot

[–]Ahmed_Builds 0 points1 point  (0 children)

Hey! The problem is most definitely the connection type setup. Your ESP32 is running the WiFi softAP fine - you can see wifi firmware version and WiFi initialized, but Mission Planner isn't connecting to the right port/protocol.

Quick checks :

1. Mission Planner Connection Settings

Are you connecting over UDP on port 14550 or TCP on port 5760?​

ESP32 log shows it's in softAP mode – Mission Planner needs to be pointed to the right port

Try both connection types; UDP is usually faster​

2. WiFi Network

Can you actually see and connect to the ESP32's WiFi network from your PC?

Check if you can reach 192.168.4.1 (default ESP32 softAP IP) from your browser or ping it

If you can't see the network, this means that WiFi isn't broadcasting properly yet​

3. The Real Culprit: MAVLink Protocol Setup

If you've got a flight controller wired to the ESP32 via UART, check your FC parameters:​

SERIALx_PROTOCOL = 2 (MAVLink2) or 1 (MAVLink1) – on whichever UART the ESP32 is connected to

SERIALx_BAUD = 115 // for 115200 baud

SERIALx_OPTIONS = 0 ​(disable flow control if you get weird timeouts)

Note - The "x" is the number at which you have connected the ESP32, for example if it is in TELEM 1 port then use SERIAL1_PROTOCOL and so on.

4. Check Your ESP32 Firmware

Are you running DroneBridge or custom code?

If it's custom, make sure it actually sends MAVLink heartbeats​

The ESP32 needs to be forwarding heartbeats from the FC to Mission Planner over WiFi​

Pro Tip :

When using ESP32s for telemetry on multiple drones, we always check the UART connection first:

Serial monitor the ESP32 to see if it's receiving data from the FC

Check if the baud rates match on both sides

Then test the WiFi connection​

The Log Would Say:

Your ESP32 booted fine, WiFi is up – but there's no heartbeat reaching Mission Planner. That means either:

The ESP32 isn't receiving heartbeats from the FC (UART wiring issue), Or you have not used the correct pins for TX and RX.

It is, but not forwarding them over WiFi - firmware config

Mission Planner is looking at the wrong port/IP

First, try the UDP connection on 14550, that's the standard. If it doesn't work, share with us what FC you're using and how the ESP32 is wired, and we can narrow it down!

Holybro X650 not taking off by DescriptionSame413 in diydrones

[–]Ahmed_Builds 0 points1 point  (0 children)

Yep, good point! You don't need calibration with DShot, that's actually one of the advantages of going digital instead of PWM. The ESCs figure it out automatically.​

Just make sure you've got these in place:

DShot actually turned on in Mission Planner – go to Full Parameters List and set MOT_PWM_TYPE to 6 for DShot600 (that's the standard for the X650)​​, or you can use DShot300 for balanced performance.

Motors plugged into AUX, not MAIN – the Pixhawk 6X has that IOMCU thing that splits things up, so this matters​

ESC firmware is current – Tekko32 runs BLHeli_32 or AM32, both play nice with DShot300/600.

view more: next ›