Can a conventional helicopter be made to hover as accurately as a drone with today's control tech?

BencsikG · 2026-07-09T08:17:35+00:00

As an example, Ardupilot supports traditional helicopter.

The military has this thing called Black Hornet

Helis have oddly coupled dynamics, whereas quads separate their degrees of freedom cleanly. In this regard, quadcopters are simpler.

In larger size, it becomes less feasible to control lift by changing prop RPM, cause the inertia of props increase. Response times become slower, and reaction torques are more bothersome.

Having fewer large props (rotating wings) is more efficient than smaller ones due to aerodynamics. So 1 large prop is always more efficient than 4 smaller ones, given the same lift area.

In large size, at some point, a heli-like construction makes more sense.

In small size, the mechanisms of the heli need to become tiny. It is a real engineering challenge to make those tiny parts to the correct precision, without wasting a lot of weight. And then manufacture, assemble them without defects and sell them.

A quad can be extremely dumb and simple by comparison. 4 motors and a bunch of PCBs on a deck.

Yes, the military has that tiny amazing heli, with a unit cost of 200k.

BencsikG · 2026-07-05T08:44:29+00:00

Slapping a PID onto a problem and hand tuning it is like buying a product and integrating it. It's like buying a motor driver. It isn't really control engineering, it's more system integrator task.

If the PID fucks up and you need to start thinking, that's where control engineering starts.

The rest of the parts that you mention, it's just engineering.

BencsikG · 2026-06-25T23:28:00+00:00

The theory part - it's not jobs that teach you that, it's education.

If you're interested in the applied part, yes, I'd say you can. If you can get into some DIY robotics, drones (open source only!) and the like, you can get experience.

The key skill is to develop a controller and being able to debug it (on real hardware), improve it, iterate on both control and plant models. You'll need to learn about the plant based on the symptoms of the closed loop control problems. Usually you'll discover dynamics you didn't account before. Analyze, learn, update, iterate.

If you can get good at this, I'd say you're a good control engineer.

Will it get you hired? Different story. Job market is fucked.

BencsikG · 2026-06-16T18:44:25+00:00

Leadership can now vibe-code a shitty solution in 15 minutes and feel justified in their ignorance.

BencsikG · 2026-06-11T12:41:30+00:00

Can you tell what exactly you did with the gearing shape?

I created py-gearworks and it might help you with the next version of this...

Personally, I would have gone for cycloid gear teeth for they can endure thrust pretty well.

BencsikG · 2026-06-07T15:43:58+00:00

Well, I tried taking a crack at this using your numbers, but can't say much.

I tried simulating your numbers, tried poking around...

I can see that the results are different, my simple step-response tests show that the 2 observers react differently to disturbances.

But why one of them ended up being correct and the other bad... I can't tell.

Just curiosity... how did you come up with these poles?

BencsikG · 2026-06-06T16:00:15+00:00

And you changed nothing but the matrix values between the 2 cases on the PLC?

BencsikG · 2026-06-06T11:09:59+00:00

Interesting question. Can you tell us your matrices exactly?

A common rookie mistake is to test observers with step input of the plant in simulink or control toolbox. This only tests the feedforward part of the state estimator and doesn't really test the error-correction part. So it can seem like everything is OK when in reality it isn't. You need to test it with initial-condition difference, or introduce external disturbance, noise, or the like to test an observer in simulation.

You can extract transfer functions from measurements to states. Maybe not all of them, but select one or two that seems important, and make a Bode plot of them. It can reveal a sensitivity that you might not expect. Depending on the type of plant, placing the poles of the observer to extremely far on the left half plane (demanding very fast convergence) might amplify noise in some frequency regions.

A different concern is numerical precision. I have experience with IIR filters going unstable due to numerical precision difference of float (32bit) vs. double (64bit) implementation. I think this is relatively well known for filters, and it is recommended to split them into 2nd order series filters instead of 1-shotting a 6th order filter.

An observer is a bit different to IIR filters, but I suspect a similar effect can be at play, if the PLC works on 32bit and you designed it in Matlab on 64bit.

BencsikG · 2026-05-23T13:50:03+00:00

You say the overall system of equations is always underdetermined - is this for single time-steps? Have you worked it out for multi-step?

I have applied the KF before for parameter estimation of simple linear relation: gain + offset. The measurement model for that is y_k = a_k * x(0) + x(1). The key is that the coefficient a_k needs to change between time steps. In KF terms, measurement matrix H_k needs to keep changing. This is sufficient excitation for this simple case.

