Go Down

Topic: Smooth motor movement (Read 638 times) previous topic - next topic


I'm trying to control a motorised fader and using the potentiometer as a position feedback. Everything works fine beside that the movement is very jitterish. Even though I made sure that it is not just a analogRead issue.

The way the motor gets new position is via serial communication. A python tool is sending new Postions frame by frame. So the "animation" is create from after effects.

My assumption is that the jitter comes from the fact that the Arduino is driving the motor to the desired position, decelerate, stop, notify about arrival, get new position value, accelerate ........

I'm not sure if this is really the case but maybe someone faced the same issue.

And in generel my question is how to tackle those issues?

- Buffer the next few positions and calculate if the motor need to decelerate or not?
This means that the whole Arduino need to have and understanding of time to know when to go to a new position and some magic code to calculate accel/decel.

- Or just sending the keyFrames with handle for the motion curve.
This seams to be even more complex.

Is the any common approach for this?


Without seeing your program ....  ?

Or links to the datasheets for the hardware you are controlling  .... ?

Two or three hours spent thinking and reading documentation solves most programming problems.


A motor control feedback loop needs to be fast, say 1000 to 10,000 times a second, serial is not the way to do it.
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]


3D printers use your first suggestion. They get commands that only specify straight-line movements but by reading ahead a few lines, they can identify curves and drive the printer in a curve that joins up the straight lines. There always has to be a buffer, otherwise the printer would have to stop and wait for each command and the print will look terrible.

Unless you have good timestamps so that the thing knows in advance when and where it's going to be, then you probably can't afford buffering. The original sender is likely to expect that the motor arrives at the commanded position as soon as the command is sent.

The keyframes idea sounds like it's close to predicting the future locations. Try to make that work.
"The problem is in the code you didn't post."


This is a control loop issue I think, not to go with incoming commands.

You have a PID loop to drive the motor?
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]


Thanks everyone for the input.

@MarkT the feedback loop is not running via Serial, this is happening on the board.

@MorganS 3D printers and G-Code is a good example since they have good accuracy and smooth motion.
I might trying to see how Grbl (https://github.com/grbl/grbl) handles this. But I agree the keyframe solution seams also the most complicated for me because that means the board needs an understanding of the whole timeline and the easing curves.

@MarkT you were right the control loop was one of the major problems here. I implemented a PID control and now the motion is much smoother. Still some little jitter moments here and there but this seam to be related to the hardware itself.

But I think this topic is still very interesting how to get from an Animation to a physical movement.


Glad the loop is working - jitter can be due to noise in the measurement of position, time-jitter in when
you read position, or an over agressive D-term (D-term tends to amplify noise).   If you aren't using a D-term
then you could try reducing overall loop gain (which will slow down response though).  Running the loop faster
will push the noise to higher frequencies and the mechanical inertia then filters it out more too I suspect.
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

Go Up