Jump to content

SHIFT Learning by Design robotic ASL hands

From Appropedia
Placeholder image. Replace with a photo of your final project.
Replace with a photo of your final project.
Project data
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
OKH Manifest Download

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 what the image shows for readers who cannot see it.
Figure 1: Replace with a "before" or context image of the project site. Captions say what the reader is looking for, and the source if it is not your team.

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.

Table 1: Example criteria and constraints for purchasing a chocolate bar. Replace with your project's criteria.
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:

  1. 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.
  2. Summary (two to three sentences): what the source is and what it says. Write it in your own words.
  3. 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.

1
Figure 1. Labeled sketch of the Slant-Front Signer design, showing the angled control panel, OLED screen, LED indicators, power button, keyboard connection, and proposed charging connection.
Slant-Front Signer

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.

2
Figure 2. Labeled sketch of the Classic Sign Station design, showing the upright enclosure, front-mounted OLED screen, LED indicators, power button, keyboard and proposed charging connections, and optional silicone hand covering.
Classic Sign Station

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.

3
Figure 3. Labeled sketch of the Textured Teaching Console design, showing the textured plastic enclosure, beveled screen inset, OLED screen, LED indicator, front button, keyboard and proposed charging connections, and optional silicone hand covering.
Textured Teaching Console

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.

4
Figure 4. Labeled sketch of the Split-Panel Sign Showcase design, showing the display plaque, separate angled screen panel, red and green LED indicators, power button, USB-A keyboard connection, and proposed USB-C charging connection.
Split-Panel Sign Showcase

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.

Table 2: Decision matrix for the four base-layout alternatives. Scores are 0–10; weighted totals are the sum of weight × score.
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.

Figure # (replace with figure number): The final design with labeled parts.

= == 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.

1
What the reader should see.
Do this first

Longer description of the step, with measurements and tools.

2
What the reader should see.
Do this next

Longer description of the step.

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.

Table 3: Project 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
PrintGrand 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:

House wren in JBWR

One sentence describing the video

Keywords: birds
Date: 2020-07-05
Language: English (en)
License: CC BY 4.0
Annotations:
  • 0:10 Birdie coming in
  • 0:16 Birdie is watching you
  • 1:19 Imma head out
  • 1:30 Bye

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.

Introduce the team and semester, e.g., This project was completed in SEMESTER YEAR by Team TEAMNAME:

  1. ↑ Lastname, F. (2026). Interview by team name, Month Day, 2026, Arcata, CA.
  2. ↑ Organization name. (Year). "Page title." <https://example.org> (Month Day, 2026).
  3. ↑ Author, A. A., and Author, B. B. (2020). "Article title." Journal Name, 12(3), 45-67.
  4. ↑ Author, A. A. (2018). Book title, Publisher, City, State.
Page data
Part of Engr205 Introduction to Design
Authors Lonny Grafman, Gavin McDowell
License CC-BY-SA-4.0
Organizations Cal Poly Humboldt
Language English (en)
Related 0 subpages, 0 pages link here
Views 15 page views (analytics)
Created September 23, 2026 by Lonny Grafman
Last edit November 2, 2026 by 2607:FB92:580:FD9:C0DD:485A:DE39:51F7

}}

}}

}}

}}

Cookies help us deliver our services. By using our services, you agree to our use of cookies.