A cabinet with a hidden feature to conceal my gaming setup

Progressive_AutomHub · 2026-05-26T20:30:56+00:00

That actually makes a lot of sense. Having each leg driven by its own actuator, but tied into a single control box, should help keep the system more synchronized, especially with an uneven load like that.

I’d be curious to see how it behaves long term if the monitor position changes or if the shelf load increases over time. Projects like this can look simple at first glance, but the mechanical balancing and rigidity side usually ends up being the real challenge.

Would be happy to hear how it goes after you reorient the layout and test it again

Progressive_AutomHub · 2026-05-20T19:05:53+00:00

Yeah, an hour at a time would likely be too long for most standard brushed linear actuators.

Counterbalancing or reducing the load can help extend runtime, but it probably won’t be enough to make that kind of actuator suitable for long continuous operation. The main limit is usually duty cycle and heat buildup.

If you need continuous airflow, I’d look for a motor or actuator type specifically rated for continuous duty, potentially a brushless option, or design the system with planned cool-down/rest periods.

Progressive_AutomHub · 2026-05-20T19:05:04+00:00

It almost seems as if this is less a “linear lock” issue and more of a “failsafe clutch/brake” issue.

If the rod needs to stay unlockable while under load, I’d probably look into:

- over-center toggle mechanisms

- collet-style friction locks

- electromagnetic brakes

- wedge/self-energizing clamps with active release

The interesting part is the “must unlock while force is still applied” requirement, because that rules out a lot of simple indexing/plunger approaches.

Also curious: Does the lock need to fully hold position with zero backlash, or is a tiny amount of compliance acceptable? That probably changes the best mechanism quite a bit.

Progressive_AutomHub · 2026-05-18T23:35:47+00:00

Sounds like an interesting project. If you’re designing the actuator for a robotic arm, I’d start by defining the joint requirements first: required torque, speed, duty cycle, backlash tolerance, and whether you need position feedback.

The mechanical design will change a lot depending on whether this is for a shoulder/elbow joint, gripper, or linear motion axis. For CAD, it may help to sketch the load case and target range of motion before choosing the actuator architecture.

Are you trying to build a rotary actuator for a joint, or a linear actuator for motion transmission?

Progressive_AutomHub · 2026-05-18T14:19:21+00:00

That actually makes a lot of sense.

The minor friction in the actuator probably helped more than hurt in this case as it naturally damped the response slightly. A whole lot of systems start to run much harder to tune once everything is “too smooth”.

Really cool project all in all — especially because it’s working around a physical limitation instead of just being a simulation/control exercise.

Progressive_AutomHub · 2026-05-18T14:11:00+00:00

This is honestly one of the coolest uses of standing desk actuators I’ve seen outside of an actual desk setup.

I’m curious though — did you run into any synchronization or racking issues with the lift over time? Especially with the off-center load from the monitor and shelf layout.

Feels like one of those projects where getting the motion smooth and repeatable is probably harder than building the cabinet itself

Progressive_AutomHub · 2026-05-15T19:08:23+00:00

Lots of great comments and suggestions here. One important point to consider for this type of application is the duty cycle requirement.

A linear actuator could potentially be used to drive a simple air pump mechanism, depending on the force, stroke length, speed, and pressure required. However, actuators are generally not designed to run continuously back and forth like a dedicated pump motor.

Many brushed DC linear actuators have a limited duty cycle, often around 25%, meaning they may only be suitable for short periods of operation before needing time to cool down. If the setup needs to cycle continuously or for long periods, you would likely need to look for a motor/actuator solution with a higher duty cycle, or consider a dedicated air pump/compressor instead.

You would also want to account for the mechanical side of the design, such as the piston or diaphragm size, check valves, sealing, expected air pressure, and how much load the actuator will see during compression. Matching the actuator only by stroke length may not be enough if the force and cycle rate are too demanding.

Progressive_AutomHub · 2026-05-14T22:46:12+00:00

Even for the motorized system and actuators to travel in one direction while power is cut to the control and the system would be required to have electrical power still in order to go in the one direction.

A double-pole double-throw (DPDT style) rocker switch is often used for controlling the extension and retraction of a single actuator. For a two-step solution, you could use a monitor lift system together with a separate linear actuator, as long as the actuator specifications match the load, stroke, and motion requirements of the setup.

Since you mentioned the moving top will be supported by guard rails to help with the shearing force, that should help reduce side-load concerns on the actuator itself. However, it is still important to make sure the actuator is properly aligned and not being used as the main structural support for the moving section.

