The final component in my design loop-closing exercise concerns the load lifting capacity of my desk. My previous torque and power analysis had suggested that I would be able to lift the desktop with 20 kg of live load placed on top, and be able to comfortably do so at a rate of 150 mm/min without running out of power (using a 12 V, 1 A wall wart). However, in my testing, I had found that I could only lift up to 12 kg of live load before stalling the motors. This stalling behavior persisted even when I reduced the speed and tried out a power supply capable of supplying up to 5 A at 12 V, suggesting that the system is torque-limited rather than current-limited.
Even though a desk that is capable of lifting 12 kg is perfectly usable, I sought to understand which part of my modelling went wrong so I can explain this discrepancy and learn from it for future designs. I am fairly certain I have the correct model form, so the error is likely to be in parameters that I have estimated. After reviewing my detailed engineering spreadsheet, I homed in on two high-uncertainty parameters that I thought could account for this discrepancy:
- Coefficient of friction between leadscrew and leadnut
- Coefficient of friction between teflon slider pads and interior surfaces of the boxway
These numbers were estimated from typical values from datasheets and other resources on the Internet, as I did not have time to carry out bench-level tests to accurately determine these coefficients. I am interested to determine how far off my initial estimates had to be in order to provide the observed performance.
I had recently learned to use the Solver tool in Microsoft Excel (in a Sloan class) to run quick optimization routines, and decided to put this newly acquired skill to use here. Adding on to my detailed engineering spreadsheet (download here), I ran three scenarios to determine the effect of estimation errors of each parameter on desk performance.
I duplicated the underlying model relating input parameters to the key output variable — total life load lifting capacity and placed them into new worksheets. For the single-parameter variation scenarios, I set the coefficient of interest (either leadnut or slider pads) as a variable and ran a non-linear optimization program to drive lifting capacity to the observed value (12 kg live load = 118 N, 45 N dead load, 162 N total). In these two scenarios, I held the other coefficient of friction constant. These scenarios are in the “ls-friction-sweep” and “slider-friction-sweep” sheets in the spreadsheet. My optimization models indicate that, all else being constant, the desk would perform as observed if:
- leadscrew coefficient of friction = 0.43 (initial estimate = 0.25); OR,
- slider pad coefficient of friction = 0.54 (initial estimate = 0.2).
Both of these values are rather high — much higher than I expect them to be and out of the typical ranges reported by most sources. This analysis suggests that it is unlikely that I was wrong on only one of these parameters — I would have to be too far off to produce observe results. It is more likely that I was wrong on both of the parameters, but to lesser degrees in each one.
“Minimum-deviation” parameter sweep
Operating under the assumption that I was “equally wrong” on each parameter (i.e., spreading my total error evenly across the two parameters), I ran a scenario to arrive at the observed lifting capacity while driving the sum of squared adjustments to the two parameters to a minimum. Under these constraints, I found that the following parameter values would produce observed performance:
- leadscrew coefficient of friction = 0.37 (initial estimate = 0.25); AND,
- slider pad coefficient of friction = 0.28 (initial estimate = 0.2)
These values are much more plausible. It is important to note that this analysis by no means produces the actual realized parameter values. It is just an indirect form of a sensitivity analysis to show whether it is reasonable for me to observe the lifting capacity I did despite being “in the ballpark” with my estimated parameters.
Conclusion and lessons learnt
I think the clear conclusion here is that I did not have a sufficiently large design factor of safety built into my system to accommodate the high uncertainty in input parameters. While working on a project for another course (analyzing how safety factors can be used to compensate for uncertainty in material properties), I came to realize the importance of matching the degree of conservatism to the level of a priori knowledge one has about the system. More uncertainty required more conservatism to give acceptable probabilities of success.
A second lesson I learned is that simple “sensitivity analyses” like these optimization routines, or even more elaborate ones that are easy to write in MATLAB or other similar environments, are useful tools to have early in the design process. This is a fitting final lesson for this project:
Deterministic design is great for getting into the ballpark of a feasible design, but incorporating simple statistical/probabilistic analyses locally at the early design stage helps you account for some of the uncertainty and can help you converge more rapidly.