We recently bought a Spike Prime kit and are preparing to register for this year’s competition. As newcomers to the world of robotics and programming, we are still getting familiar with the programming aspect. We have been following online tutorials to learn and have made good progress up until this week. Our current goal is to create a PID line follower, which has proven to be a bit challenging for us.
.
Not sure if you can see the image. The corresponding pseudo code is:
Pseudo Code
integral =0; // initializing variable
lastest_error = 0; // initializing variable
forever { // code looping
error = SensorOutput - 50; // applying offset(5) to sensor output
p_fix = error * 0.3; // mult proportional factor(0.3) to err
integral = integral + error; // integration of the error
i_fix = integral * 0.001; // multiply by factor (0.001)
derivative = error - latest_error; // calc the difference between the old/new errors
latest_error = error; // save the current error value as “latest”
d_fix = derivative * 1; // multiply by factor (1)
correction = p_fix + i_fix + d_fix; // summation of all P.I.D control values
motor_A_power = (40% + correction%); // adjust the motorA power according the the result
motor_B_power = (40% - correction%); // adjust the motorB power according the the result
}
I have noticed an issue with the update rate of the “Error” variable, which takes approximately 6 seconds. This is causing the line follower to fail. To troubleshoot, I have removed all other commands except the line “error = SensorOutput - 50,” which reads the color sensor value and subtracts it from the setpoint of 50. Despite this simplification, the update rate remains at 6 seconds. I’m curious about what might be causing the slowdown in the update rate. Could there be a deliberate “delay” or “wait for xx seconds” statement within the “FOREVER” loop that is intentionally slowing it down?
I’m not aware of a way to see the code behind the blocks. It is possible to crack open a project file - just rename the .llsp3 to have a .zip file extension and decompress it. You’ll find a handful of json files in there that describe your program layout, but no compiled code. So I could be wrong, but blocks are probably interpreted on the Spike, not compiled.
The 6 second latency sounds weird, though. How are you measuring this? Is it possible that the workbench only updates at a slow refresh rate compared to your main program loop?
One other possibility is that you have other blocks in your program not shown in the picture?
As part of my debugging process, I decided to strip down the FOREVER loop to only include the color sensor block while removing all other blocks. To measure the update time, I used a stopwatch. Surprisingly, even with this simplified setup, it took approximately 6 seconds before I observed the ERROR variable being updated after I switched the background color paper.
Within the Spike app, on the left side of the screen, there is a collapsible panel that displays instantaneous variable values. I have noticed that other variables, such as p_fix, are being updated rapidly, with an estimated rate of 1/10 of a second per data point.
Thank you for your response. I appreciate the helpful input. It appears that the issue lies not within the FOREVER loop itself, but rather with the behavior of the color sensor in reflection mode. In the past, I had created a basic line follower using a FOREVER loop, but I used the color sensor in COLOR mode instead of reflection mode. This straightforward zig-zag line follower was successful in its operation.
Update: I made a change to the PID coefficients, setting them to 0.5, 0.00001, and 1 respectively. As a result, the line follower now operates as expected, and the color sensor reading response is rapid. I’m unsure about the specific impact of the coefficient values, particularly the integral part, on the sensor response. However, I can monitor all the instantaneous variable values from the collapsible side-panel, which provides helpful insights into the system’s behavior.
