Closed acf986 closed 8 months ago
And by modifying the periodicTask to
void periodicTask(flexiv::Robot& robot, flexiv::Scheduler& scheduler, flexiv::Log& log,
const std::vector<double>& initTcpPose)
{
static int i = 0;
static int N = 8000; // It works if N = 5000(5s)
if (i % N == 0)
{
log.info("Start");
robot.setMode(flexiv::Mode::RT_CARTESIAN_MOTION_FORCE_BASE);
}
else if(i % N > 0 && i % N < N-1)
{
if (i%100 == 0)
log.info("Stream " + std::to_string(i));
robot.streamCartesianMotionForce(initTcpPose);
}
else
{
log.info("-----------STOP------------");
robot.stop();
}
i++;
if (i>10000)
{
robot.stop();
scheduler.stop();
}
}
We noticed that for the several hundreds of cycles of periodicTask after the robot.setMode(flexiv::Mode::RT_CARTESIAN_MOTION_FORCE_BASE);
call, the actual frequency is no-longer at 1000Hz, but at a frequency much higher than 1000 Hz.
@acf986 I modified your example to make sure the commands are streamed for 1s instead of 0.999s in your original example, but I still observed the timeliness monitor error. If I increased the N to 2000 (2s), then no issue. @pzhu-flexiv will check on this issue.
void periodicTask(flexiv::Robot& robot, flexiv::Scheduler& scheduler, flexiv::Log& log,
const std::vector<double>& initTcpPose)
{
static int i = 0;
static int N = 1000;
if (i % (N + 2) == 0) {
robot.setMode(flexiv::Mode::RT_CARTESIAN_MOTION_FORCE_BASE);
} else if (i % (N + 2) == (N + 1)) {
robot.stop();
} else {
robot.streamCartesianMotionForce(initTcpPose);
}
i++;
if (i > 10000) {
robot.stop();
scheduler.stop();
}
}
@munseng-flexiv May I know is your testing computer patched with a realtime kernel?
@munseng-flexiv May I know is your testing computer patched with a realtime kernel?
My workstation is Ubuntu 20.04 and is not patched with the real-time kernel. It might be the reason for the bug due to less stable whole-loop latency.
@acf986 Using the very original code snippet your provided without any modification, I can't replicate the issue on RDK v0.9 with a real robot running robot software v2.10.7. I think the code cleanup and logic robustness improvements in RDK v0.9 has already fixed this bug.
May I know when will v0.9 be formally released?
May I know when will v0.9 be formally released?
The software package is at the last stage of QC, it should be available by the end of next week.
Version information
Describe the bug Timeliness monitor cut off the RDK connection under repeated mode switching.
Steps to reproduce Compile and run the following minimum reproducible example (make sure your robot arm is not in a singularity, and modify the hard coded robot IP and local IP):
The above code does the following:
Expected behavior The program work as usual.
Screenshots
Additional context NA