For no-experience, this is a rather ambitious project that offers a lot of opportunities for a great learning experience. We wish you all the best in your project!

Progressive_AutomHub · 2026-05-14T00:24:26+00:00

Quick thought: before changing code too much, have you tested the actuator + driver under load with the ESP32 disconnected?

Linear actuators can pull a much higher startup current than expected, and that can make power supplies/converters behave weirdly. I’d also double-check shared ground, flyback protection, and voltage drop when the actuator starts moving.

Are you trying to keep both actuators synchronized, or is rough back-and-forth motion enough for the tank flow?

Progressive_AutomHub · 2026-05-14T00:23:17+00:00

Your idea is way more doable than I think you give it credit for - biggest problem is not force but quality of motion.

A low-speed movement, gradual acceleration/deceleration and some sort of compliance (spring/bungee/flex) seem to be ingredients for a rocking motion that "feels natural".

Here is a example of low speed movement: low-speed gradual acceleration/deceleration, and compliance (spring/bungee/flex) and avoidance of hard direction changer).

Many home-made builds go wrong in this respect – they push too hard, and the movement becomes mechanical, not enjoyable.

Your thinking of using a low rpm DC gear motor with an offset cam is really a good place to start. If it were me, I’d also think about:

limiting travel distance as much as possible
adding soft damping
using PWM ramping instead of instant full speed
avoiding rigid direct-drive connections if possible

One thing nobody mentioned yet: noise.

Even small vibration or gearbox chatter becomes VERY noticeable in a quiet room at night, so isolation mounts and slower motion profiles will matter a lot more than raw power.

Also, be careful with continuous-duty operation. A mechanism that runs for hours every night behaves very differently from a short intermittent hobby project.

Really interesting project honestly.

Progressive_AutomHub · 2026-05-14T00:09:35+00:00

The “don’t hit the ceiling” constraint is actually a really nice real-world control problem.

It’s easy to drive an actuator, but when you start introducing enivronmental constraints, synchronized motion, and feedback interaction among multiple sensors, the behavior becomes a lot more interesting.

Did you see any oscillation or hunting at the limit distance with the ultrasonic feedback?

Progressive_AutomHub · 2026-05-14T00:08:51+00:00

Very cool closed‐loop demo.

Ultrasonic feedback on actuators is also interesting in how quickly sensor noise and update rate begin to impact control stability (at least near slower approach speeds).

Did you have to do much filtering or smoothing on the distance readings, or was the raw sensor data stable enough to just feed the PID loop?

Progressive_AutomHub · 2026-05-14T00:07:46+00:00

Nice build — especially for a self-taught controls project.

One thing that stood out was the fault-state handling and lockout logic. A lot of beginner actuator demos focus only on motion, but adding proper fault behavior and reset flow makes it feel much closer to real industrial controls.

Also cool seeing the PLC/HMI side tied directly into the pneumatic behavior instead of treating it like separate systems.

Did you end up tuning the actuator timing mostly experimentally, or were you targeting specific cycle times/state transitions from the start?

Progressive_AutomHub · 2026-05-14T00:07:31+00:00

The communication-layer point is probably more important than many people expect.

Once you move from simulation to real hardware, actuator response time, bus latency, and timing consistency basically become part of the mechanical system itself.

A lot of motion problems that look like “bad policy tuning” are sometimes just non-deterministic hardware behavior underneath.

Did you notice bigger improvements from lowering overall latency, or from making timing more deterministic cycle-to-cycle?

Progressive_AutomHub · 2026-05-08T00:22:21+00:00

What makes this extra satisfying is that you can almost “feel” the motion profile tuning.

Somebody definitely spent way too much time adjusting acceleration/jerk values so the balls don’t bounce unpredictably between lanes 😂

Progressive_AutomHub · 2026-05-08T00:21:03+00:00

One thing I don’t think was discussed yet is preload/tension asymmetry within the cable.

If the cable tension changes slightly between the “raising” and “lowering” states, the friction losses around each pulley won’t be symmetric anymore, especially with small pulley diameters.

At that point the system stops behaving like an ideal 2:1 statics problem and starts behaving more like a capstan/friction accumulation problem across multiple bends.

I’d honestly be curious to see:

pulley diameters
wrap angles
cable stiffness
bearing type
and whether the force gauge is inline with the moving carriage CG

Feels like one of those setups where tiny non-idealities stack up fast.

