Fixing Motion Quality in a High-End TV Mount to Make Good Control Better
Motor control problems are often framed as stability problems. Is the loop stable oscillating, or maybe even overshooting?
On this project, none of that was the real issue.
The system was stable. The motors were turning. The TV moved in and out. From a pure controls standpoint, it mostly worked.
Our real problem was the motion quality.
This project was a high-end consumer product. Users expected a TV mount with smooth and precise motion, and an expensive “feeling” when operating it. This meant that we could not accept even a small amount of wobbliness or jerkiness, even if we could accept such things in an industrial product.
This project was a great example of motor control firmware decisions affecting the perceived product quality, despite the functionality of the hardware.
This client reached out to us after working with another contract engineering firm. Our client did have an existing mechanical design and firmware architecture. However, they were still struggling to get the behavior they wanted out of the system.
They needed us to come in and find what was causing the issues and fix them without needing a full redesign of the hardware.
The Project Constraints and Context
Our client already had working prototypes and their mechanical and manufacturing architecture in place. They were very close to launch and did not want us to make any large scale (and expensive) hardware changes to the design.
Some of our key constraints were:
A limited ability to change the existing mechanical design
Coordination between two motors to control one visible motion
Unit to unit variance in mechanical tolerances
A friction-based clutch design with manufacturing already established
The high cost of a mechanical rework as opposed to firmware changes
Because of the design of the system we were working on, this project became a tightly coupled electro-mechanical problem. We couldn’t treat the firmware behavior separately from the mechanics.
We run into this pattern fairly often in embedded products with motion. Because the early firmware is written before the full impact of the mechanical variations can be understood, it often doesn’t stand up to the final requirements for the product. You can read more about how we approach these mixed-domain problems on our embedded firmware development services page.
The Mechanical Challenge: Making Two Motors Work Together as One.
The original TV mount design used two motors attached to the joints of an articulating arm to provide the desired range of motion for the user. One motor controlled the “elbow” joint to extend the arm away from the wall, while a second motor was in control of the “wrist” joint where the TV itself was mounted.
To keep the TV parallel to the wall, both motors had to move in coordination. If only one motor moved, or they moved at different rates relative to each other, the result was obvious rotations or tilts during movement. These small angular errors were glaringly obvious to users, even if they were relatively small errors.
The client’s choice to use a friction clutch mechanism complicated this further. The variability introduced by the friction meant we had some units slipping more than others, variable engagement times, and differences in stopping power.
Our controls were simply too inconsistent.
The Original Firmware Approach: PID Everywhere
The original design relied heavily on PID loops as a control mechanism for the motors. While this made sense on paper, because PID control is such a standard tool in motion systems, it did not work in practice.
The PID loops were tuned well enough, but they were not tuned for the hardware they were using, like the friction clutch. Nor were they tuned for the variation that existed in the real-world application they were being used for.
The original design had several issues. One motor would be turning while the other was slipping, causing errors. These errors would accumulate between the expected position and the actual position. The PID loop would then increase output to compensate, which meant when the clutch finally engaged, the stored correction caused a sudden jump in position.
The jerky motion that was the result of these errors looked sloppy and resulted in an unpredictable final product. Technically, the motors were doing what they were told, but to a consumer they looked broken.
Why PID Was the Wrong Tool for This Design
PID control functions best with consistent and reliable feedback. It also needs to be in a system where errors are corrected quickly, but that was not true of the system we were designing for.
Using a friction clutch meant feedback that was sometimes misleading. when the system thought it was applying torque, the mechanical response would sometimes lag unpredictably.
We also did not need fast correction; that was the wrong goal in this system. While sharp corrections may be mathematically efficient, they are also visually quite ugly.
This dilemma is one of the classic failures of a PID loop in consumer motion systems. When motor control firmware does not account to mechanical slip or variability, errors accumulate in a way the system cannot nicely correct.
The most important thing we needed for the system we were in was smooth movement and consistency. We needed consumers to perceive quality in the product while they used it, which meant we needed to move the design focus away from absolutely precise movement.
Simplifying Motor Control Firmware
In order to fix the issues we were facing, we ended up completely removing the PID control. We instead opted for a much simpler incremental control system.
The core ideas of this system were as follows:
Make only a few small adjustments at any given time
Avoid large corrections to prevent jerky motion
Continuously monitor relative motion between joints
Allow the system to converge gradually rather than forcing it
We did not want the system to try to aggressively “fix” errors. We wanted to gently nudge the system towards the desired behavior through small corrections instead.
This meant programming in a more measured approach. Small amounts of lag from clutch slip in one motor didn’t always need an immediate correction. The system could wait and observe the extent of the error and then adjust incrementally to correct it. Once the clutch was engaged, the system was usually near or within the correct tolerances anyways, so we didn’t need a large correction, just small, smooth adjustments.
These changes resulted in far fewer stored-up corrections, and it eliminated large, sudden jumps. Despite our approach being a little less elegant on the control theory whiteboard, it did its work extremely well in the messy real-world systems we were working with.
Self-Adjustment and Unit-to-Unit Variation
Another boon for our new system was the ease with which it handled variation.
Because we programed for adaptive control behavior and incremental adjustments, each individual unit would tune itself over time, adjusting to small mechanical inconsistencies that might not have even shown up in factory testing. Things like clutch friction and joint resistance didn’t need to be checked manually anymore; the firmware could adjust itself as it was being used.
The system was able to find its own equilibrium over time and maintain that smooth motion under its own operating conditions, without follow-ups or tune ups.
We were able to avoid costly manual calibration during manufacturing, there were no tight mechanical tolerances to worry about, and most importantly we achieved these changes without any expensive mechanical redesigns this late in the game.
Because this kind of adaptive motor control firmware is so useful, it is something we lean heavily on when designing consumer electromechanical products. We have applied a similar strategy in several other previous designs that used lots of motion, which we describe in our embedded systems case studies.
Results: Smooth Motion Without Mechanical Redesign
The end result of our redesign was exactly what the client needed. Our TV mount moved smoothly without any jerkiness, and we didn’t make any changes to the original mechanical design, so the manufacturing decisions didn’t need any changes either.
We had cleared the path to launch for our client, while also reinforcing an important lesson for ourselves. Choosing the right level of control complexity can make or break your embedded design.
Lessons We Learned
We can broadly apply several key takeaways from this project to embedded motion systems in general.
Mathematical optimization isn’t always the most important design focus.
Perceived quality can be much more impactful, especially in a “luxury” product like a TV mount.Using PID is not a default solution
While it is a useful tool, in systems with intermittent coupling or visible motion, PID can easily make things much worse from a customer perspective.Mechanical realities must be considered during any firmware design
Clutches, friction, and tolerances cannot be dismissed as simple noise; they must be accounted for in the design.Incremental control is often better than aggressive correction
If smooth convergence is more important than speed, small changes look much better and are often more precise.Firmware flexibility can save hardware cost
Smarter motor control firmware can often eliminate expensive mechanical redesigns late in a program.
Closing Thoughts
This project is a good reminder that embedded firmware is often the difference between a product that merely works and one that feels premium to the end consumer.
If you are dealing with motion systems, control instability, or products where user perception matters as much as raw performance, this is exactly the kind of problem we help teams solve.
If that sounds familiar, feel free to schedule a call and talk through what you are seeing.
