The idea for this project came from a personal experience. After a hip injury limited my mother's mobility, I began thinking about whether a relatively simple wearable device could make everyday movement easier. That question led me to build a hip-assisting exoskeleton prototype using an Arduino, a geared DC motor, pressure sensing, and custom-fabricated metal components.

Starting with Simple Prototypes

I began by exploring how sensors could detect a person's movement and trigger mechanical assistance. My first experiment used a flex sensor, an Arduino, and a servo motor to support finger motion. Changes in the sensor's resistance were converted into motor commands, helping me understand the basic relationship between human movement and actuator response.

I then built an early leg-assistance prototype with VEX components. The motor could help lift my leg, but securing the mechanism with rubber bands was uncomfortable and unstable. That experience showed me that an exoskeleton must solve two problems at once: generating useful torque and transferring that torque comfortably to the body.

https://www.youtube.com/watch?v=gF1N3RdrTAs

Building the Hip-Assisting System

The redesigned prototype has three main parts: a waist-mounted belt, an adjustable leg strap, and an electronics module.

I designed the structural components for plasma cutting. The waist attachment connects to a weightlifting belt to provide a stable base, while the leg support uses Velcro straps and multiple mounting holes for adjustability. Folded metal sections reinforce the structure around the motor connection.

For actuation, I selected a 12 V, 12 RPM worm-gear DC motor rated at approximately 70 kgf·cm (about 7 N·m) of torque. A BTS7960 motor driver controls motor direction and speed, while an Arduino manages the sensor readings and control logic.

A thin-film pressure sensor mounted near the leg strap detects changes in applied pressure as the wearer moves. I used a logarithmic transformation and smoothing in the Arduino code to make the sensor signal more suitable for control. The goal is to detect movement intent and provide assistance at the appropriate time.

https://www.youtube.com/watch?v=oO3eecIydOg

What I Learned

This project was a proof of concept, not a clinically validated mobility aid. Although the motor's rated torque is roughly 7% of a 100 N·m reference hip torque, that comparison does not establish how much assistance a wearer actually receives. Similarly, preliminary estimates of reduced walking effort still need controlled testing.

The biggest lesson was that wearable robotics is as much about ergonomics, load paths, and reliable sensing as it is about programming. A working actuator is only one part of a useful exoskeleton.

My next steps would be to reduce structural weight, improve attachment comfort, explore EMG-based movement-intent sensing, and evaluate stronger motors and closed-loop control. Ultimately, I hope to develop a more practical and accessible system for people with limited lower-limb mobility.

Building a C# engineering tool to sweep joint angles, capture fingertip coordinates, and check mechanical interference.

Tech stack: C#, SolidWorks API, COM Interop, CAD automation

I worked on a SolidWorks add-in that automates the repetitive process of testing joint configurations in a mechanical assembly. The tool started from a joint-interference analysis workflow and evolved into a more flexible scanner for collecting fingertip-position data from robotic finger mechanisms. This tool ease the way of calculating inverse-kinematics, while still give an accurate solution.

The Engineering Problem

To model how a robotic finger moves, I needed to calculate the kinematics of the two-servo controlled finger. Since I does not have pure accurate data for the angles and dimensions, I build this plugin to both double-check my kinematics calculation and give an full, achievable angle/coordinate scan.

The goal was to automate that workflow while keeping interference analysis available when needed.

How the Add-In Works

The add-in uses the SolidWorks API from C# to work with two angular mates, labeled J1 and J2. I can specify angle ranges and scan both joints in combinations, or hold one joint fixed while varying the other. Configurable coarse, medium, and fine step sizes make it possible to start with a broad scan and then examine a smaller region more closely.

For each sampled configuration, the tool can record:

• Requested and actual joint angles

• Whether the requested position was reached

• The XYZ position of a selected scan point

• Interference information, when that option is enabled

These records help build an angle-to-position dataset that can support later fingertip modeling and gripper control.

Solving Assembly-Level Challenges

A surprisingly important problem was finding the correct mates. A joint may live inside a subassembly rather than the top-level assembly, and different subassemblies can contain mates with the same name.

To handle this, the add-in can recursively search loaded subassemblies for angular mates. It also supports Pick J1 mate and Pick J2 mate, allowing me to select the exact mates from the SolidWorks feature tree instead of relying only on names.

For coordinate collection, I can also select a specific scan point. When a mate is selected directly, the tool can read its angle value without requiring a separate reference-plane measurement for every test.

Making the Workflow More Efficient

Interference calculation is useful for clearance studies but is not always necessary when the objective is simply to sample coordinates. I added an option to disable interference checks during those scans, avoiding unnecessary calculations.

The delivered package includes a compiled add-in DLL, a COM type library, SolidWorks interoperability dependencies, a registration script, and the C# source code. That makes the tool easier to inspect, register, and continue improving.

What I Learned

This project showed me how to turn a CAD model into an engineering data source. Beyond writing code against an API, I had to think about assembly structure, mate selection, model state, repeatability, and the difference between requested and achieved geometry.

The add-in provides a foundation for generating kinematic datasets more systematically. Future work could focus on validating the exported coordinates against physical measurements and further streamlining data analysis.

Tech stack: C#, Windows Forms, C++, serial communication, robotic kinematics

During my summer 2026 internship, I worked on GripperControlApp, a Windows desktop application for operating and debugging a three-finger robotic gripper. The project brought together low-level servo commands, position models, and more intuitive controls for movements such as pinching, gripping, and twisting.

