Loomio
Sun 26 Dec 2021 6:16PM

e-NABLE Configurator Software Proposal

AK Andrew Kaiser Public Seen by 66

e-NABLE Configurator Application Project Proposal

The Elevator Pitch

Currently, when a recipient needs a device, the 3D printable files for that device are scaled linearly by a single percentage figure. This means all geometries in the model are scaled by the same amount, including holes for fasteners, tolerances between moving parts, cable channels, etc. This linear scaling leads to devices which function and fit poorly for recipients who are not the same size as the target recipient for that device design.

Linear scaling is simple, but produces devices with poor fit and function for many recipients.

On the other hand, parametric scaling is a superior but more challenging way to scale models which allows for granular control, and can preserve key dimensions and geometries such as tolerances and holes for fasteners. A device which has been parametrically scaled will fit and function far better than linearly scaled devices, but creating parametrically scaled device designs is more difficult. Even after the device design has been created, the process of scaling a model parametrically is an involved and complicated problem, and requires the usage of computer aided drafting/design (CAD) software. Most makers don't have the necessary CAD software or skills to parametrically scale a device design.

Parametric scaling is powerful and versatile, but requires software and skills most makers don't have.

Linear vs Parametric Scaling

This proposal outlines a software system which will enable makers with minimal technical skills to go through a guided measurements-taking workflow to determine an appropriate device scale for a recipient, and then use those measurements to export 3D printable files for a customized, parametrically scaled device.

This system will make scaling devices parametrically as simple for users as linear scaling currently is.

Parametric scaling is something that must be prioritized and constantly considered when designing a device. Devices which are not created to scale parametrically typically need to be re-designed from the ground up to retroactively make them parametric, and this process is far more challenging than designing linearly scaled devices. While the catalog of e-NABLE devices currently includes only a few model with any parametric scaling capabilities, the community is currently hard at work creating the first fully parametric device design, and will need a tool to simplify the process of using that device design if its parametric design is to be fully taken advantage of.

Parametric devices are coming, and this system will make them immediately and easily accessible for all.

Description of Proposed Project

Currently, all e-NABLE devices are not parametric, meaning they must all be scaled linearly. While this
proposal does not include this work, the community is currently in the process of creating a new device design which will be fully parametric, and will serve as an example for others who wish to create parametric designs.

The most modern device designs that e-NABLE is working on are parametric, meaning they have sets of variables which can be used to scale the devices in a precise and controlled way. Scaling devices parametrically will allow us to keep key geometries like holes for fasteners and cables, as well as tolerances between moving parts at the appropriate size. Parametrically scaled devices are far superior to linearly scaled devices, however the process of parametrically scaling a model is labor-intensive and requires some special skills or training, as well as access to the appropriate computer aided drafting/design (CAD) software. Additionally, determining which values to input into a parametric design in order to get an appropriate scale often requires a deep understanding of the device design, as well as detailed and comprehensive measurements of the recipient. These two challenges present a large barrier to entry, and significantly decrease the value proposition of parametrically modeling new device designs.

Thankfully, there is a way to enable non-technical users to get parametrically scaled devices through the creation of a bespoke software system. Such a system would interface directly with CAD software in order to provide the parameters for a parametric part, and would then export a 3D printable file containing the scaled and configured part. While it was not initially clear that such a software system would be possible, a prototype which interfaces with Onshape (a free online cloud CAD suite) and with Fusion 360 (a powerful desktop CAD application which is used by many e-NABLE device designers) has been created and tested. This proves that the concept is indeed viable, and ameliorates the first major challenge of parametrically scaling devices, which is the need for the appropriate CAD software and the skill to use it.

The other remaining challenge, the difficulty of determining appropriate parameter values to correctly scale a device, is also something that can be solved with a custom software system. Users can be guided through a simple measurements-taking workflow specific to the class of device that the recipient requires (such as wrist-actuated, elbow-actuated, etc.), and those measurements can then be converted into the appropriate parameters to correctly scale the device. The specifics of how these parameter values will be derived will likely vary from device to device, and are not yet concrete, but the feasibility of this is clear. Through a process that will be determined via collaboration between the creators of the software system and designers of the devices, we will be able to compute the appropriate parameter values for an individual recipient, or directly pass measurements to the device design. This process of taking measurements which are non-specific to an individual device design will enable makers to create multiple different devices for a specific recipient without needing to redo the fitting process for each device. We are confident that we will be able to make the measurements-taking workflow simple and easy enough that anyone with a mobile device and some basic measuring tools (such as a ruler and tape measure) will be able to complete the measurements-taking workflow.

