You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit d1187df
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: README.md
+35-11Lines changed: 35 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -81,14 +81,38 @@ Adding a command (overview):
81
81
-*If necessary* Add client method to `async_client.py` and `sync_client.py`.
82
82
83
83
## Control rate and performance
84
-
- Default control loop: `PAROL6_CONTROL_RATE_HZ=250` (chosen for consistent cross-platform behavior)
85
-
- Higher control rates require stronger hardware and generally produce smoother motion, but there are diminishing returns—the motion will not become infinitely smooth just by increasing the rate
86
-
- If the controller is falling behind you will see warnings like:
87
84
88
-
`Control loop avg period degraded by +XX% (avg=Ys target=Zs); latest overrun=Ws`
85
+
The default control loop rate is **100 Hz** (`PAROL6_CONTROL_RATE_HZ=100`). Higher rates up to 250 Hz and even 500 Hz are achievable, but there are diminishing returns in motion smoothness as you go higher.
89
86
90
-
If you see this, or motion feels inconsistent, reduce `PAROL6_CONTROL_RATE_HZ`
91
-
- TRACE logging impacts performance; enable only when necessary (set `PAROL_TRACE=1` or use `--log-level=TRACE`)
87
+
### Performance characteristics
88
+
89
+
The library has been optimized for real-time performance:
90
+
-**Numba JIT compilation** for hot conversion functions (steps↔radians, degrees)
91
+
-**NumPy vectorization** with pre-allocated buffers to minimize allocations
92
+
-**C++ robotics-toolbox backend** for kinematics computations
93
+
-**Very few hot-loop allocations** - most buffers are reused
94
+
95
+
Even under complete IK failure (worst-case computation), the control loop typically completes in **under 2ms**. However, consistent high-rate performance requires consideration of OS scheduling—the operating system commonly interrupts user-space processes, which can cause jitter at higher rates.
96
+
97
+
**Note:** Rates above 250 Hz may require increasing IK solving tolerance, as the distance moved per tick becomes smaller and numerical precision becomes a factor.
98
+
99
+
### Tuning for higher rates
100
+
101
+
For consistent high-rate performance:
102
+
1.**Elevate process priority**: On Linux, use `nice -n -20` or `chrt -f 50` for real-time scheduling
103
+
2.**Disable logging**: TRACE and DEBUG logging add significant overhead
104
+
3.**Reduce background load**: Heavy background tasks compete for CPU time
105
+
4.**Consider CPU isolation**: Pin the controller to dedicated cores with `taskset`
106
+
107
+
### Monitoring performance
108
+
109
+
If the controller is falling behind you will see warnings like:
110
+
111
+
```
112
+
Control loop avg period degraded by +XX% (avg=Ys target=Zs); latest overrun=Ws
113
+
```
114
+
115
+
If you see this consistently, or motion feels jittery, reduce `PAROL6_CONTROL_RATE_HZ` or address scheduling issues.
92
116
93
117
## Streaming mode
94
118
- Streaming (`STREAM|ON` / `STREAM|OFF`; `client.stream_on()` / `client.stream_off()`) is intended for high-rate jogging and continuous updates
0 commit comments