The per-axis command ramp the platform device applies below the navigation stack. More...

#include <armarx/navigation/simulation/TrajectoryFollowingSimulation.h>

Public Attributes
bool	directionPreserving {false}
	Ramp the two linear axes together instead of independently.

float	dt {0.001F}
	Control cycle of the RT loop [s]. `RTUnit` runs at 1 kHz and clamps dt to <= 2 ms.

bool	enabled {true}

float	maxAcceleration {250.F}

float	maxAngularAcceleration {0.4F}

float	maxAngularDeceleration {0.45F}

float	maxAngularVelocity {1.0F}

float	maxDeceleration {400.F}

float	maxVelocity {1500.F}

Detailed Description

The per-axis command ramp the platform device applies below the navigation stack.

Faithful model of LinearLimitedAccelerationController in devices/ethercat/platform/armar7_omni/joint_controller/Velocity.cpp, which rate-limits vx, vy and the platform yaw rate independently before the inverse kinematics.

This is the only acceleration limit in the real signal chain: the navigation stack does not bound the time derivative of the commanded twist (its alpha low-pass is configured to 0 on ARMAR-7), and the simulated platform device in RobotUnitSimulation does not either. Modelling it here is what lets the analysis answer whether the values in Armar7a/parts/Platform.xml actually keep the motors out of saturation.

Defaults mirror that file.

Definition at line 142 of file TrajectoryFollowingSimulation.h.

Member Data Documentation

◆ directionPreserving

bool directionPreserving {false}

Ramp the two linear axes together instead of independently.

Mirrors directionPreservingRamp in the platform's hardware config. Independent per-axis ramps let the commanded direction rotate whenever the two targets differ in magnitude; coupling them bounds |dv/dt| and keeps the direction. Default matches the device default so an unconfigured simulation reproduces the historical behaviour.

Definition at line 169 of file TrajectoryFollowingSimulation.h.