iFMH Robot actuator project


Getting Started with iFMH Robot Actuator Joint Modules: Simulation and Hardware Validation


Project Overview

This project is intended for engineers and robotics developers working with an iFMH rotary joint module—an integrated rotary actuator—and its simulation model for the first time. It provides joint module model files, simulation configurations, and a single-joint test example.

Using the iFMH55H100 as the reference model, this guide explains how to:

  • Prepare and connect a physical iFMH actuator.
  • Load the corresponding model in NVIDIA Isaac Sim 5.0.0.
  • Configure the single-joint simulation-to-hardware test example.
  • Send equivalent test commands to the simulated joint and hardware actuator.
  • Compare their motion responses and adjust relevant parameters.

The example provides an introductory workflow for validating a joint module model against hardware. It helps developers become familiar with the iFMH series and establishes a foundation for preliminary controller validation, robot system integration, and future multi-joint development.

This project performs joint-level simulation-to-hardware validation. It is not a complete Sim-to-Real deployment pipeline and does not validate full-robot dynamics or a full-robot controller.

About the iFMH Actuator Rotary Joint Module

The iFMH series is a family of highly integrated rotary joint modules, or integrated rotary actuators, for robotics. Depending on the model and configuration, a module may integrate a servo drive, a frameless torque motor, a motor-side absolute encoder, an output-side absolute encoder, a precision harmonic gearbox, and an optional brake.

These compact joint actuators can be used in robotic arms, humanoid robots, legged robots, and other robotic systems that require compact rotary actuation.

Before connecting the hardware, verify the complete model designation on the product label to confirm the applicable specifications and configuration.

Kinco iFMH Actuator Rotary Joint Module for robot

The model information is encoded in a QR code located on the joint housing near the wiring side. Scan the code to retrieve the joint module serial number and model designation.

Reference Models

ModelGear RatioRated TorquePeak TorqueRated SpeedMass
iFMH55H100-DCAB100:17.7 N·m35 N·m37 rpm445 g
iFMH60H100-DCAB100:127 N·m71 N·m35 rpm650 g
iFMH70H100-DCAB100:134 N·m95 N·m31 rpm815 g
iFMH80H101-DCAB101:151 N·m143 N·m35 rpm1,130 g

The reference configurations shown above have a rated voltage of 48 VDC, an input voltage range of 20–72 VDC, and 19-bit absolute encoder resolution. In this table, peak torque corresponds to the maximum instantaneous torque specified for the reference model. Use a DC power supply appropriate for the joint module and the planned test conditions.

Always base product selection, electrical connections, and hardware configuration on the product label and the selection guide and user manual for the complete model designation.

Project Files

The single-joint simulation-to-hardware comparison example is located in the sim2real_example directory. The main project structure is shown below:

project_root/├─ sim2real_example/│ ├─ sim2real_example.py│ ├─ joint_sim_config.py│ ├─ joint_hardware_driver.py│ ├─ libs/│ ├─ usd_assets/│ ├─ iFMH55H100_sim2real.csv│ └─ iFMH55H100_sim2real.png├─ urdf_assets/│ └─ iFMH series URDF robot description files└─ step_assets/ └─ iFMH series STEP CAD models

The CSV and PNG files shown above are example output filenames and may be generated after the test is run.

sim2real_example.py

This is the main test script. It loads the selected joint module model, initializes the simulation environment and hardware communication interface, sends equivalent test commands to the simulated joint and hardware actuator, records their responses, and generates result data and comparison plots.

Review the following variables before running the script:

MODEL_NAME = ...CONTROL_FREQUENCY = ...MIT_KP_Nm_rad = ...MIT_KD_Nm_rad_s = ...

For an initial test, retain the configuration supplied with the project unless the selected model or test conditions require a change. Adjust parameters only after considering the specific joint model, connected load, and observed response.

joint_sim_config.py

This file stores simulation parameter configurations for supported iFMH actuator models and applies relevant properties through UsdPhysics.DriveAPI and PhysX.

When changing the joint model, use the corresponding model file and configuration. Do not reuse all iFMH55H100 parameters for another model without verification.

joint_hardware_driver.py and libs

joint_hardware_driver.py provides the communication interface between the example program and the physical iFMH actuator. The libs directory contains libraries used for hardware control and communication.

Model Files

  • usd_assets: iFMH joint module simulation assets for Isaac Sim.
  • urdf_assets: URDF robot description files for defining links and joints and for model conversion workflows.
  • step_assets: STEP CAD models for mechanical design, assembly checks, mounting-interface verification, and interference checks.

