[{"content":" I took an AI-assisted control-design platform from concept to an MVP. It has completed two proof-of-concept cycles and passed the company\u0026rsquo;s internal product-readiness gate.\nThe product has not launched commercially. A formal B2B product-market-fit programme comes next, so this page makes no claims about paying customers, revenue or product-market fit. The company is an early-stage agentic-AI startup, and its name, customers and internal targets are confidential.\nMy roleTechnical Product Manager (Mar 2026 to present). Before that, Robotics Software Engineer on the same product (Nov 2025 to Mar 2026). TeamSeven engineers and three stakeholders across AI, control engineering, software, product design and QA StageMVP, two POC cycles complete, readiness gate approved Ways of workingAgile/Scrum with Jira, Mizito, Notion and Google Workspace The kind of workflow the platform automates. This diagram is illustrative and does not show the product interface. The problem Designing a controller takes a chain of specialist steps. An engineer starts from a nonlinear model of the system, finds an operating point and linearizes it into a state-space model. Then they design and tune candidate controllers, run closed-loop simulations, and check stability and frequency response. Each step needs expertise and usually a different tool, and when a check fails, much of the chain has to be repeated.\nThe product\u0026rsquo;s bet is that AI agents can carry much of that chain, from a system description to a verified controller candidate.\nMy role I joined the engineering team in November 2025 and was promoted to Technical Product Manager in March 2026.\nAs an engineer, I built parts of the automated pipeline. That included an agent workflow that generates operating points, state-space models, controller candidates and closed-loop simulations from nonlinear system descriptions. I also worked on model parsing, signal interconnection, Jacobian linearization, and the stability and frequency-domain checks.\nAs product manager, I own the product definition and its delivery. I wrote the market requirements document, business plan and business model canvas. I also run discovery, write requirements and acceptance criteria, manage the backlog, coordinate the team, validate releases, and wrote the go-to-market strategy and plan.\nHaving built the pipeline myself made it much easier to write requirements the engineers could act on, and to judge whether a result was correct.\nDiscovery I ran market research, competitive analysis and more than 100 customer interviews. The interviews tested our assumptions about the problem and set our priorities. I turned the findings into product requirements and a prioritized roadmap.\nMain product decisions Scope the MVP around design, simulation and verification The first release put the capabilities an engineer needs to trust a result first: automated design, closed-loop simulation and verification. Verification was in the core product from the start.\nUse acceptance criteria as the shared definition of done Every capability had user stories and acceptance criteria written in control-engineering terms. Completed features were checked against them before release, so engineering, design and QA all worked to the same definition of \u0026ldquo;done\u0026rdquo;.\nValidate before selling After the MVP, the product went through two proof-of-concept cycles and then an internal readiness gate. Go-to-market execution starts only after that gate.\nKeep technical validation apart from market evidence Test users can show that the product works. Only companies can show that they need it. The go-to-market plan I wrote defines the company-level evidence the next phase has to collect, so proof-of-concept usage is not counted as traction.\nDelivery I ran delivery in Agile/Scrum and kept the backlog prioritized in Jira, with Mizito, Notion and Google Workspace alongside it. I coordinated seven engineers and three stakeholders across AI, control engineering, software, product design and QA, and validated each completed feature against its acceptance criteria before release.\nEvidence and results In the first proof of concept, 38 academic test users created 198 projects on the platform. The second proof of concept is complete, and the product-readiness gate was approved internally, which clears the product for the next phase.\nThis is technical product validation with test users. It does not show paid usage, a company pilot or product-market fit.\nWhat\u0026rsquo;s next I wrote the go-to-market strategy and plan for the next phase. It covers target accounts, qualification, a launch sequence with gates, and the company-level evidence needed to judge product-market fit. The plan names me as the owner of PMF and go-to-market operations. The formal three-month B2B programme is the next step, and I will add its results here once there are results to report.\nThe company name, customer names, pricing, roadmap details and any internal metrics beyond those above are confidential. The diagram is illustrative. I\u0026rsquo;m happy to discuss the work in more depth in an interview, within those limits.\n","permalink":"https://mahdisf.ir/projects/ai-control-design-platform/","summary":"Technical Product Manager at an agentic-AI startup (name withheld): MRD, 100+ customer interviews, requirements and backlog, a team of seven engineers, two proof-of-concept cycles, an approved readiness gate and the go-to-market plan.","title":"Taking an AI control-design platform from concept to a validated MVP"},{"content":" ViGenX turns a plain-language editing brief into a typed, validated workflow. A person can inspect and change that workflow, and nothing renders until they approve it.\nIt is my own open-source project. I built the initial MVP in 2025 and showed it at Diginext\u0026rsquo;s 10th Startup Camp. The current release is pre-1.0, suitable for development and testing, and has not yet been validated with external users.\nMy roleIndependent product and technical lead StagePre-1.0, locally run, Apache-2.0 Built withPython, Flask, React Flow, Whisper and FFmpeg, with optional Gemini, Groq or NVIDIA planning LinksRepository · Landing page The brief becomes a graph of registered blocks that can be edited before it runs. The problem Turning a long recording into short clips means repeating the same steps. You transcribe it, find the moments worth keeping, reframe for vertical video, add captions and music, and export. One-prompt generative tools promise to automate this, but they tend to return a finished render. You can\u0026rsquo;t see which decisions were made or change one step without starting again, and rerunning the same edit gives a different result.\nThat matters more when the footage carries obligations, such as licensed music, people\u0026rsquo;s faces or third-party clips, because an opaque result is hard to review. My working hypothesis was that creators would trust automation more if they could read and change the plan before it touched their footage.\nMy role ViGenX is my own project. I defined the product vision, requirements, MVP scope and roadmap, and I led the technical build. Diginext hosted the startup camp where I showed the first MVP. It was not my employer and does not own the project.\nWhat I know about users so far There has been no structured external user research yet. The problem definition comes from my earlier work producing and editing video content, and from building the first MVP.\nThat MVP shipped three fixed pipelines: general, speaker and gaming. The current version replaces them with composable blocks that a planner assembles for each brief, so a new kind of edit needs a new block instead of a new pipeline. The fixed pipelines stay available until the graph version reaches parity.\nMain product decisions The model plans and a person approves I considered letting a language model drive the edit end to end. That is the fastest route to a demo, but it is opaque and hard to repeat. Instead, the planner compiles a brief into a graph built only from registered blocks. It cannot invent block types, parameters, file paths, commands or upload targets, and it marks every workflow it generates as requiring approval. The cost is that the planner can only do what the block catalog supports, so new capabilities need engineering work.\nUsers edit the workflow directly The graph is serializable JSON. It opens in a visual editor and can be saved and rerun, so users spend their time reviewing, adjusting and reusing an edit instead of regenerating it from another prompt.\nPlanning works without an API key A deterministic local planner handles common requests such as clip count, duration, vertical format, captions, music and branding. Model-backed planning is optional. In Auto mode ViGenX falls back to the local planner when no key is set, and in AI mode it fails with an error if no provider is configured. The local planner understands a narrower range of briefs.\nEvery export carries rights information Each export writes a rights manifest and metadata. Publishing adapters act only on approved jobs and default to private visibility where the platform supports it. The documentation says plainly that automation does not establish fair use or ownership.\nWhat I left out ViGenX is not a hosted service, has no multi-user authentication (it binds to localhost) and is not meant to edit autonomously. Leaving these out kept the scope achievable for one person and kept the trust boundary simple.\nDelivery I built the initial MVP in 2025 in five-week Agile sprints. It was a Python and Flask pipeline that turned long-form video into short clips, with transcription, key-moment scoring and face blurring using Whisper, MediaPipe, YOLOv8 and Gemini. It also had live job monitoring, a review queue, and metadata and rights files.\nThe open-source version, public since June 2026, adds a React Flow editor with generated inspector controls, templates and undo/redo. It has a block catalog for editing, audio, branding, AI analysis and export, per-node progress, batch sources, publisher adapters that wait for approval, and an entry point for third-party blocks.\nEvidence and results What exists today:\na public, Apache-2.0 repository with continuous integration and unit, API, planner, concurrency and persistence tests; a working prompt-to-workflow path that runs without downloading models or setting an API key; the showing of the initial MVP at Diginext\u0026rsquo;s 10th Startup Camp. There is no external usage data, structured user feedback or measured time saving yet. The test suite does not prove render quality on arbitrary footage, and the documentation says so. I am not claiming adoption or product-market fit.\nWhat I learned, and what\u0026rsquo;s next Separating planning from execution is what makes this AI feature reviewable. I apply the same pattern to AI in engineering software, where a wrong action is expensive and users need to check what the system intends to do before it acts.\nWriting down the non-goals and the rights disclaimer early made later scope decisions faster.\nThe next validation step is to get the first external users to run ViGenX on footage they are allowed to edit and report exactly where it fails. On the engineering side, the open priorities are prompt-to-workflow evaluations with small licensed test videos, bounded render verification, node caching, and workflow diffs with dry-run cost estimates.\nArtifacts Source code and documentation Landing page Contribution guide ","permalink":"https://mahdisf.ir/projects/vigenx-agentic-video-editor/","summary":"An open-source AI video editor that turns a plain-language brief into a typed workflow graph you can edit, with human approval before anything renders. Pre-1.0.","title":"ViGenX: an AI video editor that shows its plan before it runs"},{"content":" A fuzzy \u0026ldquo;Strength Index\u0026rdquo; 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.\nThis 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.\nMy roleProject manager and first author, in a university research team DeviceFUM-NEXA: passive hip and actuated knee joint per leg TaskStanding up from a 46 cm chair RuntimeRaspberry Pi 4B, ROS2 (Python/C++), CAN motor control Evaluation5 healthy subjects × 3 speeds × 3 device conditions The problem Fixed torque profiles are simple to deploy, but they can\u0026rsquo;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.\nThe project had to meet several constraints at once:\nestimate 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\u0026rsquo;s own burden before it could help.\nMy 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.\nI 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.\nMain 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\u0026rsquo;s capability is indirect, but it needs no extra sensors on the body.\nIt 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.\nWe 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.\nAssistance 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.\nThe evaluation included a motors-off condition, which separated the device\u0026rsquo;s burden from the controller\u0026rsquo;s benefit.\nThe four sit-to-stand phases, with the trigger point near chair lift-off.\nResults Average change in muscle effort (EMG IRMS) across the five subjects, relative to standing up without the exoskeleton. Positive values mean less effort.\nCondition Speed Effort change Variability change Assistance on (50% setting) Slow 30.34% less 33.81% less Assistance on (50% setting) Normal 13.20% less 16.45% less Assistance on (50% setting) Fast 7.59% less 14.10% less Motors off Slow 41.21% more 30.09% more Motors off Normal 38.70% more 36.17% more Motors off Fast 40.87% more 42.53% more 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\u0026rsquo;s own burden was large enough that the results could only be interpreted against the motors-off condition.\nFive healthy subjects are not a clinical cohort. These results show engineering feasibility and say nothing yet about rehabilitation efficacy. The study did not report latency, confidence intervals, statistical significance, actuator safety margins or long-term reliability. The next step would need more and more varied participants, comfort and safety measures, and repeatability data.\nThe adaptive torque keeps the shape of the reference profile at a lower magnitude across the three speeds.\nWhat 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.\nTiming belongs in the requirements. Correct output delivered at the wrong moment still fails the user.\nLimited compute and sensing pushed this design toward a small controller that is easy to explain, and that worked in its favour.\nTechnical detail How the Strength Index works The controller represents the user\u0026rsquo;s instantaneous capability as a value between 0 and 1. It takes three inputs: knee angular-velocity error, hip angular-velocity error, and the difference between desired and delivered assistive torque. Each input maps to Negative, Zero or Positive fuzzy sets, and the output uses five bands. A nine-rule Mamdani system combines them, using the minimum for rule firing and centroid defuzzification.\nWhen the user keeps up with the reference, the index rises and assistance falls. When the user lags, or the robot isn\u0026rsquo;t delivering the expected torque, the index falls and assistance rises.\nThe desired hip and knee velocity profiles are sixth-degree polynomials fitted to 20 normal sit-to-stand motions from able-bodied data. A normalized knee torque-angle profile provides the full-assistance reference, which the index scales.\nRuntime architecture 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 The controller is written in Python, with C++ ROS2 nodes for CAN reading and motor commands (SocketCAN). Real-time second-order Butterworth filters, configured for a 400 Hz sampling assumption, use a 5 Hz cutoff for hip velocity and 10 Hz for knee velocity and torque feedback.\nExperimental protocol Five healthy subjects stood up from a 46 cm chair at three target speeds (slow 20°/s, normal 35°/s, fast 60°/s) under three conditions: no exoskeleton, exoskeleton with motors off, and exoskeleton with assistance at the 50% setting. EMG was recorded from the vastus lateralis, semimembranosus and hamstrings. The analysis used IRMS as a measure of overall muscle effort, signal standard deviation for variability, and percentage change from the no-exoskeleton baseline.\nHardware and software stack Two T-Motor BLDC knee actuators (rated up to 48 Nm) with magnetic joint encoders Raspberry Pi 4B running ROS2 Python, C++, NumPy, SciPy and scikit-fuzzy CAN bus for sensor acquisition and motor commands Fuzzy assistance controller on top, PID torque control on the motor driver Publication S. M. Sarfarazi, S. Farhadi, H. Sabzali, M. H. Gheshlaghi, I. Kardan and A. Akbarzadeh, \u0026ldquo;A Fuzzy Strength Index for Adaptive Assist-as-Needed Control of a Knee Exoskeleton Robot to Enhance Sit-to-Stand Transition,\u0026rdquo; SSRN preprint, posted March 2026. doi:10.2139/ssrn.6335794. The preprint has not been peer-reviewed. Code and video are not public.\n","permalink":"https://mahdisf.ir/projects/fuzzy-aan-knee-exoskeleton/","summary":"A fuzzy Strength Index adapts knee-exoskeleton torque during sit-to-stand in real time on a Raspberry Pi running ROS2. In a five-person engineering study, measured muscle effort fell by 30% at slow speed.","title":"Adaptive sit-to-stand assistance for the FUM-NEXA knee exoskeleton"},{"content":" 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.\nThis 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.\nRead the paper summary and original figures or download the complete conference manuscript (PDF).\nThe 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\u0026rsquo;t fall. Training one \u0026ldquo;monolithic\u0026rdquo; policy to do both mixes very different objectives, and it tends to generalize poorly to new layouts.\nThe 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\u0026rsquo;t ask for motion the locomotion policy can\u0026rsquo;t deliver.\nA low-level locomotion policy tracks the command in 3D. It uses 187 terrain height samples around the robot\u0026rsquo;s body and does no explicit footstep planning.\nBoth policies were trained and evaluated in GPU-parallel Isaac Gym simulation. In the reported setup, training took about five hours on a single GPU.\nMy 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.\nResults (simulation) Measure, from the paper\u0026rsquo;s simulation evaluation Result Overall navigation success 94.2% Success on unseen map layouts, without retraining 88.6% End-to-end success with combined obstacles and terrain 87.4% Collisions compared with the monolithic baseline 71.4% fewer These numbers come from simulation under the paper\u0026rsquo;s evaluation protocol, and none of them were measured on a physical robot.\nHow 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.\nThesis 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.\nCitation Y. Ayoubi Rad, S. M. Sarfarazi and M. Shahbazi, \u0026ldquo;Hierarchical Deep Reinforcement Learning for Quadruped Navigation over Complex Terrains,\u0026rdquo; 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.\n","permalink":"https://mahdisf.ir/projects/quadruped-navigation-hierarchical-rl/","summary":"Two reinforcement-learning policies, one for navigation and one for locomotion, joined by a bounded velocity command. Simulation research presented at ICRoM 2025; thesis in progress.","title":"Hierarchical reinforcement learning for quadruped navigation"},{"content":"In this machine-vision course project, I estimated where people and vehicles are in 3D, and how fast they\u0026rsquo;re moving, using only a phone camera without LiDAR or a stereo rig.\nWhat I built YOLO11n detects objects and ByteTrack keeps their identities across frames. The metric outdoor variant of Depth Anything V2 then turns each detection into a 3D position.\nA recursive Kalman filter tracks motion with a six-value state (position and velocity in x, y, z). It uses wall-clock time between frames, so velocity stays consistent when the frame rate varies, and it keeps predicting through missed detections.\nI calibrated the camera (a Samsung A34) with a checkerboard, and used a second phone\u0026rsquo;s IMU (a Samsung A54, via Phyphox) to sanity-check the estimated velocities.\nHow I chose the components I benchmarked the detectors myself on the target laptop (RTX 3060, 6 GB):\nDetector Measured speed YOLOv8n ≈ 16 FPS YOLO11n ≈ 20 FPS YOLO26n ≈ 23 FPS I picked YOLO11n. It wasn\u0026rsquo;t the fastest, but it gave the best balance of detection quality, installation reliability and speed. The depth model was the real bottleneck at about 0.22 s per frame (≈ 4.5 FPS).\nResults and limits The Kalman filter typically converged within three to five frames of a new detection. I tested qualitatively on crowded pavements, street traffic and mixed traffic.\nThe report states the main limitation. Without LiDAR or stereo ground truth, I could not measure end-to-end depth error, and metric scale needed manual calibration. The depth model\u0026rsquo;s published benchmark (0.454 m MAE on its own validation sets) does not measure this system.\n","permalink":"https://mahdisf.ir/projects/vision-3d-state-estimation/","summary":"Single-camera 3D multi-object tracking with YOLO11n, ByteTrack, Depth Anything V2 and a 6-state Kalman filter. Components benchmarked on a laptop GPU; no ground-truth depth, so no end-to-end accuracy claim.","title":"Camera-only 3D tracking and velocity estimation"},{"content":"This is a personal experiment in connecting a language model to a robot safely. The model proposes a plan, and ROS2 executes it on a simulated arm.\nWhat 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.\nStatus and limits This is an early-stage experiment. It has no formal evaluation yet, and the code is not public. I\u0026rsquo;ll update this page with a repository, the supported task set and results when there is something worth measuring.\nThe same question drives ViGenX: how to let a language model plan while keeping execution verifiable.\n","permalink":"https://mahdisf.ir/projects/llm-powered-robotic-task-planning/","summary":"Personal experiment: natural-language instructions become ROS2 actions for a simulated arm in Gazebo, using the Gemini API. Early stage.","title":"LLM-powered robotic task planning"},{"content":"A course project in which I owned the requirements and the end-to-end build of a small robot that follows a person indoors.\nWhat 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.\nThe 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.\nAn HC-SR04 ultrasonic sensor overrides the vision system. It stops or redirects the robot whenever an obstacle is closer than 1.5 m.\nDecisions 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\u0026rsquo;s electronics simple and cheap.\nLimits This was a course prototype. It was not evaluated with a formal protocol, and no code or video is public.\n","permalink":"https://mahdisf.ir/projects/human-follower-mobile-robot/","summary":"Course project: on-phone person tracking drives an Arduino-based four-wheeled robot, with an ultrasonic safety stop at 1.5 m.","title":"Human-following mobile robot"},{"content":"Our ICRoM 2025 paper separates a quadruped robot\u0026rsquo;s navigation and locomotion into two learned policies. A high-level policy decides how to move toward a goal around obstacles; a low-level policy turns its velocity commands into stable motion over uneven ground. This page brings together the paper\u0026rsquo;s abstract, original figures and reported simulation results.\nRead the full paper (PDF · 6 pages)\nAuthors: Yousef Ayoubi Rad, Seyyed Mahdi Sarfarazi and Mohammad Shahbazi.\nAffiliation: AI \u0026amp; Dynamic Systems Lab, School of Mechanical Engineering, Iran University of Science and Technology.\nConference: 13th RSI International Conference on Robotics and Mechatronics (ICRoM 2025), December 16–18, 2025, Tehran, Iran.\nThe 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.\nAbstract 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.\nWhy 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.\nThe proposed hierarchy connects the policies through a bounded body-frame velocity command. The navigation layer uses the robot\u0026rsquo;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.\nFigure 2 from the paper. The high-level path planner and low-level locomotion controller communicate through a compact velocity interface.\nSimulation 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.\nFigure 1 from the paper. The simulated terrain suite: A, sinusoidal waves; B, discrete obstacles; C, pyramid stairs.\nThe 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.\nFigure 3 from the paper. Terrain traversal: (a) ascending obstacles, (b) stairs, (c) descending obstacles and (d) sinusoidal waves. Green points show local terrain sampling.\nFrom 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.\nFigure 4 from the paper. (a) Input occupancy map; (b) circle-based obstacle representation and navigation path.\nFigure 5 from the paper. (a) Obstacle map and route; (b) intermediate robot position; (c) complete trajectory in the simulated environment.\nReported 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.\nMethod Navigation success Collisions per episode Path ratio Tracking error (m/s) Hierarchical framework 94.2% 0.08 1.083 0.042 Monolithic baseline 81.7% 0.28 1.194 0.061 Ablation: no hierarchy 83.5% 0.22 1.176 0.057 Ablation: no terrain sensing 91.8% 0.11 1.091 0.069 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%.\nScope 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.\nOnline 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.\nFor my contribution and the ongoing thesis work, see the related research case study.\nPaper and citation Download the complete conference manuscript (PDF).\nY. 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.\nAll five figures on this page were extracted from the supplied Word manuscript. The full PDF contains the equations, references and complete discussion.\n","permalink":"https://mahdisf.ir/posts/hierarchical-deep-reinforcement-learning-quadruped-navigation/","summary":"A two-policy framework for quadruped navigation over uneven terrain, evaluated in Isaac Gym. Read the research summary, explore the original figures and download the ICRoM 2025 paper.","title":"Hierarchical Deep Reinforcement Learning for Quadruped Navigation over Complex Terrains"},{"content":"Building 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.\nLearning 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.\nReading Probabilistic Robotics — Thrun, Burgard \u0026amp; 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.\n","permalink":"https://mahdisf.ir/logs/june-2026-update/","summary":"Working on LLM-powered task planning, exploring VLA models, and building a sim benchmark.","title":"June 2026 – LLM Planning \u0026 New Directions"},{"content":"This blog is a place for concise technical notes from my work in AI and robotics.\nThe 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.\nMy 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.\n","permalink":"https://mahdisf.ir/posts/starting-this-blog/","summary":"\u003cp\u003eThis blog is a place for concise technical notes from my work in AI and robotics.\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cp\u003eMy 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.\u003c/p\u003e","title":"Starting This Blog"},{"content":"Today I tested the ROS2 planning stack in Gazebo with a simulated manipulator. The robot completed the pick-and-place behavior, but the controller still needs a tighter feedback loop for fine-grained placement.\nAdded a new lifecycle node for state management. Logged delay spikes from the joint trajectory action. Verified collision boundaries in the simulator. ","permalink":"https://mahdisf.ir/logs/robotics-simulation-log/","summary":"A short log entry covering ROS2 simulation updates and system observations.","title":"ROS2 Simulation and System Log"},{"content":"I\u0026rsquo;m a technical product manager for AI and engineering software. I work out how engineers actually do their jobs and decide what an AI product should do for them. Then I help a cross-functional team build it and show that it works.\nI came to product management from engineering. For several years I built robotics and control systems: ROS2 software for rehabilitation exoskeletons, reinforcement-learning research for legged robots, and embedded controllers. On most of those projects I also ended up writing the requirements, coordinating the team and writing up the evidence. Since March 2026 that has been my full-time role.\nWhen the user is a control engineer, a roboticist or a developer, that background lets me follow their workflow, question an architecture and judge whether a result is real.\nI started in engineering: robotics software, real-time control and simulation, in university labs and on freelance projects. I moved into product through ViGenX, my own project, and was promoted to Technical Product Manager in March 2026. Now I work on AI products that make complex engineering workflows faster and easier to trust. Experience Technical Product Manager Agentic-AI startup (name withheld) · Mar 2026 to present\nI own product for an AI-assisted control-design platform. I took it from concept to an MVP that has completed two proof-of-concept cycles and passed the internal product-readiness gate. Case study\nWrote the market requirements document, business plan and business model canvas. Ran market research, competitive analysis and more than 100 customer interviews, and turned the findings into requirements and a prioritized roadmap. Translate control-engineering workflows into user stories, acceptance criteria and validation logic, and maintain and prioritize the backlog. Coordinate seven engineers and three stakeholders across AI, control engineering, software, product design and QA, and check completed features against their acceptance criteria before release. Wrote the go-to-market strategy and plan for the next phase, a formal B2B product-market-fit programme. The company name and customer details are confidential.\nRobotics Software Engineer Same startup · Nov 2025 to Mar 2026\nDesigned an agent workflow that generates operating points, state-space models, controller candidates and closed-loop simulations from nonlinear system descriptions. I also integrated linearization, stability and frequency-domain checks into an automated verification pipeline. Product and technical lead, ViGenX Independent open-source project · 2025 to present\nDefined and built an AI video editor that turns a plain-language brief into a workflow you can inspect and edit, and waits for human approval before rendering. Showed the initial MVP at Diginext\u0026rsquo;s 10th Startup Camp. The public repository has been open since June 2026 and is pre-1.0. Case study Researcher and robotics software engineer AI and Dynamic Systems Research Lab, Iran University of Science and Technology · Nov 2024 to present\nDefine requirements, evaluation criteria and success metrics for reinforcement-learning locomotion and risk-aware navigation experiments. Co-authored research on hierarchical reinforcement learning for quadruped navigation (ICRoM 2025). I designed the hierarchical architecture and implemented the reinforcement-learning path-planning component. Research summary Helped move a 5-DOF robotic arm from a proprietary tool to ROS2, RViz and MoveIt, with a hardware-in-the-loop bridge. Freelance robotics and control engineer Short client projects via Karlancer and Parscoders · 2024 to 2025\nDelivered control-system design, neural-network modelling and CAD assignments. Robotics engineer and research assistant FUM Center of Advanced Rehabilitation and Robotics Research (FUM CARE) · Feb 2022 to Aug 2024\nBuilt modular ROS2 software in C++ and Python for exoskeleton sensing, motor control, calibration and real-time assistive torque. Project manager and first author for the FUM-NEXA knee-exoskeleton controller. Case study Implemented real-time gait-phase detection for the FUM-HEXA hip exoskeleton. The project team received the Iraj Yazdanbakhsh First Prize. Digital marketing, before engineering Several companies · 2018 to 2022\nSEO, email and campaign roles, where I first learned about acquisition, funnels and user journeys. Publications Preprint, not peer-reviewed 2026\nA Fuzzy Strength Index for Adaptive Assist-as-Needed Control of a Knee Exoskeleton Robot to Enhance Sit-to-Stand Transition\nSSRN · First author\nDOI 10.2139/ssrn.6335794↗ Related case study Conference paper; public proceedings record pending 2025\nHierarchical Deep Reinforcement Learning for Quadruped Navigation over Complex Terrains\n13th RSI International Conference on Robotics and Mechatronics (ICRoM 2025) · Second author\nRead paper and download PDF Related case study Peer-reviewed conference paper 2022\nNeural Network Extraction of the Crutch–Leg Synergy to Estimate the Intended Motion for Paraplegic Users of Rehabilitation Exoskeletons\n10th RSI International Conference on Robotics and Mechatronics (ICRoM 2022), IEEE · Co-author\nIEEE Xplore↗ In progress\nRisk-aware path planning and control for a quadruped robot under interaction uncertainty\nIran University of Science and Technology · M.Sc. thesis\nEducation M.Sc. Mechatronics Engineering (in progress)\nIran University of Science and Technology · 2024 to present\nMy thesis, still in progress, covers risk-aware path planning and control for a quadruped robot under interaction uncertainty. Bronze Medal, 2025 Talent Development Award, Department of Mechanical Engineering.\nB.Sc. Mechanical Engineering\nFerdowsi University of Mashhad · 2018 to 2024\nMy final project was real-time fuzzy control of a knee exoskeleton. Best Technologist Student of 2023, Department of Mechanical Engineering.\nProduct management training\nDigital Product Management: Modern Fundamentals, University of Virginia (2026) · Diploma in Product Management, Alison (2024) · Foundations of Project Management, Google (2024)\nSkills Product: customer discovery, market and competitive research, MRD/PRD writing, roadmapping and prioritization, user stories and acceptance criteria, release validation, Agile/Scrum.\nAI: LLM and multi-agent systems, constrained planning, deep and distributional reinforcement learning, computer vision.\nRobotics and control: ROS2, Python, C++, Isaac Gym/Sim, Gazebo, MoveIt, MATLAB/Simulink, PID, fuzzy, sliding-mode and MPC/MPPI control, sim-to-real and hardware-in-the-loop.\nTools: Jira, Notion, Git, Docker, Linux.\nLanguages: Persian (native), English (professional).\nDownload CV (PDF, one page)\n","permalink":"https://mahdisf.ir/about/","summary":"\u003cp\u003eI\u0026rsquo;m a technical product manager for AI and engineering software. I work out how engineers actually do their jobs and decide what an AI product should do for them. Then I help a cross-functional team build it and show that it works.\u003c/p\u003e\n\u003cp\u003eI came to product management from engineering. For several years I built robotics and control systems: ROS2 software for rehabilitation exoskeletons, reinforcement-learning research for legged robots, and embedded controllers. On most of those projects I also ended up writing the requirements, coordinating the team and writing up the evidence. Since March 2026 that has been my full-time role.\u003c/p\u003e","title":"About"},{"content":"I work on technical product management for AI and engineering software, especially products for robotics, autonomous systems, control engineering and developer tools. If that\u0026rsquo;s what you\u0026rsquo;re building or hiring for, email is the fastest way to reach me.\nEmail Mahdi_Sarfarazi@outlook.com\nYou can also find me on LinkedIn and see my open-source work on GitHub.\nMy one-page CV is here: download the PDF.\n","permalink":"https://mahdisf.ir/contact/","summary":"\u003cp\u003eI work on technical product management for AI and engineering software, especially products for robotics, autonomous systems, control engineering and developer tools. If that\u0026rsquo;s what you\u0026rsquo;re building or hiring for, email is the fastest way to reach me.\u003c/p\u003e\n\u003cp class=\"contact-cta\"\u003e\u003ca class=\"btn btn-primary\" href=\"mailto:Mahdi_Sarfarazi@outlook.com\"\u003eEmail Mahdi_Sarfarazi@outlook.com\u003c/a\u003e\u003c/p\u003e\n\u003cp\u003eYou can also find me on \u003ca href=\"https://www.linkedin.com/in/sarfarazi\"\u003eLinkedIn\u003c/a\u003e and see my open-source work on \u003ca href=\"https://github.com/mahdisf\"\u003eGitHub\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eMy one-page CV is here: \u003ca href=\"/cv.pdf\"\u003edownload the PDF\u003c/a\u003e.\u003c/p\u003e","title":"Contact"},{"content":"Most of my time goes into my job. I\u0026rsquo;m Technical Product Manager at an agentic-AI startup (name withheld), working on an AI-assisted control-design platform. The MVP has passed its internal readiness gate, and the next phase is a formal B2B product-market-fit programme.\nI\u0026rsquo;m also finishing my M.Sc. in Mechatronics Engineering. My thesis is on risk-aware navigation for quadruped robots.\nAlongside work, I keep developing ViGenX, my open-source video editor. It plans each edit as a workflow you can check and change before anything renders.\n","permalink":"https://mahdisf.ir/now/","summary":"\u003cp\u003eMost of my time goes into my job. I\u0026rsquo;m Technical Product Manager at an agentic-AI startup (name withheld), working on an \u003ca href=\"/projects/ai-control-design-platform/\"\u003eAI-assisted control-design platform\u003c/a\u003e. The MVP has passed its internal readiness gate, and the next phase is a formal B2B product-market-fit programme.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;m also finishing my M.Sc. in Mechatronics Engineering. My thesis is on risk-aware navigation for quadruped robots.\u003c/p\u003e\n\u003cp\u003eAlongside work, I keep developing \u003ca href=\"/projects/vigenx-agentic-video-editor/\"\u003eViGenX\u003c/a\u003e, my open-source video editor. It plans each edit as a workflow you can check and change before anything renders.\u003c/p\u003e","title":"Now"}]