This is the second post in a series of posts detailing the rationale for design choices in our motion capture glove. I will try and anticipate questions that informed users will ask. But this time, an informed user beat me to it. This post will discuss the digits specifically, but the mindset applies to all design choices made in the glove.

Brent and Josh and I have had innumerable hours of argument surrounding the choices that BUZZZZ's comment is touching. We may still offer the glove with various sensor configurations. I wrote the firmware in such a manner as to be able to cope with the absense (or loss/gain) of sensors in realtime. Feedback on the choices we made is invited.

Costs (an operating definition)

Unless specified like this...

co$ts

...the word cost might mean any of the following things...

  • Computational burden (Either CPU or Memory)
  • Bulk
  • Current consumption
  • Weight
  • Fragility
  • Foresight

This is not to say that co$t is a secondary concern. Indeed, it was an ever-present constraint while designing r1. But it is only one constraint among many.

Operating principles:
  • The best design choices are those that cost nothing but foresight. Mounting holes on the original RasPi fall into this category. They would have cost nothing but foresight.
  • Tool-use is a two-way affair. People use tools because they provide a means for their minds to leverage Nature in a manner that their bodies wouldn't otherwise allow. Tool-use extends minds that build better tools, that extend minds faster, that build better tools... This is how we get wheels, screwdrivers, airplanes, and warp drives.
  • (To be useful for more than its designer envisioned) is sufficient criteria for a "Good Tool". This allows the user of the tool to exceed the capabilities of even the designer of the tool. Knives, pencils, smartphones, and lasers are all Good Tools.
  • Planned obsolescence is an anti-value. I don't design for scrap heaps. It is neither sustainable nor cheap if your time-horizon doesn't happen to agree with that of someone else's business model.
Saving co$t, always has a cost (example: durability)
"Successful engineering is all about understanding how things break or fail."
                                                  ---Henry Petroski

Stuff breaks. For most people, the hands are the part of the body most-directly in contact with the environment, and the environment can be unkind. Damaged flesh heals. Damaged machines do not (yet). Until some genius builds a machine that heals itself, engineers need to balance repairability against durability, against all the costs and co$ts those things imply.

That our glove is designed to be repaired and extended adds about $29 to the BOM directly. The bulk of this co$t goes into interconnect and discrete components to account for the possibility that a digit might be damaged while operating. By paying the extra $29 for the glove, you can now replace the one thing that broke.

Making the USB connector ingress-resistant and the forward gasket such that you can splash water on it? That cost an extra $3.
...and so on...

So why so many sensors?

In the last post in this series, I only touched on this issue briefly, as the full-scope of the discussion would have been a digression. Here I will elaborate more completely.

Going forward, I will use the abbreviation IK for inverse kinematic model, and will sometimes use it to refer to what is really forward kinematics. Reason: both problems are present if we have to infer a joint that is not otherwise represented in the dataset, and the IK problem is much more challenging.

So the question is essentially: "Aren't 12 sensors enough to capture a good kinematic representation of a hand?".

Most probably, yes. Many companies have done so with good success. There are (broadly) these reasons we prefer 17, in descending order of proximity to the problem.

We've already paid 85% of the cost.

The following things add significantly to the cost of a digit (in ascending order):

  • silicone casting
  • 3 IMUs
  • labor required to assemble the digit,
  • flexible PCB and associated interconnect

If we cut a single IMU, the list order doesn't change, but "3" changes to "1". If we cut another IMU per-digit (7 total), we don't even cut the cost of the digit in half. In other words, more than half of a digit's cost (in terms of dollars) is incurred by supporting the first IMU. I see no reason to half-ass anything so core to save $30.

Better data.
"Engineering serendipity is this idea that we can help people come across
unexpected but helpful connections at a better than random rate. And in
some ways it's based on trying to reassess this notion of serendipitous
as lucky - to think of serendipitous as smart."
                                                    ---Ethan Zuckerman

But why stop there? What is special about 12 if you've already decided to devote the compute to running an IK model, cut it down to 7 senors and save $60. The same IK model that is usable with 12 sensors if probably serviceable with 7. So spend $5 on a bigger CPU (and $2 on a bigger battery [and $3 on a bigger regulator]) to run a more accurate kinematic model using only the distal phalanx positions. But software can only infer so much, and the more data you infer, the larger your error becomes (exponentially).

I chose to take on all that co$t anyway. The CPU is an STM32F746 ($20), and there is a CPLD intervening between it and the IMUs ($16 design choice). I spent an enormous amount of foresight to spec a CPLD image and (soft | hard)ware organization to allow for <2% CPU usage to read IMU data as fast as the sensors can return it. Essentially all of the CPU time is being reserved for use by firmware data processing, and I am
expecting that some genius reading this will make good use of it.

If this machine is designed to capture the nuances of a human hand, as swift and capable as it is, and the extra co$t means I don't nerf that genius' idea, I'm not willing to half-ass something so core to save $60.

Complicating an otherwise elegant computational pipeline, and a final admission
"Most computer technologists don't like to discuss it, but the importance of beauty is a consistent (if sometimes inconspicuous) thread in the software literature. Beauty is more important in computing than anywhere else in technology... Beauty is important in engineering terms because software is so complicated... Beauty is our most reliable guide to achieving software's ultimate goal: to break free of the computer, to break free conceptually. Software is stuff unlike any other... 

"Software's goal is to escape this gravity field, and every key step in software history has been a step away from the computer, toward forgetting about the machine and its physical structure and limitations -- forgetting that it can hold only so many bytes, that its memory is made of fixed size cells, that you refer to each cell by a numerical address. Software needn't accept those rules and limitations. 

"But as we throw off the limits, what guides us? How do we know where to head? Beauty is the best guide we have."

   ---David Gelernter, from "Machine Beauty: Elegance and the Heart of Computing", Discover 09/97

As the firmware roadmap reckons, we will have a data-stack 4-layers deep, depending on what data the user wants. See the prior post on design choices for clarification. I don't want to increase latency (a cost we haven't discussed yet) by adding I/FK models on top of an already high data processing demand. I don't want to spend months debugging a complex mathematical model for the sake of clawing back another significant figure.

To be brutally honest, I have no reason to believe that this glove will really be (as I intended) the last motion capture glove. Many very smart people have tried. Few engineers have the touch of madness required to march into this particular void with no clear market, a three-man team, no external funding, And then to open source it!?

But I didn't build the machine that I think will sell the most units, or the thing that is cheapest. I built the machine that I want to use and wear everyday. I built the best tool I could imagine.

And (especially) When I build things for pleasure (as I did this). I don't half-ass things for any cost.