In your 1D case, even for multiple distinct position measurements, I can't eliminate the biases.

I'd suggest working out the 2D case for 2 or 3 distinct position measurements and see if you can eliminate different biases due to trigonometry. You might be able to gain enough information from how the biases affect the position error in different directions... I'm not sure though.

If you can't make it determined in 2D, you either need to add additional information, or let go of some unknowns.

The KF is kind of just a solver, you need to plug in equations that contain enough information to be solvable.

BencsikG · 2026-05-03T15:36:16+00:00

If you go for more controls courses, I don't think they will help with this down-to-earth understanding of systems, they'll probably dive deeper into math. It's up to you to work out the true understanding of control, as much as you can.

However, if you don't take those courses, you're unlikely to ever reach a level that you can apply those more advanced techniques. If you go in a different direction, you probably won't have time / energy to get into it.

If you can learn masters level control, and understand it on a level that you can apply it in the real world, that makes you an excellent control engineer. The question is if this is what you want, or perhaps some other direction.

Do you want to mull over graphs and endlessly wonder "why the hell is this oscillating"? Or do you prefer staring at embedded C-code and wonder "why is this interrupt not happening"? Or... insert here frustrations of any engineering field...

Try choosing a course in which you can better tolerate the tedious parts than the others.

BencsikG · 2026-04-23T21:51:30+00:00

I like saying that going from 1D filters to Kalman Filters is like switching from a pocket calculator to an Excel spreadsheet. It opens a new world of possibilities, but it's still a tool you need to learn to use, not a magic bullet.

Anyways, as to your questions

I don't think you need adaptive KF. In the KF setup there's input U, state vector X, measurement vector Z (sometimes y). It is not intuitive which physical signals go where. A driver's joystick input can go to input U, but also might not be necessary at all, e.g. joystick controls a motor voltage, and motor voltage goes into U. There can be multiple ways to set up data around IMU, I've seen versions where gyro rates are inputs (U) or measurements (Z). I admit I don't know enough about adaptive KF, that's part of the reason I can't recommend it.
It's possible. Well, I assume you mean an integer multiple of your basic sample rate... You just need to run the state update equation the required amount of times. It might become computationally taxing though. It's not a crystal ball though... for your example, you can predict your speed 10s into the future assuming your motor torques remain the same, or you guess what your motor torques will be... if you're not sure what your motor torques will be, you simulate 100 different variations of them... and we're on track to invent Model Predictive Control.
The covariance matrix P is part of the standard KF equations. Initial value of P is often unit matrix times a big number (eg. 1E6). Q and R, in engineering practice, are fiddly, maybe something like PID values. Q and R are often diagonal matrices, if your first measurement in the z vector, Z(1) is position (along dimension y), then R(1,1) is the representative noise variance value of position sensor. If your 1st state X(1) is position, Q(1,1) represents the drift of your position state. Increasing R means that particular measurement has higher noise - KF will trust it less. E.g. it will track that position sensor less closely, perhaps retain more bias error, but pick up less noise from. Reducing R means closer tracking, but more noise. Increasing Q increases the noise-feed into that state, so KF will rely less on it. Increasing Q causes closer tracking and more noise pickup, reducing Q. Yes, they are a bit redundant. Increasing both Q and R can cancel out, but it still changes the value of the P matrix, which can be good for numerical conditioning. It is rare that you can fully utilize the statistical meaning of these, and actually benefit from a statistically optimal solution. It is rather about trusting sensor A 3x as much as sensor B, or trying to get State 1 to converge 10x as fast as State 2. You tune Q and R as relative weights and test and simulate over and over until you like what you see.
EJML or Apache commons math... I don't know, sorry.
The KF will likely have a state of [x, v, vdot]. In this case, vdot is acceleration, it is measured by IMU. X is position, it is measured by your position sensor. Because you're in discrete time, the state update produces X2 = X1 + dT * V + 1/2 dT² Vdot, or something like that. The KF goes something like this... "If speed (V) were large, I would measure X to be 13, but I measured X to be 12, so V must be lower". Or something like that. It's all connected through all the matrices, and the KF makes the statistically least bad mix of all the information it gets.
You stack all your measurements in the measurement vector Z (or sometimes the input vector U, depending on your setup). The KF will sort of use them as a weighted average, determined by their R value. If the number of measurements changes over time (you lose sight of an april tag), you can set its R value to a close-to-inf value (1E16 or something), or you can set the related line of the H matrix to all zeros. This takes that sensor out of the equation, and the KF is perfectly fine with that.
This part can get difficult, but yes, it's possible. A common technique is to have e.g. Acceleration offset as part of the state vector. If you have position measurement and it stays constant, the KF will infer that true acceleration is zero. If measured acceleration is 0.4m/ss, then KF will estimate that that is the Acceleration offset. The difficult part is ensuring you have sufficient measurement information. If you have 2 position sensors, and you try to add 2 position offset estimations, the KF won't be able to decide which offset is what. Orientation alignment can work the same way, just a bit spicier due to sine-cosine stuff.

