I’m using the VEX V5 system for a non-education application, and will often be running a single program for long periods of time, potentially days. Probably a question for @jpearman: what’s the rollover time for timer::system() and timer:systemHighResolution()? I’m using the high-res timer in a motor PID task, and as James indicated here (Accuracy of vex::task::sleep), vex::task::sleep runs on a 1mS timer tick and is subject to jitter depending on the scheduler, other tasks running, etc. I’m concerned about injecting random dt deviations into my integral and derivative term calculations relying exclusively on task::sleep.
At the top of each iteration of my PID loop, I have the following:
uint64_t current_time = timer::systemHighResolution();
// Safely handle potential rollover
uint64_t elapsed_microseconds = (current_time - last_time) & 0xFFFFFFFF; // Masking to consider only the lower bits, assuming a 32-bit overflow?
double dt = elapsed_microseconds / 1000000.0; // Convert microseconds to seconds
last_time = current_time;
To strike a balance between not blocking all my other tasks and minimizing PID loop time jitter, at the end of each PID loop iteration I run the following:
// Determine the next wake-up time, aiming for a consistent loop interval of 5 ms
uint64_t wake_up_time = last_time + 5000; // 5 ms in microseconds
while (true) {
uint64_t current_time = timer::systemHighResolution();
if (current_time < wake_up_time) { // Continue waiting if we haven't reached the wake-up time
uint64_t remaining_time = wake_up_time - current_time;
if (remaining_time > 1000) { // More than 1ms left
task::sleep(1); // Sleep to reduce CPU usage
}
} else {
break; // We've reached or passed the wake-up time
}
}
I’m assuming 32 bits on the timer overflow since the ARM9 core is 32-bit, but the VEX API doesn’t say so explicitly (VEX Help). Are there any potential hazards here I may be missing?