Keyboard Testing Robot - A Few Thoughts On Human Input Emulation

[Killvaughn]

Hello guys! 

Im new to the forum here so please don't roast me too hard!  

 

I really love the engineering efforts behind the keyboard robot topic and hoped to contribute from my Mech eng XP in designing automated equipment & test systems for OEM car makers. Keep in mind these are merely my observations and may make a few mistakes. (Im terrible at explaining this with text) Keyboards are a big deal on which I happily invest a lot of money personally, so I hope my notes below may be helpful - or not. 

 

From my perspective of the current system - Scenario 1

The current Z-Axis orientation of the robot cannot accurately emulate human inputs since force F is applied only in the Z-Axis only. While one may argue angular forces can be achieved by rotation about the wrist (Axis 6), servos used for this payload class cannot accelerate fast enough to emulate the speed of a key press. Even if one manages to accelerate to this speed, inertial forces of the robot arm will affect force measurements for key actuation. 

 

 

Actual emulation of finger inputs - Scenario 2

For scenario 2, we use an articulating end-effector attached to the robot system with a skin-like contact pad. The reasoning behind this because finger placement is rarely in the Z-Axis, and occurs with a arc-like motion. If you can imagine force acting in an angle would produce a reactionary forces in directions Rx & Ry. Rx will produce moment Mr which causes friction  force  inside the switch better emulating a human input. Furthermore, the X-Position on the keycap varies off center, and contributes to friction forces causing wear. 

 

Accurately emulating force R may require calibration of skin friction coefficient vs keycaps prior to tests, and so the end-effector will need a rubber pad on the end. It would be a good idea to use a standardised test jig with a fixed weight to measure this. The friction coefficient will also vary with perspiration and oils from Cheeto fingers. I can already imagine this will be an interesting challenge to model reliably on a scientific level... 

 

All of us know regular typing differs significantly compared to  pawning noobs on COD. For the difference in force profiles, velocity and acceleration would need to be obtained through measuring on/off times during regular/gaming use - but Im sure they have this covered already. 

 

While 3D laser scanning is robust for location, I would advise setting a hard  X|Y datum on the table to home the robot and act as a repeatable alignment tool for keyboard position. This will enabling faster setup times. I would also suggest bolting the keyboards down as well. Finally, This is probably covered already, but it may be a cool idea to calibrate pressing positions on keycaps using a UV heatmap.

 

 

In any case, Im open to what you guys think and if this makes sense? 

 

 

[LapsedMemory]

As far as what Linus has stated he's testing, he's attempting to validate the keyboard manufacturer's claims on key stroke length, activation position, etc.  He's not trying to recreate the actual feel of a keypress, this is just for comparison numbers between the different types.  If this is true, then their current test bench is perfectly fine.  Key manufacturers specs are for the vertical actuation, not a finger-type lever actuation.  There would be nothing to compare it to, data-wise.  

 

On the laser scanner any industrial scanner on the market should have the tools required to pick up the edges properly with even a rough orientation, and it should only take a few seconds at most to determine all the orientation datapoints.  As long as they have the tooling reference markers in the corners, and set their tools up properly to compensate, then they don't even have to be accurate with where the keyboard is bolted down.

 

Homing the robot to a datum is a separate action that must be done along with calibrating the camera field of view to the center point of the EOAT, which they have already done.  It has nothing to do with the keyboard location.  

 

In short, your solution may provide an interesting experiment, but I think it's outside of the scope of what they are trying to obtain at this time.

[Killvaughn]

23 minutes ago, LapsedMemory said:

As far as what Linus has stated he's testing, he's attempting to validate the keyboard manufacturer's claims on key stroke length, activation position, etc.  He's not trying to recreate the actual feel of a keypress, this is just for comparison numbers between the different types.  If this is true, then their current test bench is perfectly fine.  Key manufacturers specs are for the vertical actuation, not a finger-type lever actuation.  There would be nothing to compare it to, data-wise.  

 

On the laser scanner any industrial scanner on the market should have the tools required to pick up the edges properly with even a rough orientation, and it should only take a few seconds at most to determine all the orientation datapoints.  As long as they have the tooling reference markers in the corners, and set their tools up properly to compensate, then they don't even have to be accurate with where the keyboard is bolted down.

 

Homing the robot to a datum is a separate action that must be done along with calibrating the camera field of view to the center point of the EOAT, which they have already done.  It has nothing to do with the keyboard location.  

 

In short, your solution may provide an interesting experiment, but I think it's outside of the scope of what they are trying to obtain at this time.

Sure, of course I get the idea. I agree their setup is robust to achieve spec for spec comparisons, and I really respect the teams efforts since I have been through this integration hell on both system and hardware levels.

 

All Im saying is  that Linus very often likes to go next level to give us a real word outlook which is where I'm phoning from. I understand your point on the data, but from systems I've developed, Id say that datasets formulate themselves depending on the question your trying to answer, the key is standardisation - without this its challenging to develop any conclusion statistically. While its good to evaluate specs, its equally valuable to give manufacturers an idea on where to improve - take the PSU issues found by GN for example.

 

To me, simulating real world use cases would be to see things like,

Will a cherry switch last when subjected to eccentric presses - this is because we beat our keyboards to hell during gaming,

How does actuation speed scale with polling rates, and does this really matter? 

How does build quality affect performance and lifetime? etc etc....

 

 

 

[LapsedMemory]

5 minutes ago, Killvaughn said:

Sure, of course I get the idea. I agree their setup is robust to achieve spec for spec comparisons, and I really respect the teams efforts since I have been through this integration hell on both system and hardware levels.

 

All Im saying is  that Linus very often likes to go next level to give us a real word outlook which is where I'm phoning from. I understand your point on the data, but from systems I've developed, Id say that datasets formulate themselves depending on the question your trying to answer, the key is standardisation - without this its challenging to develop any conclusion statistically. While its good to evaluate specs, its equally valuable to give manufacturers an idea on where to improve - take the PSU issues found by GN for example.

 

To me, simulating real world use cases would be to see things like,

Will a cherry switch last when subjected to eccentric presses - this is because we beat our keyboards to hell during gaming,

How does actuation speed scale with polling rates, and does this really matter? 

How does build quality affect performance and lifetime? etc etc....

 

 

 

I'm guessing they aren't even going to attempt MTTF tests on these components, but I could be wrong. The MTTF of a Cherry MX red switch is somewhere in the 50million presses neighborhood.  If the robot can do 4 presses/second (extremely fast for a robot like the one they have), then it would take them roughly 144 days of non-stop button pushing to hit that target.  

 

They *could* setup a test to do this, but based on Linus' WAN show comments on the business case against content reviewing components further into their lifecycles, I'm guessing they are just going to focus on the immediately testable values, and let someone else do the long-term lifespan reviews.  

 

Actuation rates and polling rates are something they've stated they will be testing using signal analyzers and vision systems.