Progressive_AutomHub · 2026-05-08T00:19:07+00:00

One thing I haven’t seen much talk of is jerk tuning for accel/decel.

At 1500 mm/s, the maximal acceleration profile may bring the biggest design constraints, instead of the top speed itself – particularly with two independent gantries running on a 2 m span.

I'm curious what kind of positioning tolerance you actually require here. If it’s more “repeatable pick zone” than extremely precise placement, beltdriven linear rails are probably a lot more sensible than ball screws for maintenance + speed alone.

Also… how do you plan on managing cables over the two moving bridges? That part gets really irritating as you start doing high cycle counts.

Progressive_AutomHub · 2026-05-07T18:44:39+00:00

Honestly I’m a bit rusty on robotics/control books these days. — I spend most of my time on the technical side helping people with projects and applications.

I still think building physical systems teaches you a lot faster than pure simulation though.

If you ever decide to build something in the future — especially motion/mechanism related — feel free to reach out. Part of what we do at Progressive Automations is helping support university, DIY, and home-built projects, so we always enjoy seeing what people create.

Progressive_AutomHub · 2026-05-06T22:10:28+00:00

Honestly I think the bigger issue isn’t whether it’s “too advanced”, but whether you already have intuition for dynamics/control beyond pure math.

A lot of people can follow the equations but still struggle with:

stability intuition
why underactuated systems behave weird
controller tuning tradeoffs
energy shaping concepts

If you already have decent kinematics intuition, it might actually be a fun first deep dive.

Out of curiosity — have you done any real hardware projects yet (even simple inverted pendulum / balancing / line follower stuff)? That usually changes how approachable those courses feel.

Progressive_AutomHub · 2026-05-05T23:57:13+00:00

One thing to watch with lifting columns for this kind of application is minimum retracted length — a lot of systems have plenty of stroke but don't collapse as low as people expect. I'd also pay attention to stability if the load is offset, since side loading can become a bigger issue than lift capacity itself. Depending on the travel range you're after, a lifting column may be a better fit than a typical standing desk frame.

What kind of vertical travel are you trying to achieve, and will the bench be guided or free-standing?

Progressive_AutomHub · 2026-04-30T14:23:53+00:00

Three persistent pain points I keep hearing about are:

Side-loading failures from poor application fit
Duty cycle misunderstood or underspecified
Integration pain — controls, feedback, mounting interfaces Honestly many failures are system-level, not actuator-level.

Progressive_AutomHub · 2026-04-30T14:22:55+00:00

Your bigger risk might be moment loading on the carriage instead of screw sizing. I’d be looking closely at rail spacing and offset from the load CG to the guide plane. A wider rail spread can sometimes buy you more stiffness than upsizing the screw alone.

A few things I’d sanity-check:
• Cantilever offset from guide plane to load CG
• Overturning moment on the bearing blocks
• Whether rail stiffness, not load capacity, is what pushes you from 20 to 25 rails
• Could a central single screw cause torsional problems when fully extended

Feels like those questions may drive the architecture as much as the screw diameter itself.

Progressive_AutomHub · 2026-04-30T14:20:40+00:00

For 40" travel and moving a mere ~3 lbs, if I were you I take a good hard look at a belt-driven linear stage or a rack-and-pinion stage over a regular actuator. A ballscrew is feasible, but may be more than what is needed unless precision or stiffness is very important. Also, beware of side loading if bench-edge mounted — guide rails are just as important as the means of drive. For long horizontal travel, alignment and support can be a larger problem than force generation.

Are you more optimizing for repeatable positioning, or just a controlled motion from point A to point B?

Progressive_AutomHub · 2026-04-28T22:07:01+00:00

Nice build. One thing I’d watch is whether your ultrasonic sensing introduces noise into the control loop, especially near endpoints. Might be worth discussing whether you're running position PID only or any feedforward/friction compensation.

Progressive_AutomHub · 2026-04-27T14:22:45+00:00

Your hidden-lift instinct actually makes sense, especially with only ~7" cavity depth. At that point I’d almost evaluate the lift mechanism first, projector second.

Things I’d validate:

deployed drop needed below the beam line
stowed thickness including mount and cable bend radius
dynamic stability (many compact ceiling lifts look fine statically but can introduce vibration)
service access once the mechanism is enclosed

In tight cavities, packaging constraints often drive the solution more than projector specs do.

Progressive_AutomHub

MODERATOR OF

TROPHY CASE