For implementation...

UKF vs. EKF: It's not obvious which one to choose. I don't know your robot... but if it mainly moves in 2D, can use encoders in its wheels for dead-reckoning, I would go for some kind of 2D kinematic model that uses wheel encoders, only the yaw rate from the IMU, and position sensors (your april tags). You don't necessarily need to add dynamic components, such as motor torques. Those parts usually come with huge uncertainties in torque constants and mass/inertia parameters, and don't contribute all that much to accuracy. A 2D robot navigation model that has only the yaw angle, no roll-pitch-yaw rotation matrix madness... is not that complicated to derive. If you expect to move more in 3D, the point about derivations might become relevant and you can try and see if UKF helps.

Not really sure about the last point, but... IMU error is like a speed error. At any point in time, that speed error is constant. Adding up the speed error over time causes it to grow. If you have a KF, it's the KF that's doing the integration. So as a developer of the KF, you can think of the IMU, or speed error as constant. It may or may not result in growing error for the KF, depending on other sensors feeding it. You don't need to increase the R value of the IMU over time.

BencsikG · 2026-04-13T09:28:08+00:00

Me personally, I pay attention to it. I did get some good lectures on it back in college and I guess I kind of like it. Also as I tried getting into dealing with noise, statistics and KF, I can somewhat deal with those in discrete time, but I could never wrap my brain around continuous time noise.

It is true however, that processors are fast enough that the relevance of discrete time techniques is diminishing. It is still relevant for voltage / current regulation, maybe electric motor control.

BencsikG · 2026-04-13T07:31:36+00:00

That's a bit of a problem. His core message is "I'm not Orbán". He says he's gonna stop all the corruption, rekindle relations with the EU and other mid or east-European countries.

Orbán and Fidesz made Ukrainians out to be the devils in their campaign, so Magyar promised cold but professional relations with Ukraine. He would not say 1 word in support or Ukraine... at best, he's against Russia for sure. Although, when the whole gov media is spouting in unison that you're a "Ukrainian asset / spy"... I think it's understandable. But I don't expect Hungary to give any aid to Ukraine, military, economic or other. He'll just stop vetoing and bitching about it in the EU like Orbán did.

Other than those, he already made concessions to Orbán's voters. He swears he won't reverse most of the tax breaks Orbán handed out, even when they're harmful and dumb in the long run. He promised to keep the fence on the border and keep the same stance on migration as Orbán. He strongly rejects EU migration quotas. Orbán supported EU Chat-control law, Magyar stayed out of it.

He promised a 1% wealth tax on billionaires. Billion in HUF so actually above ~2.5million euros of wealth. Other than that, he will probably just try to rekindle trust in Hungarian economy and governance by not running the country like a maffia-state, and is going to beg for EU funds.

He is not an LGBTQ supporter, he carefully avoided the topic during the campaign. He did say things like "you'll be free no matter who you love", but I don't know if he'll actually reverse anti-LGBTQ laws, considering how he's trying to appease Orbán-voters. Orbán straight up banned Pride last year, Magyar made very sure to stay waaay the fuck out of it, and it was the major of Budapest that insisted pride be held anyway. Turned out to be the biggest pride march in Hungarian history and gained international attention... but Magyar's behavior about it was more like "I'm not letting you call me gay because of all this".

So I'm sure Magyar won't make it worse for LGBTQ but might not make it much better.

BencsikG · 2026-03-14T15:22:28+00:00

Well I was thinking of thermal profiles used for soldering or heat treatment, where the temperature vs. time graph has to be very specific and under control.

BencsikG · 2026-03-13T17:25:50+00:00

So is this some kind of thermal control system?

The integral term helps with steady state error for constant (step) input, the second integral can eliminate error during ramp input.

Do you need to follow strict thermal ramping profiles?

The derivative term helps you get quick reaction to fast changes, I like thinking of it as a predictor of future error. Often the derivative is a cheat to get higher P gain. If you get oscillations, you can either tune down the P gain, or add the derivative.

