# Kinematics and Acceleration Windows

I am a CS student who is currently programming for a robotics project. The kinematic physics at play has me a bit confused, and I am wondering if someone can provide some clarity on this problem:

I need my robot to accelerate to a cruising velocity, cruise for a bit, and then decelerate to a stop. The user defines the acceleration, deceleration, and cruising speed values. I have the ability to know how far the robot has traveled at any given point (polling the encoders).

I recall the Kinematic equations:

I solved equation 1 to be in terms of time and then substituted for time into equation 2. I then plug in my acceleration, initial velocity, and desired final velocity into the new equation and get a value for delta X. This is my "acceleration window." I do not want to used elapsed time as a metric because the processors being used are unreliable at reporting time accurately.

If my robot is in the acceleration window, it gets a new velocity using equation 4 (providing the current speed it is moving at, the distance traveled, and the specified acceleration). If it has traveled outside of the acceleration window, it moves at the cruising velocity (no math needed). If it enters the deceleration window, the 4th equation is again used, but delta X is adjusted to be the distance from the start of the deceleration window to where we are now and acceleration is swapped to the user-specified deceleration.

Unfortunately, these windows appear to be too large. The robot accelerates past the target cruising velocity, and it begins to decelerate too early.

How can I determine the size of my acceleration and deceleration windows?

• I'd like to help but can't understand the question. So, you can measure the traveled distance but not the time elapsed right? Eq. 4 is correct for the final velocity when the object is accelerated through some distance. So what is the problem? Commented Nov 6, 2019 at 21:19
• Correct, I can only measure distance traveled. Essentially, I need to pre-calculate two positions. The first position is the position for which equation 4 yields the cruising velocity. The second position is when I must commence deceleration so that the robot comes to a smooth stop as it reaches the total distance it was told to travel. Commented Nov 6, 2019 at 21:23
• You probably need to measure velocity and distance traveled, rather than calculate them. You say that you can get distance traveled, and you should be able to poll the encoders over a short time interval to get velocity, which is $v=\frac{\Delta x}{\Delta t}$ Commented Nov 6, 2019 at 21:56
• @DavidWhite are you suggesting that the velocity I am setting the robot to move at may not be the actual velocity the robot moves at? I am hesitant to use delta t because the processors used are unreliable for time calculations. Commented Nov 6, 2019 at 22:52
• @AndrewCarluccio, I'm suggesting that it should be much easier to measure two closely spaced times, do a subtraction, and arrive at delta t. There should be a system clock somewhere in your software. Also, you need feedback for your application, and a calculation is pure feedforward, which should be VERIFIED for something that operates in the real world. Commented Nov 7, 2019 at 4:52

### Schematics :

Time needed to accelerate to cruising speed or to decelerate it to zero speed is $$t = v_c/a$$

### cruising point

$$x_c = \frac{1}{2}a_{_+}t^2 = \frac{v_c^2}{2a_{_+}}$$

### deceleration point

$$L - x_d= v_ct-\frac{1}{2}a_{_-}t^2 = \frac{v_c^2}{2a_{_-}}$$

So,

$$x_d = L - \frac{v_c^2}{2a_{_-}}$$

Where $$v_c$$ - cruising speed; $$a_{_+}$$, $$a_{_-}$$ - acceleration and deceleration; $$L$$ - total distance until stop point

### bounding conditions

Keep in mind that if you want your robot to stop at maximum distance $$L$$ allowed to travel, then $$x_d \geq x_c$$ Substituting expressions we get above, results in boundary condition :

$$L \geq \frac{v_c^2}{2}\left(\frac{1}{a_{_+}}+\frac{1}{a_{_-}}\right)$$

If this condition is not met - your robot will not stop at destination, but pass through instead

• First, thank you so much for the detail of this answer. I agree with your depictions and theory. I implemented what you provided and confirmed my code was producing the correct results when compared to what I could calculate by hand. Unfortunately, my robot still accelerates past the cruising velocity and decelerates sharply very early. I made a video of the observed behavior at youtu.be/cNRvnCcZc7M and the output of the program in the description. Commented Nov 7, 2019 at 15:23
• You are welcome. I believe my calculations are OK. So problem may be elsewhere. Several research ideas : 1. SI units, I see that you measure distance in ticks, maybe some error in program converting to SI units ? 2. In my formulas deceleration is in absolute value (don't put - sign in front of it) 3. Verify that robot has plenty of distance to move (bound $L$ condition) 4. Finally reaching negative end velocity clearly indicates some serious problem, Commented Nov 7, 2019 at 19:43
• probably robot has too much time for deceleration,- so either $x_d$ calculation in program results in too small value or some error in distance polling sensors, double-check distance sensor errors. It may be that they are damaged and/or not measuring distance in linear response way. Commented Nov 7, 2019 at 20:03
• I am going to mark this response as the answer. We have continued our testing as the issue persists, but clearly the issue is not caused by the original question alone, and as your response satisfies the question posed here, it should be marked as such. I will comment again when we resolve everything. Commented Nov 10, 2019 at 16:39
• I had a breakthrough today and realized that I should be passing the difference between my current encoder reading and my previous encoder reading at each evaluation of equation 4 while moving. This solved the issue! Commented Nov 12, 2019 at 0:40