SHIFT Learning by Design robotic ASL hands

| Authors | Lonny Grafman Emilio Replace these |
|---|---|
| Location | Arcata, California, United States |
| Status | "In progress" is not in the list (Idea, Designed, Modelled, Prototyped, Verified, Deployed) of allowed values for the "Project status" property. In progress |
| Made | No |
| Replicated | No |
This paragraph appears in search results and previews for this page. In three to five sentences, summarize the whole project from background to result: what you designed, for whom, where and when, why it matters, and how it turned out. Write this last. It should make sense to someone who has never heard of your project, your client, or Humboldt County.
Background
[edit | edit source]
Describe the background of the project, covering who, what, when, why, and where: the client, the site, the course (Engr205 Introduction to Design at Cal Poly Humboldt), the semester, and your team. This page will be read by people around the world and in the future, so give enough context that a stranger understands it. Refer to your images in the text, e.g., Figure 1 shows the site before the project.
Images uploaded to Appropedia must be free to share and uniquely named. Start each file name with your project name, e.g., CCAT_compost_bin_background.jpg. Use File:Default.png as a placeholder until you have the real image. Give every image alt text (alt=) that describes it for readers using screen readers; the caption is what everyone reads, the alt text is what the image shows.
Problem statement
[edit | edit source]The objective of this project is to design, build, and test a... Write this so that a reader would know when the project is complete. You will refine this statement throughout the semester.
Problem analysis
[edit | edit source]This section defines what the ASL fingerspelling robotic hand must do and how design options will be judged. It lists the specifications and considerations for the hand and its quiz base, presents the weighted criteria and constraints in Table 1, and describes how the Cal Poly Humboldt ASL Club will use the finished unit.
Specifications
[edit | edit source]Specifications are what must exist and the conditions the design must meet. Introduce the list, e.g., the specifications for this project include:
- The hand must fingerspell words using the ASL alphabet.
- The device must accept typed input from the user.
- The device must fit on a small desk.
- The device must be usable by one person for self-guided learning.
- All electronics must be housed internally, with no exposed wires.
- The keyboard must be detachable.
- A screen must display the user's input, instructions, and results.
- Each finger must have two degrees of motion (curl and side-to-side spread).
Considerations
[edit | edit source]Considerations are what the design must keep in mind. Introduce the list, e.g., the considerations for this project include:
- Users will range from beginner to advanced ASL students, so the hand and on-screen instructions must work at different levels of fingerspelling ability.
- Materials should be lightweight so the device is easy to carry and puts less load on the servos.
- The device should be easy and intuitive to use, even for someone using it for the first time.
- The device should be easy to repair, since return elastics and tendons stretch and wear out over time and will need to be replaced.
Criteria and constraints
[edit | edit source]Criteria are the basis for judging solutions, and constraints are the limits each criterion must meet. Table 1 lists the criteria, constraints, and weights for this project. A weight of 10 marks the most important criteria. The weights reflect feedback from the ASL Club, which put readable handshapes and finger mobility first because the hand is only useful as a learning tool if members can recognize the letters it forms.
| Criterion | Constraint | Weight (0–10, 10 highest) |
|---|---|---|
| Finger Mobility | Has to clearly show all 26 letters | 10 |
| Usability | can be easily used by at least one person | 6 |
| Battery life | Greater than or equal to 3 hours battery life | 2 |
| Portability | Can be transported from classroom to library by one person | 7 |
| Speed | Can spell up to 5 letters per second | 5 |
Usage and production volume
[edit | edit source]The team will build one unit for the Cal Poly Humboldt ASL Club. Club members and other ASL learners will use it, one or more people at a time, to practice reading fingerspelling: the user(s) types or picks a word, watches the hand spell it, and checks their answer on the screen. The device will mostly be used during club meetings, study sessions, and events. Clear on-screen instructions should let a first-time user run it without help. The club should be able to use the hand for several academic years if worn elastics and tendons are replaced. Only one unit is planned, but the CAD files, code, and assembly instructions will be published on this page so other schools, clubs, or makers can build their own.
Literature review
[edit | edit source]This literature review is an annotated bibliography. Introduce it in one to two sentences that name the topics covered and why they matter for this project. Group entries under topic headings (Client first, then 4-12 topics relevant to your design, such as materials, similar projects, local climate, or user needs).
Minimum sources per team member: one peer-reviewed journal article, one book, and two credible web sources, plus the client sources your team needs. More credible sources are welcome.
Each entry has three parts:
- The citation in ASCE format. Either place it inside a named footnote, as in the examples below, so it appears under References and can be reused elsewhere on the page with
<ref name="Smith2020" />, or write it out in full at the start of the entry. Pick one approach and use it for the whole page. - Summary (two to three sentences): what the source is and what it says. Write it in your own words.
- Relevance (one to two sentences): how it informs this design, e.g., a criterion, a constraint, an alternative, or a decision.
Aim for 75-150 words per entry. No plagiarism: summarize, do not copy. Quote sparingly and always in quotation marks with a citation.
Client
[edit | edit source]Describe the client and what matters to them for this project. Sources here are often the client's website, documents, and interviews.
Client interview[1]
- Summary: Who you interviewed, their role, and the key points they shared.
- Relevance: Which criteria, constraints, or considerations came from this interview.
- Interview
Client website[2]
- Summary: ...
- Relevance: ...
- Web
First topic
[edit | edit source]Replace "First topic" with a descriptive heading. Open with one sentence that says why this topic matters to the project.
Short title of the source[3]
- Summary: ...
- Relevance: ...
- Peer-reviewed journal
Short title of the source[4]
- Summary: ...
- Relevance: ...
- Book
Second topic
[edit | edit source]You get the idea. Use as many topics as your project needs.
Key takeaways
[edit | edit source]In three to six bullets, synthesize what the literature means for your design. Cite the entries above, e.g., <ref name="Author2020" />.
- Takeaway that shaped a criterion or constraint.
- Takeaway that shaped an alternative or the final decision.
Alternative solutions
[edit | edit source]Introduce this section in one to two sentences specific to your project.
Alternatives
[edit | edit source]Describe four to eight alternatives, each under its own 'step template' as shown below and each with a catchy, descriptive name.

