PID Tuning. With AI!

Every so often somebody tells me that

they used chat GPT or some other AI tool

to paid tune their quadcopter. And my

first reaction is that's dumb. That

doesn't seem like it's even possible.

And I suspect that chat GPT is just

saying smart sounding things like it

always does and then giving you terrible

advice and then like placebo effect.

Maybe it's better, maybe it's worse,

maybe it's a coin toss. I don't think it

can really pit tune. But I've got this

quad and I want to pit tune it. And

anytime somebody makes a radical claim

that makes me go, "That's dumb. That's

impossible." I could at least test it

out, right? That's what we're doing in

this video. We're going to use AI to pit

tune this quad. I'm Joshua Bardwell and

you're going to learn something today.

Before we get into the video, let me

make my case for why I'm skeptical that

AI or large language models can ptune a

quadcopter. It's not just me being a

sort of kmagin and like new technology

coming along and me going shaking my

fist at it, you know, old man yells at

cloud fashion.

Large language models and all sort of

artificial intelligence machine

learning. Uh the way that they work is

that they are trained on a certain data

set. So like let's say you wanted to

have a large language model that could

tell the difference between pictures of

dogs and cats. And in fact, one of the

earliest uh AI projects was a project of

visual identification similar to that

telling dogs from cats. And uh the way

it works is you feed the model a data

set which is a bunch of labeled pictures

like this is a picture of a dog, this is

a picture of a cat, this is a dog, this

is a cat. And after it sees so many of

them, it can tell the difference. It

knows dogs look like this, cats look

like that. And that's very very general

and very simplistic, but that is more or

less how large language models and AI

work. The problem arises when the AI is

presented with a piece of data that

isn't consistent with the data set that

it was trained on. Um, so for example,

large language models are very very good

at coding. And the reason that they're

good at coding, one of them is that they

have a massive body of knowledge. There

are so many projects that are public on

GitHub. The source code is there for

everyone to see. Every website is

public. You just download the website

and there's the whole thing. So there's

these massive data sets that they can

learn from. So when you ask them to do

something, there's a pretty good chance

that they have seen something like it.

And they're very, very good at putting

together those pieces into making what

seems like completely original,

completely novel solutions, but they're

not. Uh, I'm skeptical that large

language models have been trained on

Betaflight Blackbox logs or INV or

whatever blackbox logs and I'm skeptical

that the things that they have been

trained on are generalizable enough or

similar enough that they're going to be

able to produce good results. Now, there

may be some things that they can do. For

example, one of the things you do when

you tune a quadcopter is you tune the

filters. and the concept of filters, the

concept of taking gyro data and breaking

it down into into frequency components

and then filtering it. Those are

concepts that I I could see a large

language model being successful at. But

PID tuning I think is going to be much

harder. I'm I'm frankly skeptical that

it could even look understand the

contents of a blackbox log. Oh well, I

guess I was right. Uh they can't. Huh.

Video over. Far from it. And it says

yes, it can parse and analyze INAV

blackbox logs, but it admits that it

cannot directly ingest a raw binary txt

file, which um I wouldn't have thought

that it could. Okay. But then it gives

me some tips for how I can get the

information to it. And one of the things

it says is to give me the header

information. So here is the blackbox

file opened in a text editor. And if I

just grab this header information here,

boom, CtrlV,

I'm going to guess that it's going to do

an okay job at parsing this. This is

correct. This is correct. This is

correct. And this is correct. Um, these

are I don't know, are they standard

starting points? Um, this is the

starting pids for a 7 in. It's the uh

INAV 7in preset. They wouldn't be

standard starting points for a 5- in.

and it doesn't know what size drone I

have, but they're a fairly standard

starting point. It's one of the INAV

presets. It says the D term is moderate.

Well, it's literally the starting

preset, so you know, it's just probably

pretty normal. Well, I should hope

that's correct. That is the default

preset.

This is relatively low. If this is a

5-in build, this might feel if it's a

larger 7 to 10 in. That is correct. that

75 Hz gyro LPF was set uh based on INV's

recommendation in their quick tune for

10-in props. DTM LPF. Um this is a

neutral observation. Again, I didn't

change this. Uh dynamic notch is

enabled. Fine. This is an interesting

observation. With birectional DSHO,

motor RPM is reported immediately after

the flight controller sends the DSOT

packet to the ESC. The ESC responds with

a report of its current RPM. In

addition, it is reported every single

packet time. Every single time the

flight controller sends a D-shot packet,

the ESC responds with its RPM. With ESC

telemetrybased RPM reporting, it is a

separate process that's doing the

polling. And that process can be delayed

relative to the motor outputs. And

addition in addition, ESC telemetry is

pulled in a roundroin fashion. So the

flight controller pulls ESC 1 2 3 4 1 2

3 4. So the update frequency is much

slower.

The Betaflight dev's position is that

the way INAV does it, I'm not trying to

put words in their mouth, but my

impression is that they didn't do it.

They invented birectional DSHO

specifically so they could do it the way

they could do it. They could have done

it the way INAV did it and decided not

to presumably because they felt it was

inadequate. INAV's position obviously is

that it works fine. I've always left RPM

filtering off on INV for that reason cuz

I kind of believe the Betaflight devs

when they say that the way INV does it

basically doesn't work. Well, Gemini's

found another mistake that I made. Uh on

Betaflight, the raw gyro data or the un

unfiltered gyro data is recorded

automatically in recent versions. I

forgot that INV doesn't do that and you

have to set the the flight controller to

record that data manually. Oh well,

here's the first major flub for the AI.

set debug mode

equals

and

uh gyroscaled is not there. Is there

anything that might resemble gyroscal?

There isn't. I'm going to guess it's cuz

it records it automatically, but let me

just ask it. That's what Betaflight

calls it, by the way. I think maybe it's

a little confusing or aha. Yes, it's a

new INAV 9 thing. Gyro raw captures

direct software filtering. Uh, set debug

mode equals gyro raw. Except I'm pretty

sure it's already doing that. Uh,

debug mode is set to none. No, it's gyro

raw isn't there either. However, if we

look at the

uh file and we try to add graph custom

graph, we actually see gyro raw is

there. So I think what's happened is

that INV also automatically records the

raw driver data because it knows that

we're going to want it. Is there data

here? Yeah. Yeah. So it's already done

that. I don't need to set up the debug

mode. And this is the kind of place

where AI kind of trips over its own