IEEE Robotics & Automation Magazine - September 2023 - 127

the combined cost of components in the ORH, along with the
time and effort required to manufacture and assemble parts,
reaches or even exceeds the cost of the commercially available
hardware alternative, users will be less likely to adopt the
ORH. Keeping the total price of off-the-shelf parts, calling for
simple fabrication processes, and requiring common materials
and tools for assembly can aid affordability of the ORH and
improve its ability to reach new users.
Once the hardware has been designed and documented,
developers face the challenge of selecting a dissemination
strategy and an appropriate license that will help them reach
as many potential users as possible. Even after users adopt the
hardware, developers need to continue engaging and nurturing
the community around the project. This might require them
to regularly communicate through forums, incorporate user
feedback, update files for compatibility, or prepare additional
documentation. For all the time and labor required, prospective
developers considering open sourcing their project may be
put off by the unclear opportunities to capture value for themselves
through the released hardware. There is not a straightforward
commercialization strategy for open source hardware,
which may be a significant challenge, especially for developers
with limited funding to continue R&D on their project. In
such cases, developers could choose to apply certain licenses
to capitalize on any commercial distribution of their hardware
in the future.
BEST PRACTICES FOR ORH
A successful ORH project maximally leverages developers'
efforts in preparing documentation, maintaining design simplicity
and budget, and publishing regular updates by extracting
all the benefits that come with open source technologies.
As such, the developer should try to
gain widespread adoption of his or her
project and sustain it over a long period
of time. OSHWA lays out steps developers
can take to persuade users to use
their open source project and help build
a community around it [17]. In this section,
we briefly outline some of these
best practices relevant to ORH that
developers could follow after they have
decided to open source their robot
hardware (see Figure 1). Later, in the
" Developing an ORH Project " section,
we further detail the pipeline of requisite
methods and considerations at these
different stages of developing an ORH
project from scratch, along with examples
from effective ORH projects.
■ The ORH development process begins
with the design of the hardware components.
As an open source hardware
project, the original and editable-
preferably, made with open source CAD
tools like FreeCAD or Onshape-
design files for the various custom components in the
assembly should be released for the user to reference and
fabricate the parts. This includes 3D CAD files and 2D
part files for planar parts, in various editable and interchange
formats like .step.
■ These design files should be prepared with ranges of
user expertise in mind, i.e., the design features should
be purposefully simple and consistent throughout the
parts. In addition to part files, supplementary files like
circuit diagrams and technical drawings may also be
useful for the user to replicate the components easily on
his or her end.
■ Off-the-shelf components should be utilized as much as
possible to relieve some of the manufacturing load of
replicating an ORH. If custom-fabricated parts are absolutely
required, then the design of these parts should
account for easy manufacturability at the user's end and
the variability in fabrication from different types of manufacturing
equipment.
■ Although the source part files are a crucial part of an ORH
project, they are not sufficient on their own to ensure the
hardware's reproducibility. Thorough documentation
describing the various manufacturing and assembly steps
needed to build the hardware makes open source projects
extremely lucrative. The bill of materials (BOM) and lists
with links to off-the-shelf parts are very useful for users to
acquire components.
■ Before prospective users commit to an ORH, they might
also want to know whether they have access to the
required equipment and whether they can use the fabrication
processes needed to replicate all the components of
the project. The documentation should list fabrication
* 3D/2D Part Files, in
Open Source CAD
When Possible
* Purposeful,
Design
Design
Consistent, Simple
Part Designs
* Easy to Manufacture
or Get Off the Shelf
* BOM, Processes,
Links to COTS Parts
Support
Document
Document
* Tools, Variations in
Fabrication
* Photos, Videos of
Steps and Parts
Disseminate
* Communicate,
User Feedback,
Revise Parts
mmunicate
er F
vise
k,
* Maintain Through
Tracked Updates
Disseminate
* Host on Repos,
Open-Source Hubs,
and Directories
* Indicate License
Applied to Files
* Contacts, User
Forum Space
FIGURE 1. The development process of an ORH with some best practices that developers
can follow to make their project as widely adopted and retained as possible. BOM: bill of
materials; COTS: commercial off the shelf.
SEPTEMBER 2023 IEEE ROBOTICS & AUTOMATION MAGAZINE
127
IEEE Robotics & Automation Magazine - September 2023

Table of Contents for the Digital Edition of IEEE Robotics & Automation Magazine - September 2023