Once these two major challenges have been addressed, and e-NABLE has parametrically scalable devices in its catalog, we will be able to enable non-technical individuals to attain 3D printable files to create devices with a previously unattainable fit and function. The entire workflow, depending on the complexity of the measurements-taking workflow, could be expected to take as few as five minutes from opening the app to kicking off an export, the results of which would be delivered to the user by email.

Expected results/impact

Once this work is completed, e-NABLE will have a new platform to host its catalog of devices and will empower users to generate highly customized device models on demand. This will make the customization workflow which previously would have taken a large investment of time from some with powerful software and special skills into something that any member of the general public can complete in minutes.

Application Requirements

  • Users shall be able to add People (also known as recipients), and attach a picture to each Person
  • Users shall be able to add Measurements to a Person, both for left and right arms/hands
  • Users shall be able to add Measurements through an interactive workflow which contains images and descriptions of how to perform each step in the flow
  • Users shall be able to export a device from a list of devices that are applicable to any given Measurements
  • Users shall be able to use the application on both mobile and desktop devices, but the desktop application will simply be the mobile version in a container in the center of the window
  • Users shall be able to reuse People and Measurements added in previous sessions via caching all data on the user's device
  • Users shall receive their exported device models as an email attachment
  • Designers shall be able to provide device designs in the format of a list of Onshape parts or Fusion 360 parts to the developers, who can add them to the list of available devices
  • Designers shall be able to provide supplementary documentation and resources for each device, such as assembly/printing instructions in the form of a PDF

Estimate of work effort involved

Some work was already done on the prototype and the start of the MVP before any talk of a proposal, and so task-specific time tracking was not done. Time was tracked, but not for specific deliverables. Once talk of a proposal started, we started tracking hours more closely and counted them specifically on deliverables. The backend has thus-far only been counted as a single deliverable because only one developer has been assigned to it.

Prototypes are applications which are created to prove the viability of a concept and to determine any parts of a concept which are exceptionally hard or impossible to implement. Prototypes are generally constructed as quickly as possible, and so are not suitable to ever be deployed to production. A prototype of both the front and back ends were created to prove that this application was viable, and some core code from both was reused for the MVPs.

Front End (the web application users will interact with)

Work Already Done:

Web Application - Prototype: 20 hrs

Remaining Deliverables:

Add People - MVP: 25 hrs

Add Measurements to Person - MVP: 20 hrs

Create New Measurement Set - MVP: 30 hrs

Add Local Storage for People & Measurements - MVP: 20 hrs

Application Testing - MVP: 25 hrs

Total Remaining Time: 120 hrs

Back End (the server-side application exporting device models)

Work Already Done:

Exporter Service - Prototype: 40 hrs

Exporter Service - MVP: 15 hrs

Remaining Deliverables:

Modify Fusion360BomExporter to use a single product with a main component instead of using a list of products for each component: 10 hrs

Test above: 5 hrs

Implement extension to ExportPackagingService to allow for additional files to be included in output: 5 hrs

Test above: 2.5 hrs

Implement EmailExportDeliveryService for delivering results to the user as an email attachment: 10 hrs

Test above: 5 hrs

Upgrade Fusion 360 exporter add-in to export an occurrence instead of the root component, and to bundle dependencies inside the add-in for portability: 8 hrs

Test above: 1 hr

Modify BOM schema and Fusion360BomExporter to allow for exporting occurrences from multiple designs: 5 hrs

Test above: 2.5 hrs

Total Remaining Time: 54 hrs

Bugfixes

We estimate that 60 hours will be required to fix issues that are discovered once the system goes into production.

Deployment

We estimate that 20 hours of work will be required to deploy the backend to Azure and the front end to Vercel

Summary

Front End Already Done: 20 hrs

Front End Remaining: 120 hrs

Back End Already Done: 55 hrs

Back End Remaining: 54 hrs

Bugfixes: 60 hrs

