Core project 02 · EtherCAT torque control

55 kg quadruped

I worked on the software and control path from a PPO locomotion policy to 12 EtherCAT drives in CiA-402 Profile Torque mode, with joint-level recordings used to investigate deployment mismatch.

Real-robot walking video.
  • Period
    September 2025-June 2026
  • Platform
    55 kg · 12 actuators
  • Policy
    45-D observation → 12-D action · implemented at 50 Hz
  • Evidence
    Retained walking, PACE data collection, and joint tracking records

Control architecture

Policy, PD, fieldbus, and robot form one feedback loop.

The learned policy supplies joint targets; lower layers recompute torque from current feedback and refresh the EtherCAT PDO path at a faster rate.

Quadruped PPO and EtherCAT control architecture A 45-dimensional observation enters a PPO policy, producing joint targets. A one kilohertz PD controller sends torque targets through a two kilohertz SOEM EtherCAT master to 12 CiA-402 torque drives and the quadruped. Joint feedback returns to the PD and observation path. Dashed annotations show possible mismatch and timing effects. Command and torque path policy targets are held while PD and fieldbus loops continue at their own rates Feedback path joint state, IMU information, and timing are not assumed to be perfectly synchronous 45-D observation ω, gravity, command q, dq, last action PPO / ONNX policy 45 → 12 action implemented at 50 Hz Joint targets 12 × [kp, qd, kd, dqd, τff] PD control τ = kp(qd-q)+kd(dqd-dq) 1 kHz recompute · ZOH SOEM / EtherCAT PDO exchange + state management 2 kHz · 500 μs 12 CiA-402 drives 12 targets torque PDO Quadruped + sensors encoder q, dq, torque, IMU physical feedback Observation update coordinate mapping + scaling policy input at next step q, dq for PD joint + IMU feedback Possible timing effects observation/action delay jitter · missed updates Possible plant mismatch actuator delay · static friction model mismatch
Source-supported path: 45-D observation → PPO policy → joint targets → 1 kHz PD → 2 kHz SOEM/EtherCAT → 12 Profile-Torque drives → robot. Dashed labels denote likely sources of deployment mismatch, not separately measured contributions.

My Role

Deployment software, real-time control integration, and mismatch diagnosis.

  • Policy pathONNX runner, 45-D observation construction, action mapping, and state-machine integration.
  • Low-level pathJoint target handoff, 1 kHz PD computation, SOEM EtherCAT exchange, and CiA-402 drive-state handling.
  • DiagnosisDesired-versus-measured joint recording, model/interface checks, and iteration around delay, friction, and actuation behavior.

The archived project contains several model/configuration versions. This page shows the hardware path and records, not an unverified aggregate performance metric.

Diagnostic loop

Joint traces turned an ambiguous behavior into a tractable signal path.

I used desired and measured joint motion to inspect tracking shape, offsets, and axis-specific behavior before revising model/interface assumptions and returning to hardware tests.

01

Observe

PACE-based collection retained commanded and measured joint trajectories instead of relying only on body-level behavior.

02

Localize

Checks covered coordinate mappings, default pose and action scale, static friction, actuator response, and PD behavior.

03

Iterate

Model/interface changes and dynamics compensation were assessed through the same measured control path.

Hardware record

Platform, test setup, and joint tracking.

The images show the physical platform and bench context. The curve is a retained command-versus-measurement diagnostic, not a summarized tracking score.

Desired and measured front-left quadruped joint tracking curves
Desired versus measured joints. Retained PACE chirp visualization for the front-left leg.
55 kg quadruped standing in a laboratory
55 kg quadruped. Hardware platform used for the EtherCAT deployment work.
Quadruped in a laboratory data collection setup
PACE data collection. Hardware setup associated with joint-level diagnosis.
Quadruped model in Isaac Sim
Simulation model. Isaac Sim environment used during the deployment workflow.
PACE data collection. Representative video associated with joint-level diagnosis.

What I learned

Sim2Real is a systems diagnosis problem.

This work strengthened my interest in controllers that can distinguish model, actuation, sensing, and timing effects rather than absorb all of them as a single unexplained deployment error.