Return to Answer

Since both leftTargetPWM and leftActualPWM are uint8_t values, the result will also be an uint8_t value. If the sum of the two values would be larger than 255, the result will overflow and wrap. Only after that will it divide by 2. A safer way would be to divide each value by two first:

leftActualPWM = leftTargetPWM / 2 + leftActualPWM / 2;

But that way you will lose one bit of precision. You can also cast one of the values to uint16_t, so the result will be an uint16_t value:

leftActualPWM = (static_cast<uint16_t>(leftTargetPWM) + leftActualPWM) / 2;

If the CPU in your Arduino has hardware support for floating point operations, I would rather store most variables as float, and only convert to uint8_t PWM values right before calling analogWrite().

Depending on the type of the variables, the addition could overflow before the division is performed, which would result in an unexpected result, possibly leading to badly behaving motor speed.

While it might actually be safe here due to integer promotion rules, you could explicitly convert the values to a type that you know is safe for the given operation:

leftActualPWM = (static_cast<uint16_t>(leftTargetPWM) + leftActualPWM) / 2;

Or if possible, as Toby Speight suggested, use C++20's std::midpoint():

leftActualPWM = std::midpoint(leftTargetPWM, leftActualPWM);

Alternatively, if the CPU in your Arduino has hardware support for floating point operations, I would rather store most variables as float, and only convert to uint8_t PWM values right before calling analogWrite().

Since both leftTargetPWM and leftActualPWM are uit8_t values, the result will also be an uint8_t value. If the sum of the two values would be larger than 255, the result will overflow and wrap. Only after that will it divide by 2. A safer way would be to divide each value by two first:

Since both leftTargetPWM and leftActualPWM are uint8_t values, the result will also be an uint8_t value. If the sum of the two values would be larger than 255, the result will overflow and wrap. Only after that will it divide by 2. A safer way would be to divide each value by two first:

You mention "feedback control" in your comments, however what you have implemented does not rely on feedback at all, it's simply a way to smooth the transition from one speed to another. This will indeed help smooth the motion of the robot, but the way you implemented it is very naive.

You mention "feedback control" in your comments, however what you have implemented does not rely on feedback at all, instead it's an open-loop controller to smooth the transition from one speed to another. This will indeed help smooth the motion of the robot, but the way you implemented it is very naive.