A fuzzy “Strength Index” adapts knee-exoskeleton torque in real time while the user stands up from a chair. In a five-person engineering study it cut measured muscle effort by 30% at slow speed, with smaller gains at faster speeds.

This is a research prototype from FUM CARE. I am first author of a preprint on SSRN, which has not been peer-reviewed. The study was an engineering evaluation and was not clinical.

My role

Project manager and first author, in a university research team

Device

FUM-NEXA: passive hip and actuated knee joint per leg

Task

Standing up from a 46 cm chair

Runtime

Raspberry Pi 4B, ROS2 (Python/C++), CAN motor control

Evaluation

5 healthy subjects × 3 speeds × 3 device conditions

The problem

Fixed torque profiles are simple to deploy, but they can’t tell a user who is moving faster than the reference from one who needs substantial help. A rehabilitation device also has to avoid the opposite failure: giving so much torque that the user stops contributing.

The project had to meet several constraints at once:

• estimate how much help is needed from signals available on the robot, without continuous EMG control;
• adapt torque during the movement as well as between sessions;
• run on a Raspberry Pi-class computer with a small sensor and actuator set;
• start assisting at the right moment, close to lifting off the chair;
• show that the device reduces effort after accounting for its own weight and inertia.

The last constraint turned out to matter most. Wearing the exoskeleton with the motors off increased measured muscle effort by about 40%, so the controller had to more than offset the device’s own burden before it could help.

My role

I was project manager and first author. It was a team project at FUM CARE, and I was not the sole designer, fabricator or experimenter.

I developed the control concept, meaning the Strength Index, the fuzzy rule base and the torque-scaling policy. I connected the controller to ROS2, the CAN sensors and actuators, real-time filtering and logging. I coordinated the control, mechanical, experimental and writing work needed to get from concept to a working prototype, and helped structure the three device conditions and three speeds used for validation. I also wrote the manuscript and prepared its figures.

Main design decisions

The controller estimates how much help the user needs from hip and knee velocity errors and torque feedback, without EMG. That estimate of the user’s capability is indirect, but it needs no extra sensors on the body.

It scales a reference torque using the index: assistive torque = desired torque × (1 − Strength Index). The movement target stays the same while the amount of help changes.

We chose a small rule base. Nine fuzzy rules run comfortably on a Raspberry Pi and are easy to inspect and tune, which suited a small team and limited compute better than a learned model.

Assistance starts at chair lift-off. The right torque at the wrong phase of the movement is still a bad experience, so we treated the trigger point as a requirement.

The evaluation included a motors-off condition, which separated the device’s burden from the controller’s benefit.

The four sit-to-stand phases, with the trigger point near chair lift-off.

Results

Average change in muscle effort (EMG IRMS) across the five subjects, relative to standing up without the exoskeleton. Positive values mean less effort.

Assistance reduced measured effort at all three speeds. The benefit was largest at slow speed, where help matters most for users who struggle to follow the reference, and it shrank at fast speed, so the controller was not equally effective everywhere. The device’s own burden was large enough that the results could only be interpreted against the motors-off condition.

The adaptive torque keeps the shape of the reference profile at a lower magnitude across the three speeds.

What I took into product work

A feature can make things worse before it helps, so I now try to measure the cost of adopting a product separately from the value of using it.

Timing belongs in the requirements. Correct output delivered at the wrong moment still fails the user.

Limited compute and sensing pushed this design toward a small controller that is easy to explain, and that worked in its favour.

Technical detail

CAN sensor data
  → filter joint velocity and torque
  → compute motion and torque errors
  → fuzzy Strength Index → scale desired torque
  → motor-driver PID → CAN → knee BLDC actuators
  → log sensor, motor and controller data

Publication

S. M. Sarfarazi, S. Farhadi, H. Sabzali, M. H. Gheshlaghi, I. Kardan and A. Akbarzadeh, “A Fuzzy Strength Index for Adaptive Assist-as-Needed Control of a Knee Exoskeleton Robot to Enhance Sit-to-Stand Transition,” SSRN preprint, posted March 2026. doi:10.2139/ssrn.6335794. The preprint has not been peer-reviewed. Code and video are not public.

What it does

It takes an instruction in plain language and uses the Gemini API to turn it into a sequence of ROS2 actions, which then run on a simulated robotic arm in Gazebo.

Status and limits

This is an early-stage experiment. It has no formal evaluation yet, and the code is not public. I’ll update this page with a repository, the supported task set and results when there is something worth measuring.

The same question drives ViGenX: how to let a language model plan while keeping execution verifiable.

Working on LLM-powered robotic task planning systems that translate natural-language commands into executable ROS2 action sequences for simulated manipulators. The goal: making robots that can take verbal instructions and turn them into safe, verifiable motion plans.

Learning

Exploring diffusion-based robot policies and vision-language-action (VLA) models — particularly how they can replace hand-coded task planners in unstructured environments. Also getting deeper into Isaac Sim for large-scale sim-to-real workflows.

Reading

• Probabilistic Robotics — Thrun, Burgard & Fox (finally finishing it)
• Recent papers from CoRL 2025 on world models for robot learning
• The Art of Doing Science and Engineering — Richard Hamming

Side Project

Building a small robotics simulation benchmark for evaluating LLM planners across a variety of household manipulation tasks — dishes, drawers, object sorting. Planning to release it as open source.

The topics I plan to write about include ROS2 software architecture, reinforcement learning for control, Isaac Gym and Gazebo simulation workflows, multimodal robot data pipelines, and the practical details of connecting LLMs and VLMs to robotic systems.

My goal is to keep the writing useful: implementation notes, design decisions, experiments, lessons from hardware integration, and research summaries that can help another engineer reproduce or improve the work.

• Added a new lifecycle node for state management.
• Logged delay spikes from the joint trajectory action.
• Verified collision boundaries in the simulator.