Deployment: 20 hrs

Total Hours of Work: 329 hrs

Estimated Timeline for Completion

Timeline for Remaining Deliverables:

Backend Ready for Deployment: February 2022

Frontend Mockup Done: February 2022

Frontend Wireframe Done: April 2022

Frontend Ready for Deployment: June 2022

Target MVP Deployment Date: July 2022

Development Tools

Grafana Cloud

We will be able to remain on the free plan of GrafanaCloud for the foreseeable future.

Vercel

We will be able to remain on the hobby plan of Vercel for the foreseeable future.

MailSlurp

We will be able to use the free trial of MailSlurp for the foreseeable future.

Total Cost: None

Names of Individuals Responsible for Deliverables

Lukas Peterson will take the lead on front end deliverables, and Andrew Kaiser will take the lead on back end deliverables. Ultimately, both parties will be jointly responsible for all deliverables.

Amount of Funding Being Requested

Team's Hourly Rate: $75/hr

Team's Discount for e-NABLE: 50%

Team's Hourly Rate for e-NABLE: $32.50/hr

Total Number of Hours: 329 hrs

Total Cost of Development: $10692.50

Potential Future Work (Outside the Scope for This Proposal)

Currently... Eventually...

Technical Configuration of Generated Models

Currently, the system does not include support for configuring variables that do not pertain to a
Person's physiology. Eventually, the system could be augmented to add support for technical
configurations, such as allowing the user to specify the diameter or wire, the tolerance between
joints, the type of fasteners being used, etc.

Pocket Fit Preview

Currently, the process of virtually fitting devices includes a step where images of a Person's
limb are scaled and compared to a scaled model of the device they are receiving so thata maker can
ensure that they have selected a scale which will result in a pocket (the part of the device where
the user's limb goes) is appropriately sized. Eventually, this is workflow could be integrated
into this application, removing the need for CAD software to do virtual fittings. A user would be
able to attach pictures of a Person's limb along with a scale reference (like a ruler), and would
then be able to scale the picture of the Person's limb and an outline of the device pocket in
order to determine if the pocket will fit the Person. This would greatly reduce the need for test
prints to ensure a device will fit.

Adding a Database and Authentication

Currently, all data for the application is stored locally on a user's device. This approach
guarantees regulatory compliance (ex. HIPPA) and makes development far more simple. Eventually,
we want to allow a user to store their data in the cloud and attach their e-NABLE Hub
account to the application so that they can access their data on multiple devices, and so that
we can enable convenient sharing of a Person's measurements between e-NABLE memebers. For example,
once these features are added, a user would be able to log in and add a person on their mobile
device, then log in on a desktop computer to share the Person and their Measurements with another
individual, and then that individual could then access these data on another device. This would
enable a "pipelining" procedure for creating large numbers of devices efficiently for situations
like a refugee camp. It would also allow for a Person and/or their friends/family to complete the
entire measurement flow remotely, and then share those Measurements with a local e-NABLE chapter
who could then perform validation and manufacturing.

Part Polymorphism

Currently, a device must be modeled entirely in Onshape or entirely in Fusion 360. No device may
draw parts from both platforms. Eventually, this could be changed in the future to enable users
to build device designs out of whatever parts they desire. If open standards for the interfaces
between parts emerge, it would be possible to allow designers to rapidly create new devices by
mixing and matching parts from various devices to create a highly custom device with minimal
duplicated effort. This would also allow for the utilization of whichever CAD software is best
suited to modeling a specific part to be used. For example, if a specific part of a device needed
to be made in some specialty software like Blender, Rhino, or something similar, then they could
model that part with the most suitable tools without needing to remodel the entire device in that
software.

Additional Features - Years Out, Maybe Never

  • Different levels of measurement specificity
  • Photogrammetry/pointcloud data used to replace measurements workflow
  • Integration with commercial on-demand 3D printing services
  • Export configured slicer projects instead of STLs
  • Publicly uploaded devices
  • Expansion into other types of customized 3D printed assistive devices
JS

Jon Schull Mon 3 Jan 2022 2:05PM

Very nice proposal!

BR

Bob Rieger Fri 14 Jan 2022 1:16AM

Having printed, fabricated and donated some 41 devices, I believe this is a very important piece of work, and should be supported!