The Slant-Front Signer design places the robotic hand above a rectangular base with an angled front control panel. The surface labeled ANGLED FOR VIEWING positions the OLED screen and controls toward the user. The OLED screen provides a location to display the selected letter or operating status, connecting the keyboard input to the handshape demonstration.
The components labeled LED LIGHTS and POWER BUTTON provide visible operating feedback and a dedicated power control. The USB FOR KEYBOARD connection provides an input point for selecting letters, while the USB-C FOR CHARGING connection identifies the proposed charging interface. Grouping these features on the front of the enclosure keeps the display, controls, and connections together for club demonstrations.
This alternative emphasizes screen visibility, accessible controls, and a compact tabletop arrangement. The panel angle and hand height remain features to evaluate during prototyping.

The Classic Sign Station design mounts the robotic hand above a box-shaped enclosure with an upright front panel. The OLED SCREEN sits on the front face, with the LED indicators above it and the POWER BUTTON and connection ports near the lower edge. This arrangement separates visual feedback from the lower controls and presents the main features in a straightforward layout.
The SILICONE label identifies an optional white or translucent covering for the hand. This feature explores a more finished appearance, while its effect on finger movement and handshape visibility remains a testing consideration. The LEFT OR RIGHT HAND label identifies handedness as a design choice rather than an automatic switching feature.
The USB FOR KEYBOARD and USB-C FOR CHARGING labels identify the proposed input and charging connections. This alternative emphasizes a simple enclosure and a centralized display for educational demonstrations.

The Textured Teaching Console design combines an angled display panel with a textured enclosure. The TEXTURED PLASTIC (WHOLE BOX) label identifies the proposed exterior finish, while the BEVEL INSET FOR SCREEN label identifies the recessed border surrounding the OLED SCREEN. These features distinguish the display area from the enclosure and create a consistent visual appearance.
The LED provides a location for operating-status feedback, and the front-mounted BUTTON provides a dedicated user control whose function remains to be defined. The USB FOR KEYBOARD and USB-C FOR CHARGING connections sit along the lower front edge, keeping the proposed input and charging interfaces accessible.
The SILICONE and LEFT OR RIGHT HAND labels identify optional hand-covering and handedness choices. This alternative emphasizes visual presentation and a clearly defined screen area. The enclosure texture and optional covering remain subject to fabrication and hand-motion testing.