URDF and STEP files do not directly replace a simulation model configured with joint, mass, inertia, collision, and drive properties.

Software and Hardware Requirements

Software

  • NVIDIA Isaac Sim 5.0.0.
  • A Python 3.11 environment.
  • The downloaded and extracted project files.

NVIDIA resources:

Hardware

  • A PC that meets the installation and runtime requirements for Isaac Sim 5.0.0.
  • An iFMH joint module that matches the selected test model.
  • A CAN FD interface or commissioning tool compatible with the joint module.
  • A DC power supply suitable for the joint module and test conditions.
  • A rigid test fixture for securing the joint module during motion testing.
  • An independent power-disconnect or emergency-stop provision appropriate for the test setup.

CPU, memory, GPU, VRAM, storage, and operating-system requirements may change between Isaac Sim releases. Before installation, run the Isaac Sim Compatibility Checker available from NVIDIA’s download page and refer to the official system requirements for version 5.0.0.

Step 1: Inspect the Physical Joint Module

After unpacking the module, check for shipping damage and verify that the model designation on the product label matches the ordered configuration. Before applying power, confirm the following:

  • The supply voltage matches the joint module specification.
  • The DC+ and DC- polarity is correct.
  • CAN_H and CAN_L are wired correctly.
  • The communication interface and driver are compatible.
  • No personnel, tools, or other obstructions are near the rotating output flange.

Do not apply a supply voltage that conflicts with the product label. Do not issue a motion command until communication is stable, no active faults are reported, and the joint module has been securely mounted for testing.

Step 2: Install and Validate Isaac Sim

  1. Open the official NVIDIA system requirements page and confirm that the PC meets the requirements for Isaac Sim 5.0.0.
  2. Download and run the Isaac Sim Compatibility Checker.
  3. After completing the compatibility check, download and install Isaac Sim 5.0.0.
  4. Confirm that the required Python 3.11 environment is available.
  5. Launch Isaac Sim and complete an initial startup and basic runtime check.

Isaac Sim supports multiple installation workflows, including workstation and Python environment installations. For a first run of this example, complete the official workstation installation and verify that Isaac Sim starts correctly before loading the project.

Step 3: Select the Joint Model

Locate the USD file in usd_assets that corresponds to the physical iFMH actuator, then set MODEL_NAME in sim2real_example.py.

When changing to the iFMH60H100, iFMH70H100, or iFMH80H101, also verify the following model-specific properties:

  • Mass, center of mass, and moment of inertia.
  • Gear ratio and axis of rotation.
  • Position, velocity, and torque limits.
  • Stiffness, damping, and actuator response.
  • External load and fixture inertia.

The model name, physical parameters, and control configuration must match the physical actuator and the test setup.

Step 4: Validate the Simulation First

Before commanding the physical actuator, verify that the simulation operates as expected:

  • Load the corresponding USD model.
  • Check the joint direction, joint zero position, range of motion, and units.
  • Confirm that the model has no unintended collisions or constraints.
  • Run the test over a small range of motion.
  • Verify that the simulated position and velocity responses are reasonable.

Step 5: Secure the Joint Module Before Motion Testing

The module does not need to be mounted for an unpowered inspection, model verification, or a communication check that does not enable the actuator or issue motion commands. Before enabling the actuator or sending any motion command, however, securely mount it to a rigid test fixture.

Securing the joint module helps prevent the housing from reacting to output torque, the output flange from rotating unexpectedly, and the cables from being pulled. It also improves the repeatability of simulation-to-hardware comparisons.

For the first test:

  • Keep the output unloaded or use a known low-inertia load.
  • Use a small range of motion and conservative initial parameters.
  • Set conservative velocity and torque limits.
  • Keep personnel clear of the rotating output.
  • Secure the power and communication cables.
  • Provide an independent power-disconnect or emergency-stop provision appropriate for the test setup.

Refer to the product selection guide and user manual for detailed mounting requirements. The mounting surface should be flat and clean.

A warped or deformed mounting surface, contamination, burrs, mounting-hole position errors, or abnormal loads may reduce performance, cause abnormal noise, or shorten service life. Do not strike the output side, and do not subject the rear connectors to impact or heavy loads.

Step 6: Connect the Hardware

Keep the power supply disconnected while completing the power and communication wiring. Provide adequate cable slack and strain relief. The user manual recommends a cable bend radius of at least six times the cable diameter.