The main goal was to make the gripper easier to test than it would be through individual servo commands alone.

From Servo IDs to a Usable Interface

The gripper uses six servo channels. GripperControlApp provides a graphical interface where I can select a COM port, connect or disconnect the device, switch between left-hand and right-hand configurations, and adjust individual servos.

For engineering tests, the interface also shows estimated fingertip XYZ coordinates and raw servo-load values. The load readings are useful as diagnostic feedback, although they are not calibrated torque measurements.

The application also supports previewing finger angles and coordinates without connecting the physical gripper, which is helpful when checking mappings and control logic.

Translating Fingertip Motion into Commands

Directly changing a servo position does not tell me where the fingertip will go. To make the controls more meaningful, I worked with sampled motion data and coordinate models for the index finger, middle finger, and thumb.

These models support two useful operations: translating functional motions such as bend and swing into servo positions, and searching for a nearby reachable finger configuration from a requested XYZ target.

The thumb needed special attention. Its sampled bending range extended to 78°, so a curve-fitting approach was used to extrapolate the model toward 95°. This expands the modeled control range, but the extrapolated positions require physical validation.

Reusable Grasping Modes

Rather than repeatedly tuning each servo by hand, I added higher-level movement functions:

• Pinch: Coordinate the index finger and thumb around a specified fingertip separation.

• Grip: Generate a three-finger grasp using a cylindrical object diameter and an adjustable spread parameter.

• Twist: Combine index-finger lateral motion with thumb rotation to approximate a repeated twisting action while maintaining a pinch-distance constraint.

Twist is an approximate motion strategy, not a verified exact spiral trajectory. It is intended as a useful starting point for manipulation experiments.

Designing for Real Hardware

The software includes adjustable calibration offsets, servo-position limits, motion speeds, waiting behavior, serial timeouts, and left/right-hand mapping. The underlying C++ modules for finger modeling and movement logic were also retained for reuse and future integration.

The GUI includes optional entry points for vision-triggered grasping and hand-pose tracking. Those perception pipelines are a separate project; here, the focus was on creating a practical control and debugging layer between software and the actuators.

https://youtu.be/dFQ2OKNHxc8

Tech stack: Python, YOLOv8n, OpenCV, MediaPipe, JSON-based interprocess communication

During my summer 2026 engineering internship, I explored two ways of turning visual information into robotic gripper commands: detecting when a bottle is approaching a grasp position, and translating human hand motion into a three-finger robot's control parameters.

Both prototypes use Python for perception and exchange simple state files with a separate Windows gripper-control application. That kept the vision experiments modular while making integration possible.

Demo 1: Bottle Detection and a Grasp-Ready Signal

https://youtu.be/9NCkOY2QKWQ

The first pipeline processes an RTSP camera stream using OpenCV and a pretrained YOLOv8n object detector. It identifies bottles, draws bounding boxes, measures their apparent width, and displays a guidance arrow from the detected object toward a target point in the frame.

The camera configuration supports cropping a view from a combined stereo stream. In the archived setup, the program selected the top half of a top-bottom camera layout.

Instead of assuming that a 2D detection provides an exact distance, I used the bottle's changing bounding-box width as a simple approach indicator. The packaged logic computes width statistics every 0.5 seconds. After two sufficiently increasing measurement periods, a subsequent disappearance lasting more than 0.5 seconds produces the status:

Ready to Grab

That status is written to vision_status.txt, which the gripper application can read through its Vision Auto Grip function.

This is a rule-based prototype for recognizing an approach-and-disappearance sequence, not a calibrated depth-estimation or autonomous grasp-planning system.

Demo 2: Translating Human Hand Motion

https://youtu.be/VJNXMwqcy-Y

The second pipeline uses MediaPipe to track 21 hand landmarks from a computer webcam. Rather than treating hand tracking as a collection of discrete gestures only, it estimates continuous motion parameters: finger bending, finger spread, and thumb rotation.

Because the robotic gripper has only three fingers, the human-to-robot mapping is adapted:

• Human index finger → robot index finger

• Human little finger → robot middle finger

• Human thumb → robot thumb

The program converts landmark geometry into bend, swing, and rotation values and writes them to hand_state.json. The desktop controller reads these values in its Fast Tracking mode and translates them into servo targets.

Stabilizing the Control Signal

Camera landmarks fluctuate, and sending every small movement directly to motors can produce jerky behavior. To limit that effect, the controller uses several filtering and command constraints:

• A five-sample median filter and exponential moving average (EMA)

• A dead zone to ignore very small target changes

• A maximum servo-position step per update

• Thumb-angle restrictions and a reduced command speed

The packaged Fast Tracking settings use a 50 ms update interval (up to 20 Hz). These controls reduce command jitter but are not substitutes for a physical emergency stop or verified mechanical limits.

Integration and Next Steps

The overall pipelines are straightforward:

RTSP camera → YOLO bottle detection → vision_status.txt → Vision Auto Grip
Webcam → MediaPipe landmarks → hand_state.json → Fast Tracking

The file-based connection made it easy to develop perception and actuator control as separate programs. It also has limitations: hard-coded paths need adjustment on another computer, and a reader can occasionally encounter a state file while it is being updated.

The next steps would be to replace file polling with a more robust communication channel, validate the hand-to-gripper mapping on hardware, and evaluate the system under changing lighting, camera angles, and object motion.