The Split-Panel Sign Showcase design divides the front of the base into a dedicated control area and a separate angled screen area. The DISPLAY PLAQUE sits on the upper-left surface and provides space for the project name or brief operating instructions. The SCREEN occupies the angled panel on the right, separating the selected-letter display from the identification plaque and power controls.
The LEDS RED/GREEN and POWER BUTTON labels identify the status indicators and power control on the left front panel. The USB-A FOR KEYBOARD and USB-C FOR CHARGING labels identify the keyboard and proposed charging connections below the screen.
This arrangement supports educational presentation by giving project identification, operating feedback, and user input distinct locations. Compared with the simpler box-shaped alternatives, the divided enclosure introduces additional panel geometry to account for during fabrication.
Continue this for the four to eight alternatives you have.
Decision
[edit | edit source]Introduce this section in one to two sentences specific to your project.
Criteria definitions
[edit | edit source]Each criterion from Table 1 is defined below as it is used to judge the alternatives. These definitions describe what is being measured, not the limits each criterion must meet; the limits are the constraints listed in Table 1.
- Finger Mobility
- The degree to which the base layout leaves the hand's motion unobstructed so it can clearly form all 26 ASL letters.
- Usability
- How easily one person can operate the quiz alone, including reading the screen and the hand at the same time and reaching the keyboard and controls.
- Battery life
- How well the layout supports running the device for the intended session length, considering space for a power source and whether the layout assumes battery operation.
- Portability
- How conveniently one person can carry the finished device between locations such as a classroom and the library, considering size, weight, and handholds.
- Speed
- How well the layout supports fingerspelling at a useful pace without adding mechanical friction or delays to the hand's motion.
We used a Delphi decision matrix to choose between the four base-layout alternatives. Each team member independently scored every alternative from 0 to 10 against every criterion in Table 1, using the definitions above. We then met as a team, compared our scores, discussed the criteria where we differed by three or more points, and explained our reasoning before settling on the consensus scores shown in Table 2. Because all four alternatives share the same hand, servos, and control code, we scored only what each layout itself changes; screen placement, simultaneous hand-and-screen visibility, enclosure size, controls, and appearance; and kept scores equal wherever a layout does not change the outcome. Table 2 summarizes the decision matrix.
| Criterion | Weight | Slant-Front Signer | Classic Sign Station | Textured Teaching Console | Split-Panel Sign Showcase |
|---|---|---|---|---|---|
| Finger mobility | 10 | 9 | 9 | 9 | 9 |
| Usability | 6 | 8 | 8 | 8 | 8 |
| Battery life | 2 | 8 | 8 | 8 | 8 |
| Portability | 7 | 8 | 8 | 8 | 7 |
| Speed | 5 | 9 | 9 | 9 | 9 |
| Weighted total | 30 | 255 | 255 | 255 | 248 |
= == Final decision ===
We selected the Slant-Front Signer as our final design. As shown in Table 2, it earned 255 out of 300 possible points, tying the Classic Sign Station and Textured Teaching Console for first place and exceeding the Split-Panel Sign Showcase’s 248 points. It scored 9/10 for finger mobility and speed and 8/10 for usability, battery life, and portability. Because the matrix produced a three-way tie, we chose the Slant-Front Signer based on our preference for its angled front panel, which positions the screen and controls toward the user for independent ASL practice.
Show your most impactful prototypes from earliest to final. Include at least one prototype for function (does it work? e.g., testing a mechanism, material, or dimension) and at least one prototype for desire (will people want to use it? e.g., a mockup shown to the client or users for feedback). Each caption should say what the prototype is, whether it tested function or desire, and what you learned from it. Early sketches, failed attempts, and photos of materials and hands at work all help tell the story.
= = Final design ==
Describe the final design, starting with the big picture and then going into detail. Use labeled images and refer to them in the text. This is usually a big section.