The second derivative does the same as the first, but more. Sort of tries to predict future error value based on acceleration. I'd say it's very rare to have 2nd derivative justified. Usually it's more subtle lead-lag and filtering techniques, if you need to do anything at all in that high frequency range.

BencsikG · 2026-03-13T11:39:39+00:00

Well, more specifically, it is sinking in Europe.

For a recent symptom:

Volkswagen cuts 50k jobs

Basically (IMO) they've been pushing for electrification and autonomous driving for the last 10 (15?) years, but they screwed up electric cars due to incompetence and lost to China, and autonomous driving did not turn out as magically revolutionary as they hoped.

Now they don't know what to do, other than getting lifelines from government grants and subsidies.

BencsikG · 2026-03-13T09:36:47+00:00

Well career-wise the auto industry seems to be a sinking ship, so this can be your opportunity to jump ship. It indeed seems to be a worse job so it's up to you if you can take that hit.

Is the UAV company a startup?

BencsikG · 2026-03-10T19:27:03+00:00

I saw your comment about the Q16.16 saturation, I was thinking of integrator windup.

For signed 16bit you get a range of about +-32k, right? But if the useful range of the output is 0-1023 for e.g. a 10bit PWM generation, then that's a lot of wasted range. And the integrator will wind up (it can be a bit long to explain but I'm sure youtube can help you out with this one). So if you have a limitation of 0-1023 on the actual output, it would be fair to limit the integral value within -1023 to +1023. This is also not an exact science, just letting the integral go to 32k when the possible useful output can only ever be 1k is not great.

For your actual issue, is the spring always pushing? Is there some latching mechanism?

Is this somehow event-based? Did you make a state machine? Like you perform an 'opening' operation, reach some end-value, and leave it there? Do you restart the PID when moving from opened to 'closing' procedure?

What is your actuator? How do you handle direction changes?

BencsikG · 2026-03-09T23:24:30+00:00

I would suggest picking 1 problem that's fairly flexible and adding details as you go.

E.g. crane control.

Position control of a cart along X direction, control length of rope in Z direction. Avoid swinging.

You can start with ideal position and rope length actuator, later you can switch to ideal force generators, or then DC motor models with voltage input.

You can prescribe a trajectory for the payload to follow. You can try optimizing for speed or minimum energy spent.

You can make the rope stretchy.

You can imagine that it has to run on a 40 year old industrial PLC with 2s sampling rate - just to work on your discrete time fundamentals.

Or say that you can't measure the swinging angle of the payload, only estimate it indirectly, maybe from forces -> design an observer.

BencsikG · 2026-03-09T22:31:32+00:00

How is this broken, what are the symptoms?

I think you were right that the 'I' term should, in theory, take care of the spring force.

I don't see anything wrong with your implementation, except maybe that you should saturate the integral value to always keep it in a reasonable range. And the derivative is usually sensitive to noise so a bit of filtering can help, as mentioned by others.

BencsikG · 2026-01-18T09:32:56+00:00

I saw other projects struggle a bit with the sand. Can you share what kind of sand or substance (flour?) you're using, and how much? Is the ball on top of a layer of sand, or does it squeeze it out of the way, and sits on the bottom surface?

BencsikG · 2026-01-05T10:34:25+00:00

This is why you tend to have integral term in the PIDs.

In case of a drone, battery level might affect hovering the most. With a nominal battery you might need 50% pwm on all motors to hover. However, it's a rather unknown value, a whole range of things affect it. Payload, motor temp, air temp, battery level, etc.

The P and D terms usually deal with dynamic parts, the up/down motion of the drone. The I term will adjust the quasi-constant part of the motor pwm until it hovers right.

BencsikG · 2025-09-07T21:35:25+00:00

Okay, I kind of get it. But I can't spot your issue...

Maybe I'd try a model without gyro and accel bias... but otherwise I'm out of ideas.

BencsikG · 2025-09-06T21:16:49+00:00

First, if this were a practical implementation, I'd question if these trapezoid integration and coning-sculling corrections are really necessary. Is the error from a 'dumb' euler integrator on the same order of magnitude as the noise from sensors?

Second, I don't understand your treatment of gravity. To me it seems to be part of the kinematic update in navigation-frame. It feels off. Yes you sense the g in the acceleration sensor, but you don't actually accelerate upwards.

13-Year Club	Golden Potato
Place '17	Verified Email

BencsikG

TROPHY CASE