No, slew rate applies to something in motion. The OP seems to be interested in delay between "setting" a new position in software, and the beginning of change in response to that.
That's what I detailed, in post#12. No real response since then, so
#20 has given a data that the 6V Servo takes about 100 ms time to make a 60 deg change in position. Can this not be taken as a response time of the Servo? If yes, then OP may try the sketch of #21.
You stated a desire to know the time lag from 'setting the servo' to begin of motion, and posted code that began by capturing a timestamp just before setting the servo in software, and then monitored an analog input for a position change. I've explained why that could be quite unpredictable. If you don't understand my explanation, please ask for clarification.
However, if one wanted to measure the actual response time of the servo to a new pulse width, probably the best approach would be to, immediately after setting the servo, to monitor the servo output pin for the falling edge of the pulse, and then measure the time from that point until the Analog input starts to change.
There will be two possible values returned by this approach; the majority should provide the number you're seeking, while a minority will provide a number approximately 20 ms longer, due to the unpredictable timing between the interrupt cycle and your code.
The arm moves between 0 and 90 degrees. The Arduino operates at 5V, and I found that the pulses corresponding to 0 and 90 degrees are 123 and 326, respectively. The pulse width range is from 551 to 1471 microseconds.
I conducted a test to determine the smallest number of pulses that result in a detectable movement in degrees.
• The total number of pulses for 0 to 90 degrees is 1471 - 551 =920 microseconds.
• After testing, I observed that if the Arduino sends a signal at every single microsecond, the servo cannot respond properly.
• The smallest number of microseconds the servo could respond to was 5 microseconds, meaning 5 microseconds produced the smallest observable movement.
• Therefore, the number of steps from 0 to 90 degrees becomes 920 / 5 = 184 steps. Witch I name it “call”
Why do I use this method?
Although the servo is typically controlled in 1-degree in each step (90 steps for 90 degrees), using microsecond-level precision allows me to divide the range into 184 finer steps or call. This provides smoother and more accurate movement, taking full advantage of the servo's capability.
As shown in pictures (1) and (2), I need to find the minimum response time (send data time) it takes for the Arduino signal to reach the servo just before the servo starts moving. (in other words, the time it takes between sending the signal to the motor beginning to move)
To do this, my teacher suggested a method:
• Run the arm through 184 steps (0 to 90 degrees), varying the number of "send" commands:
The tests go like this. For the first test we send one signal (call) to the motor to move from 0 to 90 degrees. During the motion, we measure the time for the movement and the process. Then we subtract the process time with the movement time to get the total response time of that specific number of calls.
After that, we redo the motion, but now we add 1 more call to send for the servos movement (in other words, it will go from 0 to 45 to 90 degrees), we measure the process and movement time of that to get the response time for that many calls. Repeat this 184 times to get all the possible response times.
Clearer explanation is provided in picture (1) and (2) and (3).
Response time= process time – movement time
In this step, I need to record the response times found in step 4, plot them on graph number 4 ("time-call"), and draw a trend line to estimate the average response time.
Currently, I am stuck on step 4 and need help. I would appreciate it if someone could assist me.
I have flagged this for merging with your previous thread by a moderator, as it is simply a disguised continuation. Please do not cross-post like this.
Please also address the on-topic questions you have been asked by myself and other posters, and ignore the OT diversions as much as possible.
@clemontine ,
I've merged your 2 topics as the second one seems to be a continuation of the first. I can't help thinking you started the second because this one wandered off all over the place. Do please continue here.
Everyone,
I've deleted the discussion about the finer points of servo behaviour because they clearly don't help the OP at all, and the OP seemed to give up and start a new topic. Please continue to help but please keep in mind what is helpful for the OP and what should be discussed elsewhere if it's worth discussing at all.
Please note that when doing this I probably deleted some of the good stuff, if so then I apologise, but it's very hard to know what to delete and what to keep sometimes. If you have pertinent questions for the OP and I have deleted them then please ask again and be sure to direct what you say to the OP. Also the same with answers, if I've deleted useful information for the OP please re-post it.
Your teacher has laid out the steps quite clearly, so if you are having trouble understanding their instructions, you will need to point out specifically what part or parts of the provided instructions you are having trouble understanding or implementing.
I would suggest that you ignore this part:
Instead, measure the time from just before when the first servo command is executed until when it reaches 90°; repeat this for each of the following cases:
0°→90°
0°→45°, followed by 45°→90°
0°→30°; 30°→60°; 60°→90°
etc.
Then create the scatter plot shown in your first image, graphing the number of servo commands (1, 2, 3,...) as a function of the measured total time to reach 90°.
If the graph appears to be linear, perform a linear regression — the best fit slope will represent the overhead for each servo command call. The intercept, when divided into 90°, will represent an effective slew rate.
Why do you believe there is a problem with the code currently shown in your post #1 (last edited 17 Jun 2025 09:13 UTC)? What happens when you run the code?
There are some minor adjustments that could be made, for example, inserting a 1-second delay after starting the serial communication:
Serial.begin(115200);
delay(1000);
Serial.println("Serial monitor is ready.");
You might consider including min and max arguments when attaching the servo:
You could also try to adjust the map() limits in your readEncoder() function based on your calibration in post #13:
con_angle = map(raw, 121, 326, 551, 1471);
Furthermore, your stopping criterion should probably be adjusted to account for the known direction of motion and the precision of your angle measurements:
do { readEncoder(); } while (endPulse - con_angle > 5);
Other than that, I don't see any obvious reason why your code shouldn't run. What does it output to the Serial Monitor?