= == Construction ===
Give a complete description of how the final design is built, with lots of images, so someone else could replicate it. Use one {{Step}} per step. This is much easier to write as descriptive (what you did) instead of prescriptive (what another person should do), but you can take either approach.
Timeline
[edit | edit source]The timeline below shows the major milestones for designing, building, and delivering the ASL fingerspelling robotic hand, with the physical hand planned to be mechanically complete by October 30 (Week 10). Tasks were scheduled around weekly Tuesday client check-ins and Friday group build sessions, and this table will be updated at the end of the semester to show the actual timeline.
| Date | Description | Status |
|---|---|---|
| September 20, 2026 | Background and problem statement posted | Complete |
| September 27, 2026 | Literature review posted | Complete |
| October 2, 2026 | Robot Nano Hand parts ordered | Complete |
| October 4, 2026 | Problem analysis, timeline, and ethics posted | Complete |
| October 9, 2026 | Parts received; ASL club observation and interview completed | Not started |
| October 13, 2026 | Final word list and letter priorities confirmed with client | Not started |
| October 16, 2026 | Print settings optimized and first prototype (V1) hand printed | Not started |
| October 23, 2026 | First prototype assembled with tendons and servos | Not started |
| October 27, 2026 | Client review of first prototype handshapes | Not started |
| October 30, 2026 | Hand, base, and electronics integrated; physical hand mechanically complete | Not started |
| November 3, 2026 | Client walkthrough and ASL student testing of the fingerspelling quiz | Not started |
| November 13, 2026 | A–Z letter calibration and reliability testing completed | Not started |
| November 17, 2026 | Project more than 90% complete; code finalized and posted to GitHub | Not started |
| November 22, 2026 | Appropedia page draft and presentation slides completed | Not started |
| December 1, 2026 | Final presentation | Not started |
| December 6, 2026 | Final design report, digital deliverables, and video submitted | Not started |
| December 8, 2026 | Robotic hand handed off to the ASL club with care guide | Not started |
| December 17, 2026 | Final pitch in the Great Hall | Not started |
Costs
[edit | edit source]The costs of the ASL robotic hand include the team’s design time, the materials and components needed for construction, and future operation and maintenance expenses. These categories distinguish the effort required to develop the design from the expenses of building and maintaining it.
Design cost
[edit | edit source]Show the total human hours your team spent outside of class, grouped into categories (e.g., research, brainstorming, prototyping, construction, documentation). Three teammates working for one hour is three human hours.
Implementation cost
[edit | edit source]The current implementation cost of the ASL robotic hand is $267.43, based on the purchased components listed in the bill of materials below. These amounts represent actual purchase costs rather than proposed estimates. The purchases include stainless steel dowel pins, servo motors, elastic bands, an LCD touchscreen, a USB-to-TTL adapter, a servo driver, and an ESP32 microcontroller.image.jpg
No donated materials have been used in the project. Any reused materials will be identified separately in the bill of materials, along with any cost to the team. The current total includes only the purchases recorded so far; additional materials and expenses will be added as they are confirmed. The budget will be updated at the end of the semester to reflect the final construction cost.
The cost of replicating the hand may differ from the team’s expenditures because purchased quantities may include spare components, and future builders may pay different prices for materials.
| Item | Amount | Cost per unit | Total |
|---|---|---|---|
| 18-8 Stainless Steel Dowel Pin 2 mm Diameter, 10 mm Long Part number 91585A221 — Purchased | 100 | USD 0.17 | USD 17.00 |
| 18-8 Stainless Steel Dowel Pin 2 mm Diameter, 16 mm Long Part number 91585A231 — Purchased | 50 | USD 0.26 | USD 13.00 |
| 18-8 Stainless Steel Dowel Pin 2 mm Diameter, 18 mm Long Part number 91585A233 — Purchased | 50 | USD 0.22 | USD 11.00 |
| 18-8 Stainless Steel Dowel Pin 2 mm Diameter, 20 mm Long Part number 91585A240 — Purchased | 50 | USD 0.23 | USD 11.50 |
| 18-8 Stainless Steel Dowel Pin 2 mm Diameter, 24 mm Long Part number 91585A261 — Purchased | 50 | USD 0.29 | USD 14.50 |
| SCS0009 Servos — Purchased | 10 | USD 9.50 | USD 95.00 |
| 15mm Elastic Bands — Purchased | 150 | USD 0.05 | USD 7.50 |
| LCD touch screen — Purchased | 1 | USD 29.00 | USD 29.00 |
| USB to TTL adapter — Purchased | 1 | USD 19.44 | USD 19.44 |
| Servo Driver Motor — Purchased | 1 | USD 26.00 | USD 26.00 |
| ESP32 — Purchased | 1 | USD 23.49 | USD 23.49 |
| Grand total | USD 267.43EUR 229.99 <br />GBP 195.22 <br />CAD 331.61 <br />MXN 5,575.92 <br />INR 20,017.14 <br /> | ||
Maintenance cost
[edit | edit source]Introduce the ongoing costs in time and money, usually per year.
{ | class = "wikitable sortable" | + Table 4: Yearly maintenance cost. ! Task ! Frequency ! Time per year (hours) ! Cost per year (USD) | - | Example task | Monthly | 2 | 0.00 | - ! Total ! ! 2 ! 0.00 | } = = Operation ==
Introduce how to use the design, then give step-by-step instructions with labeled images. Use {{Step}} if the process has more than a few steps. A short video is a great addition:
Maintenance
[edit | edit source]Introduce this maintenance section. Answer these questions:
- Are there any needed actions for maintenance?
- How often?
- Who should perform maintenance?
Maintenance schedule
[edit | edit source]This is when to maintain what. Please keep the format the same as it can be used to auto-populate maintenance tables.
- Daily
- A daily task
- A daily task
- Weekly
- a weekly task
- a weekly task
- Monthly
- a monthly task
- a monthly task
- Yearly
- a yearly task
- a yearly task
- Every __ years
- task
- task
Maintenance instructions
[edit | edit source]Give step-by-step maintenance instructions, using {{Step}} if helpful.
Conclusion
[edit | edit source]Testing results
[edit | edit source]Describe how you tested the final design and what the results were. Compare the results to your criteria, e.g., in a table like Table 5.
{ | class = "wikitable sortable" | + Table 5: Final design performance against criteria. ! Criterion ! Constraint ! Result ! Met? | - | Cost | Less than or equal to $3 per ounce | $2.50 per ounce | Yes | } = == Discussion ===
Discuss what the testing results mean.
Lessons learned
[edit | edit source]Discuss what your team learned and what you would do differently next time.
Next steps
[edit | edit source]Discuss next steps for the project as it goes on into the future.
Troubleshooting
[edit | edit source]Cover basic operating problems only. For complex issues, the suggestion might be to contact ________.
{ | class = "wikitable" ! Problem ! Suggestion | - | Example issue | Example solution or suggestion | - | Does not turn on | Make sure it is plugged in. | - | Another issue | Etc. | } = = Inspirational Video ==
Include an inspirational video for sharing.
Team
[edit | edit source]Introduce the team and semester, e.g., This project was completed in SEMESTER YEAR by Team TEAMNAME:
- Lonny Grafman
- Emilio Velis
- One bullet for each team member, in the format
[[User:Username|Full Name]]. = = References ==
- ↑ Lastname, F. (2026). Interview by team name, Month Day, 2026, Arcata, CA.
- ↑ Organization name. (Year). "Page title." <https://example.org> (Month Day, 2026).
- ↑ Author, A. A., and Author, B. B. (2020). "Article title." Journal Name, 12(3), 45-67.
- ↑ Author, A. A. (2018). Book title, Publisher, City, State.
| Authors | Lonny Grafman, Gavin McDowell |
|---|---|
| License | CC-BY-SA-4.0 |
| Organizations | Cal Poly Humboldt |
| Cite as | Lonny Grafman, Gavin McDowell (2026). "SHIFT Learning by Design robotic ASL hands". Appropedia. Retrieved November 5, 2026. |
}}
}}
}}
}}