I know this code is 4 years old, and it's just a small robot arm we should not expect much from, but it is a great resource to learn from and I love Mr. Skyentific's implementation of inverse kinematics here. I took a deep dive into the code looking to scale it up to a bigger and more serious arm, and I have issues with the coordinatedMotion() function and moveMotors() behavior.
Essentially, what the implemented coordinatedMove() function does is breaks the move into 3 phases: acceleration, stable speed and deceleration. Then calculates the time and number of steps needed to go through each of these stages.
HOWEVER, the steps are always administered to the driver at the maximum possible step rate, leading to all of them being sent in one batch and then just waiting for the time for the next phase of the move to come. Rinse and repeat.
What if the motors are so fast that they perform the move sooner than the time for the next movement phase comes?
What if the move is very slow and very long?
The effect is compounded by doing that to 6 motors, one at a time (!), leading to an uneven start of movement in every one (of three) phases of motion.
Verdict: this is not coordinated movement at all!
What can be done for this to be scalable?
1 - the delay between high/low pulses for each motor must be adjusted individually for all 6 motors to ensure smooth stepping from the beginning to the end of each phase of movement
2 - steps need to be administered to motors in an asynchronous way simultaneously: e.g. synced first step, and then all steps given out with various (calculated) delays, all leading to motion at the right speed for each individual motor.
3 - use a ready library and a faster microcontroller, like Teensy 4.1 and AccelStepper, or copying code from one of the 3D printer firmwares.
I know this code is 4 years old, and it's just a small robot arm we should not expect much from, but it is a great resource to learn from and I love Mr. Skyentific's implementation of inverse kinematics here. I took a deep dive into the code looking to scale it up to a bigger and more serious arm, and I have issues with the coordinatedMotion() function and moveMotors() behavior.
Essentially, what the implemented coordinatedMove() function does is breaks the move into 3 phases: acceleration, stable speed and deceleration. Then calculates the time and number of steps needed to go through each of these stages.
HOWEVER, the steps are always administered to the driver at the maximum possible step rate, leading to all of them being sent in one batch and then just waiting for the time for the next phase of the move to come. Rinse and repeat. What if the motors are so fast that they perform the move sooner than the time for the next movement phase comes? What if the move is very slow and very long? The effect is compounded by doing that to 6 motors, one at a time (!), leading to an uneven start of movement in every one (of three) phases of motion.
Verdict: this is not coordinated movement at all!
What can be done for this to be scalable? 1 - the delay between high/low pulses for each motor must be adjusted individually for all 6 motors to ensure smooth stepping from the beginning to the end of each phase of movement
2 - steps need to be administered to motors in an asynchronous way simultaneously: e.g. synced first step, and then all steps given out with various (calculated) delays, all leading to motion at the right speed for each individual motor.
3 - use a ready library and a faster microcontroller, like Teensy 4.1 and AccelStepper, or copying code from one of the 3D printer firmwares.