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.

Separating where to go from how to walk let a simulated quadruped reach 94.2% navigation success, including 88.6% on map layouts it had never seen.

This is simulation research, presented as a conference paper at ICRoM 2025. A public proceedings record is not available yet. My M.Sc. thesis extends this work and is still in progress, and this page reports no hardware results.

Read the paper summary and original figures or download the complete conference manuscript (PDF).

The problem

A legged robot crossing cluttered, uneven ground has two jobs at once: choose a route around obstacles, and place its feet so it doesn’t fall. Training one “monolithic” policy to do both mixes very different objectives, and it tends to generalize poorly to new layouts.

The approach

A high-level navigation policy works on a 2D map and goal, and outputs a body-frame velocity command. That command is bounded, so the navigation policy can’t ask for motion the locomotion policy can’t deliver.

A low-level locomotion policy tracks the command in 3D. It uses 187 terrain height samples around the robot’s body and does no explicit footstep planning.

Both policies were trained and evaluated in GPU-parallel Isaac Gym simulation. In the reported setup, training took about five hours on a single GPU.

My role

I was second author on a three-person paper. I designed the hierarchical structure and implemented the reinforcement-learning path-planning component. In the lab, I also define requirements, evaluation criteria and success metrics for this line of experiments.

Results (simulation)

These numbers come from simulation under the paper’s evaluation protocol, and none of them were measured on a physical robot.

How this carries over to product work

Deciding what the upper layer may request, and what the lower layer guarantees, turned one hard problem into two testable ones, and each layer could be evaluated against its own success criteria. I use the same approach when I scope product features and split work between teams.

Thesis work, in progress

The thesis extends the architecture toward risk-aware navigation. It combines global graph search (Dijkstra) with sampling-based local planning (MPPI) and a distributional reinforcement-learning controller for locomotion. Results will be published once the thesis is complete.

Citation

Y. Ayoubi Rad, S. M. Sarfarazi and M. Shahbazi, “Hierarchical Deep Reinforcement Learning for Quadruped Navigation over Complex Terrains,” 13th RSI International Conference on Robotics and Mechatronics (ICRoM 2025), Tehran, December 2025. Author-hosted conference manuscript (PDF). A proceedings link will be added when the public record is available.

What I built

A Python (Kivy/Buildozer) Android app runs a TensorFlow Lite MobileNet v1 model on the phone to detect and select the person to follow, at roughly 60 frames per second.

The phone sends forward, backward, left, right and stop commands over USB serial to an Arduino Uno, which drives four DC motors through an L298N driver.

An HC-SR04 ultrasonic sensor overrides the vision system. It stops or redirects the robot whenever an obstacle is closer than 1.5 m.

Decisions worth noting

I compared a Raspberry Pi with a smartphone as the compute platform, and SAMURAI, YOLOv8 and MobileNet as detectors, choosing on inference efficiency. Running vision on the phone kept the robot’s electronics simple and cheap.

Limits

This was a course prototype. It was not evaluated with a formal protocol, and no code or video is public.

Read the full paper (PDF · 6 pages)

Authors: Yousef Ayoubi Rad, Seyyed Mahdi Sarfarazi and Mohammad Shahbazi.
Affiliation: AI & Dynamic Systems Lab, School of Mechanical Engineering, Iran University of Science and Technology.
Conference: 13th RSI International Conference on Robotics and Mechatronics (ICRoM 2025), December 16–18, 2025, Tehran, Iran.

The downloadable PDF is the conference manuscript supplied by the authors. All results below were obtained in simulation. This page does not report deployment on a physical robot.

Abstract

Quadruped robots are promising for tasks like disaster response and exploration, navigating cluttered spaces while maintaining stability over uneven terrains such as stairs, slopes, and obstacles. This paper presents a hierarchical deep reinforcement learning (HRL) framework that decouples high-level navigation from low-level locomotion via a compact velocity-command interface u = (vₓ, vᵧ, ωz). The high-level policy generates smooth body-frame velocity commands for goal-directed movement in 2D maps, while the low-level policy executes these commands using joint targets with PD control, enhanced by proprioceptive feedback and local terrain sampling. This modular approach mitigates reward conflicts, boosts training efficiency, and enables independent layer optimization in Isaac Gym. Evaluations on maze-like maps and varied terrains show reliable goal reaching, stable tracking, and improved robustness over monolithic baselines. The results underscore how hierarchical decomposition enhances generalization and stability, offering a promising path for intelligent quadruped mobility in real-world applications.

Why separate navigation from locomotion?

Choosing a route and keeping a legged robot balanced involve different observations, actions and time scales. Training a single policy to solve both can introduce competing rewards and make it harder to reuse a locomotion controller on a new map.

The proposed hierarchy connects the policies through a bounded body-frame velocity command. The navigation layer uses the robot’s pose, relative goal and obstacle information. The locomotion layer uses body and joint measurements together with a fixed pattern of 187 local terrain-height samples. Joint targets are tracked by a PD controller. Command saturation and smoothing keep the interface within the motion limits used in the simulation.

Simulation and terrain awareness

Experiments use Isaac Gym with a Legged-Gym-style task wrapper. The terrain suite includes stairs, ramps, discrete obstacles and sinusoidal surfaces. Navigation is trained in a 10 × 10 m workspace with procedurally generated obstacles; larger maps are normalized to the training domain.

The high-level planner is trained with Proximal Policy Optimization (PPO), using an MLP with two 256-neuron hidden layers. Training proceeds in stages: first train locomotion on procedural terrains, then hold that policy fixed while training navigation. The paper reports about five hours of combined training on an NVIDIA RTX 3080 Ti, with roughly 12,000 parallel simulation environments.

From a map to a velocity command

Input occupancy maps are converted into obstacle features for the navigation policy. The planner uses goal and obstacle information to produce commands, while the locomotion policy handles contact and balance in the physics simulation.

Reported results

The following values reproduce Table I of the paper. Navigation success, collision rate, path ratio and linear velocity-tracking error are distinct measures; navigation success alone does not describe end-to-end performance on uneven terrain.

The paper also reports 88.6% navigation success on unseen map layouts, without retraining, and 87.4% end-to-end success when obstacles and terrain variations are combined. Compared with the monolithic baseline, collisions per episode fall from 0.28 to 0.08, a 71.4% reduction. Removing terrain sensing raises the reported fall rate from 1.4% to 7.3%.

Scope and limitations

Evaluation uses simulation, static obstacles and nominal sensing. The local height representation does not provide semantic understanding or long-range terrain topology. Tight bends and small-platform sequences can slow progress, and freezing locomotion during navigation training limits how the two layers adapt together.

Online mapping, dynamic obstacles, selective co-training and hardware validation remain directions for further work. The reported simulation results are not evidence of real-world reliability.

For my contribution and the ongoing thesis work, see the related research case study.

Paper and citation

Download the complete conference manuscript (PDF).

Y. Ayoubi Rad, S. M. Sarfarazi and M. Shahbazi, “Hierarchical Deep Reinforcement Learning for Quadruped Navigation over Complex Terrains,” 13th RSI International Conference on Robotics and Mechatronics (ICRoM 2025), Tehran, Iran, December 16–18, 2025.

All five figures on this page were extracted from the supplied Word manuscript. The full PDF contains the equations, references and complete discussion.

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.