If the selected model uses CAN FD:

  • Connect CAN_H and CAN_L as specified in the product user manual.
  • Configure the CAN bus termination resistors according to the connected devices and network topology.
  • Verify communication and feedback before enabling motion.

During operation, the joint module may return regenerative energy to the DC bus and raise the bus voltage. The module does not provide internal regenerative-energy dissipation. The power supply and DC bus design must therefore account for regenerative energy.

Step 7: Configure and Run the Example

After confirming that the simulation model, physical model, and hardware communication configuration match, review:

MODEL_NAMECONTROL_FREQUENCYMIT_KP_Nm_radMIT_KD_Nm_rad_s

Use the same test command, initial position, load condition, and recording duration in simulation and on hardware. For the first run, begin with lower controller gains, a small range of motion, and conservative velocity and torque limits.

When sim2real_example.py runs, the example sends equivalent commands to the simulated joint and hardware actuator and records their responses. During the test, continuously monitor the direction of motion, cables, temperature, DC bus voltage, communication status, and fault indications.

Stop the test immediately if you observe abnormal noise, oscillation, incorrect motion direction, loss of communication, overtemperature, or overvoltage.

Step 8: Review the Test Results

The example may generate:

iFMH55H100_sim2real.csviFMH55H100_sim2real.png

Use the CSV file for further data analysis and the PNG file for a quick visual comparison of the simulated and hardware response curves. Review the following characteristics:

  • Command-to-feedback latency.
  • Position tracking error.
  • Differences in velocity response.
  • Overshoot and settling time.
  • Oscillation and steady-state error.
  • Acceleration, deceleration, and direction-reversal behavior.

The simulated and physical responses do not need to match at every sample. Evaluate whether the model fidelity is sufficient for the intended engineering task, such as preliminary controller validation, motion planning, load evaluation, or system integration.

Adjusting Simulation and Control Parameters

If the simulated and physical responses differ significantly, review the following areas in order:

  1. Test conditions: Confirm that the command, initial position, load, mounting method, sample rate, and timestamps are consistent.
  2. Mechanical parameters: Check mass, center of mass, moment of inertia, gear ratio, axis of rotation, joint limits, and fixture inertia.
  3. Actuator and controller parameters: Check joint-drive stiffness and damping gains (Kp/Kd), velocity and torque limits, controller saturation, and feedback filtering.
  4. Transmission characteristics: Check static friction, Coulomb friction, viscous friction, torsional compliance, and backlash or lost motion.
  5. Communication and timing: Check command latency, feedback latency, communication jitter, control-cycle variation, and time synchronization.

Adjust one parameter category at a time. Preserve the initial configuration and the results from each test so that the source of any change can be identified.

This project does not automatically identify or calibrate these parameters.

Troubleshooting

SymptomItems to Check
Isaac Sim does not startPC system requirements, GPU driver, and Compatibility Checker results
USD model does not loadIsaac Sim version, model name, file path, and asset references
Simulated joint does not moveJoint axis, drive configuration, motion limits, and control target
No communication with the hardware actuatorPower, wiring, interface driver, CAN FD settings, bus termination, and joint ID
Hardware actuator oscillates after enableStop immediately; check direction, joint zero position, Kp/Kd, control-loop frequency, load, and fixture stiffness
Simulated response is significantly fasterCommunication latency, actuator response, friction, load inertia, and control cycle
Simulation and hardware curves do not alignTimestamps, sample rate, start time, and unit conversions

Next Steps

After completing the single-joint test, you can:

  • Import the corresponding URDF model into an Isaac Lab simulation workflow.
  • Use the STEP CAD model for mechanical assembly and clearance checks.
  • Integrate a validated USD simulation model and verified control configuration into a robotic arm, humanoid robot, legged robot, or another multi-joint project.

For a multi-joint system, document the model designation, joint ID, motion limits, and control configuration for every joint module. A successful single-joint test does not by itself validate full-robot dynamics or a full-robot controller.

Conclusion

This project provides a practical starting point for developers using an iFMH integrated rotary actuator and its simulation model for the first time. The workflow covers hardware inspection, Isaac Sim setup, model selection, simulation validation, hardware connection, and joint-level response comparison.

Matching the correct model and configuration, limiting the initial test range, securing the joint module, and tuning parameters incrementally can help developers evaluate the module more safely and efficiently while establishing a reliable foundation for subsequent robot system development.